I learned circuit design and went from not knowing what a ground plane was to having an 8 layer board working in three years.

https://GitHub.com/oro-os/link

It probably wouldn't hold up super well to professional scrutiny but everything on it works.

I would not have been able to do it without companies like JLC. It made an entire industry approachable, which is old fashioned 'good business' IMO.

▲

jacquesm 2 days ago | parent | next [-]

I absolutely love your project and I hope it will become a breakout success. It has all the right components for a computing environment that is not controlled.

Have you thought about RISC-V implementations of the kernel as well (iirc you're on ARM and on x64)?

▲

junon 2 days ago | parent [-]

Thank you! I'm working on a refactor of the kernel now that has all three, yes :)

	▲	jacquesm 2 days ago \| parent [-]
		Oh, it only gets better. Thank you so much. If you ever get to the point where you have something ready to order please drop me a line (mail in profile) and I'll buy one set to evaluate and if it works well I will get some more people on it.

▲

Teever 2 days ago | parent | prev [-]

Can you talk more about the design of the board?

Also, what's that large five pin connector in the bottom left for?

	▲	junon 2 days ago \| parent [-]
		The board is part of the CI pipeline for the OS. The kernel is built in the normal CI pipeline, unit tested, etc. then platform-specific images are built. Those are picked up by GitHub CI runners (could be anything but I'm using GH for now) that pull those image artifacts and send them over the internet to the board, which stores them on the microSD slot. Then the board will boot the device-under-test (either by enabling a USB VBUS line, asserting PS_ON and pressing the power button, whatever the device needs) and will serve the image either a via USB mass device or by switching on access to the microSD card directly via a ribbon connector/custom microSD PCB and ribbon cable. The kernel then communicates over serial back to the Link, which proxies that back up to the CI runner for evaluating test runs, etc. Everything is configured using MQTT and mDNS. Using async Rust via Embassy for the firmware. 5-pin on the bottom left is for power - 5V 2A 'always on' supply (on the ATX24 adapters that's the 5vsb line), 5V 3A aux line (for VBUS, optional and not otherwise used to power the board itself), a sense line for the aux power (board will shut down and display an error on over-current of the main line if not sensed), active-low aux line enable signal (PS_ON for ATX24 sources), and ground. This means that it's used to cut power on x86 machines, or to use a stock desktop PSU even for arm/riscv dev boards. In the future I want to make this all rack mounted and have a dedicated power supply for multiples of these.