OK. I suggest you get a console cable and post the output from the console logs. It’s pretty much shooting blindly without that information.
Drew
You mean something like a ADAFRUIT Industries 954 USB-to-TTL Serial Cable, Raspberry PI ? Ok, i’ll get one and see how to output what it says. Thx
Yes. Those are good devices to have for troubleshooting when working with the RpI platforms.
Drew
I get a blank screen on windows and mac. Side note is that I see that you changed the process and it seems broken in the sense that before when I switched branches it would re-build a lot of the recipes and re-create the image. I did a git pull and notice patches and linux-firmware update but when I did a bitbake image, it said nothing was needed to update and switching branches seemed to cause no changes in the image. I ran repo sync but that didn’t do anything.
Maybe related to the boot issue, I got this warning message:
WARNING: u-boot-1_2020.01-r0 do_provide_mender_defines: Found more than one dtb specified in KERNEL_DEVICETREE ( bcm2708-rpi-zero-w.dtb bcm2708-rpi-b.dtb bcm2708-rpi-b-plus.dtb bcm2709-rpi-2-b.dtb bcm2710-rpi-3-b.dtb bcm2710-rpi-3-b-plus.dtb bcm2711-rpi-4-b.dtb bcm2708-rpi-cm.dtb bcm2710-rpi-cm3.dtb overlays/at86rf233.dtbo overlays/disable-bt.dtbo overlays/dwc2.dtbo overlays/gpio-key.dtbo overlays/hifiberry-amp.dtbo overlays/hifiberry-dac.dtbo overlays/hifiberry-dacplus.dtbo overlays/hifiberry-digi.dtbo overlays/i2c-rtc.dtbo overlays/iqaudio-dac.dtbo overlays/iqaudio-dacplus.dtbo overlays/miniuart-bt.dtbo overlays/mcp2515-can0.dtbo overlays/mcp2515-can1.dtbo overlays/pitft22.dtbo overlays/pitft28-resistive.dtbo overlays/pitft28-capacitive.dtbo overlays/pitft35-resistive.dtbo overlays/pps-gpio.dtbo overlays/rpi-ft5406.dtbo overlays/rpi-poe.dtbo overlays/vc4-kms-v3d.dtbo overlays/vc4-fkms-v3d.dtbo overlays/w1-gpio-pullup.dtbo overlays/w1-gpio.dtbo overlays/gpio-ir.dtbo overlays/gpio-ir-tx.dtbo ). Only one should be specified. Choosing the last one: bcm2710-rpi-cm3.dtb. Set KERNEL_DEVICETREE to the desired dtb file to silence this warning.
I will try setting the u-boot KERNEL_DEVICETREE to bcm2711-rpi-4-b.dtb and seeing if it fixes anything.
You should be getting UBoot output at the least. If not, then changing the device tree entry won’t make a difference as the issue is somewhere else.
I don’t follow your issue about the building of packages. Bitbake is pretty good about not rebuilding things it doesn’t need to do, and that’s pretty much independent of Mender. I can’t comment in your specific case since I don’t know exactly what is done.
One question I have though, you mention both changing branches and running repo sync. I’m wondering if you have a mismatch of branches? I’ve never tried changing branches within a repo checkout. I normally just keep a directory for each branch that I want to work with to avoid any chance of that.
Can you start fresh and record all the steps you are taking so I can try and replicate your issue?
Drew
So, I started a new build using the normal yocto build process and I was able to get the Warrior branch to bootup, which is better than nothing. I tried both the master branch and and dunfell branch but the board is still not booting up on the raspberry pi 4. I tried the build on the raspberry pi 3 and it seemed to work, so the issue seems isolated to raspberry pi 4. Not sure if the version of raspberry pi 4 hardware matters, but it’s the original hardware and no the updated version.
Thanks for the details. @lluiscampos do you have any thoughts on this?
Sorry @ikkysleepy but I don’t know what the issue might be neither. Tomorrow I am going to the office so I’ll give it a try with a freshly build image, but at this point is really hard to guess what can be wrong with your setup (if anything is wrong).
@lluiscampos It looks like I’m hitting a similar problem to the one @ikkysleepy described.To my knowledge, I followed the procedure on this page, specifying BRANCH as ‘dunfell’. I’m using a Raspberry PI 4b with 8 GB of RAM. I verified I can flash a Raspbian OS image, and that boots, with serial output, so I believe there’s an issue with this Mender Yocto image that I’ve built.
I’m following up see if you were able to reproduce the problem on your end?
@mikeb @ikkysleepy Actually, I have been able to reproduce it today in the office and I am investigating further as we speak… Thanks for reporting! I’ll keep you posted.
@lluiscampos Thank you. Out of curiosity, does your raspberry pi 4b have 8 GB of RAM? I know that the Raspbian based bootloader required an update to handle the newer model with more memory. But if yours has less, then of course, that would suggest this is a different issue.
Hi again,
Just as a heads-up: I was not able to figure it out today and I will be offline for 5 days now. I hope to have time to look into this more next week.
@lluiscampos Thank you for the update. FWIW, I just built a stock raspberry pi 4 image with dunfell, following this procedure:
This came right up on my board. So just as a datapoint, I think the mender specific layer may have something stale, or perhaps a regression.
@mikeb @ikkysleepy Hi again. Sorry I have been offline for few days.
So after some closer debugging, the problem was quite obvious after all: we are missing setting ENABLE_UART in local.conf.
See layer documentation here: meta-raspberrypi/extra-build-config.md at master · agherzan/meta-raspberrypi · GitHub
I did submit a PR to meta-mender-community adding such setting (see here), but you should be able to see the serial output by just adding to your local.conf the following:
ENABLE_UART = "1"
Why this works in warrior is a mystery to me…
@lluiscampos Thank you for following up! I’m curious, does this imply that this BSP is expected to not output on HDMI, and only on the UART? For ex. the stock raspberry pi 4 yocto BSP I built outputted to HDMI by default.
@mikeb I am not sure, to be honest. This is a detail that I couldn’t figure out the reason for.
My final step to make the image bootable was to set KERNEL_IMAGETYPE to “uImage” as U-Boot scripts get confused if it’s anything else.
2 Likes
I’m also having u-boot issues on the pi 4. Not sure if the meta-raspberrypi layer is using this branch of u-boot or ( GitHub - agherzan/u-boot at ag/rpi4) or upstream u-boot which doesn’t seem to have much support. There’s a issue tag open in the meta-raspberrypi layer Rpi 4 doesn't boot with u-boot when enable_uart=0 in config.txt · Issue #732 · agherzan/meta-raspberrypi · GitHub around why u-boot isn’t loading. Added comment here Rpi 4 doesn't boot with u-boot when enable_uart=0 in config.txt · Issue #732 · agherzan/meta-raspberrypi · GitHub. Whenever I try to get u-boot going on the raspberrypi 4 I run into bellow
DRAM: 3.9 GiB
RPI 4 Model B (0xc03112)
mbox: Timeout waiting for response
bcm2835: Could not set module 3 power state
initcall sequence 000000003b3d28f8 failed at call 0000000000084344 (err=-5)
### ERROR ### Please RESET the board ###
Is anyone else seeing similar issues? Or already working on a solution to solve it?
Update: Nevermind upstream support for the raspberrypi 4 in u-boot does exists. Looks like my issue is here arch/arm/mach-bcm283x/msg.c · master · U-Boot / U-Boot · GitLab. Not sure why bcm2835_mbox_call_prop fails to set power state.
If you change the if statement which I don’t recommend. You can get as far as
U-Boot 2021.10-rc4-00005-g66448edb24-dirty (Sep 16 2021 - 12:42:29 -0500)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03112)
mbox: Timeout waiting for response
MMC: mbox: Timeout waiting for response
mbox: Timeout waiting for response
bcm2835: Could not query eMMC clock rate
mbox: Timeout waiting for response
mbox: Timeout waiting for response
bcm2835: Could not query eMMC clock rate
mbox: Timeout waiting for response
mbox: Timeout waiting for response
bcm2835: Could not query eMMC clock rate
mmcnr@7e300000 - probe failed: -5
mbox: Timeout waiting for response
mbox: Timeout waiting for response
bcm2835: Could not query eMMC clock rate
emmc2@7e340000 - probe failed: -5
mbox: Timeout waiting for send space
mbox: Timeout waiting for send space
bcm2835: Could not query eMMC clock rate
Loading Environment from FAT... mbox: Timeout waiting for send space
mbox: Timeout waiting for send space
bcm2835: Could not query eMMC clock rate
In: serial
Out: serial
Err: serial
mbox: Timeout waiting for send space
bcm2835: Could not query MAC address
mbox: Timeout waiting for send space
bcm2835: Could not query board serial
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
U-Boot> ls
ls - list files in a directory (default /)
Usage:
ls <interface> [<dev[:part]> [directory]]
- List files in directory 'directory' of partition 'part' on
device type 'interface' instance 'dev'.
U-Boot>
Not sure if this is related but now I am getting this error
ERROR: u-boot-1_2020.01-r0 do_configure: U-Boot configuration rpi_4_32b_config has setting:
CONFIG_ENV_OFFSET=0x800000
CONFIG_ENV_OFFSET_REDUND=0x1000000
but Mender expects:
CONFIG_ENV_OFFSET=0x400000
Please fix U-Boot's configuration file.
I see that this was maybe fixed here: meta-mender/0001-configs-rpi-enable-mender-requirements.patch at master · mendersoftware/meta-mender · GitHub but doesn’t seem like it’s working now.
This is related to having used too much storage I think:
ERROR: Actual rootfs size (28618 kB) is larger than allowed size 16384 kB
Update: this fixed the issue:
MENDER_STORAGE_TOTAL_SIZE_MB = "2824"
MENDER_BOOT_PART_SIZE_MB = "32"
CONFIG_ENV_OFFSET = "0x800000"
CONFIG_ENV_OFFSET_REDUND = "0x100000"
Note that you don’t need to set those two CONFIG_ENV variables in local.conf, and in fact it’s better not to. They are tied to the patch contents, and therefore should be set by the meta-mender layer (it’s why the error happened in the first place).