From mboxrd@z Thu Jan 1 00:00:00 1970 From: yoann padioleau Content-Type: multipart/alternative; boundary="Apple-Mail=_06566EBA-BA9A-4F84-B23C-D3DA48AD11CF" Message-Id: <98136872-0209-4836-B147-4926629CD573@gmail.com> Date: Fri, 13 Jan 2017 12:29:29 -0800 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: [9fans] fail to crosscompile Rasperry Pi Miller's kernel Topicbox-Message-UUID: b1afa742-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail=_06566EBA-BA9A-4F84-B23C-D3DA48AD11CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=3Dken-cc = now https://bitbucket.org/plan9-from-bell-labs/9-cc/ = (actually I use my own simplified fork: https://github.com/aryx/fork-kencc ) I am able to compile/link the default bcm/ kernel with this distribution: https://github.com/0intro/plan9/ = I am also able to compile/link the latest kernel from richard miller http://9p.io/magic/webls?dir=3D/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=E2=80=99t 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/?=20 Note that the 9pi image at = http://9p.io/magic/webls?dir=3D/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/ = from Jan 2015, so I guess the problem = has to be in kencc/. --Apple-Mail=_06566EBA-BA9A-4F84-B23C-D3DA48AD11CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=3Dken-cc
now
(actually I use my own simplified fork:
https://github.com/aryx/fork-kencc
)

I = am able to compile/link the default bcm/ kernel
with = this distribution: https://github.com/0intro/plan9/
I = am also able to compile/link the latest kernel from richard = miller




Note that the 9pi image at http://9p.io/magic/webls?dir=3D/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/ from Jan 2015, so I = guess the problem has to be in kencc/.







= --Apple-Mail=_06566EBA-BA9A-4F84-B23C-D3DA48AD11CF-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 15 Jan 2017 16:11:15 -0800 To: aryx.padator@gmail.com, 9fans@9fans.net Message-ID: <5f8906f3cd22fe88bbdd8fc8a29e1bd8@mule> In-Reply-To: <98136872-0209-4836-B147-4926629CD573@gmail.com> References: <98136872-0209-4836-B147-4926629CD573@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] fail to crosscompile Rasperry Pi Miller's kernel Topicbox-Message-UUID: b1cacacc-ead9-11e9-9d60-3106f5b1d025 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: yoann padioleau In-Reply-To: <5f8906f3cd22fe88bbdd8fc8a29e1bd8@mule> Date: Mon, 16 Jan 2017 12:58:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <98136872-0209-4836-B147-4926629CD573@gmail.com> <5f8906f3cd22fe88bbdd8fc8a29e1bd8@mule> To: erik quanstrom Cc: 9fans@9fans.net Subject: Re: [9fans] fail to crosscompile Rasperry Pi Miller's kernel Topicbox-Message-UUID: b1d2a36e-ead9-11e9-9d60-3106f5b1d025 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 = wrote: >=20 >> 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/?=20= >=20 > i think your source is out-of-sync: >=20 > -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. >=20 > 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. >=20 > - erik