[Toybox] [Aboriginal] big endian problems

[wj]

interesting really !
It reminds me to my first "wrapping cabling" the 6800  ... time ago
to build a C.A.M.A.C compatible micro for data acquisition !!!!
( transition from programming on ibm360 with triodes pentodes as
room heater )

On jeu., 2014-10-23 at 01:16 +0100, Owen Shepherd wrote:
> 
> > 
> > Rob Landley
> > 22 October 2014 17:42
> > On 10/22/14 09:25, James McMechan wrote:
> > > I was trying to do a multi-architecture buildall and it blew up on the 2nd architecture on both sparc and ppc it seems the toybox md5sum sha1sum are not big endian safe, i have not puzzled out the logic yet.
> > 
> > Sigh. It _was_ bigendian safe, before I applied the unroll patch to
> > speed it up back in may.
> > 
> > I have a second unroll patch applied to my local tree that speeds it up
> > further, but it's just too ugly for words. I've been meaning to poke at
> > this and try to clean up the faster version, but getting it to be both
> > simple and fast is _hard_, and haven't made a big enough block of time
> > to sit down and stare at it yet.
> > 
> > I hadn't done a proper retest because I wasn't done changing it. My bad,
> > sorry. I'll build a fresh powerpc test image here and at least fix the
> > big endian failure today.
> > 
> > > Seagate GoFlex Home ARM 1.2GHz kirkwood 5te 128MB works
> > > required chmod 666 /dev/null and then 'ln -s libc-2.18.so libc.so.0' so native
> > > compiler would build under arch linux
> > 
> > Um, did you make this change _to_ arch linux? (Confused, the aboriginal
> > linux system image I have lying around already has /dev/null chmod 666,
> > and libc.so.0 is a symlink to libuClibc-0.9.33.2.so. Linking glibc to
> > libc.so.0 is... ouch?
> > 
> > > took 287m for a single arch compile
> > > 
> > > 
> > > my other systems are still in need of work
> > > AMD Athlon64 - power supply replacement
> > > Intel P75 24MB - networking problems
> > > hp sh3 32MB - have not yet got aboriginal to build for sh3
> > 
> > Oh wow, you have an sh3 test system?
> > 
> > I'm currently trying to get aboriginal to build for sh2, which is nommu
> > and thus weird. (I've got a little xylinx fpga here with an sh2
> > bitstream, and an old code sourcery sh2 toolchain hooked into a
> > buildroot fork with a kernel and such.) I've already got sh4 working in
> > aboriginal, so collecting the whole set would be nice on general principles.
> > 
> > Adding sh2 and sh3 support to qemu is also on the todo list. I _think_
> > it's mostly a question of chopping sh4 down to the earlier/smaller
> > instruction sets (and disabling the mmu for sh2), but I have a giant PDF
> > to read through to see what the actual differences are...
> > 
> > > TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel
> > > hoo-too Tripmate Elite - also MIPS not yet tested
> > 
> > mips has a sort of oabi/eabi thing going on, where the old mipsr4k
> > binaries I'm building (with the hard 256 meg memory constraint) are
> > being replaced by "mips32" which is some confusing thing I need to read
> > up on and has some kind of "kernel space code and userspace code aren't
> > the same thing" weirdness going on that I got half an explanation of and
> > don't understand.
> > 
> > If anybody has a decent explanation of that lying around, I'd love to
> > add it to the link collection. I never properly finished:
> > 
> >   http://landley.net/aboriginal/architectures.html
> > 
> > Because I don't _know_ this information, and what research I did do is a
> > bit stale now...
> > 
> > Rob
> I don't have any info on MIPS ABI transitions, but I do have a few
> comments and corrections to make to that page (mostly regarding ARM,
> but a few other historical trivia):
>       * ARMv5 didn't make Thumb mandatory (hence ARMv5T); that was
>         ARMv6
>       * Thumb-2 was actually an ARMv6 extension (ARMv6T2)
>       * ARMv7-M also have a completely different exception model
>         (ARMv6-M is a further stripped down version of ARMv7-M, not
>         actually a predecessor). The M stands for microcontroller
>         (much like the v7-R variant stands for Realtime, of the hard
>         realtime sort). Being a microcontroller arch, backwards
>         compatibility is pretty unimportant.
>       * Big vs Little endian is a runtime distinction as well (APSR
>         contains two bits - BE8 and BE32 - which can be used to switch
>         into one of the two big endian modes, depending upon which
>         your processor supports. BE8 is the one all modern processors
>         support, BE32 is the one all older processors support, IIRC).
>         Nobody that I know of would use "armv4tl" as an architecture
>         designator
>       * The ABI commonly called "OABI" is actually an old, deprecated
>         version of the EABI (it was deprecated because it didnt'
>         interwork with Thumb code, or indeed work with Thumb very well
>         at all). Linux took the opportunity to rework its' system call
>         ABI at the same time. You can run EABI software on ARMv4 (no
>         Thumb), with some caveats (you need to translate all BX
>         instructions into MOV PC instructions)
>       * Motorola didn't get their engineers back in their lawsuit
>         against MOS Technologies. The eventual settlement was that MOS
>         would discontinue the 6501, a 6800 pin-compatible variant of
>         the 6502
>       * Following on from this, the 68000 was the successor to (and
>         designed by the same team as) the 6809, Motorola's "6800 v2",
>         done after the engineers left to found MOS (several of which
>         would later move to the Western Design Center, which produced
>         the 65816. WDC are an interesting example of did something two
>         decades ago, still living entirely on the results of that
>         thing)
>       * The Acorn BBC Micro was a 6502 based machine. ARM was
>         developed for its' 32-bit successor.
>       * AArch64 is a completely revised architecture. In particular,
>         it has a new, cleaner instruction set; the system register set
>         has been redesigned; the whole privilege level and hypervisor
>         functionality has been redone; the general purpose register
>         file has been enlarged and all special purpose registers
>         removed (SP is no longer in the register file, for one). I
>         wouldn't be so sure of a merge.
> _______________________________________________
> Aboriginal mailing list
> Aboriginal at lists.landley.net
> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net



 1414048835.0