From: Ulf Samuelsson <ulf@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] AT91 with framebuffer in SDRAM
Date: Tue, 23 Oct 2007 22:14:27 +0200 [thread overview]
Message-ID: <015b01c815be$c86a7a50$7b00000a@atmel.com> (raw)
In-Reply-To: 206b9e70710231256v2416675bw857cb8f508bc2394@mail.gmail.com
> 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
next prev parent reply other threads:[~2007-10-23 20:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-22 23:21 [U-Boot-Users] AT91 with framebuffer in SDRAM Zac Wheeler
2007-10-23 4:05 ` [U-Boot-Users] Idle mode example for at91rm9200 Leonid
2007-10-23 5:24 ` [U-Boot-Users] AT91 with framebuffer in SDRAM Ulf Samuelsson
2007-10-23 19:56 ` Zac Wheeler
2007-10-23 20:14 ` Ulf Samuelsson [this message]
2007-10-25 22:13 ` Zac Wheeler
2007-10-26 5:51 ` Ulf Samuelsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='015b01c815be$c86a7a50$7b00000a@atmel.com' \
--to=ulf@atmel.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox