OpenFirmware and Linux v5.0 on XO-1.75

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenFirmware and Linux v5.0 on XO-1.75

Lubomir Rintel
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

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

James Cameron-2
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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: 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
> >

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

James Cameron-2
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 ([hidden email]) (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
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

Lubomir Rintel
On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:

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

Makes sense. I think the self-test still works and none of the existing
funcitionality was broken deliberately.

[...]

I've given the thing some more testing and fixed up some of the
commits. I've also added an ext2fs fix that would be corrupting the
file systems with incompatible flags (the stock Fedora image), despite
being able to read it okay:

  git pull https://github.com/lkundrak/openfirmware lr/olpc-xo175-2

(diff it against lr/olpc-xo175-1 to see what changed)

> 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 ([hidden email]) (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.

Ah, okay. It might then just be that you don't have the olpc_apsp
module in the initrd. That might be the case especially with an older
dracut version and when running a kernel that has the APSP driver
built-in.

Some other drivers might be missing too. Here's one that's known to
have the necessary modules (generated on my f29 running a Fedora
kernel):

https://fedorapeople.org/~lkundrak/initramfs-5.0.0-0.rc7.git2.1.fc31.armv7hl.img

If things still don't work afterwards, please share the dmesg.
>
> > 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?

Not sure what you mean here.

Lubo

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

Lubomir Rintel
In reply to this post by James Cameron-2
On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:
[snip]

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

Figured out what's wrong. There's actually three drivers competing for
mrvl,pxa-uart, one of them deprecated the two other broken. This should
eventually be somehow disambiguated, but for now I just sent in the
fixes:

https://lore.kernel.org/lkml/20190224115802.13436-1-lkundrak@.../T/#u
https://lore.kernel.org/lkml/20190224115929.13548-1-lkundrak@.../T/#u
https://lore.kernel.org/lkml/20190224120053.13682-1-lkundrak@.../T/#u

Lubo

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

James Cameron-2
In reply to this post by Lubomir Rintel
On Sat, Feb 23, 2019 at 06:06:56PM +0100, Lubomir Rintel wrote:

> On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:
> > On Fri, Feb 22, 2019 at 12:14:00PM +0100, Lubomir Rintel wrote:
> > > 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?
>
> Not sure what you mean here.

Sorry.  Configuring and building kernels is for me a rare thing to do,
and whenever I try I'm usually interrupted by something more urgent,
as I've quite a few other things I've got to do.  I'm still a newbie
at it because I can't dedicate the time.

http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-4.8&id=4731695ff517ccb145e60d68acd2f7f15eb4ab6b
is an example patch which, in addition to a few irrelevant changes,
adds our OLPC RPM build process;

- our defconfig,

- a spec file for rpmbuild,

- a build script,

- an openfirmware boot script.

Some of this may have bit-rotted.

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

Lubomir Rintel
On Mon, 2019-02-25 at 20:00 +1100, James Cameron wrote:

> On Sat, Feb 23, 2019 at 06:06:56PM +0100, Lubomir Rintel wrote:
> > On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:
> > > On Fri, Feb 22, 2019 at 12:14:00PM +0100, Lubomir Rintel wrote:
> > > > 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?
> >
> > Not sure what you mean here.
>
> Sorry.  Configuring and building kernels is for me a rare thing to do,
> and whenever I try I'm usually interrupted by something more urgent,
> as I've quite a few other things I've got to do.  I'm still a newbie
> at it because I can't dedicate the time.
>
> http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-4.8&id=4731695ff517ccb145e60d68acd2f7f15eb4ab6b
> is an example patch which, in addition to a few irrelevant changes,
> adds our OLPC RPM build process;
>
> - our defconfig,
>
> - a spec file for rpmbuild,
>
> - a build script,
>
> - an openfirmware boot script.
>
> Some of this may have bit-rotted.

So, over the last week or so, I spent some effort making this work with
the OLPC RPM build tooling. Here's what I came up with:

http://v3.sk/~lkundrak/olpc/green_ears.jpeg

The kernel:

  git pull https://github.com/hackerspace/olpc-xo175-linux/ olpc-5.0

Based on vanilla v5.0.8, a few parts taken from olpc-4.8, olpc-3.0-arm,
along with my defconfig and a couple of changes to support cross-build
on Fedora 30. I've not tested native builds, I didn't dare to run it on
the XO.

Firmware:

  git pull https://github.com/lkundrak/openfirmware/ lr/olpc-xo175-3

A couple more small fixups here and there since lr/olpc-xo175-2. The
most notable fix is for a regression that caused the RTC to be cleared
on each boot.

  git pull https://github.com/lkundrak/dracut-modules-olpc/ master

There's a fix for assumptions about the mmc controller numbering. Also,
to boot a FDT-based kernel the initramfs needs to avoid triggering the
compat boot path (that lies about bootpath and disables the DT
flattening).

  git pull https://github.com/lkundrak/olpc-utils/ v5.0
  git pull https://github.com/lkundrak/olpc-utils/ master

Fixes the X11 video.

The patched packages are here: http://v3.sk/~lkundrak/olpc/
The dracut-modules-olpc package needs to be installed prior to the
kernel.

Lubo

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

James Cameron-2
On Fri, Apr 19, 2019 at 08:58:15AM +0200, Lubomir Rintel wrote:

> On Mon, 2019-02-25 at 20:00 +1100, James Cameron wrote:
> > On Sat, Feb 23, 2019 at 06:06:56PM +0100, Lubomir Rintel wrote:
> > > On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:
> > > > On Fri, Feb 22, 2019 at 12:14:00PM +0100, Lubomir Rintel wrote:
> > > > > 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?
> > >
> > > Not sure what you mean here.
> >
> > Sorry.  Configuring and building kernels is for me a rare thing to do,
> > and whenever I try I'm usually interrupted by something more urgent,
> > as I've quite a few other things I've got to do.  I'm still a newbie
> > at it because I can't dedicate the time.  [...]
>
> So, over the last week or so, I spent some effort making this work with
> the OLPC RPM build tooling. Here's what I came up with:
>
> http://v3.sk/~lkundrak/olpc/green_ears.jpeg

Thanks, that's fantastic.  I've mostly reproduced your work, and have
my build of your 5.0 kernel running on an XO-1.75 with an adjusted
Fedora 18 user space and a fixed root= argument.

> The kernel:
>
>   git pull https://github.com/hackerspace/olpc-xo175-linux/ olpc-5.0
>
> Based on vanilla v5.0.8, a few parts taken from olpc-4.8,
> olpc-3.0-arm, along with my defconfig and a couple of changes to
> support cross-build on Fedora 30. I've not tested native builds, I
> didn't dare to run it on the XO.

Pushed as http://dev.laptop.org/git/olpc-kernel/log/?h=olpc-5.0

My dmesg;
http://dev.laptop.org/~quozl/z/1hHiN5.txt

I used an Ubuntu 18.04 cross-build to make the kernel I'm using at the
moment, as our production builder is Fedora 18.  I've started to
iterate on a Fedora 30 builder, but I'm not sure I've got everything I
need.  Here's the packages I'm adding;

gcc-arm-linux-gnu binutils-arm-linux-gnu
rpm-build bison flex m4 make openssl-devel perl

> Firmware:
>
>   git pull https://github.com/lkundrak/openfirmware/ lr/olpc-xo175-3
>
> A couple more small fixups here and there since lr/olpc-xo175-2. The
> most notable fix is for a regression that caused the RTC to be cleared
> on each boot.

Pushed as
https://github.com/quozl/openfirmware/commits/lr/olpc-xo175-3

Released q4e00ja.rom from this as is;
http://dev.laptop.org/~quozl/q4e00ja.rom

Removed the dtcompat.fth fload and released q4e01ja.rom;
http://dev.laptop.org/~quozl/q4e01ja.rom

As the firmware will update on a standard system before the kernel
will boot, this seems an okay way to do it.  What do you think?

>   git pull https://github.com/lkundrak/dracut-modules-olpc/ master
>
> There's a fix for assumptions about the mmc controller
> numbering. Also, to boot a FDT-based kernel the initramfs needs to
> avoid triggering the compat boot path (that lies about bootpath and
> disables the DT flattening).

Thanks.  I'm yet to use this, but plan to.

>   git pull https://github.com/lkundrak/olpc-utils/ v5.0
>   git pull https://github.com/lkundrak/olpc-utils/ master
>
> Fixes the X11 video.

Thanks, yes, it does work, though I had to recreate the xorg.conf.d
symlink, not sure why.

Pushed as http://dev.laptop.org/git/projects/olpc-utils/log/?h=v5.1

Packaged as
http://dev.laptop.org/~quozl/olpc-utils-5.1.0-0.olpc.armv7hl.rpm
http://dev.laptop.org/~quozl/olpc-utils-5.1.0-0.olpc.src.rpm

> The patched packages are here: http://v3.sk/~lkundrak/olpc/
> The dracut-modules-olpc package needs to be installed prior to the
> kernel.

Oops, I should have read all this way before acting.  I got caught up
in code review.  Sorry.  I'll do another test using your binaries.

By the way, there's an interesting symptom on WiFi, a variable latency
on inbound ssh, also shows up as a latency staircase effect in
outbound "ping -n -i 0.200".

Also, power is not turned off on system halt.  I remember fixing that
once, so no biggie.

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

Lubomir Rintel
On Sat, 2019-04-20 at 18:08 +1000, James Cameron wrote:

> On Fri, Apr 19, 2019 at 08:58:15AM +0200, Lubomir Rintel wrote:
> > On Mon, 2019-02-25 at 20:00 +1100, James Cameron wrote:
> > > On Sat, Feb 23, 2019 at 06:06:56PM +0100, Lubomir Rintel wrote:
> > > > On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:
> > > > > On Fri, Feb 22, 2019 at 12:14:00PM +0100, Lubomir Rintel wrote:
> > > > > > 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?
> > > >
> > > > Not sure what you mean here.
> > >
> > > Sorry.  Configuring and building kernels is for me a rare thing to do,
> > > and whenever I try I'm usually interrupted by something more urgent,
> > > as I've quite a few other things I've got to do.  I'm still a newbie
> > > at it because I can't dedicate the time.  [...]
> >
> > So, over the last week or so, I spent some effort making this work with
> > the OLPC RPM build tooling. Here's what I came up with:
> >
> > http://v3.sk/~lkundrak/olpc/green_ears.jpeg
>
> Thanks, that's fantastic.  I've mostly reproduced your work, and have
> my build of your 5.0 kernel running on an XO-1.75 with an adjusted
> Fedora 18 user space and a fixed root= argument.

(regarding the root= argument, see also the stable mmc names patch
below)

>
> > The kernel:
> >
> >   git pull https://github.com/hackerspace/olpc-xo175-linux/ olpc-5.0
> >
> > Based on vanilla v5.0.8, a few parts taken from olpc-4.8,
> > olpc-3.0-arm, along with my defconfig and a couple of changes to
> > support cross-build on Fedora 30. I've not tested native builds, I
> > didn't dare to run it on the XO.
>
> Pushed as http://dev.laptop.org/git/olpc-kernel/log/?h=olpc-5.0
>
> My dmesg;
> http://dev.laptop.org/~quozl/z/1hHiN5.txt
>
> I used an Ubuntu 18.04 cross-build to make the kernel I'm using at the
> moment, as our production builder is Fedora 18.  I've started to
> iterate on a Fedora 30 builder, but I'm not sure I've got everything I
> need.  Here's the packages I'm adding;
>
> gcc-arm-linux-gnu binutils-arm-linux-gnu
> rpm-build bison flex m4 make openssl-devel perl

Sounds about right. In general I think it's the *-arm-linux-gnu cross-
toolchain packages + the RPM's BuildRequires.

> > Firmware:
> >
> >   git pull https://github.com/lkundrak/openfirmware/ lr/olpc-xo175-3
> >
> > A couple more small fixups here and there since lr/olpc-xo175-2. The
> > most notable fix is for a regression that caused the RTC to be cleared
> > on each boot.
>
> Pushed as
> https://github.com/quozl/openfirmware/commits/lr/olpc-xo175-3
>
> Released q4e00ja.rom from this as is;
> http://dev.laptop.org/~quozl/q4e00ja.rom
>
> Removed the dtcompat.fth fload and released q4e01ja.rom;
> http://dev.laptop.org/~quozl/q4e01ja.rom

This second image removes the ablity to boot the legacy OLPC OS kernel,
doesn't it?

> As the firmware will update on a standard system before the kernel
> will boot, this seems an okay way to do it.  What do you think?

Sounds all right.

> >   git pull https://github.com/lkundrak/dracut-modules-olpc/ master
> >
> > There's a fix for assumptions about the mmc controller
> > numbering. Also, to boot a FDT-based kernel the initramfs needs to
> > avoid triggering the compat boot path (that lies about bootpath and
> > disables the DT flattening).

By the way there's this patch we could use if we needed stable device
names:

https://lore.kernel.org/lkml/20190416133930.1819-1-lkundrak@.../

But as the OLPC OS' initrd already relies on incorrect numbering
(different from what OFW and presumably marvell uses) and the dtcompat
translates it to something yet more incorrect, this wouldn't really be
useful for compatibility. So if nobody picks up the patch, there's
probably not much point in pushing it forward.

> Thanks.  I'm yet to use this, but plan to.
>
> >   git pull https://github.com/lkundrak/olpc-utils/ v5.0
> >   git pull https://github.com/lkundrak/olpc-utils/ master
> >
> > Fixes the X11 video.
>
> Thanks, yes, it does work, though I had to recreate the xorg.conf.d
> symlink, not sure why.
>
> Pushed as http://dev.laptop.org/git/projects/olpc-utils/log/?h=v5.1
>
> Packaged as
> http://dev.laptop.org/~quozl/olpc-utils-5.1.0-0.olpc.armv7hl.rpm
> http://dev.laptop.org/~quozl/olpc-utils-5.1.0-0.olpc.src.rpm
>
> > The patched packages are here: http://v3.sk/~lkundrak/olpc/
> > The dracut-modules-olpc package needs to be installed prior to the
> > kernel.
>
> Oops, I should have read all this way before acting.  I got caught up
> in code review.  Sorry.  I'll do another test using your binaries.
>
> By the way, there's an interesting symptom on WiFi, a variable latency
> on inbound ssh, also shows up as a latency staircase effect in
> outbound "ping -n -i 0.200".

I have no idea why would this happen. I'll focus my attention on
getting the remaning drivers merged first and then look into the bugs.

> Also, power is not turned off on system halt.  I remember fixing that
> once, so no biggie.

That is because the EC driver is not yet in. It is probably ready to
merge at this point (went throught several rounds of reviews now), but
it sort of depends on platform/x86 parts of the battery branch.

However, the battery branch now landed in the power-supply tree and as
it's a standalone immutable branch in said tree, the x86 crowd can
merge it in and then the EC branch can follow.

Take care
Lubo

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

James Cameron-2
On Sun, Apr 21, 2019 at 12:02:56PM +0200, Lubomir Rintel wrote:

> On Sat, 2019-04-20 at 18:08 +1000, James Cameron wrote:
> > On Fri, Apr 19, 2019 at 08:58:15AM +0200, Lubomir Rintel wrote:
> > > On Mon, 2019-02-25 at 20:00 +1100, James Cameron wrote:
> > > > On Sat, Feb 23, 2019 at 06:06:56PM +0100, Lubomir Rintel wrote:
> > > > > On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:
> > > > > > On Fri, Feb 22, 2019 at 12:14:00PM +0100, Lubomir Rintel wrote:
> > > > > > > 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?
> > > > >
> > > > > Not sure what you mean here.
> > > >
> > > > Sorry.  Configuring and building kernels is for me a rare thing to do,
> > > > and whenever I try I'm usually interrupted by something more urgent,
> > > > as I've quite a few other things I've got to do.  I'm still a newbie
> > > > at it because I can't dedicate the time.  [...]
> > >
> > > So, over the last week or so, I spent some effort making this work with
> > > the OLPC RPM build tooling. Here's what I came up with:
> > >
> > > http://v3.sk/~lkundrak/olpc/green_ears.jpeg
> > > [...]
> > > Firmware:
> > >
> > >   git pull https://github.com/lkundrak/openfirmware/ lr/olpc-xo175-3
> > >
> > > A couple more small fixups here and there since lr/olpc-xo175-2. The
> > > most notable fix is for a regression that caused the RTC to be cleared
> > > on each boot.
> >
> > Pushed as
> > https://github.com/quozl/openfirmware/commits/lr/olpc-xo175-3
> >
> > Released q4e00ja.rom from this as is;
> > http://dev.laptop.org/~quozl/q4e00ja.rom
> >
> > Removed the dtcompat.fth fload and released q4e01ja.rom;
> > http://dev.laptop.org/~quozl/q4e01ja.rom
>
> This second image removes the ablity to boot the legacy OLPC OS kernel,
> doesn't it?

For secure boot, yes.  But you could still use root=.

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenFirmware and Linux v5.0 on XO-1.75

Lubomir Rintel
On Mon, 2019-04-22 at 06:10 +1000, James Cameron wrote:

> On Sun, Apr 21, 2019 at 12:02:56PM +0200, Lubomir Rintel wrote:
> > On Sat, 2019-04-20 at 18:08 +1000, James Cameron wrote:
> > > On Fri, Apr 19, 2019 at 08:58:15AM +0200, Lubomir Rintel wrote:
> > > > On Mon, 2019-02-25 at 20:00 +1100, James Cameron wrote:
> > > > > On Sat, Feb 23, 2019 at 06:06:56PM +0100, Lubomir Rintel wrote:
> > > > > > On Sat, 2019-02-23 at 10:52 +1100, James Cameron wrote:
> > > > > > > On Fri, Feb 22, 2019 at 12:14:00PM +0100, Lubomir Rintel wrote:
> > > > > > > > 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?
> > > > > >
> > > > > > Not sure what you mean here.
> > > > >
> > > > > Sorry.  Configuring and building kernels is for me a rare thing to do,
> > > > > and whenever I try I'm usually interrupted by something more urgent,
> > > > > as I've quite a few other things I've got to do.  I'm still a newbie
> > > > > at it because I can't dedicate the time.  [...]
> > > >
> > > > So, over the last week or so, I spent some effort making this work with
> > > > the OLPC RPM build tooling. Here's what I came up with:
> > > >
> > > > http://v3.sk/~lkundrak/olpc/green_ears.jpeg
> > > > [...]
> > > > Firmware:
> > > >
> > > >   git pull https://github.com/lkundrak/openfirmware/ lr/olpc-xo175-3
> > > >
> > > > A couple more small fixups here and there since lr/olpc-xo175-2. The
> > > > most notable fix is for a regression that caused the RTC to be cleared
> > > > on each boot.
> > >
> > > Pushed as
> > > https://github.com/quozl/openfirmware/commits/lr/olpc-xo175-3
> > >
> > > Released q4e00ja.rom from this as is;
> > > http://dev.laptop.org/~quozl/q4e00ja.rom
> > >
> > > Removed the dtcompat.fth fload and released q4e01ja.rom;
> > > http://dev.laptop.org/~quozl/q4e01ja.rom
> >
> > This second image removes the ablity to boot the legacy OLPC OS kernel,
> > doesn't it?
>
> For secure boot, yes.  But you could still use root=.

Hmmm, but it also turns on the DT flattening which is mutually
exclusive with ATAGs (because r2 points to either of them). I think the
legacy kernel wouldn't even be able to get any kernel command line
arguments (including root=) or memory size. I though the machine ID is
also different for BSP-based kernel than for the FDT-based.

That said, I haven't actually tested whether that is the case. If it
somehow works, but I can't see how (kernel using built-in arguments and
ignoring machine id? no idea).

Lubo

_______________________________________________
Devel mailing list
[hidden email]
http://lists.laptop.org/listinfo/devel