[9fans] fail to crosscompile Rasperry Pi Miller's kernel

[yoann padioleau <aryx.padator@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

Hi,

I am trying to compile the plan9 kernel for the Rasperry pi
from Richard Miller. I am using from MacOSX the kencc toolchain
https://code.google.com/hosting/moved?project=ken-cc <https://code.google.com/hosting/moved?project=ken-cc>
now
https://bitbucket.org/plan9-from-bell-labs/9-cc/ <https://bitbucket.org/plan9-from-bell-labs/9-cc/>
(actually I use my own simplified fork:
https://github.com/aryx/fork-kencc <https://github.com/aryx/fork-kencc>
)

I am able to compile/link the default bcm/ kernel
with this distribution: https://github.com/0intro/plan9/ <https://github.com/0intro/plan9/>
I am also able to compile/link the latest kernel from richard miller
http://9p.io/magic/webls?dir=/sources/contrib/miller/9/bcm <http://9p.io/magic/webls?dir=/sources/contrib/miller/9/bcm>

The problem is that when I boot it on my physical Raspberry Pi 1,
I just get a blue screen. I don’t get the Plan9 console greeting,
nothing.

The call to fbinit in bcm/vcore.c is working because
the memset in fbinit is working (hence the blue screen).
But calls following fbinit do not work. I tracked it down
to a call to malloc() in allocmemimage in libmemdraw.
In fact, if I do a call to malloc() in main.c before the call to
screeninit, nothing works (I get a gradient picture on the screen).

Does any of you have any idea what could be the cause of the problem? The linker 5l in kencc does not support the -f linking option, but I think none of the code in pool.c or libmemdraw use float/double at this point.
Is there some important patches to 5l or 5c I am missing in kencc/? 

Note that the 9pi image at http://9p.io/magic/webls?dir=/sources/contrib/miller <http://9p.io/magic/webls?dir=/sources/contrib/miller> is working on my Raspberry Pi. So this is not a problem in my Raspberry. I am also using the official plan9 distribution https://github.com/0intro/plan9/ <https://github.com/0intro/plan9/> from Jan 2015, so I guess the problem has to be in kencc/.








[-- Attachment #2: Type: text/html, Size: 3224 bytes --]