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

Re: odroid hc1 on debian?



On Thu, Oct 12, 2017 at 03:05:16PM +0200, Andreas Jellinghaus wrote:

> My understanding is: bl2 loads u-boot, and "720k" in the name
> indicates that it expects u-boot size to be that large. 

That sounds like a reasonable assumption given the layout
of the components.

> Smaller sizes padded with zero are fine.  The trustzone blob is
> expected behind u-boot, and the u-boot env after that one.  So
> it is one long chain of elements of fixed sizes, and having
> soom room in the u-boot part makes sense, as only the vendor
> can update those blobs, I suppose?

As the u-boot binary is a "user serviceable part" :-), it can of
course vary in size quite a bit depending on the selected
featureset (and even on the compiler used), so having some spare
space behind it definitely makes sense.  Regarding updating the
blobs: yes, they can only be updated by the board manufacturer,
and judging from the experience with other ARM-based systems
quite often even the board manufacturer doesn't get the sources
for the blobs and has to rely on the SoC manufacturer himself.

> One more question:
> on arm, is there any code in the first sectore side by side to the
> partition table?
> 
> I know x86 has the mbr code in it, some tiny code to scan the partition
> table for the first partition with the boot flag set, and then load the
> first sector of that partition.  Or some code that loads grub/lilo/... 
> from non-partition space.  Is arm doing the same or is arm firmware
> loading from sector 1+ of the boot device without code in sector 0?

The low-level boot process on ARM-based SoCs isn't standardized
as it is on i386/amd64-based PCs, so the area that gets loaded
and executed on cold boot varies quite a bit from SoC
manufacturer to SoC manufacturer.  As a rule of thumb there is
usually no code in sector 0 directly after the partition table on
ARM-based systems, but technically nothing would stop some
manufacturer from producing a SoC that loads its boot code from
there.

>     Does the XU4/HC1 work with a 3.3V cable or does it require
>     one of the rather rare (and expensive) 2.5V or 1.8V
>     models?  If a 3.3V cable is sufficient, send me a PM for a
>     resonably priced source in Germany.
> 
> The odroid usb-uart supports 1.8V-3.3V, so I guess it needs
> such a device.  Can't find one without a huge price tag and/or
> international shipping costs.

I have done some further research and it looks like the odroid
USB-UART module uses one of the four pins in the socket as a
voltage supply for the UART side of the USB-UART module.  The
CP2104 that is used on that module supports driving the UART side
from an "external" voltage supply pin instead of from the chips'
own supply voltage, which allows using it on boards with
different logic voltage levels as long as the board provides an
appropriate supply.  Some of the older odroid boards like the C2
seem to use 3.3V signalling, but according to some information
from the odroid wiki, the XU4/HC1 indeed seems to require 1.8V,
so using a "standard" 3.3V cable on the XU4/HC1 would probably
fry your board.

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: