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] RFC: U-Boot OneNAND IPL TEXT_BASE
Date: Sun, 2 May 2010 17:21:39 +0200	[thread overview]
Message-ID: <201005021721.39707.marek.vasut@gmail.com> (raw)
In-Reply-To: <z2n9c9fda241005020407j931b5f9v1b12672c515a8363@mail.gmail.com>

Dne Ne 2. kv?tna 2010 13:07:13 Kyungmin Park napsal(a):
> On Sun, May 2, 2010 at 3:39 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > Dne Ne 2. kv?tna 2010 05:54:41 Kyungmin Park napsal(a):
> >> Hi,
> >> 
> >> Which CPU do you use? In most ARM cpu, CPU load the IPL into its
> >> internal SRAM, and runs at here.
> > 
> > PXA270 ... the BootRAM is mapped to 0x0 and the code runs from there.
> > 
> >> But in your case it's not. So you maybe redefine IPL address.
> >> 
> >> Instead of modifying the config.mk, how about to define IPL_TEXT_BASE.
> >> 
> >> e.g.,
> >> 
> >> In OneNAND IPL code,
> >> 
> >> #ifndef BOARD_IPL_TEXT_BASE
> >> #define ONENAND_IPL_TEXT_BASE BOARD_IPL_TEXT_BASE
> >> #endif
> > 
> > That won't help -- TEXT_BASE is used while compiling start.S (to setup
> > stack under TEXT_BASE) and the config.mk prepares the gcc options for
> > start.S (the TEXT_BASE is defined in the gcc options).So modifying
> > config.mk is unavoidable I fear.
> 
> Sorry my mistake. It's already supported at current drivers. Now I
> works on s5pc100 and s5pc110 and each define it's TEXT_BASE at
> onenand_ipl/board/samsung/${board_name}/config.mk. and it's used at
> start.S
> 
I noticed the config.mk in onenand-ipl/board/... were meant to be used, but in 
my case, those were not used. Instead, the board/... config.mk was used (and 
from what I saw in config.mk, that's understandable).

Also, see the Makefile in onenand-ipl/board/apollon/Makefile -- onenand-
ipl/board/apollon/config.mk defines the TEXT_BASE in Makefile, but right before 
that it includes the system-wide config.mk, which configures the compiler 
options and amongst those is -DTEXT_BASE and that one is set to one defined in 
board/apollon/config.mk . Obviously when compiling start.S, that one is used.

Cheers

> No need to modify config.mk and Makefile. If you need I can't send a
> sample files to you.
> 
> Thank you,
> Kyungmin Park
> 
> > The thing we can do is define STACK_TOP_BASE and that'd certainly do the
> > trick! This would allow me to point stack into SRAM, while running the
> > IPL code from BootRAM. Of course, in case STACK_TOP_BASE wasn't defined,
> > it'd fall back to the old code in start.S. This would of course work
> > without modifying config.mk and I start to like such a solution.
> > 
> > Hm?
> > 
> >> load IPL code ONENAND_IPL_TEXT_BASE instead of current code.
> >> 
> >> Thank you,
> >> Kyungmin Park
> > 
> > Thanks!
> > 
> >> On Sat, May 1, 2010 at 11:48 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> > Hey,
> >> > 
> >> > I've been tinkering with OneNAND IPL in uboot. I found out it wan't to
> >> > load itself to the address specified in board/$(BOARDDIR)/config.mk .
> >> > That's fine in most cases, but in my case that wasn't possible.
> >> > 
> >> > In my case, SDRAM init didn't fit into the IPL, so I had to copy
> >> > U-Boot into SRAM, then execute it and let it relocate itself into
> >> > SDRAM. One more time: IPL: OneNAND->SRAM
> >> > U-Boot: SRAM->SDRAM
> >> > 
> >> > It all works fine, but when compiling the IPL, I had to alter
> >> > TEXT_BASE not to point into SDRAM but SRAM too (because of stack). I
> >> > introduced a variable called IPL which allows using config.mk from
> >> > (for example) onenand-
> >> > ipl/board/$(BOARDDIR)/config.mk rather than the
> >> > board/$(BOARDDIR)/config.mk one, which is in my opinion a correct
> >> > behaviour.
> >> > 
> >> > Any opinions?
> >> > 
> >> > Thanks in advance.
> >> > 
> >> > diff --git a/config.mk b/config.mk
> >> > index 73b5195..8639580 100644
> >> > --- a/config.mk
> >> > +++ b/config.mk
> >> > @@ -130,9 +130,13 @@ BOARDDIR = $(VENDOR)/$(BOARD)
> >> >  else
> >> >  BOARDDIR = $(BOARD)
> >> >  endif
> >> > +ifdef  IPL
> >> > +sinclude $(TOPDIR)/$(IPL)/board/$(BOARDDIR)/config.mk  # include IPL
> >> > specific rules
> >> > +else
> >> >  ifdef  BOARD
> >> >  sinclude $(TOPDIR)/board/$(BOARDDIR)/config.mk # include board
> >> > specific rules endif
> >> > +endif
> >> > 
> >> >  #####################################################################
> >> > ### #
> >> > 
> >> > _______________________________________________
> >> > U-Boot mailing list
> >> > U-Boot at lists.denx.de
> >> > http://lists.denx.de/mailman/listinfo/u-boot

      reply	other threads:[~2010-05-02 15:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-01  2:48 [U-Boot] RFC: U-Boot OneNAND IPL TEXT_BASE Marek Vasut
2010-05-02  3:54 ` Kyungmin Park
2010-05-02  6:39   ` Marek Vasut
2010-05-02 11:07     ` Kyungmin Park
2010-05-02 15:21       ` 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=201005021721.39707.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.