On 5/28/2026 1:05 PM, Philippe Mathieu-Daudé wrote: > On 28/5/26 22:01, Pierrick Bouvier wrote: >> On 5/28/2026 12:56 PM, Philippe Mathieu-Daudé wrote: >>> On 28/5/26 21:40, Pierrick Bouvier wrote: >>>> On 5/27/2026 1:13 PM, Philippe Mathieu-Daudé wrote: >>>>> Rather than adapting the array endianness when it it >>>>> filled, directly initialize the CODE words with the >>>>> correct endianness. >>>>> >>>>> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> >>>>> --- >>>>> hw/riscv/boot.c | 30 +++++++++++++----------------- >>>>> 1 file changed, 13 insertions(+), 17 deletions(-) >>>>> >>>> >>>> One could argue original version is more readable. >>>> Any specific reason for rewriting things this way (performance, >>>> personal >>>> preference, other)? >>>> Not a blocker, just want to understand the original motivation. >>> >>> Looking at the following changes, I think it makes more sense to >>> have the CODE section const little-endian, while the DATA section >>> is swapped. Otherwise we'd need 2 distinct loops. >>> >> >> In this case, having two distinct arrays, and two distinct loops might >> be more clear IMHO. >> The function is called only once, we can afford this. > > This was my first approach until I realized this array is > registered with rom_add_blob_fixed_as(). > > We could register 2 distincts arrays, mrom.reset.code and > mrom.reset.rodata. Now than the patch is written & reviewed, > it sure it is worth it.
Not blocking for sure, things can be enhanced and refactored later.
