12:57 p.m.
> 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:
> >>
> >> https://bodhi.fedoraproject.org/updates/FEDORA-2018-56bc88dfb2
> >>
> >> 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]
> >>
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=29&a...
> >> _______________________________________________
> >> arm mailing list -- arm(a)lists.fedoraproject.org
> >> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >> https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
> > _______________________________________________
> > arm mailing list -- arm(a)lists.fedoraproject.org
> > To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
>