Charon doesn't start on the Open Pandora (GNU/Linux ARMv7) port

[Samuel VISCAPI]

Dear Charles,

I have compiled Inferno OS on the Open Pandora, a gaming handheld machine running GNU/Linux ARMv7.

• Release thread:

https://pyra-handheld.com/boards/threads/inferno-operating-system.78360/

• Package on the official repository:

http://repo.openpandora.org/?page=detail&app=inferno-magicsam

Everything seems to be working correctly, except Charon, which doesn't want to start at all...

A "ps" after a failed attempt at starting the browser shows "Img" in the list of running processes (albeit in release state (I don't know what that means)).

There's already a thread opened at Google groups regarding this issue, with a screenshot:

https://groups.google.com/forum/#!topic/inferno-os/lwWiebTRmMA

I recompiled the whole thing with the following flags (to take care of potential floating point issues), but to no avail: Charon still doesn't start.

"export CFLAGS="-Ofast -pipe -mcpu=cortex-a8 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -fsingle-precision-constant -fdiagnostics-color=auto -fuse-ld=gold -fuse-linker-plugin -fsigned-char -mneon-for-64bits -mvectorize-with-neon-double""

Could you please have a look at it ?

Best regards,

Samuel a.k.a "Magic Sam" from the Open Pandora community

[Charles Forsyth]

I've suddenly realised what it is. Comment out the two lines in charon's mkfile starting with the one labelled img.dis. The mk clean, mk -i install in /appl/charon

The -c option is forcing the use of JIT for Img, and the JIT by no means supports NEON fp (and the fp it does support will have no support in hardware or on Linux).

[Samuel VISCAPI]

Hi Charles,

Thanks for having a look at this issue, it's really appreciated :)

I've updated the sources, edited the mkfile in appl/charon and I'm currently recompiling everything.

Starting "emu" with the "-c1" parameter makes Inferno crash immediately on the Pandora. Is it related ?

Cheers, Samuel

[Samuel VISCAPI]

Hi again,

It didn't work :( Charon still fails to start (while still bumping CPU usage to 100%...).

I commented out (with "#") the two following lines in /appl/charon/mkfile:

img.dis: img.b $MODULE $SYS_MODULE

limbo $LIMBOFLAGS -c -gw img.b

Then I did:

hg pull -uv

./makemk.sh | tee makemk.log

export PATH="/mnt/utmp/inferno-magicsam/inferno/Linux/arm/bin:$PATH"

mk nuke | tee mknuke.log

mk install | tee mkinstall.log

What am I doing wrong ?

Cheers, Samuel

[Charles Forsyth]

Try running emu -s ... to see if it's looping catching a signal.

[Samuel VISCAPI]

I'm already using emu -s:

emu -s -S -g 800x424 -C m8 /dis/wm/wm.dis wm/logon

If there are any logs, where should they be ?

Cheers, Samuel

[Charles Forsyth]

Normally traps etc would be printed in the usual way by the system or shell in the terminal window in which emu was started

When building emu, in the emu config file's "code" section, include the line code int dontcompile = 1;

to make absolutely certain that nothing is using the JIT (even if it has been compiled -c).

Finally, you might need to compile emu with the -g option in the emu mkfile, and then point a debugger such as gdb at it, to see where it's looping. Unfortunately, it's a bit hard to diagnose problems on hardware I haven't got, although some of what you describe might be reproducible on a Rpi.

[Samuel VISCAPI]

Could you please give me the full paths to the files you are referring to ?

I think the emu mkfile is inferno/emu/mkfile, but I have a doubt regarding the emu config file.

Cheers, Samuel

[Charles Forsyth]

No, the emu mkfile for (say) a Linux port will be inferno/emu/Linux/mkfile and the config file will be inferno/emu/Linux/emu.

[Samuel VISCAPI]

Hi Charles,

Thanks for the paths. Regarding the mkfile, is it inferno/emu/Linux/mkfile or inferno/emu/Linux/mkfile-arm (in my case) ?

Cheers, Samuel

[Samuel VISCAPI]

Nevermind, it's inferno/emu/Linux/mkfile.

Cheers, Samuel

[Samuel VISCAPI]

mk nuke failed with the following message (IIRC):

cd Linux mkfile, error line 40, expected line of file <: (or something similar) Return code: 1

Let's hope this won't have huge side effects on the ongoing compilation.

Cheers, Samuel

[Samuel VISCAPI]

OK, botched the mkfile, I solved the formatting issues, nuked everything again, and restarted the compilation.

Cheers, Samuel

[Samuel VISCAPI]

It works :)

Thank you very much Charles for your help !

Cheers, Samuel

[Samuel VISCAPI]

"int dontcompile = 1;" in the code section of inferno/emu/Linux/emu did the trick.

Thanks again for your help, it's REALLY appreciated !

Best, Samuel

[Charles Forsyth]

The underlying bug is that the floating-point ops generated by the ARM JIT were for the hardware FP in the box at the time, which is also supported by the native Inferno fp emulation. I think there was only ever one implementation of that old ARM FP as the 7500FPE. Subsequently, ARM changed the floating-point completely, including introducing vector modes, but the JIT has not been updated, although it probably isn't too hard for the basic operations and calling sequence it uses. The software emulation for the new hardware has been done for Plan 9, so that's not a problem.

[Samuel VISCAPI]

Hi Charles,

Is it something your're planning to work on ? If I could be of any help, please let me know, I'd be glad to give you a hand (with tests and such) :)

Cheers, Samuel

P.S: would an access to my Pandora (Cortex-A8 with NEON instructions) through Styx be of any use to you ?