<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<blockquote style="border: 0px none;"
cite="mid:5447DE6D.6020101@landley.net" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="rob@landley.net" photoname="Rob Landley"
src="cid:part1.07000001.03060708@e43.eu"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:rob@landley.net"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Rob Landley</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">22 October 2014
17:42</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><pre wrap="">On 10/22/14 09:25, James McMechan wrote:
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap=""><!---->
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.
</pre><blockquote type="cite"><pre wrap="">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
</pre></blockquote><pre wrap=""><!---->
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?
</pre><blockquote type="cite"><pre wrap="">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
</pre></blockquote><pre wrap=""><!---->
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...
</pre><blockquote type="cite"><pre wrap="">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
</pre></blockquote><pre wrap=""><!---->
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:
<a class="moz-txt-link-freetext" href="http://landley.net/aboriginal/architectures.html">http://landley.net/aboriginal/architectures.html</a>
Because I don't _know_ this information, and what research I did do is a
bit stale now...
Rob
</pre></div>
</blockquote>
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):<br>
<ul>
<li>ARMv5 didn't make Thumb mandatory (hence ARMv5T); that was ARMv6</li>
<li>Thumb-2 was actually an ARMv6 extension (ARMv6T2)</li>
<li>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.<br>
</li>
<li>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<br>
</li>
<li>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)<br>
</li>
<li>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</li>
<li>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 <span style="font-style: italic;">did something
two decades ago, still living entirely on the results of that thing)</span><br>
</li>
<li>The Acorn BBC Micro was a 6502 based machine. ARM was developed
for its' 32-bit successor.</li>
<li>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.<br>
</li>
</ul>
</body></html>