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 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.