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:
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&component=bcm283x-firmware
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
