Hi! I’m learning how the Balena customer board supports works (Customer Board Support | balena) so my employer can integrate with a custom Jetson carrier board.
Balena has already connected us with a contractor who will provide official integration, so right now I’m just prototyping & learning.
Our board uses a jetson orin nano. I’ve been walking through balena-jetson-orin and jetson-flash.
Most steps seem clear, but one recipe layers/meta-balena-jetson/recipes-bsp/tegra-binaries/tegra-flash-dry_36.3.0.bb is copying a boot blob, UEFI capsule, and partition specification.
I was able to generate a UEFI capsule using NVidia’s instructions, but the boot0.img files are opaque.
Where do these artifacts come from for the jetson orin?
I’m particularly interested in how this PR was accomplished:
Our board does not have EEPROM, so we need to make a change to set cvb_eeprom_read_size = <0x0> which seems to be baked into the boot partition somewhere.
Hi @cdalke-havoc , the boot0 image is actually taken from a Orin Nano Devkit which has been flashed using the standard Jetpack BSP archive, after first applying these changes listed below. You can extract it using dd if=/dev/mtd0 of=/tmp/boot0.img right after it has been written in rcm-boot mode by the BSP’s kernel_flash scripts.
Depending on your carrier board, you may want to also edit other board configuration files, i.e for pinmux changes in the QSPI, before creating the boot0 image or the UEFI capsule. You will also want to delete the reboot command from the initramdisk while the QSPI is being provisioned, so it does not reset right after it finished writing the QSPI in rcm-boot mode.
Great, and to make sure I understand, is this process of “applying these changes listed below” something that you are performing manually or is it expected that part of the yocto build will produce what you need?
I attempted to follow your process by applying these patches manually and was able to get to a bootable image on our carrier board and extracted a boot0.img based on your instructions. Once I used the image, however, the boot failed after flashing to the NVMe:
[0000.481] E> BL_CARVEOUT: Failed to allocate memory of size 0x4000000 for CO:43.
[0000.488] C> Task 0x20 failed (err: 0x49490403)
[0000.493] E> Top caller module: BL_CARVEOUT, error module: BL_CARVEOUT, reason: 0x03, aux_info: 0x04
[0000.502] C> Boot Info Table status dump :
01111111001110001111111111111111
Before this, I also had moderate success by trying to add board support in a fork and I was able to get much closer to a successful boot. I’ve been able to get Balena booting from the USB drive, and most of the peripherals work (USB, status LED, Ethernet) while booted with USB.
However, after flashing to NVMe succeeds and the device restarts, it gets stuck at boot, this time with an error about trying to read from the EEPROM because cvb_eeprom_read_size is not set correctly.
It seems that the firmware loaded during flashing works (temporarily) but then whatever actually gets flashed is incorrectly configured.
My current attempt at board support for the carrier board is in this fork:
And what should be included in which part of the Yocto build. My PRs are quite messy because of this and I think a bunch of the files are in the wrong place.
Tested this again and confirmed that depending on how I build and flash balena, I always get one of these two issues in the bootloader aAfter the first boot w/ USB succeeds:
[0000.483] E> BL_CARVEOUT: Failed to allocate memory of size 0x4000000 for CO:43.
[0000.490] C> Task 0x20 failed (err: 0x49490403)
[0000.495] E> Top caller module: BL_CARVEOUT, error module: BL_CARVEOUT, reason: 0x03, aux_info: 0x04
[0000.504] C> Boot Info Table status dump :
Or
I> Task: Prepare eeprom data
E> I2C: slave not found in slaves.
E> I2C: Could not write 0 bytes to slave: 0x00ae with repeat start true.
E> I2C_DEV: Failed to send register address 0x00000000.
E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xae at 0x00000000 via instance 0.
E> eeprom: Retry to read I2C slave device.
E> I2C: slave not found in slaves.
E> I2C: Could not write 0 bytes to slave: 0x00ae with repeat start true.
E> I2C_DEV: Failed to send register address 0x00000000.
E> I2C_DEV: Could not read 256 registers of size 1 from slave 0xae at 0x00000000 via instance 0.
E> eeprom: Failed to read I2C slave device
C> Task 0x0 failed (err: 0x1f1e050d)
E> Top caller module: I2C_DEV, error module: I2C, reason: 0x0d, aux_info: 0x05
I> Busy Spin
