Thanks, very good progress. Here's what I've done; - reviewed the aggregate change from master branch, and each commit,
- 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, - 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, and the keyboard is unresponsive in the dracut shell. 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. - 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 > -- James Cameron http://quozl.netrek.org/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel