I just receive my replacement device as my build was dead.
I will start building it again on native aarch64 device.
Hopefully this weekend.
Thank you.
UPDATE:
Had put it to build last night and now it have completed took approx 16 hours and 46 minutes to complete.
Now I can start looking into device specific kernel package while have the uboot image to flash but I need to know how the ipfire boots after the uboot is read by the device.
I will flash an image of aarchc64 on sd card and see whats inside the boot partition.
Update2:
Linux Kernel 4.14 have support for RK3328 already so we just need to add rockpie overlay to it.
I have created a gist for now, I can test the uboot while kernel we have to do it together alone with ipfire configs. Here is the gist for patches for kernel 4.14 and mainline uboot.
Can anyone from ipfire look into the patch I have got ready for 4.14 @ms or @arne_f, Just let me know how I can add it to the existing kernel build for ipfire then I can get it done from next time, I also have the mainline uboot patch ready.
Please check and let me know if there is anything more needed to add rockpie support.
That sounds good. But please follow this to submit any patches for review:
That way, we have a proper papertrail on our mailing list, everyone from the development community is involved and our tools automatically pick up the patches from the list and make them easier to merge.
I am looking into ways to push the patch, I have found where to place the uboot patch but not sure about kernel patch location, I will look into it further as I get time on the weekend.
To test the build i tried using rockc64 dtb as it is a similar device like RockPiE except this one have 2 onboard lan. I used the correct uboot image and flashed it over the sd card.
Now It does boot into the image but fails to load the kernel.
Log below.
INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9
U-Boot 2020.04-1 (May 22 2020 - 13:38:59 +0000) Manjaro ARM
Model: Pine64 Rock64
DRAM: 1022 MiB
PMIC: RK8050 (on=0x40, off=0x00)
MMC: rksdmmc@ff500000: 1, rksdmmc@ff520000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial@ff130000
Out: serial@ff130000
Err: serial@ff130000
Model: Pine64 Rock64
Net: eth0: ethernet@ff540000
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
2915 bytes read in 3 ms (948.2 KiB/s)
## Executing script at 00500000
Loading Linux 4.14.184-ipfire ...
error: invalid magic number.
Loading initial ramdisk ...
error: you need to load the kernel first.
Press any key to continue...
I have few other questions regarding the default aarch64 image that was created after compiling from source.
Update:
I see that there is hardcoded boot.cmd for few devices, I will have to understand how the loads the dtb and kernel from there.
Why can’t we use extlinux.conf as it is much better then boot scripts for individual devices.
Normal this script parse some variables from u-boot environment. The hardcoded variables are only some quirks.
because some soc’s like the RPi can only boot from fat32 partitions. (also efi must on a FAT partition)
We ship an uncompressed aarch64 kernel image because the old u-boot has a bug to detect the compressed image. Maybee this is now fixed and the new u-boot need the compressed one.
I get it booted up on my arm64 marvell espressobin v7 :
Marvell>> usb reset
resetting USB...
USB0: Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Marvell>> fatload usb 0:1 $fdt_addr /dtb-4.14.196-ipfire/marvell/armada-3720-espressobin.dtb
reading /dtb-4.14.196-ipfire/marvell/armada-3720-espressobin.dtb
7400 bytes read in 28 ms (257.8 KiB/s)
Marvell>> fatload usb 0:1 $kernel_addr vmlinuz-4.14.196-ipfire
reading vmlinuz-4.14.196-ipfire
17601024 bytes read in 257 ms (65.3 MiB/s)
Marvell>> setenv bootargs $console root=/dev/sda3 rw rootwait
Marvell>> printenv bootargs
bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/sda2 rw rootwait
booti $kernel_addr - $fdt_addr
I have manually get networks up :
[root@ipfire ~]# ip link set eth0 up
[root@ipfire ~]# ip link set lan1 up
[root@ipfire ~]# ip link set wan up
[root@ipfire ~]# ip link set dummy0 up
I am able to ping from lan1 :
[root@ipfire ~]# ping 10.4.2.1
PING 10.4.2.1 (10.4.2.1) 56(84) bytes of data.
64 bytes from 10.4.2.1: icmp_seq=1 ttl=64 time=2.03 ms
64 bytes from 10.4.2.1: icmp_seq=2 ttl=64 time=0.747 ms
You can try to set ETH1ADDR= (Not exact sure about the syntax but if there is ETHADDR= it should correct) to a different mac address in uboot and run saveenv.
After this the setup should work correct.
For easier start after a kernel update you should try to load boot.scr and run it from the usb drive istead of manually load dtb and kernel. (but im not sure if the marvell uboot support all needed features but on older marvells this has worked.)
But from my OpenWrt box, there is only eth0 then wan/lan0/lan1 as subset of eth0 :
root@C3BOX:/# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc mq state UP qlen 1024
link/ether xx:yy:aa:bb:ab:2a brd ff:ff:ff:ff:ff:ff
3: wan@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-wan state LOWERLAYERDOWN qlen 1000
link/ether xx:yy:aa:bb:ab:2a brd ff:ff:ff:ff:ff:ff
4: lan0@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-LAN0 state LOWERLAYERDOWN qlen 1000
link/ether xx:yy:aa:bb:ab:2a brd ff:ff:ff:ff:ff:ff
5: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-LAN1 state UP qlen 1000
link/ether xx:yy:aa:bb:ab:2a brd ff:ff:ff:ff:ff:ff
Ok. Than this is different. Then you are forced to hack this manually because the setup need different mac’s. Did you know how this is implemented. For me this looks like a VLAN Switch but i dont see any VLAN ID’s in the config.
Hello,
Finally I have recieved my replacement device of Nanopi R2s
So now i have 3 boards which see potential device to have ipfire for.
Also the fact that now I have another device to build packages i can dedicate a device for ipfire pkg building and it have enough storage on emmc so I don’t have to worry about storage issue while compiling.
Update:
Checking Logfiles for new Files
*** Build finished in 19:32:13 [ DONE ]
Logs
It took 19 hours to build aarch64 image
I have been trying to make it boot but It is resetting the board after grub. Used mainline uboot for the board.
RockPiE3 = RK3328 board with 1gb ram. The first issue is that the uart log is not clear so I am not able to understand what is causing the reboot.
Finally switch uart and not I can read but it is getting stuck at kernel and I think it is cause of baudrate difference
U-Boot 2020.10-1 (Oct 14 2020 - 10:55:00 +0000) Manjaro ARM
Model: Pine64 Rock64
DRAM: 1022 MiB
PMIC: RK8050 (on=0x40, off=0x00)
MMC: mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from MMC... Card did not respond to voltage select!
*** Warning - No block device, using default environment
In: serial@ff130000
Out: serial@ff130000
Err: serial@ff130000
Model: Pine64 Rock64
Net: Could not get PHY for ethernet@ff540000: addr -1
No ethernet found.
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
245 bytes read in 3 ms (79.1 KiB/s)
1: Manjaro ARM
Retrieving file: /initramfs-4.14.208-ipfire.img
7465912 bytes read in 170 ms (41.9 MiB/s)
Retrieving file: /vmlinuz-4.14.208-ipfire
17644032 bytes read in 397 ms (42.4 MiB/s)
append: initrd=/initramfs-4.14.208-ipfire.img console=tty1 console=ttyS2,1500000 root=UUID=52066f7b-5e0a-4ac5-9b5f-ae98c6785ad6 rw rootwait
Retrieving file: /dtb-4.14.208-ipfire/rockchip/rk3328-rock64.dtb
32046 bytes read in 5 ms (6.1 MiB/s)
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
Loading Ramdisk to 3d814000, end 3df32bb8 ... OK
Loading Device Tree to 000000003d809000, end 000000003d813d2d ... OK
Starting kernel ...
The baudrate should not the problem if you have set this via console=ttyXX,baudrate IPFire should use the configured rate.
Don’t set console= twice. The IPFire initskripts try to detect if it should use serial or video by this parameter. I’m also not sure if ttyS2 is the correct serial console. I think it was ttyS0 on my R2S but im not sure.
Yes I think your right, i will make some more changes and I will have to use the accurate dtb for my boards.
I will fetch dtb from official image and reuse it over ipfire image for testing and see if I can get ipfire to start if that works then it will me a simple fix with dts patch of their device.
Secondly, I would like to propose to move all devices to extconfig to make booting process very simple and easy to maintain, as most of the devices are already supported by mainline linux and it can read extlinux where we can define all the parameters for boot which can look grub.
Let me know your thoughts on extlinux idea, as maintaining boot script for devices is alot of work.
I was able to pass the issue which was the board getting stuck at Starting kernel it was for to missing config for rockchip boards.
Now it seems to fail with mmc initialisation as I assume it is due to difference in the dtb. To solve this I will have to patch the kernel with the right dtb which is my next step maybe during this weekend.
I have also received Rock64 to cross verify my builds as the default kernel have rock64 dtb present so it is easier to test.
We should be getting more support for arm64 boards in 2021.
Because some workarounds that were necessary for the espressobin seem to be more generally useful for a universal image that can boot on different devices and from different media, I link the topic from here:
I tried to boot on rock64 and it seem that the sdcard is not visible to the linux kernel so I assume I must have missed a config for the rk sdmmc in the kernel.
I have asked for help from the rockchip developer, I will try to rebuild the kernel once I receive some response from them.
