Re: [PATCH] roms: opensbi: Upgrade from v0.6 to v0.7

[Bin Meng]

On Wed, Apr 22, 2020 at 6:04 PM Philippe Mathieu-Daudé
<address@hidden> wrote:
>
> On 4/22/20 11:50 AM, Bin Meng wrote:
> > On Wed, Apr 22, 2020 at 4:15 PM Philippe Mathieu-Daudé
> > <address@hidden> wrote:
> >>
> >> On 4/22/20 3:30 AM, Bin Meng wrote:
> >>> Hi Alistair,
> >>>
> >>> On Tue, Apr 21, 2020 at 9:34 AM Bin Meng <address@hidden> wrote:
> >>>>
> >>>> Hi Alistair,
> >>>>
> >>>> On Tue, Apr 21, 2020 at 2:41 AM Alistair Francis <address@hidden> wrote:
> >>>>>
> >>>>> On Mon, Apr 20, 2020 at 6:25 AM Bin Meng <address@hidden> wrote:
> >>>>>>
> >>>>>> Upgrade OpenSBI from v0.6 to v0.7 and the pre-built bios images.
> >>>>>>
> >>>>>> The v0.7 release includes the following commits:
> >>>>>>
> >>>>>> f64f4b9 lib: Add a new platform feature to bringup secondary harts
> >>>>>> b677a9b lib: Implement hart hotplug
> >>>>>> 5b48240 lib: Add possible hart status values
> >>>>>> e3f69fc lib: Implement Hart State Management (HSM) SBI extension
> >>>>>> 6704216 lib: Check MSIP bit after returning from WFI
> >> [...]
> >>>>>> 6c7922e lib: Support vector extension
> >>>>>> 615587c docs: Update README about supported SBI versions
> >>>>>> 66d0184 lib: Allow overriding SBI implementation ID
> >>>>>> 9f1b72c include: Bump-up version to 0.7
> >>
> >> The git-short-log in the commit message is very appreciated, thanks.
> >>
> >>>>>>
> >>>>>> Signed-off-by: Bin Meng <address@hidden>
> >>>>>
> >>>>> Reviewed-by: Alistair Francis <address@hidden>
> >>>>>
> >>>>> Can you share a git branch with this patch? From memory these binary
> >>>>> patches don't apply well from emails.
> >>
> >> Indeed. These patches are good candidate to use the 'git-format-patch
> >> --no-binary' option with a link to a git repository to fetch the full
> >> commit:
> >>
> >
> > Some other project mailing lists do not prevent binary patch mails. If
> > this is QEMU convention, I suggest we document this in
> > https://wiki.qemu.org/Contribute/SubmitAPatch.
>
> This is not a convention, but a personal suggestion. QEMU mailing list
> don't have this limitation AFAIK. However some MTA do weird things when
> relaying encoded binaries, and the result is patch are simply not
> applicable.
> Also such large (broken) mails are a pain when your mailbox has quota.
>
> I added this entry:
> https://wiki.qemu.org/Contribute/SubmitAPatch#Avoid_posting_large_binary_blob

Thanks for updating the QEMU WiKi. Looks good to me.

>
> >
> >>     --no-binary
> >>       Do not output contents of changes in binary files,
> >>       instead display a notice that those files changed.
> >>       Patches generated using this option cannot be applied
> >>       properly, but they are still useful for code review.
> >>
> >>>>
> >>>> Sure. Please grab the bits from http://github.com/lbmeng/qemu opensbi 
> >>>> branch.
> >>>>
> >>>> You can also use patchwork to help with your custodian work.
> >>>> http://patchwork.ozlabs.org/project/qemu-devel/patch/address@hidden/
> >>>>
> >>>> Click on the "mbox" button to download the patch and apply it.
> >>>
> >>> Will this be 5.0, or 5.1?
> >>
> >> Unlikely 5.1, too late.
> >
> > I am fine. Just wanted to know the strategy of which QEMU release to
> > ship which OpenSBI release. +Anup in case he has some comments.
>
> Well I'm not taking any decision here, I'm simply sharing the impression
> I have after reading the thread between Palmer and Peter:
> https://www.mail-archive.com/address@hidden/msg697142.html
> You can still ask Alistair to insist to Peter, but you'd need a strong
> reason :)

Yes, I see that. Unfortunately that patch series was not put in the
RISC-V queue in time and missed the merge window. Sigh.

Regards,
Bin