2 posts were split to a new topic: Reduce clock speed/power consumption on RPi4B?
@arne_f - Is there anything else I can try to test out? I didnât see any associated updates in the most recent test version, but I may have missed it. In the end, I could always swap my two Pi 4âs and probably get up and running. I had been holding off doing that in order to allow for testing more combinations, but I donât know what else I can try? Anything else I can do to help?
Craig
One more interesting data point. I found out that Ubuntu is using u-boot as well. I grabbed the 20.04 (desktop) image, flashed it to an SD card and tried to boot it up. Iâm seeing exactly the same error code loop there as Iâm seeing with IPFire. I will update the IPFire ticket with this new information and I will go ahead and open a bug report in u-boot as well.
This is strange because i use ubuntu 20.04 on an 8GB RPi4 to built the IPFire image.
Maybee there are also different 8GB hardware revisions.
I honestly donât know at this point. While Iâm fairly technical, u-boot is way lower level than I generally deal with and I donât really know how else to help.
Hi, iâm new to Ipfire and Raspberry and iâm facing the same problem
invalid bus width
error -22 whilst initialising SD Card
And really donât know what to do, iâve tried flashing it many times using different pieces of software and still getting the same error
i have the new board rev 1.4
which models do you have?
I have Rev 1.2 as 2GB and 4GB version.
Rev 1.4 has an important hardware change. The VIA VL805 has no firmware EEPROM anymore so the bootloader must initalize it before it try to use it.
I have tried to update u-boot to 2021.10 rc5 which now crash on all my RPi 4 boards.
https://people.ipfire.org/~arne_f/highly-experimental/u-boot-2021.10-rc5/
so is no solution.
I have tried to update u-boot to 2021.10 rc5 which now crash on all my RPi 4 boards.
https://people.ipfire.org/~arne_f/highly-experimental/u-boot-2021.10-rc5/
so is no solution.
Is it worth me downloading and trying on my Pi or is it completely busted?
I did try to post to their mailing list about this issue, but my post has so far not cleared moderation. It is unclear to me how to interact with the u-boot team to even log this issue.
Craig
Hello,
maybe thatâs a helpful hint.
https://forums.raspberrypi.com/viewtopic.php?t=319125
https://archlinuxarm.org/forum/viewtopic.php?f=67&t=15422
According to this threads i have modified the files boot.cmd and boot.scr and ipfire boots up until setup with a revision 1.4 board.
- booti ${kernel_addr_r} ${ramdisk_addr} ${fdt_addr_r};
+ booti ${kernel_addr_r} ${ramdisk_addr} ${fdt_addr};
- booti ${kernel_addr_r} - ${fdt_addr_r};
+ booti ${kernel_addr_r} - ${fdt_addr};
But after that it doesnât go any further.
The keyboard does not work or the system hangs.
Regards
Michael
This seems like a very positive bit of insight!
I have Rev 1.2 as 2GB and 4GB version.
Rev 1.4 has an important hardware change. The VIA VL805 has no firmware EEPROM anymore so the bootloader must initalize it before it try to use it.
so is no solution.
Considering the popularity of RPi 4 boards, should a note be put on the wiki, to the effect that ânewly purchased boards are currenly not workingâ ?
there is already a note:
True - but newbies might not be aware of whether rev 1.4 is old, new or somewhere in between nor might vendors be aware of what rev they are selling, because there appears to be no relevant markings.
IPFire Project wonât endear itself to prospective users if many buy a new device, only to find that it might not be supported any time soon.
should a note be put on the wiki, to the effect that ânewly purchased boards are currenly not workingâ ?
It isnât ALL ânewly purchased boardsâ. My RPi4B 4GB RAM model is brand new and just purchased last month. And it works A-OK.
Feel free to update the IPFire Wiki as you see fit. It is open to the IPFire community for reading and writing.
It isnât ALL ânewly purchased boardsâ. My RPi4B 4GB RAM model is brand new and just purchased last month. And it works A-OK.
Probably dependent on the stock that a supplier has so newly purchased may still be an old hardware version if the stock is not so new.
Unfortunately if Raspberry donât put a hardware version number on the board then it is just a guessing game.
Iâll leave to those having RPi 4 to update the wiki content regarding it. I donât have one.
This isnât the list I was looking for but it might help:
https://elinux.org/RPi_HardwareHistory
Near the end of the table are three entries for the latest RPi boards. They have a version 1.4 with a release date of Q2 2020.
See Arneâs post for reference to the version 1.4:
Rev 1.4 has an important hardware change. The VIA VL805 has no firmware EEPROM anymore so the bootloader must initalize it before it try to use it.
I tried LOTS of different terminal commands to grab the model number but I didnât find one that works with the IPFire. Many of the commands I found were for the Raspberry Pi OS Buster (or something similar). Like this one in the link above:
cat /proc/cpuinfo | grep 'Revision'
A few references were non-RPi terminal commands but I did not locate the Model number.
So we may need to find a way to identify the model number and the version. Besides building up a Raspberry PI OS build and testing.
The reality is that someone could spend upwards of 100 euro on a RPi 4 ensemble (board, case, fan, power supply, quality uSD card) and have unknown/low probablity of it working with IPFire, whereas for not much more oultlay, they could purchase an economy, pre-assembled x86_64 mini-pc and have almost 100% probablity of it working with IPFire.
Rodney - I understand what you just stated. That makes sense to me.
And I know the 8GB RAM model is the one that doesnât work. I think the note at the top addresses that device.
So I am missing your concern. What words are missing from the wiki?
If you just do
cat /proc/cpuinfo
Then there is a section like this
Hardware : BCM2835
Revision : a01041
Serial : 00000000ab2dce93
Model : Raspberry Pi 2 Model B Rev 1.1
The line Revision is the same as the first column of the table that you showed. So you should be able to tell from that if a board is a 1.4 or earlier.
The above is from an old RPi that I use with Arch Linux as my orange zone dhcp server but the cpuinfo should, I believe, be available from all the ARM based installs.