From: Mark Jackson <mpfj-list@newflow.co.uk>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
Date: Fri, 23 Aug 2013 10:28:29 +0100 [thread overview]
Message-ID: <52172B3D.80601@newflow.co.uk> (raw)
In-Reply-To: <1375161535-29884-4-git-send-email-lokeshvutla@ti.com>
On 30/07/13 06:18, Lokesh Vutla wrote:
> From: Heiko Schocher <hs@denx.de>
>
> s_init has the same outline for all the AM33xx based
> board. So making it generic.
> This also helps in addition of new Soc with minimal changes.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Signed-off-by: Tom Rini <trini@ti.com>
<snip>
This patch introduces the following new function call ...
> +void s_init(void)
> +{
> + /*
> + * The ROM will only have set up sufficient pinmux to allow for the
> + * first 4KiB NOR to be read, we must finish doing what we know of
> + * the NOR mux in this space in order to continue.
> + */
> +#ifdef CONFIG_NOR_BOOT
> + enable_norboot_pin_mux();
> +#endif
... which replaces the old code ...
> - /*
> - * The ROM will only have set up sufficient pinmux to allow for the
> - * first 4KiB NOR to be read, we must finish doing what we know of
> - * the NOR mux in this space in order to continue.
> - */
> -#ifdef CONFIG_NOR_BOOT
> - asm("stmfd sp!, {r2 - r4}");
> - asm("movw r4, #0x8A4");
> - asm("movw r3, #0x44E1");
> - asm("orr r4, r4, r3, lsl #16");
> - asm("mov r2, #9");
> - asm("mov r3, #8");
> - asm("gpmc_mux: str r2, [r4], #4");
> - asm("subs r3, r3, #1");
> - asm("bne gpmc_mux");
> - asm("ldmfd sp!, {r2 - r4}");
> -#endif
Now (for the TI boards) enable_norboot_pin_mux() is defined as:-
> +#if defined(CONFIG_NOR_BOOT)
> +static struct module_pin_mux norboot_pin_mux[] = {
> + {OFFSET(lcd_data1), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data2), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data3), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data4), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data5), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data6), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data7), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data8), MODE(1) | PULLUDDIS},
> + {OFFSET(lcd_data9), MODE(1) | PULLUDDIS},
> + {-1},
> +};
> +
> +void enable_norboot_pin_mux(void)
> +{
> + configure_module_pin_mux(norboot_pin_mux);
> +}
> +#endif
Firstly, this pinmux code seems wrong, since lcd_data pin map:-
lcd_data1 (mode 1) => gpmc_a1_mux1
lcd_data2 (mode 1) => gpmc_a2_mux1
lcd_data3 (mode 1) => gpmc_a3_mux1
lcd_data4 (mode 1) => gpmc_a4_mux1
lcd_data5 (mode 1) => gpmc_a5_mux1
lcd_data6 (mode 1) => gpmc_a6_mux1
lcd_data7 (mode 1) => gpmc_a7_mux1
lcd_data8 (mode 1) => gpmc_a12_mux1
lcd_data9 (mode 1) => gpmc_a13_mux1
Doesn't this leave gpmc_a[8..11] unconfigured ?
Shouldn't we configure lcd_vsync, lcd_hsync and lcd_pclk ?
Secondly, I've modded our Nanobone code to match this new setup, as follows:-
static struct module_pin_mux norboot_pin_mux[] = {
{OFFSET(lcd_data1), (MODE(1) | PULLUDDIS)}, /* GPMC A17 */
{OFFSET(lcd_data2), (MODE(1) | PULLUDDIS)}, /* GPMC A18 */
{OFFSET(lcd_data3), (MODE(1) | PULLUDDIS)}, /* GPMC A19 */
{OFFSET(lcd_data4), (MODE(1) | PULLUDDIS)}, /* GPMC A20 */
{OFFSET(lcd_data5), (MODE(1) | PULLUDDIS)}, /* GPMC A21 */
{OFFSET(lcd_data6), (MODE(1) | PULLUDDIS)}, /* GPMC A22 */
{OFFSET(lcd_data7), (MODE(1) | PULLUDDIS)}, /* GPMC A23 */
{OFFSET(lcd_vsync), (MODE(1) | PULLUDDIS)}, /* GPMC A24 */
{OFFSET(lcd_hsync), (MODE(1) | PULLUDDIS)}, /* GPMC A25 */
{OFFSET(lcd_pclk), (MODE(1) | PULLUDDIS)}, /* GPMC A26 */
{-1},
};
void enable_norboot_pin_mux(void)
{
configure_module_pin_mux(norboot_pin_mux);
}
But this fails to boot. However, if I use the old ASM code:-
void enable_norboot_pin_mux(void)
{
asm("stmfd sp!, {r2 - r4}");
asm("movw r4, #0x8A4");
asm("movw r3, #0x44E1");
asm("orr r4, r4, r3, lsl #16");
asm("mov r2, #9");
asm("mov r3, #8");
asm("gpmc_mux: str r2, [r4], #4");
asm("subs r3, r3, #1");
asm("bne gpmc_mux");
asm("ldmfd sp!, {r2 - r4}");
}
... this now boots correctly !!
Anyone care to comment ?
next prev parent reply other threads:[~2013-08-23 9:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 5:18 [U-Boot] [PATCH V2 0/4]ARM: AM33xx: Cleanup clocks and hwinit Lokesh Vutla
2013-07-30 5:18 ` [U-Boot] [PATCH V2 1/4] ARM: AM33xx: Cleanup dplls data Lokesh Vutla
2013-07-30 7:33 ` Heiko Schocher
2013-07-30 5:18 ` [U-Boot] [PATCH V2 2/4] ARM: AM33xx: Cleanup clocks layer Lokesh Vutla
2013-07-30 7:33 ` Heiko Schocher
2013-07-30 5:18 ` [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place Lokesh Vutla
2013-07-30 7:34 ` Heiko Schocher
2013-08-21 15:51 ` Mark Jackson
2013-08-21 16:26 ` Tom Rini
2013-08-23 9:28 ` Mark Jackson [this message]
2013-08-23 10:25 ` Lokesh Vutla
2013-08-23 10:55 ` Mark Jackson
2013-08-28 12:58 ` Mark Jackson
2013-07-30 5:18 ` [U-Boot] [PATCH V2 4/4] musb: Disable extra prints Lokesh Vutla
2013-07-30 7:34 ` Heiko Schocher
2013-08-16 13:34 ` [U-Boot] [PATCH V2 0/4]ARM: AM33xx: Cleanup clocks and hwinit Tom Rini
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=52172B3D.80601@newflow.co.uk \
--to=mpfj-list@newflow.co.uk \
--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