From: Roberto Nibali <rnibali@gmail.com>
To: "Eric Bénard" <eric@eukrea.com>
Cc: barebox@lists.infradead.org
Subject: Re: Booting mx25 based device from SD and NOR
Date: Fri, 25 May 2012 11:04:52 +0200 [thread overview]
Message-ID: <CAONxwYNisYJ+hvHTnxjHs-oPVGDFrhajVxMMrZXFJ8GN7aTg9A@mail.gmail.com> (raw)
In-Reply-To: <20120524153119.6d724afc@eb-e6520>
[-- Attachment #1.1: Type: text/plain, Size: 5362 bytes --]
Hi Eric
> > well NAND boot + nand rootfs works fine here (cpuimx25) and I assume
> > > NAND boot + sd rootfs would work as sd is properly detected during
> boot.
> > >
> > > Yep, I believe it's more a question of me setting the parameters
> correctly
> > upon boot. But without a proper low level init (which I don't have
> because
> > I do not really understand all the details of the low level code), there
> > are other factors which could inhibit the proper boot, as you mention
> below.
> >
> if your sd's partitions are detected by the kernel you must be able to
> boot a rootfs on it it's just a bootargs problem (and kernel
> configuration to have the right FS included).
>
That's my understanding too, however it does not work at the moment. But
what's really important is that I have NOR support when loading barebox as
first stage boot loader from SD card.
> > I suppose WEIM configuration is done in the low level part, isn't it?
> Where
> > would I find an appropriate example? I have been reading all the fsl
> > board's low_level codes, but have a hard time figuring out how to apply
> it
> > to my board.
> >
> > With regard to the IOMUX, I was under the impression that it does not
> > matter much, since after low level code run, the execution path is:
> >
> > late_initcall()
> > mem_initcall()
> > device_initcall() --> add_cfi_flash_device()
> > console_initcall() --> mxc_iomux_v3_setup_multiple_pads()
> > core_initcall()
> >
> > So CFI/NOR detection happens before IOMUX setup, at least that's what I
> > have gathered for my board copying from various other examples in
> barebox.
> > What would the correct code execution path be from the architectural
> point
> > of view?
> >
> nothing prevents you from moving mxc_iomux_v3_setup_multiple_pads to
> device_initcall as done in
>
> http://git.pengutronix.de/?p=barebox.git;a=blob;f=arch/arm/boards/eukrea_cpuimx25/eukrea_cpuimx25.c;h=1b8f618138023b88893a024ddc0c078b7b9f2325;hb=c48de4beee21c3a5573cec084123c33ae08f6f7a
>
> Thanks, I have done this now, looks much cleaner. Stil, I wonder about the
order of things when powering and booting up the mx25 in general.
lowlevel -> AIPS -> MAX (MPR, SGPCR, MGPCR) -> M3IF -> MPLL clock
-> other clocks
late_initcall -> fec_init
mem_initcall -> imx25_mem_init
device_initcall -> devices_init
console_initcall -> console_init
core_initcall -> core_setup
> for the weim setting you may need to do something similar to what is
> done on line 187 of :
>
> http://git.pengutronix.de/?p=barebox.git;a=blob;f=arch/arm/boards/eukrea_cpuimx27/eukrea_cpuimx27.c;h=63e87c9551c440edab572f5252a503ba4d533161;hb=c48de4beee21c3a5573cec084123c33ae08f6f7a
>
>
Now that piece certainly was missing, but how the heck did you find out
those register values? Where did you get the information about writing to
chip select 0 and selecting:
CSCR0U: 0x00008F03
CSCR0L: 0xA0330D01
CSCR0A: 0x002208C0
I have patched mx25-regs.h accordingly and added an equivalent call using
the same register values:
diff --git a/arch/arm/mach-imx/include/mach/imx25-regs.h
b/arch/arm/mach-imx/include/mach/imx25-regs.h
index 73307c4..8225832 100644
--- a/arch/arm/mach-imx/include/mach/imx25-regs.h
+++ b/arch/arm/mach-imx/include/mach/imx25-regs.h
@@ -72,6 +72,7 @@
#define CCM_LTR1 0x44
#define CCM_LTR2 0x48
#define CCM_LTR3 0x4c
+#define CCM_MCR 0x64
#define PDR0_AUTO_MUX_DIV(x) (((x) & 0x7) << 9)
#define PDR0_CCM_PER_AHB(x) (((x) & 0x7) << 12)
@@ -107,6 +108,22 @@
#define CSCR_L(x) (WEIM_BASE + 4 + (x) * 0x10)
#define CSCR_A(x) (WEIM_BASE + 8 + (x) * 0x10)
+/* Chip Select Registers */
+#define IMX_WEIM_BASE WEIM_BASE
+#define CSxU(x) __REG(IMX_WEIM_BASE + (cs * 0x10) + 0x00) /* Chip Select x
Upper Register */
+#define CSxL(x) __REG(IMX_WEIM_BASE + (cs * 0x10) + 0x04) /* Chip Select x
Lower Register */
+#define CSxA(x) __REG(IMX_WEIM_BASE + (cs * 0x10) + 0x08) /* Chip Select x
Addition Register */
+#define EIM __REG(IMX_WEIM_BASE + 0x60) /* WEIM Configuration Register
*/
+
+#ifndef __ASSEMBLY__
+static inline void imx25_setup_weimcs(size_t cs, unsigned upper, unsigned
lower, unsigned addional)
+{
+ CSxU(cs) = upper;
+ CSxL(cs) = lower;
+ CSxA(cs) = addional;
+}
+#endif /* __ASSEMBLY__ */
+
/*
* Definitions for the clocksource driver
*
But it still does not work. What could be missing? How can I find out more
about which chip select I need? I'm practically married to the MX25-RM
documentation, but still, it's one heck of a large piece of documentation.
I found the following example (using cs2), but I am not sure this helps:
@; config WEIM to Async access with EDC, OEA, RWA, RWN, EBC, 16 bit port
and PSR WRITE WEIM_CSCR2U, 0x12020802
WRITE WEIM_CSCR2L, 0x80330d03
@ ; config Flash to WRAP 8 mode (by half word accesses) WRITE_H
(CS2_BASE_ADDR+0x2384), 0x60 @ ; offset = 0x11c2 << 1 for 16 bit port
WRITE_H (CS2_BASE_ADDR+0x2384), 0x03
WRITE_H (CS2_BASE_ADDR+0x0), 0xff @ ; Flash to read mode
@ ; config to WEIM Sync access with WRAP8, 16 bit port WRITE WEIM_CSCR2U,
0x13510802
WRITE WEIM_CSCR2L, 0x80330d03
Could it be that I am missing an iomux setting? Clock missing? I am fairly
certain that my NOR is at CS0, so the above example from the RM does not
help much, I suppose.
Best regards
Roberto
[-- Attachment #1.2: Type: text/html, Size: 7859 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2012-05-25 9:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 12:11 Roberto Nibali
2012-05-22 18:42 ` Sascha Hauer
2012-05-23 10:43 ` Roberto Nibali
2012-05-23 11:47 ` Eric Bénard
2012-05-24 12:49 ` Roberto Nibali
2012-05-24 12:58 ` Eric Bénard
2012-05-24 13:18 ` Roberto Nibali
2012-05-24 13:31 ` Eric Bénard
2012-05-25 9:04 ` Roberto Nibali [this message]
2012-05-25 10:08 ` Eric Bénard
2012-05-29 9:06 ` Roberto Nibali
2012-05-29 9:29 ` Sascha Hauer
2012-05-29 9:56 ` Roberto Nibali
2012-05-29 10:14 ` Roberto Nibali
2012-05-30 5:47 ` Sascha Hauer
2012-05-30 6:39 ` Juergen Beisert
2012-05-31 13:12 ` Roberto Nibali
2012-05-31 17:06 ` Sascha Hauer
2012-06-01 10:25 ` Roberto Nibali
2012-06-05 7:09 ` Sascha Hauer
2012-05-24 17:17 ` Sascha Hauer
2012-05-25 9:19 ` Roberto Nibali
2012-05-25 10:01 ` Sascha Hauer
2012-05-29 9:26 ` Roberto Nibali
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=CAONxwYNisYJ+hvHTnxjHs-oPVGDFrhajVxMMrZXFJ8GN7aTg9A@mail.gmail.com \
--to=rnibali@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=eric@eukrea.com \
/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