OpenFirmware and Linux v5.0 on XO-1.75

[Lubomir Rintel]

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?

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

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

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

> and the
>   keyboard is unresponsive in the dracut shell.

Which exact kernel are you using? Keyboard is not expected to work
before rc6.

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


> 
> 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.
> 
> On Thu, Feb 21, 2019 at 11:54:15AM +0100, Lubomir Rintel wrote:
> > Hi,
> > 
> > for the past few days I've been looking into updating the XO-1.75
> > OpenFirmware so that it's good enough to boot mainline Linux.
> > 
> > It now looks usable enough: the essentials such as simple framebuffer,
> > keyboard, Wi-Fi or USB all seem to work.
> > 
> > The branch's pretty large; counting 60 commits at the moment. Get it
> > from:
> > 
> >   git pull https://github.com/lkundrak/openfirmware lr/olpc-xo175-1
> > 
> > It's not done or finished (see the TODOs in many commits). Some
> > bindings are not settled in Linux tree. Howerver I still think it may
> > be a good idea to share it early to get some feedback and identify bits
> > that obviously stink.
> > 
> > I've tested it with the latest Fedora kernel [1] build (yay!) and also
> > booted the latest OLPC OS release. When booting the latter, there were
> > no differencies in "find /sys/devices -type d |sort" output, so I
> > assume the drivers that would use the device tree (there probably
> > aren't many) bind just fine.
> > 
> > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1214041
> > 
> > I tried not to break other boards. olpc/4.0 still builds fine, but is
> > likely to end up with three clock nodes (/pmua, /apbc and /clocks).
> > olpc/3.0 was bitrotten before and I did not try doing x86 build, for
> > the most part I've been building natively on the XO-1.75.
> > 
> > For a x86_64 hosted build I needed to patch cforth. See [2]. The 
> > MitchBradley/cforth [1] master branch actually takes a similar
> > approach, but there the 1.75 support there seems severely bitrotten.
> > 
> > [2] https://github.com/lkundrak/cforth/commit/c88790fd32.patch
> > [3] https://github.com/MitchBradley/cforth
> > 
> > I didn't have the guts to actually flash and run the image built on
> > x86_64. I don't not seem to be able to program the spi flash by
> > attaching a soic8 clip to it, without unsoldering the chip and I don't
> > feel like doing that if I fuck things up.
> > 
> > At some point I'll hopefully follow up with something that could be
> > actually merged into the OpenFirmware, perhaps in a month or so. Until
> > then some more bindings may settle.
> > 
> > In particular, my hopes are that some of Armada DRM or EC may make it
> > into 5.1. Camera works, but needs some more love, perhaps 5.2.
> > 
> > Take care
> > Lubo
> >