Hi Philippe, On Fri, Feb 21, 2020 at 4:54 PM Philippe Mathieu-Daudé <phi...@redhat.com> wrote: > > On 2/21/20 6:54 AM, Anup Patel wrote: > > On Fri, Feb 21, 2020 at 8:08 AM Bin Meng <bmeng...@gmail.com> wrote: > >> > >> Hi Philippe, > >> > >> On Fri, Feb 21, 2020 at 1:31 AM Philippe Mathieu-Daudé > >> <phi...@redhat.com> wrote: > >>> > >>> Hi Bin, > >>> > >>> On 2/20/20 3:42 PM, Bin Meng wrote: > >>>> Although the real world SiFive HiFive Unleashed board is a 64-bit > >>>> hardware configuration, with QEMU it is possible to test 32-bit > >>>> configuration with the same hardware features. > >>>> > >>>> This updates the roms Makefile to add the build rules for creating > >>>> the 32-bit OpenSBI firmware image for sifive_u machine. A pre-built > >>>> OpenSBI image (built from commit 3e7d666) has been added as the > >>>> default bios for 32-bit sifive_u machine. > >>> > >>> With QEMU: > >>> > >>> fatal: ambiguous argument '3e7d666': unknown revision or path not in the > >>> working tree. > >>> > >>> This looks like an OpenSBI commit but QEMU only include up to v0.5. > >>> > >>> Can you build v0.5? Else can you update the submodule? > >>> > >> > >> Will do in v2. > > > > We plan to release OpenSBI v0.6 on monday (24th Feb 2020) so maybe > > you can update all RISC-V ROM images based on OpenSBI v0.6 ?? > > Sounds cleaner.
Yes, will update all RISC-V ROM images to v0.6 in v2. > > Suggestions when updating a QEMU git-submodule: > > > - Include output of submodule 'git-log --reverse --oneline' > > - Send series/pull-request with 'git-format-patch --no-binary' > Sure. I believe with "--no-binary" I will need provide a repo for pull? > > > >> > >>> Also, can you add a CI job to build this, so we have reproducible builds > >>> (see QEMU commit 71920809ceabed as example)? > >> > >> I cannot find any document for how to test CI job with gitlab CI. Does > >> QEMU has a public CI runner for testing? > > There is: > > https://wiki.qemu.org/Testing > https://wiki.qemu.org/Testing/CI > > Currently you can use whatever CI best suits you (although long term is > probably to rely more on GitLab, because it allows adding runners on > particular hardware/setup). Thank you very much for the pointers. I will add a CI job in v2. Regards, Bin