Hardware Enablement

FOSDEM Video Box

A bespoke HDMI capture device for conferences.
A bespoke OSHW HDMI video capture solution is being developed for use at FOSDEM and other open source conferences. This talk will explain the what, why, how and hopefully when.
FOSDEM is unique in that it has 750+ talks on two days, with more than 28 parallel tracks. All are captured and streamed out live, and a sanitised version of each talk is re-encoded for separate viewing after the event. For each track, there are (at least) two capture boxes, one for the speakers' laptop (which also feeds the projector), and at least one for a camera. This means FOSDEM has close to 60 video capture boxes deployed. The FOSDEM video boxes are also used at several other conferences, and we are in active contact with several more, as each conference basically has the same problem to solve, albeit at a smaller scale than FOSDEM. Today, our capture boxes are an amalgamation of many different devices tied together, and while the whole is working surprisingly well, it is far from ideal. Some bits are non-free, some bits are hard or even impossible to control, and the result is bulky and, relatively speaking, expensive. Sourcing the exact same components again to expand the current array of boxes is nigh impossible, and the bulk of these boxes means that deployment is more of a hassle than it could be. To solve almost all of our issues, we are creating a bespoke HDMI capture solution by tying a HDMI-to-parallel-RGB decoder chip to the camera input of the venerable Allwinner A20 SoC. The Allwinner A20 was chosen due to its feature set, large community (linux-sunxi), its advanced upstream support and the availability of OSHW board designs. We were lucky to find a suitable board in the Olimex Lime2 (which is OSHW), which exposes all the necessary IO pins on pinheaders. Capturing 1280x720@50Hz, encoding it to h.264 for local storage and streaming over the network, while displaying the captured frames directly to HDMI or VGA (projector) and a status LCD, while also capturing (and passing through) audio is a challenge on this cheap, low power but open hardware. It forces us to make use of a wide array of SoC HW blocks, not all of which previously had driver support, and we are close to saturate the available memory and bus bandwidth. So while a good part of this talk is about describing the bigger problem we are trying to solve, this project very much is an issue of hardware enablement.

Additional information

Type devroom

More sessions

2/2/20
Hardware Enablement
Fabien Chouteau
K.4.401
For embedded developers using alternative programming languages, but also for anyone using third party driver frameworks such as libopencm3, one of the main pain points to start using a microcontroller is to make a Board Support Package. Things like linker script or startup code (crt0) not only require skills, but also information that are not always easily accessible. In this talk we will present a tool that generates linker script, startup code, and low level hardware binding for 3000 ARM ...
2/2/20
Hardware Enablement
Anton Kuzmin
K.4.401
An approach to challenges of an on-FPGA debugging of IP cores based on free software tools is demonstrated. Various aspects and related problems of an on-hardware debugging are presented along with the tools to address them, such as OpenOCD, sigrok/PulseView, GHDL, etc. Real-life working configuration and missing bits of software are accompanied by the live debug session demo running on Open-source Hardware.
2/2/20
Hardware Enablement
Mario Behling
K.4.401
While it is standard to deploy every single code commit using CI systems and deploy new code automatically we are only at the beginning of automation for designing hardware. In this talk I will share the experience with continuous integration tools in FOSSASIA hardware projects, and specifically our Pocket Science Lab. I will outline opportunities and challenges for implementing CI processes for hardware.
2/2/20
Hardware Enablement
K.4.401
We talked extensively about LinuxBoot, a Linux-based environment intended to be integrated into the firmware on the boot ROM. This time we want to talk about how do we test LinuxBoot before it goes to production. We will talk about ConTest, an open-source continuous and on-demand system testing framework that we designed to be modular, validating, and infrastructure-agnostic, and how it is helping us validate open source firmware on our datacenter platforms.
2/2/20
Hardware Enablement
Drew Fustini
K.4.401
Want to run Linux with RISC-V on Open Source Hardware? This talk will explore the current options including how open source FPGA tools can be leveraged to build open Linux-capable systems.
2/2/20
Hardware Enablement
Philipp Klaus Krause
K.4.401
The Taiwanese company Padauk makes small 8-bit microcontrollers, the smallest of which are available at 0.01 € even in small quantities. Even the larger ones are just a few cents; a particularly interestign feature is the hardware multithreading support available in larger devices. Until recently, the only available toolchain was Padauk's non-free toolchain based around their "MINI-C" IDE (which despite, the name, ist just a bit of C-like syntactic sugar coating for assembler, and in no way a ...
2/2/20
Hardware Enablement
Michał Żygowski
K.4.401
The presentation is about AMD's involvement in coreboot evolution and development. Gives a high-level overview of the engagement of the silicon vendor in the coreboot project history. The presentation may contain a little bit of technical aspects of firmware and BIOS. However, the intended audience is not only firmware and BIOS developers, but also free and libre hardware enthusiasts too. If anybody is interested in the future of famous platforms like Asus KGPE-D16, Lenovo G505S, PC Engines ...