SoPine SPI booting

[ayufan]

I pushed quite recent u-boot with sunxi and apritzel patches that allows to enable SD/eMMC/USB/PXE booting of SoPine.

This new u-boot can also be put on SPI to allow booting without SD/eMMC.

You can find sources and releases here: https://github.com/ayufan-pine64/bootloa...d/releases.

[hexalyn]

Great ! Looking forward to the clusterboard for PXE booted sopine clusters at home

@ayufan: As I lack knowledge related to kernel build and Linux builds for the SoPine, do you think it might be possible to "hack" the LinuxKit toolkit (https://github.com/linuxkit/linuxkit) and build SoPine compatible rootfs images instead of RPi3 images : https://github.com/linuxkit/linuxkit/blo...rm-rpi3.md ?

In this toolkit they use u-boot to start the RPi3 so I think we might even be able to adapt the process to boot from a ".img" image no ?

Thanks in advance

[ayufan]

Maybe. But I would look for 64-bit.

[aww]

So I am trying to use this SPI build with the new Sopine clusterboard and am having a ton of issues. It'll boot, and start looking to boot from dhcp, but it isn't connecting to the network(I don't even see a dhcp request come across when I tcpdump the upstream port). 

It works fine when a node is in the sopine baseboard, and I am also having networking issues with all images except your minimal xenial build. Things will boot, but they won't make any network requests.

[pfeerick]

So I am trying to use this SPI build with the new Sopine clusterboard and am having a ton of issues. It'll boot, and start looking to boot from dhcp, but it isn't connecting to the network(I don't even see a dhcp request come across when I tcpdump the upstream port). 

It works fine when a node is in the sopine baseboard, and I am also having networking issues with all images except your minimal xenial build. Things will boot, but they won't make any network requests.

I also have not been able to get the sopines to do either BOOTP or DHCP requests when in the clusterboard, but don't have a sopine baseboard to compare against. However, with the same test setup, but substituing a rock64 which will PXE boot, I see the requests come through just fine, on dnsmasq and tcpdump.

I'm trying to set up a pine64 as a DHCP+PXE master for the clusterboard. Testing for the DHCP/BOOTP requests using:

Code:

sudo tcpdump -i eth0 port 67 or port 68 -e -n

[hexalyn]

I have the same issue. I think it lies with the fact that there are network issues on the kernel side (as explained here : https://forum.pine64.org/showthread.php?tid=5712) and this has not been fixed in @ayufan u-boot build for now. I don't have enough knowledge to create a pull request or make a new build.

@aww Could you replicate the network fix here maybe : https://github.com/ayufan-pine64/u-boot-...i-a64.dtsi ?

That way we would just have to rebuild u-boot and use @ayufan's makefiles to recreate a new version working with the clusterboard ?
That would be awesome !

EDIT: It seems you already did it ! : https://github.com/andrewl3wis/u-boot-su...41e5603dd7

[pfeerick]

EDIT: It seems you already did it ! : https://github.com/andrewl3wis/u-boot-su...41e5603dd7

Nice! Now just have to work out how to get it onto the sopine modules!

[hexalyn]

@pfeerick : I managed to build the image using ayufan's scripts but with @aww u-boot version.
I do not have any sopine module at reach right now, could you try it ?

Here is the link to download my build : https://transfer.sh/OOvBr/u-boot-sopine-...spi.img.xz

It works the same as ayufan's as it was built in the same manner. Thanks !

[aww]

That's my attempts to get it working. I wasn't successful, but I was trying things late at night so might of missed something.


I think the root issue is that ayafan's fork(and u-boot upstream) are currently missing the patches for realtek network timing that are in Mainline. The reason that rgmii-txid works in Armbian looks like a side affect of another patch that adds the "magic" timing numbers in that someone got from realtek.

[hexalyn]

@aww I see... If I understand correctly, here: https://patchwork.ozlabs.org/patch/873752/ they patch mainline u-boot with the realtek stuff.
As I have seen, every modified file in this patch has the same "pre-patch" state as the files in your modified u-boot version.
Couldn't we juste apply this patch onto your repo if this is the realtek only patch ?

Thanks