Re: ARM EABI port: minimum CPU choice
Hi all,
I'm not a DD but I am an experienced Unix sysadmin. And as a sysadmin I want to add my 2 cents. Given the limited supply of effort to move Debian ARM forward, it's important to choose an easy-to-maintain, generic solution (personally, I would go insane in my job if I didn't do this on a regular basis). Otherwise, it will take much longer to impliment, and hurt Debian ARM's chances of building up more of a "critical-mass" community sooner.
And after reading this thread so far, I think the easiest-to-maintain, reasonable solution is to not have thumb instructions supported, and worry about thumb-only ARM CPUs *only* when thumb-only processors hit the mainstream market (at which time Debian users might actually acquire them and want to use stock Debian on them).
I think it's very important to economize the efforts of DD's to maintain/develop Debian ARM, and strive towards the generic interests of end users having easy access to popular Debian software that works well (like firefox). I don't think DD's should cater to 3rd party software makers who *might* require thumb. Hopefully any such 3rd partys can choose (or re-engineer) to not use thumb of they want to easily run on a Debian ARM system. Let them deal with that complication. Not DDs.
If I'm not mistaken, Debian has a long history of serving the widest audience of users first and foremost, not those 3rd parties.
Cheers,
On 7/25/06,
Catalin Marinas <catalin.marinas@arm.com> wrote:
"Martin Guy" <martinwguy@gmail.com> wrote:
> So... is there a valid need for anyone to be able to include fragments
> of Thumb code in an otherwise wholly 32-bit Debian ARM system? A
> reason so pressing and of such widespread usefulness to outweigh the
> global disadvantages of including interworking?
Since you would call the port ARM EABI, I think it should be close to
what the EABI mandates. Otherwise people won't be able to run
pre-compiled third-party software (built with an EABI compiler). The
problem with this is that ARMv4(t) wouldn't be supported but there is
already a Debian ARM port which is pure 32bit.
Another reason would be to make life easier for people trying to
re-compile applications to Thumb on an ARM Debian machine. Without
interworking, they would have to use workarounds like scratchbox +
qemu (I'm not sure whether Qemu supports Thumb).
> Thumb emulation via illegal instruction traps? No, I'm only joking...
Not to entirely emulate Thumb but you could actually hack the kernel
to trap and dynamically replace the "BX LR" instruction with a "MOV
PC, LR" on ARMv4t. It would be a longer start-up time but will get
faster afterwards (this approach wouldn't work with XIP though).
--
Catalin
--
To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
Dustin Harriman
My Blog: http://ca.blog.360.yahoo.com/dustinharriman
RSS Feed: http://ca.blog.360.yahoo.com/rss-RkGSoVA1brWtXrVH9Gr5CzgVujwwGg--?cq=1
Reply to: