Hi,
I have come across your distro totally by random - because there’s an article that says you got donated a CN7800 Dev Board!
Are you already using it or is it still waiting on the shelf?
I’ve been looking for one of those, or anything of the era because I’m porting Alpine onto some Cavium CN73xx/CN2360 „LiquidIO II" network adapters.
It’ll be a mips64-octeon-muslhf architecture or so. (I don’t even know)
One of the dev boards sold for a few 100 USD last year, but I missed that and the only other left to buy is around $5000.
(and no they don’t reply to more realistic offers)
I wonder if I could borrow your board for a few months and pay in naturals, meaning a few of the CN23XX NICs.
They’re dual port 10/25g, 16 Core, 8GB Ram, 2GB eMMC and dual SATA.
You could use them as builders like I’m also gonna do.
They need a fan and a PCIe host to boot them. (In theory, the latter is not true. I think they can boot without any PC attached, and it’s another thing I’m keen to try out)
I’m also setting up gitlab CI for the octeon SDK and of course I’ll make that CI config public so you’ll also be able to use it later.
It’s build against the SDK 5.1 and I got most of it working already.
Did your board include the SDK, too?
Did you get any board documentation?
Marvell has never responded to any inquiries I sent them, so I couldn’t get a newer SDK, Octeon Simulator or anything else.
It’s really cumbersome to work only with the NICs since there’s no board docs and I’m walking around blind when trying to figure out what they really support.
(i.e. can’t tell if they got certain offload engines)
If I could test on a dev board I could have some baseline to compare to, find out how the the CI needs to look like to have multiple builds etc.
The CI is currently in the state that I have a docker container image for wrapping the old SDK, and I got builds working for all the boot loaders, some examples, and am pausing till I can sort out non-interactive kernel config using make silentoldconfig or something.
So like a few weeks and it’ll run kernel builds and create bootable miniroot initrd.
After that I’m gonna go back to aports builds I think, and that would all be useable for you directly.
I’m first gonna rebuild 3.14/3.15 as hardfloat and with octeon2/octeon3 tuning.
From there I think the next step is going to use the upstream kernel (it seems most is in fact upstream now) and also jump forward with the u-boot version.
This is why I needed the CI since there’s so many variations as to watch which patch might be working / missing / incompatible.
Especially making sure no softfloat library gets linked in is a very special „exercise“.
Once U-Boot is current, I need to fix the fw_printenv/setenv tools and have a current kernel running with current musl/busybox/libftd.
Then, comes branching aports and cherry-picking the changes that removed alpine’s mips support, modify them from mips64 to mips64-octeon-muslhf or so, and then I can re-bootstrap my cards and use them to do massive parallel builds.
I’m not certain it will be more than a hobby port, I’ll see about upstreaming back to alpine once I got a working proof of concept (meaning, hard float, ramdisk support, current must version, gcc and ldd matching the right *-*-* tripe, able to boot a kernel-liquidio flavour with some kicking)
It’s honestly quite a few months of work since I’m not invovlved in u-boot, plus got some health issues that make this a topic i can only touch every odd month.
But I think most of my work will overlap with yours and, yeah, well, if you’re not on it already, I’d like to borrow that dev board if possible.
Otherwise if you’re already working on the mips port, lets just share patches or whatever and double the speed :-)
If you can tell any errors with the order I’m gonna try things,
Greetings,
Florian
Received on Wed May 14 2025 - 16:33:11 CEST