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

Create issue
Issue #344 resolved
Samuel VISCAPI created an issue

Dear Charles,

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

  • Release thread:

  • Package on the official repository:

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:!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

Comments (16)

  1. 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).

  2. Samuel VISCAPI reporter

    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

  3. Samuel VISCAPI reporter

    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

    ./ | 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

  4. Samuel VISCAPI reporter

    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

  5. 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.

  6. Samuel VISCAPI reporter

    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

  7. 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.

  8. Samuel VISCAPI reporter

    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

  9. Samuel VISCAPI reporter

    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

  10. Samuel VISCAPI reporter

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

    Cheers, Samuel

  11. Samuel VISCAPI reporter

    "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

  12. 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.

  13. Samuel VISCAPI reporter

    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 ?

  14. Log in to comment