[fedora-arm] Fedora 29 new U-Boot/arm-trusted-firmware and Raspberry Pi firmware heads up

Discussion:

Peter Robinson

2018-09-07 09:32:24 UTC

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 -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@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/***@lists.fedoraproject.or

Robert Moskowitz

2018-09-07 12:19:51 UTC

Permalink

What is meant by:

Improvements for upgrade path for UEFI on ARMv7

thanks

Post by Peter Robinson
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
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
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@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

Robert Moskowitz

2018-09-07 17:19:28 UTC

Permalink

Post by Robert Moskowitz
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?

thanks

Post by Robert Moskowitz
thanks

Post by Peter Robinson
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
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
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

Peter Robinson

2018-09-07 17:57:32 UTC

Permalink

Post by Robert Moskowitz
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

Post by Robert Moskowitz

Post by Peter Robinson
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
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
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

Robert Moskowitz

2018-09-07 18:35:48 UTC

Permalink

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.

Post by Peter Robinson

Post by Robert Moskowitz
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

Post by Robert Moskowitz

Post by Peter Robinson
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
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
_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

_______________________________________________
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

Robert Moskowitz

2018-09-07 12:41:29 UTC

Permalink

Peter,

I have scanned update-uboot. I am not really all that skilled at script
writing, but I get the drift that you need to provide a koji image name
to download and get the uboot directory.

It would seem to be 'cleaner' if the update testing repo had a uboot rpm
that could be installed to get all the forthcoming ubbot images? Then
dd from there?

How is one to figure out which koji image to specify?

Seems like a great beginning of a great tool.

Peter Robinson

2018-09-07 13:48:38 UTC

Permalink

Post by Robert Moskowitz
Peter,
I have scanned update-uboot. I am not really all that skilled at script
writing, but I get the drift that you need to provide a koji image name
to download and get the uboot directory.

No, you don't, that's just an option. Generally you do "dnf upgrade
--refresh" and if a new version of U-Boot rpms get installed you would
then run something like:
"update-uboot --target=udoo_neo --media=/dev/mmcblk0"

of course updating the target and the media/

Post by Robert Moskowitz
It would seem to be 'cleaner' if the update testing repo had a uboot rpm
that could be installed to get all the forthcoming ubbot images? Then
dd from there?

That is exactly what it does.

Post by Robert Moskowitz
How is one to figure out which koji image to specify?

You don't, see above.

Post by Robert Moskowitz
Seems like a great beginning of a great tool.

Robert Moskowitz

2018-09-07 14:08:57 UTC

Permalink

Told you I was not skilled at scripts. I did not get this from what few
comments were in the beginning of the script.

I now understand better. But...

Why the --refresh in your dnf update example below?

I did a little digging in /boot to see if there is any information on
what uboot SOC is installed. Did not find one. It would be great if
the default for this command could determine the proper uboot and
device. Also perhaps the tag option could be tagged as optional? Or
some more test about what it means and why most of us will not use it?

thanks

Post by Peter Robinson

No, you don't, that's just an option. Generally you do "dnf upgrade
--refresh" and if a new version of U-Boot rpms get installed you would
"update-uboot --target=udoo_neo --media=/dev/mmcblk0"
of course updating the target and the media/

Post by Robert Moskowitz
It would seem to be 'cleaner' if the update testing repo had a uboot rpm
that could be installed to get all the forthcoming ubbot images? Then
dd from there?

That is exactly what it does.

Post by Robert Moskowitz
How is one to figure out which koji image to specify?

You don't, see above.

Post by Robert Moskowitz
Seems like a great beginning of a great tool.

Peter Robinson

2018-09-07 14:39:10 UTC

Permalink

It forces a refresh on the metadata.

I did a little digging in /boot to see if there is any information on
what uboot SOC is installed. Did not find one. It would be great if
the default for this command could determine the proper uboot and
device. Also perhaps the tag option could be tagged as optional? Or
some more test about what it means and why most of us will not use it?

Added a RFE for the clarification of the tag option.

It's actually hard to determine the board option that's needed from a
running system and hence why we don't auto detect it.

thanks

Post by Peter Robinson

Post by Robert Moskowitz
It would seem to be 'cleaner' if the update testing repo had a uboot rpm
that could be installed to get all the forthcoming ubbot images? Then
dd from there?

That is exactly what it does.

Post by Robert Moskowitz
How is one to figure out which koji image to specify?

You don't, see above.

Post by Robert Moskowitz
Seems like a great beginning of a great tool.

Robert Moskowitz

2018-09-07 14:28:26 UTC

Permalink

Did a bit more digging.

Perhaps adding update-uboot to
https://fedoraproject.org/wiki/Architectures/ARM/Installation

might make sense? So that the steps to update uboot are clearer from
the beginning.

Fedora uses understand 'dnf update'. Updating uboot needing an extra
step is different.

Hmmm. Thought more about what device uboot is on, and I realize that it
may be really hard to get that right. Like when I have uboot on my uSD
card and nothing else on it and the partitions on the sata drive.
Assuming that the uboot device is the same as the one that contains
/boot is not always right.

I just looked at one Cubieboard2 system set up this way (OK, it is
Centos7, not Fedora2x). The sata is /dev/sda. The 'USB external' drive
is /dev/sdb. I am guessing from looking in /dev that uboot is on
/dev/mmcblk0? I looked at the beginning of the console capture, at it
does not indicate where it found uboot:

U-Boot SPL 2018.09-rc2 (Aug 14 2018 - 16:45:15 +0000)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1

U-Boot 2018.09-rc2 (Aug 14 2018 - 16:45:15 +0000) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Cubietech Cubieboard2
I2C:   ready
DRAM: 1 GiB
MMC:   SUNXI SD/MMC: 0
Loading Environment from FAT... Unable to use mmc 0:2... HDMI connected:
Setting
up a 1920x1080 dvi console (overscan 0x0)

Sigh.

thanks

Post by Peter Robinson

Post by Robert Moskowitz
It would seem to be 'cleaner' if the update testing repo had a uboot rpm
that could be installed to get all the forthcoming ubbot images? Then
dd from there?

That is exactly what it does.

Post by Robert Moskowitz
How is one to figure out which koji image to specify?

You don't, see above.

Post by Robert Moskowitz
Seems like a great beginning of a great tool.