Rpi4 < $(community_build)

just click refresh... that is a known thing about firstboot especially if internet is unavailable...

ok, cool... I will test this now;

  • boot from factory on usb with no mmc inserted with boot order set to f14
  • reboot from luci

about the first one, the internet was available.

tests fine for me under those conditions using luci reboot
(usb3 stick in usb3 port)

maybe try a different disk or port...
(is it a newer 8G model?)

If I disconnect the pi from power and reconnect it again, it boots just fine.
its the 2gb model

1 Like

tried a different USB device. no luck.

1 Like

sounds hardware/bootloader-config specific

try asking the learnered peeps https://forums.raspberrypi.com/ about any experience with that disk or symptoms...

only thing that's really standing out to me based on what's been provided is the uber recent bootloader version... (or is that 12th of the 2nd format is different)

i'm running: Apr 29 2021 17:11:25

########### ls -1 firmware/stable/ | grep '^pieeprom-2021' | tail -n5
pieeprom-2021-01-16.bin
pieeprom-2021-02-16.bin
pieeprom-2021-03-18.bin
pieeprom-2021-04-29.bin *
pieeprom-2021-07-06.bin

so i'm one stable version behind... but it was tested working from the december 2020 or something (initial stable usb boot release from last year... may have been mid-year) bootloader also... most fixes since then are all video related... with some whacky xhci quirks too...

last one with anything substantial was 03/2021 here is the list while I have it up...

Display VC_BUILD_ID strings instead of the SHA256 hash
Add support for [cm4] and [pi400] config conditionals filters.
Change network boot to use the same "RXID" Ethernet PHY configuration as the 5.10 kernel
TFTP - reply to duplicate ACKS
Skip rendering of HDMI diagnostics display for the first 8 seconds unless an error occurs.
UDP checksum fixes
Add support for the BCM2711 XHCI controller - BOOT_ORDER 0x5
XHCI protocol layer fixes for non-VLI controllers
*? Avoid USB MSD timeout if there is only one device
Implement tryboot for OS upgrade fallback
Check the update-timestamp before applying an update in SELF-UPDATE mode

ill flash the version you have and let you know, currently I'm on it.

right, it's not booting regardless of the USB drive or the EEPROM version. it will boot 1 time and won't reboot.
this is only happening with OpenWrt, not raspbian os.
very odd.

1 Like

hmmm... still could be hardware but seeing as you went through all that trouble... the output from these might be useful;

from my build...;

rpi4-getrevision.sh 

from raspbiOSianian;

strings /boot/start4.elf | grep VC_BUILD
rpi4-getrevision.sh
4B 1.2 2GB Sony_UK b03112
strings /boot/start4.elf | grep VC_BUILD
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 10:47:33
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Oct 29 2021
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_BRANCH: stable_20210929
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: b8a114e5a9877e91ca8f26d1a5ce904b2ad3cf13 (clean)

now, i will boot from an sd card and update it to the lastest build and clone the card to the USB device to see if the problem is still there.

1 Like

ok... it's a newer 2G ... i've got

[root@dca632 /usbstick 56°] rpi4-getrevision.sh 
4B 1.1 2GB Sony_UK b03111

well... in light of the above... when the firstboot is done if you are comforable with a text editor or using 21.02.1 (luci > [editor]) or in a pc...

you might try removing...

/boot/cmdline.txt

pci=pcie_bus_perf

/boot/config.txt

dtparam=sd_poll_once

no idea what the top one does... maybe it's not liking that board revision...


elfdat-notes

other than that... my build has 'head' elf/dat /boot/[firmware]... so we could also try matching whatever is in raspbiOSianian...

[root@dca632  56°] strings /boot/start4.elf | grep VC_BUILD
VC_BUILD_ID_USER: dom
VC_BUILD_ID_TIME: 11:40:59
VC_BUILD_ID_VARIANT: start
VC_BUILD_ID_TIME: Dec  1 2021
VC_BUILD_ID_BRANCH: bcm2711_2
VC_BUILD_ID_HOSTNAME: buildbot
VC_BUILD_ID_PLATFORM: raspberrypi_linux
VC_BUILD_ID_VERSION: be18b6271a0f99f896fc81249da5da6658422558 (clean)

after those two... I am truly lost...

(come to think of it that might make more sense if you've been testing with 21.02.1 up until now) pi-foundation claim these are supposed to be backwards compatible... but we just may have found the straw that broke the camels back... i probably should have frozen that for 21.02.x but it's worked ok up until now and is a bit of an artifact of how my build scripts work)

although... it boots once... so that points more towards the txt if anything...

1 Like

it's rebooting without problems now!
after removing

pci=pcie_bus_perf
dtparam=sd_poll_once
1 Like

omg! winner :1st_place_medal:

no more pcie_bus_perf then I guess... if you never mentioned reboot works with raspiOSianian I would have never made the connection...

thanks heaps for helping me find that bug... ( but my bad on that one, because that tweak didn't really have any proven major benefit so really should not have enabled it...)

1 Like

I'm very new to this kinda stuff, but I'm enjoying it. Thank you too!

1 Like

it is back again after I restored a previous config backup. then I edited config.txt and cmdline.txt but it's still not solved. maybe ill have to do everything from scratch. also, see this.
Thank you.

1 Like

make your backup using the [backup] in the picture above...


by 'see this' do you mean update-unavailable? did you click [refresh]?

yes. I did hit refresh. didn't work.

1 Like

this may tell us something... may not;


grep UPGRADEs /root/wrt.ini; rm -rf /tmp/.update* ; rpi-sysup-online.sh -v check

i got this

 grep UPGRADEs /root/wrt.ini; rm -rf /tmp/.update* ; rpi-sysup-online.sh -v check
#UPGRADEsFLAVOUR="release"
UPGRADEsFLAVOUR="release"
Download: wulfy23/rpi4 rpisysup.sh
/tmp/rpisysup.sh              100%[=================================================>]  32.53K  --.-KB/s    in 0.01s
/bin/sh /tmp/rpisysup.sh   check   -v
no-flavour-given@ini> FLAVOUR=release
ext4 sysupgrade only
1 Like

yay, something to work with!

blkid
cp /etc/custom/wrt.ini /root/wrt.ini

hmmmm... leave those with me... i'll check the logic in case its rejecting non mmc somewhere in the updatecheck...