It’s less interesting than you might think XMODEM isn’t a part of the product, it’s merely what we’re using to get images loaded into RAM over UART to be able to quickly iterate on host OS development (i.e., obviating the need to drop a payload into SPI NOR) – so it was really a question strictly of expedience. If you’re curious about what is in the product, I went into some of the details of what we’re building (and why) in my recent talk on engineering towards holistic systems.
Sounds very familiar. For software work on the early CHERI prototypes, the easiest way of loading a kernel was via the JTAG interface (which actually injected instructions to materialise a constant value and then write it into memory at a specific address into the pipeline) and then use JTAG to set the PC value to the kernel entry point. No loader, no filesystem, no system firmware even, just a debugging interface that splatted data into memory and poked the register file.
I sometimes miss this on more production systems. Being able to just take a kernel image and run it with no supporting infrastructure was great for iteration.
The Arduino folks have had lots of problems with FTDI USB->serial adapters on different platforms, and solutions for them. The official drivers are pretty bad. Another big problem is that a TON of FTDI chips are just counterfeits and don’t work very well. I’m assuming Oxide doesn’t have this issue in their lab, but maybe their customers will have it.
Totally agreed on FTDI driver quality and the counterfeit problem. Fortunately, our customers never need to connect via serial port: all of the management is via the dedicated management network.
I thought you were just complaining about a mild gray on white, but wow, this failed AA contrast requirements! The only parts that passed were in code blocks and the site’s name!
I’d love to have been a fly on the wall when Oxide engineers decided to make their sleds read their initrd using XModem
It’s less interesting than you might think XMODEM isn’t a part of the product, it’s merely what we’re using to get images loaded into RAM over UART to be able to quickly iterate on host OS development (i.e., obviating the need to drop a payload into SPI NOR) – so it was really a question strictly of expedience. If you’re curious about what is in the product, I went into some of the details of what we’re building (and why) in my recent talk on engineering towards holistic systems.
Sounds very familiar. For software work on the early CHERI prototypes, the easiest way of loading a kernel was via the JTAG interface (which actually injected instructions to materialise a constant value and then write it into memory at a specific address into the pipeline) and then use JTAG to set the PC value to the kernel entry point. No loader, no filesystem, no system firmware even, just a debugging interface that splatted data into memory and poked the register file.
I sometimes miss this on more production systems. Being able to just take a kernel image and run it with no supporting infrastructure was great for iteration.
The Arduino folks have had lots of problems with FTDI USB->serial adapters on different platforms, and solutions for them. The official drivers are pretty bad. Another big problem is that a TON of FTDI chips are just counterfeits and don’t work very well. I’m assuming Oxide doesn’t have this issue in their lab, but maybe their customers will have it.
Totally agreed on FTDI driver quality and the counterfeit problem. Fortunately, our customers never need to connect via serial port: all of the management is via the dedicated management network.
The website is unreadable due to its low contrast design, but fortunately Reader Mode works fine.
I contacted Matt and he adjusted the design a bit.
Thank you, it looks significantly better at least to me.
I thought you were just complaining about a mild gray on white, but wow, this failed AA contrast requirements! The only parts that passed were in code blocks and the site’s name!
Nice illustration of how even seemingly simple and low-level things are quite intricate.
I think that that’s our unofficial slogan at Oxide…
YMODEM (with 1K blocks, CRC and filename/size in packet 0) is a huge improvement.