On 10/24/24 19:59, Philippe Mathieu-Daudé wrote:
Cc'ing Jan.
On 22/10/24 12:04, Guenter Roeck wrote:
On 10/21/24 21:09, Philippe Mathieu-Daudé wrote:
Hi Guenter,
On 21/10/24 11:02, Guenter Roeck wrote:
Unrelated to this, but I found that the sd emulation in 9.1 is also broken
for loongarch and sifive_u, and partially for ast2600-evb (it has two
controllers, with one of them no longer working). That is too much for me
to track down quickly, so this is just a heads-up.
It would greatly help if we could merge some of your testsuite under QEMU.
Please Cc me with reproducer or assign Gitlab issues to me,
I'll have a look.
If it wasn't funny, it would be sad.
hw/sd/sd.c:sd_reset() calls sd_bootpart_offset() t determine the boot partition
offset. That function needs to have sd->ext_csd[EXT_CSD_PART_CONFIG] configured.
However, the value is only set later in sd_reset() with the call to
sc->set_csd().
One of the parameters of that function is the previously calculated size.
So in other words there is a circular dependency. The call to
sd_bootpart_offset()
returns 0 because sd->ext_csd[EXT_CSD_PART_CONFIG] isn't set, then
the call to sc->set_csd() sets it ... too late. Subsequent calls to
sd_bootpart_offset() will then return the expected offset.
oh. I didn't realize that :/ I guess we only tested our own scenario when
we were working on the ast2600 bringup.
I think the change in the reset handler should be :
- size -= sd_bootpart_offset(sd);
+ if (sd_is_emmc(sd)) {
+ size -= sd->boot_part_size * 2;
+ }
Thanks,
C.
I have no idea how this is supposed to work, and I don't think it works
as implemented. I'll revert commit e32ac563b83 in my local copy of qemu.
> Jan, can you have a look at this bug report please? Otherwise I'll
have a look during soft freeze.
Regards,
Phil.
