[Letux-kernel] [OpenOCD-devel] [PATCH]: d86217d board: add Skytone Alpha 400

[Paul Boddie]

On Tuesday, 3 November 2020 23:08:31 CET Daniel Glöckner wrote:
> Hello Riccardo,
> 
> On Tue, Nov 03, 2020 at 08:52:07PM +0100, Riccardo Mottola wrote:
> > I still have my Letux 400 and it works, even the battery hold some
> > charge... possibly because I use it rarely, but still do test it
> > every month or so. Before the CI20 it was absolutely the only
> > MIPS-LE setup I had (who much I wish it would be BE).
> 
> you have a CI20? In http://openocd.zylin.com/4246 the question came
> up if the workarounds necessary for the JZ4730 are necessary also for
> later XBurst chips.

JTAG wizardry is rather beyond my expertise, but it may be the case that some 
workarounds have become unnecessary as the product range has evolved.

Although the JZ4780 in the CI20 is similar to the other products in the range, 
and there are various features of the architecture that are not supported 
quite as expected (thinking of various instruction variants that had to be 
emulated to get the Fiasco microkernel to work), I think the JZ4780 benefits 
from higher conformance to things like MIPS32r2, which might be expected since 
I think the product was developed after Ingenic acquired a MIPS licence. (I 
think the JZ4720 and JZ4730 indicate MIPS32r1 support in the appropriate 
configuration registers.)

So, it isn't inconceivable that conformance in other areas might have 
improved. But people would have to check, and the CI20 is at least more 
convenient to do this with than the Letux 400.

> > The cpu of the Letux400 is a bit hampered by the lack of the FPU
> > requiring a recompile - the original distribution from HongKong was
> > optimized for that and run fast - including a mini-Firefox and MP3
> > playback working, instead on Debian which requires hard-float and
> > emulation is used, performances are bad, you cannot even an audio
> > file.
> 
> Doesn't the Linux kernel emulate the fpu instructions?

Yes, the Algorithmics floating point emulator was merged long ago, and it even 
became mandatory long ago, apparently to prevent people from making the wrong 
choices by accident when configuring the kernel.

When I started playing with the Ben NanoNote, it became apparent to me that 
some media-related software would work a lot better with soft-float support, 
just to avoid the continual trapping to the kernel (dynamic recompilation 
might have been nice), but this ends up requiring soft-float toolchains and 
libraries. I think I looked at ways of cross-building packages (having found 
the Vorbis library that provided a soft-float decoder), but it was probably 
too much effort for me to figure it out at the time.

The Debian toolchains that are provided these days for MIPS all seem to be 
configured only for hard-float output, and so using Buildroot toolchains seems 
to be the way to go for soft-float output. I found this to actually be 
necessary when building Fiasco, and since I didn't get round to looking at 
floating point emulation in the L4 Runtime Environment (or much else with 
regard to the Letux 400 and NanoNote in this regard), it was also beneficial 
to build user-space programs with the soft-float toolchain, too.

> > Remembers me the day of 68k Macs and Amigas which had no FPU
> > ("embeded controller" or "low cost" CPUs...)
> 
> Before ARMv6 there were very few ARMs with fpu. The NXP LPC3250 is the
> only ARMv5 I know which has one. When I bought my Letux 400 we still
> had customers starting Linux projects on fpu-less ARMs.

My hands-on ARM experience is from the days of the ARM2 which only eventually 
got hardware floating point support for some machines from a WE32206 co-
processor board:

http://chrisacorns.computinghistory.org.uk/32bit_UpgradesA2G/
Acorn_AKA20_WE32206FPCoPro.html

Eventually, ARM3 users got the benefit of the "native" FPA10 co-processor:

http://chrisacorns.computinghistory.org.uk/32bit_UpgradesH2Z/
Simtec_ARM3FPA.html

Perhaps the first ARM with integrated floating point support, at least in some 
kind of volume, may have been the ARM7500FE:

http://chrisacorns.computinghistory.org.uk/Computers/A7000+.html

This is all ancient history now, but still fascinating!

Paul