[U-Boot] [PATCH v4 00/19] sunxi: sync H3, H5, A64 DTs from mainline Linux

Mark Kettenis mark.kettenis at xs4all.nl
Mon Apr 2 19:06:47 UTC 2018


> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara at arm.com>
> Date: Mon, 2 Apr 2018 16:14:29 +0100
> 
> On 02/04/18 13:47, Mark Kettenis wrote:
> 
> Hi,
> 
> >> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= <andre.przywara at arm.com>
> >> Date: Mon, 2 Apr 2018 12:51:50 +0100
> >>
> >> On 02/04/18 12:20, Mark Kettenis wrote:
> >>
> >> ....
> >>
> >>>> This feature make U-Boot to have full Linux dts inside, Can't we
> >>>> implement automatic-boot-of-os distro to grab Linux dtb during
> >>>> commands stage like other distro does? Because this make few
> >>>> development struggles for U-Boot project like (few of the comments are
> >>>> repeated from previous mail, but I'm trying to group them all)
> >>>> - Unnecessary to maintain nodes which are not required for bootloader
> >>>> and which doesn't have proper dt drivers.
> >>>> - It becomes more patches for each-and-every sync.
> >>>> - We can compare the sync with Linux dt and simply apply on U-Boot
> >>>> which look not good to project growing.
> >>>> - Increase size(though it 10KB increase) it becomes unnecessary size
> >>>> from U-Boot point-of-view
> >>>
> >>> This is not just about booting Linux.  And even if it was, it means
> >>> that you can only boot on hardware for which a full device tree is
> >>> included in your distro.  So a new board that comes with a usable
> >>> U-Boot in SPI flash still won't work since the right device tree isn't
> >>> there.
> >>
> >> Ah right, I didn't even mention SPI flash in that thread. Thanks!
> >>
> >> Out of curiosity: what OS are you thinking about? Collecting trophies
> >> here ;-) I tried the FreeBSD-current installer the other day, and it
> >> worked pretty well.
> > 
> > OpenBSD.  ARMv8-wise, our support for Allwinner A64/H5 and Rockchip
> > RK3399 is pretty decent these days and Rockchip RK3328 is coming along
> > as well.
> 
> Ah, great! I didn't know that OpenBSD was that far.
> Do you know of anything missing in the DT or UEFI support from mainline
> U-Boot? I put firmware images on my Pine64 github repo[1] for A64 and H5
> boards, which are based on 2018.03 plus this series, if you want to give
> it a try.
> Trying to wrap my around INSTALL.arm64, but you might be faster ;-)
> Does 6.2 provide enough to work? Or shall I wait till the 15th?

6.3 was released today!  Defenitely try that instead of 6.2.

> >  And I'm working on Marvell 8040 support.  There is support
> > for ARMv7 as well which includes many of the older Allwinner SoCs.
> > We don't have the resources to build images for all the different
> > boards that are out there though, which probably is the biggest
> > stumbling block for getting OpenBSD to run.  Our bootloader is UEFI,
> 
> That sounds good!
> 
> > so with a recent enough U-Boot in flash the default install.fs image
> 
> Is that the FFS filesystem in the OpenBSD partition of miniroot.fs?
> Which just contains the bsd.rd kernel + RAM fs?
> The 6.2 directory didn't have an explicit install.fs image.

Hmm, I meant minirootXX.fs (which for 6.3 is called miniroot63.fs).

That is a disk image that can be dd'ed directly to the boot media,
i.e. a uSD card.  It has an MBR partition table, a partition with a
FAT filesystem that has the UEFI bootloader (and Raspberry Pi
firmware) and a partition with an OpenBSD disklabel and an FFS
filesystem that has the bsd.rd kernel that includes the RAM
filesystem.

You can simply overwrite the Pine64 firmware that is already on there
(in the space before the first partition) with your own firmware.  My
Pine64 board is dead, but I tried your firmware on my Orange Pi PC 2
and it works fine.

Mainline U-Boot works fine as well, but it works better if I stick an
updated Linux device tree on the FAT filesystem.  I believe that with
the current U-Boot device tree only one of the USB ports works.


More information about the U-Boot mailing list