[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: odroid hc1 on debian?



2017-11-01 13:51 GMT+01:00 Paul Wise <pabs@debian.org>:
I think once more devices switch away from u-boot to UEFI, it might
become easier.

are people in SBC community actively working on that, or is it just a possible option?

I learned about u-root a few days ago, an effort to implement all basic userland in go.
This resonated quite well with me, as the various tools written in python or perl seem to call into shell scripts to run c binaries in the end. Thus we end up with many languages mixed into one system. Only one seems simpler to me, and I happen to be a fan of golang.

> With D-I, live boot, debootstrap, multistrap, vmdebootstrap, vmdb2 and many
> other efforts in parallel however I'm lost and confused about the right
> direction.

I think most people doing installs on ARM just
debootstrap/qemu-debootstrap onto a filesystem they created manually.
vmdebootstrap is supposed to be obsoleted by vmdb2, but the latter
isn't packaged yet.

I'm looking into what I can do with vmdb2. Yet it seems to call into shell commands in the end, including debootstrap. Thus a nice layer on top, but not a new infrastructure.

In general the procedure to get an ARM device supported properly is
something like this (I'm probably missing some steps):

Upstream all patches for bootloaders (u-boot/TianoCore/coreboot/etc).

DONE: while there are more patches in the hardkernel u-boot repo, the current u-boot release in testing works good enough.

Upstream all patches for the Linux kernel.

DONE: Same: there might be more patches, but enough was upstreamed so the testing kernel works fine.
 
Upstream all patches for graphics drivers (Linux, libdrm, mesa etc).

DONE: odroid-hc1 is a compute node computer - network, sata, cpu, ram, serial console for debugging. No graphics (well, the CPU contains some GPU but no wires/connectors, thus supporting it is optional).
 
Open all firmware blobs (or upstream them to linux-firmware.git/fwupd).

TODO: I wasn't sure thus even send an email to debian-kernel: is linux-firmware repo only for firmware uses by the driver, or do they accept firmware for u-boot too? Is one big repo for everything the desired state or many small packages? Any blueprint? Any good legal direction to get odroid to do the necessary license declaration etc?
 
Add support for the device to Debian u-boot, linux.

 DONE: I used the testing u-boot (exynos), the odroid-xu3 binary works on xu4 and hc1 too.

Add support for the device to the flash-kernel database:

https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/db/all.db

ah, I didn't know about that one. What does it do, who uses this code?

DONE: it contains a odroid-xu4 entry, that would work on the hc1 too. 

Add support for d-i SD-card images (not sure where):

http://ftp.debian.org/debian/dists/testing/main/installer-armhf/current/images/hd-media/SD-card-images/
http://ftp.debian.org/debian/dists/testing/main/installer-armhf/current/images/netboot/SD-card-images/
http://ftp.nl.debian.org/debian/dists/testing/main/installer-armhf/current/images/u-boot/

TODO: yes, I'd love for those automated build mechanism to create an image for the odroid-xu4/hc1. Who maintains this system, where is the code or config?
Does that place allow non-free binaries in the image, or do we need to go to the cdimage.debian.org infrastructure instead? that one has non-free images:
https://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/

So the situation isn't bad, but when I started the thread a month ago I had the same questions above :(

Maybe I should try debian-users or debian-devel instead?

Andreas

Reply to: