GNU bug report logs - #31416
[PATCH 0/4] Generalize bootloader installer selection.

Previous Next

Full log

View this message in rfc822 format

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 31416 <at> debbugs.gnu.org
Subject: [bug#31416] [PATCH 3/4] bootloader: Add make-u-boot-bootloader.
Date: Sun, 17 Jun 2018 23:41:38 +0200

[Message part 1 (text/plain, inline)]

Hi,

On Sun, 17 Jun 2018 22:33:05 +0200
ludo <at> gnu.org (Ludovic Courtès) wrote:

> Instead of using these .cfg files as-is, how about “importing” them?
> That <soc> structure (or whatever) we discussed could contain
> essentially the relevant part of those .cfg files

Yeah

> (the partitioning info
> founds in those files seems less relevant to me

Yes.  Buildroot is a huge superset of what we actually need :).

> IOW, we could definitely take Buildroot as an inspiration (it’s probably
> one of the best tools in this area), but maybe not reuse the actual
> files.

The advantage if we reused the actual files is that we'd not have to maintain
it so much ourselves.

But if we use the <soc> solution, it's not actually that much work to maintain it.

I've extracted the list of socs using

  u-boot-2018.05$ grep -C 1 -r SYS_SOC . |grep default |awk '{print $3}' |sort |uniq |grep '"' >Q

and I got this list:

"ae250"
"ae3xx"
"ag101"
"am33xx"
"apq8016"
"apq8096"
"armada100"
"aspeed"
"at91"
"ath79"
"au1x00"
"baytrail"
"bcm235xx"
"bcm281xx"
"bcm283x"
"bcm3380"
"bcmcygnus"
"bcmnsp"
"braswell"
"broadwell"
"coreboot"
"davinci"
"efi"
"ep93xx"
"exynos"
"fsl-layerscape"
"hi3798cv200"
"hi6220"
"highbank"
"ivybridge"
"keystone"
"kirkwood"
"lpc32xx"
"ls102xa"
"meson"
"mvebu"
"mx25"
"mx27"
"mx31"
"mx35"
"mx5"
"mx6"
"mx7"
"mx7ulp"
"mx8m"
"mxs"
"ns2"
"omap3"
"omap4"
"omap5"
"orion5x"
"pic32mzda"
"qemu"
"quark"
"queensbay"
"rmobile"
"rockchip"
"s5pc1xx"
"snapdragon"
"socfpga"
"socfpga_arria10"
"spear"
"stih410"
"stm32mp"
"stv0991"
"sunxi"
"tangier"
"tegra114"
"tegra124"
"tegra186"
"tegra20"
"tegra210"
"tegra30"
"uniphier-v7"
"vf610"
"zynq"
"zynqmp"

Not that bad, eh?

Next would be to find those in buildroot, extract the relevant information from their genimage.cfg and unify them.
But that's a little involved.  A path would be:

(1) Extract possible SYS_SOC and SYS_VENDOR from all u-boot Kconfigs
(2) Find out which u-boot defconfigs would lead to those u-boot Kconfigs
(3) Find out which buildroot defconfigs would lead to those u-boot defconfigs
(4) Find out which buildroot board directory is used by each buildroot defconfig
(5) Extract the genimage.cfg from each such buildroot board directory
(6) Extract the u-boot installation specific parts from the genimage.cfg
(7) Unify the set of "genimage.cfg" parts for this SOC and make sure they are always the same

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.