[PATCH 0/6] orion/kw/mvebu: stability/usability patches

[PATCH 0/6] orion/kw/mvebu: stability/usability patches

[Michael Grzeschik]

While porting an older iomega iConnect machine to the latest version of
barebox, several shortcomings were identified. This patch series
addresses and resolves these issues.

Signed-off-by: Michael Grzeschik <grzeschik@puzzle.ch>
---
Michael Grzeschik (6):
      images: mvebu: skip images whose binary header is missing
      mtd: nand: orion: set Hamming ECC algorithm in ->attach_chip()
      gpio: orion: do not let banks without alias collide
      filetype: detect kwbimage v0 images for NAND boot
      mtd: nand: orion: register the NAND device as "nand"
      gpio: orion: register at coredevice level

 common/filetype.c                 |  9 +++++++--
 drivers/gpio/gpio-orion.c         | 18 +++++++++++++++---
 drivers/mtd/nand/raw/nand_orion.c | 22 ++++++++++++++++++++--
 images/Makefile.mvebu             | 23 ++++++++++++++++++-----
 4 files changed, 60 insertions(+), 12 deletions(-)
---
base-commit: 6a8b1f474121f10f9faeb59268b4ec63d1bd1be2
change-id: 20261103-orion_kw_mvebu-b746f8634963

Best regards,
--  
Michael Grzeschik <grzeschik@puzzle.ch>

[PATCH 1/6] images: mvebu: skip images whose binary header is missing

[Michael Grzeschik]

The Armada 370/XP/38x boards embed DDR training code from
arch/arm/boards/*/binary.0, which is not part of barebox. A missing file
stopped the whole build:

  No rule to make target 'arch/arm/boards/globalscale-mirabox/binary.0',
  needed by 'images/start_globalscale_mirabox.pblb.mvebu1img'.  Stop.

so mvebu_defconfig could not be built without the firmware for every
board, not even for boards that need none.

Use the missing firmware handling that the Rockchip images already use:
depend on the binary headers only if they exist, and if one is missing,
record it in <image>.missing-firmware and create an empty image. The
images step then reports the image as skipped, or fails the build with
CONFIG_MISSING_FIRMWARE_ERROR=y.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Michael Grzeschik <grzeschik@puzzle.ch>
---
 images/Makefile.mvebu | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/images/Makefile.mvebu b/images/Makefile.mvebu
index 7c918cb9f1..d4f2476aae 100644
--- a/images/Makefile.mvebu
+++ b/images/Makefile.mvebu
@@ -8,11 +8,24 @@
 $(obj)/%.kwbimg: $(obj)/% FORCE
 	$(call if_changed,kwb_image)
 
+# Binary headers (DDR training code, arch/arm/boards/*/binary.0) are not part
+# of barebox. If one is missing, report the image as missing firmware instead
+# of failing the build, so multi-board builds produce all other images. The
+# image is only skipped unless CONFIG_MISSING_FIRMWARE_ERROR=y.
+mvebu_missing_binhdr = $(filter-out $(wildcard $(BINHDR_$(@F))),$(BINHDR_$(@F)))
+
+define mvebu_binhdr_image
+	$(Q)$(if $(mvebu_missing_binhdr), \
+		echo $(patsubst $(srctree)/%,%,$(mvebu_missing_binhdr)) >$@.missing-firmware, \
+		rm -f $@.missing-firmware)
+	$(call if_changed,$(if $(mvebu_missing_binhdr),0size,$(1)))
+endef
+
 $(obj)/%.mvebu0img: $(obj)/% scripts/mvebuimg FORCE
-	$(call if_changed,mvebu0_image)
+	$(call mvebu_binhdr_image,mvebu0_image)
 
 $(obj)/%.mvebu1img: $(obj)/% scripts/mvebuimg FORCE
-	$(call if_changed,mvebu1_image)
+	$(call mvebu_binhdr_image,mvebu1_image)
 
 KWBOPTS = -c -d 0x1000000 -e 0x1000000
 
@@ -127,6 +140,6 @@ pblb-$(CONFIG_MACH_USI_TOPKICK) += start_usi_topkick
 image-$(CONFIG_MACH_USI_TOPKICK) += barebox-usi-topkick.img
 image-$(CONFIG_MACH_USI_TOPKICK) += barebox-usi-topkick-2nd.img
 
-# ensure that an image depends on its included binhdrs
-$(foreach f,$(pblb-y),$(eval $$(obj)/$f.pblb.mvebu0img: $$(BINHDR_$f.pblb.mvebu0img)))
-$(foreach f,$(pblb-y),$(eval $$(obj)/$f.pblb.mvebu1img: $$(BINHDR_$f.pblb.mvebu1img)))
+# ensure that an image depends on its included binhdrs, as far as they exist
+$(foreach f,$(pblb-y),$(eval $$(obj)/$f.pblb.mvebu0img: $$(wildcard $$(BINHDR_$f.pblb.mvebu0img))))
+$(foreach f,$(pblb-y),$(eval $$(obj)/$f.pblb.mvebu1img: $$(wildcard $$(BINHDR_$f.pblb.mvebu1img))))

-- 
2.53.0

[PATCH 2/6] mtd: nand: orion: set Hamming ECC algorithm in ->attach_chip()

[Michael Grzeschik]

The driver selects software Hamming ECC before nand_scan(), but
rawnand_dt_init() unconditionally overwrites chip->ecc.algo with the
device tree setting. None of the Kirkwood device trees has an ECC
property, so the algorithm ends up as NAND_ECC_ALGO_UNKNOWN and probing
fails:

  WARNING: at drivers/mtd/nand/raw/nand_base.c:5783/nand_set_ecc_soft_ops()!
  WARNING: Unsupported ECC algorithm!

leaving all boards with an orion NAND controller without NAND.

Do the same as the Linux orion_nand driver: keep the software engine as
default before scanning, and pick the Hamming algorithm in
->attach_chip(), which runs after the device tree has been parsed, if
neither the device tree nor anything else chose one.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Michael Grzeschik <grzeschik@puzzle.ch>
---
 drivers/mtd/nand/raw/nand_orion.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/nand_orion.c b/drivers/mtd/nand/raw/nand_orion.c
index c7fa4a08e9..68797b9b38 100644
--- a/drivers/mtd/nand/raw/nand_orion.c
+++ b/drivers/mtd/nand/raw/nand_orion.c
@@ -73,6 +73,19 @@ static void orion_nand_read_buf(struct nand_chip *chip, uint8_t *buf, int len)
 		buf[i++] = readb(io_base);
 }
 
+static int orion_nand_attach_chip(struct nand_chip *chip)
+{
+	if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT &&
+	    chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN)
+		chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
+
+	return 0;
+}
+
+static const struct nand_controller_ops orion_nand_controller_ops = {
+	.attach_chip = orion_nand_attach_chip,
+};
+
 static int orion_nand_probe(struct device *dev)
 {
 	struct resource *iores;
@@ -117,8 +130,13 @@ static int orion_nand_probe(struct device *dev)
 	chip->legacy.IO_ADDR_R = chip->legacy.IO_ADDR_W = io_base;
 	chip->legacy.cmd_ctrl = orion_nand_cmd_ctrl;
 	chip->legacy.read_buf = orion_nand_read_buf;
+	/*
+	 * The default ECC engine is software. The algorithm is set in
+	 * ->attach_chip(), after rawnand_dt_init() has overwritten it with the
+	 * (usually absent) device tree setting.
+	 */
 	chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
-	chip->ecc.algo = NAND_ECC_ALGO_HAMMING;
+	chip->legacy.dummy_controller.ops = &orion_nand_controller_ops;
 
 	WARN(width > 16, "%d bit bus width out of range", width);
 	if (width == 16)

-- 
2.53.0

[PATCH 3/6] gpio: orion: do not let banks without alias collide

[Michael Grzeschik]

The driver uses the "gpio" alias index to place a bank in the global
GPIO number space and leaves the base at 0 when there is no alias. The
Kirkwood device trees have no gpio aliases, so both banks were
registered at base 0. gpiochip_add() then rejected the second bank with
-EBUSY, which the driver ignored, so every user of gpio1 deferred
forever:

  gpio-leds gpio-leds.of: error Requested probe deferral: getting gpio for /gpio-leds/led-level
  gpio_keys gpio_keys.of: error Requested probe deferral: requesting gpio #0

Let gpiolib choose the base when there is no alias, and fail the probe
with an error message if the chip cannot be registered.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Michael Grzeschik <grzeschik@puzzle.ch>
---
 drivers/gpio/gpio-orion.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-orion.c b/drivers/gpio/gpio-orion.c
index ef7d1ff114..994ba1926e 100644
--- a/drivers/gpio/gpio-orion.c
+++ b/drivers/gpio/gpio-orion.c
@@ -83,7 +83,7 @@ static int orion_gpio_probe(struct device *dev)
 {
 	struct resource *iores;
 	struct orion_gpio_chip *gpio;
-	int id;
+	int id, ret;
 
 	gpio = xzalloc(sizeof(*gpio));
 	iores = dev_request_mem_resource(dev, 0);
@@ -95,14 +95,26 @@ static int orion_gpio_probe(struct device *dev)
 	gpio->chip.dev = dev;
 	gpio->chip.ops = &orion_gpio_ops;
 
+	/*
+	 * Without a gpio alias, let gpiolib pick the base. Defaulting to 0
+	 * made the second bank of Kirkwood SoCs collide with the first one.
+	 */
 	id = of_alias_get_id(dev->of_node, "gpio");
 	if (id >= 0)
 		gpio->chip.base = id * 32;
+	else
+		gpio->chip.base = -1;
 
 	gpio->chip.ngpio = 32;
 	of_property_read_u32(dev->of_node, "ngpios", &gpio->chip.ngpio);
 
-	gpiochip_add(&gpio->chip);
+	ret = gpiochip_add(&gpio->chip);
+	if (ret) {
+		dev_err(dev, "failed to register gpio chip: %pe\n", ERR_PTR(ret));
+		release_region(iores);
+		free(gpio);
+		return ret;
+	}
 
 	dev_dbg(dev, "probed gpio%d with base %d\n", dev->id, gpio->chip.base);
 

-- 
2.53.0

[PATCH 4/6] filetype: detect kwbimage v0 images for NAND boot

[Michael Grzeschik]

The kwbimage detection requires header bytes 0x1-0x3 to be zero before
it looks at the header version. That is right for v1 headers, where
they are reserved, but in v0 headers byte 0x1 is the NAND ECC mode and
bytes 0x2-0x3 are the NAND page size. Every v0 image for NAND boot, as
used on Kirkwood, was therefore reported as unknown, and the mvebu
barebox_update handler refused it:

  ERROR: /barebox-ram.img is not a valid kwbimage
  update failed

Check these bytes for v1 headers only. v0 detection still requires a
valid header checksum.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Michael Grzeschik <grzeschik@puzzle.ch>
---
 common/filetype.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/common/filetype.c b/common/filetype.c
index a25be6e2fc..c5bed9eca9 100644
--- a/common/filetype.c
+++ b/common/filetype.c
@@ -406,9 +406,13 @@ enum filetype file_detect_type(const void *_buf, size_t bufsize)
 
 	if ((buf8[0] == 0x5a || buf8[0] == 0x69 || buf8[0] == 0x78 ||
 	     buf8[0] == 0x8b || buf8[0] == 0x9c) &&
-	    buf8[0x1] == 0 && buf8[0x2] == 0 && buf8[0x3] == 0 &&
 	    buf8[0x18] == 0 && buf8[0x1b] == 0 && buf8[0x1c] == 0) {
 
+		/*
+		 * In v0 headers byte 0x1 is the NAND ECC mode and bytes
+		 * 0x2-0x3 the NAND page size, both non-zero for NAND images.
+		 * Only v1 headers have them reserved.
+		 */
 		if (buf8[0x8] == 0) {
 			unsigned char sum = 0;
 			int i;
@@ -420,7 +424,8 @@ enum filetype file_detect_type(const void *_buf, size_t bufsize)
 			    fuzz_insecure_checksum_accepted(sum, buf8[0x1f]))
 				return filetype_kwbimage_v0;
 		} else if (buf8[0x8] == 1) {
-			if (buf8[0x1d] == 0 &&
+			if (buf8[0x1] == 0 && buf8[0x2] == 0 && buf8[0x3] == 0 &&
+			    buf8[0x1d] == 0 &&
 			    (buf8[0x1e] == 0 || buf8[0x1e] == 1))
 				return filetype_kwbimage_v1;
 		}

-- 
2.53.0

[PATCH 5/6] mtd: nand: orion: register the NAND device as "nand"

[Michael Grzeschik]

All other raw NAND drivers register their device as "nand", so the
flash shows up as /dev/nand0 with partitions like /dev/nand0.barebox.
The orion driver used "orion_nand", giving /dev/orion_nand0 and
/dev/orion_nand0.barebox, so board code, environments and documentation
written for the common name did not find the device:

  update barebox on /dev/nand0.barebox.bb from /barebox-ram.img using handler nand.
  update failed
  barebox_update: No such file or directory

Use the common name. Nothing in barebox refers to the old one.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Michael Grzeschik <grzeschik@puzzle.ch>
---
 drivers/mtd/nand/raw/nand_orion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/nand_orion.c b/drivers/mtd/nand/raw/nand_orion.c
index 68797b9b38..eb58cba399 100644
--- a/drivers/mtd/nand/raw/nand_orion.c
+++ b/drivers/mtd/nand/raw/nand_orion.c
@@ -152,7 +152,7 @@ static int orion_nand_probe(struct device *dev)
 		goto no_dev;
 	}
 
-	add_mtd_nand_device(mtd, "orion_nand");
+	add_mtd_nand_device(mtd, "nand");
 	return 0;
 no_dev:
 	if (!IS_ERR(clk))

-- 
2.53.0

[PATCH 6/6] gpio: orion: register at coredevice level

[Michael Grzeschik]

On boards without deep probe, all devices are created at core_initcall
and each driver probes its devices when it registers. The orion GPIO
driver registered at device level, like its consumers, and drivers/led
and drivers/input are linked before drivers/gpio, so gpio-leds and
gpio-keys were always probed before the GPIO controllers existed:

  gpio-leds gpio-leds.of: error Requested probe deferral: getting gpio for /gpio-leds/led-level
  gpio_keys gpio_keys.of: error Requested probe deferral: requesting gpio #0

They succeeded on the deferred retry, but the messages look like errors
with a debug log level. Register at coredevice level like most other GPIO
controller drivers, so the controllers are there before their users.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Michael Grzeschik <grzeschik@puzzle.ch>
---
 drivers/gpio/gpio-orion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-orion.c b/drivers/gpio/gpio-orion.c
index 994ba1926e..7d9fd33312 100644
--- a/drivers/gpio/gpio-orion.c
+++ b/drivers/gpio/gpio-orion.c
@@ -132,4 +132,4 @@ static struct driver orion_gpio_driver = {
 	.probe = orion_gpio_probe,
 	.of_compatible = DRV_OF_COMPAT(orion_gpio_dt_ids),
 };
-device_platform_driver(orion_gpio_driver);
+coredevice_platform_driver(orion_gpio_driver);

-- 
2.53.0