On Sun, 18 May 2014 20:41:59 +0200
Henrik Nordström <hen...@henriknordstrom.net> wrote:
> fre 2014-05-16 klockan 22:59 +0300 skrev Siarhei Siamashka:
>
> > Do we have some sort of a BROM USB driver running alongside with
> > our SPL in the FEL mode? At least the stack base is set so that
> > we don't have too much SRAM available for SPL.
>
> The FEL binary is only responsible for initializing the DRAM. All USB is
> managed by BROM.
Yeah, that's exactly what I'm telling you. The BROM USB driver does
not just magically work, but very likely needs some part of SRAM for
itself at least for its temporary buffers.
My question was whether you possibly know the exact SRAM memory layout
in the FEL mode and the areas possibly reserved by BROM. If you don't
really know, then we always have the BROM disassembly listings if
somebody is really curious.
> Basic order is
>
> BROM connection established
> Upload FEL binary to SRAM
> Execute FEL binary in SRAM to configure the board for DRAM access
> Upload u-boot.bin to DRAM
> Execute u-boot.
>
> > When doing experiments with the DRAM initialization code, I want
> > to be able to do various things. For example, calculating the
> > timings (converting nanoseconds to cycles) right in the SPL instead
> > of having this stuff pre-computed and tabulated. Another example of
> > a moderate SRAM space user is the DRAM calibration code for finding
> > optimal parameters. And extra debugging code with verbose messages
> > can also use up a lot of space.
>
> Last time I looked there was plenty of space left in FEL even with full
> printf enabled.
I'm glad to know that there is plenty of space left there for *you*.
But just like described in the quoted paragraph above, *I* am adding
a lot of *new* code there. And *I* am getting very close to the
available SRAM size limit.
> > Most importantly, when we are running out of space, the code starts
> > to misbehave in unpredictable ways. It is not like we are getting a
> > a nice and helpful error message in this case. So what's wrong
> > with just having more headroom?
>
> The linking fails if we run out of space, unless there is an error in
> the fel lds script.
You can check the fel lds script yourself:
https://github.com/linux-sunxi/u-boot-sunxi/blob/44b53fd3928f/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
It does not use the MEMORY command to describe the size limits.
But now consider the following. The FEL SPL binary is loaded at the
address 0x2000 (which is also the entry point), and the stack pointer
is set to 0x5E00 on A20 right at the start. This gives us around 15872
bytes for everything (code, data, bss and stack). And also have a look
here to see how much of it is already used up:
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04883.html
If the compiled FEL SPL binary is too large, the stack is starting to
overwrite the useful data, causing all kind of bugs.
Again, the question is whether it is safe to use SRAM below 0x2000
and/or above 0x5E00. Maybe the stack can be relocated somewhere else?
But regardless of where the stack is located, not using Thumb2 is
too generous and wasteful.
In any case, it has been already agreed that this patch is not
going into the u-boot-sunxi repository. For the time being, I can
use it in my own fork perfectly fine. So you have nothing to worry
about :-)
--
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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
