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

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

[Zac Wheeler]

Hi,

I'm trying to cobble together a proto with the AT91SAM9261EK and a WVGA TFT
screen using Ulf's 1.2.0-atmel branch. I have gotten the screen to work just
fine. The problem is that I need to operate out of SDRAM, and I'm trashing
the environment variables somehow. The environment variables are at
PHYS_SDRAM + 0x100 and are 0x2000 long so I have tried PHYS_SDRAM + several
larger numbers (0x10000, 0x20000, 0x100000) for fb_base but all result in
corrupt environment variables when I try to save them. I believe that I am
staying out of u-boot's operating RAM (0x23f00000+ correct?), but I could be
mistaken.

The symptom is the constantly-recurring bad CRC warning and saveenv appears
to have no effect. The settings seem to be working fine when I switch
fb_base back to AT91C_IRAM, but obviously the display doesn't function
properly. I've looked through for obvious mistakes in writing the logo and
text below the logo to the fb but haven't been able to track anything down.

Also, as an aside, I think that the vl_pixclock variable is used incorrectly
in the at91sam926X files. It is supposed to be (from the definition) in
picoseconds but appears to only work in Hz.

Any help is appreciated.

Thanks,
Zac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20071022/10d3b095/attachment.htm 

[U-Boot-Users] Idle mode example for at91rm9200.

[Leonid]

Hi:

I need to test Idle mode for Atmel at91rm9200 CPU.

Does anybody have "ready to go" code for that purpose which can be
compiled as part of u-boot or as standalone application (running after
u-boot or as a first code on the board)?

Any additional information on this subject is also appreciated.

Thanks,

Leonid.

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

[Ulf Samuelsson]

> Hi,
>
> I'm trying to cobble together a proto with the AT91SAM9261EK and a WVGA 
> TFT
> screen using Ulf's 1.2.0-atmel branch. I have gotten the screen to work 
> just
> fine. The problem is that I need to operate out of SDRAM, and I'm trashing
> the environment variables somehow. The environment variables are at
> PHYS_SDRAM + 0x100 and are 0x2000 long so I have tried PHYS_SDRAM + 
> several
> larger numbers (0x10000, 0x20000, 0x100000) for fb_base but all result in
> corrupt environment variables when I try to save them. I believe that I am
> staying out of u-boot's operating RAM (0x23f00000+ correct?), but I could 
> be
> mistaken.
>

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.

> The symptom is the constantly-recurring bad CRC warning and saveenv 
> appears
> to have no effect. The settings seem to be working fine when I switch
> fb_base back to AT91C_IRAM, but obviously the display doesn't function
> properly. I've looked through for obvious mistakes in writing the logo and
> text below the logo to the fb but haven't been able to track anything 
> down.
>
> Also, as an aside, I think that the vl_pixclock variable is used 
> incorrectly
> in the at91sam926X files. It is supposed to be (from the definition) in
> picoseconds but appears to only work in Hz.
>
> Any help is appreciated.
>
> Thanks,
> Zac
>


Best Regards
Ulf Samuelsson

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

[Zac Wheeler]

On 10/22/07, Ulf Samuelsson <ulf@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.

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

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

[Ulf Samuelsson]

> On 10/22/07, Ulf Samuelsson <ulf@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.

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

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


> 
> 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

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

[Zac Wheeler]

On 10/23/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> > On 10/22/07, Ulf Samuelsson <ulf@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

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

[Ulf Samuelsson]

> On 10/23/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>> > On 10/22/07, Ulf Samuelsson <ulf@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.
> 

I think that you should still do this.
You may need to do a slight modification to U-Boot
so that the dataflash write driver copies a chunk of data to
the internal SRAM before it writes it to the dataflash.

The CPU is sitting idling while waiting for the PDC to complete the SPI transfer anyway.

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57