<hurricos>
Hey stintel: I don't believe I ever did for sure
<stintel>
oh :(
<hurricos>
I would strongly recommend looking at other utilities in the SDK.
<hurricos>
Obviously the console "works", insofar as all of the other utilies can send or redirect commands to the device's console
<hurricos>
even liquidio can do it for sure. But it really should be rewritten cleanly
<stintel>
I've now 2 SNIC10E-G in my test box, unfortunately the NAND driver is ancient and will need some refactoring for 5.10
<hurricos>
(bleh!)
<hurricos>
They're not crashing your test box too often?
<stintel>
just pushed fixes for the SPI NOR and added uboot-envtools + /etc/fw_env.config
<stintel>
I don't recall if it ever crashed my test box
<stintel>
ah, I also had to massage the SDK a bit to get stuff to build on a musl host :P
<hurricos>
Your *host* is running OpenWrt?
<stintel>
no
<Habbie>
why not?
<Habbie>
:)
<stintel>
Habbie: if I need to be compiling stuff on the host, I rather have a general-purpose distro
<stintel>
with gcc only being available in the packages feed ... nuff said
<Habbie>
ack, i was kidding, although i was pondering a general-purpose distro on docker on openwrt last week ;)
<stintel>
that's a minefield I don't want to step into
<Habbie>
i tried just running some regression tests on openwrt a few weeks ago, it was a major pain
<Habbie>
(i did not succeed)
<hurricos>
Unfortunately a lot of the glue that makes containers 'n' stuff work just isn't there for OpenWrt. Hugely systemd
<stintel>
systemdisease :)
<hurricos>
Not saying not to fight the good fight. The problem is that people (like me) give up before they succeed.
<Habbie>
i never missed systemd when doing things with containers
<Habbie>
(and i miss systemd plenty, although procd seems decent)
<hurricos>
I'm right now struggling with the MX100 not having ports deterministically named
<hurricos>
Or not *declaratively* named, anyways. OpenWrt completely non-mac80211 device naming, expecting the kernel / (procd?) to handle it, but there isn't even a config element in /etc/config/network for what I want
<hurricos>
s/but/so/
<hurricos>
stintel: try looking at octeon-remote-bootcmd
<hurricos>
wow, that is ugly. Never mind. It calls out to octeon-remote.c::octeon_remote_send_bootcmd which dives directly into writing into memory on the Octeon device at 'BOOTLOADER_PCI_READ_BUFFER_DATA_ADDR'
<stintel>
lol if I add console=ttyS0,115200 console=ttyS1,115200 to cmdline I get duplicate output
<hurricos>
@neggles: oh, hey! How is the performance? Still based on stintel's Linux tree, yes?
<Slimey>
lols
<hurricos>
stintel: That's strange. I thought ttyS1 mapped to the unpopulated headers near the LED / bracket.
Borromini has quit [Quit: leaving]
philipp64 has quit [Quit: philipp64]
<hurricos>
@stintel: I imagine you're also using the oct-remote-console binary shipped with the repo? Have you tried recompiling it?
<stintel>
hurricos: I have to recompile everything, remote-lib borks on musl and doesn't detect the octeon devices
<hurricos>
Oh, but other things work post-recompilation?
philipp64 has joined #openwrt-devel
<stintel>
hurricos: yes, I can boot/load/bootcmd
<hurricos>
I'm realizing I've forgotten more than I wanted to. I certainly recall having oct-remote-console work for U-boot based on a re-compiled U-boot sent via oct-boot. However, that sotps working as soon as Linux loads.
<stintel>
yeah, and it boots OpenWrt, so you can make a 10GbE router with it in theory
<Habbie>
right
<Habbie>
reminds me of that person who booted linux on their WD SATA drive
<stintel>
but the SPI NOR is too small
<Habbie>
not from
<Habbie>
-on-
<stintel>
but the early revisions of the card have NAND as well
<stintel>
and that's what I'm trying to access nwo
<Habbie>
the day you realise that your computer is a network of devices, some of which allow you access to farther away network of devices, is a magical day
<stintel>
:P
floof58 has quit [Ping timeout: 480 seconds]
<neggles>
hurricos: yep :) I have some hope that my concept of “router/firewall hiding in the NIC” might actually be achievable
<neggles>
it’s also an LFS file so that link won’t work oops
<hurricos>
neggles: yeah, but not versioned :(
<hurricos>
I guess you could unpack and commit each dump in sequence.
<neggles>
i have considered doing that, starting with the 5.1 full SDK release
<hurricos>
s/versioned/directly in git/. Just makes observability harder is all.
Tapper has quit [Ping timeout: 480 seconds]
<neggles>
yeah it’s because it’s just the tools/ directory from the full SDK; I’m still trying to twist their arm for the full SDK matching that version
<neggles>
but yeah, I might just extract the tools releases one by one and commit them on top of the 5.1 SDK, then do the same with the kernel sources I’ve found from various versions / vendor gpl tarballs; not sure how useful it’ll be 🤷♂️
<hurricos>
And while the hardware has XAUI to interact with SFI (for your SFP+ modules), the CPU is very weak. You need to be using the Cavium-specific packet handling hardware to get any real performance
<hurricos>
Even so much as passing packets through the standard OpenWrt firewall chain is limited to ~1-2Gbps.
<hurricos>
This ignoring the fact that the card draws 30W constantly :grimacing:
<neggles>
yeah, the offload / acceleration binaries from EdgeOS 2.0 on an ER-6 should work - same chip generation, just less cores
<hurricos>
well, when you say "work" ....
<neggles>
it’s just netfilter plugins and I actually have source for some of it
<neggles>
¯\_(ツ)_/¯ what I really want is a nVidia/Mellanox BlueField 2, but they’re four grand (and even if I wanted to pay that, they’re unobtanium atm)
<hurricos>
'1345' is the bit that varies throughout the adapters -- earlier (e.g. 1337) has female connectors for serial, instead of male ones, etc. etc.
<neggles>
the other odd thing is that these cards shipped with backup bootloaders present, while liquidio adapters usually don’t have that, you have to set a register in the Vitesse PHY to invert the RX loss signal, and XAUI0 is connected to PHY1 / vice versus
<neggles>
(I checked the crosspoint registers, it’s not flipped inside the chip)
<neggles>
might be an idea to flip those 3 bits so int 0 = int 0
<hurricos>
neggles: Do you have a raw copy of the NOR hanging around anywhere?