Custom resin-init-flasher

General
1

Hello everyone,

We are in the verge of integrating our own board with BalenaOS.
Currently we are able to produce an BalenaOS image that runs from the SD ( balena-image ). The next step I want to achieve is the image that runs from internal memory.
My board has a special memory architecture which need to boot from a NAND and then jumps to eMMC. Our main processor is not capable of booting from internal eMMC.

Which would be the best method to add a custom step in the resin-init-flasher process that would flash the bootloader to the NAND?
Adding a custom service doing that?
Via resin-init-flasher.bbapend recipe?

any ideas will be much appreciated!

Thanks a lot

2

Hi Alvaro, there are a couple of hooks called from the flasher script that allow for device specific customizations:

These are called from:

4

Thanks Alex!

I have tinkered with that hook and been able to create a resin-init-flasher image!

The flashing process works smoothly but I’ve come to another issue.
As said our system must boot from a NAND flash and then can jump to internal eMMC. In order to achieve this we crafted a custom uboot that is flashed into the NAND by “resin-init-flasher-board”.
The booting sequence is then performed like this:

  1. U-boot-spl ( NAND ) loaded&run
  2. U-boot ( NAND ) loaded&run
  3. Balena U-boot (eMMC) loaded&run
  4. Balena Kernel+rootfs loaded&run

Given that the Balena-u-boot is stored at the eMMC I would expect that it stores its envvars also at the eMMC but the problem is that it stores them in the NAND!
From the linux POV there seems to be no problem, as fw_printenv&setenev works well reading and writing uboot envvars, but this setup seems to be a little strange.
I am not sure this is a well formed solution but I´m afraid I don’t know how to force the balena-u-boot to store the envvars in the eMMC.

Any ideas on why this could be happening?

Thanks in advance!

5

Hello again Alex,

I finally nailed it but took me some mining into the U-boot code itself and a couple of patches more. Now we got full uboot chain from NAND to eMMC with proper uboot envvars saving.
Still some points to sharpen with our image but in a good path to make it happen.

Thanks!

8

Hi Alvaro, the location if the uboot environment is defined at compile time as a configuration variable CONFIG_ENV_IS_IN_*. This is generally set by the vendor on the default u-boot configuration file (see configs - uboot-imx - i.MX U-Boot).

The Yocto build system usingn the UBOOT_CONFIG variable to specify what configuration file to use and this is generally specified as part of the machine configuration.

I hope the above allows you to locate the configuration and check how u-boot is being configured.