Slarm64 (up to date) on a Pi 400.

Managed to mess up my install updating the kernel a few days ago. Managed to get it all sorted, but now I have to use uBoot - the kernel image doesn't seem to work anymore. Not a problem, except...

During the initial uBoot screen, I see a very brief message about being unable to read uEnv.txt. Its there and gone in a flash (no idea if its logged anywhere?) but it seems to be saying that opening the file would over-write reserved memory.

Everything appears to be working normally, except WiFi has gone walkabout again! My usual fix no longer works. Not a big issue, as I have a wired connection available, but irritating!

--
Pete

i added support for overlays maybe problems in prefixes/suffixes.

need logs to understand the problems.

The wifi issue (and I've just noticed sound is missing too) may be related to the uEnv.txt issue. That contains the "fdtfile=bcm2711-rpi-400.dtb" statement, and if that is not getting read, I suspect the configuration may be wrong.

I'm not at all familiar with the Pi boot process - especially uBoot - but that looks like some kind of database file to me, so its probably important!

There's also quite a lot of other stuff in that file that looks related to setting up sound, mac addresses, etc. Until I can get the file read at boot, I'm not inclined to bother about looking for the other stuff.

Does uBoot log its process anywhere? This appears to be before the kernel boots, so I wouldn't expect to find anything in the kernel logs. Also, I'm not clear if the uEnv.txt file is only used by the uBoot process, and the kernel sorts its own configurations out once loaded?

Any advice / suggestions welcome!

Cheers,

--
Pete

logs is about dmesg.

Yes, but dmesg only records the *kernel* messages.The failure to load uEnv.txt is happening during the uBoot sequence, before the kernel loads. I tried "dmesg | grep uEnv", but unsurprisingly, it shows no results.

I've tried googling for "uboot Reading file would overwrite reserved memory" which produces quite a lot of hits, but none specific to the Pi.

--
Pete

uEnv.txt is read by u-boot from boot.scr

OK, I see a line at the top of the boot.scr file which reads:
I've also found some references (via google) to uboot having been "fixed" to stop files over-writing reserved memory. This is presumably the problem I'm running in to - that "load addr" is already in use by something, and the newer uboot is barfing on it.

Knowing little or nothing about how the Pi handles its memory, I'm loath to just blindly experiment! But I'm guessing that the "0x3900...." is the culprit?

--
Pete

try "0x02400000" in boot.cmd
and recompile boot.scr

YES! That has got it to load the uEnv.txt script OK.

Still no wifi or audio, but I'll have a look at that tomorrow!

To get bluetooth to work, I had to add Exaga's fix to the config.txt file:
Previously, to get wifi working, I had to replace the entire brcm folder in /lib/firmware with one from Raspbian, and delete the /lib/firmware/ap6256 folder. I haven't done that recently, so the firmware folder probably got overwritten when I did the kernel upgrade. Not previously had an issue with sound, though (unless it was so long ago, I've forgotten!).

Its getting late here, so I'm calling it quits for tonight. I'll have another look in the morning, and post any logs that look interesting. Is there anything specific you would like me to look for?

--
Pete

enough detailed dmesg in uEnv.txt verbosity=8


but dtoverlay=enable-bt works instead of dtparam=krnbt=on ?

1 members found this post helpful.

I ran into something similar when trying to create new images for my NanoPi NEO Core2 after the overlay / prefix / suffix switches. After a bunch of head scratching and config fiddling, one of the essential parts of the fix was to change the ftd line in uEnv.txt as such:

old line:
new line:
The fact that I had a typo in the filename for the *.dtb did not help either, but eventually both fixes made booting work again.

So, in your case, I would expect to see a change by changing:
to:
or something similar, maybe? I am not sure, I do not have a Raspberry Pi to test with, and I know they have a different boot process than the allwinner or rockchip boards.

The original post reminded me of my situation, so I thought I would share just in case it helps. The original problem was that I was passing the wrong filename for the dtb all together, and after I got that straightened out, I still had to add the directory prefix for the *.dtb file.

What are the contents of your /boot/dtbs directory on that image? Just curious...

1 members found this post helpful.

for broadcom it is taken without prefixes (everything is in the root) from 1 partition

1 members found this post helpful.

OK, curioser and curioser!

@shelldweller: the bcm2711-rpi-400.dtb file appears in /boot , /boot/dtb and boot/dtbs/5.17.2/broadcom.

The files are all the same size, so I assume they are identical. boot/dtbs/5.17.2/ also contains a folder named "overlays". The only thing I see of interest (to me!) in there is the rpivid-v4l2.dtbo file, which I believe is something to do with hardware video acceleration (still investigating this!). Your thoughts on needing the full path to these files might explain why I've never had much luck getting this to work, and I will follow it up!

Back to the main issues:

@sndwvs: That is interesting! Using that instead of Exaga's fix gets audio working, but kills bluetooth! Restoring Exaga's fix and commenting out yours re-instates bluetooth, but kills audio!

I'm attaching 4 files.two are demsg files with the sndwvs fix for bluetooth or Exaga's fix. The other two are the outputs from I don't currently have a monitor that supports sound over hdmi (one is arriving this afternoon), but since the desktop indicates audio is muted with Exaga's fix, I assume its not working. I should be able to confirm or otherwise this evening.

To fix Wifi, I'm going to try my old fix of replacing the /lib/firmware/brcm folder with the one from Pi OS and removing the /lib/firmware/ap6256 folder. This has worked in the past, but not recently. This may be connected to the above oddities between fixes, as noted above!

Cheers,

--
Pete

Attached Files

	dmesg_sndwvs.txt (33.4 KB, 3 views)
	dmesg_exaga.txt (32.8 KB, 5 views)
	asound_sndwvs.txt (428 Bytes, 5 views)
	asound_exaga.txt (154 Bytes, 5 views)

Quick update on wifi: Replacing the /lib/firmware/brcm folder with either the one from Pi OS or slackwareaarch64 causes the wifi icon to appear in NetworkManager, but no networks show. Using the stock brcm folder, I don't even get the icons in NetworkManager.

--
Pete

NetworkManager is not an indicator, you need to look in dmesg about loading firmware.