[U-Boot-Users] AT91 with framebuffer in SDRAM

[Zac Wheeler]

On 10/23/07, Ulf Samuelsson <ulf at atmel.com> wrote:
> > On 10/22/07, Ulf Samuelsson <ulf at atmel.com> wrote:
> >>
> >> The environment variables should be stored in flash, not in SDRAM.
> >> - Even if you execute from SDRAM.
> >>
> >> What type of flash are you using.
> >> My stuff is there to support dataflash, and anything else
> >> get little or no testing.
> >
> > I am using dataflash for everything. Everything is pretty equivalent
> > to your code base, just the LCD timing values and the fb_base have
> > changed.
> >
>
> > Maybe I should rephrase. Everything seems fine once it is in
> > dataflash. But if I `setenv bootcmd something' and then `saveenv`, it
> > says "saving to dataflash...". `printenv` prints back the correct
> > value (bootcmd=something), which I understand it isn't actually
> > reloading from dataflash. If I then reset the board that
> > bootcmd=something is gone. The environment variables are not in
> > protected dataflash.
> >
> > In board/at91sam9261ek/at91sam9261ek.c
> > If I change
> > gd->fb_base = (unsigned long) PHYS_SDRAM  + 0x10000;
> > back to
> > gd->fb_base = (unsigned long) AT91C_IRAM;
> > the LCD goes wonky but saving to dataflash works again.
>
> Don't know if this is the problem, but you can at least try it:
>
> The main difference I can see is that when you put the framebuffer in
> external SDRAM, you are affecting the bus bandwidth.
> When doing the LCD from internal SRAM, you have zero access.
>
> Consider changing the speed of the SPI to much lower speed (1 Mbps).
> If this works, then increase the speed, until you see the problem.
> Reduce to something lower.

This did the trick, thanks Ulf. I'm using 8 MHz as it seems stable.

>
> An alternative is to link the environment into the internal SRAM.
> Then the SPI transfer will not be affected by the LCD refresh.

I couldn't take this approach because this only sort of skirts the
problem. If I did something else (e.g. used u-boot to upgrade itself)
it would corrupt the write and then I'm back to JTAG to reload it.

>
> Ensure that you run the SPI in mode 0, dont ask me why
>

I won't :)

>
> >
> > The problem is that my framebuffer needs to be 384k, which is too big
> > for the internal ram.  Looking at what I just wrote it seems that
> > maybe it is the writes to dataflash that are breaking, and not
> > actually parts of the SDRAM getting corrupted.
> >
> > Zac
> >
>
>
> Best Regards
> Ulf Samuelsson
>
>

Thanks again,
Zac