On Sat, 19 Mar 2016 18:29:40 +0100
Bernhard Nortmann <[email protected]> wrote:
> Am 17.03.2016 um 13:55 schrieb Bernhard Nortmann:
> >
> > I can confirm/reproduce this behaviour on my A20 when accessing the
> > SID register. Interesting enough, the bytes that actually do get read
> > (i.e. end up != 0) are "correct", as if the aw_usb_read() somehow
> > truncates everything down to single-byte range:
> >
> > sunxi-tools # ./sunxi-fel hexdump 0x01c23800 16
> > 01c23800: 4f 00 00 00 86 00 00 00 48 00 00 00 e9 00 00 00
> >
>
> Btw: This "MSB zero" problem doesn't seem related to the FEL protocol in
> any way, but looks like a more general hardware limitation. U-Boot's
> memory display exposes the very same quirk when not accessing the SID
> registers as "long" (i.e. 32-bit) values:
>
> => md.l 0x01c23800 4
> 01c23800: 1651664f 80485686 53504848 0702dde9 OfQ..VH.HHPS....
> => md.w 0x01c23800 8
> 01c23800: 664f 0000 5686 0000 4848 0000 dde9 0000 Of...V..HH......
> => md.b 0x01c23800 10
> 01c23800: 4f 00 00 00 86 00 00 00 48 00 00 00 e9 00 00 00 O.......H.......
Yes, it's a well known fact about accessing hardware registers in
general. Because partial read/write of such 32-bit hardware registers
makes no sense, the hardware does not need to be excessively
complicated and is allowed to talk back only when getting exact
match on the address bus.
The commit message was only speculating about the FEL implementation
in the BROM, which is very likely relying on a naive "one byte at a
time" memcpy implementation here.
So we need to introduce these extra helper functions to read/write
32-bit values because the basic FEL protocol can't provide the needed
functionality. These helper functions have a very broad use, starting
from just reading the SID value (it is simple and easy to verify
example) or asserting/deasserting the OpenRISC core reset. And
potentially ending even with implementing or prototyping some bigger
drivers for the hardware via some sort of RPC MMIO approach.
Also because we need to upload and execute some code for implementing
this, we have to review how the SRAM memory is managed. That's what the
rest of this patch series is all about (move the scratch area under the
IRQ stack, support 40KiB SPL size for making future improvements
possible, avoid clashing with the SRAM area reserved for the OpenRISC
firmware).
Regarding the SRAM memory layout in the FEL mode, the following wiki
page provides some information:
https://linux-sunxi.org/SRAM_dumps_from_A13_in_FEL_mode
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
