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 (mockbu...@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/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel