---- On Wed, 14 May 2025 09:33:11 -0500 Florian Heigl <florian.heigl_at_gmail.com> wrote ---
> Hi,
>
> I have come across your distro totally by random - because there’s an article that says you got donated a CN7800 Dev Board!
Correct.
> Are you already using it or is it still waiting on the shelf?
It's in storage waiting to be set up.
> 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)
That is unfortunate, but it is the reality of the situation.
> 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.
Possibly. Would you be able to do your work remotely or would you need physical access?
> 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 will need to double check what accessories we have and what the documentation says.
> 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.
Good.
>
> Did your board include the SDK, too?
> Did you get any board documentation?
We (well, specifically I, personally, not the distro) have an NDA with the company and have received all of the relevant documentation. Obviously I need to play by the rules here and cannot share anything that is covered by the agreement. My goal was to bring up the board and then for us to use it as a builder, which is distro-agnostic.
I will emphasize that they are very strict about this, even though it is a legacy board, and it took quite some effort to acquire this.
>
> Marvell has never responded to any inquiries I sent them, so I couldn’t get a newer SDK, Octeon Simulator or anything else.
This is the reality, sadly.
> 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)
I *may* be able to answer specific questions about this but I would assume most of it (whether in code or documentation) is covered by the NDA.
If you are not able to acquire that yourself, unfortunately there may not be much we or I can do to help.
> 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.
We can discuss this.
> 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.
Makes sense.
> 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.
OK. My main concern is accidentally bricking the board since, as you said, it is not easy or cheap to replace, and I do not know if there is a robust or reliable way to re-flash the necessary pieces. I assume it is low risk but one can never be too careful.
> 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)
We would greatly appreciate any and all help in the mips64 groundwork.
>
> 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.
Let's be in touch about it. You can email me personally about it or find me on IRC, 'zv' on Libera, OFTC, and Interlinked.
> Otherwise if you’re already working on the mips port, lets just share patches or whatever and double the speed :-)
No one is actively working on it. I am traveling, looking for additional employment, and writing two books.
> If you can tell any errors with the order I’m gonna try things,
Seems reasonable. I would recommend trying to get the NDA because that will make it possible for us to easily collaborate, and get you the information you need. Without it, things will be more difficult.
There may be another option, which is for me to hire you as a contractor, but I'd rather not do the paperwork if I don't need to.
Zach
Received on Wed May 14 2025 - 17:00:21 CEST