---------- ye olde gpm cut n' paste starts tothings:/mnt/archives/clfs-aarch64/linux-4.8.7$ find . -name bcm2837-rpi-3-b.dtb
./arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb
---------- ye olde gpm cut n' paste ends
Built with the current aarch64-unknown-linux-gnu cross compiler (gcc v6.2.0) resident on a x86_64-silvermont-linux-gnu host with the same
gcc version.
Also worth mentioning is that the linux-4.8.7 source is unpatched and
was obtained from kernel.org so it hasn't been altered in any way
shape or form.
For the curious; tothings is the unpriviledged hacker guy on the x86_64-silvermont-linux-gnu host who built the
aarch64-unknown-linux-gnu toolchain and isn't afraid to use it.
As per usual, time will tell.
Methinks you need to make a step-by-step instruction
people interested that don't want the headaches. :)
I may indeed be stuck using 32 bit for now
Have you done anything else with it? Like tried to build any
useful programs?
I should get over to Amazon and get my 2nd RPi3 for the
whole-house media server.
I may indeed be stuck using 32 bit for now
Near as I can tell you are not alone. I have yet to run across anyone claiming pure 64 bit on any arm64 platform, nevermind raspi3. It
might turn out that I am the first and the ONLY one willing to go out
on that particular limb ... if indeed I end up on that particular
limb. I haven't committed. ;-)
I have yet to get a first one. However we're on totally different wavelengths so I doubt you need my interference for your plans. If I commit then my plan is to get a working pure 64 bit gcc and friends envoroment working on it ... if indeed there is an 'it'. I am in no
rush.
From what I've seen the ODROID-C2 has some working 64bit stuff out
there.
ArchLinuxARM
5-8 business days.
ArchLinuxARM
I heard a rumour that the 64 bit version was being abandoned. Maybe
they are putting it on hold until aarch64 matures a bit. If so I can understand why.
5-8 business days.
Heh, heh. Like I previously said, way too much fun. There ought to
be a law.
Check back on some previous messages.
Check back on some previous messages.
If you mean ArchLinuxARM-aarch64-latest I already have it. At the
moment I lack a proper target for it but no matter as it lacks gcc and friends so as a candidate for development there isn't the tools to kickstart anything.
As for the latest kernel built using the cross compiler I am heartened
to see that stock kernel source (no patching) looks to be working as
far as the raspi3 and arm64 is concerned. Unfortunetly it won't work
with qemu due to lack of proper machine emulation.
Can't win them all.
What do you need qemu for? Are you trying to keep up with your
DOS-think crowd? :)
Did you receive my netmail?
Yes. I sent a direct reply to it. I suspect an incompatible
pktheader but the netmail reply will tell the tale. I have been using
a 2.2 pktheader for awhile now and it did work with all concerned up
to now. It still works to the Vancouver link.
I don't think hpt supports type 2.2 packets after sifting through
the docs either. :/
I don't think hpt supports type 2.2 packets after sifting through
the docs either. :/
It was working up to a couple days ago. :-/
It only seems to be a couple specific messages. This one was
obviously fine, and processed accordingly
That's why I had asked. It only seems to be a couple specific messages. This one was obviously fine, and processed accordingly.
-={ 2016-11-12 12:03:08.411157271-06:00 }=-
Hey Nicholas!
It only seems to be a couple specific messages. This one wasThat is because I switched back to the old route once I noticed the change in the pkts I get from you.
obviously fine, and processed accordingly
This reply is via the old route.
Life is good,
Maurice
... G-|-# a wyrd swa hio scel.
Fate ever goes as it must.
This makes 3 replies to the above message.
The above made it to here.
since we both know it isn't always the case.
What are we betting
What are we betting that neither of the others makes it to the
other?
It only seems to be a couple specific messages. This one was
obviously fine, and processed accordingly
That is because I switched back to the old route once I noticed the
change in the pkts I get from you.
This reply is via the old route.
This makes 3 replies to the above message. Let's see which ones make
it all the way.
What are we betting that neither of the others makes it to the
other?
So far only you are the only one making it across the board ... but
then again you already knew this didn't you?
I hadn't realized you could switch it up on the fly.
Was 2.2 packets ever fully adopted?
Seems like quite a few softwares don't support it.
You tend to talk to yourself quite a bit.
Was 2.2 packets ever fully adopted? Or did it ever make it out of proposal? Seems like quite a few softwares don't support it.
I'm fairly certain 2.2 packets open up the headers to allow larger
fields, correct?
That's most likely why hpt wasn't liking it, as it is stated in hpt's
docs that 2+ have 8 character limits on like pkt password and whatnot.
I hadn't realized you could switch it up on the fly.
Yep. I used to have another path not too long ago. I am beginning to wonder if it was a bad idea to switch it off now. :-/
Was 2.2 packets ever fully adopted?
Seems like quite a few softwares don't support it.
It was working with yours. Beats me why it now doesn't as I am doing
it exactly the same. I did notice that you started zipping msgs
destined for me around the same time it broke. Is that the cause? I don't do zip nor support it in any way shape or form.
Anyhow I see there are missing messages that didn't make it through
the loop and I am unsure if there is anything I can do about it at
this end other than to pay myself off with the 15 year old scotch. I
am willing to try again with the route through you but don't know what your node now expects from mine.
If you insist on using type 2.2 packets
At the moment my node is expecting type 2+ packets.
Seems like quite a few softwares don't support it.
It was working with yours. Beats me why it now doesn't as I am doing
it exactly the same. I did notice that you started zipping msgs
destined for me around the same time it broke. Is that the cause? I don't do zip nor support it in any way shape or form.
If you insist on using type 2.2 packets
I don't use any of them. I was/am only tacking them onto the
outbound. If you insist on a different format than what was working
just fine then you should have let me know beforehand. I haven't
changed anything as far as outbound is concerned but am willing to try something different if it will help.
At the moment my node is expecting type 2+ packets.
I tried that with one direct netmail to you and you never responded or acknowledged it so I assumed it was broken as well. Beats me why but
I haven't been dealing with netmail so it could easily be something
there. I am seeing yours just fine but then again no matter what type
the pkt header is it ends up being ignored at this end. Near as I can tell the first 58 bytes of pkt's are utter crap and always have been.
What do you see in them?
or something like that ;)
I let you know as soon as I was aware of it.
They were stopped here, most likely because they were type 2.2
packets. At the moment my node is expecting type 2+ packets. If I can
find something in the documentation that states I can change that, I
will most definitely let you know.
unless i'm mistaken, HPT recognises all three Type 2 PKT formats...
or something like that ;)
And what format would it's pkt header use? ;-)
Anyhow the first and only areafix worked fine and I am not going to
change ANYTHING until I am sure I am the cause of any recent bug. At
this writing I am not convinced that I am.
They were stopped here, most likely because they were type 2.2
packets. At the moment my node is expecting type 2+ packets. If I
can find something in the documentation that states I can change
that, I will most definitely let you know.
unless i'm mistaken, HPT recognises all three Type 2 PKT formats...
i'm fairly certain i've thrown all three types at it over here but
that was a while back :?
changing the archiver shouldn't affect the PKT headers at all
Here is the EXACT routine I use here to generate 2.2 headers and it
should be noted was used for the original areafix that originated from here to turn on echos not too long ago;
---------- ye olde gpm cut n' paste starts
# generate Type 2.2 pktHeader
echo "$origNode,$destNode,$origPoint,$destPoint,,2,2,$origNet,$destNet ,255,0,,$origZone,$destZone,fidonet,fidonet,0" | \ perl -e 'while(<>){@myarray = split(",", $_);};\
print pack("S4a8S4C2a8S2a8a8I", @myarray);' > $OUTPKT ---------- ye olde gpm cut n' paste ends
It can. There are lossy archive/compression software especially the
ones that combine the two. I won't even mention the ones that are obsolete especially regarding datetime stamps. However I doubt that
is the real issue but better to be safe than sorry. It isn't like
there aren't already many horror stories about pkzip and the ilk. I
see no good reason to tempt the fates. Do you?
Having said that we'll never know since he already switched it back
but I haven't sent any more messages as I am waiting for confirmation before sending any more test messages. Also I wouldn't mind your
input about the type 2.2 routine I posted in a previous reply to you.
Here is the EXACT routine I use here to generate 2.2 headers and it
should be noted was used for the original areafix that originated from here to turn on echos not too long ago;
---------- ye olde gpm cut n' paste starts
# generate Type 2.2 pktHeader
echo "$origNode,$destNode,$origPoint,$destPoint,,2,2,$origNet,$destNet ,255,0,,$origZone,$destZone,fidonet,fidonet,0" | \ perl -e 'while(<>){@myarray = split(",", $_);};\
print pack("S4a8S4C2a8S2a8a8I", @myarray);' > $OUTPKT ---------- ye olde gpm cut n' paste ends
Here is the EXACT routine I use here to generate 2.2 headers and it
should be noted was used for the original areafix that originated from here to turn on echos not too long ago;
---------- ye olde gpm cut n' paste starts
# generate Type 2.2 pktHeader
echo "$origNode,$destNode,$origPoint,$destPoint,,2,2,$origNet,$destNet ,255,0,,$origZone,$destZone,fidonet,fidonet,0" | \ perl -e 'while(<>){@myarray = split(",", $_);};\
print pack("S4a8S4C2a8S2a8a8I", @myarray);' > $OUTPKT ---------- ye olde gpm cut n' paste ends
CapabilityWord error in following pkt!
further testing to get this figured out
is why is there two "fidonet" entries in the above routine?
CapabilityWord error in following pkt!
I'll have to look that up to see what field(s) it is supposed to
match. Also due to the lack of suitable documentation, I will reverse engineer your pkt headers and see what I can match up to my 2+ pkt generator and see what gives there.
If you are aware of any PROPER documentation where a thingy like the
perl oneliner I posted can be formed from, now would be an excellent
time to bring it up and possibly save much grief. I doubt such documentation truly exists but maybe. I am unaware of any and
originally built that one from using the hit and miss method.
is why is there two "fidonet" entries in the above routine?
Those match with domain names for 5d addressing such as 1:153/7001.0@fidonet. They can easily be changed to variables if and
when it ever matters. At the moment it doesn't ... does it?
BTW the reason I prefer type 2.2, not that I really care, is that it contains no datetime stamps which might help out systems that cannot generate datetime stamps, especially obsolete ones. Just a thought.
Not sure if that helps you any.
I couldn't find any physical capability words
Information is a wonderful thing.
Seems as though BBBS may do the same thing in this regard.
Not really although it does tell me that hpt is not reading it as type 2.2. The datetime stamp is a dead giveaway.
I couldn't find any physical capability words
I am not sure what you mean but I think fields 6 and 7 might be what you're thinking about. I have a bash script I wrote to test the first
58 bytes of raw pkt files in an attempt to distinguish the pkt type.
It seems to work but was based on the document neither of us seems to
be able to locate on the ftsc site.
I think we can crack it.
Oh well ... back to the drawing board eh? I'll fire off a warning
shot here when I have something worth testing. I plan to first look
at the bash pkt determinator and see what I can learn from it before hacking headers.
A bottle of 15 year old scotch.
reply to friends might help
---------- ye olde gpm cut n' paste starts
# generate Type 2 pktHeader
PKT_DATE=( $(date +"%Y %-m %-d %-H %-M %-S" | \
awk 'BEGIN { OFS = "," } {print $1, $2-1, $3, $4, $5, $6}') )
echo -e "$origNode,$destNode,${PKT_DATE[@]},0,2,$origNet,$destNet,0,0,,$origZo ne,$destZone," | \ perl -e 'while(<>){@myarray = split(/,/, $_);};\
print pack("S12C2a8S2a20", @myarray);' > $OUTPKT
---------- ye olde gpm cut n' paste ends
Anyhow I am glad to see type 2 pkt headers working again. I am going
to leave the type 2.2 links as is for now as I think that is a better
type especially for nodes that cannot do datetime stamps.
Time for bed. I earned it methinks.
changing the archiver shouldn't affect the PKT headers at all
It can.
There are lossy archive/compression software especially the ones that combine the two. I won't even mention the ones that are obsolete especially regarding datetime stamps. However I doubt that is the
real issue but better to be safe than sorry. It isn't like there
aren't already many horror stories about pkzip and the ilk. I see no
good reason to tempt the fates. Do you?
Having said that we'll never know since he already switched it back
but I haven't sent any more messages as I am waiting for confirmation before sending any more test messages. Also I wouldn't mind your
input about the type 2.2 routine I posted in a previous reply to you.
They were stopped here, most likely because they were type 2.2
packets. At the moment my node is expecting type 2+ packets. If I
can find something in the documentation that states I can change
that, I will most definitely let you know.
unless i'm mistaken, HPT recognises all three Type 2 PKT formats...
i'm fairly certain i've thrown all three types at it over here but
that was a while back :?
From hpt.texi:
"tossing packets of 2, 2.0 & 2+ types"
and..
"PKT password is limited to 8 characters, this is PKT 2+ limit."
That is all I found in that document regarding packet header types. A search for "2.2" returns nothing, and a search for "2+" returns the
two above lines. That was all I could see on the matter.
hpt does come with a "pktinfo" program I may be able to run on one of
his packets that fails here. That may lead to more clues.
ask,---------- ye olde gpm cut n' paste starts
# generate Type 2.2 pktHeader
echo "$origNode,$destNode,$origPoint,$destPoint,,2,2,$origNet,$destNet
,255,0,,$origZone,$destZone,fidonet,fidonet,0" | \ perl -e
'while(<>){@myarray = split(",", $_);};\
print pack("S4a8S4C2a8S2a8a8I", @myarray);' > $OUTPKT
---------- ye olde gpm cut n' paste ends
So your generated packet headers will only work with Fidonet? Reason I
is why is there two "fidonet" entries in the above routine?
By the way, hpt.texi mentions this "CapabilityWord" as something used
by old software.
IgnoreCapWord definition:
"Ignoring Capability Word in pkt files. If some pkt moved to bad. This may help, but not recommended. It is better to change old software."
So I'm guessing you're using some kind of capability word in your
headers that are causing hpt to consider it bad.
we stopped using archivers over here for FTN stuffs over a decade
ago...
i saw it but i haven't had time to extract it and give it a play
Looks good.
That brings up the differences between type 2 and type 2+ though.
I believe zone and point information was introduced.
If we can get it there,
i saw it but i haven't had time to extract it and give it a play
I see your reply to Nick with cited ftsc documents which I plan to reference once I get an opportunity to read them over and compare to
what I currently have. Thank you for that.
my type 2+ stuff uses both of the named documents
it may have been the document that Stephen Hurd (Deuce) was
working on
my type 2+ stuff uses both of the named documents
I see that but have yet to take a looksee at either. Thanks for the
heads up.
it may have been the document that Stephen Hurd (Deuce) was working
on
I am wondering if that is the same one I saw and now looks to be
missing in action. If so it was a well written doc as per all three
pkt types.
Speaking of a difference I see in your READPKT.PAS that proddata in
type 2.2 is defined as "array[0..3] of char" whereas in the posted
type 2.2 I have it as a 32 bit integer. FSC-0045 doesn't define it
but does have it's width specified as 4 bytes which doesn't help
matters any. Personally either/or is fine with me but I was hoping to
get it right and a 32 bit integer is not the same as a 4 byte
character string/array/whatever other than they are both 4 bytes at
the same offset.
seems pretty well open ended as far as those bytes are concerned
Are we friends?
If so then you are welcome to share the planned 15
year old but I suggest you bring some Danish beer to go along with it.
We can use them as chasers.
na i will take it return home
i'm not certain but i'm fairly sure that i've run some 2.2 PKTs
through the reader
Note that all the echo calls are one line or at least were when
they left here.
i'm not certain but i'm fairly sure that i've run some 2.2 PKTs
through the reader
Here is something I'd appreciate your input on;
i am not ignoring this... i plan on digging into it
to play with this code...
Here is something I'd appreciate your input on;
---------- pkt type data vector generator starts
---------- pkt type data vector generator endsthe
Note that all the echo calls are one line or at least were when they left here. Also I used your Origin line address with the domain addition as
destAddr. Also, also added ansi colours (red) the the type echo's (see 'echo -e' calls). All output is pure ascii
and the only thing I can see that could possibly benefit from utf-8 encoding would be the domain names but then due to the byte
limitations that would be even more crippling than it already is.
Note that all the echo calls are one line or at least were when they
left here.
I hate to be the one to tell you this but the entire message got
tampered with somewhere along the line.
On the plus side, at least it made it through the loop although I am
not convinced it is worth it given the obvious mess made of it.
:::sigh:::
i am not ignoring this... i plan on digging into it
Take your time, I am in no rush as I have (had) it all working at one
time or another. For my part I just want verification to it's
validity given the lack of published standards.
to play with this code...
Not much to play with. It's missing the conversion to binary but that wouldn't help much as far as identification as valid data as per the
three types.
how do you convert it to binary?
FTN domains are of similar nature to NETBIOS and NOVELL domains
restricted to printable ASCII characters
i want to look at it with a couple of packet inspection tools...
i want that conversion to binary so i can see it with some pkt
readers
how do you convert it to binary?
perl oneliners. Calls to the builtin pack() function to be more specific.
i want to look at it with a couple of packet inspection tools...
Sure.
something that should be added at some point if the code is going
to be shared with others
something that should be added at some point if the code is going to
be shared with others
For sure.
On that note when can one expect a valid fts doc(s) regarding pkt
types?
proposals cannot become standards until they are in widespread use
proposals cannot become standards until they are in widespread use
How many more years?
It would be MUCH cheaper to just buy it in Denmark. Also it is
probably cheaper for you to fly to Scotland and buy it there.
Have you ever been to Scotland?
this 3rd attempt has been doing OK
why previous proposals have not been trotted back out yet is
above my pay grade AFAIK...
it would be like snowballs outside of danmark
i have yes, seen a alumimium factory
this 3rd attempt has been doing OK
From this angle they look just as sleepy as past ones and it looked
like they'd sleep right through the usual election. Fairly tame in comparison to past ones.
why previous proposals have not been trotted back out yet is above my
pay grade AFAIK...
Understood. I can wait a couple of weeks, perhaps until the new year
if needed. Maybe then someone will drag out the proposal I last saw
and perhaps we can decipher something half-ass useful out of it. ;-)
Good thing I am in no rush, and like the ftsc, am going nowhere fast. :::evil grin:::
i would have proposed that you be nominated
all the more reason for you to join in the fun!
i would have proposed that you be nominated
What have I ever done to you? ;-)
all the more reason for you to join in the fun!
I have done that in the past. At the moment I am distracted with
getting a handle on stuff I have a direct influence over such as the
type 2, 2+ and 2.2 data vectors I posted to you. Speaking of which I changed the 2+ one's I specifier to a4 (ascii string) from I (32 bit integer) and now see XPKT show up on a certain node's type 2+ data
vector. I like the ascii data vectors. :-)
one of the Type 3 packet proposals... i seem to recall also a
Type 10 proposal
at least one of the Type 3 proposals was all text oriented
Definetly something to think about but in the meantime I believe the better distraction would be to see official documentation for the currently used pkt headers. Of those I see type 2.2 being the best
simply because of the lack of a questionable datetime stamp.
i agree that the existing type 2.2 and 2+ proposals should be
elevated to standards
the timestamp thing in the packet headers of type 2 and 2+?
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495947:06:56 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 287,048 |