[U-Boot] SPI support for Sequoia board
Hello All, I am using AMCC sequoia board. using u-boot version U-Boot 1.3.4 Need to implement SPI based RTC chip. I find some problem in implementing SPI, is some patch there? Any support appreciated. Thanks & regards, Zaahir Khan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc85xx: Add 4-bits eSDHC support for MPC8569E-MDS boards
Thanks to "Errata to MPC8569E PowerQUICC III Integrated Host Processor
Family Reference Manual, Rev. 0" document, which describes all eSDHC
pins, we can add 4-bits eSDHC support for MPC8569E-MDS boards.
Signed-off-by: Anton Vorontsov
---
board/freescale/mpc8569mds/mpc8569mds.c | 14 ++
include/configs/MPC8569MDS.h|4
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mpc8569mds/mpc8569mds.c
b/board/freescale/mpc8569mds/mpc8569mds.c
index cdd7813..6e90c09 100644
--- a/board/freescale/mpc8569mds/mpc8569mds.c
+++ b/board/freescale/mpc8569mds/mpc8569mds.c
@@ -437,6 +437,11 @@ int board_mmc_init(bd_t *bd)
console_assign(stdin, "eserial1");
printf("Switched to UART1 (initial log has been printed to "
"UART0).\n");
+
+ clrsetbits_be32(&gur->plppar1, PLPPAR1_UART0_BIT_MASK,
+ PLPPAR1_ESDHC_4BITS_VAL);
+ clrsetbits_be32(&gur->plpdir1, PLPDIR1_UART0_BIT_MASK,
+ PLPDIR1_ESDHC_4BITS_VAL);
bcsr6 |= BCSR6_SD_CARD_4BITS;
} else {
printf("should be disabled.\n");
@@ -483,6 +488,15 @@ static void fdt_board_fixup_esdhc(void *blob, bd_t *bd)
break;
}
}
+
+ if (hwconfig_subarg_cmp("esdhc", "mode", "4-bits")) {
+ off = fdt_node_offset_by_compatible(blob, -1, "fsl,esdhc");
+ if (off < 0) {
+ printf("WARNING: could not find esdhc node\n");
+ return;
+ }
+ fdt_delprop(blob, off, "sdhci,1-bit-only");
+ }
}
#else
static inline void fdt_board_fixup_esdhc(void *blob, bd_t *bd) {}
diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h
index 1e659e2..e16f0e1 100644
--- a/include/configs/MPC8569MDS.h
+++ b/include/configs/MPC8569MDS.h
@@ -277,6 +277,10 @@ extern unsigned long get_clock_freq(void);
#define PLPDIR1_I2C_BIT_MASK 0x000F
#define PLPDIR1_I2C2_VAL 0x000F
#define PLPDIR1_ESDHC_VAL 0x0006
+#define PLPPAR1_UART0_BIT_MASK 0x0fc0
+#define PLPPAR1_ESDHC_4BITS_VAL0x0a80
+#define PLPDIR1_UART0_BIT_MASK 0x0fc0
+#define PLPDIR1_ESDHC_4BITS_VAL0x0a80
/*
* General PCI
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 1/3] s3c24x0 code style changes
Dear Scott Wood, In message <4b27faf1.1070...@freescale.com> you wrote: > > Yes, as part of the set of patches in the custodian tree. Why introduce > conflicts by targetting an older tree? What if the new patch depends on > previous patches that have gone into the custodian branch? Custodians should send pull requests early and often to avoid big differences from building up. > I also don't see what is different about this patch than all the other > patches on the list that target some custodian tree. If you're trying Whenever I notice that a patch does not apply against "master" or "next" I will complain. > to change common practice, a general announcement would be nice rather > than picking an arbitrary patch to make an example out of. I've been making this very same statement before, whenever I noticed such an issue. So far, it happened only very infrequently. > So I should send a request immediately after every set of patches I > apply, with no time for futher testing or review? What if the next > branch hasn't opened yet? You should never apply any patches to your custodian tree without review, and normally only after sufficient testing. If you are experimenting, then use a branch for this, but never do this on the maste rbranch of a custodian repo. > > If I am supposed to test something, I don;t want to have to bother > > about some 30+ custodian trees hanging around, and finding the right > > branch in the right tree > > I'm fine with asking people to specify exactly what branch/repo they had > in mind for the patch. Fine for you, but I don't accept this. > I don't want to have to resolve merge conflicts (inevitably sometimes > incorrectly) in every patch because they were based on code which has > been modified by a previously-applied patch. In such a case the poster can / should ask the custodian to get his stuff pulled. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Pardon me for breathing, which I never do anyway so I don't know why I bother to say it, oh God, I'm so depressed. Here's another of those self-satisfied doors. Life! Don't talk to me about life." - Marvin the Paranoid Android ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] JFFS2 Loading Error on non 8k blocksize NAND [DEMO PATCH 1/1]
Hello everyone. Well, this is my first post on the list and its to announce a small bug that I've found when using JFFS2 on NAND in UBoot. This issue was seen only once volume production was started on a new device. However, its a simple fix and I'm including my temporary patch for it at the end Basically, when using the "fsload" command to read our kernel from NAND flash in preparation for boot, a small percentage of our partitions were displaying a CRC error on boot. Upon investigation, I noticed the fsload application skipping over bad erase blocks of 8k in size. This is to be expected, except that our NAND flash has 128k block sizes. In certain cases, we get a bad eraseblock in just the wrong location that then causes us to read invalid information for a kernel image. Upon tracking this down, it appears that the jffs2_1pass.c is using older system configuration variables instead of the newer CONFIG_SYS_ prefixed variables. It also had the Page size hard coded to 512. Included is my patch that makes the code functional for properly-configured boards with new code, but its a demo only as this code probably needs a little bit of refactoring and cleanup so that its more generic in nature. - Patch Snip - diff -ruN u-boot/fs/jffs2/jffs2_1pass.c uboot/fs/jffs2/jffs2_1pass.c --- u-boot/fs/jffs2/jffs2_1pass.c 2009-12-15 14:20:33.0 -0600 +++ uboot/fs/jffs2/jffs2_1pass.c 2009-12-15 14:19:27.0 -0600 @@ -158,12 +158,12 @@ * */ -#define NAND_PAGE_SIZE 512 +#define NAND_PAGE_SIZE CONFIG_SYS_NAND_PAGE_SIZE #define NAND_PAGE_SHIFT 9 #define NAND_PAGE_MASK (~(NAND_PAGE_SIZE-1)) #ifndef NAND_CACHE_PAGES -#define NAND_CACHE_PAGES 16 +#define NAND_CACHE_PAGES CONFIG_SYS_NAND_PAGE_COUNT #endif #define NAND_CACHE_SIZE (NAND_CACHE_PAGES*NAND_PAGE_SIZE) -- -- Hunter Cobbs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx, mpc86xx: Fix gd->cpu pointer after relocation
Dear Peter Tyser, In message <1260900647-21296-1-git-send-email-pty...@xes-inc.com> you wrote: > The gd->cpu pointer is set to an address located in flash when the > probecpu() function is called while U-Boot is executing from flash. > This pointer needs to be updated to point to an address in RAM after > relocation has occurred otherwise Linux may not be able to boot due to > "fdt board" crashing if flash has been erased or changed. > > This bug was introduced in commit > a0e2066f392782730f0398095e583c87812d97f2. > > Signed-off-by: Peter Tyser > Reported-by: Ed Swarthout > --- > Below is the output of Ed's test after applying this patch: > U-Boot 2009.11-rc2-00110-g5b75c04-dirty (Dec 15 2009 - 12:05:00) > > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > CPU0: 8572E, Version: 1.1, (0x80e80011) > Core: E500, Version: 3.0, (0x80210030) > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > Clock Configuration:cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > >CPU0:1333.333 MHz, cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > CPU1:1333.333 MHz, cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > >CCB:533.333 MHz, >DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:66.667 MHz > L1:D-cache 32 kB enabled >I-cache 32 kB enabled > Board: X-ES XPedite5370 3U VPX SBC >Rev A, Serial# 12345678, Cfg 12345678-1 > I2C: ready > DRAM: cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 > 2 GB (DDR2, 64-bit, CL=5, ECC on) >DDR Controller Interleaving Mode: bank > FLASH: Executed from FLASH1 > FLASH: 256 MB > L2:1024 KB enabled > cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 > cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 > cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 > cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 > NAND: 1024 MiB > ... > > => md 7ffc0a60 > 7ffc0a60: 38353732 8572 > 7ffc0a70: 0080e800 0002 50313031 3100P1011... > 7ffc0a80: 0080e500 0001 > 7ffc0a90: 50313031 3100 P1011... > 7ffc0aa0: 0080ed00 0001 50313032 3000P1020... > 7ffc0ab0: 0080e400 0002 > 7ffc0ac0: 50313032 3000 P1020... > 7ffc0ad0: 0080ec00 0002 50323031 3000P2010... > 7ffc0ae0: 0080e300 0001 > 7ffc0af0: 50323031 3000 P2010... > 7ffc0b00: 0080eb00 0001 50323032 3000P2020... > 7ffc0b10: 0080e200 0002 > 7ffc0b20: 50323032 3000 P2020... > 7ffc0b30: 0080ea00 0002 50343034 3000P4040... > 7ffc0b40: 00820100 0004 > 7ffc0b50: 50343034 3000 P4040... > => > > lib_ppc/board.c |8 > 1 files changed, 8 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The number you have dialed is imaginary. Please divide by 0 and try again. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: davinci_nand.c performance enhancments
On Tue, Dec 15, 2009 at 02:37:59PM +, Nick Thompson wrote:
> +/*
> + * Exploit the little endianness of the ARM to do multi-byte transfers
> + * per device read. This can perform over twice as quickly as individual
> + * byte transfers when buffer alignment is conducive.
> + *
> + * NOTE: This only works if the NAND is not connected to the 2 LSBs of
> + * the address bus. On Davinci EVM platforms this has always been true.
> + */
> +static void nand_davinci_read_buf(struct mtd_info *mtd, uint8_t *buf, int
> len)
> +{
> + struct nand_chip *chip = mtd->priv;
> + const u32 *nand = chip->IO_ADDR_R;
> +
> + if int)buf | len) & 0x3) == 0)
> + while (len > 0) {
> + *(u32 *)buf = readl(nand);
> + buf += 4;
> + len -= 4;
> + }
It's unlikely to actually happen with the current NAND code, but this
could accelarate some additional cases as:
if uintptr_t)buf) & 3) == 0) {
while (len >= 4) {
...
}
}
> + else if int)buf | len) & 0x1) == 0)
> + while (len > 0) {
> + *(u16 *)buf = readw(nand);
> + buf += 2;
> + len -= 2;
> + }
> + else
> + while (len-- > 0)
> + *buf++ = readb(nand);
We generally put brances around multi-line "if" bodies (especially
complex ones), even if it's technically one statement.
> - unsigned int hw_4ecc[4] = { 0, 0, 0, 0 };
> - unsigned int const1 = 0, const2 = 0;
> - unsigned char count1 = 0;
> + unsigned int hw_4ecc[4];
> + unsigned int const1;
> + unsigned char count1;
Maybe further change "count1" to "i" and "const1" to "i * 2" (the
code generated should be the same)? Similarly, it would be nice if we
could do something with "pspare"/"pspare1" further on (even pspare[2] or
pspare1/pspare2 would be nicer).
Or maybe that could be converted to autoinc as well, with some statement
splitting to introduce the necessary sequence points.
Other than cosmetic issues, this looks OK. I'll be on vacation until the
end of the year, so ACK a cleaned-up patch if someone wants to apply it
before I get back.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 1/3] s3c24x0 code style changes
Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20091215201449.ga4...@loki.buserror.net> you wrote: >> I don't follow -- why can't people base patches on the tree they're >> expecting them to be applied to? > > In the end, people expect to have their patches applied to mainline, > which means "master" or "next", right? Yes, as part of the set of patches in the custodian tree. Why introduce conflicts by targetting an older tree? What if the new patch depends on previous patches that have gone into the custodian branch? > Any custodian trees are just > staging areas on that way, and custodian should take care to keep he > difference between their trees (at least their master branches) to > mainline as small as possible. Obviously we aren't going to keep the trees gratuitously different -- but sometimes there will be patches in there, and we should encourage, not discourage, patch submitters targetting the tree that they will actually be applied to. I also don't see what is different about this patch than all the other patches on the list that target some custodian tree. If you're trying to change common practice, a general announcement would be nice rather than picking an arbitrary patch to make an example out of. > I always try to handle any pull > requests really quickly. So I should send a request immediately after every set of patches I apply, with no time for futher testing or review? What if the next branch hasn't opened yet? > If I am supposed to test something, I don;t want to have to bother > about some 30+ custodian trees hanging around, and finding the right > branch in the right tree I'm fine with asking people to specify exactly what branch/repo they had in mind for the patch. I don't want to have to resolve merge conflicts (inevitably sometimes incorrectly) in every patch because they were based on code which has been modified by a previously-applied patch. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx, mpc86xx: Fix gd->cpu pointer after relocation
From: Kumar Gala [mailto:ga...@kernel.crashing.org] > On Dec 15, 2009, at 12:10 PM, Peter Tyser wrote: > > > The gd->cpu pointer is set to an address located in flash when the > > probecpu() function is called while U-Boot is executing from flash. > > This pointer needs to be updated to point to an address in > > RAM after relocation has occurred otherwise Linux may not be able > > to boot due to "fdt board" crashing if flash has been erased or > > changed. > > > > This bug was introduced in commit > > a0e2066f392782730f0398095e583c87812d97f2. > > > > Signed-off-by: Peter Tyser > > Reported-by: Ed Swarthout > > Tested-by: Kumar Gala Tested on MPC8527DS. Tested by: Ed Swarthout ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 1/3] s3c24x0 code style changes
Dear Scott Wood, In message <20091215201449.ga4...@loki.buserror.net> you wrote: > > I don't follow -- why can't people base patches on the tree they're > expecting them to be applied to? In the end, people expect to have their patches applied to mainline, which means "master" or "next", right? Any custodian trees are just staging areas on that way, and custodian should take care to keep he difference between their trees (at least their master branches) to mainline as small as possible. I always try to handle any pull requests really quickly. If I am supposed to test something, I don;t want to have to bother about some 30+ custodian trees hanging around, and finding the right branch in the right tree so test one patch and another combo for the next patch. See also http://www.denx.de/wiki/U-Boot/Patches , bullet no. 3 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I wrote my name at the top of the page. I wrote down the number of the question ``1''. After much reflection I put a bracket round it thus ``(1)''. But thereafter I could not think of anything connected with it that was either relevant or true. - Sir Winston Churchill _My Early Life_ ch. 2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 1/3] s3c24x0 code style changes
On Tue, Dec 15, 2009 at 01:15:17PM +0100, Wolfgang Denk wrote: > Dear "kevin.morf...@fearnside-systems.co.uk", > > In message <4b2548eb.4000...@fearnside-systems.co.uk> you wrote: > > Cleans up the s3c24x0 header files by changing the upper case members > > of the s3c24x0 register structures to lower case and changing all code > > that uses these register structures. > > > > Signed-off-by: Kevin Morfitt > > Thanks for doing such cleanup. > > > The patches are based on the u-boot-samsung repository. > > Please adhere to posting guidelines. Patches posted ere MUST be based > either on the "master" or on the "next" trees. > > Please considered these patches NAKed because of this. I don't follow -- why can't people base patches on the tree they're expecting them to be applied to? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] AM35x: Initial support for the processor
Sanjeev Premi wrote: > This patchset adds basic support for the AM35x > processors. It also ensures that u-boot banner > shows correct processor at start-up. > > Addition of AM35x impacts existing code for OMAP3, > most patches in this set are applicable to both > processor families. > > The series has been tested on the OMAP3EVM and > AM3517EVM. To test on AM3517EVM, earlier patches > posted by Vaibhav are required. > > [1] http://lists.denx.de/pipermail/u-boot/2009-November/064670.html > > The am3517 support is not in. This patchset is dependent on it. These changes can only be reviewed casually until then. Vaibhav, When will next rev of the am3517 changes be posted ? Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx, mpc86xx: Fix gd->cpu pointer after relocation
On Dec 15, 2009, at 12:10 PM, Peter Tyser wrote: > The gd->cpu pointer is set to an address located in flash when the > probecpu() function is called while U-Boot is executing from flash. > This pointer needs to be updated to point to an address in RAM after > relocation has occurred otherwise Linux may not be able to boot due to > "fdt board" crashing if flash has been erased or changed. > > This bug was introduced in commit > a0e2066f392782730f0398095e583c87812d97f2. > > Signed-off-by: Peter Tyser > Reported-by: Ed Swarthout Tested-by: Kumar Gala - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection of cpu revision
> -Original Message- > From: Tom [mailto:tom@windriver.com] > Sent: Tuesday, December 15, 2009 10:44 PM > To: Premi, Sanjeev > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection > of cpu revision > > Sanjeev Premi wrote: > > Each call to get_cpu_rev() leads to repetitive > > execution of code to detect the cpu revision. > > > > This patchset ensures that mechanism to detect > > revision is not executed each time; instead a > > stored value is returned. > > > > Since, revision info is needed in s_init(), > > the function to identify cpu revision needs > > to be called twice. At the moment, it is > > necessary/ unavoidable. > > > > Is there some other reason to read this register only once? > This function is not used frequently and i do not > think the complexity of optimizing is necessary. As more processors and revision specific code gets added, there will be more occurrences for this check. I have just posted patches for basic support for the AM35x processors. Now, the cpurev for this silicon is ES1.0; but have otherwise similar features that the OMAP35x ES3.1 si (I am not accounting other IP differences between the processors here). Also, I don't believe there is any complexity added as the contents of register are being read and saved in a global variable for use later. Best regards, Sanjeev > > Tom > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] OMAP3, AM35x: Update function print_cpuinfo()
The function is updated to make use of the cpu related
information extracted in arch_cpu_init().
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/sys_info.c | 45
1 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 3544d26..1228f5f 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -364,45 +364,60 @@ u32 get_device_type(void)
*/
int print_cpuinfo (void)
{
- char *cpu_s, *sec_s;
+ char cpu_s[16], sec_s[4];
- switch (get_cpu_type()) {
+ switch (cpu_id) {
case OMAP3503:
- cpu_s = "3503";
+ strcpy(cpu_s, "OMAP3503");
break;
case OMAP3515:
- cpu_s = "3515";
+ strcpy(cpu_s, "OMAP3515");
break;
case OMAP3525:
- cpu_s = "3525";
+ strcpy(cpu_s, "OMAP3503");
break;
+ case OMAP3430:
case OMAP3530:
- cpu_s = "3530";
+ strcpy(cpu_s, "OMAP3430/3530");
break;
- default:
- cpu_s = "35XX";
+ case CTRL_AM3505:
+ strcpy(cpu_s, "AM3505");
+ break;
+ case CTRL_AM3517:
+ strcpy(cpu_s, "AM3517");
break;
+
+ default:
+ if (cpu_family == CPU_AM35XX)
+ strcpy(cpu_s, "AM35xx");
+ else
+ strcpy(cpu_s, "OMAP34xx/35xx");
}
switch (get_device_type()) {
case TST_DEVICE:
- sec_s = "TST";
+ strcpy(sec_s, "TST");
break;
case EMU_DEVICE:
- sec_s = "EMU";
+ strcpy(sec_s, "EMU");
break;
case HS_DEVICE:
- sec_s = "HS";
+ strcpy(sec_s, "HS");
break;
case GP_DEVICE:
- sec_s = "GP";
+ strcpy(sec_s, "GP");
break;
default:
- sec_s = "?";
+ strcpy(sec_s, "?");
}
- printf("OMAP%s-%s ES%s, CPU-OPP2 L3-165MHz\n",
- cpu_s, sec_s, rev_s[get_cpu_rev()]);
+ /*
+* TBD: Revision numbers for AM35x may not be same as OMAP35x.
+* Will need to re-look sometime later.
+*/
+ printf("%s-%s ES%s,%s L3-165MHz\n",
+ cpu_s, sec_s, rev_s[get_cpu_rev()],
+ (cpu_family == CPU_AM35XX) ? "" : " CPU-OPP2");
return 0;
}
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] OMAP3, AM35x: Update the checks for CPU revision
The usage of get_cpu_rev() to check for cpu revision
is no longer appropriate - after updates in previous
patches.
This patch ensures correct usage.
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/cache.S | 30 --
cpu/arm_cortexa8/omap3/clock.c |3 ++-
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/cache.S b/cpu/arm_cortexa8/omap3/cache.S
index 0f63815..8e985d8 100644
--- a/cpu/arm_cortexa8/omap3/cache.S
+++ b/cpu/arm_cortexa8/omap3/cache.S
@@ -131,10 +131,23 @@ finished_inval:
l2_cache_enable:
push{r0, r1, r2, lr}
- @ ES2 onwards we can disable/enable L2 ourselves
+ @ We can disable/enable L2 ourselves for these devices
+ @ - OMAP3430/OMAP35xx (ES2 onwards)
+ @ - AM35xx
+ mov r0, #CPU_AM35XX
+ bl is_cpu_family
+ cmp r0, #1
+ beq l2_cache_enable_LATER_THAN_ES2 @ family is AM35xx
+
+ mov r0, #CPU_OMAP34XX
+ bl is_cpu_family
+ cmp r0, #1
+ bne l2_cache_enable_END @ Family isn't OMAP34xx/35xx
+
bl get_cpu_rev
cmp r0, #CPU_3XX_ES20
blt l2_cache_disable_EARLIER_THAN_ES2
+l2_cache_enable_LATER_THAN_ES2:
mrc 15, 0, r3, cr1, cr0, 1
orr r3, r3, #2
mcr 15, 0, r3, cr1, cr0, 1
@@ -162,10 +175,23 @@ l2_cache_enable_END:
l2_cache_disable:
push{r0, r1, r2, lr}
- @ ES2 onwards we can disable/enable L2 ourselves
+ @ We can disable/enable L2 ourselves for these devices
+ @ - OMAP3430/OMAP35xx (ES2 onwards)
+ @ - AM35xx
+ mov r0, #CPU_AM35XX
+ bl is_cpu_family
+ cmp r0, #1
+ beq l2_cache_disable_LATER_THAN_ES2 @ family is AM35xx
+
+ mov r0, #CPU_OMAP34XX
+ bl is_cpu_family
+ cmp r0, #1
+ bne l2_cache_enable_END @ Family isn't OMAP34xx/35xx
+
bl get_cpu_rev
cmp r0, #CPU_3XX_ES20
blt l2_cache_disable_EARLIER_THAN_ES2
+l2_cache_disable_LATER_THAN_ES2:
mrc 15, 0, r3, cr1, cr0, 1
bic r3, r3, #2
mcr 15, 0, r3, cr1, cr0, 1
diff --git a/cpu/arm_cortexa8/omap3/clock.c b/cpu/arm_cortexa8/omap3/clock.c
index 174c453..0a1e603 100644
--- a/cpu/arm_cortexa8/omap3/clock.c
+++ b/cpu/arm_cortexa8/omap3/clock.c
@@ -170,7 +170,8 @@ void prcm_init(void)
* and sil_index will get the values for that SysClk for the
* appropriate silicon rev.
*/
- if (get_cpu_rev())
+ if ((is_cpu_family(CPU_OMAP34XX) && (get_cpu_rev() >= CPU_3XX_ES20)) ||
+ (is_cpu_family(CPU_AM35XX)))
sil_index = 1;
/* Unlock MPU DPLL (slows things down, and needed later) */
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] OMAP3, AM35x: Detect exact CPU in arch_cpu_init()
This patch identifies exact cpu in function arch_cpu_init().
It does the following:
- It consolidates all related #defines into omap3.h.
- Prefixes CTRL_ to #defines used in comparison against
contents of Control Status Register returned by the
function get_cpu_type().
- Adds new #defines to identify exact CPU id.
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/sys_info.c | 55 ++-
include/asm-arm/arch-omap3/cpu.h |6
include/asm-arm/arch-omap3/omap3.h | 26 +++-
3 files changed, 77 insertions(+), 10 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 6206e17..3544d26 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -45,14 +45,17 @@ static u16 cpu_family;
static u16 cpu_id;
static u8 cpu_revision;
+static u32 get_cpu_type(void);
+
/**
* Identify the silicon
*
- * Currently, it identifies the cpu family and silicon revision.
+ * It identifies the cpu family, exact cpu and silicon revision.
*/
void identify_cpu (void)
{
u32 cpuid = 0;
+ u32 cputype;
u16 hawkeye;
struct ctrl_id *id_base;
@@ -73,6 +76,9 @@ void identify_cpu (void)
hawkeye = (cpuid >> HAWKEYE_SHIFT) & 0x;
cpu_revision = (cpuid >> CPU_3XX_ID_SHIFT) & 0xf;
+ /*
+* Identify cpu family and revision
+*/
switch (hawkeye) {
case HAWKEYE_OMAP34XX:
cpu_family = CPU_OMAP34XX;
@@ -90,6 +96,51 @@ void identify_cpu (void)
cpu_family = CPU_OMAP34XX;
break;
}
+
+ cputype = get_cpu_type();
+ switch (cpu_family)
+ {
+ case CPU_OMAP34XX:
+ switch (cputype) {
+ case CTRL_OMAP3503:
+ cpu_id = OMAP3503;
+ break;
+ case CTRL_OMAP3515:
+ cpu_id = OMAP3515;
+ break;
+ case CTRL_OMAP3525:
+ cpu_id = OMAP3525;
+ break;
+ case CTRL_OMAP3530:
+ cpu_id = OMAP3430; /* Same as OMAP3530 */
+ break;
+ default:
+ cpu_id = OMAP3430;
+ break;
+ }
+ break;
+
+ case CPU_AM35XX:
+ switch (cputype) {
+ case CTRL_AM3505:
+ cpu_id = AM3505;
+ break;
+ case CTRL_AM3517:
+ cpu_id = AM3517;
+ break;
+ default:
+ cpu_id = AM3505;
+ break;
+ }
+ break;
+
+ default:
+ /*
+* Fall back to most common device
+*/
+ cpu_id = OMAP3430;
+ break;
+ }
}
}
@@ -150,7 +201,7 @@ void dieid_num_r(void)
/**
* get_cpu_type(void) - extract cpu info
**/
-u32 get_cpu_type(void)
+static u32 get_cpu_type(void)
{
return readl(&ctrl_base->ctrl_omap_stat);
}
diff --git a/include/asm-arm/arch-omap3/cpu.h b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..088a342 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -60,12 +60,6 @@ struct ctrl {
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL_STRICT_NAMES */
-/* cpu type */
-#define OMAP3503 0x5c00
-#define OMAP3515 0x1c00
-#define OMAP3525 0x4c00
-#define OMAP3530 0x0c00
-
#ifndef __KERNEL_STRICT_NAMES
#ifndef __ASSEMBLY__
struct ctrl_id {
diff --git a/include/asm-arm/arch-omap3/omap3.h
b/include/asm-arm/arch-omap3/omap3.h
index 86df1f2..af23e5d 100644
--- a/include/asm-arm/arch-omap3/omap3.h
+++ b/include/asm-arm/arch-omap3/omap3.h
@@ -161,8 +161,6 @@ struct gpio {
#define DDR_133133 /* most combo, some mem d-boards */
#define DDR_165165 /* future parts */
-#define CPU_3430 0x3430
-
/*
* 343x real hardware:
* ES1 = rev 0
@@ -197,4 +195,28 @@ struct gpio {
#define CPU_OMAP34XX 0x3400 /* OMAP34xx/OMAP35 devices */
#define CPU_AM35XX 0x3500 /* AM35xx devices */
+/*
+ * Define CPUs
+ */
+#define OMAP3430 0x3430
+
+#define OMAP3503 0x3503
+#define OMAP35
[U-Boot] [PATCH 1/4] AM35x: Introduce support for AM35x processors
This patch adds support for TI's recently announced
AM35x family of devices.
It implements function is_family() to differentiate
between OMAP34x/OMAP35x and AM35x device families at
runtime.
[1] http://www.ti.com/sitara
[2] http://www.ti.com/arm
[3]
http://tiexpressdsp.com/index.php?title=Applications_Processors_Crossreference
[4] http://marc.info/?l=linux-omap&m=125615009412281&w=2
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/sys_info.c | 42
include/asm-arm/arch-omap3/omap3.h | 14 ++
include/asm-arm/arch-omap3/sys_proto.h |1 +
3 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 449262a..6206e17 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -41,16 +41,19 @@ static char *rev_s[CPU_3XX_MAX_REV] = {
"3.0",
"3.1"};
-static u8 cpu_revision;
+static u16 cpu_family;
+static u16 cpu_id;
+static u8 cpu_revision;
/**
* Identify the silicon
*
- * Currently, it identifies the cpu revision.
+ * Currently, it identifies the cpu family and silicon revision.
*/
void identify_cpu (void)
{
u32 cpuid = 0;
+ u16 hawkeye;
struct ctrl_id *id_base;
/*
@@ -59,6 +62,7 @@ void identify_cpu (void)
*/
__asm__ __volatile__("mrc p15, 0, %0, c0, c0, 0":"=r"(cpuid));
if ((cpuid & 0xf) == 0x0) {
+ cpu_family = CPU_OMAP34XX;
cpu_revision = CPU_3XX_ES10;
} else {
/* Decode the IDs on > ES1.0 */
@@ -66,11 +70,26 @@ void identify_cpu (void)
cpuid = readl(&id_base->idcode);
+ hawkeye = (cpuid >> HAWKEYE_SHIFT) & 0x;
cpu_revision = (cpuid >> CPU_3XX_ID_SHIFT) & 0xf;
- /* Some early ES2.0 seem to report rev 0, fix this */
- if(cpu_revision == 0)
- cpu_revision = CPU_3XX_ES20;
+ switch (hawkeye) {
+ case HAWKEYE_OMAP34XX:
+ cpu_family = CPU_OMAP34XX;
+
+ /* Some early ES2.0 seem to report ID 0, fix this */
+ if(cpu_revision == 0)
+ cpu_revision = CPU_3XX_ES20;
+ break;
+
+ case HAWKEYE_AM35XX:
+ cpu_family = CPU_AM35XX;
+ break;
+
+ default:
+ cpu_family = CPU_OMAP34XX;
+ break;
+ }
}
}
@@ -89,6 +108,19 @@ int arch_cpu_init (void)
return 0;
}
+/**
+ * Check if cpu belongs to specific family
+ *
+ * Returns 1 if true, 0 if false.
+ */
+u8 is_cpu_family(u16 family)
+{
+ if (cpu_family == family)
+ return 1;
+
+ return 0;
+}
+
/*
* dieid_num_r(void) - read and set die ID
*/
diff --git a/include/asm-arm/arch-omap3/omap3.h
b/include/asm-arm/arch-omap3/omap3.h
index 12815f6..86df1f2 100644
--- a/include/asm-arm/arch-omap3/omap3.h
+++ b/include/asm-arm/arch-omap3/omap3.h
@@ -183,4 +183,18 @@ struct gpio {
#define WIDTH_8BIT 0x
#define WIDTH_16BIT0x1000 /* bit pos for 16 bit in gpmc */
+/*
+ * Hawkeye values
+ */
+#define HAWKEYE_OMAP34XX 0xb7ae
+#define HAWKEYE_AM35XX 0xb868
+
+#define HAWKEYE_SHIFT 12
+
+/*
+ * Define CPU families
+ */
+#define CPU_OMAP34XX 0x3400 /* OMAP34xx/OMAP35 devices */
+#define CPU_AM35XX 0x3500 /* AM35xx devices */
+
#endif
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index 9ddd272..0b6e48b 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -41,6 +41,7 @@ void watchdog_init(void);
void set_muxconf_regs(void);
void identify_cpu(void);
+u8 is_cpu_family(u16);
u8 get_cpu_rev(void);
u32 get_mem_type(void);
u32 get_sysboot_value(void);
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] AM35x: Initial support for the processor
This patchset adds basic support for the AM35x processors. It also ensures that u-boot banner shows correct processor at start-up. Addition of AM35x impacts existing code for OMAP3, most patches in this set are applicable to both processor families. The series has been tested on the OMAP3EVM and AM3517EVM. To test on AM3517EVM, earlier patches posted by Vaibhav are required. [1] http://lists.denx.de/pipermail/u-boot/2009-November/064670.html Sanjeev Premi (4): AM35x: Introduce support for AM35x processors OMAP3, AM35x: Detect exact CPU in arch_cpu_init() OMAP3, AM35x: Update function print_cpuinfo() OMAP3, AM35x: Update the checks for CPU revision cpu/arm_cortexa8/omap3/cache.S | 30 +++- cpu/arm_cortexa8/omap3/clock.c |3 +- cpu/arm_cortexa8/omap3/sys_info.c | 140 +++- include/asm-arm/arch-omap3/cpu.h |6 -- include/asm-arm/arch-omap3/omap3.h | 40 +- include/asm-arm/arch-omap3/sys_proto.h |1 + 6 files changed, 188 insertions(+), 32 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc85xx, mpc86xx: Fix gd->cpu pointer after relocation
The gd->cpu pointer is set to an address located in flash when the probecpu() function is called while U-Boot is executing from flash. This pointer needs to be updated to point to an address in RAM after relocation has occurred otherwise Linux may not be able to boot due to "fdt board" crashing if flash has been erased or changed. This bug was introduced in commit a0e2066f392782730f0398095e583c87812d97f2. Signed-off-by: Peter Tyser Reported-by: Ed Swarthout --- Below is the output of Ed's test after applying this patch: U-Boot 2009.11-rc2-00110-g5b75c04-dirty (Dec 15 2009 - 12:05:00) cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 CPU0: 8572E, Version: 1.1, (0x80e80011) Core: E500, Version: 3.0, (0x80210030) cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 Clock Configuration:cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 CPU0:1333.333 MHz, cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 CPU1:1333.333 MHz, cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 CCB:533.333 MHz, DDR:333.333 MHz (666.667 MT/s data rate) (Asynchronous), LBC:66.667 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: X-ES XPedite5370 3U VPX SBC Rev A, Serial# 12345678, Cfg 12345678-1 I2C: ready DRAM: cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 cpu_numcores gd=e0003f80 cpu=fffd0a60 n=2 2 GB (DDR2, 64-bit, CL=5, ECC on) DDR Controller Interleaving Mode: bank FLASH: Executed from FLASH1 FLASH: 256 MB L2:1024 KB enabled cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 cpu_numcores gd=7fe67f78 cpu=7ffc0a60 n=2 NAND: 1024 MiB ... => md 7ffc0a60 7ffc0a60: 38353732 8572 7ffc0a70: 0080e800 0002 50313031 3100P1011... 7ffc0a80: 0080e500 0001 7ffc0a90: 50313031 3100 P1011... 7ffc0aa0: 0080ed00 0001 50313032 3000P1020... 7ffc0ab0: 0080e400 0002 7ffc0ac0: 50313032 3000 P1020... 7ffc0ad0: 0080ec00 0002 50323031 3000P2010... 7ffc0ae0: 0080e300 0001 7ffc0af0: 50323031 3000 P2010... 7ffc0b00: 0080eb00 0001 50323032 3000P2020... 7ffc0b10: 0080e200 0002 7ffc0b20: 50323032 3000 P2020... 7ffc0b30: 0080ea00 0002 50343034 3000P4040... 7ffc0b40: 00820100 0004 7ffc0b50: 50343034 3000 P4040... => lib_ppc/board.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 765f97a..dd22f99 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN; +#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) + /* +* The gd->cpu pointer is set to an address in flash before relocation. +* We need to update it to point to the same CPU entry in RAM. +*/ + gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE; +#endif + #ifdef CONFIG_SERIAL_MULTI serial_initialize(); #endif -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
On Dec 15, 2009, at 11:29 AM, Peter Tyser wrote: > On Tue, 2009-12-15 at 10:57 -0600, Kumar Gala wrote: >> On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote: >> >>> On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote: On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote: > The following debug patch shows that gd->cpu is not being relocated to > ddr. Linux may not be able to boot due to "fdt board" crashing if > flash has been erased or changed. > > On mpc8572ds: > > => fdt board > fdt board > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > > Signed-off-by: Ed Swarthout > --- > cpu/mpc8xxx/cpu.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) I agree w/Ed that we broke the relocation of gd->cpu with commit: commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser Date: Mon Sep 21 11:20:27 2009 -0500 ppc: Remove board.c relocation fixups Signed-off-by: Peter Tyser ... -#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) - gd->cpu += gd->reloc_off; -#endif Peter, Joakim, any suggestions on how to properly fix this? >>> >>> Hmm, the cpu pointer is set with a flash address since probecpu() is >>> called before relocation. The relocation fixups only update initialized >>> pointers, so the cpu pointer isn't touched during relocation fixups. >>> >>> Do we really need to call probecpu() so early? Calling it after >>> relocation would resolve the problem. Calling it both before and after >>> relocation would resolve the issue too, but seems kind of hokey. >>> >>> Otherwise we could re-add a fixup to board.c, eg: >>> diff --git a/lib_ppc/board.c b/lib_ppc/board.c >>> index 765f97a..f245a10 100644 >>> --- a/lib_ppc/board.c >>> +++ b/lib_ppc/board.c >>> @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) >>> /* The Malloc area is immediately below the monitor copy in DRAM */ >>> malloc_start = dest_addr - TOTAL_MALLOC_LEN; >>> >>> +#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) >>> + /* >>> +* The cpu pointer is set to an address in flash prior to >>> relocation. >>> +* We need to update it to point to the same CPU entry in RAM. >>> +*/ >>> + gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE; >>> +#endif >>> + >>> #ifdef CONFIG_SERIAL_MULTI >>> serial_initialize(); >>> #endif >>> >>> >>> What's less dirty, adding some magical relocation fixup math, or calling >>> a function two times to magically update a variable? Or can we just >>> call probecpu() once after relocation? >> >> Where would we call it if it was after relocation? > > Either near the top of lib_ppc/board.c:board_init_r() or possibly in > cpu/mpc8[5|6]xx/cpu_init.c:cpu_init_r(). > > I added Ed's debug, and it looks like cpu_numcores() is called many > times prior to relocation though. So I'd assume we can't just call it > once after relocation. > > So the options are: > 1. Add "gd->cpu +=" fixup to lib_ppc/board.c where it used to be (We > can't put the manual fixup in cpu/mpc8[5|6]xx/cpu_init.c since that code > won't have the relocation offset needed for fixing up). > 2. Re-call probecpu() in lib_ppc/board.c > 3. Re-call probecpu() in cpu/mpc8[5|6]xx/cpu_init.c > > I'd slightly lean towards #1, but its not particularly pretty either... I'm for #1 as well. Can you send a clean patch w/signoff. I'll test it right away. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
On Tue, 2009-12-15 at 10:57 -0600, Kumar Gala wrote: > On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote: > > > On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote: > >> On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote: > >> > >>> The following debug patch shows that gd->cpu is not being relocated to > >>> ddr. Linux may not be able to boot due to "fdt board" crashing if > >>> flash has been erased or changed. > >>> > >>> On mpc8572ds: > >>> > >>> => fdt board > >>> fdt board > >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > >>> > >>> Signed-off-by: Ed Swarthout > >>> --- > >>> cpu/mpc8xxx/cpu.c |4 +++- > >>> 1 files changed, 3 insertions(+), 1 deletions(-) > >> > >> I agree w/Ed that we broke the relocation of gd->cpu with commit: > >> > >> commit a0e2066f392782730f0398095e583c87812d97f2 > >> Author: Peter Tyser > >> Date: Mon Sep 21 11:20:27 2009 -0500 > >> > >> ppc: Remove board.c relocation fixups > >> > >> Signed-off-by: Peter Tyser > >> > >> ... > >> > >> -#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) > >> - gd->cpu += gd->reloc_off; > >> -#endif > >> > >> Peter, Joakim, > >> > >> any suggestions on how to properly fix this? > > > > Hmm, the cpu pointer is set with a flash address since probecpu() is > > called before relocation. The relocation fixups only update initialized > > pointers, so the cpu pointer isn't touched during relocation fixups. > > > > Do we really need to call probecpu() so early? Calling it after > > relocation would resolve the problem. Calling it both before and after > > relocation would resolve the issue too, but seems kind of hokey. > > > > Otherwise we could re-add a fixup to board.c, eg: > > diff --git a/lib_ppc/board.c b/lib_ppc/board.c > > index 765f97a..f245a10 100644 > > --- a/lib_ppc/board.c > > +++ b/lib_ppc/board.c > > @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) > > /* The Malloc area is immediately below the monitor copy in DRAM */ > > malloc_start = dest_addr - TOTAL_MALLOC_LEN; > > > > +#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) > > + /* > > +* The cpu pointer is set to an address in flash prior to > > relocation. > > +* We need to update it to point to the same CPU entry in RAM. > > +*/ > > + gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE; > > +#endif > > + > > #ifdef CONFIG_SERIAL_MULTI > > serial_initialize(); > > #endif > > > > > > What's less dirty, adding some magical relocation fixup math, or calling > > a function two times to magically update a variable? Or can we just > > call probecpu() once after relocation? > > Where would we call it if it was after relocation? Either near the top of lib_ppc/board.c:board_init_r() or possibly in cpu/mpc8[5|6]xx/cpu_init.c:cpu_init_r(). I added Ed's debug, and it looks like cpu_numcores() is called many times prior to relocation though. So I'd assume we can't just call it once after relocation. So the options are: 1. Add "gd->cpu +=" fixup to lib_ppc/board.c where it used to be (We can't put the manual fixup in cpu/mpc8[5|6]xx/cpu_init.c since that code won't have the relocation offset needed for fixing up). 2. Re-call probecpu() in lib_ppc/board.c 3. Re-call probecpu() in cpu/mpc8[5|6]xx/cpu_init.c I'd slightly lean towards #1, but its not particularly pretty either... Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection of cpu revision
Sanjeev Premi wrote: > Each call to get_cpu_rev() leads to repetitive > execution of code to detect the cpu revision. > > This patchset ensures that mechanism to detect > revision is not executed each time; instead a > stored value is returned. > > Since, revision info is needed in s_init(), > the function to identify cpu revision needs > to be called twice. At the moment, it is > necessary/ unavoidable. > Is there some other reason to read this register only once? This function is not used frequently and i do not think the complexity of optimizing is necessary. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
On Dec 15, 2009, at 11:01 AM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <9053d472-817a-484d-93c1-657cf15d1...@kernel.crashing.org> you > wrote: >> >> I agree w/Ed that we broke the relocation of gd->cpu with commit: > > I was on the verge of releasing v2009.11 - shall I wait for a fix? Yes, please do. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Makefile: fix parallel build
On Tuesday 15 December 2009 08:51:46 Daniel Hobi wrote: > depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk > - for dir in $(SUBDIRS) ; do $(MAKE) -C $$dir _depend ; done > + for dir in $(SUBDIRS) cpu/$(CPU) $(dir $(LDSCRIPT)) ; do \ > + $(MAKE) -C $$dir _depend ; done i'd stick a short comment here explaining the reason for the specific subdirs. otherwise, the new additions all look good to me. this is something that has annoyed me for quite a long time, but has been hard to reproduce to figure out what exactly was failing. thanks ! Signed-off-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] mpc83xx: Add NAND boot support for MPC8315E-RDB boards
The core support for NAND booting is there already, so this patch
is pretty straightforward.
There is one trick though: top level Makefile expects nand_spl to
be in nand_spl/board/$(BOARDDIR), but we can fully reuse the code
from mpc8313erdb boards, and so to not duplicate the code we just
symlink nand_spl/board/freescale/mpc8315erdb to mpc8313erdb.
Signed-off-by: Anton Vorontsov
---
On Mon, Dec 07, 2009 at 03:10:34PM -0600, Kim Phillips wrote:
> > include/configs/MPC8315ERDB.h | 95
> > +++--
> > 6 files changed, 139 insertions(+), 20 deletions(-)
>
> please add NAND boot instructions to doc/README.mpc8315erdb also.
Done.
> > + if [ "$(findstring _NAND_,$@)" ] ; then \
>
> missing leading @ - s/if/@if/.
Fixed, thanks.
> > + ln -sf mpc8313erdb nand_spl/board/freescale/mpc8315erdb ; \
> > + fi ;
>
> can we instead permanently rename
> nand_spl/board/freescale/mpc8313erdb to mpc831xerdb...argh, probably
> not without merging the non-NAND parts also...
Yep, not that easy.
> > + relocate_code(CONFIG_SYS_NAND_U_BOOT_RELOC + 0x1, (gd_t *)gd,
>
> use CONFIG_SYS_NAND_U_BOOT_RELOC_SP
Done.
> meanwhile, 8315 NAND boot doesn't build when applied to u-boot's next
> branch:
>
> Configuring for MPC8315ERDB board...
> sdram.o: In function `fixed_sdram':
> /home/r1aaha/git/u-boot/nand_spl/board/freescale/mpc8313erdb/sdram.c:72:
> undefined reference to `udelay'
>
> perhaps due to some confusion with setting CONFIG_SYS_RAMBOOT?
This is due commit 3eb90bad651fab39cffba750ec4421a9c01d60e7
("Generic udelay() with watchdog support"). SPL code doesn't
use lib_generic/time.c, so nowadays we should use __udelay().
The commit above converted MPC8313ERDB boards, but didn't do the
same for 8315 (there was no need since 8315 didn't use SPL at
that time).
Thanks!
MAKEALL |1 +
Makefile |6 ++-
board/freescale/mpc8315erdb/config.mk |8 +++
board/freescale/mpc8315erdb/mpc8315erdb.c | 42 +
board/freescale/mpc8315erdb/sdram.c |9 +++-
doc/README.mpc8315erdb| 24 +++-
include/configs/MPC8315ERDB.h | 96 +++--
7 files changed, 163 insertions(+), 23 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index ab1bb6f..1b78778 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -362,6 +362,7 @@ LIST_83xx=" \
MPC8313ERDB_33 \
MPC8313ERDB_NAND_66 \
MPC8315ERDB \
+ MPC8315ERDB_NAND\
MPC8323ERDB \
MPC832XEMDS \
MPC832XEMDS_ATM \
diff --git a/Makefile b/Makefile
index 75b2c1e..8ffaa1e 100644
--- a/Makefile
+++ b/Makefile
@@ -2294,8 +2294,12 @@ MPC8313ERDB_NAND_66_config: unconfig
echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk ; \
fi ;
+MPC8315ERDB_NAND_config \
MPC8315ERDB_config: unconfig
- @$(MKCONFIG) -a MPC8315ERDB ppc mpc83xx mpc8315erdb freescale
+ @if [ "$(findstring _NAND_,$@)" ] ; then \
+ ln -sf mpc8313erdb nand_spl/board/freescale/mpc8315erdb ; \
+ fi ;
+ @$(MKCONFIG) -t $(@:_config=) MPC8315ERDB ppc mpc83xx mpc8315erdb
freescale
MPC8323ERDB_config:unconfig
@$(MKCONFIG) -a MPC8323ERDB ppc mpc83xx mpc8323erdb freescale
diff --git a/board/freescale/mpc8315erdb/config.mk
b/board/freescale/mpc8315erdb/config.mk
index f768264..bf972fb 100644
--- a/board/freescale/mpc8315erdb/config.mk
+++ b/board/freescale/mpc8315erdb/config.mk
@@ -1 +1,9 @@
+ifndef NAND_SPL
+ifeq ($(CONFIG_MK_NAND), y)
+TEXT_BASE = $(CONFIG_RAMBOOT_TEXT_BASE)
+endif
+endif
+
+ifndef TEXT_BASE
TEXT_BASE = 0xFE00
+endif
diff --git a/board/freescale/mpc8315erdb/mpc8315erdb.c
b/board/freescale/mpc8315erdb/mpc8315erdb.c
index dea4d6f..2fcd475 100644
--- a/board/freescale/mpc8315erdb/mpc8315erdb.c
+++ b/board/freescale/mpc8315erdb/mpc8315erdb.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -45,6 +47,8 @@ int board_early_init_f(void)
return 0;
}
+#ifndef CONFIG_NAND_SPL
+
static u8 read_board_info(void)
{
u8 val8;
@@ -220,3 +224,41 @@ int board_eth_init(bd_t *bis)
cpu_eth_init(bis); /* Initialize TSECs first */
return pci_eth_init(bis);
}
+
+#else /* CONFIG_NAND_SPL */
+
+int checkboard(void)
+{
+ puts("Board: Freescale MPC8315ERDB\n");
+ return 0;
+}
+
+void board_init_f(ulong bootflag)
+{
+ board_early_init_f();
+ NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500),
+CONFIG_SYS_NS16550_CLK / 16 / CONFIG_BAUDRATE);
+ puts("NAND boot... ");
+ init_timebase();
+ initdram(0);
+ relocate_code(CONFIG_SYS_NAND_U_BOOT_RELOC_SP, (gd_t *)gd,
+ CONFIG_SYS_NAND_U_BOOT_RELOC);
+}
+
+void board_init_r(gd_t *gd, ulong dest_addr)
+{
+ nand_boot();
+}
+
+void putc(char c)
+{
+ if (gd->fla
Re: [U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
Dear Kumar Gala, In message <9053d472-817a-484d-93c1-657cf15d1...@kernel.crashing.org> you wrote: > > I agree w/Ed that we broke the relocation of gd->cpu with commit: I was on the verge of releasing v2009.11 - shall I wait for a fix? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Due to lack of disk space, this fortune database has been discontinued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 3/3] s3c24x0 code style changes
Dear Kevin, in message <4b2796b7.3000...@fearnside-systems.co.uk> you wrote: > > All I really wanted to do was change the sc324x0 register struct members > to lower case, but if I do that without cleaning up the white space I > get checkpatch.pl errors, and if I don't change the code to use the > accessor functions the patch will get NAK-ed anyway...and all I really > want to do is get the code into a state where I can add support for the > Embest SBC244-II Board! I understand and appreciate your efforts. In such a situation it is actually not really important in which order the changes are performend, but they shouldbe separated into orthogonal patches, and these patches submitted as a series. > I think I'll split the patches into a white-space change followed by an > accessor function/s3c24x0 register change patch. This is indeed the optimal sequence in this situation. > > Please also re-check the resulting code. I think there are some way > > too long lines, etc. > > checkpatch.pl didn't report any line length errors before I emailed the > patches. I'll check it again. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Humans do claim a great deal for that particular emotion (love). -- Spock, "The Lights of Zetar", stardate 5725.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
On Dec 15, 2009, at 10:17 AM, Peter Tyser wrote: > On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote: >> On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote: >> >>> The following debug patch shows that gd->cpu is not being relocated to >>> ddr. Linux may not be able to boot due to "fdt board" crashing if >>> flash has been erased or changed. >>> >>> On mpc8572ds: >>> >>> => fdt board >>> fdt board >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 >>> cpu_numcores gd=3fe6df68 cpu=effed578 n=2 >>> >>> Signed-off-by: Ed Swarthout >>> --- >>> cpu/mpc8xxx/cpu.c |4 +++- >>> 1 files changed, 3 insertions(+), 1 deletions(-) >> >> I agree w/Ed that we broke the relocation of gd->cpu with commit: >> >> commit a0e2066f392782730f0398095e583c87812d97f2 >> Author: Peter Tyser >> Date: Mon Sep 21 11:20:27 2009 -0500 >> >> ppc: Remove board.c relocation fixups >> >> Signed-off-by: Peter Tyser >> >> ... >> >> -#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) >> - gd->cpu += gd->reloc_off; >> -#endif >> >> Peter, Joakim, >> >> any suggestions on how to properly fix this? > > Hmm, the cpu pointer is set with a flash address since probecpu() is > called before relocation. The relocation fixups only update initialized > pointers, so the cpu pointer isn't touched during relocation fixups. > > Do we really need to call probecpu() so early? Calling it after > relocation would resolve the problem. Calling it both before and after > relocation would resolve the issue too, but seems kind of hokey. > > Otherwise we could re-add a fixup to board.c, eg: > diff --git a/lib_ppc/board.c b/lib_ppc/board.c > index 765f97a..f245a10 100644 > --- a/lib_ppc/board.c > +++ b/lib_ppc/board.c > @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) > /* The Malloc area is immediately below the monitor copy in DRAM */ > malloc_start = dest_addr - TOTAL_MALLOC_LEN; > > +#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) > + /* > +* The cpu pointer is set to an address in flash prior to relocation. > +* We need to update it to point to the same CPU entry in RAM. > +*/ > + gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE; > +#endif > + > #ifdef CONFIG_SERIAL_MULTI > serial_initialize(); > #endif > > > What's less dirty, adding some magical relocation fixup math, or calling > a function two times to magically update a variable? Or can we just > call probecpu() once after relocation? Where would we call it if it was after relocation? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
On Tue, 2009-12-15 at 08:49 -0600, Kumar Gala wrote: > On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote: > > > The following debug patch shows that gd->cpu is not being relocated to > > ddr. Linux may not be able to boot due to "fdt board" crashing if > > flash has been erased or changed. > > > > On mpc8572ds: > > > > => fdt board > > fdt board > > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > > > > Signed-off-by: Ed Swarthout > > --- > > cpu/mpc8xxx/cpu.c |4 +++- > > 1 files changed, 3 insertions(+), 1 deletions(-) > > I agree w/Ed that we broke the relocation of gd->cpu with commit: > > commit a0e2066f392782730f0398095e583c87812d97f2 > Author: Peter Tyser > Date: Mon Sep 21 11:20:27 2009 -0500 > > ppc: Remove board.c relocation fixups > > Signed-off-by: Peter Tyser > > ... > > -#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) > - gd->cpu += gd->reloc_off; > -#endif > > Peter, Joakim, > > any suggestions on how to properly fix this? Hmm, the cpu pointer is set with a flash address since probecpu() is called before relocation. The relocation fixups only update initialized pointers, so the cpu pointer isn't touched during relocation fixups. Do we really need to call probecpu() so early? Calling it after relocation would resolve the problem. Calling it both before and after relocation would resolve the issue too, but seems kind of hokey. Otherwise we could re-add a fixup to board.c, eg: diff --git a/lib_ppc/board.c b/lib_ppc/board.c index 765f97a..f245a10 100644 --- a/lib_ppc/board.c +++ b/lib_ppc/board.c @@ -645,6 +645,14 @@ void board_init_r (gd_t *id, ulong dest_addr) /* The Malloc area is immediately below the monitor copy in DRAM */ malloc_start = dest_addr - TOTAL_MALLOC_LEN; +#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) + /* +* The cpu pointer is set to an address in flash prior to relocation. +* We need to update it to point to the same CPU entry in RAM. +*/ + gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE; +#endif + #ifdef CONFIG_SERIAL_MULTI serial_initialize(); #endif What's less dirty, adding some magical relocation fixup math, or calling a function two times to magically update a variable? Or can we just call probecpu() once after relocation? Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Ideas on implementing bootcount limit support on non PPC?
Hi, I have been searching the archives and I've seen posts that suggest that the bootcount feature is trivial to implement in non PPC cpu's but haven't seen a discussion of what would be involved or ideas on how to go about it. I have flash (where the u-boot env. vars are stored) and EEPROM via I2c. My ARM926ejs variant has SRAM on chip, but I'm not sure of its state on reset yet. So should I use flash or eeprom to store the bootcount? I know it was originally intended to increment only on reset (not power cycle) but I don't know how I can accomplish since I asked chip vendor if any registers survive reset and the answer was "no". Looking for ideas on the best way to go about implementing this feature for a ARM926ejs based core. Actual chip is picoChip PC205. Regards, Brian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DEBUG 8xxx cpu_numcores
On Dec 15, 2009, at 1:07 AM, Ed Swarthout wrote: > The following debug patch shows that gd->cpu is not being relocated to > ddr. Linux may not be able to boot due to "fdt board" crashing if > flash has been erased or changed. > > On mpc8572ds: > > => fdt board > fdt board > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > cpu_numcores gd=3fe6df68 cpu=effed578 n=2 > > Signed-off-by: Ed Swarthout > --- > cpu/mpc8xxx/cpu.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) I agree w/Ed that we broke the relocation of gd->cpu with commit: commit a0e2066f392782730f0398095e583c87812d97f2 Author: Peter Tyser Date: Mon Sep 21 11:20:27 2009 -0500 ppc: Remove board.c relocation fixups Signed-off-by: Peter Tyser ... -#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) - gd->cpu += gd->reloc_off; -#endif Peter, Joakim, any suggestions on how to properly fix this? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Davinci: davinci_nand.c performance enhancments
Introduces various optimisations that approximately triple the
read data rate from NAND when run on da830evm.
Most of these optimisations depend on the endianess of the machine
and most of them are very similar to optimisations already present
in the Linux Kernel.
Signed-off-by: Nick Thompson
---
drivers/mtd/nand/davinci_nand.c | 140 +++
1 files changed, 97 insertions(+), 43 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 90e038e..3ce75ea 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -59,14 +59,67 @@
static emif_registers *const emif_regs = (void *)
DAVINCI_ASYNC_EMIF_CNTRL_BASE;
+/*
+ * Exploit the little endianness of the ARM to do multi-byte transfers
+ * per device read. This can perform over twice as quickly as individual
+ * byte transfers when buffer alignment is conducive.
+ *
+ * NOTE: This only works if the NAND is not connected to the 2 LSBs of
+ * the address bus. On Davinci EVM platforms this has always been true.
+ */
+static void nand_davinci_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ const u32 *nand = chip->IO_ADDR_R;
+
+ if int)buf | len) & 0x3) == 0)
+ while (len > 0) {
+ *(u32 *)buf = readl(nand);
+ buf += 4;
+ len -= 4;
+ }
+ else if int)buf | len) & 0x1) == 0)
+ while (len > 0) {
+ *(u16 *)buf = readw(nand);
+ buf += 2;
+ len -= 2;
+ }
+ else
+ while (len-- > 0)
+ *buf++ = readb(nand);
+}
+
+static void nand_davinci_write_buf(struct mtd_info *mtd, const uint8_t *buf,
+ int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ const u32 *nand = chip->IO_ADDR_W;
+
+ if int)buf | len) & 0x3) == 0)
+ while (len > 0) {
+ writel(*(u32 *)buf, nand);
+ buf += 4;
+ len -= 4;
+ }
+ else if int)buf | len) & 0x1) == 0)
+ while (len > 0) {
+ writew(*(u16 *)buf, nand);
+ buf += 2;
+ len -= 2;
+ }
+ else
+ while (len-- > 0)
+ writeb(*buf++, nand);
+}
+
static void nand_davinci_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
{
struct nand_chip *this = mtd->priv;
u_int32_t IO_ADDR_W = (u_int32_t)this->IO_ADDR_W;
- IO_ADDR_W &= ~(MASK_ALE|MASK_CLE);
-
if (ctrl & NAND_CTRL_CHANGE) {
+ IO_ADDR_W &= ~(MASK_ALE|MASK_CLE);
+
if ( ctrl & NAND_CLE )
IO_ADDR_W |= MASK_CLE;
if ( ctrl & NAND_ALE )
@@ -75,7 +128,7 @@ static void nand_davinci_hwcontrol(struct mtd_info *mtd, int
cmd, unsigned int c
}
if (cmd != NAND_CMD_NONE)
- writeb(cmd, this->IO_ADDR_W);
+ writeb(cmd, IO_ADDR_W);
}
#ifdef CONFIG_SYS_NAND_HW_ECC
@@ -247,26 +300,25 @@ static int nand_davinci_4bit_calculate_ecc(struct
mtd_info *mtd,
const uint8_t *dat,
uint8_t *ecc_code)
{
- unsigned int hw_4ecc[4] = { 0, 0, 0, 0 };
- unsigned int const1 = 0, const2 = 0;
- unsigned char count1 = 0;
+ unsigned int hw_4ecc[4];
+ unsigned int const1;
+ unsigned char count1;
nand_davinci_4bit_readecc(mtd, hw_4ecc);
/*Convert 10 bit ecc value to 8 bit */
for (count1 = 0; count1 < 2; count1++) {
- const2 = count1 * 5;
const1 = count1 * 2;
/* Take first 8 bits from val1 (count1=0) or val5 (count1=1) */
- ecc_code[const2] = hw_4ecc[const1] & 0xFF;
+ *ecc_code++ = hw_4ecc[const1] & 0xFF;
/*
* Take 2 bits as LSB bits from val1 (count1=0) or val5
* (count1=1) and 6 bits from val2 (count1=0) or
* val5 (count1=1)
*/
- ecc_code[const2 + 1] =
+ *ecc_code++ =
((hw_4ecc[const1] >> 8) & 0x3) | ((hw_4ecc[const1] >> 14) &
0xFC);
@@ -274,7 +326,7 @@ static int nand_davinci_4bit_calculate_ecc(struct mtd_info
*mtd,
* Take 4 bits from val2 (count1=0) or val5 (count1=1) and
* 4 bits from val3 (count1=0) or val6 (count1=1)
*/
- ecc_code[const2 + 2] =
+ *ecc_code++ =
((hw_4ecc[const1] >> 22) & 0xF) |
((hw_4ecc[const1 + 1] << 4) & 0xF0);
@@ -282,13 +334,1
Re: [U-Boot] [PATCH ARM 3/3] s3c24x0 code style changes
Wolfgang Denk wrote: > Dear "kevin.morf...@fearnside-systems.co.uk", > > In message <4b2548ff.6040...@fearnside-systems.co.uk> you wrote: >> Cleans up the s3c24x0 header files by changing the upper case members >> of the s3c24x0 register structures to lower case and changing all code >> that uses these register structures. > > The commit message should also mention that you convert the code into > using accessor functions. > > You also perform a white space cleanup here. this may be a good thing > (opinions differ), but in any case it is an unrelated change that must > be performed in a separate commit. > All I really wanted to do was change the sc324x0 register struct members to lower case, but if I do that without cleaning up the white space I get checkpatch.pl errors, and if I don't change the code to use the accessor functions the patch will get NAK-ed anyway...and all I really want to do is get the code into a state where I can add support for the Embest SBC244-II Board! I think I'll split the patches into a white-space change followed by an accessor function/s3c24x0 register change patch. > Note that the same applies to the other two patches. > > Please also re-check the resulting code. I think there are some way > too long lines, etc. checkpatch.pl didn't report any line length errors before I emailed the patches. I'll check it again. > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Makefile: fix parallel build
During parallel build, the top Makefile spawns multiple sub-makes for
targets in cpu/$(CPU) and $(dir $(LDSCRIPT)). If the .depend files are
not present in these directories, the sub-makes may end up generating
these files simultaneously which leads to corrupted content.
A typical error message is:
.depend:39: *** multiple target patterns. Stop.
This patch serializes the creation of .depend in cpu/$(CPU) and
$(dir $(LDSCRIPT)) by adding these directories to the depend target
in the top Makefile.
Other directories in $(LIBS) are not affected since they contain only
one Make target and thus only one sub-make is spawned per directory.
Signed-off-by: Daniel Hobi
---
v2:
- Break overlong line
- Add comment about other directories to commit message
- Also build target _depend in $(dir $(LDSCRIPT)) (as suggested by Mike)
This requires the Makefile in $(dir $(LDSCRIPT)) to provide a
_depend target, which is the case for all LDSCRIPT values in the
current tree
diff --git a/Makefile b/Makefile
index 19b5ac0..e9be7a5 100644
--- a/Makefile
+++ b/Makefile
@@ -400,7 +400,8 @@ env:
$(MAKE) -C tools/env all MTD_VERSION=${MTD_VERSION} || exit 1
depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
- for dir in $(SUBDIRS) ; do $(MAKE) -C $$dir _depend ; done
+ for dir in $(SUBDIRS) cpu/$(CPU) $(dir $(LDSCRIPT)) ; do \
+ $(MAKE) -C $$dir _depend ; done
TAG_SUBDIRS += include
TAG_SUBDIRS += lib_generic board/$(BOARDDIR)
--
1.6.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] omap3: Identify cpu in s_init()
When s_init() is called, the silicon version hasn't yet
been identified. This would lead to incorrect index in
the DPLL table.
This patch ensures that silicon is identified as first
step in s_init().
When called from s_init(), the globals updated in the
function identify_cpu() lie in 'relocated' address
space.
So, identify_cpu() is called again in arch_cpu_init().
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/board.c |2 ++
cpu/arm_cortexa8/omap3/sys_info.c | 17 +++--
include/asm-arm/arch-omap3/sys_proto.h |1 +
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 2aa69b3..2f27cb9 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -193,6 +193,8 @@ void s_init(void)
{
int in_sdram = is_running_in_sdram();
+ identify_cpu();
+
watchdog_init();
try_unlock_memory();
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 40866ae..449262a 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -44,11 +44,11 @@ static char *rev_s[CPU_3XX_MAX_REV] = {
static u8 cpu_revision;
/**
- * Perform architecture specific initialization.
+ * Identify the silicon
*
* Currently, it identifies the cpu revision.
*/
-int arch_cpu_init (void)
+void identify_cpu (void)
{
u32 cpuid = 0;
struct ctrl_id *id_base;
@@ -72,6 +72,19 @@ int arch_cpu_init (void)
if(cpu_revision == 0)
cpu_revision = CPU_3XX_ES20;
}
+}
+
+/**
+ * Perform architecture specific initialization
+ */
+int arch_cpu_init (void)
+{
+ /*
+* The identification done in s_init is 'lost' due to
+* relocation. The variable contents are not same.
+* Function identify_cpu() is called again.
+*/
+ identify_cpu();
return 0;
}
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index 1c99c45..9ddd272 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -40,6 +40,7 @@ void enable_gpmc_cs_config(const u32 *gpmc_config, struct
gpmc_cs *cs, u32 base,
void watchdog_init(void);
void set_muxconf_regs(void);
+void identify_cpu(void);
u8 get_cpu_rev(void);
u32 get_mem_type(void);
u32 get_sysboot_value(void);
--
1.6.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] omap3: Optimize detection of cpu revision
Each call to get_cpu_rev() leads to repetitive execution of code to detect the cpu revision. This patchset ensures that mechanism to detect revision is not executed each time; instead a stored value is returned. Since, revision info is needed in s_init(), the function to identify cpu revision needs to be called twice. At the moment, it is necessary/ unavoidable. Sanjeev Premi (2): omap3: Identify the CPU in arch_cpu_init() omap3: Identify cpu in s_init() cpu/arm_cortexa8/omap3/board.c |2 + cpu/arm_cortexa8/omap3/sys_info.c | 73 ++-- include/asm-arm/arch-omap3/sys_proto.h |3 +- include/configs/omap3_beagle.h |2 + include/configs/omap3_evm.h|2 + include/configs/omap3_overo.h |2 + include/configs/omap3_pandora.h|2 + include/configs/omap3_zoom1.h |2 + include/configs/omap3_zoom2.h |2 + 9 files changed, 66 insertions(+), 24 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] omap3: Identify the CPU in arch_cpu_init()
The function get_cpu_rev() is called multiple times
during execution resulting in probe into the IDCODE
register to extract the revision information.
This patch does the following:
- Moves the steps to identify static cpu information
into arch_cpu_init().
- Updates configs for all omap3 boards to define
CONFIG_ARCH_CPU_INIT.
- Updates get_cpu_rev() to return value calculated in
arch_cpu_init().
- Since revision isn't expected to be longer than 8bits,
get_cpu_rev() return a u8 value instead of u32.
Signed-off-by: Sanjeev Premi
---
cpu/arm_cortexa8/omap3/sys_info.c | 60 +++
include/asm-arm/arch-omap3/sys_proto.h |2 +-
include/configs/omap3_beagle.h |2 +
include/configs/omap3_evm.h|2 +
include/configs/omap3_overo.h |2 +
include/configs/omap3_pandora.h|2 +
include/configs/omap3_zoom1.h |2 +
include/configs/omap3_zoom2.h |2 +
8 files changed, 50 insertions(+), 24 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 31b2003..40866ae 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -41,6 +41,41 @@ static char *rev_s[CPU_3XX_MAX_REV] = {
"3.0",
"3.1"};
+static u8 cpu_revision;
+
+/**
+ * Perform architecture specific initialization.
+ *
+ * Currently, it identifies the cpu revision.
+ */
+int arch_cpu_init (void)
+{
+ u32 cpuid = 0;
+ struct ctrl_id *id_base;
+
+ /*
+* On ES1.0 the IDCODE register is not exposed on L4
+* so using CPU ID to differentiate between ES1.0 and > ES1.0.
+*/
+ __asm__ __volatile__("mrc p15, 0, %0, c0, c0, 0":"=r"(cpuid));
+ if ((cpuid & 0xf) == 0x0) {
+ cpu_revision = CPU_3XX_ES10;
+ } else {
+ /* Decode the IDs on > ES1.0 */
+ id_base = (struct ctrl_id *) OMAP34XX_ID_L4_IO_BASE;
+
+ cpuid = readl(&id_base->idcode);
+
+ cpu_revision = (cpuid >> CPU_3XX_ID_SHIFT) & 0xf;
+
+ /* Some early ES2.0 seem to report rev 0, fix this */
+ if(cpu_revision == 0)
+ cpu_revision = CPU_3XX_ES20;
+ }
+
+ return 0;
+}
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -78,30 +113,9 @@ u32 get_cpu_type(void)
/**
* get_cpu_rev(void) - extract version info
**/
-u32 get_cpu_rev(void)
+u8 get_cpu_rev(void)
{
- u32 cpuid = 0;
- struct ctrl_id *id_base;
-
- /*
-* On ES1.0 the IDCODE register is not exposed on L4
-* so using CPU ID to differentiate between ES1.0 and > ES1.0.
-*/
- __asm__ __volatile__("mrc p15, 0, %0, c0, c0, 0":"=r"(cpuid));
- if ((cpuid & 0xf) == 0x0)
- return CPU_3XX_ES10;
- else {
- /* Decode the IDs on > ES1.0 */
- id_base = (struct ctrl_id *) OMAP34XX_ID_L4_IO_BASE;
-
- cpuid = (readl(&id_base->idcode) >> CPU_3XX_ID_SHIFT) & 0xf;
-
- /* Some early ES2.0 seem to report ID 0, fix this */
- if(cpuid == 0)
- cpuid = CPU_3XX_ES20;
-
- return cpuid;
- }
+ return cpu_revision;
}
/
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index 34bd515..1c99c45 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -40,7 +40,7 @@ void enable_gpmc_cs_config(const u32 *gpmc_config, struct
gpmc_cs *cs, u32 base,
void watchdog_init(void);
void set_muxconf_regs(void);
-u32 get_cpu_rev(void);
+u8 get_cpu_rev(void);
u32 get_mem_type(void);
u32 get_sysboot_value(void);
u32 is_gpmc_muxed(void);
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 19a5ec9..640562c 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -28,6 +28,8 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#define CONFIG_ARCH_CPU_INIT 1
+
/*
* High Level Configuration Options
*/
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index a5514ae..0e85393 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -33,6 +33,8 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#define CONFIG_ARCH_CPU_INIT 1
+
/*
* High Level Configuration Options
*/
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index ffb515d..4ff06a3 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -20,6 +20,8 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#define CONFIG_ARCH_CPU_INIT 1
Re: [U-Boot] Problem with transparent PCI-PCI bridge on Canyonlands
Hi, Stefan Stefan Roese wrote: > Felix, > > On Tuesday 15 December 2009 08:30:26 Felix Radensky wrote: > >> Can I do anything else to help you identify the problem ? >> > > Do you have other PPC4xx boards, in which you could test this PCI-PCI bridge > board? > No, I don't. > Some other comments below. > > >> Thanks. >> >> Felix. >> >> Felix Radensky wrote: >> >>> Hi, >>> >>> Feng Kan wrote: >>> Can you turn on the additional debug information. That will give a better Clue as to what part is hanging. >>> I've enabled debugging in drivers/pci/pci.c. I'm seeing an infinite flow >>> of messages >>> >>> PCI: Bus Dev VenId DevId Class Int >>> PCI Scan: Found Bus 0, Device 6, Function 0 >>> PCI Scan: Found Bus 1, Device 6, Function 0 >>> ... >>> PCI Scan: Found Bus 255, Device 6, Function 0 >>> PCI Scan: Found Bus 0, Device 6, Function 0 >>> PCI Scan: Found Bus 1, Device 6, Function 0 >>> ... >>> > > Strange to see an infinite loop here. I suggest you debug, why > pci_hose_scan_bus() is called endlessly. Hard to guess without access to such > a board. > OK, thanks. I'll look into it. Felix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 3/3] s3c24x0 code style changes
Dear "kevin.morf...@fearnside-systems.co.uk", In message <4b2548ff.6040...@fearnside-systems.co.uk> you wrote: > Cleans up the s3c24x0 header files by changing the upper case members > of the s3c24x0 register structures to lower case and changing all code > that uses these register structures. The commit message should also mention that you convert the code into using accessor functions. You also perform a white space cleanup here. this may be a good thing (opinions differ), but in any case it is an unrelated change that must be performed in a separate commit. Note that the same applies to the other two patches. Please also re-check the resulting code. I think there are some way too long lines, etc. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Is there a way to determine Yesterday's date using Unix utilities? echo "what is yesterday's date?" | /bin/mail root -- Randal L. Schwartz in ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 1/3] s3c24x0 code style changes
Dear "kevin.morf...@fearnside-systems.co.uk",
In message <4b2548eb.4000...@fearnside-systems.co.uk> you wrote:
> Cleans up the s3c24x0 header files by changing the upper case members
> of the s3c24x0 register structures to lower case and changing all code
> that uses these register structures.
>
> Signed-off-by: Kevin Morfitt
Thanks for doing such cleanup.
> The patches are based on the u-boot-samsung repository.
Please adhere to posting guidelines. Patches posted ere MUST be based
either on the "master" or on the "next" trees.
Please considered these patches NAKed because of this.
...
> --- a/cpu/arm920t/s3c24x0/usb_ohci.c
> +++ b/cpu/arm920t/s3c24x0/usb_ohci.c
> @@ -212,8 +212,8 @@ void ep_print_int_eds(struct ohci *ohci, char *str)
> printf(__FILE__ ": %s branch int %2d(%2x):", str, i, i);
> while (*ed_p != 0 && j--) {
> struct ed *ed = (struct ed *) m32_swap(ed_p);
> - printf(" ed: %4x;", ed->hwINFO);
> - ed_p = &ed->hwNextED;
> + printf(" ed: %4x;", ed->hwinfo);
> + ed_p = &ed->hwnexted;
Her readability suffers a lot. What is "hwnexted" ??It might make
sense to add some underscores here to improve readability - or chose
better variable names.
> - dbg("%08x", edp->hwINFO);
> - dbg("%08x", edp->hwTailP);
> - dbg("%08x", edp->hwHeadP);
> - dbg("%08x", edp->hwNextED);
> + dbg("%08x", edp->hwinfo);
> + dbg("%08x", edp->hwtailp);
> + dbg("%08x", edp->hwheadp);
> + dbg("%08x", edp->hwnexted);
Ditto. Please check globally.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"A fractal is by definition a set for which the Hausdorff Besicovitch
dimension strictly exceeds the topological dimension."
- Mandelbrot, _The Fractal Geometry of Nature_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH ARM 2/3] s3c24x0 code style changes
Dear "kevin.morf...@fearnside-systems.co.uk",
In message <4b2548f7.2060...@fearnside-systems.co.uk> you wrote:
> Cleans up the s3c24x0 header files by changing the upper case members
> of the s3c24x0 register structures to lower case and changing all code
> that uses these register structures.
>
> Signed-off-by: Kevin Morfitt
> ---
> board/mpl/vcma9/vcma9.c | 264 ++-
> board/mpl/vcma9/vcma9.h | 91 +++---
> board/samsung/smdk2400/smdk2400.c | 53 ++--
> board/samsung/smdk2410/smdk2410.c | 85 +++---
> board/sbc2410x/sbc2410x.c | 131 +-
> board/trab/cmd_trab.c | 547 +---
> board/trab/rs485.c| 92 ---
> 7 files changed, 626 insertions(+), 637 deletions(-)
>
> diff --git a/board/mpl/vcma9/vcma9.c b/board/mpl/vcma9/vcma9.c
> index 1835677..84338eb 100644
> --- a/board/mpl/vcma9/vcma9.c
> +++ b/board/mpl/vcma9/vcma9.c
> @@ -39,32 +39,31 @@ DECLARE_GLOBAL_DATA_PTR;
> #define FCLK_SPEED 1
>
> #if FCLK_SPEED==0/* Fout = 203MHz, Fin = 12MHz for Audio */
> -#define M_MDIV 0xC3
> -#define M_PDIV 0x4
> -#define M_SDIV 0x1
> + #define M_MDIV 0xC3
> + #define M_PDIV 0x4
> + #define M_SDIV 0x1
> #elif FCLK_SPEED==1 /* Fout = 202.8MHz */
> -#define M_MDIV 0xA1
> -#define M_PDIV 0x3
> -#define M_SDIV 0x1
> + #define M_MDIV 0xA1
> + #define M_PDIV 0x3
> + #define M_SDIV 0x1
> #endif
>
> #define USB_CLOCK 1
>
> #if USB_CLOCK==0
> -#define U_M_MDIV 0xA1
> -#define U_M_PDIV 0x3
> -#define U_M_SDIV 0x1
> + #define U_M_MDIV0xA1
> + #define U_M_PDIV0x3
> + #define U_M_SDIV0x1
> #elif USB_CLOCK==1
> -#define U_M_MDIV 0x48
> -#define U_M_PDIV 0x3
> -#define U_M_SDIV 0x2
> + #define U_M_MDIV0x48
> + #define U_M_PDIV0x3
> + #define U_M_SDIV0x2
> #endif
NAK. C preprocessor lines always start in the first column. Do not do
this.
> int board_init(void)
> {
> - struct s3c24x0_clock_power * const clk_power =
> - s3c24x0_get_base_clock_power();
> - struct s3c24x0_gpio * const gpio = s3c24x0_get_base_gpio();
> + struct s3c24x0_clock_power *const clk_power =
> + s3c24x0_get_base_clock_power();
Indentation not by TAB.
> /* set up the I/O ports */
> - gpio->GPACON = 0x007F;
> - gpio->GPBCON = 0x002A;
> - gpio->GPBUP = 0x02BF;
> - gpio->GPCCON = 0x;
> - gpio->GPCUP = 0x;
> - gpio->GPDCON = 0x;
> - gpio->GPDUP = 0x;
> - gpio->GPECON = 0x;
> - gpio->GPEUP = 0x37F7;
> - gpio->GPFCON = 0x;
> - gpio->GPFUP = 0x;
> - gpio->GPGCON = 0xFFEAFF5A;
> - gpio->GPGUP = 0xF0DC;
> - gpio->GPHCON = 0x0028;
> - gpio->GPHUP = 0x0656;
> + writel(0x007F, &gpio->gpacon);
> + writel(0x002A, &gpio->gpbcon);
> + writel(0x02BF, &gpio->gpbup);
> + writel(0x, &gpio->gpccon);
> + writel(0x, &gpio->gpcup);
> + writel(0x, &gpio->gpdcon);
> + writel(0x, &gpio->gpdup);
> + writel(0x, &gpio->gpecon);
> + writel(0x37F7, &gpio->gpeup);
> + writel(0x, &gpio->gpfcon);
> + writel(0x, &gpio->gpfup);
> + writel(0xFFEAFF5A, &gpio->gpgcon);
> + writel(0xF0DC, &gpio->gpgup);
> + writel(0x0028, &gpio->gphcon);
> + writel(0x0656, &gpio->gphup);
Such a change should introduce symbolic constants for all thes magic
numbers, and add comments what they actually do.
> #if defined(CONFIG_CMD_NAND)
> -extern ulong
> -nand_probe(ulong physadr);
> -
> +extern ulong nand_probe(ulong physadr);
Please move proprtypes to appropriate header files.
...
> -
> NF_Conf((1<<15)|(0<<14)|(0<<13)|(1<<12)|(1<<11)|(TACLS<<8)|(TWRPH0<<4)|(TWRPH1<<0));
> -/*nand->NFCONF =
> (1<<15)|(1<<14)|(1<<13)|(1<<12)|(1<<11)|(TACLS<<8)|(TWRPH0<<4)|(TWRPH1<<0); */
> -/* 1 11 1, 1 xxx, r xxx, r xxx */
> -/* En 512B 4step ECCR nFCE=H tACLS tWRPH0 tWRPH1 */
> + nf_conf((1 << 15) | (0 << 14) | (0 << 13) | (1 << 12) | (1 << 11) |
> + (TACLS << 8) | (TWRPH0 << 4) | (TWRPH1 << 0));
> + /*nand->NFCONF =
> (1<<15)|(1<<14)|(1<<13)|(1<<12)|(1<<11)|(TACLS<<8)|(TWRPH0<<4)|(TWRPH1<<0); */
Line too long. Please check globally.
> #ifdef DEBUG
> - printf("NAND flash probing at 0x%.8lX\n", (ulong)nand);
> + printf("NAND flash probing at 0x%.8lX\n", (ulong) nand);
> #endif
> - printf ("%4lu MB\n", nand_probe((ulong)nand) >> 20);
> + printf("%4lu MB\n", nand_probe((ulong) nand) >> 20);
No additional spaces here.
> -static inline void NF_WaitRB(void)
> +static inline void nf_waitrb(void)
> {
> - struct s3c2410_nand * const nand = s3c2410_get_base_nand();
> + struct s3c24
[U-Boot] [PATCH] TI: DaVinci: Updating EMAC driver for DM365, DM646x and DA8XX
The EMAC IP on DM365, DM646x and DA830 is slightly different
from that on DM644x. This change updates the DaVinci EMAC driver
so that EMAC becomes operational on SOCs with EMAC v2.
Signed-off-by: Nick Thompson
Signed-off-by: Sandeep Paulraj
---
Applies to: u-boot-ti
This is a combined patch with Sandeep's DM365 and DM646x changes
and additional changes for DA830. It replaces previous submissions
for EMAC support on these devices.
drivers/net/davinci_emac.c | 131 -
include/asm-arm/arch-davinci/emac_defs.h | 60 +-
2 files changed, 164 insertions(+), 27 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index fa8cee4..dbf94d2 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
unsigned int emac_dbg = 0;
#define debug_emac(fmt,args...)if (emac_dbg) printf(fmt,##args)
@@ -107,6 +108,35 @@ static void davinci_eth_mdio_enable(void)
while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE) {;}
}
+/* Read a PHY register via MDIO inteface */
+int mdio_read(int phy_addr, int reg_num)
+{
+ writel(MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_READ |
+ ((reg_num & 0x1F) << 21) |
+ ((phy_addr & 0x1F) << 16),
+ &adap_mdio->USERACCESS0);
+
+ /* Wait for command to complete */
+ while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO);
+
+ return readl(&adap_mdio->USERACCESS0) & 0x;
+}
+
+/* Write to a PHY register via MDIO inteface */
+void mdio_write(int phy_addr, int reg_num, unsigned int data)
+{
+ /* Wait for User access register to be ready */
+ while (readl(&adap_mdio->USERACCESS0) & MDIO_USERACCESS0_GO);
+
+ writel(MDIO_USERACCESS0_GO |
+ MDIO_USERACCESS0_WRITE_WRITE |
+ ((reg_num & 0x1F) << 21) |
+ ((phy_addr & 0x1F) << 16) |
+ (data & 0x),
+ &adap_mdio->USERACCESS0);
+}
+
/*
* Tries to find an active connected PHY. Returns 1 if address if found.
* If no active PHY (or more than one PHY) found returns 0.
@@ -119,7 +149,8 @@ static int davinci_eth_phy_detect(void)
active_phy_addr = 0xff;
- if ((phy_act_state = adap_mdio->ALIVE) == 0)
+ phy_act_state = adap_mdio->ALIVE & EMAC_MDIO_PHY_MASK;
+ if (phy_act_state == 0)
return(0); /* No active PHYs */
debug_emac("davinci_eth_phy_detect(), ALIVE = 0x%08x\n", phy_act_state);
@@ -245,9 +276,33 @@ static int davinci_mii_phy_write(char *devname, unsigned
char addr, unsigned cha
{
return(davinci_eth_phy_write(addr, reg, value) ? 0 : 1);
}
-
#endif
+static void emac_gigabit_enable(void)
+{
+#ifdef DAVINCI_EMAC_GIG_ENABLE
+ int temp
+
+ if (mdio_read(EMAC_MDIO_PHY_NUM, 0) & (1 << 6)) {
+ /*
+* Check if link detected is giga-bit
+* If Gigabit mode detected, enable gigbit in MAC and PHY
+*/
+ writel(EMAC_MACCONTROL_GIGFORCE |
+ EMAC_MACCONTROL_GIGABIT_ENABLE,
+ &adap_emac->MACCONTROL);
+
+ /*
+* The SYS_CLK which feeds the SOC for giga-bit operation
+* does not seem to be enabled after reset as expected.
+* Force enabling SYS_CLK by writing to the PHY
+*/
+ temp = mdio_read(EMAC_MDIO_PHY_NUM, 22);
+ temp |= (1 << 4);
+ mdio_write(EMAC_MDIO_PHY_NUM, 22, temp);
+ }
+#endif
+}
/* Eth device open */
static int davinci_eth_open(struct eth_device *dev, bd_t *bis)
@@ -255,16 +310,23 @@ static int davinci_eth_open(struct eth_device *dev, bd_t
*bis)
dv_reg_paddr;
u_int32_t clkdiv, cnt;
volatile emac_desc *rx_desc;
+ unsigned long mac_hi;
+ unsigned long mac_lo;
debug_emac("+ emac_open\n");
/* Reset EMAC module and disable interrupts in wrapper */
adap_emac->SOFTRESET = 1;
while (adap_emac->SOFTRESET != 0) {;}
+#if defined(DAVINCI_EMAC_VERSION2)
+ writel(1, &adap_ewrap->softrst);
+ while (readl(&adap_ewrap->softrst) != 0);
+#else
adap_ewrap->EWCTL = 0;
for (cnt = 0; cnt < 5; cnt++) {
clkdiv = adap_ewrap->EWCTL;
}
+#endif
rx_desc = emac_rx_desc;
@@ -274,27 +336,27 @@ static int davinci_eth_open(struct eth_device *dev, bd_t
*bis)
/* Set MAC Addresses & Init multicast Hash to 0 (disable any multicast
receive) */
/* Using channel 0 only - other channels are disabled */
adap_emac->MACINDEX = 0;
- adap_emac->MACADDRHI =
- (davinci_eth_mac_addr[3] << 24) |
- (davinci_eth_mac_addr[2] << 16) |
- (davinci_eth_mac_addr[1] <<
Re: [U-Boot] [PATCH] Makefile: fix parallel build
On Tuesday 15 December 2009 04:21:02 Daniel Hobi wrote: > On 11.12.2009 20:25, Mike Frysinger wrote: > > On Thursday 10 December 2009 08:41:07 Daniel Hobi wrote: > >> During parallel build, the top Makefile spawns multiple sub-makes > >> for targets in cpu/$(CPU). If cpu/$(CPU)/.depend is not present, the > >> sub-makes may end up generating this file simultaneously which leads > >> to corrupted content. > >> > >> A typical error message is: > >> > >> .depend:39: *** multiple target patterns. Stop. > >> > >> This patch serializes the creation of cpu/$(CPU)/.depend by adding > >> cpu/$(CPU) to the depend target in the top Makefile. > > > > seems to happen in lib_$(ARCH)/ too, but in reviewing my logs from the > > last few months, most parallel .depend failures have indeed been in > > cpu/$(CPU)/. maybe this is just coincidence though ... perhaps the depend > > target should walk all subdirs instead of a just random few ones (use > > LIBS). > > The problem with cpu/$(CPU)/ is that the top Makefile builds multiple > targets within this directory in parallel - at least start.o and > lib$(CPU).a. For all other directories, parallel build should work, > since there is only one target per directory. OK, that answers the next part > Can you provide any commit ID where building lib_$(ARCH)/ failed? it isnt specific to lib_$(ARCH). wherever the LDSCRiPT is located will cause a problem. in the Blackfin case, it's in lib_blackfin/. so maybe to extend this workaround, add like $(dir $(LDSCRIPT)) to the list. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: fix parallel build
On 11.12.2009 20:25, Mike Frysinger wrote: > On Thursday 10 December 2009 08:41:07 Daniel Hobi wrote: >> During parallel build, the top Makefile spawns multiple sub-makes >> for targets in cpu/$(CPU). If cpu/$(CPU)/.depend is not present, the >> sub-makes may end up generating this file simultaneously which leads >> to corrupted content. >> >> A typical error message is: >> >> .depend:39: *** multiple target patterns. Stop. >> >> This patch serializes the creation of cpu/$(CPU)/.depend by adding >> cpu/$(CPU) to the depend target in the top Makefile. > > seems to happen in lib_$(ARCH)/ too, but in reviewing my logs from the last > few months, most parallel .depend failures have indeed been in cpu/$(CPU)/. > maybe this is just coincidence though ... perhaps the depend target should > walk all subdirs instead of a just random few ones (use LIBS). The problem with cpu/$(CPU)/ is that the top Makefile builds multiple targets within this directory in parallel - at least start.o and lib$(CPU).a. For all other directories, parallel build should work, since there is only one target per directory. Can you provide any commit ID where building lib_$(ARCH)/ failed? Thus, adding all LIBS to the depend target should not make any difference. In order to properly track such dependencies we should switch to non-recursive Makefiles (as seen in Linux) since Recursive Make [is] Considered Harmful[1]. [1] http://miller.emu.id.au/pmiller/books/rmch/ Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problem with transparent PCI-PCI bridge on Canyonlands
Felix, On Tuesday 15 December 2009 08:30:26 Felix Radensky wrote: > Can I do anything else to help you identify the problem ? Do you have other PPC4xx boards, in which you could test this PCI-PCI bridge board? Some other comments below. > Thanks. > > Felix. > > Felix Radensky wrote: > > Hi, > > > > Feng Kan wrote: > >> Can you turn on the additional debug information. That will give a > >> better > >> Clue as to what part is hanging. > > > > I've enabled debugging in drivers/pci/pci.c. I'm seeing an infinite flow > > of messages > > > > PCI: Bus Dev VenId DevId Class Int > > PCI Scan: Found Bus 0, Device 6, Function 0 > > PCI Scan: Found Bus 1, Device 6, Function 0 > > ... > > PCI Scan: Found Bus 255, Device 6, Function 0 > > PCI Scan: Found Bus 0, Device 6, Function 0 > > PCI Scan: Found Bus 1, Device 6, Function 0 > > ... Strange to see an infinite loop here. I suggest you debug, why pci_hose_scan_bus() is called endlessly. Hard to guess without access to such a board. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
