From: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL
Date: Sat, 9 Feb 2013 14:53:44 +0100 (CET) [thread overview]
Message-ID: <1769202195.1301597.1360418024882.JavaMail.root@advansee.com> (raw)
In-Reply-To: <8623173.1208999.1360367245269.JavaMail.root@advansee.com>
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?
Best regards,
Beno?t
next prev parent reply other threads:[~2013-02-09 13:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-08 22:49 [U-Boot] [PATCH v5 1/8] nand: mxc: Prepare to add support for i.MX5 Benoît Thébaudeau
2013-02-08 22:49 ` [U-Boot] [PATCH v5 2/8] nand: mxc: Add " Benoît Thébaudeau
2013-02-08 22:49 ` [U-Boot] [PATCH v5 3/8] imx: mx5: lowlevel_init: Simplify code Benoît Thébaudeau
2013-02-08 22:49 ` [U-Boot] [PATCH v5 4/8] imx: mx53ard: Add support for NAND Flash Benoît Thébaudeau
2013-02-08 22:49 ` [U-Boot] [PATCH v5 5/8] nand: mxc: Fix debug trace in mxc_nand_read_oob_syndrome() Benoît Thébaudeau
2013-02-08 22:49 ` [U-Boot] [PATCH v5 6/8] nand: mxc: Use appropriate page number in syndrome functions Benoît Thébaudeau
2013-02-08 22:49 ` [U-Boot] [PATCH v5 7/8] Makefile: u-boot-with-spl.bin: Pad to CONFIG_SPL_MAX_SIZE Benoît Thébaudeau
2013-02-08 22:49 ` [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL Benoît Thébaudeau
2013-02-08 23:47 ` Benoît Thébaudeau
2013-02-09 13:53 ` Benoît Thébaudeau [this message]
2013-02-09 16:38 ` Benoît Thébaudeau
2013-02-09 23:24 ` Marek Vasut
2013-02-10 0:02 ` Benoît Thébaudeau
2013-02-10 13:37 ` Benoît Thébaudeau
2013-02-12 13:45 ` Benoît Thébaudeau
2013-02-12 14:44 ` Stefano Babic
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=1769202195.1301597.1360418024882.JavaMail.root@advansee.com \
--to=benoit.thebaudeau@advansee.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