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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox