Hello Siarhei!
I'm still catching up in my understanding of the concepts and inner
workings of the fel utility and its relationship with the BROM code.
Thanks to your detailed explanations, the picture has gotten a lot clearer.
What's the expected usage (required size in bytes) of the scratch area
for ARM code used internally by the fel utility? My impression is that a
relatively small size is sufficient, so I could imagine setting aside a
separate SRAM region (".scratch_internal") exclusively reserved for
"internal" usage by sunxi-fel. That way side effects on the "user"
scratch area may be avoided. I recognize that this is somewhat pointless
after moving scratch_addr "out of harm's way" below 0x2000 - just
playing with ideas here...
Looking at the new memory / SRAM buffer mappings, I notice a 'gap' of
0x200 bytes in most layouts, just below the .thunk_addr. On
A10/A13/A20/H3 that would be 0xA000 to 0xA1FF, on A31 0x22C00 to
0x22DFF, A64: 0x1AC00-0x1ADFF, and 0x46C00-0x46DFF on the other SoCs.
The only exception so far is Jens Kuske's A80 patch, which places
.thunk_addr = 0x23400 immediately after the swap buffers.
Is that area meant to be some safety margin in case the thunk code stack
grows below .thunk_addr, or actually unused? Might this be a candidate
for a ".scratch_internal" (or even all scratch usage by the fel
utility)? As an experiment, I have set ".scratch_addr = 0xA000" on an
A20, and didn't notice negative side effects.
Regards, B. Nortmann
--
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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
