OpenFirmware and Linux v5.0 on XO-1.75

[James Cameron]

On Fri, Feb 22, 2019 at 12:14:00PM +0100, Lubomir Rintel wrote:
> On Fri, 2019-02-22 at 17:23 +1100, James Cameron wrote:
> > Thanks, very good progress.  Here's what I've done;
> > 
> > - reviewed the aggregate change from master branch, and each commit,
> 
> Does it look, eh, reasonable? Got any comments/suggestions?

Yes, it looks reasonable.  Given that the firmware would not need to
run in factory and would only be used with a new kernel, the rest of
the firmware functions won't need to be considered.  I'm not worried
if it breaks the self-test features, for example.

> > - built the firmware on my xo-4 build server, flashed an xo-1.75 c2
> >   sku200x2; it boots fine the old kernel from arm-3.0-wip branch, with
> >   some unimportant problems like keymapping,
> 
> I intend to look into the key mapping at some point, because I've
> noticed the keyboard sometimes sends scancodes the kernel doesn't
> recognize.
> 
> By the way, my unit has has the "olpcm" non-membrane keyboard. I'm
> wondering if the scan codes it sends are the same as the membrane
> one?

I can't remember, sorry.

> Will the key mapping in hwdb need to distinguish between the two? (I
> also have a membrane keyboard, so I could actually just check that
> myself...)
> 
> > - on the fedora 18 root filesystem, installed the 5.0.0
> >   kernel{-core,-modules,} with --nodeps and --force,
> > 
> > - adjusted boot/ so that olpc.fth runs the 5.0.0 kernel,
> > 
> > - booted it a few times trying to fix the missing root filesystem;
> >   more work needed, the device name may have changed and i've not
> >   found a way to find what it is, or it isn't being detected; serial
> >   console doesn't work even with console=ttyS2,115200
> 
> Yeah, the device names are not stable for some reason. I don't know how
> are they determined, I'll need to take a look. Perhaps it's just a
> matter of adding the right aliases to the device tree.
> 
> Somewhat wierdly, my stripped down monolithic kernel calls the UART2
> ttyS2, while the Fedora kernel ends up with ttyS0.

Thanks, switching to ttyS0 worked.

> Similar issue with the MMC; the SD card ends up mmcblk1 with one
> kernel, mmcblk0 with another.

No MMC detects.

> The actual boot parameters I am testing with are in the lower half of
> my boot script (it's somewhat messy, copied it directly from my /boot
> without an attempt to tidy it up):
> https://people.freedesktop.org/~lkundrak/lr-olpc-boot/boot/menu.fth

Thanks.

> > and the
> >   keyboard is unresponsive in the dracut shell.
> 
> Which exact kernel are you using? Keyboard is not expected to work
> before rc6.

[    0.000000] Linux version 5.0.0-0.rc7.git2.1.fc31.armv7hl (mockbuild at buildvm-armv7-08.arm.fedoraproject.org) (gcc version 9.0.1 20190209 (Red Hat 9.0.1-0.4) (GCC)) #1 SMP Wed Feb 20 21:06:49 UTC 2019

You pointed to it.

> Also, which config? Mine is basically this:
> https://raw.githubusercontent.com/hackerspace/olpc-xo175-linux/lr/olpc-xo175/arch/arm/configs/olpc_xo175_defconfig

The config used by Fedora.

Can we work toward some kind of reproducible build?

> > My mind has bitrotted.
> > 
> > On your interest in building on x86_64, suggestions;
> > 
> > - there are six 0.1" pitch pads on the back of the PCB which expose
> >   the SPI Flash chip pins, so you can hook a programmer to them, but
> >   check the voltage levels; some units used 1.8V chips, most used
> >   3.3V.
> 
> Ah, cool. Good to know there's a reasonable recovery option. Hope my
> chip is 3.3V, because I dropped the programmer that could do 1.8V on
> the floor and it seems it needs repairs :) 3.3V one could be programmed
> with a Rasbperry Pi, and I even have some spare 3.3V chips if I fuck up
> majorly.
> 
> But for now I just stay off overwriting cforth because I don't even
> feel like opening the machine again.
> 
> > - build a composite image by hand using the cforth you know already
> >   works, and the openfirmware built on x86_64,
> > 
> > - use binary comparison of the .rom file to make sure the cforth
> >   section hasn't changed much; if it hasn't, probably good to go, but
> >   if it has, no idea.
> > [...]

-- 
James Cameron
http://quozl.netrek.org/