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

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

[yoann padioleau]

[-- 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 --]

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

[erik quanstrom]

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

i think your source is out-of-sync:

         -f     (5l only) Generate VFP hardware floating-point
                 instructions.  Without this option, 5l generates
                 arm7500 floating-point instructions which are emu-
                 lated in the kernel.

i would imagine that your machine may have booted (the kernel does not use floating point),
but you can't see the screen.  if you set up a cpu server, there's a good chance it will be
accessable.

- erik

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

[yoann padioleau]

Without -f I was able to get something on the screen.
The code in libdraw and libmemdraw does not use floats.
But I was having weird failures in malloc.

I updated my kencc fork to the latest version
and now everything works!
The problem apparently was more related to 5c than 5l.
I updated 5l to support -f but I still had the problem.
After updating 5c then everything worked.


> On Jan 15, 2017, at 4:11 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 
>> 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/? 
> 
> i think your source is out-of-sync:
> 
>         -f     (5l only) Generate VFP hardware floating-point
>                 instructions.  Without this option, 5l generates
>                 arm7500 floating-point instructions which are emu-
>                 lated in the kernel.
> 
> i would imagine that your machine may have booted (the kernel does not use floating point),
> but you can't see the screen.  if you set up a cpu server, there's a good chance it will be
> accessable.
> 
> - erik