On Fri, Sep 7, 2018 at 3:09 PM Robert Moskowitz <firstname.lastname@example.org> wrote:
> 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?
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.
> On 09/07/2018 09:48 AM, Peter Robinson wrote:
> > On Fri, Sep 7, 2018 at 1:41 PM Robert Moskowitz <email@example.com> wrote:
> >> 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/
> >> 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.
> >> How is one to figure out which koji image to specify?
> > You don't, see above.
> >> Seems like a great beginning of a great tool.
> >> 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  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
> >>>  https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=29&component=bcm283x-firmware
> >>> _______________________________________________
> >>> arm mailing list -- firstname.lastname@example.org
> >>> To unsubscribe send an email to email@example.com
> >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >>> List Archives: https://firstname.lastname@example.org
arm mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com