Linux next-20181204 on a XO-1.75
Hello. Good news: [lkundrak@xo ~]$ uname -a Linux xo.local 4.20.0-rc5-next-20181204 #4 PREEMPT Tue Dec 4 08:55:53 CET 2018 armv7l armv7l armv7l GNU/Linux As of next-20181204, linux-next (targetting v4.21 at this point) can successfully boot on a XO-1.75. That is thanks to the kindness of Linux maintainers who integrated fixes for booting the MMP2 platform with DT-based kernels and numerous developers who provided reviews and feedback dmesg (somewhat verbose because of CONFIG_DEBUG_DRIVER=y): https://people.freedesktop.org/~lkundrak/olpc/next-20181204/dmesg.txt While there are many more fixes currently in review to enable more hardware, with a good base tree it will be much easier to review the and try them out. Here's how (experience with building a kernel assumed): $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git $ cd linux-next $ wget -O .config https://people.freedesktop.org/~lkundrak/olpc/next-20181204/defconfig $ make ARCH=arm olddefconfig $ make ARCH=arm CROSS_COMPILE=arm-linux-gnu- $ Now you can copy the zImage to the SD card. In order to boot it some tweaks to the devicetree are necessary at this point. Copy dt.fth from https://people.freedesktop.org/~lkundrak/olpc/next-20181204/ to your /boot and fload it from the olpc.fth: " fload last:\boot\dt.fth" evaluate If you don't have a olpc.fth, you can grab mine from the same address along with the other *.fth scripts. They implement a simple boot menu with a countdown. Please note that I'm new to Forth and my style is probably somewhat sloppy and not a good example to someone who's also new to the language. What works: * UARTs, SD, USB, Accelerometer, RTC * GPIO keys: Sense for Audio Jacks and Lid switches * Screen, via simple-framebuffer Things that are known not working: * Keyboard. There's an irqchip patch in review that fixes the interrupt delivery to the SP. For now CONFIG_SERIO_OLPC_APSP needs to be disabled. * Camera and Embedded Controller support are not in yet. In review. * DRM. Work needed. Russel King posted patches that add necessary DT bindings to the Armada DRM. They require an encoder, but we don't seem to have one. Shall we create a fake one like drivers/gpu/drm/imx/parallel-display.c does, or is the HiMax DCON considered an encoder? I didn't ask Russell yet -- I'll do once I learn enough about DRM not to sound too stupid. * GPU. I have no idea how is the GPU clock hooked on in MMP2 clock tree. I didn't really ask anyone with a datasheet yet. Would Etnaviv just work with our GPU? I didn't try. * The dt.fth is missing support for the above probably gets things wrong on few places. It's a work-in-progress hack until OFW gets updated. * I didn't test Sound and Suspend/Resume at all. Love, Lubo - - - - - - - - - - - - - - - - 8< - - - - - - - - - - - - - - - - - I'm new to the list, so I guess it's appropriate to introduce myself: I'd eventually like to see a stock and up-to-date Fedora image boot on an OLPC XO-1.75, and that can't be done without a good mainline Linux support. This is essentially a hobby project. Despite I'm typically not considered to be a child anymore the computer is still a learning accessory for me. Perhaps in a few years my baby girl (two months old now) will be able to have fun with the laptop. I'm based in Brno, Czech Republic and work full-time on maintaining NetworkManager along with a few fellow hackers scattered across Europe. I waste my time riding bikes and doing drugs. I'm going to FOSDEM 2019, if anybody would like to meet. - - - - - - - - - - - - - - - - 8< - - - - - - - - - - - - - - - - - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Linux next-20181204 on a XO-1.75
Thanks. On my test unit, this change was needed; --- dt.fth.orig 2018-12-04 18:23:57.0 +1100 +++ dt.fth 2018-12-08 17:18:42.143073750 +1100 @@ -362,7 +362,7 @@ " /clocks" encode-phandle MMP2_CLK_TWSI5 encode-int encode+ " resets" property device-end -" dev /i2c@d4034000/accelerometer@1d" evaluate +" dev /i2c@d4034000/accelerometer@19" evaluate " st,lis3lv02d" +compatible " st,lis331dlh" +compatible device-end -- James Cameron http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Linux next-20181204 on a XO-1.75
On Sat, 2018-12-08 at 17:26 +1100, James Cameron wrote: > Thanks. On my test unit, this change was needed; > > --- dt.fth.orig 2018-12-04 18:23:57.0 +1100 > +++ dt.fth 2018-12-08 17:18:42.143073750 +1100 > @@ -362,7 +362,7 @@ > " /clocks" encode-phandle MMP2_CLK_TWSI5 encode-int encode+ " > resets" property > device-end > > -" dev /i2c@d4034000/accelerometer@1d" evaluate > +" dev /i2c@d4034000/accelerometer@19" evaluate > " st,lis3lv02d" +compatible > " st,lis331dlh" +compatible > device-end Thanks. I guess there's no need for the bus address there, " /i2c@d4034000/accelerometer" resolves to the correct node, regardless of what model/address the actual accelerometer is: https://people.freedesktop.org/~lkundrak/olpc/dt.fth ^ here's the current version I have. Includes camera and display. I hope I'll manage to follow up with the DRM patches later today. I'll very much appreciate if you take a look then as there are some bits I couldn't figure out without the panel and SoC manuals (and might be even wrong in OFW). There are probably bugs. I've observed some problems, such as an occasional "Data Abort" when the USB ethernet is not plugged in (?) that can be fixed by merely splitting the file into two and floading them separately. I guess I'm corrupting something somewhere, but I find figuring out precisely what is going on non-trivial. Also, the modifications to the internal sdhci node prevent OFW from booting from the internal emmc. That said, it still serves as a good reference for the changes that will need to be done to support mainline kernels once the bits settle. PS: The previous message didn't make it to the list as it seems to require moderation. I guess this one will neither, unless you approve it. Lubo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Linux next-20181204 on a XO-1.75
On Tue, Dec 18, 2018 at 11:39:19AM +0100, Lubomir Rintel wrote: > On Sat, 2018-12-08 at 17:26 +1100, James Cameron wrote: > > Thanks. On my test unit, this change was needed; > > > > --- dt.fth.orig 2018-12-04 18:23:57.0 +1100 > > +++ dt.fth 2018-12-08 17:18:42.143073750 +1100 > > @@ -362,7 +362,7 @@ > > " /clocks" encode-phandle MMP2_CLK_TWSI5 encode-int encode+ " > > resets" property > > device-end > > > > -" dev /i2c@d4034000/accelerometer@1d" evaluate > > +" dev /i2c@d4034000/accelerometer@19" evaluate > > " st,lis3lv02d" +compatible > > " st,lis331dlh" +compatible > > device-end > > Thanks. I guess there's no need for the bus address there, " > /i2c@d4034000/accelerometer" resolves to the correct node, regardless > of what model/address the actual accelerometer is: Yes. Chip is LIS33DE in older builds, and LIS3DHTR in newer builds. > https://people.freedesktop.org/~lkundrak/olpc/dt.fth > ^ here's the current version I have. Had a look, saw nothing obviously wrong. Am a bit worried about the amount of dictionary space remaining; you could reduce that worry by removing those constants and adding the names as comments later. Also you might check for data or control stack excursions; check balance of the stacks across the fload. > Includes camera and display. I hope I'll manage to follow up with the > DRM patches later today. I'll very much appreciate if you take a look > then as there are some bits I couldn't figure out without the panel and > SoC manuals (and might be even wrong in OFW). Ok. > There are probably bugs. I've observed some problems, such as an > occasional "Data Abort" when the USB ethernet is not plugged in (?) > that can be fixed by merely splitting the file into two and floading > them separately. I guess I'm corrupting something somewhere, but I find > figuring out precisely what is going on non-trivial. Yes, figuring out is non-trivial. We rarely made significant device tree changes at this stage, we try to bring them into the source. There is simultaneous activity going on (keyboard, USB), and it's not as multi-tasking as other environments. Use ftrace after the "Data Abort" to see if the saved exception stack can tell you anything interesting? > Also, the modifications to the internal sdhci node prevent OFW from > booting from the internal emmc. That said, it still serves as a good > reference for the changes that will need to be done to support mainline > kernels once the bits settle. Thanks. > PS: The previous message didn't make it to the list as it seems to > require moderation. I guess this one will neither, unless you approve > it. I've just now located and approved your subscription. As in the list info, we get a lot of bogus subscriptions for some reason. > Lubo > -- James Cameron http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
