On 21.02.19 14:22, Philipp Tomsich wrote:
>
>
>> On 21.02.2019, at 13:00, Andre Przywara wrote:
>>
>> On Thu, 21 Feb 2019 12:47:04 +0100
>> Alexander Graf wrote:
>>
>> Hi Alex,
>>
>>> On 02/21/2019 02:30 AM, Andre Przywara wrote:
Read the specified "arch" value from a legacy or FIT U-Boo
> On 21.02.2019, at 13:00, Andre Przywara wrote:
>
> On Thu, 21 Feb 2019 12:47:04 +0100
> Alexander Graf wrote:
>
> Hi Alex,
>
>> On 02/21/2019 02:30 AM, Andre Przywara wrote:
>>> Read the specified "arch" value from a legacy or FIT U-Boot image and
>>> store it in our SPL data structure.
>>
On Thu, 21 Feb 2019 12:47:04 +0100
Alexander Graf wrote:
Hi Alex,
> On 02/21/2019 02:30 AM, Andre Przywara wrote:
> > Read the specified "arch" value from a legacy or FIT U-Boot image and
> > store it in our SPL data structure.
> > This allows loaders to take the target architecture in account f
> On 21.02.2019, at 12:47, Alexander Graf wrote:
>
> On 02/21/2019 02:30 AM, Andre Przywara wrote:
>> Read the specified "arch" value from a legacy or FIT U-Boot image and
>> store it in our SPL data structure.
>> This allows loaders to take the target architecture in account for
>> custom load
On 02/21/2019 02:30 AM, Andre Przywara wrote:
Read the specified "arch" value from a legacy or FIT U-Boot image and
store it in our SPL data structure.
This allows loaders to take the target architecture in account for
custom loading procedures.
Having the complete string -> arch mapping for FIT
Read the specified "arch" value from a legacy or FIT U-Boot image and
store it in our SPL data structure.
This allows loaders to take the target architecture in account for
custom loading procedures.
Having the complete string -> arch mapping for FIT based images in the
SPL would be too big, so we
6 matches
Mail list logo