Friday, September 7, 2018

[fedora-arm] Re: Impact of UEFI boot - Re: Re: Fedora 29 new U-Boot/arm-trusted-firmware and Raspberry Pi firmware heads up

Thanks Peter!

I will keep on as I have been doing.

BTW, though the update-uboot is of value, I just build a new 4Gb uMd
card with just the swap cards and reboot.  If the new uboot would not
work, I have a clean path back.

On 09/07/2018 01:57 PM, Peter Robinson wrote:
>>> Improvements for upgrade path for UEFI on ARMv7
>> I just spent a little time researching UEFI. I have a few concerns, and
>> it probably explains a challenge I have had on my x86_64 notebook.
>> That is, I have the 'habit' of developing a build on a test system,
>> moving the drive to the production unit in my rack and booting up.
>> It seems I can do that with Legacy BIOS as it searches for a boot drive
>> with an MBR and goes from there. My take on UEFI is that the GUID for a
>> drive and other information is stored on the system board and that is
>> used to find the bootup drive. You swap out drives, it won't boot up.
>> Either you need a tool to change the GUID information in the system, or
>> change the GUID in the drive you are using.
>> I suppose one way is to set the GUID in my drive to what the production
>> system is expecting so that the move goes smoothly.
>> Do I have this right? Is there something else I should be aware of and
>> plan for?
> In the ARM case UEFI is the only way we've ever supported booting a
> system on 64 bit ARM (aarch64) systems and this aligns us with all new
> x86_64 devices as well as all aarch64 devices so there's a single code
> path for us to support.
> Nope, you do not, all the details around UEFI should also be stored
> on the drive, and if not the UEFI firmware can read the details and
> work out what to do. Some stuff is stored in UEFI variables in the
> firmware but it is easy enough to deal with when you move drives to
> the machine.
> In the ARMv7 case on SBCs there's generally no variable storage anyway
> so we use sane defaults and the ability to move storage between
> devices is unchanged from the current method we do things.
> Peter
>>> On 09/07/2018 05:32 AM, Peter Robinson wrote:
>>>> Hi All,
>>>> There's a new update headed to testing for Fedora 29. It makes some
>>>> adjustments to how we handle a few things, in particular the Raspberry
>>>> Pi firmware:
>>>> I don't expect anyone to see anything issues in particular especially
>>>> for the vast majority of people that just use a SD card or HDD with
>>>> their ARM device but there might be some corner cases for people with
>>>> slightly more esoteric setups when they upgrade. If anyone sees any
>>>> issues please open a bug [1] or reply to this or reach out on
>>>> #fedora-arm. The change has been in rawhide for a little while and
>>>> I've not seen any fall out there.
>>>> Also the new U-Boot will have some slight improvements for those
>>>> running AllWinner 64 bit devices as we've moved to the upstream ARM
>>>> trusted firmware. It's just a snapshot at the moment but the previous
>>>> fork was quite old and had it's issues on certain devices so I expect
>>>> this to be an overall win for people there, but again I can't test
>>>> everything so if anyone sees issues please reach out.
>>>> All please add karma to the above update when you do test it. People
>>>> can update U-Boot on a running system with the update-uboot command
>>>> with similar syntax to arm-image-installer.
>>>> Peter
>>>> [1]
>>>> _______________________________________________
>>>> arm mailing list --
>>>> To unsubscribe send an email to
>>>> Fedora Code of Conduct:
>>>> List Guidelines:
>>>> List Archives:
>>> _______________________________________________
>>> arm mailing list --
>>> To unsubscribe send an email to
>>> Fedora Code of Conduct:
>>> List Guidelines:
>>> List Archives:
arm mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:

No comments:

Post a Comment