From: Sricharan R <r.sricharan@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Potential issue with recent OMAP PRCM struct unification
Date: Tue, 2 Apr 2013 15:02:21 +0530 [thread overview]
Message-ID: <515AA5A5.7090607@ti.com> (raw)
In-Reply-To: <FE617508-910F-4835-9DB2-295840587000@prograde.net>
Hi Mike Cashwell,
On Monday 01 April 2013 09:12 PM, Michael Cashwell wrote:
> Greetings,
>
> I think <http://patchwork.ozlabs.org/patch/218063/> or something related to it has confused OMAP4 clock init. I haven't entirely unraveled the onion but wanted to ping the list to see if this is known or I'm off in the weeds.
>
> Using u-boot master at commit a268170 in DEBUG mode the SPL says (in part):
>
> Enable clock module - 4a008e20
> Enable clock module - 4a008e28
> Enable clock module - 4a008e40 << later builds omit
> Enable clock module - 4a009338 << these two clocks
> Enable clock module - 4a004528
> Enable clock module - 4a004530
> Enable clock module - 4a004538
>
> That build works. But by commit 417c558 the 2 clocks noted are omitted and the later call to get_ram_size() hangs.
>
> In tracing this I found that the prcm structure initializes one field (cm_l3instr_intrconn_wp1_clkct) but then enable_non_essential_clocks() passes an array populated using a different field (cm_l3instr_intrconn_wp1_clkctrl) to do_enable_clocks(). That latter uninitialized field is zero which terminates that clock init array and results in the two clock omissions above.
>
> Searching for this and leaving out omap5 for clarity I see:
>
> cashwell.ubuntu:u-boot$ rgrep cm_l3instr_intrconn_wp1_clkct | grep -v omap5
> ./arch/arm/cpu/armv7/omap4/prcm-regs.c: .cm_l3instr_intrconn_wp1_clkct = 0x4a008e40,
> ./arch/arm/cpu/armv7/omap4/hw_data.c: (*prcm)->cm_l3instr_intrconn_wp1_clkctrl,
> ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkctrl;
> ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkct;
>
> On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and cm_l3instr_intrconn_wp1_clkctrl is a mistake.
>
> If that's true can anyone say which should be eliminated and whether or not the order of fields in struct prcm_regs matters?
>
First, on which board are you testing ?. I tested the mainline on my 4460 ES1.1 PANDA and it booted.
Also why are you enabling the non-essential clocks ?
Now enabling non-essential clocks is deprecated and they are **not** by enabled by default.
As you said the unnecessary entry in omap_common.h should be removed and typo in prcm-regs.c
I can correct this, but does correcting this gets you working again ?
Enabling these two clocks should have nothing to do with boot.
Regards,
Sricharan
next prev parent reply other threads:[~2013-04-02 9:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-01 15:42 [U-Boot] Potential issue with recent OMAP PRCM struct unification Michael Cashwell
2013-04-02 9:32 ` Sricharan R [this message]
2013-04-02 12:29 ` Michael Cashwell
2013-04-02 15:06 ` Sricharan R
2013-04-02 15:17 ` Tom Rini
2013-04-02 15:55 ` Sricharan R
2013-04-02 16:42 ` Tom Rini
2013-04-02 17:29 ` Sricharan R
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=515AA5A5.7090607@ti.com \
--to=r.sricharan@ti.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.