All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] pxa: Passing ATAGs to kernel don't work
Date: Wed, 17 Aug 2011 12:07:35 +0200	[thread overview]
Message-ID: <201108171207.35162.marek.vasut@gmail.com> (raw)
In-Reply-To: <4E4B915E.3080806@cit-ec.uni-bielefeld.de>

On Wednesday, August 17, 2011 12:01:02 PM Stefan Herbrechtsmeier wrote:
> Am 10.08.2011 12:47, schrieb Stefan Herbrechtsmeier:
> > Am 09.08.2011 21:46, schrieb Marek Vasut:
> >> On Tuesday, August 09, 2011 03:14:38 PM Stefan Herbrechtsmeier wrote:
> >>> Hi,
> >>> 
> >>> after porting my board support from u-boot 2009.11 to 2011.06
> >>> together with adding the relocation support
> >>> the ATAGs passing don't work any more.
> >>> 
> >>> I have add icache_disable() and dcache_disable()
> >>> to my board_init() like on other pxa boards.
> >>> 
> >>> It looks like the mapping of the Dcache as RAM is not cleared
> >>> and will be re-enabled by the kernel.
> >> 
> >> Thanks for tracing this, can you submit a patch ?
> > 
> > I have only avoid the problem and don't really fix the problem,
> > as I am not familiar with the MMU configuration and the relocation.
> > 
> > I think the right solution will be to clean up the MMU at the end of the
> > relocation
> > and maybe disable it, instead of doing this at board_init().
> > 
> > Should it be functional to add the following MMU initialisation from an
> > other start.S
> > after the clear_bss in start.S or should it be enough to flush the TLB
> > and disable the D-cache?
> > 
> > clear_mmu:
> >       /*
> >       
> >        * flush v4 I/D caches
> >        */
> >       
> >       mov    r0, #0
> >       mcr    p15, 0, r0, c7, c7, 0    /* flush v3/v4 cache */
> >       mcr    p15, 0, r0, c8, c7, 0    /* flush v4 TLB */
> >       
> >       /*
> >       
> >        * disable MMU stuff and caches
> >        */
> >       
> >       mrc    p15, 0, r0, c1, c0, 0
> >       bic    r0, r0, #0x00002300    @ clear bits 13, 9:8 (--V- --RS)
> >       bic    r0, r0, #0x00000087    @ clear bits 7, 2:0 (B--- -CAM)
> >       orr    r0, r0, #0x00000002    @ set bit 2 (A) Align
> >       orr    r0, r0, #0x00001000    @ set bit 12 (I) I-Cache
> >       mcr    p15, 0, r0, c1, c0, 0
> > 
> > If I understand the code correct, the command is wrong, as the I-Cache
> > is enabled.
> 
> I looks like the main fault was the missing flush during cache disable
> because
> flush_cache() is empty for the pxa architecture.

Check Hong Xu's efforts on ARM926EJS caches ... maybe you can implement the 
flushing for pxa :)

> 
> I have add a define CONFIG_SYS_INIT_RAM_ADDR for the initial RAM in cache.
> Additional I have fix the define of CONFIG_SYS_INIT_SP_ADDR.
> I have move the dcache und mmu disable to the start.S at the end of the
> relocation
> and add a flush. This prevent people to enable the dcache by removing the
> dcache_disable() without setup the MMU correct.
> 
> >>> If I change the initial RAM mapping from first SDRAM partition start
> >>> address to second unused SDRAM partition start address the ATAGs
> >>> passing works.
> >>> 
> >>> Can somebody confirm that the ATAGs passing works on u-boot 2011.06 for
> >>> a pxa board.
> >>> 
> >>> Is there any reason, that the initial RAM is mapped to SDRAM start
> >>> address range?
> >> 
> >> I think now it can be changed. Maybe there was something about OneNAND
> >> IPL, I'm not really sure anymore.
> > 
> > What is the best value to use for the initial RAM address mapping?
> 
> I am now using 0xc0000000 as it is above the SDRAM range,
> but 0xa0000000 now works as well.

Ack
> 
> >>> Addition there is a bug in pxa_dram_init as it is called before
> >>> relocation and want to trigger some refresh cycles by write some
> >>> values to the SDRAM start address range but instead writes to the
> >>> mapped initial RAM.
> >> 
> >> Patch is welcome please.
> > 
> > Or should I keep the initial RAM mapping to SDRAM  start address
> > and move the SDRAM refresh cycles trigger address behind the mapped area.
> 
> I leave it as it is, because I move the initial RAM address.
> 
> I will commit patches for this and some USB host and device fixes,
> when I have some time to port my change to the git HEAD and
> change all pxa boards accordingly.

Thanks!
> 
> Regards,
>      Stefan

      reply	other threads:[~2011-08-17 10:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-09 13:14 [U-Boot] pxa: Passing ATAGs to kernel don't work Stefan Herbrechtsmeier
2011-08-09 19:46 ` Marek Vasut
2011-08-10 10:47   ` Stefan Herbrechtsmeier
2011-08-17 10:01     ` Stefan Herbrechtsmeier
2011-08-17 10:07       ` Marek Vasut [this message]

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=201108171207.35162.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.