Please test the aktual nightly build of the next tree.
https://nightly.ipfire.org/next/
Im working on RPi firmare / u-boot updates.
Om my RPi’s (RPi3b+ and RPi4 4GB v1.2) this image boot from mmc and also from usb without manual changes.
2 Likes
Hi Arne,
I downloaded the flash image and it booted fine.
"system": {
"kernel_release": "6.12.8-ipfire",
"language": "en",
"memory": 8041100,
"model": "Raspberry Pi 4 Model B Rev 1.5",
"release": "IPFire 2.29 (aarch64) - core192 Development Build: next/b9dd3e20",
"root_size": 125173760.0,
"vendor": null,
"virtual": false
}
I did notice is that it recognizes the microsd card as mmcblk1 instead of mmcblk0.
179 0 125173760 mmcblk1
179 1 507904 mmcblk1p1
179 2 32768 mmcblk1p2
179 3 124616704 mmcblk1p3
I checked and confirm that journal is on for p3.
[root@ipfirearne log]# tune2fs -l /dev/mmcblk1p3 | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent 64bit flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize metadata_csum orphan_present
I also have a Pi4B Rev 1.1. I know that work before, but will try on that when I can to see if any regression issues there.
Regards,
Stephen
Hi Arne,
Pi4B Revision 1.1 also boots with no problems:
"system": {
"kernel_release": "6.12.8-ipfire",
"language": "en",
"memory": 3926684,
"model": "Raspberry Pi 4 Model B Rev 1.1",
"release": "IPFire 2.29 (aarch64) - core192 Development Build: next/b9dd3e20",
"root_size": 62367744.0,
"vendor": null,
"virtual": false
}
179 0 62367744 mmcblk1
179 1 507904 mmcblk1p1
179 2 32768 mmcblk1p2
179 3 61810688 mmcblk1p3
[root@ipfirearne ~]# tune2fs -l /dev/mmcblk1p3 | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent 64bit flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize metadata_csum orphan_present
Regards,
Stephen
Hi Arne,
my first post ever…
Allow me to confirm: Your new Core 192, ( 2025-01-05 19:59:27 +0100-b9dd3e20/),
works on raspi 4, 8 GB, Rev. 1.4, see profile in this post.
Let me add: Core 192 shows hardware-graphs, which I missed since the new kernel shipped with core 174 (or 178?) until core 190.
In core 190 I additionally get an error which reads: “cannot assign (mac-adress of raspi-wlan)”. This error is gone with core 192, too.
To boot from usb-stick I just had to change “serial=on” to “off”.
I’m no technician and I won’t be online often, but if you tell me, which log you would like to see and were I may find it, I will do my best.
{
“profile”: {
“bogomips”: 108.0,
“cpu”: {
“arch”: “aarch64”,
“count”: 4,
“family”: null,
“flags”: [
“fp”,
“asimd”,
“evtstrm”,
“crc32”,
“cpuid”
],
“model”: null,
“model_string”: null,
“speed”: 0,
“stepping”: null,
“vendor”: “”
},
“devices”: [
{
“deviceclass”: “c0330”,
“driver”: “xhci_hcd”,
“model”: “3483”,
“sub_model”: “3483”,
“sub_vendor”: “1106”,
“subsystem”: “pci”,
“vendor”: “1106”
},
{
“deviceclass”: “60400”,
“driver”: “pcieport”,
“model”: “2711”,
“sub_model”: “0000”,
“sub_vendor”: “0000”,
“subsystem”: “pci”,
“vendor”: “14e4”
},
{
“deviceclass”: “3/1/1”,
“driver”: “usbhid”,
“model”: “0010”,
“subsystem”: “usb”,
“vendor”: “0461”
},
{
“deviceclass”: null,
“driver”: “usb”,
“model”: “0002”,
“subsystem”: “usb”,
“vendor”: “1d6b”
},
{
“deviceclass”: null,
“driver”: “usb”,
“model”: “6544”,
“subsystem”: “usb”,
“vendor”: “0930”
},
{
“deviceclass”: null,
“driver”: “usb”,
“model”: “3431”,
“subsystem”: “usb”,
“vendor”: “2109”
},
{
“deviceclass”: “3/0/0”,
“driver”: “usbhid”,
“model”: “0010”,
“subsystem”: “usb”,
“vendor”: “0461”
},
{
“deviceclass”: null,
“driver”: “usb”,
“model”: “0003”,
“subsystem”: “usb”,
“vendor”: “1d6b”
},
{
“deviceclass”: null,
“driver”: “usb”,
“model”: “0010”,
“subsystem”: “usb”,
“vendor”: “0461”
},
{
“deviceclass”: “9/0/0”,
“driver”: “hub”,
“model”: “0002”,
“subsystem”: “usb”,
“vendor”: “1d6b”
},
{
“deviceclass”: “8/6/80”,
“driver”: “usb-storage”,
“model”: “6544”,
“subsystem”: “usb”,
“vendor”: “0930”
},
{
“deviceclass”: “9/0/0”,
“driver”: “hub”,
“model”: “3431”,
“subsystem”: “usb”,
“vendor”: “2109”
},
{
“deviceclass”: “9/0/0”,
“driver”: “hub”,
“model”: “0003”,
“subsystem”: “usb”,
“vendor”: “1d6b”
}
],
“network”: {
“blue”: false,
“green”: true,
“orange”: false,
“red”: true
},
“system”: {
“kernel_release”: “6.12.8-ipfire”,
“language”: “en”,
“memory”: 8041100,
“model”: “Raspberry Pi 4 Model B Rev 1.4”,
“release”: “IPFire 2.29 (aarch64) - core192 Development Build: next/b9dd3e20”,
“root_size”: 15148608.0,
“vendor”: null,
“virtual”: false
}
},
“profile_version”: 0,
“public_id”: “077ee12d01962b7f5ef9751e113402d6b45ebecb”
}
I don’t need a log. The info that the boot works now is enough.
The missing graphs has a special reason in the work-around for the bootproblem. (most every syntax or fdt addressing error in boot.scr will switch to boot via grub fallback)
If you use this fallback not all hardware will detected. (tempsensors, sound etc.)
This now all should work.
@arne_f - Reading back, I’m wondering if the latest versions boot using serial console without the boot.cmd changes documented in the wiki? You may remember that I had submitted a patchset a while back to allow booting using serial console on those devices that were marked in the wiki. I’ve continued using my changes locally as I’ve done release updates. If those changes are no longer necessary or (worse) will actually break things, I’d love to hear more. If I get some time, I can try a fresh SD Card with the standard download as well as one where I’ve updated the boot.cmd/boot.scr to see how things behave. But, if you already know the status, I may not need to bother.
Thanks,
Craig
1 Like
I have still no newer boards but on my board this boot.cmd changes result in not full supported hardware (no temp sensors and no cpufreq)
An my boads are drawing much more power. (The change result in an error that do the same as erasing boot.cmd / boot.scr which fall back to a strip down devicetree.
some other users have reported that core192 boot without changes and support cpufreq now. Can you test this on your board? (usb and mmc boot)
@arne_f - Just to check. You are asking if I can test without my previous changes? I hope to do some testing this weekend. I have SD Cards created that are the base image from IPFire download as well as a card that has the changes I’ve been applying for the last few releases. I will start with the clean card to see what happens and report back.
At times, I’ve missed doing the Web UI update… but having the previous working card to swap back to ends up being worth the extra effort!
Craig
Gentlemen,
core 192 (download today, 250321) works on rpi 4b 8 GB Rev. 1.5 (eeprom “stable” dated january 2025.
Just had to change “serial” from on to off.
Installed from scratch and restored data.
{
"profile": {
"bogomips": 108.0,
"cpu": {
"arch": "aarch64",
"count": 4,
"family": null,
"flags": [
"fp",
"asimd",
"evtstrm",
"crc32",
"cpuid"
],
"model": null,
"model_string": null,
"speed": 0,
"stepping": null,
"vendor": ""
},
"devices": [
{
"deviceclass": "c0330",
"driver": "xhci_hcd",
"model": "3483",
"sub_model": "3483",
"sub_vendor": "1106",
"subsystem": "pci",
"vendor": "1106"
},
{
"deviceclass": "60400",
"driver": "pcieport",
"model": "2711",
"sub_model": "0000",
"sub_vendor": "0000",
"subsystem": "pci",
"vendor": "14e4"
},
{
"deviceclass": null,
"driver": "usb",
"model": "5583",
"subsystem": "usb",
"vendor": "0781"
},
{
"deviceclass": "255/255/0",
"driver": "r8152",
"model": "8156",
"subsystem": "usb",
"vendor": "0bda"
},
{
"deviceclass": null,
"driver": "usb",
"model": "0002",
"subsystem": "usb",
"vendor": "1d6b"
},
{
"deviceclass": "8/6/98",
"driver": "uas",
"model": "5583",
"subsystem": "usb",
"vendor": "0781"
},
{
"deviceclass": null,
"driver": "usb",
"model": "0010",
"subsystem": "usb",
"vendor": "0461"
},
{
"deviceclass": "3/0/0",
"driver": "usbhid",
"model": "0010",
"subsystem": "usb",
"vendor": "0461"
},
{
"deviceclass": "255/255/0",
"driver": "r8152",
"model": "8156",
"subsystem": "usb",
"vendor": "0bda"
},
{
"deviceclass": null,
"driver": "usb",
"model": "3431",
"subsystem": "usb",
"vendor": "2109"
},
{
"deviceclass": null,
"driver": "r8152-cfgselector",
"model": "8156",
"subsystem": "usb",
"vendor": "0bda"
},
{
"deviceclass": null,
"driver": "usb",
"model": "0003",
"subsystem": "usb",
"vendor": "1d6b"
},
{
"deviceclass": null,
"driver": "r8152-cfgselector",
"model": "8156",
"subsystem": "usb",
"vendor": "0bda"
},
{
"deviceclass": "9/0/0",
"driver": "hub",
"model": "0002",
"subsystem": "usb",
"vendor": "1d6b"
},
{
"deviceclass": "3/1/1",
"driver": "usbhid",
"model": "0010",
"subsystem": "usb",
"vendor": "0461"
},
{
"deviceclass": "9/0/0",
"driver": "hub",
"model": "3431",
"subsystem": "usb",
"vendor": "2109"
},
{
"deviceclass": "9/0/0",
"driver": "hub",
"model": "0003",
"subsystem": "usb",
"vendor": "1d6b"
}
],
"network": {
"blue": true,
"green": true,
"orange": false,
"red": true
},
"system": {
"kernel_release": "6.12.13-ipfire",
"language": "de",
"memory": 8041036,
"model": "Raspberry Pi 4 Model B Rev 1.5",
"release": "IPFire 2.29 (aarch64) - core192",
"root_size": 60082176.0,
"vendor": null,
"virtual": false
}
},
"profile_version": 0,
"public_id": "06174a8fe53f58c71ea826477e142d3f98f0ab97"
}
graphs:
ACPI Thermal-Zone Temp Diagramm works.
hwtemp Diagramm works
sda? I’m running from usb-stick.
statusinfo:
processor works.
cpu frequence shows nothing.
load average works.
Thank you for bringing back the graphs…
EDIT: moderator formatted code block
1 Like
@arne_f - Over the weekend, I had a chance to try using the standard Raspberry Pi image as well as my “hacked up” version. In my case, I do not have a display or keyboard attached and have been using serial console via my changes for the last few months. Unfortunately, neither of those versions work anymore. I will need to find more time to see if I can find an approach that does work for serial console, unless someone else has figured that out.
Thanks,
Craig
5 posts were split to a new topic: Just seeing the “rainbow-colored” screen on Raspberry 4 Rev 1.5