[Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Kilian Zinnecker via buildroot]

Hello all,

I saw that RISC-V's OpenSBI recently got an update to v1.6.[1] In buildroot 
the package's latest version is v1.5.[2] I would like to bump it. Ofc. I'd 
have to adjust the version in the Config.in, and also the hashes in the hash 
file. I am wondering what is required with regards to testing? Currently I 
cannot test whether RISC-V boards would work with OpenSBI v1.6. However, I 
could do a build-test, i.e., pick a RISC-V defconfig, adjust its OpenSBI 
version to 1.6 (just locally, not sending any patch with that regard to any 
board's defconfig) and see, whether OpenSBI v1.6 gets build successfully. Is 
this sufficient as testing before sending a patch bumping OpenSBI? Or is 
additional testing expected before sending a bump-patch?

Best regards,
Kilian

[1] https://github.com/riscv-software-src/opensbi/commit/
bd613dd92113f683052acfb23d9dc8ba60029e0a
[2] https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/opensbi/
Config.in?ref_type=heads#L21-22


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Julien Olivain]

Hi Kilian,

On 26/12/2024 22:19, Kilian Zinnecker via buildroot wrote:
> Hello all,
> 
> I saw that RISC-V's OpenSBI recently got an update to v1.6.[1] In 
> buildroot
> the package's latest version is v1.5.[2] I would like to bump it. Ofc. 
> I'd
> have to adjust the version in the Config.in, and also the hashes in the 
> hash
> file.

This is correct. You can have a look how the previous versions
were updated, for details. For example, see [3].
This will update only the default "latest" OpenSBI version. Usually,
defconfigs in Buildroot are using a specific, fixed custom version.

> I am wondering what is required with regards to testing? Currently I
> cannot test whether RISC-V boards would work with OpenSBI v1.6. 
> However, I
> could do a build-test, i.e., pick a RISC-V defconfig, adjust its 
> OpenSBI
> version to 1.6 (just locally, not sending any patch with that regard to 
> any
> board's defconfig) and see, whether OpenSBI v1.6 gets build 
> successfully. Is
> this sufficient as testing before sending a patch bumping OpenSBI? Or 
> is
> additional testing expected before sending a bump-patch?

There is no strict rules for testing. The general guideline would be
"the more, the better" ;)  Doing a compilation test only for such a
component is a bit limited. Doing a runtime test would be better.
So, if you have a specific board in mind, you can ask in the patch
cover letter (on in the patch note) for somebody with access to the
board to test and reply with the "Tested-by:" tag.

Fortunately, in Buildroot, there is several defconfigs for
RISC-V emulators [4] [5] [6] [7]. If you don't have a specific board
in mind, you could use those to runtime test this new v1.6. Those
emulators are usually good references.

For example, after locally modifying those defconfigs to use this new
OpenSBI version, you can use commands such as:

     make qemu_riscv64_virt_defconfig
     make
     output/images/start-qemu.sh

Or:

     make spike_riscv64_defconfig
     make
     board/spike/riscv64/start.sh

and check you can reach the user-space and the system login. You can
describe your test methodology in the cover letter (or patch note) to 
make
reviews faster for the maintainers. See for example [8].

> Best regards,
> Kilian
> 
> [1] https://github.com/riscv-software-src/opensbi/commit/
> bd613dd92113f683052acfb23d9dc8ba60029e0a
> [2] 
> https://gitlab.com/buildroot.org/buildroot/-/blob/master/boot/opensbi/
> Config.in?ref_type=heads#L21-22

Best regards,

Julien.

[3] 
https://gitlab.com/buildroot.org/buildroot/-/commit/c583befc8e92d0ae70d4fcb967bf8257ea94d577
[4] 
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/qemu_riscv32_virt_defconfig
[5] 
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/qemu_riscv64_virt_defconfig
[6] 
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/spike_riscv32_defconfig
[7] 
https://gitlab.com/buildroot.org/buildroot/-/blob/master/configs/spike_riscv64_defconfig
[8] 
https://patchwork.ozlabs.org/project/buildroot/patch/20240622114621.447904-1-ju.o@free.fr/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Kilian Zinnecker via buildroot]

Hello Julien, hello Mark, hello Alistair,

Mark and Alistair, I added you, because you are listed in the DEVELOPERS file 
for qemu_riscv64_virt_defconfig / OpenSBI - hope its ok ;)

[--SNIP--]
> This is correct. You can have a look how the previous versions
> were updated, for details. For example, see [3].
> This will update only the default "latest" OpenSBI version. Usually,
> defconfigs in Buildroot are using a specific, fixed custom version.

Thanks Julien! I locally adjusted the OpenSBI version number and the package's 
hash. Then I adjusted the used version of OpenSBI in the 
qemu_riscv64_virt_defconfig and started a build: The build was successfull, 
hence also the build of OpenSBI v1.6 worked. However, when I try to run 
output/images/start_qemu.sh I get the error, that ROM regions do overlap:

The following two regions overlap (in the memory address space):
  fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 
0x00000000000271e0)
  mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)

I guess, that the OpenSBI image had a different starting address in the past, 
leaving some space for mrom.reset? I double checked, and when building 
qemu_riscv64_virt_defconfig without modifying its OpenSBI version, it still 
works, so the problem must come from my changes. I am not so familiar with 
OpenSBI and also not with Qemu and hence was not able to find a solution to the 
problem yet.

I also tried building qemu_riscv64_virt_efi_defconfig, but that board seems to 
need a github login to fetch some package. I didn't look into this in much 
detail yet (e.g., whether it was my fault for some reason), but I am planning 
to have another look at that and then maybe sent a separate email for this 
issue.

Thanks and best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Julien Olivain]

Hi Kilian,

On 27/12/2024 19:31, Kilian Zinnecker via buildroot wrote:
> Hello Julien, hello Mark, hello Alistair,
> 
> Mark and Alistair, I added you, because you are listed in the 
> DEVELOPERS file
> for qemu_riscv64_virt_defconfig / OpenSBI - hope its ok ;)
> 
> [--SNIP--]
>> This is correct. You can have a look how the previous versions
>> were updated, for details. For example, see [3].
>> This will update only the default "latest" OpenSBI version. Usually,
>> defconfigs in Buildroot are using a specific, fixed custom version.
> 
> Thanks Julien! I locally adjusted the OpenSBI version number and the 
> package's
> hash. Then I adjusted the used version of OpenSBI in the
> qemu_riscv64_virt_defconfig and started a build: The build was 
> successfull,
> hence also the build of OpenSBI v1.6 worked. However, when I try to run
> output/images/start_qemu.sh I get the error, that ROM regions do 
> overlap:
> 
> The following two regions overlap (in the memory address space):
>   fw_jump.elf ELF program header segment 1 (addresses 
> 0x0000000000000000 -
> 0x00000000000271e0)
>   mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
> 
> I guess, that the OpenSBI image had a different starting address in the 
> past,
> leaving some space for mrom.reset? I double checked, and when building
> qemu_riscv64_virt_defconfig without modifying its OpenSBI version, it 
> still
> works, so the problem must come from my changes. I am not so familiar 
> with
> OpenSBI and also not with Qemu and hence was not able to find a 
> solution to the
> problem yet.

I was able to reproduce this issue.

I was also able to work around it by replacing "fw_jump.elf" by
"fw_jump.bin" in [1]. See also [2].

So, to summarize: it is OK to bump the default opensbi version to 1.6
in a commit (without touching the defconfigs) since we are able to
make it work in qemu with a workaround. IT might be a good idea to
add a reference to [2] in the commit log.

Since we learned that opensbi 1.6 no longer start our qemu defconfigs,
we could update those qemu_riscv{32,64}_virt_defconfigin in separate 
commits
to use opensbi 1.6, and also the corresponding
updating board/qemu/riscv{32,64}-virt/readme.txt which is used to 
generate
the output/images/start_qemu.sh script.

> I also tried building qemu_riscv64_virt_efi_defconfig, but that board 
> seems to
> need a github login to fetch some package. I didn't look into this in 
> much
> detail yet (e.g., whether it was my fault for some reason), but I am 
> planning
> to have another look at that and then maybe sent a separate email for 
> this
> issue.

This is a known issue. See [3] for some details.

> Thanks and best regards,
> Kilian

Best regards,

Julien.

[1] 
https://gitlab.com/buildroot.org/buildroot/-/blob/2024.11/board/qemu/riscv64-virt/readme.txt?ref_type=tags&plain=1#L3
[2] https://github.com/riscv-software-src/opensbi/issues/372
[3] 
https://gitlab.com/buildroot.org/buildroot/-/commit/47fc9e5509837260310cd7e41335fade29b587b1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Kilian Zinnecker via buildroot]

Hello Julien,

[--SNIP--]

> I was able to reproduce this issue.
> 
> I was also able to work around it by replacing "fw_jump.elf" by
> "fw_jump.bin" in [1]. See also [2].

Great, thanks!

> So, to summarize: it is OK to bump the default opensbi version to 1.6
> in a commit (without touching the defconfigs) since we are able to
> make it work in qemu with a workaround. IT might be a good idea to
> add a reference to [2] in the commit log.

I just sent a patch. I hope it is as expected. I added a "Tested-by" with your 
name and email - hope this is ok?

> Since we learned that opensbi 1.6 no longer start our qemu defconfigs,
> we could update those qemu_riscv{32,64}_virt_defconfigin in separate
> commits
> to use opensbi 1.6, and also the corresponding
> updating board/qemu/riscv{32,64}-virt/readme.txt which is used to
> generate
> the output/images/start_qemu.sh script.

Do you want to adjust the defconfigs or shall I give it a shot? If the later, 
shall I add you also with a signed-off-by to the patch, as if I assemlbe the 
patch, I heavily rely on the information you provided? 

[--SNIP--]

> This is a known issue. See [3] for some details.

Ah, thanks!

Best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Kilian Zinnecker via buildroot]

Hello Julien,

[--SNIP--]

> Do you want to adjust the defconfigs or shall I give it a shot? If the
> later, shall I add you also with a signed-off-by to the patch, as if I
> assemlbe the patch, I heavily rely on the information you provided?

I prepared a patch to also update the qemu board defconfigs. Will send it after 
the OpenSBI patch was accepted. Tell me, whether I should add your signed-off-
by as well.

Thanks and best regards,
Kilian


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [Help] How to bump a package, e.g., OpenSBI?

[Julien Olivain]

On 29/12/2024 12:40, Kilian Zinnecker wrote:
> Hello Julien,
> 
> [--SNIP--]
> 
>> Do you want to adjust the defconfigs or shall I give it a shot? If the
>> later, shall I add you also with a signed-off-by to the patch, as if I
>> assemlbe the patch, I heavily rely on the information you provided?
> 
> I prepared a patch to also update the qemu board defconfigs. Will send 
> it after
> the OpenSBI patch was accepted. Tell me, whether I should add your 
> signed-off-
> by as well.

You can send your patches, I just merged the opensbi-1.6 bump. There is 
no need
to add me in the "Signed-off-by". It will be added automatically by 
patchwork
if it's me merging the patch.

> Thanks and best regards,
> Kilian

Best regards,

Julien.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot