search

raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.1k stars 1.68k forks source link

Firmware does not boot my bare metal software anymore #1561

Closed alepi closed 3 years ago

alepi commented 3 years ago

Describe the bug Hi, I am writing bare metal software for the raspberry pi 4. To boot it I used to copy the FAT partition from a raspberry pi os image and then add in my kernel and config.txt. This does not work anymore.

Firmware from 2019-09-26-raspbian-buster.img boots bare metal software perfectly. Firmware from 2021-03-04-raspios-buster-armhf.img hangs at the coloured square.

My config.txt is as follows:

arm_64bit=1 kernel_old=1 disable_commandline_tags=1

To reproduce get this code (it's not my actual code but I tried this one as a test and got the same problem) https://github.com/isometimes/rpi4-osdev/tree/master/part5-framebuffer and build it. Copy the firmware from 2021-03-04-raspios-buster-armhf.img and it hangs. Copy the firmware from 2019-09-26-raspbian-buster.img and it boots.

Expected behaviour I would expect the software to boot normally as before.

Actual behaviour The software hangs at the initial coloured square.

System

popcornmix commented 3 years ago

Can you identify the exact update which caused this. See: https://github.com/Hexxeh/rpi-firmware/commits/master

If you click on each commit the end of the url contains a git hash. Run sudo rpi-update <hash> to revert back to that version. Report the first version with this error.

alepi commented 3 years ago

I'll do that and report it back here when I find out what the specific commit is. Thanks :-)

alepi commented 3 years ago

Ok, I did the tests. I have two consecutive commits where the earliest works and the latest doesn't

commit 634e380a4d041492f859712bd2c81112a535b515 DOES work commit da3752a358a86014cdcce5fc3be5b18d7ec074c4 does NOT work

I am leaving that to you guys. Let me know :-)

pelwell commented 3 years ago

firmware: arm_ldconfig: Honour the kernel8 text offset looks like a likely culprit.

alepi commented 3 years ago

I am not an expert in these matters but it looks likely that you're right.

My bare metal software expects to be loaded at 0 and uses the documented kernel_old=1 option to ensure that it is ok to be loaded there.

pelwell commented 3 years ago

That sounds like a regression. Does it work with kernel_address=0?

pelwell commented 3 years ago

Never mind - it won't. The fix looks easy.

alepi commented 3 years ago

Cool thanks :-) Let me know when to close the issue

pelwell commented 3 years ago

The fix was, indeed, simple - it's in the internal software repo and a firmware build including the patch has successfully loaded the example bare-metal image and put some graphics on the monitor. Once the next firmware release is available we'll comment here - close the issue when you can confirm the problem is solved.

alepi commented 3 years ago

cool thanks :-)

popcornmix commented 3 years ago

Not sure if you noticed the github message above, but the fix is in current rpi-update firmware.

alepi commented 3 years ago

Hi,

thanks :-)

Sorry for the slow response, it can take me a while to do the rpi-update as I am not using raspbian and every time I have to reinstall it.

I just reinstalled it, did an rpi-update and still it does not work.

I tried also with the specific commit with hash 1df55790fb191704c0ce630d4d0713a8beb43a7d and it complained that the hash was invalid.

pelwell commented 3 years ago

@popcornmix This update didn't make its way to Hexxeh's rpi-firmware repo, so it isn't available via rpi-update. Is this by design?

@alepi In the short term you will need to download the files manually from here: https://github.com/raspberrypi/firmware/tree/master/boot

popcornmix commented 3 years ago

Sorry - didn't get pushed to Hexxeh - done now.

alepi commented 3 years ago

rpi-update works now :-)

closing the issue