[Arm-netbook] device tree not the answer in the ARM world

[Ken Phillis Jr]

On Mon, May 6, 2013 at 10:25 AM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> mark, thank for this.  i'm bringing lkml back in [my decision] but
> just this once as i believe the point's now been made.  i'm also
> leaving it below [top-post style] as it's background, as well as
> standing on its own merit.
>
> i was under the impression that device tree had been declared
> successful on power-pc [and wasn't aware of SPARC], so a reality check
> is much appreciated.  in effect what you're saying is that the
> standardisation through things *other* than device tree - i.e. there
> wasn't so much of a problem of diversity in the first place [*1], and
> this in turn means that device tree could be declared "more"
> successful.
>
> in other words, once again, the link between the original purpose for
> which device tree was invented [solve the ARM hardware diversity /
> proliferation problem] and its actual success in achieving that
> purpose is demonstrated to be at best an assumption and at worst a
> failure [in the ARM world].
>
> that there are *other* successes - incidental to its genesis - that
> device tree has solved is fantastic, but completely beside the point.
>
> so the question becomes - unless someone can demonstrate that device
> tree has or can solve the [ARM hardware diversification] problem and
> nobody has so far - what *can* solve the problem of massive hardware
> diversity [both SoCs and peripherals] in the face of pathological
> corporate behaviour that i've outlined over the course of the past few
> messages?
>
> l.
>
> [*1] for many reasons - not least but most obviously as mark clearly
> points out: there aren't that many peripherals to support!!!
>
>

I know that Hardware Trees may not help. However I did mention UEFI
[1] a while back. I believe that UEFI offers a longer term solution
that will allow Linux ( and possibly other operating systems) to offer
better support for all-in-one kernel packaging.

As for already supported platforms on UEFI, I know that the Beagle
Board [2][3] and the Samsung Origen [4] both offer support for UEFI
Directly. The only issue is that I do not know if is that Linux does
not offer UEFI/EFI for ARM devices, however Linux does support
UEFI/EFI with x86/x86_64 based systems. [5]
 Also, I do know that there is a ArmPlatformPkg module found in
TianoCore that can offer some insight in porting UEFI to any given ARM
device [6].



[1]  http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
[2] Short description of the UEFI usage on the Beagle Board.
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=BeagleBoardPage
[3] Longer description of UEFI on the Beagle Board.
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Beagle_Board_Wiki
[4] Samsung Origen documentation
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=SamsungPlatformPkg
[5] UEFI Documentation - ArmPlatformPkg
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatformPkg

[6] Kernel Documentation on booting:
For X86/x86_64:
=================================================
Title: The EFI Boot Stub
File: Linux/Documentation/x86/efi-stub.txt

Title: General note on [U]EFI x86_64 support
File: Linux/Documentation/x86/x86_64/uefi.txt

Title: THE LINUX/x86 BOOT PROTOCOL
File: Linux/Documentation/x86/boot.txt

For ARM/ARM64:
=================================================
Title: Booting ARM Linux
File: Linux/Documentation/arm/Booting

Title: Booting AArch64 Linux
File: Linux/Documentation/arm64/booting.txt


> On Mon, May 6, 2013 at 3:06 PM, Mark Morgan Lloyd
> <markMLl.debian-arm at telemetry.co.uk> wrote:
>
>> [Grimace] DeviceTree works up to a point on SPARC and PPC Macs, where there
>> is a limited number of peripheral device types and (in general) they're
>> described by published data. Part of that success though is because these
>> machines also expose a standardised UI (OpenPROM or whatever you want to
>> call it) which developers can use for manual enumeration and debugging and
>> which the kernel can use provided that it gets the calling convention right
>> (I've seen a firmware change on SPARC break the kernel).
>>
>> Leaving aside the more esoteric peripherals (sending morse using a camera
>> flash LED or whatever :-) there are at least t^Hfour problems:
>>
>> i)   There's no standardised interface to get at the configuration.
>>
>> ii)  It's not self-describing, particularly in the case of GPIO-attached
>> peripherals.
>>
>> iii) It's no replacement for enumerating PCI-attached peripherals.
>>
>> iv)  It's no replacement for enumerating chips on a JTAG loop.
>>
>> Put another way, Cory Doctorow's "InstallParty" software isn't even science
>> fiction: it's pure fantasy, and is likely to stay that way.
>>
>> --
>> Mark Morgan Lloyd
>> markMLl .AT. telemetry.co .DOT. uk
>>
>> [Opinions above are the author's, not those of his employers or colleagues]
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-arm-REQUEST at lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmaster at lists.debian.org
>> Archive: http://lists.debian.org/km8de1$mel$1@pye-srv-01.telemetry.co.uk
>>
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk