Re: hw/misc/aspeed_scu: 5d971f9e breaks Supermicro AST2400

[Joel Stanley]

On Wed, 1 Jul 2020 at 01:23, Ryan Chen <ryan_chen@aspeedtech.com> wrote:

> On Tue, 30 Jun 2020 at 15:32, Erik Smit <erik.lucas.smit@gmail.com> wrote:
> >
> > Hi Philippe,
> >
> > On Tue, 30 Jun 2020 at 17:29, Philippe Mathieu-Daudé <f4bug@amsat.org> 
> > wrote:
> > >
> > > Hi Erik,
> > >
> > > On 6/30/20 5:11 PM, Erik Smit wrote:
> > > > Hello,
> > > >
> > > > 5d971f9e memory: Revert "memory: accept mismatching sizes in
> > > > memory_region_access_valid" breaks Supermicro AST2400 u-boot.
> > > > Supermicro AST2500 u-boot is fine.
> > > >
> > > > The u-boot tries to make a 2-byte read from address 0x84, but
> > > > aspeed_ast2400_scu_ops has min_access = 4. When I change
> > > > min_access to
> > > > 2 or revert above commit, u-boot boots again.
> > > >
> > > > Is changing min_access to 2 the right way to fix this?
>
> Ryan, do all addresses on the AST2400's APB respond to single byte accesses?

>         Most register is not support byte access, it need to refer the 
> datasheet descript each area. [chapter : ARM Address Space Mapping]

Thanks Ryan.

Summarising that table:

 - most addresses are 4 byte write accesses.
 - all addresses support 1/2/4 byte reads.

The regions that accept 1/2/4 byte access are the SDRAM, SRAM,
ethernet MACs, video engine, the flash controller regions (2000_0000
-> 2FFF_FFFF and 3000_0000 -> 3FFF_FFFF), and the AHB to LPC bridges
(6000_0000 -> 6FFF_FFFF and 7000_0000 -> 7FFF_FFFF).

We don't model the AHB to LPC bridges in qemu, nor the legacy flash
controller region at 1000_0000 -> 15FF_FFFF.

> > >
> > > If you have access to the datasheet and can verify, then yes.
> > > Else I suppose Cédric, Andrew or Joel can check for you.
> >
> > I do not have a datasheet. Aspeed seems quite picky about sharing this
> > and I'm just a random researcher.
>
> Erik, can you point us to the image you're using?
>
> What is the command line are you testing with?
>
> Happy to fix the model to support random firmwares, as long as the fix is 
> correct for other (open source) firmwares.
>
> >
> > Best regards,
> >
> > Erik Smit