Re: odroid hc1 on debian?
On Wed, Nov 01, 2017 at 02:28:12PM +0100, Andreas Jellinghaus wrote:
> 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?
Getting "regular" (i.e. tianocore-based) UEFI onto common SBCs is
probably unrealistic. There is work in progress to implement the
UEFI boot protocol (but not the UEFI runtime services) on top of
u-boot, so that it is possible to use u-boot to start an UEFI-grub.
That doesn't solve the issue that one still needs a hardware-specific
u-boot build for each system; it only helps unifying things at a
higher level.
> 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.
That addresses a somewhat different field and is still based on
a (stripped-down) UEFI implementation.
> 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?
There may be somwhat of a confusion about the term "firmware" here.
The linux-firmware repository is AFAIK for peripheral device
firmware, i.e. for code that doesn't run on the main CPU but on the
embedded controllers in devices like graphics cards or network
adapters and gets loaded into these devices by the Linux kernel. In
case of the HC1, the blobs in question are ATF (Arm Trusted
Firmware)/TrustZone components that run on the main CPU and are
executed before Linux is even started. They are firmware as well,
but a different kind of firmware.
> 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?
It takes care of creating a proper boot environment (e.g. updating
boot scripts, wrapping the kernel and the initrd into uImages on
platforms where that is required, writing the kernel to NOR flash
on platforms where that is necessary, etc.) on kernel installation
and upgrades.
> DONE: it contains a odroid-xu4 entry, that would work on the hc1 too.
Vagrant mentioned that there seem to be differences between the XU4
and the HC1 and that a separate HC1 device-tree has been submitted
for kernel 4.15. If that new devicetree gets used, a corresponding
entry in the flash kernel machine database will become necessary.
> 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?
The debian-installer team maintains this.
For the source code and build system, please refer to
https://wiki.debian.org/DebianInstaller/CheckOut
> Does that place allow non-free binaries in the image
No, debian-installer is main-only.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: