Question about extension board used in U-boot

Question about extension board used in U-boot

[Ying-Chun Liu (PaulLiu)]

[-- Attachment #1.1: Type: text/plain, Size: 1711 bytes --]

Hi all,


I have some questions about how to implement extension board usage.
My case is on imx8mm-cl-iot-gate. It can add three different types of
extension boards.
One of the extension boards is SPI extension which have 3 empty slots.
And you can add
some small boards onto it. One of them is a "TPM2" module.


My first question is if I want to use tpm2 in U-boot for measured boot.
How to implement this right? Currently I just modify the dts used by
U-boot to let it drive
the extension board. And let it drive the TPM. But it is not good for
upstreaming because
when other types of extension boards installed then it is not working.
Where to implement this? What is the best practice of this?


The second question is about extension manager.
I have read the extension.rst. I think I'll implement this anyway
because then
I can have a command to query what type of extension boards I have.
And if the extension board is the 3 slots one. I can then detect which
slot is the TPM.
I'll implement this anyway because the "extension" command is convenient
for users.
But it seems to me that it only solves the problem for Linux kernel.
It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
extension board.
But it is too late for U-boot itself, right?


The third question is I'm also dong SystemReady IR certificate. That means
the dtb for Linux is directly provided by U-boot. We use U-boot dtb
directly to Linux
kernel. In this case, how to modify that dts dynamically to feed to the
Linux kernel by
the extension manager?
What is the best practice if I want to use U-boot dts for Linux in
implementation?


Thanks a lot.


Yours,
Paul



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Question about extension board used in U-boot

[François Ozog]

Hi Paul

Too posting because I think we also need to address this at a higher level.

i think we discussed this topic quite a while back. I may be wrong but it
may be Bill Mills who proposed to have an eeprom on the extensions that the
carrier board can use to detect and fetch proper overlay. Another way would
be that the contract between the extension board and the carrier board
includes an i2c accessible storage to fetch an overlay that would identify
the board and give all details. Bottom line, a software only solution seems
not entirely satisfying.
In that suboptimal case, U-Boot shall be able to assemble a DT for itself
and another for OS (may be same in some cases) through scripting. And in
this case, come your questions  below

.

Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <paulliu@debian.org>
a écrit :

> Hi all,
>
>
> I have some questions about how to implement extension board usage.
> My case is on imx8mm-cl-iot-gate. It can add three different types of
> extension boards.
> One of the extension boards is SPI extension which have 3 empty slots.
> And you can add
> some small boards onto it. One of them is a "TPM2" module.
>
>
> My first question is if I want to use tpm2 in U-boot for measured boot.
> How to implement this right? Currently I just modify the dts used by
> U-boot to let it drive
> the extension board. And let it drive the TPM. But it is not good for
> upstreaming because
> when other types of extension boards installed then it is not working.
> Where to implement this? What is the best practice of this?


> The second question is about extension manager.
> I have read the extension.rst. I think I'll implement this anyway
> because then
> I can have a command to query what type of extension boards I have.
> And if the extension board is the 3 slots one. I can then detect which
> slot is the TPM.
> I'll implement this anyway because the "extension" command is convenient
> for users.
> But it seems to me that it only solves the problem for Linux kernel.
> It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
> extension board.
> But it is too late for U-boot itself, right?
>
>
> The third question is I'm also dong SystemReady IR certificate. That means
> the dtb for Linux is directly provided by U-boot. We use U-boot dtb
> directly to Linux
> kernel. In this case, how to modify that dts dynamically to feed to the
> Linux kernel by
> the extension manager?
> What is the best practice if I want to use U-boot dts for Linux in
> implementation?
>
>
> Thanks a lot.
>
>
> Yours,
> Paul
>
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

Re: Question about extension board used in U-boot

[François Ozog]

Le sam. 18 sept. 2021 à 08:49, François Ozog <francois.ozog@linaro.org> a
écrit :

> Hi Paul
>
> Too posting because I think we also need to address this at a higher level.
>
> i think we discussed this topic quite a while back. I may be wrong but it
> may be Bill Mills who proposed to have an eeprom on the extensions that the
> carrier board can use to detect and fetch proper overlay. Another way would
> be that the contract between the extension board and the carrier board
> includes an i2c accessible storage to fetch an overlay that would identify
> the board and give all details.
>
i just forgot to state that the mode is well known: SPD for DIMMs.

> Bottom line, a software only solution seems not entirely satisfying.
> In that suboptimal case, U-Boot shall be able to assemble a DT for itself
> and another for OS (may be same in some cases) through scripting. And in
> this case, come your questions  below
>
> .
>
> Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <paulliu@debian.org>
> a écrit :
>
>> Hi all,
>>
>>
>> I have some questions about how to implement extension board usage.
>> My case is on imx8mm-cl-iot-gate. It can add three different types of
>> extension boards.
>> One of the extension boards is SPI extension which have 3 empty slots.
>> And you can add
>> some small boards onto it. One of them is a "TPM2" module.
>>
>>
>> My first question is if I want to use tpm2 in U-boot for measured boot.
>> How to implement this right? Currently I just modify the dts used by
>> U-boot to let it drive
>> the extension board. And let it drive the TPM. But it is not good for
>> upstreaming because
>> when other types of extension boards installed then it is not working.
>> Where to implement this? What is the best practice of this?
>
>
>> The second question is about extension manager.
>> I have read the extension.rst. I think I'll implement this anyway
>> because then
>> I can have a command to query what type of extension boards I have.
>> And if the extension board is the 3 slots one. I can then detect which
>> slot is the TPM.
>> I'll implement this anyway because the "extension" command is convenient
>> for users.
>> But it seems to me that it only solves the problem for Linux kernel.
>> It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
>> extension board.
>> But it is too late for U-boot itself, right?
>>
>>
>> The third question is I'm also dong SystemReady IR certificate. That means
>> the dtb for Linux is directly provided by U-boot. We use U-boot dtb
>> directly to Linux
>> kernel. In this case, how to modify that dts dynamically to feed to the
>> Linux kernel by
>> the extension manager?
>> What is the best practice if I want to use U-boot dts for Linux in
>> implementation?
>>
>>
>> Thanks a lot.
>>
>>
>> Yours,
>> Paul
>>
>>
>> --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog

Re: Question about extension board used in U-boot

[Heinrich Schuchardt]

On 9/18/21 8:54 AM, François Ozog wrote:
> Le sam. 18 sept. 2021 à 08:49, François Ozog <francois.ozog@linaro.org> a
> écrit :
>
>> Hi Paul
>>
>> Too posting because I think we also need to address this at a higher level.
>>
>> i think we discussed this topic quite a while back. I may be wrong but it
>> may be Bill Mills who proposed to have an eeprom on the extensions that the
>> carrier board can use to detect and fetch proper overlay. Another way would
>> be that the contract between the extension board and the carrier board
>> includes an i2c accessible storage to fetch an overlay that would identify
>> the board and give all details.
>>
> i just forgot to state that the mode is well known: SPD for DIMMs.
>
>> Bottom line, a software only solution seems not entirely satisfying.
>> In that suboptimal case, U-Boot shall be able to assemble a DT for itself
>> and another for OS (may be same in some cases) through scripting. And in
>> this case, come your questions  below
>>
>> .
>>
>> Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <paulliu@debian.org>
>> a écrit :
>>
>>> Hi all,
>>>
>>>
>>> I have some questions about how to implement extension board usage.
>>> My case is on imx8mm-cl-iot-gate. It can add three different types of
>>> extension boards.
>>> One of the extension boards is SPI extension which have 3 empty slots.
>>> And you can add
>>> some small boards onto it. One of them is a "TPM2" module.

You could implement the weak function board_fdt_blob_setup() to detect
your addon boards and extend the devicetree.


>>>
>>>
>>> My first question is if I want to use tpm2 in U-boot for measured boot.
>>> How to implement this right? Currently I just modify the dts used by
>>> U-boot to let it drive

Measured boot is provided in U-Boot v2021.10-rc4 based on TPMv2. Just
enable CONFIG_EFI_TCG2_PROTOCOL.

>>> the extension board. And let it drive the TPM. But it is not good for
>>> upstreaming because
>>> when other types of extension boards installed then it is not working.
>>> Where to implement this? What is the best practice of this?
>>
>>
>>> The second question is about extension manager.
>>> I have read the extension.rst. I think I'll implement this anyway
>>> because then
>>> I can have a command to query what type of extension boards I have.
>>> And if the extension board is the 3 slots one. I can then detect which
>>> slot is the TPM.
>>> I'll implement this anyway because the "extension" command is convenient
>>> for users.
>>> But it seems to me that it only solves the problem for Linux kernel.
>>> It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
>>> extension board.
>>> But it is too late for U-boot itself, right?
>>>
>>>
>>> The third question is I'm also dong SystemReady IR certificate. That means
>>> the dtb for Linux is directly provided by U-boot. We use U-boot dtb
>>> directly to Linux
>>> kernel. In this case, how to modify that dts dynamically to feed to the
>>> Linux kernel by
>>> the extension manager?

U-Boot has a fdt command which you could use to apply overlays. Or
implement function board_fdt_blob_setup().

Best regards

Heinrich

>>> What is the best practice if I want to use U-boot dts for Linux in
>>> implementation?
>>>
>>>
>>> Thanks a lot.
>>>
>>>
>>> Yours,
>>> Paul
>>>
>>>
>>> --
>> François-Frédéric Ozog | *Director Business Development*
>> T: +33.67221.6485
>> francois.ozog@linaro.org | Skype: ffozog
>>
>> --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
> _______________________________________________
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
>

Re: Question about extension board used in U-boot

[Ying-Chun Liu (PaulLiu)]

[-- Attachment #1.1: Type: text/plain, Size: 5082 bytes --]

Hi Heinrich,

I think I met some chicken and egg problem. Or I misunderstand something
you mentioned.


So I tried board_fdt_blob_setup() and board_fix_fdt().
Both are too early.
I need i2c to be drived first. And then I can use
dm_i2c_probe() on different address to detect which extension board it is.
However, in board_fdt_blob_setup() or board_fix_fdt(). i2c seems not
working there.
I can do the detection in board_late_init() but it is just too late for
U-boot itself.
Good for Linux kernel though.


Sorry for my bad English. Measured boot is already working on my branch.
But the way I implemented this is directly modify the dts of U-boot and
assume
the TPM extension board is always there. Thus this is not upstreamable.


I think let me upstream some code by extension manager first (for linux
kernel first).
And then we can see how the detection is implemented and how to modify
it for U-boot.


Thanks,
Paul


Heinrich Schuchardt 於 2021/9/18 下午3:14 寫道:
>
>
> On 9/18/21 8:54 AM, François Ozog wrote:
>> Le sam. 18 sept. 2021 à 08:49, François Ozog
>> <francois.ozog@linaro.org> a
>> écrit :
>>
>>> Hi Paul
>>>
>>> Too posting because I think we also need to address this at a higher
>>> level.
>>>
>>> i think we discussed this topic quite a while back. I may be wrong
>>> but it
>>> may be Bill Mills who proposed to have an eeprom on the extensions
>>> that the
>>> carrier board can use to detect and fetch proper overlay. Another
>>> way would
>>> be that the contract between the extension board and the carrier board
>>> includes an i2c accessible storage to fetch an overlay that would
>>> identify
>>> the board and give all details.
>>>
>> i just forgot to state that the mode is well known: SPD for DIMMs.
>>
>>> Bottom line, a software only solution seems not entirely satisfying.
>>> In that suboptimal case, U-Boot shall be able to assemble a DT for
>>> itself
>>> and another for OS (may be same in some cases) through scripting.
>>> And in
>>> this case, come your questions  below
>>>
>>> .
>>>
>>> Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu)
>>> <paulliu@debian.org>
>>> a écrit :
>>>
>>>> Hi all,
>>>>
>>>>
>>>> I have some questions about how to implement extension board usage.
>>>> My case is on imx8mm-cl-iot-gate. It can add three different types of
>>>> extension boards.
>>>> One of the extension boards is SPI extension which have 3 empty slots.
>>>> And you can add
>>>> some small boards onto it. One of them is a "TPM2" module.
>
> You could implement the weak function board_fdt_blob_setup() to detect
> your addon boards and extend the devicetree.
>
>
>>>>
>>>>
>>>> My first question is if I want to use tpm2 in U-boot for measured
>>>> boot.
>>>> How to implement this right? Currently I just modify the dts used by
>>>> U-boot to let it drive
>
> Measured boot is provided in U-Boot v2021.10-rc4 based on TPMv2. Just
> enable CONFIG_EFI_TCG2_PROTOCOL.
>
>>>> the extension board. And let it drive the TPM. But it is not good for
>>>> upstreaming because
>>>> when other types of extension boards installed then it is not working.
>>>> Where to implement this? What is the best practice of this?
>>>
>>>
>>>> The second question is about extension manager.
>>>> I have read the extension.rst. I think I'll implement this anyway
>>>> because then
>>>> I can have a command to query what type of extension boards I have.
>>>> And if the extension board is the 3 slots one. I can then detect which
>>>> slot is the TPM.
>>>> I'll implement this anyway because the "extension" command is
>>>> convenient
>>>> for users.
>>>> But it seems to me that it only solves the problem for Linux kernel.
>>>> It can apply a DTB Overlay to Linux DTB to let Linux knows we have
>>>> that
>>>> extension board.
>>>> But it is too late for U-boot itself, right?
>>>>
>>>>
>>>> The third question is I'm also dong SystemReady IR certificate.
>>>> That means
>>>> the dtb for Linux is directly provided by U-boot. We use U-boot dtb
>>>> directly to Linux
>>>> kernel. In this case, how to modify that dts dynamically to feed to
>>>> the
>>>> Linux kernel by
>>>> the extension manager?
>
> U-Boot has a fdt command which you could use to apply overlays. Or
> implement function board_fdt_blob_setup().
>
> Best regards
>
> Heinrich
>
>>>> What is the best practice if I want to use U-boot dts for Linux in
>>>> implementation?
>>>>
>>>>
>>>> Thanks a lot.
>>>>
>>>>
>>>> Yours,
>>>> Paul
>>>>
>>>>
>>>> -- 
>>> François-Frédéric Ozog | *Director Business Development*
>>> T: +33.67221.6485
>>> francois.ozog@linaro.org | Skype: ffozog
>>>
>>> -- 
>> François-Frédéric Ozog | *Director Business Development*
>> T: +33.67221.6485
>> francois.ozog@linaro.org | Skype: ffozog
>> _______________________________________________
>> boot-architecture mailing list
>> boot-architecture@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/boot-architecture
>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Modules for carrier boards [Was: Re: Question about extension board used in U-boot]

[Daniel Thompson]

On Sat, Sep 18, 2021 at 08:49:48AM +0200, François Ozog wrote:
> Hi Paul
> 
> Too posting because I think we also need to address this at a higher level.
> 
> i think we discussed this topic quite a while back. I may be wrong but it
> may be Bill Mills who proposed to have an eeprom on the extensions that the
> carrier board can use to detect and fetch proper overlay. Another way would
> be that the contract between the extension board and the carrier board
> includes an i2c accessible storage to fetch an overlay that would identify
> the board and give all details.

What you're describing sounds exactly like Raspberry Pi HATs work:
https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md

Similarly Beagleboard capes use rely on I2C EEPROMs for make them
discoverable, although I don't think all have to have a built-in
overlay (IIRC because they joined the party too early).

In other words there's plenty of prior art here and, as new hardware
standards come out, it should be much easier for them to find this prior
art. However I'm near certain mistakes will still be made...


> Bottom line, a software only solution seems not entirely satisfying.
> In that suboptimal case, U-Boot shall be able to assemble a DT for itself
> and another for OS (may be same in some cases) through scripting. And in
> this case, come your questions  below.

Sub-optimal or not[1] the u-boot extension board code still looks like it
would be a good starting point even for boards with non-discoverable
extensions (96Boards CE 1.0 for example).

If implementing on a board with non-discoverable extensions then I would
consider implementing "extension scan" to report non-discoverable modules
(e.g. from an internal list) and proposing patches to that "extension
apply all" would not enable non-discoverable boards (so that non-
discoverable boards would have to be enabled by injecting a "extension
apply <id>" into the boot scripts).

Of course, I may have overlooked a better existing mechanism in u-boot
but that's what I would start with until I was corrected by
maintainers ;-) .


Daniel.


[1] And also extremely off-topic for Paul since his (a) boards are
    discoverable and (b) the extension framework can't fire up early
    enough for TPM extensions ;-) .



> Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <paulliu@debian.org>
> a écrit :
> 
> > Hi all,
> >
> >
> > I have some questions about how to implement extension board usage.
> > My case is on imx8mm-cl-iot-gate. It can add three different types of
> > extension boards.
> > One of the extension boards is SPI extension which have 3 empty slots.
> > And you can add
> > some small boards onto it. One of them is a "TPM2" module.
> >
> >
> > My first question is if I want to use tpm2 in U-boot for measured boot.
> > How to implement this right? Currently I just modify the dts used by
> > U-boot to let it drive
> > the extension board. And let it drive the TPM. But it is not good for
> > upstreaming because
> > when other types of extension boards installed then it is not working.
> > Where to implement this? What is the best practice of this?
> 
> 
> > The second question is about extension manager.
> > I have read the extension.rst. I think I'll implement this anyway
> > because then
> > I can have a command to query what type of extension boards I have.
> > And if the extension board is the 3 slots one. I can then detect which
> > slot is the TPM.
> > I'll implement this anyway because the "extension" command is convenient
> > for users.
> > But it seems to me that it only solves the problem for Linux kernel.
> > It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
> > extension board.
> > But it is too late for U-boot itself, right?
> >
> >
> > The third question is I'm also dong SystemReady IR certificate. That means
> > the dtb for Linux is directly provided by U-boot. We use U-boot dtb
> > directly to Linux
> > kernel. In this case, how to modify that dts dynamically to feed to the
> > Linux kernel by
> > the extension manager?
> > What is the best practice if I want to use U-boot dts for Linux in
> > implementation?
> >
> >
> > Thanks a lot.
> >
> >
> > Yours,
> > Paul
> >
> >
> > --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
> _______________________________________________
> boot-architecture mailing list
> boot-architecture@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture

Re: Modules for carrier boards [Was: Re: Question about extension board used in U-boot]

[François Ozog]

Le lun. 20 sept. 2021 à 13:32, Daniel Thompson <daniel.thompson@linaro.org>
a écrit :

> On Sat, Sep 18, 2021 at 08:49:48AM +0200, François Ozog wrote:
> > Hi Paul
> >
> > Too posting because I think we also need to address this at a higher
> level.
> >
> > i think we discussed this topic quite a while back. I may be wrong but it
> > may be Bill Mills who proposed to have an eeprom on the extensions that
> the
> > carrier board can use to detect and fetch proper overlay. Another way
> would
> > be that the contract between the extension board and the carrier board
> > includes an i2c accessible storage to fetch an overlay that would
> identify
> > the board and give all details.
>
> What you're describing sounds exactly like Raspberry Pi HATs work:
> https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md
>
> Similarly Beagleboard capes use rely on I2C EEPROMs for make them
> discoverable, although I don't think all have to have a built-in
> overlay (IIRC because they joined the party too early).
>
I believe this would be a great SystemReady addition: define details of the
DT lifecycle and probably adopt one of the two models. Or worst case define
a consolidated one.
I hope this is also adoptable by  96boards…

>
> In other words there's plenty of prior art here and, as new hardware
> standards come out, it should be much easier for them to find this prior
> art. However I'm near certain mistakes will still be made...
>
>
> > Bottom line, a software only solution seems not entirely satisfying.
> > In that suboptimal case, U-Boot shall be able to assemble a DT for itself
> > and another for OS (may be same in some cases) through scripting. And in
> > this case, come your questions  below.
>
> Sub-optimal or not[1] the u-boot extension board code still looks like it
> would be a good starting point even for boards with non-discoverable
> extensions (96Boards CE 1.0 for example).
>
> If implementing on a board with non-discoverable extensions then I would
> consider implementing "extension scan" to report non-discoverable modules
> (e.g. from an internal list) and proposing patches to that "extension
> apply all" would not enable non-discoverable boards (so that non-
> discoverable boards would have to be enabled by injecting a "extension
> apply <id>" into the boot scripts).
>
> Of course, I may have overlooked a better existing mechanism in u-boot
> but that's what I would start with until I was corrected by
> maintainers ;-) .
>
>
> Daniel.
>
>
> [1] And also extremely off-topic for Paul since his (a) boards are
>     discoverable and (b) the extension framework can't fire up early
>     enough for TPM extensions ;-) .
>
>
>
> > Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <
> paulliu@debian.org>
> > a écrit :
> >
> > > Hi all,
> > >
> > >
> > > I have some questions about how to implement extension board usage.
> > > My case is on imx8mm-cl-iot-gate. It can add three different types of
> > > extension boards.
> > > One of the extension boards is SPI extension which have 3 empty slots.
> > > And you can add
> > > some small boards onto it. One of them is a "TPM2" module.
> > >
> > >
> > > My first question is if I want to use tpm2 in U-boot for measured boot.
> > > How to implement this right? Currently I just modify the dts used by
> > > U-boot to let it drive
> > > the extension board. And let it drive the TPM. But it is not good for
> > > upstreaming because
> > > when other types of extension boards installed then it is not working.
> > > Where to implement this? What is the best practice of this?
> >
> >
> > > The second question is about extension manager.
> > > I have read the extension.rst. I think I'll implement this anyway
> > > because then
> > > I can have a command to query what type of extension boards I have.
> > > And if the extension board is the 3 slots one. I can then detect which
> > > slot is the TPM.
> > > I'll implement this anyway because the "extension" command is
> convenient
> > > for users.
> > > But it seems to me that it only solves the problem for Linux kernel.
> > > It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
> > > extension board.
> > > But it is too late for U-boot itself, right?
> > >
> > >
> > > The third question is I'm also dong SystemReady IR certificate. That
> means
> > > the dtb for Linux is directly provided by U-boot. We use U-boot dtb
> > > directly to Linux
> > > kernel. In this case, how to modify that dts dynamically to feed to the
> > > Linux kernel by
> > > the extension manager?
> > > What is the best practice if I want to use U-boot dts for Linux in
> > > implementation?
> > >
> > >
> > > Thanks a lot.
> > >
> > >
> > > Yours,
> > > Paul
> > >
> > >
> > > --
> > François-Frédéric Ozog | *Director Business Development*
> > T: +33.67221.6485
> > francois.ozog@linaro.org | Skype: ffozog
> > _______________________________________________
> > boot-architecture mailing list
> > boot-architecture@lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/boot-architecture
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog