From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= <benoit.thebaudeau@advansee.com>
Date: Sun, 10 Feb 2013 01:02:58 +0100 (CET)
Subject: [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic
	SPL
In-Reply-To: <201302100024.04728.marex@denx.de>
References: <1360363767-8658-1-git-send-email-benoit.thebaudeau@advansee.com>
	<1769202195.1301597.1360418024882.JavaMail.root@advansee.com>
	<498559314.1303951.1360427906372.JavaMail.root@advansee.com>
	<201302100024.04728.marex@denx.de>
Message-ID: <744475063.1305237.1360454578156.JavaMail.root@advansee.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Marek Vasut,

On Sunday, February 10, 2013 12:24:04 AM, Marek Vasut wrote:
> Dear Beno?t Th?baudeau,
> 
> > On Saturday, February 9, 2013 2:53:44 PM, Beno?t Th?baudeau wrote:
> > > On Saturday, February 9, 2013 12:47:25 AM, Beno?t Th?baudeau wrote:
> > > > On Friday, February 8, 2013 11:49:27 PM, Beno?t Th?baudeau wrote:
> > > > > Subject: [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL
> > > > > 
> > > > > Signed-off-by: Beno?t Th?baudeau <benoit.thebaudeau@advansee.com>
> > > > > ---
> > > > > 
> > > > > Changes in v5:
> > > > >  - Remove spaces between function name and open parenthesis.
> > > > >  - Fix mx31pdk and tx25 Makefile-s and SPL linker scripts.
> > > > >  - Remove the useless definition of CONFIG_SPL_LDSCRIPT.
> > > > >  - Fix the call to nand_boot().
> > > > > 
> > > > > Changes in v4:
> > > > >  - New patch.
> > > > > 
> > > > > Changes in v3: None
> > > > > Changes in v2: None
> > > > 
> > > > This is now supposed to be working and compile-tested.
> > > > 
> > > > Custodians, please review and advise.
> > > > 
> > > > Board maintainers, please test.
> > > > 
> > > > Tell me if I should split away some stuff.
> > > > 
> > > > Should doc/README.arm-relocation be updated, and how since tx25 no
> > > > longer uses
> > > > NAND SPL, which is also deprecated?
> > > > 
> > > > Note that mx31pdk and tx25 had been broken by commit
> > > > e05e5de7fae5bec79617e113916dac6631251156. After this commit, for those
> > > > boards,
> > > > _main called board_init_f, which called relocate_code, which
> > > > unexpectedly (for
> > > > their users) returned to nowhere in ctr0.S instead of calling
> > > > nand_boot. Also,
> > > > crt0.S calls nand_boot if CONFIG_SPL_BUILD is not defined but
> > > > CONFIG_NAND_SPL
> > > > is, which is not normal for NAND SPL. Other NAND SPL boards may be
> > > > broken too,
> > > > but that's not too much of an issue since they are supposed to migrate
> > > > to generic SPL.
> > > 
> > > I am also wondering if board_init_f should not be moved out of
> > > mxc_nand_spl.c to
> > > either <board>/lowlevel_init.S or <board>/<board>.c. That would make
> > > mxc_nand_spl.c more generic if for some reason a board needs to do
> > > specific things. Any opinion?
> > > 
> > > For the start.S files, since it's not possible to know from
> > > CONFIG_SPL_BUILD and
> > > CONFIG_NAND_SPL if relocate_code is needed or not, I see the following
> > > choices:
> > > 1) Let it defined in all cases. It's quite small, so it won't hurt much.
> > > 2) Create a specific SPL #define (e.g. CONFIG_SPL_RELOCATE_CODE) to
> > > define it
> > > 
> > >    for generic SPL only if needed.
> > > 
> > > 3) Just create a specific linker section for it so that it's
> > > automatically
> > > 
> > >    garbage-collected if unneeded.
> > > 
> > > Any opinion?
> 
> How much of start.S can be actually rewritten in pure-C ?

I would say only relocate_code(). Apart from this function, start.S only deals
with preprocessor register accesses and IRQ / exception handling that require
assembly.

As to relocate_code(), it would still be tricky in pure C because it mixes
absolute addresses with position-independent code and data accesses, so one
would have to be very careful about the C coding of this function in order to
avoid a dependency on compiler choices. Having it written in assembly guarantees
a correct result and emphasizes the absolute/relative access constraints for
easier maintenance.

But this is only my opinion.

Best regards,
Beno?t