IPFire on Orange Pi R1 Plus LTS

[hexit78]

Hi, I have an Orange Pi R1 Plus LTS, this board is currently running OpenWRT 23.05.2 without problem.

I am not able to run IpFire on it.
Tried release ipfire-2.27-core182-aarch64.img.xz

I have followed this guide without success:
https://www.ipfire.org/docs/hardware/arm/orangepi/orangepi-r1-plus-lts

Serial output:

NOTICE:  BL31: v2.7(release):
NOTICE:  BL31: Built : 13:19:07, Dec 22 2023
NOTICE:  BL31:Rockchip release version: v1.2

Did I do something wrong?

[pike_it (Pike)]

Checksum of the image has been verified before etching into sdcard?

[hexit78]

No, I don’t find the checksum on the download page to do a comparison.

Where can I find it?

[pike_it (Pike)]

Indeed you’re correct.
https://www.ipfire.org/downloads/ipfire-2.27-core182
No checksum or link to checksum files on the download page.
At least for the flash file might be a useful tool to understand if the download went correctly.

Anyway: I don’t use ARM boards, neither I never used Orange Pi. I hope that some one with direct experience on your hardware might post something more useful.

[hexit78]

Thank you Pike,

I think you’re right, it’s the first thing to verify!

I found the b2 checksum file on a mirror download site and it’s the same of mine.
https://mirror.aarnet.edu.au/pub/ipfire/releases/ipfire-2.x/2.27-core182/

My problem was not caused by a bad checksum.

[peppetech]

I don’t have any experience with the Rock chip platform but there was an issue a little while ago

Core Update 167 requires additional step for ARM users before rebooting

Hi, unfortunately, there is still a quirk present in Core Update 167, affecting installations running on ARM: Because the packaged initial ramdisk for u-boot was missing in the update, ARM installations stall on booting after the upgrade, since the kernel version in the ramdisk differs from the actually installed kernel. Due to capacity constraints and some core developers being unavailable during the QA phase, this bug was unfortunately not fixed while Core Update 167 has still been in testin…

[hexit78]

How can I get rid of that, support for this development board was added at core 175, so I can’t run command before rebooting because I can’t start it first.

Did somebody know how this can be fixed when I prepare the SD card if that was the cause of the problem?

[bonnietwin (Adolf Belka)]

@peppetech

I don’t have any experience with the Rock chip platform but there was an issue a little while ago

That bug mentioned in that post was only applicable to upgrades from Core Update 166 to Core Update 167.
The bug was fixed for Core Update 168.

[ric9 (Rico Hoppe)]

@pike_it @hexit78

Checksums can be found through hovering over the download link for your image

[pike_it (Pike)]

Nice. Selecting the checksum value on a hovering layout. Easyest place for copying the data and matching the info of the checksum…

[bbitsch (Bernhard Bitsch)]

Depends on your system of matching.
Computing the checksum of your download and comparing with the hovering layout is possible.

[mike023456 (Mike O)]

Hi there.
Im new to IPFire. Just downloaded it to give it a try but I am having the exact same issue as Hexit78 and the exact messages mentioned below:

NOTICE: BL31: v2.7(release):
NOTICE: BL31: Built: 20:28:51, Apr 14 2024
NOTICE: BL31: Rockchip release version: v1.2

It’s an Orange Pi r1 Plus LTS. Verified SHA256 checksum and flashed it to 2 different SD cards including a SanDisk 64 GB class 10.

How can I debug this?!
Any help is highly appreciated.

[mike023456 (Mike O)]

Update:
Turns out it was a loose TTL UART connection! it’s magically working whenever I move the the jumper wires! must move them after every reboot for it to work! This made my day!

Now another problem.
For some reason IPFire setup can’t find any network interfaces. running ifconfig shows only the loopback interface.

[ms (Michael Tremer)]

@mike023456

Turns out it was a loose TTL UART connection! it’s magically working whenever I move the the jumper wires! must move them after every reboot for it to work! This made my day!

Interesting, but good that you found it.

@mike023456

For some reason IPFire setup can’t find any network interfaces. running ifconfig shows only the loopback interface.

That suggests that either the wrong device tree file is being loaded, the EFI BIOS not configured correctly to tell the OS which NICs it has, or simply there is no driver for them.

[mike023456 (Mike O)]

Further update:
All good now. The network interface issue was caused by a corrupted filesystem, probably due to the many hard resets I’ve done when the serial connection wasn’t working.

I re-flashed the image to the SD card again but back to square one… this time moving jumper wires didn’t help however changing serial baud rate helped! Used minicom instead of putty and now everything is working like a charm.

[mike023456 (Mike O)]

@ms a quick question: I noticed a weird behaviour:
The first time I flashed the IPFire image to the SD card, uEnv.txt didn’t have the following lines:

ethaddr=92:16:c3:e7:1c:00
eth1addr=92:16:c3:e7:1c:01

They were added after the first boot attempt.
Does IPFire add fake MAC addresses, probably to ease identification of network interfaces for the setup? or is this malicious behaviour?

Please let me know if that’s normal.
Thanks & Regards

[arne_f]

Yes. IPFire generate new MAC addresses at first boot because the SoC Serialnumber is not programmed and there is no MAC address eeprom on the OrangePi R1 Plus LTS.