Re: odroid hc1 on debian?
On Fri, Oct 06, 2017 at 07:26:39PM +0200, Andreas Jellinghaus wrote:
> Thanks, "network-console" sounds like what I want. But if it
> contains the debian-installer: does it have a special mode for
> this setup?
>
> A traditional install has two medium: one source medium (dvd,
> cd, usb-stick) and one target medium (hard disk, ...). But
> here the microSD card with the image would be both the place
> where the install image was written, and the place of the final
> installation too. If debian-installer is not designed to
> handle that, I could check out debootstrap or similar to create
> a "final" setup.
The installer handles this case well :-). At the point at which
it starts partitioning and formatting the installation target,
all components required by the installer are already in RAM, so
it is no problem to overwite the SD card from which the installer
had originally been loaded.
> The odroid HC1 is a stripped down odroid XU4, thus if the later
> has a device tree, it should work for both.
That depends very much on how exactly that "stripping down" has
happened. It may well work, but it doesn't necessarily have to,
and using a wrong device-tree could in theory even cause hardware
damage (for example by using wrong voltage regulator settings).
I wouldn't try running a device-tree for another board without
first making definitely sure that they are compatible.
> You are right about the blob for uboot, I had forgotten about that.
>
> https://github.com/hardkernel/u-boot/tree/odroidxu4-v2017.05/sd_fuse
> that repo has the binaries and a script to fuse them with uboot.
Ok, so that unfortunately means that there is no way for Debian
to provide official bootable SD card images for this platform.
> back to technical details:
> if the result is just prepending before boot binary, that would be
> inconvenient, but easy enough to do.
>
> So what is the next step? does debian-arm compile a uboot binary for each
> target plattform? a kernel?
Debian has a separate u-boot binary for every platform as u-boot
is always platform-specific. U-Boot isn't only a bootloader like
GRUB but also provides BIOS-like functions (e.g. setting up the
DRAM controller and providing PSCI callbacks to the kernel, which
is highly hardware-dependent). The kernel itself is generic;
the platform-specific information required by the kernel is in
the device-tree file.
> What would be good next steps? I have several of these small
> boards, so I can boot one with armbian and also experiment with
> booting one or several with debian and compare things.
I think the best way would be to get a serial console cable for
the board so that you can interact with u-boot and see debug
output. You could then start with the "generic" netboot installer
SD card image (which contains the kernel, the device-trees and
the installer, but no u-boot) and try adding a proper u-boot and
device-tree for your platform to it. Once this works, you could
then move on to trying it with the net-console variant.
To get the "generic" image, run the following steps:
$ wget https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/partition.img.gz
$ wget https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/firmware.none.img.gz
$ zcat firmware.none.img.gz partition.img.gz > SD_card.img
Note: today's daily image build has failed due to a kernel
upgrade in unstable that needs adjustments in the installer
source code; I'm just in the process of addressing that, so
please wait until tomorrow before trying it out ;-).
> If I could get debian to the point where a user running linux
> (e.g. desktop/amd64) could install a debian image (all free
> software), and then overwrite those special sectors with the
> cpu vendor blobs, to get a working system - that would work for
> me. Thoughts?
As long as the location of the proprietary bootcode for the Exynos
doesn't conflict with our standard partition layout, that should
work.
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: