Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear Albert ARIBAUD, In message 4cf74fed.2030...@free.fr you wrote: BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2... ... plus it removes the linker warning! Oops. Why would this make a difference? I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board. No, I don't think this is a good idea as it just papers over an existing problem. Does it help when you change the *(.bss) in arch/arm/cpu/armv7/u-boot.lds into *(.*bss) (so it also includes any .sbss objects) ? 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 ATTENTION: Despite Any Other Listing of Product Contents Found Here- on, the Consumer is Advised That, in Actuality, This Product Consists Of 99.99% Empty Space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:21 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Hi Wolfgang, Le 02/12/2010 08:34, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf743e6.60...@free.fr you wrote: Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation. Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init. This should be safe. Alright. You could try out what happens if you make get_omap3_evm_rev() static... No change: the warning remains, and so do the two segments. Maybe I should subscribe the binutils list and ask there. Meanwhile, this variable could be initialized to some safe value such as OMAP3EVM_BOARD_UNKNOWN. One of the things I did to move it away from .bss BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2... ... plus it removes the linker warning! I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board. Albert, I have already done this - may not be exactly same. while trying to debug linker script problem; did not want to deviate from the current problem so it is in my working code. ~sanjeev Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 12:30 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Wolfgang Denk Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Le 01/12/2010 22:39, Albert ARIBAUD a écrit : This one is a conundrum. Using 2010q1, building omap3_evm causes a linker warning arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8f0 overlaps previous sections while building omap3_beagle does not cause any linker warning. Both boards use the same armv7 u-boot.lds and have a .bss which is way bigger than the .rel.dyn plus .dynsym sections that it does overlay. IOW, they have a similar layout for .rel.dyn, .dynsym and .bss, but one gets the warning and one does not. The one difference a readelf shows is that for beagle, there is only one segment: 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym While for evm there is 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .bss 01 .dynsym Note that .bss has appeared in segment 00 for evm, whereas it was absent for beagle, and that .dynsym was rejected to a second segment -- why? I don't know. Note: I've tried with putting input sections .rel.dyn and .dynsym into a single output section .rel.dyn: this makes the second segment disappear, but for evm the warning remains and .bss remains in the segment. I have a tiny clue. Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. If this BSS variable is used before relocation (I haven't checked this), then anyway it'll have to move; in that case I'll keep an eye on this linker warning and try to sort it out if I get time. I did explain yesterday that variable is not used in relocation. If you notice the code snippet I sent yesterday, I had removed every assignment to the variable. And 2009q1 was still not happy! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 02/12/2010 09:13, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf74fed.2030...@free.fr you wrote: BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2... ... plus it removes the linker warning! Oops. Why would this make a difference? Alignement issues, possibly, although we do align the location pointer before the overlay point -- or some bug in the linker. I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board. No, I don't think this is a good idea as it just papers over an existing problem. Oh--I did not mean to forget the linker warning thing. Just separate the issues, because I think this particular linker warning is unrelated with getting the board working. So Sanjeev would change the u8 to an int and proceed with board debug, and I would investigate this issue -- actually, try and find a minimal example that I could go to the binutils list with rather than a full-blown u-boot tree. Does it help when you change the *(.bss) in arch/arm/cpu/armv7/u-boot.lds into *(.*bss) (so it also includes any .sbss objects) ? No change. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip] So Sanjeev would change the u8 to an int and proceed with board debug, I will be away from desk for an hour. Will have the patch posted immediately after... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Hi Sanjeev, Le 02/12/2010 09:30, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip] So Sanjeev would change the u8 to an int and proceed with board debug, I will be away from desk for an hour. Will have the patch posted immediately after... Please let us know the current status of the board, i.e. whether it works or not, and if not, what the console output is. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear Albert ARIBAUD, In message 4cf7583c.7000...@free.fr you wrote: Does it help when you change the *(.bss) in arch/arm/cpu/armv7/u-boot.lds into *(.*bss) (so it also includes any .sbss objects) ? No change. Hm... Maybe it is indeed not a good idea to mix short objects with those requiring larger alignments - we might lose space at best, or case misaligned variables? Eventually it's better to explicitly write *(.bss*) *(.sbss*) as we have it in many PowerPC linker scripts (but I have to admit that I don't know if this is really needed - I don't see any .sbss anywhere in this build (I do see them in some objects for PowerPC). For example: PowerPC: - readelf -S common/dlmalloc.o | grep bss [ 3] .bss NOBITS 34 00 00 WA 0 0 1 [36] .bss.n_mmaps_max NOBITS 002728 04 00 WA 0 0 4 [37] .sbss.mem_malloc_ NOBITS 002728 04 00 WA 0 0 4 [38] .bss.max_total_me NOBITS 002728 04 00 WA 0 0 4 [40] .bss.max_sbrked_m NOBITS 00272c 04 00 WA 0 0 4 [43] .bss.top_pad NOBITS 002734 04 00 WA 0 0 4 [44] .sbss.mem_malloc_ NOBITS 002734 04 00 WA 0 0 4 [45] .sbss.mem_malloc_ NOBITS 002734 04 00 WA 0 0 4 [46] .bss.current_mall NOBITS 002734 28 00 WA 0 0 4 ARM: - readelf -S common/dlmalloc.o | grep bss [ 5] .bss NOBITS 0015e0 44 00 WA 0 0 4 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've got a bad feeling about this. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
Hi Sekhar, Hmm, I had tested DA850 EVM yesterday with U-Boot 2010.12-rc2, and was able to successfully boot (at least most of the times). ---logs Booting with TI UBL Device OPP (300MHz, 1.2V) U-Boot 2010.12-rc2 (Nov 30 2010 - 11:55:35) I2C: ready DRAM: 128 MiB Using default environment In:serial Out: serial Err: serial Net: Ethernet PHY: GENERIC @ 0x00 DA850-evm Some of the times, the boot hung after printing DRAM: 128 MiB, but never did it hang without printing anything. And what is the reason why it hung after printing the DRAM message? In effect you say that you also see a bug, so is it correct to assume that you're looking into it? Thanks Detlev -- Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. -- Antoine de Saint-Exupery -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ARM] [davinci] timer.c changes
I have changed the davinci timer code to work with the, originally at91 only, gd variables: unsigned long timer_rate_hz; unsigned long tbl; unsigned long tbu; unsigned long long timer_reset_value; It does use the timer_reset_value to keep compatibility with places where timers are not used correctly. I have tested it on da830evm and it my board now boots correctly. Has it been agreed on the way forward for these timer fixes? Is it worth me posting the patch? It does seem to me that there would be room for a common layer and a arch specific tbl/tbu emulation layer as suggested here: http://lists.denx.de/pipermail/u-boot/2010-November/081377.html but maybe it would be good to get more boards working prior to release and then look at how they can be made more common later? Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot networking not working
Hi! thanks for your quick replys. More helpful than the manufacturer thats for sure. I totally admit that im a newbie at all this, so sorry if I dont understand things. I was under the impression that the MAC address was supplied by the hardware supplier. (at least this seems to be the can in the PC world). Is this not the case in the embedded world? Cheers Mark Wolfgang Denk wrote: Dear Mark Underwood, In message1291273748.31320.3.ca...@bertha you wrote: I've got an sbc6000x from www.armkits.com. I've been working through how to put debian onto this board and was making some progress (im just a beginner), but now I dont have network access when at the U-boot prompt. The Board is connected to the network as the link light is on on the interface. As soon as I try to ping the board itself ie ping 192.192.192.200 (the default ip address) the link light goes out. this is from the command line Well, I guess you did not read the FAQ... U-Boot printenv bootcmd=nand read 0x2200 0x1A 0x20; bootm 0x2200 bootdelay=3 baudrate=115200 ethaddr=DE:AD:BE:EF:01:01 Ouch. See FAQ 14.2.13. Ethernet Does Not Work See also 14.2.14. Where Can I Get a Valid MAC Address from? Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot networking not working
Mark, Please do not write your answers above the text you answer to (i.e., do not top-post) Le 02/12/2010 10:48, Mark Underwood a écrit : Hi! thanks for your quick replys. More helpful than the manufacturer thats for sure. I totally admit that im a newbie at all this, so sorry if I dont understand things. No problem -- we all learn something new every day. :) I was under the impression that the MAC address was supplied by the hardware supplier. (at least this seems to be the can in the PC world). Is this not the case in the embedded world? Yes, it is; but while the supplier provides a unique MAC address for each MAC they send out, they don't necessarily burn it in the HW: it is often configurable. Here, the MAC is configured from a u-boot env variable; but obviously, the MAC address specified in your u-boot environment is not a valid one (I needed a second look and a step backward to read it as DEAD BEEF 01 01). I suggest looking for your MAC address on a sticker or marking on the board, or a printed leaflet, or on the box. Cheers Mark Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] [REPOST-2] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board specific code
for ex- following code configures MFPs 107 and 108 for UART_TX/RX functionality
int board_early_init_f(void)
{
u32 mfp_cfg[] = {
/* Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
mfp_config(mfp_cfg);
return 0;
}
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Please Ignore earlier patch, below bufix is added to this patch
Change log v3:
Fixed: Read-modify-Write a mfg register as per configuration
ANDed with MASK value before ORing for each configuration
REPOST-V1:
I am sorry for the repost-V1 :-(
MASK values changed to relevent (copy paste mistake)
Change log v3-repost-2
Soc specific pointer updation code is replaced by a macro
MFPR_PTR_UPDATE, will be put in asm/arch/mfp.c
Regards..
Prafulla . .
drivers/gpio/Makefile |1 +
drivers/gpio/mfp.c| 103 +
include/mfp.h | 97 ++
3 files changed, 201 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/mfp.c
create mode 100644 include/mfp.h
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 398024c..f6903d5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -27,6 +27,7 @@ LIB := $(obj)libgpio.o
COBJS-$(CONFIG_AT91_GPIO) += at91_gpio.o
COBJS-$(CONFIG_KIRKWOOD_GPIO) += kw_gpio.o
+COBJS-$(CONFIG_MFP)+= mfp.o
COBJS-$(CONFIG_MXC_GPIO) += mxc_gpio.o
COBJS-$(CONFIG_PCA953X)+= pca953x.o
COBJS-$(CONFIG_S5P)+= s5p_gpio.o
diff --git a/drivers/gpio/mfp.c b/drivers/gpio/mfp.c
new file mode 100644
index 000..db71a74
--- /dev/null
+++ b/drivers/gpio/mfp.c
@@ -0,0 +1,103 @@
+/*
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Written-by: Prafulla Wadaskar prafu...@marvell.com,
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include asm/io.h
+#include mfp.h
+#include asm/arch/mfp.h
+#ifdef CONFIG_ARMADA100
+#include asm/arch/armada100.h
+#define MFPR_BASE ARMD1_MFPR_BASE;
+#else
+#error Unsupported SoC...
+#endif
+
+/*
+ * mfp_config
+ *
+ * On most of Marvell SoCs (ex. ARMADA100) there is Multi-Funtion-Pin
+ * configuration registers to configure each GPIO/Function pin on the
+ * SoC.
+ *
+ * This function reads the array of values for
+ * MFPR_X registers and programms them into respective
+ * Multi-Function Pin registers.
+ * It supports - Alternate Function Selection programming.
+ *
+ * Whereas,
+ * The Configureation value is constructed using ARMD_MFP()
+ * array consists of 32bit values as-
+ * Bits 31-16 : Mfp instance number (i.e. MFPR no. to be programmed)
+ * Bits 15-13 : PULL_UP/PULL_DOWN selection
+ * Bits 11:10 : Pin Driver strength
+ * Bits 6-4: Edge detection configuration
+ * Bits 2-0: Alternate Function Selection
+ *
+ * For more details please refer respective Product Software Manual
+ */
+void mfp_config(u32 *mfp_cfgs)
+{
+ u32 *p_mfpr = NULL;
+ u32 val, cfg_val, mfpr_no;
+
+ do {
+ cfg_val = *mfp_cfgs++;
+ /* exit if End of configuration table detected */
+ if (cfg_val == MFP_EOC)
+ break;
+ /* abstract mfpr tobe programmed from configuration value */
+ mfpr_no = (cfg_val MFP_PINNO_MASK) 16;
+ BUG_ON(mfpr_no = MFP_PIN_MAX);
+
+ p_mfpr = (u32 *)MFPR_BASE;
+ MFPR_PTR_UPDATE(p_mfpr, mfpr_no);
+ /*p_mfpr contains address of register to be programmed */
+
+ /* Read-modify-Write a mfg register as per configuration */
+ val = readl(p_mfpr);
+ if (cfg_val MFP_CFG_AF) {
+ /* Abstract and program
[U-Boot] [PATCH v3 3/7] [REPOST] add Multi Function Pin configuration support for ARMADA100
This patch adds the support MFP support for Marvell ARMADA100 SoCs Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log v3 REPOST: macro MFPR_PTR_UPDATE added arch/arm/include/asm/arch-armada100/mfp.h | 231 + 1 files changed, 231 insertions(+), 0 deletions(-) create mode 100755 arch/arm/include/asm/arch-armada100/mfp.h diff --git a/arch/arm/include/asm/arch-armada100/mfp.h b/arch/arm/include/asm/arch-armada100/mfp.h new file mode 100755 index 000..f77055c --- /dev/null +++ b/arch/arm/include/asm/arch-armada100/mfp.h @@ -0,0 +1,231 @@ +/* + * Based on linux/arch/arm/mach-mpp/include/mfp-pxa168.h + * (C) Copyright 2007 + * Marvell Semiconductor www.marvell.com + * 2007-08-21: eric miao eric.m...@marvell.com + * + * (C) Copyright 2010 + * Marvell Semiconductor www.marvell.com + * Written-by: Prafulla Wadaskar prafu...@marvell.com + * Contributor: Mahavir Jain mj...@marvell.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#ifndef __ARMADA100_MFP_H +#define __ARMADA100_MFP_H + +/* + * On ARMADA100, (Ref: Specs: A1.1) + * the offset address are divided in three regions and are not + * consecutive, this macro updates the same + */ +#define MFPR_PTR_UPDATE(ptr, no) \ + if (no 37)\ + ptr += (0x004c / 4) + no; \ + else if ( no = 56) \ + ptr += (0x00e0 / 4) + (no - 56);\ + else\ + ptr += (no - 37); + +/* By default Pin Drive is set to medium */ +#define MFPD(x)MFP(x) | MFP_DRIVE(MEDIUM) + +/* GPIOs */ +#defineGPIOAF(x) (if (x = 15) ? 5 : \ +if (x == 16) ? 0 : \ +if (x == 17) ? 5 : \ +if (x == 18) ? 0 : \ +if (x == 19) ? 5 : \ +if (x == 20) ? 0 : \ +if (x = 25) ? 5 : \ +if (x == 26) ? 0 : \ +if (x == 33) ? 5 : 0) + +#define MFP_GPIO(x)MFPD(x) | MFP_AF(GPIOAF(x)) + +/* UART2 */ +#define MFP47_UART2_RXDMFPD(47) | MFP_AF(6) +#define MFP48_UART2_TXDMFPD(48) | MFP_AF(6) +#define MFP88_UART2_RXDMFPD(88) | MFP_AF(2) +#define MFP89_UART2_TXDMFPD(89) | MFP_AF(2) + +/* UART3 */ +#define GPIO8_UART3_RXD MFPD(8) | MFP_AF(2) +#define GPIO9_UART3_TXD MFPD(9) | MFP_AF(2) + +/* MFU */ +#define MFP86_TX_CLK MFPD(86) | MFP_AF(5) +#define MFP87_TX_ENMFPD(87) | MFP_AF(5) +#define MFP88_TX_DQ3 MFPD(88) | MFP_AF(5) +#define MFP89_TX_DQ2 MFPD(89) | MFP_AF(5) +#define MFP90_TX_DQ1 MFPD(90) | MFP_AF(5) +#define MFP91_TX_DQ0 MFPD(91) | MFP_AF(5) +#define MFP92_MII_CRS MFPD(92) | MFP_AF(5) +#define MFP93_MII_COL MFPD(93) | MFP_AF(5) +#define MFP94_RX_CLK MFPD(94) | MFP_AF(5) +#define MFP95_RX_ERMFPD(95) | MFP_AF(5) +#define MFP96_RX_DQ3 MFPD(96) | MFP_AF(5) +#define MFP97_RX_DQ2 MFPD(97) | MFP_AF(5) +#define MFP98_RX_DQ1 MFPD(98) | MFP_AF(5) +#define MFP99_RX_DQ0 MFPD(99) | MFP_AF(5) +#define MFP100_MII_MDC MFPD(100) | MFP_AF(5) +#define MFP101_MII_MDIOMFPD(101) | MFP_AF(5) +#define MFP103_RX_DV MFPD(103) | MFP_AF(5) + +/* SSP2*/ +#define MFP107_SPI_NOR_RXD MFPD(107) | MFP_AF(4) +#define MFP108_SPI_NOR_TXD MFPD(108) | MFP_AF(4) +#define MFP109_SPI_NOR_SYSCLK MFPD(109) | MFP_AF(4) +#define MFP111_SPI_NOR_CLK MFPD(111) | MFP_AF(4) + +/* DFI */ +#define MFP0_DFI_D15 MFPD(0) | MFP_AF(0) +#define MFP1_DFI_D14 MFPD(1) | MFP_AF(0) +#define MFP2_DFI_D13 MFPD(2) | MFP_AF(0) +#define MFP3_DFI_D12 MFPD(3) | MFP_AF(0) +#define MFP4_DFI_D11 MFPD(4) | MFP_AF(0) +#define MFP5_DFI_D10 MFPD(5) | MFP_AF(0) +#define MFP6_DFI_D9MFPD(6) | MFP_AF(0)
Re: [U-Boot] [PATCH v3 3/7] [REPOST] add Multi Function Pin configuration support for ARMADA100
Dear Prafulla Wadaskar, In message 1291302695-15561-2-git-send-email-prafu...@marvell.com you wrote: This patch adds the support MFP support for Marvell ARMADA100 SoCs Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log v3 REPOST: macro MFPR_PTR_UPDATE added arch/arm/include/asm/arch-armada100/mfp.h | 231 + 1 files changed, 231 insertions(+), 0 deletions(-) create mode 100755 arch/arm/include/asm/arch-armada100/mfp.h ... +/* GPIOs */ +#define GPIOAF(x) (if (x = 15) ? 5 : \ + if (x == 16) ? 0 : \ + if (x == 17) ? 5 : \ + if (x == 18) ? 0 : \ + if (x == 19) ? 5 : \ + if (x == 20) ? 0 : \ + if (x = 25) ? 5 : \ + if (x == 26) ? 0 : \ + if (x == 33) ? 5 : 0) Does this code actually compile? 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 To the systems programmer, users and applications serve only to provide a test load. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST] add Multi Function Pin configuration support for ARMADA100
Hi Prafulla, On Thu, Dec 2, 2010 at 11:11 PM, Prafulla Wadaskar prafu...@marvell.com wrote: This patch adds the support MFP support for Marvell ARMADA100 SoCs Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log v3 REPOST: macro MFPR_PTR_UPDATE added arch/arm/include/asm/arch-armada100/mfp.h | 231 + 1 files changed, 231 insertions(+), 0 deletions(-) create mode 100755 arch/arm/include/asm/arch-armada100/mfp.h diff --git a/arch/arm/include/asm/arch-armada100/mfp.h b/arch/arm/include/asm/arch-armada100/mfp.h new file mode 100755 index 000..f77055c --- /dev/null +++ b/arch/arm/include/asm/arch-armada100/mfp.h @@ -0,0 +1,231 @@ +/* + * Based on linux/arch/arm/mach-mpp/include/mfp-pxa168.h + * (C) Copyright 2007 + * Marvell Semiconductor www.marvell.com + * 2007-08-21: eric miao eric.m...@marvell.com + * + * (C) Copyright 2010 + * Marvell Semiconductor www.marvell.com + * Written-by: Prafulla Wadaskar prafu...@marvell.com + * Contributor: Mahavir Jain mj...@marvell.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA + */ + +#ifndef __ARMADA100_MFP_H +#define __ARMADA100_MFP_H + +/* + * On ARMADA100, (Ref: Specs: A1.1) + * the offset address are divided in three regions and are not + * consecutive, this macro updates the same + */ +#define MFPR_PTR_UPDATE(ptr, no) \ + if (no 37) \ + ptr += (0x004c / 4) + no; \ + else if ( no = 56) \ + ptr += (0x00e0 / 4) + (no - 56);\ + else \ + ptr += (no - 37); + +/* By default Pin Drive is set to medium */ +#define MFPD(x) MFP(x) | MFP_DRIVE(MEDIUM) + +/* GPIOs */ +#define GPIOAF(x) (if (x = 15) ? 5 : \ + if (x == 16) ? 0 : \ + if (x == 17) ? 5 : \ + if (x == 18) ? 0 : \ + if (x == 19) ? 5 : \ + if (x == 20) ? 0 : \ + if (x = 25) ? 5 : \ + if (x == 26) ? 0 : \ + if (x == 33) ? 5 : 0) + +#define MFP_GPIO(x) MFPD(x) | MFP_AF(GPIOAF(x)) + Do we really need this? I think the better way to configure GPIO MFP is doing like below. That is create each GPIO name, and define its MFPD and MFP_AF. +/* UART2 */ +#define MFP47_UART2_RXD MFPD(47) | MFP_AF(6) +#define MFP48_UART2_TXD MFPD(48) | MFP_AF(6) +#define MFP88_UART2_RXD MFPD(88) | MFP_AF(2) +#define MFP89_UART2_TXD MFPD(89) | MFP_AF(2) + +/* UART3 */ +#define GPIO8_UART3_RXD MFPD(8) | MFP_AF(2) +#define GPIO9_UART3_TXD MFPD(9) | MFP_AF(2) + +/* MFU */ +#define MFP86_TX_CLK MFPD(86) | MFP_AF(5) +#define MFP87_TX_EN MFPD(87) | MFP_AF(5) +#define MFP88_TX_DQ3 MFPD(88) | MFP_AF(5) +#define MFP89_TX_DQ2 MFPD(89) | MFP_AF(5) +#define MFP90_TX_DQ1 MFPD(90) | MFP_AF(5) +#define MFP91_TX_DQ0 MFPD(91) | MFP_AF(5) +#define MFP92_MII_CRS MFPD(92) | MFP_AF(5) +#define MFP93_MII_COL MFPD(93) | MFP_AF(5) +#define MFP94_RX_CLK MFPD(94) | MFP_AF(5) +#define MFP95_RX_ER MFPD(95) | MFP_AF(5) +#define MFP96_RX_DQ3 MFPD(96) | MFP_AF(5) +#define MFP97_RX_DQ2 MFPD(97) | MFP_AF(5) +#define MFP98_RX_DQ1 MFPD(98) | MFP_AF(5) +#define MFP99_RX_DQ0 MFPD(99) | MFP_AF(5) +#define MFP100_MII_MDC MFPD(100) | MFP_AF(5) +#define MFP101_MII_MDIO MFPD(101) | MFP_AF(5) +#define MFP103_RX_DV MFPD(103) | MFP_AF(5) + +/* SSP2*/ +#define MFP107_SPI_NOR_RXD MFPD(107) | MFP_AF(4) +#define MFP108_SPI_NOR_TXD MFPD(108) | MFP_AF(4) +#define MFP109_SPI_NOR_SYSCLK MFPD(109) | MFP_AF(4) +#define MFP111_SPI_NOR_CLK MFPD(111) | MFP_AF(4) + +/* DFI */
[U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
This patch does following changes:
* Change the type (u8 - int) for omap3_evm_version.
* Introduce an 'undefined' board revision for init
value.
* Use of #define instead of magic numbers
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 39 +++
board/ti/evm/evm.h | 17 +++--
2 files changed, 30 insertions(+), 26 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 09d14f7..8d9ce73 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -37,36 +37,43 @@
#include asm/mach-types.h
#include evm.h
-static u8 omap3_evm_version;
+static int omap3_evm_version = OMAP3EVM_BOARD_UNDEF;
-u8 get_omap3_evm_rev(void)
+int get_omap3_evm_rev(void)
{
return omap3_evm_version;
}
+/**
+ * The board revision can be ascertained only by identifying the
+ * Ethernet chipset used on the board.
+ *
+ * The revision can be read from ID_REV register on the PHY.
+ */
static void omap3_evm_get_revision(void)
{
-#if defined(CONFIG_CMD_NET)
- /*
-* Board revision can be ascertained only by identifying
-* the Ethernet chipset.
-*/
- unsigned int smsc_id;
+#define CONFIG_SMC911X_ID_REV (CONFIG_SMC911X_BASE + 0x50)
- /* Ethernet PHY ID is stored at ID_REV register */
- smsc_id = readl(CONFIG_SMC911X_BASE + 0x50) 0x;
- printf(Read back SMSC id 0x%x\n, smsc_id);
+#define SMSC_ID_9115 0x0115 /* SMSC9115 chipset */
+#define SMSC_ID_9220 0x9220 /* SMSC9220 chipset */
+
+#if defined(CONFIG_CMD_NET)
+ unsigned int smsc_id = readl(CONFIG_SMC911X_ID_REV) 0x;
switch (smsc_id) {
- /* SMSC9115 chipset */
- case 0x0115:
+ case SMSC_ID_9115:
omap3_evm_version = OMAP3EVM_BOARD_GEN_1;
break;
- /* SMSC 9220 chipset */
- case 0x9220:
+ case SMSC_ID_9220:
+ omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
+ break;
default:
+ printf (Unknown board revision.);
+ /*
+* Assume the latest revision
+*/
omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
- }
+ }
#else
#if defined(CONFIG_STATIC_BOARD_REV)
/*
diff --git a/board/ti/evm/evm.h b/board/ti/evm/evm.h
index a76deb8..de96504 100644
--- a/board/ti/evm/evm.h
+++ b/board/ti/evm/evm.h
@@ -34,18 +34,15 @@ const omap3_sysinfo sysinfo = {
};
/*
- * OMAP35x EVM revision
- * Run time detection of EVM revision is done by reading Ethernet
- * PHY ID -
- * GEN_1 = 0x0115
- * GEN_2 = 0x9220
+ * OMAP35x EVM Revision.
+ * The revision can be detected only based on Ethernet PHY ID.
*/
-enum {
- OMAP3EVM_BOARD_GEN_1 = 0, /* EVM Rev between A - D */
- OMAP3EVM_BOARD_GEN_2, /* EVM Rev = Rev E */
-};
+#define OMAP3EVM_BOARD_UNDEF -1 /* EVM revision not detected */
+
+#define OMAP3EVM_BOARD_GEN_1 1 /* EVM Rev between A - D*/
+#define OMAP3EVM_BOARD_GEN_2 2 /* EVM Rev = Rev E */
-u8 get_omap3_evm_rev(void);
+int get_omap3_evm_rev(void);
#if defined(CONFIG_CMD_NET)
static void setup_net_chip(void);
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST-2] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Dear Prafulla Wadaskar,
In message 1291302695-15561-1-git-send-email-prafu...@marvell.com you wrote:
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board specific code
for ex- following code configures MFPs 107 and 108 for UART_TX/RX
functionality
int board_early_init_f(void)
{
u32 mfp_cfg[] = {
/* Console on UART1 */
MFP107_UART1_RXD,
MFP108_UART1_TXD,
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
mfp_config(mfp_cfg);
return 0;
}
This smells as if it needs a ton of #defines in header files, covering
all possible pin configurations. Is there not a way to implemtn this
less expensively?
For example, check how such configurations are done in PowerPC land -
see for example the I/O configuration tables qe_iop_conf_tab[] in
board/freescale/mpc8360erdk/mpc8360erdk.c or in
board/freescale/mpc8568mds/mpc8568mds.c 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
Very ugly or very beautiful women should be flattered on their
understanding, and mediocre ones on their beauty.
-- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 2:12 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Hi Sanjeev, Le 02/12/2010 09:30, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip] So Sanjeev would change the u8 to an int and proceed with board debug, I will be away from desk for an hour. Will have the patch posted immediately after... Please let us know the current status of the board, i.e. whether it works or not, and if not, what the console output is. Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet. Also noticed a difference between the changes I made yesterday; and your mail - maintaining 'u8' vs. 'int' for the omap3_evm_revision. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST-1] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Dear Prafulla Wadaskar, In message f766e4f80769bd478052fb6533fa745d19a9291...@sc-vexch4.marvell.com you wrote: Since the mfp.c is for generic case, and should be made as generic at the beginning... Sure.. but I don't know how it will be on other SoCs? Apart from that what would be other impact? So in my opinion, let's keep it for future updates. No, this is the wrong approach. Already now you realize that this code does not reallys cale well with future extensions, because you put all the logic in your code. I think this is a bad approach here. Instead, make the whole thing data driven - implement only minimal code that waks through a table provided by the user. Instead of putting the logic in the code, try to put it in the data. With reference to your precise concern, I will create a macro in asm/arch/mfp.h moving below code there. + if ( mfpr_no 37) + p_mfpr += (0x004c / 4) + mfpr_no; + else if ( mfpr_no = 56) + p_mfpr += (0x00e0 / 4) + (mfpr_no - 56); + else + p_mfpr += (mfpr_no - 37) No, please don't. It's ugly, not readable and not maintainable. 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 You might not be as stupid as you look. This is not hard. Let's think about this. I mean ... I'll think about this, and you can join in when you know the words. - Terry Pratchett, _Men at Arms_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST] add Multi Function Pin configuration support for ARMADA100
Dear Lei Wen, In message aanlktimztfsml0bzbti+exrzjkg5jh9kxqzukevrc...@mail.gmail.com you wrote: Do we really need this? I think the better way to configure GPIO MFP is doing like below. That is create each GPIO name, and define its MFPD and MFP_AF. +/* UART2 */ +#define MFP47_UART2_RXDMFPD(47) | MFP_AF(6) +#define MFP48_UART2_TXDMFPD(48) | MFP_AF(6) +#define MFP88_UART2_RXDMFPD(88) | MFP_AF(2) ... No. This is exactly what I do not want to see. We will end up with zillions of #defines, and only a tiny percentage of them will ever be used. Please use plain simple tables instead. 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 If there are self-made purgatories, then we all have to live in them. -- Spock, This Side of Paradise, stardate 3417.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Dear Sanjeev Premi, In message 1291288812-12653-1-git-send-email-pr...@ti.com you wrote: This patch does following changes: * Change the type (u8 - int) for omap3_evm_version. * Introduce an 'undefined' board revision for init value. * Use of #define instead of magic numbers Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 39 +++ board/ti/evm/evm.h | 17 +++-- 2 files changed, 30 insertions(+), 26 deletions(-) diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c index 09d14f7..8d9ce73 100644 --- a/board/ti/evm/evm.c +++ b/board/ti/evm/evm.c @@ -37,36 +37,43 @@ #include asm/mach-types.h #include evm.h -static u8 omap3_evm_version; +static int omap3_evm_version = OMAP3EVM_BOARD_UNDEF; ... +#define OMAP3EVM_BOARD_UNDEF -1 /* EVM revision not detected */ Sorry, but I will not accept this patch. The only purpose of this initialization with a non-zero value is to paper over a problem. As a result, the problem will be left unsolved, so it bites us again elsewhere, and we increase the memory footprint of the U-Boot image without need. NAK. 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 You get a wonderful view from the point of no return. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247b9a...@dbde02.ent.ti.com you wrote: Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet. Could you ***please*** be a bit more precise? What EXACTLY was that sort related change? Do you still need to remove the $(sort) call for the LIBS? That should NOT be done. 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 You can't evaluate a man by logic alone. -- McCoy, I, Mudd, stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: make timer variables in gt_t available for all ARM platforms
On 01/12/10 12:16, Prafulla Wadaskar wrote:
After ARM relocation,
any code executed directly or indirectly by board_init_f() have
global (BSS) variables need to be fixed. mostly timer.c needs to
fix on most of the ARM platforms.
This patch makes timer related variables in gd_t available for
all ARM implementation
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
arch/arm/include/asm/global_data.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index ada3fbb..efb502e 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -55,7 +55,9 @@ typedef struct global_data {
unsigned long plla_rate_hz;
unsigned long pllb_rate_hz;
unsigned long at91_pllb_usb_init;
- /* static data needed by at91's timer.c */
+#endif
+#ifdef CONFIG_ARM
+ /* static data needed by most of timer.c on ARM platforms */
unsigned long timer_rate_hz;
unsigned long tbl;
unsigned long tbu;
This file is ARM specific. Doesn't this mean CONFIG_ARM is always defined here?
Regards,
Nick.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Le 02/12/2010 12:37, Wolfgang Denk a écrit : Dear Sanjeev Premi, In message1291288812-12653-1-git-send-email-pr...@ti.com you wrote: This patch does following changes: * Change the type (u8 - int) for omap3_evm_version. * Introduce an 'undefined' board revision for init value. * Use of #define instead of magic numbers Signed-off-by: Sanjeev Premipr...@ti.com --- board/ti/evm/evm.c | 39 +++ board/ti/evm/evm.h | 17 +++-- 2 files changed, 30 insertions(+), 26 deletions(-) diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c index 09d14f7..8d9ce73 100644 --- a/board/ti/evm/evm.c +++ b/board/ti/evm/evm.c @@ -37,36 +37,43 @@ #includeasm/mach-types.h #include evm.h -static u8 omap3_evm_version; +static int omap3_evm_version = OMAP3EVM_BOARD_UNDEF; ... +#define OMAP3EVM_BOARD_UNDEF-1 /* EVM revision not detected */ Sorry, but I will not accept this patch. The only purpose of this initialization with a non-zero value is to paper over a problem. As a result, the problem will be left unsolved, so it bites us again elsewhere, and we increase the memory footprint of the U-Boot image without need. NAK. Note that initialization should be unnecessary if the static variable is int rather than u8. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Dear Albert ARIBAUD, In message 4cf7896b.5090...@free.fr you wrote: Note that initialization should be unnecessary if the static variable is int rather than u8. It should ALWAYS be not necessary. Otherwise we have a bug, and that bug needs to be fixed rather than papered over. 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 Quantum Mechanics is God's version of Trust me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Le 02/12/2010 13:01, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf7896b.5090...@free.fr you wrote: Note that initialization should be unnecessary if the static variable is int rather than u8. It should ALWAYS be not necessary. I understand your point re: the linker warning, i.e. initializing should never be done to just get rid of a warning. Otherwise we have a bug, and that bug needs to be fixed rather than papered over. Yes, there is a bug whereby an u8 BSS variable causes a linker warning, and I believe this bug to be with the linker -- I'm working on getting a minimal example of it so that I could completely verify that the warning does not affect the semantics of the code generated. Now, on an unrelated note, omap3_emv's code arbitrarily uses an u8 where an int (or enum) would be more appropriate, and this should be changed not because it removes a linker warning, but because the u8 choice is arbitrary and at best as effective as using an int, at worst suboptimal to that. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 02, 2010 5:09 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247b9a...@dbde02.ent.ti.com you wrote: Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet. Could you ***please*** be a bit more precise? What EXACTLY was that sort related change? Do you still need to remove the $(sort) call for the LIBS? That should NOT be done. Wolfgang, I know it shouldn't be done - but just trying to take problem one by one. Unless you want me to report the problems onl after I have a fix for them - and not seek any help. ~sanjeev 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 You can't evaluate a man by logic alone. -- McCoy, I, Mudd, stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 02, 2010 5:07 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code. Dear Sanjeev Premi, In message 1291288812-12653-1-git-send-email-pr...@ti.com you wrote: This patch does following changes: * Change the type (u8 - int) for omap3_evm_version. * Introduce an 'undefined' board revision for init value. * Use of #define instead of magic numbers Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 39 +++ board/ti/evm/evm.h | 17 +++-- 2 files changed, 30 insertions(+), 26 deletions(-) diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c index 09d14f7..8d9ce73 100644 --- a/board/ti/evm/evm.c +++ b/board/ti/evm/evm.c @@ -37,36 +37,43 @@ #include asm/mach-types.h #include evm.h -static u8 omap3_evm_version; +static int omap3_evm_version = OMAP3EVM_BOARD_UNDEF; ... +#define OMAP3EVM_BOARD_UNDEF -1 /* EVM revision not detected */ Sorry, but I will not accept this patch. The only purpose of this initialization with a non-zero value is to paper over a problem. As a result, the problem will be left unsolved, so it bites us again elsewhere, and we increase the memory footprint of the U-Boot image without need. At least I haven't deserted the problem; but the patch will help some one to test beyond the basic boot and see if there is any other impact on the functionality. The board has been broken for many weeks. As we see problem with sort($LIBS); there could be more issues that are yet to be discovered. ~sanjeev NAK. 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 You get a wonderful view from the point of no return. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] [davinci] timer.c changes
Hi Nick, On Thu, Dec 2, 2010 at 4:39 AM, Nick Thompson nick.thomp...@ge.com wrote: I have changed the davinci timer code to work with the, originally at91 only, gd variables: unsigned long timer_rate_hz; unsigned long tbl; unsigned long tbu; unsigned long long timer_reset_value; It does use the timer_reset_value to keep compatibility with places where timers are not used correctly. I have tested it on da830evm and it my board now boots correctly. Has it been agreed on the way forward for these timer fixes? Is it worth me posting the patch? I am very interested in taking your patch for a test-drive. but maybe it would be good to get more boards working prior to release and then look at how they can be made more common later? +1 for that. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...)
Maybe in init sequens asm func, i used turn on led to check which func faild. -- View this message in context: http://old.nabble.com/-U-Boot--OMAP3%3A-relocation-and-bss-usage-%28timer%2C-gpmc%2C-...%29-tp30341173p30358424.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
The code is based on that used in the at91 timers, modified to use
a davinci specific hardware timer. It also maintains reset_timer()
to allow deprecated timer usage to continue to work (for example,
in nand_base.c)
Signed-off-by: Nick Thompson nick.thomp...@ge.com
---
This patch relies on http://patchwork.ozlabs.org/patch/73758/ which has not been
accepted yet. I have made a comment on it, suggesting that it should be changed:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90040/focus=90162
arch/arm/cpu/arm926ejs/davinci/timer.c | 77
1 files changed, 28 insertions(+), 49 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/timer.c
b/arch/arm/cpu/arm926ejs/davinci/timer.c
index 9da7443..bfc6b40 100644
--- a/arch/arm/cpu/arm926ejs/davinci/timer.c
+++ b/arch/arm/cpu/arm926ejs/davinci/timer.c
@@ -40,6 +40,8 @@
#include common.h
#include asm/io.h
+DECLARE_GLOBAL_DATA_PTR;
+
struct davinci_timer {
u_int32_t pid12;
u_int32_t emumgt;
@@ -57,11 +59,9 @@ struct davinci_timer {
static struct davinci_timer * const timer =
(struct davinci_timer *)CONFIG_SYS_TIMERBASE;
-#define TIMER_LOAD_VAL (CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ)
-#define TIM_CLK_DIV16
+#define TIMER_LOAD_VAL 0x
-static ulong timestamp;
-static ulong lastinc;
+#define TIM_CLK_DIV16
int timer_init(void)
{
@@ -71,72 +71,51 @@ int timer_init(void)
writel(0x06 | ((TIM_CLK_DIV - 1) 8), timer-tgcr);
writel(0x0, timer-tim34);
writel(TIMER_LOAD_VAL, timer-prd34);
- lastinc = 0;
- timestamp = 0;
writel(2 22, timer-tcr);
+ gd-timer_rate_hz = CONFIG_SYS_HZ_CLOCK / TIM_CLK_DIV;
+ gd-timer_reset_value = 0;
return(0);
}
void reset_timer(void)
{
- writel(0x0, timer-tcr);
- writel(0x0, timer-tim34);
- lastinc = 0;
- timestamp = 0;
- writel(2 22, timer-tcr);
+ gd-timer_reset_value = get_ticks();
}
-static ulong get_timer_raw(void)
+/*
+ * Get the current 64 bit timer tick count
+ */
+unsigned long long get_ticks(void)
{
- ulong now = readl(timer-tim34);
-
- if (now = lastinc) {
- /* normal mode */
- timestamp += now - lastinc;
- } else {
- /* overflow ... */
- timestamp += now + TIMER_LOAD_VAL - lastinc;
- }
- lastinc = now;
- return timestamp;
+ unsigned long now = readl(timer-tim34);
+
+ /* increment tbu if tbl has rolled over */
+ if (now gd-tbl)
+ gd-tbu++;
+ gd-tbl = now;
+
+ return (((unsigned long long)gd-tbu) 32) | gd-tbl;
}
ulong get_timer(ulong base)
{
- return((get_timer_raw() / (TIMER_LOAD_VAL / TIM_CLK_DIV)) - base);
-}
+ unsigned long long timer_diff;
-void set_timer(ulong t)
-{
- timestamp = t;
+ timer_diff = get_ticks() - gd-timer_reset_value;
+
+ return (timer_diff / (gd-timer_rate_hz / CONFIG_SYS_HZ)) - base;
}
void __udelay(unsigned long usec)
{
- ulong tmo;
- ulong endtime;
- signed long diff;
-
- tmo = CONFIG_SYS_HZ_CLOCK / 1000;
- tmo *= usec;
- tmo /= (1000 * TIM_CLK_DIV);
-
- endtime = get_timer_raw() + tmo;
+ unsigned long long endtime;
- do {
- ulong now = get_timer_raw();
- diff = endtime - now;
- } while (diff = 0);
-}
+ endtime = ((unsigned long long )usec * gd-timer_rate_hz) / 100UL;
+ endtime += get_ticks();
-/*
- * This function is derived from PowerPC code (read timebase as long long).
- * On ARM it just returns the timer value.
- */
-unsigned long long get_ticks(void)
-{
- return(get_timer(0));
+ while (get_ticks() endtime)
+ ;
}
/*
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Dear Albert ARIBAUD, In message 4cf7922b.3020...@free.fr you wrote: Now, on an unrelated note, omap3_emv's code arbitrarily uses an u8 where an int (or enum) would be more appropriate, and this should be changed not because it removes a linker warning, but because the u8 choice is arbitrary and at best as effective as using an int, at worst suboptimal to that. Well, an u8 is as good a data type as any other. The available range of 0...255 seems more than sufficient to store the needed information, so why should I waste 4 bytes of storage when a single byte is sufficient as well? 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 You know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247b9a...@dbde02.ent.ti.com you wrote: Do you still need to remove the $(sort) call for the LIBS? That should NOT be done. ... I know it shouldn't be done - but just trying to take problem one by one. Unless you want me to report the problems onl after I have a fix for them - and not seek any help. Well, the thing is that I am not convinced that these are really two separate issues. Both seem to have somethign to do with what the linker is doing. 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 No question is too silly to ask. Of course, some questions are too silly to to answer... - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ubifs.c: BUG: Error following links
The link_name variable is declared inside the if block and it is used
outside it through the name pointer.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
---
fs/ubifs/ubifs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 0f8128c..2bad027 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -386,6 +386,7 @@ static unsigned long ubifs_findfile(struct super_block *sb,
char *filename)
unsigned long root_inum = 1;
unsigned long inum;
int symlink_count = 0; /* Don't allow symlink recursion */
+ char link_name[64];
strcpy(fpath, filename);
@@ -422,7 +423,6 @@ static unsigned long ubifs_findfile(struct super_block *sb,
char *filename)
ui = ubifs_inode(inode);
if ((inode-i_mode S_IFMT) == S_IFLNK) {
- char link_name[64];
char buf[128];
/* We have some sort of symlink recursion, bail out */
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
Hi Nick,
On Thu, Dec 2, 2010 at 8:57 AM, Nick Thompson nick.thomp...@ge.com wrote:
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
The code is based on that used in the at91 timers, modified to use
a davinci specific hardware timer. It also maintains reset_timer()
to allow deprecated timer usage to continue to work (for example,
in nand_base.c)
Signed-off-by: Nick Thompson nick.thomp...@ge.com
---
This patch relies on http://patchwork.ozlabs.org/patch/73758/ which has not
been
accepted yet. I have made a comment on it, suggesting that it should be
changed:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90040/focus=90162
arch/arm/cpu/arm926ejs/davinci/timer.c | 77
1 files changed, 28 insertions(+), 49 deletions(-)
Applies cleanly to v2010.12-rc2 on top of
http://patchwork.ozlabs.org/patch/73758/
Tested on da850evm w/o any config changes. This fixes the freeze on
boot: 10/10 times.
You're awesome, Nick!
Tested-by: Ben Gardiner bengardi...@nanometrics.ca
diff --git a/arch/arm/cpu/arm926ejs/davinci/timer.c
b/arch/arm/cpu/arm926ejs/davinci/timer.c
[...]
void __udelay(unsigned long usec)
{
- ulong tmo;
- ulong endtime;
- signed long diff;
-
- tmo = CONFIG_SYS_HZ_CLOCK / 1000;
- tmo *= usec;
- tmo /= (1000 * TIM_CLK_DIV);
-
- endtime = get_timer_raw() + tmo;
+ unsigned long long endtime;
- do {
- ulong now = get_timer_raw();
- diff = endtime - now;
- } while (diff = 0);
-}
+ endtime = ((unsigned long long )usec * gd-timer_rate_hz) / 100UL;
just one minor checkpatch.pl warning; should be (unsigned long long)
-- no space before ')'
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] davinci: Rewrite timer.c to use tbl/tbu emulation variables in gd
On 02/12/10 14:18, Ben Gardiner wrote: Hi Nick, On Thu, Dec 2, 2010 at 8:57 AM, Nick Thompson nick.thomp...@ge.com wrote: This change allows the davinci timer functions to be used before relocation since it avoids using static variables prior to BSS being made available. Signed-off-by: Nick Thompson nick.thomp...@ge.com --- This patch relies on http://patchwork.ozlabs.org/patch/73758/ which has not been accepted yet. I have made a comment on it, suggesting that it should be changed: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90040/focus=90162 Applies cleanly to v2010.12-rc2 on top of http://patchwork.ozlabs.org/patch/73758/ Tested on da850evm w/o any config changes. This fixes the freeze on boot: 10/10 times. You're awesome, Nick! Tested-by: Ben Gardiner bengardi...@nanometrics.ca I thought it sounded like the problem you where having. Glad it helps. Thanks for the Tested-by. + endtime = ((unsigned long long )usec * gd-timer_rate_hz) / 100UL; just one minor checkpatch.pl warning; should be (unsigned long long) -- no space before ')' Good spot. I've fixed that locally and will submit a v2 if the depending patch finds favour - Alternative approaches have been suggested, this one is *my* short-term favourite. Thanks, Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] onenand: fix oob print out issue
Seems original implementation forget to set the pointer to point
to the oobbuf, so when we want to see oob buf, we see nothing...
Fix it by get pointer as the oobbuf set.
Signed-off-by: Lei Wen lei...@marvell.com
---
common/cmd_onenand.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
index 33108f1..6d77495 100644
--- a/common/cmd_onenand.c
+++ b/common/cmd_onenand.c
@@ -319,6 +319,8 @@ static int onenand_dump(struct mtd_info *mtd, ulong off,
int only_oob)
}
puts(OOB:\n);
i = mtd-oobsize 3;
+ p = oobbuf;
+
while (i--) {
printf(\t%02x %02x %02x %02x %02x %02x %02x %02x\n,
p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7]);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...)
Am 02.12.2010 14:33, schrieb zfsdk: Maybe in init sequens asm func, i used turn on led to check which func faild. Using a LED for debugging is time consuming. And you won't see which code still uses BSS before relocation as such code does not have to fail (it still might work). I prefer reading source. Using JTAG should help too, but I think, using JTAG and a debugger might got somewhat harder, at least after the code got relocated. Anyway, a JTAG-debugger could help a lot searching the stuff which currently goes wrong before relocation. I assume single stepping the few dozen lines which are executed before relocation could be done in a few hours and it should reveal most of the code which accesses BSS before relocation. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] onenand: add yaffs write command
Yaffs image require to use the oob to store some info, so when we
burn the yaffs image, we need to also write the image's oob part
into flash.
This patch add addition suffix to onenand write to give the uboot
the power to directly burn the yaffs image to onenand.
Signed-off-by: Lei Wen lei...@marvell.com
---
common/cmd_onenand.c | 41 -
1 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
index 6d77495..6a22b8a 100644
--- a/common/cmd_onenand.c
+++ b/common/cmd_onenand.c
@@ -112,8 +112,32 @@ static int onenand_block_read(loff_t from, size_t len,
return 0;
}
+static int onenand_write_oneblock_withoob(loff_t to, const u_char * buf,
+ size_t *retlen)
+{
+ struct mtd_oob_ops ops = {
+ .len = mtd-writesize,
+ .ooblen = mtd-oobsize,
+ .mode = MTD_OOB_AUTO,
+ };
+ int page, ret = 0;
+ for (page = 0; page (mtd-erasesize / mtd-writesize); page ++) {
+ ops.datbuf = (u_char *)buf;
+ buf += mtd-writesize;
+ ops.oobbuf = (u_char *)buf;
+ buf += mtd-oobsize;
+ ret = mtd-write_oob(mtd, to, ops);
+ if (ret)
+ break;
+ to += mtd-writesize;
+ }
+
+ *retlen = (ret) ? 0 : mtd-erasesize;
+ return ret;
+}
+
static int onenand_block_write(loff_t to, size_t len,
- size_t *retlen, const u_char * buf)
+ size_t *retlen, const u_char * buf, int withoob)
{
struct onenand_chip *this = mtd-priv;
int blocks = len this-erase_shift;
@@ -140,7 +164,10 @@ static int onenand_block_write(loff_t to, size_t len,
goto next;
}
- ret = mtd-write(mtd, ofs, blocksize, _retlen, buf);
+ if (!withoob)
+ ret = mtd-write(mtd, ofs, blocksize, _retlen, buf);
+ else
+ ret = onenand_write_oneblock_withoob(ofs, buf,
_retlen);
if (ret) {
printk(Write failed 0x%x, %d, (u32)ofs, ret);
skip_ofs += blocksize;
@@ -386,19 +413,22 @@ static int do_onenand_write(cmd_tbl_t * cmdtp, int flag,
int argc, char * const
{
ulong addr, ofs;
size_t len;
- int ret = 0;
+ int ret = 0, withoob = 0;
size_t retlen = 0;
if (argc 3)
return cmd_usage(cmdtp);
+ if (strncmp(argv[0] + 6, yaffs, 5) == 0)
+ withoob = 1;
+
addr = (ulong)simple_strtoul(argv[1], NULL, 16);
printf(\nOneNAND write: );
if (arg_off_size(argc - 2, argv + 2, ofs, len) != 0)
return 1;
- ret = onenand_block_write(ofs, len, retlen, (u8 *)addr);
+ ret = onenand_block_write(ofs, len, retlen, (u8 *)addr, withoob);
printf( %d bytes written: %s\n, retlen, ret ? ERROR : OK);
@@ -521,6 +551,7 @@ static cmd_tbl_t cmd_onenand_sub[] = {
U_BOOT_CMD_MKENT(bad, 1, 0, do_onenand_bad, , ),
U_BOOT_CMD_MKENT(read, 4, 0, do_onenand_read, , ),
U_BOOT_CMD_MKENT(write, 4, 0, do_onenand_write, , ),
+ U_BOOT_CMD_MKENT(write.yaffs, 4, 0, do_onenand_write, , ),
U_BOOT_CMD_MKENT(erase, 3, 0, do_onenand_erase, , ),
U_BOOT_CMD_MKENT(test, 3, 0, do_onenand_test, , ),
U_BOOT_CMD_MKENT(dump, 2, 0, do_onenand_dump, , ),
@@ -560,7 +591,7 @@ U_BOOT_CMD(
info - show available OneNAND devices\n
onenand bad - show bad blocks\n
onenand read[.oob] addr off size\n
- onenand write addr off size\n
+ onenand write[.yaffs] addr off size\n
read/write 'size' bytes starting at offset 'off'\n
to/from memory address 'addr', skipping bad blocks.\n
onenand erase [force] [off size] - erase 'size' bytes from\n
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v2] UBIFS: Change ubifsload to not read beyond the requested size
Hi Wolfgang, sorry for the late reply. I just stumbled again over this mail. On Monday 01 November 2010 20:05:00 Wolfgang Denk wrote: I still wonder what's the logic behind this code. When will read_block() return -ENOENT (aka No such file or directory) ? What are the other possible error conditions, and why would it make sense to continue reading after these other errors? As it seems, ENOENT is used to mark a hole in the file system. Meaning space that will be filled with zeros but does not occupy space (other than in the index). So we should keep the existing logic intact. 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
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Le 02/12/2010 14:58, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf7922b.3020...@free.fr you wrote: Now, on an unrelated note, omap3_emv's code arbitrarily uses an u8 where an int (or enum) would be more appropriate, and this should be changed not because it removes a linker warning, but because the u8 choice is arbitrary and at best as effective as using an int, at worst suboptimal to that. Well, an u8 is as good a data type as any other. The available range of 0...255 seems more than sufficient to store the needed information, so why should I waste 4 bytes of storage when a single byte is sufficient as well? You don't necessarily use only one byte when declaring an u8 instead of an int, because the next declaration may have alignment requirements that will cause the compiler to skip bytes after the u8. Besides, u8 is not as good a data type as any other, it is a specific data type whereas 'int' is the native data type of the platform, supposed to be the most natural to deal with for the cpu -- 32-bit for an ARM. u8 are perfect and normal, for instance, as fields of a structure which represents byte registers, or to perform 8-bit arithmetic. Here, however, there is indeed no reason to use any specific type, so we should use the cpu's native type. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb_ether: register usb ethernet gadget at each eth init
Hi Lei, Lei Wen wrote: Since the ether may not be the only one usb gadget would be used in the uboot, it is neccessary to do the register each time the eth begin to work to make usb gadget driver less confussed when we want to use two different usb gadget at the same time. Usb gadget driver could simple ignore the register operation, if it find the driver has been registered already. Signed-off-by: Lei Wen lei...@marvell.com Tested, works fine on my board. BTW, for future reference the tags in the subject should be [U-Boot] [PATCH v2]. v2 points to that this is an improved/fixed version of a patch previously submitted. This can be reached using --subject-prefix=U-Boot] [PATCH v2 passed to git format-patch command. Best regards, Vitaly. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tsec: Revert to setting TBICR_ANEG_ENABLE by default for SGMII
Hi Kumar, Signed-off-by: Kumar Gala ga...@kernel.crashing.org Acked-by: Peter Tyser pty...@xes-inc.com Tested-by: Peter Tyser pty...@xes-inc.com snip index e0a1fa4..9d87eaf 100644 --- a/include/configs/xpedite537x.h +++ b/include/configs/xpedite537x.h @@ -375,6 +375,12 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #define CONFIG_MII_DEFAULT_TSEC 1 /* Allow unregistered phys */ #define CONFIG_ETHPRIME eTSEC2 Would you mind adding a comment along the lines of the following to xpedite537x.h and xpedite550x.h above the CONFIG_TSEC_TBICR_SETTINGS define?: /* * In-band SGMII auto-negotiation between TBI and BCM5482S PHY fails, force * 1000mbps SGMII link */ +#define CONFIG_TSEC_TBICR_SETTINGS ( \ + TBICR_PHY_RESET \ + | TBICR_FULL_DUPLEX \ + | TBICR_SPEED1_SET \ + ) + Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fsl_upm: Add MxMR/MDR synchronization
From: John Schmoller jschmol...@xes-inc.com
According to Freescale reference manuals (eg section 13.4.4.2
Programming the UPMs of the P4080 Reference Manual):
Since the result of any update to the MxMR/MDR register must be in
effect before the dummy read or write to the UPM region, a write to
MxMR/MDR should be followed immediately by a read of MxMR/MDR.
The UPM on a custom P4080-based board did not work without performing
a read of MxMR/MDR after a write.
Signed-off-by: John Schmoller jschmol...@xes-inc.com
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
drivers/mtd/nand/fsl_upm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index b76c673..be00555 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -21,6 +21,7 @@
static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
{
clrsetbits_be32(upm-mxmr, MxMR_MAD_MSK, MxMR_OP_RUNP | pat_offset);
+ (void)in_be32(upm-mxmr);
}
static void fsl_upm_end_pattern(struct fsl_upm *upm)
@@ -35,6 +36,7 @@ static void fsl_upm_run_pattern(struct fsl_upm *upm, int
width,
void __iomem *io_addr, u32 mar)
{
out_be32(upm-mar, mar);
+ (void)in_be32(upm-mar);
switch (width) {
case 8:
out_8(io_addr, 0x0);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
Scott Wood wrote: If you were to immediately follow it with out_8 as currently defined, yes. But setbits_8 should be OK. I don't want my flash_writeX functions to make any assumptions about what set_mux_to_diu() does. Can I just replace the __raw_readb() with an in_8()? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
On Tue, Nov 30, 2010 at 8:00 AM, Wolfgang Denk w...@denx.de wrote: Hello everybody. I apologise for being a bit late with this announcement: * U-Boot v2010.12-rc2 was released on Sunday, November 28. * Release v2010.12 is (still) scheduled in 13 days: on December 13, 2010. Please help testing, and check if all your relevant patches have been included. I have verified ca9x4_ct_vxp builds cleanly if the following patches are applied: ARMV7: Vexpress build errors http://lists.denx.de/pipermail/u-boot/2010-November/081033.html ARMV7: Vexpress compile warnings http://lists.denx.de/pipermail/u-boot/2010-November/081034.html ARMV7:ca9x4_ct_vxp: udelay reference fix http://patchwork.ozlabs.org/patch/73478/ John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Dear Albert ARIBAUD, In message 4cf7c7f4.6030...@free.fr you wrote: Well, an u8 is as good a data type as any other. The available range of 0...255 seems more than sufficient to store the needed information, so why should I waste 4 bytes of storage when a single byte is sufficient as well? You don't necessarily use only one byte when declaring an u8 instead of an int, because the next declaration may have alignment requirements that will cause the compiler to skip bytes after the u8. Besides, u8 is The compiler / linker may (or may not) optimize this and collect variables of similar alignment. An int foo; is likely to end in .bss segment, while an char foo; will probably show up in .sbss - I don;t know how good or bad the current situation for ARM is, but I'm sure it is improving (look for example at all the microoptimizations done by Linaro). not as good a data type as any other, it is a specific data type whereas 'int' is the native data type of the platform, supposed to be the most natural to deal with for the cpu -- 32-bit for an ARM. Can an ARM CPU not read1s and write single bytes, too? u8 are perfect and normal, for instance, as fields of a structure which represents byte registers, or to perform 8-bit arithmetic. Here, however, there is indeed no reason to use any specific type, so we should use the cpu's native type. I do not share your opinion. But this is a pretty academic topic, and I'm neither in the mood nor do I have the time for lengthy discussions. Let's stop this here. 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 Cigarette, n.: A fire at one end, a fool at the other, and a bit of tobacco in between. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm920t/at91/reset: board_reset: define weak symbol
Am 30.11.2010 20:45, schrieb Andreas Bießmann: From: Andreas Bießmann biessm...@corscience.de Signed-off-by: Andreas Bießmann biessm...@corscience.de --- I can confirm this patch. It works with eb+cpux9k2 board. regard Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
Le 02/12/2010 19:51, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf7c7f4.6030...@free.fr you wrote: Well, an u8 is as good a data type as any other. The available range of 0...255 seems more than sufficient to store the needed information, so why should I waste 4 bytes of storage when a single byte is sufficient as well? You don't necessarily use only one byte when declaring an u8 instead of an int, because the next declaration may have alignment requirements that will cause the compiler to skip bytes after the u8. Besides, u8 is The compiler / linker may (or may not) optimize this and collect variables of similar alignment. An int foo; is likely to end in .bss segment, while an char foo; will probably show up in .sbss - I don;t know how good or bad the current situation for ARM is, but I'm sure it is improving (look for example at all the microoptimizations done by Linaro). There is only a single .bss for ARM. not as good a data type as any other, it is a specific data type whereas 'int' is the native data type of the platform, supposed to be the most natural to deal with for the cpu -- 32-bit for an ARM. Can an ARM CPU not read1s and write single bytes, too? It can, but for many of its operations, it can only work with 32-bit data. Let's stop this here. Understood. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] Vexpress build errors
From: Matt Waddel matt.wad...@linaro.org
This patch fixes build errors in the vexpress system:
- Removed sys_proto.h requirement from syslib.c.
- Switched vexpress to the default armv7 linker script.
- Renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE.
Signed-off-by: Matt Waddel matt.wad...@linaro.org
---
Change log v2:
Removed the new arch/arm/include/asm/arch-armv7/sys_proto.h file.
arch/arm/cpu/armv7/syslib.c |1 -
board/armltd/vexpress/config.mk |3 +-
board/armltd/vexpress/u-boot.lds | 65 --
3 files changed, 1 insertions(+), 68 deletions(-)
delete mode 100644 board/armltd/vexpress/u-boot.lds
diff --git a/arch/arm/cpu/armv7/syslib.c b/arch/arm/cpu/armv7/syslib.c
index f9ed9a3..84d17f0 100644
--- a/arch/arm/cpu/armv7/syslib.c
+++ b/arch/arm/cpu/armv7/syslib.c
@@ -23,7 +23,6 @@
#include common.h
#include asm/io.h
-#include asm/arch/sys_proto.h
/
* sdelay() - simple spin loop. Will be constant time as
diff --git a/board/armltd/vexpress/config.mk b/board/armltd/vexpress/config.mk
index 2d797d7..36395f2 100644
--- a/board/armltd/vexpress/config.mk
+++ b/board/armltd/vexpress/config.mk
@@ -19,5 +19,4 @@
#
# Linux-Kernel is expected to be at 0x60008000
#
-TEXT_BASE = 0x6080
-LDSCRIPT := $(SRCTREE)/board/armltd/vexpress/u-boot.lds
+CONFIG_SYS_TEXT_BASE = 0x6080
diff --git a/board/armltd/vexpress/u-boot.lds b/board/armltd/vexpress/u-boot.lds
deleted file mode 100644
index 5ac62f2..000
--- a/board/armltd/vexpress/u-boot.lds
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * (C) Copyright 2002
- * Gary Jennejohn, DENX Software Engineering, g...@denx.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
-OUTPUT_ARCH(arm)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
- . = ALIGN(4);
- .text :
- {
- arch/arm/cpu/armv7/start.o (.text)
- *(.text)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata))) }
-
- . = ALIGN(4);
- .data : { *(.data)
- __datarel_start = .;
- *(.data.rel)
- __datarelrolocal_start = .;
- *(.data.rel.ro.local)
- __datarellocal_start = .;
- *(.data.rel.local)
- __datarelro_start = .;
- *(.data.rel.ro)
- }
-
- __got_start = .;
- . = ALIGN(4);
- .got : { *(.got) }
- __got_end = .;
-
- . = .;
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
-
- . = ALIGN(4);
- __bss_start = .;
- .bss : { *(.bss) }
- _end = .;
-}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
Hi Wolfgang, On 12/02/2010 11:13 AM, John Rigby wrote: On Tue, Nov 30, 2010 at 8:00 AM, Wolfgang Denk w...@denx.de wrote: Hello everybody. I apologise for being a bit late with this announcement: * U-Boot v2010.12-rc2 was released on Sunday, November 28. * Release v2010.12 is (still) scheduled in 13 days: on December 13, 2010. Please help testing, and check if all your relevant patches have been included. I have verified ca9x4_ct_vxp builds cleanly if the following patches are applied: ARMV7: Vexpress build errors http://lists.denx.de/pipermail/u-boot/2010-November/081033.html I found that you had NAKed a patch similar to this one a few weeks ago. So I redid this patch and submitted a new one this morning: http://lists.denx.de/pipermail/u-boot/2010-December/082984.html This one removes the #include sys_proto.h. The other 2 patches John listed below should still be valid for this platform. Thanks, Matt ARMV7: Vexpress compile warnings http://lists.denx.de/pipermail/u-boot/2010-November/081034.html ARMV7:ca9x4_ct_vxp: udelay reference fix http://patchwork.ozlabs.org/patch/73478/ John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: S3C64XX: add support for mini6410
Hi Albert, On 12/01/2010 08:42 AM, Albert ARIBAUD wrote: Hi Darius, Le 30/11/2010 10:19, Darius Augulis a écrit : I understand, that there is such rule in u-boot, but it's ... at least strange. Even linux kernel doesn't use such approach and uses simple defines instead. One big disadvantage for already existing platforms - one must convert all defines to C structure. These rules apply to new code; existing code can just remain the same, precisely to avoid rewrites. Remove almost everything from header file, because no need to have duplicated code. ? And what about code porting between linux kernel and u-boot? With definitions in header file it's easy copy paste procedure. There are exceptions for code ported from Linux, IIRC. What if I need two registers separated with big gap from one big 100 register bank? Then I need to build huge C structure with many dummy variables. That's only one dummy variable, an array of 100 elements. Plus it *shows* there is a gap, which when dealing with datasheets is a plus. Lot of lines... In this case, possibility to make a dummy error is bigger. IMHO C structure for register definition is not better than definitions in header file. It's worse. We could have much tiny, simply and more readable code with definition in header file. And this approach has been used for years and still used in linux kernel. Perhaps, not without reason... One of the interests of C structs is that they guarantee against errors in typing register offsets, for instance. really? All is fine until there are no lot of gaps between registers. For example - s3c6410 gpio register bank has lot of random gaps. Size of gaps vary from 8 to 1744 bytes randomly. I tried to make such structure, but I gave up calculating(!) how many dummy variables I have to put in particular gap. Also gpio port registers are mixed with other special registers, port alphabetical order do not fit offset order, etc... There is 1000x times bigger possibility to do an error. Because most datasheets provide simple table of register names and offsets near them. You must be almost blind to make error during this simple copy paste procedure from pdf to C file. And I got crazy and spend 2 hours trying to build one single structure for gpio registers. It's absolutely stupid. And it's only gpio - what about other xx SoC modules? I've ported fb driver in shorter time than I wasted for this worthless work. I think u-boot maintainers make big mistake with this rule. I'm afraid I will stop my work adding mini6410 and other boards to mainline, because I don't have time for such games with C structures for SoC registers. You suggest to spend lot of hours in such place, where it's enough 2 minutes. I need to write few registers, but instead of defining them (few lines of code) I must calculate, and build entire structure with hundreds of registers... Sorry, I wont do this. Perhaps this and similar strict rules, especially those which do not add any improvement, forces lot of people to have their own modified copies of u-boot. You lose community... regards, Darius If u-boot maintainers are really going not accept this patch because of this, I will change it. But it's meaningless and very annoying. Please bear with it, just like we all bear with e.g. coding style rules from checkpatch.pl even though we would personally do it another way. thanks, Darius Amicalement, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/8xxx: Fix _POST_WORD_ADDR on 85xx 86xx systems
Hi Kumar, #elif defined (CONFIG_MPC85xx) #include asm/immap_85xx.h -#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr)) +#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_PIC_OFFSET + \ + offsetof(ccsr_pic_t, tfrr)) #elif defined (CONFIG_MPC86xx) #include asm/immap_86xx.h -#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr)) +#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + CONFIG_SYS_MPC86xx_PIC_OFFSET + \ + offsetof(ccsr_pic_t, tfrr)) #elif defined (CONFIG_4xx) #define _POST_WORD_ADDR \ John Schmoller just submitted the same patch internally, but used CONFIG_SYS_MPC8xxx_PIC_ADDR instead of (IMMR + OFFSET). Its a bit cleaner, and allows combining the 85xx and 86xx case. common.h should already include asm/immap8[56]xx.h. Best, Peter diff --git a/include/post.h b/include/post.h index 957ce3b..15a20c1 100644 --- a/include/post.h +++ b/include/post.h @@ -56,14 +56,8 @@ #include asm/immap_qe.h #define _POST_WORD_ADDR(CONFIG_SYS_IMMR + CPM_POST_WORD_ADDR) -#elif defined (CONFIG_MPC85xx) -#include asm/immap_85xx.h -#define _POST_WORD_ADDR(CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr)) - -#elif defined (CONFIG_MPC86xx) -#include asm/immap_86xx.h -#define _POST_WORD_ADDR(CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr)) - +#elif defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) +#define _POST_WORD_ADDR(CONFIG_SYS_MPC8xxx_PIC_ADDR + offsetof(ccsr_pic_t, tfrr)) #elif defined (CONFIG_4xx) #define _POST_WORD_ADDR \ (CONFIG_SYS_OCM_DATA_ADDR + CONFIG_SYS_GBL_DATA_OFFSET - 0x4) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Try to fix Board eb_cpux9k2
Dear Albert ARIBAUD, A second problem, the board does not restart (reset command). I find out that a NULL pointer used by reset code, was also relocated. How did you come to this conclusion? NULL pointers are constants and thus are *not* relocated. This problem will be gone with Andreas Bießmann patch arm920t/at91/reset: board_reset: define weak symbol reset I have currently no access to a BDI2000. But I think, this problems are not board specific. It is possible, there are problems with vector tables or memory protection Any suggestions? I suggest visually running through all (board or cpu-specific) code that runs as part of execution board_init_f() and checking that no global is ever used -- BSS or initialized. Andreas mirror BSS check says OK, But the board hangs on write access to nand memory space (0x4000) without any error message. The board use 920t on at91rm9200 soc regards Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Try to fix Board eb_cpux9k2
Le 02/12/2010 21:27, Jens Scharsig a écrit : I suggest visually running through all (board or cpu-specific) code that runs as part of execution board_init_f() and checking that no global is ever used -- BSS or initialized. Andreas mirror BSS check says OK, But the board hangs on write access to nand memory space (0x4000) without any error message. Did you also apply Andreas's fix to not use r8 in start.S? Thats's http://patchwork.ozlabs.org/patch/73685/. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.12-rc2 released
Some of the times, the boot hung after printing DRAM: 128 MiB, but never did it hang without printing anything. The same here. Beagleboard xM rev.A hangs after DRAM: 256 MiB Regards, -- Carlo Caione ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/13] mpc8569mds: Remove unnecessary CONFIG_SYS_LBC_SDRAM_BASE definition
This isn't used - delete it. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- include/configs/MPC8569MDS.h |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h index c7973b4..720b5b6 100644 --- a/include/configs/MPC8569MDS.h +++ b/include/configs/MPC8569MDS.h @@ -262,12 +262,6 @@ extern unsigned long get_clock_freq(void); #define CONFIG_SYS_OR3_PRELIM CONFIG_NAND_OR_PRELIM /* NAND Options */ #endif -/* - * SDRAM on the LocalBus - */ -#define CONFIG_SYS_LBC_SDRAM_BASE 0xf000 /* Localbus SDRAM */ -#define CONFIG_SYS_LBC_SDRAM_SIZE 64 /* LBC SDRAM is 64MB */ - #define CONFIG_SYS_LBC_LCRR0x0004 /* LB clock ratio reg */ #define CONFIG_SYS_LBC_LBCR0x0004 /* LB config reg */ #define CONFIG_SYS_LBC_LSRT0x2000 /* LB sdram refresh timer */ -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/13] mpc8540eval: Split initdram() into initdram() and sdram_init()
Modeled after the MPC8540DS code; this will allow us to use a common
initdram() once that is available. There should be no functional
change.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/mpc8540eval/mpc8540eval.c | 64 +-
1 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/board/mpc8540eval/mpc8540eval.c b/board/mpc8540eval/mpc8540eval.c
index 054d644..f1ab360 100644
--- a/board/mpc8540eval/mpc8540eval.c
+++ b/board/mpc8540eval/mpc8540eval.c
@@ -64,41 +64,15 @@ int checkboard (void)
return (0);
}
-phys_size_t initdram (int board_type)
+void sdram_init(void)
{
- long dram_size = 0;
-
-#if !defined(CONFIG_RAM_AS_FLASH)
+#if !defined(CONFIG_RAM_AS_FLASH) /* LocalBus is not emulating flash */
volatile fsl_lbc_t *lbc = LBC_BASE_ADDR;
+ volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
sys_info_t sysinfo;
uint temp_lbcdll = 0;
-#endif
-#if !defined(CONFIG_RAM_AS_FLASH) || defined(CONFIG_DDR_DLL)
- volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
-#endif
-#if defined(CONFIG_DDR_DLL)
- uint temp_ddrdll = 0;
- /* Work around to stabilize DDR DLL */
- temp_ddrdll = gur-ddrdllcr;
- gur-ddrdllcr = ((temp_ddrdll 0xff) 16) | 0x8000;
- asm(sync;isync;msync);
-#endif
-
-#if defined(CONFIG_SPD_EEPROM)
- dram_size = fsl_ddr_sdram();
- dram_size = setup_ddr_tlbs(dram_size / 0x10);
- dram_size *= 0x10;
-#else
- dram_size = fixed_sdram ();
-#endif
-
-#if defined(CONFIG_SYS_RAMBOOT)
- return dram_size;
-#endif
-
-#if !defined(CONFIG_RAM_AS_FLASH) /* LocalBus is not emulating flash */
get_sys_info(sysinfo);
/* if localbus freq is less than 66MHz,we use bypass mode,otherwise use
DLL */
if(sysinfo.freqSystemBus/(CONFIG_SYS_LBC_LCRR LCRR_CLKDIV)
6600) {
@@ -132,6 +106,38 @@ phys_size_t initdram (int board_type)
lbc-mrtpr = CONFIG_SYS_LBC_MRTPR;
asm(sync);
#endif
+}
+
+phys_size_t initdram(int board_type)
+{
+ long dram_size = 0;
+
+#if !defined(CONFIG_RAM_AS_FLASH) || defined(CONFIG_DDR_DLL)
+ volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+#endif
+
+#if defined(CONFIG_DDR_DLL)
+ uint temp_ddrdll = 0;
+
+ /* Work around to stabilize DDR DLL */
+ temp_ddrdll = gur-ddrdllcr;
+ gur-ddrdllcr = ((temp_ddrdll 0xff) 16) | 0x8000;
+ asm(sync;isync;msync);
+#endif
+
+#if defined(CONFIG_SPD_EEPROM)
+ dram_size = fsl_ddr_sdram();
+ dram_size = setup_ddr_tlbs(dram_size / 0x10);
+ dram_size *= 0x10;
+#else
+ dram_size = fixed_sdram();
+#endif
+
+#if defined(CONFIG_SYS_RAMBOOT)
+ return dram_size;
+#endif
+
+ sdram_init();
#if defined(CONFIG_DDR_ECC)
{
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/13] mpc85xx/tlb.c: Allow platforms to specify wimge bits
Some platforms might want to override the default wimge=0 for
DDR. Add CONFIG_DDR_TLB_WIMGE for those platforms to use.
This will initially only be used by TQM85xx, but could be
useful for other boards or testing going forward.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/cpu/mpc85xx/tlb.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
index e3a71ae..513 100644
--- a/arch/powerpc/cpu/mpc85xx/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/tlb.c
@@ -250,10 +250,14 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
{
int i;
unsigned int tlb_size;
+ unsigned int wimge = 0;
unsigned int ram_tlb_address = (unsigned int)CONFIG_SYS_DDR_SDRAM_BASE;
unsigned int max_cam = (mfspr(SPRN_TLB1CFG) 16) 0xf;
u64 size, memsize = (u64)memsize_in_meg 20;
+#ifdef CONFIG_DDR_TLB_WIMGE
+ wimge = CONFIG_DDR_TLB_WIMGE;
+#endif
size = min(memsize, CONFIG_MAX_MEM_MAPPED);
/* Convert (4^max) kB to (2^max) bytes */
@@ -277,7 +281,7 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
tlb_size = (camsize - 10) / 2;
set_tlb(1, ram_tlb_address, p_addr,
- MAS3_SX|MAS3_SW|MAS3_SR, 0,
+ MAS3_SX|MAS3_SW|MAS3_SR, wimge,
0, ram_tlb_index, tlb_size, 1);
size -= 1ULL camsize;
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/13] SBC8560: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
This is for boards that use the SDRAM mode on the LBC but don't require any additional setup. I'm merging all the initdram() calls into a single function for 85xx, and have to be able to distinguish between boards that require an sdram_init() function, and those that do not. We could have defined an empty sdram_init() but I hate doing that. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- include/configs/sbc8560.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/sbc8560.h b/include/configs/sbc8560.h index 101c5d9..65d8eba 100644 --- a/include/configs/sbc8560.h +++ b/include/configs/sbc8560.h @@ -136,6 +136,9 @@ #undef CONFIG_CLOCKS_IN_MHZ +/* No sdram_init() required - some boards require additional setup */ +#define CONFIG_SYS_LBC_NO_SDRAM_INIT + #if defined(CONFIG_RAM_AS_FLASH) #define CONFIG_SYS_LBC_SDRAM_BASE0xfc00 /* Localbus SDRAM */ #define CONFIG_SYS_FLASH_BASE0xf800 /* start of FLASH 8M */ -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/13] PM854: rename CONFIG_SYS_LBC_SDRAM_BASE CONFIG_SYS_LBC_BASE
As far as I can tell, this board doesn't actually configure the LBC
for SDRAM. I've renamed this to avoid confusion (and to make the
initdram() cleanup easier later.)
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/pm854/law.c |5 ++---
board/pm854/tlb.c |4 ++--
include/configs/PM854.h |6 +-
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/board/pm854/law.c b/board/pm854/law.c
index ac21d7a..bea9259 100644
--- a/board/pm854/law.c
+++ b/board/pm854/law.c
@@ -35,7 +35,7 @@
* 0xc000_ 0xdfff_ RapidIO 512M
* 0xe000_ 0xe000_ CCSR1M
* 0xe200_ 0xe2ff_ PCI1 IO 16M
- * 0xf000_ 0xf7ff_ SDRAM 128M
+ * 0xf000_ 0xf7ff_ LBC 128M
* 0xf800_ 0xf80f_ BCSR1M
* 0xfc00_ 0x_ FLASH (boot bank) 64M
*
@@ -49,8 +49,7 @@ struct law_entry law_table[] = {
SET_LAW(CONFIG_SYS_DDR_SDRAM_BASE, LAW_SIZE_256M, LAW_TRGT_IF_DDR),
#endif
SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
- /* This is not so much the SDRAM map as it is the whole localbus map. */
- SET_LAW(CONFIG_SYS_LBC_SDRAM_BASE, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
+ SET_LAW(CONFIG_SYS_LBC_BASE, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
SET_LAW(CONFIG_SYS_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
SET_LAW(CONFIG_SYS_RIO_MEM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
};
diff --git a/board/pm854/tlb.c b/board/pm854/tlb.c
index 5e74e2d..dadb75c 100644
--- a/board/pm854/tlb.c
+++ b/board/pm854/tlb.c
@@ -93,9 +93,9 @@ struct fsl_e_tlb_entry tlb_table[] = {
/*
* TLB 6: 64M Cacheable, non-guarded
-* 0xf000_ 64M LBC SDRAM
+* 0xf000_ 64M LBC
*/
- SET_TLB_ENTRY(1, CONFIG_SYS_LBC_SDRAM_BASE, CONFIG_SYS_LBC_SDRAM_BASE,
+ SET_TLB_ENTRY(1, CONFIG_SYS_LBC_BASE, CONFIG_SYS_LBC_BASE,
MAS3_SX|MAS3_SW|MAS3_SR, 0,
0, 6, BOOKE_PAGESZ_64M, 1),
diff --git a/include/configs/PM854.h b/include/configs/PM854.h
index 1e2089f..39283b2 100644
--- a/include/configs/PM854.h
+++ b/include/configs/PM854.h
@@ -123,11 +123,7 @@
#define CONFIG_SYS_DDR_MODE0x0062 /* DLL,normal,seq,4/2.5 */
#define CONFIG_SYS_DDR_INTERVAL0x045b0100 /* autocharge,no open
page */
-/*
- * SDRAM on the Local Bus
- */
-#define CONFIG_SYS_LBC_SDRAM_BASE 0xf000 /* Localbus SDRAM */
-#define CONFIG_SYS_LBC_SDRAM_SIZE 0 /* LBC SDRAM is 0 MB */
+#define CONFIG_SYS_LBC_BASE0xf000 /* Localbus */
#define CONFIG_SYS_FLASH_BASE 0xfe00 /* start of 32 MB FLASH
*/
#define CONFIG_SYS_BR0_PRELIM 0xfe001801 /* port size 32bit */
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/13] Go to common initdram() on 85xx-based boards
This patch series consists of a bunch of cleanups that allow us to use a common initdram() on all of the non-corenet 85xx-based boards. Also, switch to using phys_size_t to represent the size of memory returned. Most of these patches are just code rearranges or renaming things to get a common scheme in place. There are also lots of cleanups - the various initdram() implementations had a variety of issues that I have hopefully fixed. This is a large patch series, and I've had to hack on a bunch of different boards that I know nothing about, so I'd appreciate any review commentary. I have tested this on 8572DS and confirmed that the results of a MAKEALL powerpc are the same before and after this series. Cheers, Becky arch/powerpc/cpu/mpc85xx/cmd_errata.c|3 + arch/powerpc/cpu/mpc85xx/cpu.c | 58 ++ arch/powerpc/cpu/mpc85xx/tlb.c |6 ++- arch/powerpc/include/asm/fsl_ddr_sdram.h | 13 arch/powerpc/include/asm/fsl_lbc.h |7 ++ board/atum8548/atum8548.c| 25 + board/freescale/mpc8536ds/mpc8536ds.c| 21 --- board/freescale/mpc8540ads/mpc8540ads.c | 52 + board/freescale/mpc8540ads/tlb.c | 19 -- board/freescale/mpc8541cds/mpc8541cds.c | 43 -- board/freescale/mpc8544ds/mpc8544ds.c| 17 -- board/freescale/mpc8548cds/mpc8548cds.c | 38 board/freescale/mpc8555cds/mpc8555cds.c | 45 -- board/freescale/mpc8560ads/mpc8560ads.c | 52 + board/freescale/mpc8560ads/tlb.c | 19 -- board/freescale/mpc8568mds/mpc8568mds.c | 38 board/freescale/mpc8569mds/mpc8569mds.c | 36 board/freescale/mpc8572ds/mpc8572ds.c| 19 -- board/freescale/p1022ds/p1022ds.c| 13 board/freescale/p1_p2_rdb/ddr.c | 15 +- board/freescale/p2020ds/p2020ds.c| 34 ++- board/mpc8540eval/mpc8540eval.c | 52 +--- board/pm854/law.c|5 +- board/pm854/pm854.c | 62 +--- board/pm854/tlb.c| 18 +- board/pm856/law.c|5 +- board/pm856/pm856.c | 57 +-- board/pm856/tlb.c| 18 +- board/sbc8548/sbc8548.c | 45 +-- board/sbc8548/tlb.c | 34 --- board/sbc8560/sbc8560.c | 93 +- board/socrates/sdram.c | 15 +- board/stx/stxgp3/stxgp3.c| 32 -- board/stx/stxssa/stxssa.c| 33 --- board/tqc/tqm85xx/sdram.c| 70 +++ board/tqc/tqm85xx/tlb.c | 47 --- board/xes/common/Makefile|2 - board/xes/common/fsl_8xxx_ddr.c | 46 --- board/xes/xpedite517x/xpedite517x.c | 13 doc/README.mpc85xxads|4 +- include/configs/MPC8536DS.h |1 - include/configs/MPC8540EVAL.h|2 +- include/configs/MPC8548CDS.h |2 +- include/configs/MPC8568MDS.h |1 - include/configs/MPC8569MDS.h |7 -- include/configs/MPC8572DS.h |1 - include/configs/P1_P2_RDB.h |1 - include/configs/PM854.h |8 +-- include/configs/PM856.h |8 +-- include/configs/SBC8540.h|5 +- include/configs/TQM85xx.h|6 ++- include/configs/sbc8560.h|5 +- include/configs/stxgp3.h |5 +- include/configs/stxssa.h |1 - 54 files changed, 185 insertions(+), 1092 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/13] socrates: rename sdram_setup fixed_sdram()
This will help us go to a fixed initdram() for all 85xx boards going
forward. sdram_setup() had an argument that it didn't need, since the
value was #defined.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/socrates/sdram.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/socrates/sdram.c b/board/socrates/sdram.c
index 029ba02..ef897b2 100644
--- a/board/socrates/sdram.c
+++ b/board/socrates/sdram.c
@@ -39,7 +39,7 @@
* so this should be extended for other future boards
* using this routine!
*/
-long int sdram_setup(int casl)
+long int fixed_sdram(void)
{
volatile ccsr_ddr_t *ddr = (void *)(CONFIG_SYS_MPC85xx_DDR_ADDR);
@@ -85,7 +85,7 @@ phys_size_t initdram (int board_type)
dram_size = setup_ddr_tlbs(dram_size / 0x10);
dram_size *= 0x10;
#else
- dram_size = sdram_setup(CONFIG_DDR_DEFAULT_CL);
+ dram_size = fixed_sdram();
#endif
return dram_size;
}
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/13] tqm85xx: create fixed_sdram() to do sdram setup
Also, change this code to use phys_size_t instead of long int.
Using common naming for this function will enable us to use the common
initdram() for 85xx going forward. Other than the type change,
this is just a code rearrange.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/tqc/tqm85xx/sdram.c | 37 +++--
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/board/tqc/tqm85xx/sdram.c b/board/tqc/tqm85xx/sdram.c
index 503c5e5..260cd1c 100644
--- a/board/tqc/tqm85xx/sdram.c
+++ b/board/tqc/tqm85xx/sdram.c
@@ -65,6 +65,7 @@ sdram_conf_t ddr_cs_conf[] = {
#defineN_DDR_CS_CONF (sizeof(ddr_cs_conf) / sizeof(ddr_cs_conf[0]))
int cas_latency (void);
+static phys_size_t sdram_setup(int);
/*
* Autodetect onboard DDR SDRAM on 85xx platforms
@@ -73,7 +74,26 @@ int cas_latency (void);
* so this should be extended for other future boards
* using this routine!
*/
-long int sdram_setup (int casl)
+phys_size_t fixed_sdram(void)
+{
+ int casl = 0;
+ phys_size_t dram_size = 0;
+
+ casl = cas_latency();
+ dram_size = sdram_setup(casl);
+ if ((dram_size == 0) (casl != CONFIG_DDR_DEFAULT_CL)) {
+ /*
+* Try again with default CAS latency
+*/
+ printf(Problem with CAS lantency, using default CL %d/10!\n,
+ CONFIG_DDR_DEFAULT_CL);
+ dram_size = sdram_setup(CONFIG_DDR_DEFAULT_CL);
+ puts( );
+ }
+ return dram_size;
+}
+
+static phys_size_t sdram_setup(int casl)
{
int i;
volatile ccsr_ddr_t *ddr = (void *)(CONFIG_SYS_MPC85xx_DDR_ADDR);
@@ -376,8 +396,7 @@ long int sdram_setup (int casl)
phys_size_t initdram (int board_type)
{
- long dram_size = 0;
- int casl;
+ phys_size_t dram_size = 0;
#if defined(CONFIG_DDR_DLL)
/*
@@ -407,17 +426,7 @@ phys_size_t initdram (int board_type)
}
#endif
- casl = cas_latency ();
- dram_size = sdram_setup (casl);
- if ((dram_size == 0) (casl != CONFIG_DDR_DEFAULT_CL)) {
- /*
-* Try again with default CAS latency
-*/
- printf (Problem with CAS lantency, using default CL %d/10!\n,
- CONFIG_DDR_DEFAULT_CL);
- dram_size = sdram_setup (CONFIG_DDR_DEFAULT_CL);
- puts ( );
- }
+ dram_size = fixed_sdram();
return dram_size;
}
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/13] PM856: Rename CONFIG_SYS_LBC_SDRAM_BASE CONFIG_SYS_LBC_BASE
This board does not actually configure anything for SDRAM - change
the name to avoid confusion and make it easier to go to a common
initdram going forward.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
board/pm856/law.c |5 ++---
board/pm856/tlb.c |4 ++--
include/configs/PM856.h |6 +-
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/board/pm856/law.c b/board/pm856/law.c
index ac21d7a..bea9259 100644
--- a/board/pm856/law.c
+++ b/board/pm856/law.c
@@ -35,7 +35,7 @@
* 0xc000_ 0xdfff_ RapidIO 512M
* 0xe000_ 0xe000_ CCSR1M
* 0xe200_ 0xe2ff_ PCI1 IO 16M
- * 0xf000_ 0xf7ff_ SDRAM 128M
+ * 0xf000_ 0xf7ff_ LBC 128M
* 0xf800_ 0xf80f_ BCSR1M
* 0xfc00_ 0x_ FLASH (boot bank) 64M
*
@@ -49,8 +49,7 @@ struct law_entry law_table[] = {
SET_LAW(CONFIG_SYS_DDR_SDRAM_BASE, LAW_SIZE_256M, LAW_TRGT_IF_DDR),
#endif
SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
- /* This is not so much the SDRAM map as it is the whole localbus map. */
- SET_LAW(CONFIG_SYS_LBC_SDRAM_BASE, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
+ SET_LAW(CONFIG_SYS_LBC_BASE, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
SET_LAW(CONFIG_SYS_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
SET_LAW(CONFIG_SYS_RIO_MEM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_RIO),
};
diff --git a/board/pm856/tlb.c b/board/pm856/tlb.c
index 5e74e2d..dadb75c 100644
--- a/board/pm856/tlb.c
+++ b/board/pm856/tlb.c
@@ -93,9 +93,9 @@ struct fsl_e_tlb_entry tlb_table[] = {
/*
* TLB 6: 64M Cacheable, non-guarded
-* 0xf000_ 64M LBC SDRAM
+* 0xf000_ 64M LBC
*/
- SET_TLB_ENTRY(1, CONFIG_SYS_LBC_SDRAM_BASE, CONFIG_SYS_LBC_SDRAM_BASE,
+ SET_TLB_ENTRY(1, CONFIG_SYS_LBC_BASE, CONFIG_SYS_LBC_BASE,
MAS3_SX|MAS3_SW|MAS3_SR, 0,
0, 6, BOOKE_PAGESZ_64M, 1),
diff --git a/include/configs/PM856.h b/include/configs/PM856.h
index d3e8f41..dbce6c4 100644
--- a/include/configs/PM856.h
+++ b/include/configs/PM856.h
@@ -125,11 +125,7 @@
#define CONFIG_SYS_DDR_MODE0x0062 /* DLL,normal,seq,4/2.5 */
#define CONFIG_SYS_DDR_INTERVAL0x045b0100 /* autocharge,no open
page */
-/*
- * SDRAM on the Local Bus
- */
-#define CONFIG_SYS_LBC_SDRAM_BASE 0xf000 /* Localbus SDRAM */
-#define CONFIG_SYS_LBC_SDRAM_SIZE 0 /* LBC SDRAM is 0 MB */
+#define CONFIG_SYS_LBC_BASE0xf000 /* Localbus */
#define CONFIG_SYS_FLASH_BASE 0xfe00 /* start of FLASH 32M */
#define CONFIG_SYS_BR0_PRELIM 0xfe001801 /* port size 32bit */
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/13] stxgp3: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
This is needed to distinguish between boards with lbc sdram that require additional initialization and those that do not. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- include/configs/stxgp3.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/stxgp3.h b/include/configs/stxgp3.h index c2497ad..f4cd138 100644 --- a/include/configs/stxgp3.h +++ b/include/configs/stxgp3.h @@ -82,6 +82,9 @@ #define CONFIG_SYS_LBC_SDRAM_BASE 0xf000 /* Localbus SDRAM */ #define CONFIG_SYS_LBC_SDRAM_SIZE 256 /* LBC SDRAM is 64MB */ +/* No sdram_init() required - some boards require additional setup */ +#define CONFIG_SYS_LBC_NO_SDRAM_INIT + #define CONFIG_SYS_FLASH_BASE0xff00 /* start of FLASH 16M */ #define CONFIG_SYS_BR0_PRELIM0xff001801 /* port size 32bit */ -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/13] SBC8540: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
This is used to distinguish between boards that require extra setup to use LBC sdram, and those that don't Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- include/configs/SBC8540.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/SBC8540.h b/include/configs/SBC8540.h index fd9bacc..7c1d0bd 100644 --- a/include/configs/SBC8540.h +++ b/include/configs/SBC8540.h @@ -151,6 +151,9 @@ #endif #define CONFIG_SYS_LBC_SDRAM_SIZE 64 /* LBC SDRAM is 64MB */ +/* No sdram_init() required - some boards require additional setup */ +#define CONFIG_SYS_LBC_NO_SDRAM_INIT + /* local bus definitions */ #define CONFIG_SYS_BR1_PRELIM 0xe4001801 /* 64M, 32-bit flash */ #define CONFIG_SYS_OR1_PRELIM 0xfc000ff7 -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/13] 85xx boards: Rename CONFIG_DDR_DLL to CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN
This config option is for an erratum workaround; rename it to be more
clear. Also, drop it from config files don't need it and were
undefining it.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++
arch/powerpc/cpu/mpc85xx/cpu.c|2 +-
doc/README.mpc85xxads |4 ++--
include/configs/MPC8536DS.h |1 -
include/configs/MPC8540EVAL.h |2 +-
include/configs/MPC8548CDS.h |2 +-
include/configs/MPC8572DS.h |1 -
include/configs/P1_P2_RDB.h |1 -
include/configs/PM854.h |2 +-
include/configs/PM856.h |2 +-
include/configs/SBC8540.h |2 +-
include/configs/TQM85xx.h |2 +-
include/configs/sbc8560.h |2 +-
include/configs/stxgp3.h |2 +-
include/configs/stxssa.h |1 -
15 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index d73f3d7..2d32532 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -47,6 +47,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#if defined(CONFIG_SYS_P4080_ERRATUM_CPU22)
puts(Work-around for Erratum CPU22 enabled\n);
#endif
+#if defined(CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN)
+ puts(Work-around for DDR MSYNC_IN Erratum enabled\n);
+#endif
return 0;
}
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index f242baf..f15daa3 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -295,7 +295,7 @@ phys_size_t initdram(int board_type)
puts(Initializing\n);
-#if defined(CONFIG_DDR_DLL)
+#if defined(CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN)
{
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
unsigned int x = 10;
diff --git a/doc/README.mpc85xxads b/doc/README.mpc85xxads
index 046f981..d059a97 100644
--- a/doc/README.mpc85xxads
+++ b/doc/README.mpc85xxads
@@ -144,8 +144,8 @@ Updated 13-July-2004 Jon Loeliger
also manual config the DDR after undef this
definition.
CONFIG_DDR_ECC only for ECC DDR module
-CONFIG_DDR_DLL DLL fix on some ADS boards needed for more
- stability.
+CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_INDLL fix on some ADS boards
needed
+ for more stability.
CONFIG_HAS_FEC If an FEC is on chip, set to 1, else 0.
Other than the above definitions, the rest in the config files are
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 850665a..774c59f 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -145,7 +145,6 @@
#undef CONFIG_FSL_DDR_INTERACTIVE
#define CONFIG_SPD_EEPROM /* Use SPD EEPROM for DDR setup */
#define CONFIG_DDR_SPD
-#undef CONFIG_DDR_DLL
#define CONFIG_ECC_INIT_VIA_DDRCONTROLLER /* DDR controller or DMA? */
#define CONFIG_MEM_INIT_VALUE 0xDeadBeef
diff --git a/include/configs/MPC8540EVAL.h b/include/configs/MPC8540EVAL.h
index a968949..073241b 100644
--- a/include/configs/MPC8540EVAL.h
+++ b/include/configs/MPC8540EVAL.h
@@ -122,7 +122,7 @@
#undef CONFIG_FSL_DDR_INTERACTIVE
#define CONFIG_SPD_EEPROM /* Use SPD EEPROM for DDR setup */
#define CONFIG_DDR_SPD
-#define CONFIG_DDR_DLL /* possible DLL fix needed */
+#define CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN/* possible DLL fix needed */
#undef CONFIG_DDR_ECC /* only for ECC DDR module */
#undef CONFIG_ECC_INIT_VIA_DDRCONTROLLER /* DDR controller or DMA? */
diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h
index b221a5c..e5ac3a9 100644
--- a/include/configs/MPC8548CDS.h
+++ b/include/configs/MPC8548CDS.h
@@ -89,7 +89,7 @@ extern unsigned long get_clock_freq(void);
#undef CONFIG_FSL_DDR_INTERACTIVE
#define CONFIG_SPD_EEPROM /* Use SPD EEPROM for DDR setup*/
#define CONFIG_DDR_SPD
-#define CONFIG_DDR_DLL /* possible DLL fix needed */
+#define CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN/* possible DLL fix needed */
#define CONFIG_ECC_INIT_VIA_DDRCONTROLLER /* DDR controller or DMA? */
#define CONFIG_MEM_INIT_VALUE 0xDeadBeef
diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h
index 692c811..1373f26 100644
--- a/include/configs/MPC8572DS.h
+++ b/include/configs/MPC8572DS.h
@@ -99,7 +99,6 @@
#undef CONFIG_FSL_DDR_INTERACTIVE
#define CONFIG_SPD_EEPROM /* Use SPD EEPROM for DDR setup */
#define CONFIG_DDR_SPD
-#undef CONFIG_DDR_DLL
#define CONFIG_ECC_INIT_VIA_DDRCONTROLLER
#define CONFIG_MEM_INIT_VALUE 0xDeadBeef
diff --git a/include/configs/P1_P2_RDB.h
[U-Boot] [PATCH 12/13] mpc85xx boards: initdram() cleanup/bugfix
Correct initdram to use phys_size_t to represent the size of
dram; instead of changing this all over the place, and correcting
all the other random errors I've notived, create a
common initdram that is used by all non-corenet 85xx parts. Most
of the initdram() functions were identical, with 2 common differences:
1) DDR tlbs for the fixed_sdram case were set up in initdram() on
some boards, and were part of the tlb_table on others. I have
changed them all over to the initdram() method - we shouldn't
be accessing dram before this point so they don't need to be
done sooner, and this seems cleaner.
2) Parts that require the DDR11 erratum workaround had different
implementations - I have adopted the version from the Freescale
errata document. It also looks like some of the versions were
buggy, and, depending on timing, could have resulted in the
DDR controller being disabled. This seems bad.
The xpedite boards had a common/fsl_8xxx_ddr.c; with this
change only the 517 board uses this so I have moved the ddr code
into that board's directory in xpedite517x.c
The ATUM8548 board didn't appear to set up any tlbs in the
fixed_sdram case; this patch fixes that.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/cpu/mpc85xx/cpu.c | 58 ++
arch/powerpc/include/asm/fsl_ddr_sdram.h | 13
arch/powerpc/include/asm/fsl_lbc.h |7 ++
board/atum8548/atum8548.c| 25 +
board/freescale/mpc8536ds/mpc8536ds.c| 21 ---
board/freescale/mpc8540ads/mpc8540ads.c | 52 +
board/freescale/mpc8540ads/tlb.c | 19 --
board/freescale/mpc8541cds/mpc8541cds.c | 43 --
board/freescale/mpc8544ds/mpc8544ds.c| 17 --
board/freescale/mpc8548cds/mpc8548cds.c | 38
board/freescale/mpc8555cds/mpc8555cds.c | 45 --
board/freescale/mpc8560ads/mpc8560ads.c | 52 +
board/freescale/mpc8560ads/tlb.c | 19 --
board/freescale/mpc8568mds/mpc8568mds.c | 38
board/freescale/mpc8569mds/mpc8569mds.c | 36
board/freescale/mpc8572ds/mpc8572ds.c| 19 --
board/freescale/p1022ds/p1022ds.c| 13
board/freescale/p1_p2_rdb/ddr.c | 15 +-
board/freescale/p2020ds/p2020ds.c| 34 ++-
board/mpc8540eval/mpc8540eval.c | 52 +
board/pm854/pm854.c | 62 +---
board/pm854/tlb.c| 14 -
board/pm856/pm856.c | 57 +--
board/pm856/tlb.c| 14 -
board/sbc8548/sbc8548.c | 45 +--
board/sbc8548/tlb.c | 34 ---
board/sbc8560/sbc8560.c | 93 +-
board/socrates/sdram.c | 15 +-
board/stx/stxgp3/stxgp3.c| 32 --
board/stx/stxssa/stxssa.c| 33 ---
board/tqc/tqm85xx/sdram.c| 37
board/tqc/tqm85xx/tlb.c | 47 ---
board/xes/common/Makefile|2 -
board/xes/common/fsl_8xxx_ddr.c | 46 ---
board/xes/xpedite517x/xpedite517x.c | 13
include/configs/TQM85xx.h|4 +
36 files changed, 124 insertions(+), 1040 deletions(-)
delete mode 100644 board/xes/common/fsl_8xxx_ddr.c
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 55ee36d..f242baf 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -34,6 +34,7 @@
#include asm/io.h
#include asm/mmu.h
#include asm/fsl_law.h
+#include asm/fsl_lbc.h
#include post.h
#include asm/processor.h
#include asm/fsl_ddr_sdram.h
@@ -286,6 +287,63 @@ void mpc85xx_reginfo(void)
print_lbc_regs();
}
+/* Common ddr init for non-corenet fsl 85xx platforms */
+#ifndef CONFIG_FSL_CORENET
+phys_size_t initdram(int board_type)
+{
+ phys_size_t dram_size = 0;
+
+ puts(Initializing\n);
+
+#if defined(CONFIG_DDR_DLL)
+ {
+ ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ unsigned int x = 10;
+ unsigned int i;
+
+ /*
+* Work around to stabilize DDR DLL
+*/
+ out_be32(gur-ddrdllcr, 0x8100);
+ asm(sync;isync;msync);
+ udelay(200);
+ while (in_be32(gur-ddrdllcr) != 0x81000100) {
+ setbits_be32(gur-devdisr, 0x0001);
+ for (i = 0; i x; i++)
+ ;
+ clrbits_be32(gur-devdisr, 0x0001);
+ x++;
+ }
+ }
+#endif
+
+#if defined(CONFIG_SPD_EEPROM) || defined(CONFIG_DDR_SPD)
+ dram_size = fsl_ddr_sdram();
+#else
+
Re: [U-Boot] [PATCH] tsec: Revert to setting TBICR_ANEG_ENABLE by default for SGMII
On Dec 2, 2010, at 10:50 AM, Peter Tyser wrote: Hi Kumar, Signed-off-by: Kumar Gala ga...@kernel.crashing.org Acked-by: Peter Tyser pty...@xes-inc.com Tested-by: Peter Tyser pty...@xes-inc.com snip index e0a1fa4..9d87eaf 100644 --- a/include/configs/xpedite537x.h +++ b/include/configs/xpedite537x.h @@ -375,6 +375,12 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #define CONFIG_MII_DEFAULT_TSEC 1 /* Allow unregistered phys */ #define CONFIG_ETHPRIME eTSEC2 Would you mind adding a comment along the lines of the following to xpedite537x.h and xpedite550x.h above the CONFIG_TSEC_TBICR_SETTINGS define?: /* * In-band SGMII auto-negotiation between TBI and BCM5482S PHY fails, force * 1000mbps SGMII link */ +#define CONFIG_TSEC_TBICR_SETTINGS ( \ +TBICR_PHY_RESET \ +| TBICR_FULL_DUPLEX \ +| TBICR_SPEED1_SET \ +) + Thanks, Peter Will make these changes repost - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_upm: Add MxMR/MDR synchronization
On Thu, 2 Dec 2010 18:19:08 -0600
Kumar Gala ga...@kernel.crashing.org wrote:
[Adding Scott W. - would like his ack on this]
Acked-by: Scott Wood scottw...@freescale.com
- k
On Dec 2, 2010, at 11:43 AM, Peter Tyser wrote:
From: John Schmoller jschmol...@xes-inc.com
According to Freescale reference manuals (eg section 13.4.4.2
Programming the UPMs of the P4080 Reference Manual):
Since the result of any update to the MxMR/MDR register must be in
effect before the dummy read or write to the UPM region, a write to
MxMR/MDR should be followed immediately by a read of MxMR/MDR.
The UPM on a custom P4080-based board did not work without performing
a read of MxMR/MDR after a write.
Signed-off-by: John Schmoller jschmol...@xes-inc.com
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
drivers/mtd/nand/fsl_upm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/fsl_upm.c b/drivers/mtd/nand/fsl_upm.c
index b76c673..be00555 100644
--- a/drivers/mtd/nand/fsl_upm.c
+++ b/drivers/mtd/nand/fsl_upm.c
@@ -21,6 +21,7 @@
static void fsl_upm_start_pattern(struct fsl_upm *upm, u32 pat_offset)
{
clrsetbits_be32(upm-mxmr, MxMR_MAD_MSK, MxMR_OP_RUNP | pat_offset);
+ (void)in_be32(upm-mxmr);
}
static void fsl_upm_end_pattern(struct fsl_upm *upm)
@@ -35,6 +36,7 @@ static void fsl_upm_run_pattern(struct fsl_upm *upm, int
width,
void __iomem *io_addr, u32 mar)
{
out_be32(upm-mar, mar);
+ (void)in_be32(upm-mar);
switch (width) {
case 8:
out_8(io_addr, 0x0);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] SBC8560: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
On Thu, Dec 2, 2010 at 5:45 PM, Becky Bruce bec...@kernel.crashing.org wrote: This is for boards that use the SDRAM mode on the LBC but don't require any additional setup. I'm merging all the initdram() calls into a single function for 85xx, and have to be able to distinguish between boards that require an sdram_init() function, and those that do not. We could have defined an empty sdram_init() but I hate doing that. Would a weak function be a better way to do this? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb_ether: register usb ethernet gadget at each eth init
Hi Vitaly, On Fri, Dec 3, 2010 at 12:34 AM, Vitaly Kuzmichev vkuzmic...@mvista.com wrote: Hi Lei, Lei Wen wrote: Since the ether may not be the only one usb gadget would be used in the uboot, it is neccessary to do the register each time the eth begin to work to make usb gadget driver less confussed when we want to use two different usb gadget at the same time. Usb gadget driver could simple ignore the register operation, if it find the driver has been registered already. Signed-off-by: Lei Wen lei...@marvell.com Tested, works fine on my board. BTW, for future reference the tags in the subject should be [U-Boot] [PATCH v2]. v2 points to that this is an improved/fixed version of a patch previously submitted. This can be reached using --subject-prefix=U-Boot] [PATCH v2 passed to git format-patch command. Got that. Thanks for testing. :-) Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] include/linux/mii.h: update for supporting GE
This file has been synced (copy) from Linux source code. This commit was based on kernel 2.6.32. It updates gigabit related phy registers and basic definitions. Signed-off-by: Macpaul Lin macp...@andestech.com --- include/linux/mii.h | 270 +-- 1 files changed, 197 insertions(+), 73 deletions(-) diff --git a/include/linux/mii.h b/include/linux/mii.h index 7c63095..359fba8 100644 --- a/include/linux/mii.h +++ b/include/linux/mii.h @@ -8,99 +8,184 @@ #ifndef __LINUX_MII_H__ #define __LINUX_MII_H__ +#include linux/types.h + /* Generic MII registers. */ -#define MII_BMCR 0x00/* Basic mode control register */ -#define MII_BMSR 0x01/* Basic mode status register */ -#define MII_PHYSID10x02/* PHYS ID 1 */ -#define MII_PHYSID20x03/* PHYS ID 2 */ -#define MII_ADVERTISE 0x04/* Advertisement control reg */ -#define MII_LPA0x05/* Link partner ability reg */ -#define MII_EXPANSION 0x06/* Expansion register */ -#define MII_DCOUNTER 0x12/* Disconnect counter */ -#define MII_FCSCOUNTER 0x13/* False carrier counter */ -#define MII_NWAYTEST 0x14/* N-way auto-neg test reg */ -#define MII_RERRCOUNTER 0x15 /* Receive error counter */ -#define MII_SREVISION 0x16/* Silicon revision*/ -#define MII_RESV1 0x17/* Reserved... */ -#define MII_LBRERROR 0x18/* Lpback, rx, bypass error*/ -#define MII_PHYADDR0x19/* PHY address */ -#define MII_RESV2 0x1a/* Reserved... */ -#define MII_TPISTATUS 0x1b/* TPI status for 10mbps */ -#define MII_NCONFIG0x1c/* Network interface config*/ +#define MII_BMCR0x00/* Basic mode control register */ +#define MII_BMSR0x01/* Basic mode status register */ +#define MII_PHYSID1 0x02/* PHYS ID 1 */ +#define MII_PHYSID2 0x03/* PHYS ID 2 */ +#define MII_ADVERTISE 0x04/* Advertisement control reg */ +#define MII_LPA 0x05/* Link partner ability reg*/ +#define MII_EXPANSION 0x06/* Expansion register */ +#define MII_CTRL10000x09/* 1000BASE-T control */ +#define MII_STAT10000x0a/* 1000BASE-T status */ +#define MII_ESTATUS0x0f/* Extended Status */ +#define MII_DCOUNTER0x12/* Disconnect counter */ +#define MII_FCSCOUNTER 0x13/* False carrier counter */ +#define MII_NWAYTEST0x14/* N-way auto-neg test reg */ +#define MII_RERRCOUNTER 0x15/* Receive error counter */ +#define MII_SREVISION 0x16/* Silicon revision*/ +#define MII_RESV1 0x17/* Reserved... */ +#define MII_LBRERROR0x18/* Lpback, rx, bypass error*/ +#define MII_PHYADDR 0x19/* PHY address */ +#define MII_RESV2 0x1a/* Reserved... */ +#define MII_TPISTATUS 0x1b/* TPI status for 10mbps */ +#define MII_NCONFIG 0x1c/* Network interface config*/ /* Basic mode control register. */ -#define BMCR_RESV 0x003f /* Unused... */ -#define BMCR_SPEED1000 0x0040 /* MSB of Speed (1000) */ -#define BMCR_CTST 0x0080 /* Collision test */ -#define BMCR_FULLDPLX 0x0100 /* Full duplex */ -#define BMCR_ANRESTART 0x0200 /* Auto negotiation restart*/ -#define BMCR_ISOLATE 0x0400 /* Disconnect DP83840 from MII */ -#define BMCR_PDOWN 0x0800 /* Powerdown the DP83840 */ -#define BMCR_ANENABLE 0x1000 /* Enable auto negotiation */ -#define BMCR_SPEED100 0x2000 /* Select 100Mbps */ -#define BMCR_LOOPBACK 0x4000 /* TXD loopback bits */ -#define BMCR_RESET 0x8000 /* Reset the DP83840 */ +#define BMCR_RESV 0x003f /* Unused... */ +#define BMCR_SPEED1000 0x0040 /* MSB of Speed (1000) */ +#define BMCR_CTST 0x0080 /* Collision test */ +#define BMCR_FULLDPLX 0x0100 /* Full duplex */ +#define BMCR_ANRESTART 0x0200 /* Auto negotiation restart*/ +#define BMCR_ISOLATE0x0400 /* Disconnect DP83840 from MII */ +#define BMCR_PDOWN 0x0800 /* Powerdown the DP83840 */ +#define BMCR_ANENABLE 0x1000 /* Enable auto negotiation */ +#define BMCR_SPEED100
[U-Boot] Ein Stellenangebot in Logistik-Bereich
Sehr geehrte Ich heibe Christian Schroeder und ich habe ein Angebot fur Sie! Unser Unternehmen Jasckson Logistic sucht im Moment neue Arbeitskrafte! Wir haben Ihre Bewerbungsunterlagen bei uns vor einige Zeit liegen gefunden und jetzt mochten wir Ihnen eine Stelle von unseren AuBendienstvertreter anbieten. Was spricht dafur? Keine vorherige Erfahrung notig! wir machen gratis ein Training fur Sie, falls Sie mit uns kooperieren. Schauen Sie, was wir Ihnen anbieten: Stelle: AuBendienstvertreter Bedingungen: Deutsche Staatsangehorigkeit, FlieBendes Deutsch, Grundkenntnisse von Microsoft Word und Microsoft Excel, Grundkenntnisse von Konsumelektronik PC mit Email- und Moglichkeit die Emails min. 2mal taglich zu prufen Drucker, Scanner Volljahrigkeit Beschreibung: - Briefe vom unseren Mitarbeiter regelmaBig empfangen, - Einen Bericht ausfertigen und ihn an den Obermanager verschicken (Der Arbeitnehmer ist einem Obermanager unterordnet), - die angekommene Postsendungen, gemaB unserer Vorschriften, weiterzuleiten, - die Unterlagen, mit Angabe aller Details der Artikel, auszufullen (Der Arbeitnehmer bekommt alle ausfuhrlichen Dokumente fur jede Verpackung per Email), - die Ware versenden. Personliche Eigenschaften: Ehrlichkeit Geselligkeit Teamfahigkeit Hoflichkeit Die Vergutung: 40. pro jede erfolgreich versendete Postsendung (ca.3000 . monatlich) mit Check oder per Uberweisung einmal pro Monat. Wenn Sie daran interessiert sind, schreiben Sie mir unter: job.ulrichra...@gmail.com Danke, Christian Schroeder HR Department Jasckson Logistic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include/linux/mii.h: update for supporting GE
On Thursday, December 02, 2010 22:25:53 Macpaul Lin wrote:
This file has been synced (copy) from Linux source code.
pulling in updates is fine, but i dont think it makes sense to pull in
types/prototypes that arent used in u-boot
+/* This structure is used in all SIOCxMIIxxx ioctl calls */
+struct mii_ioctl_data {
+ __u16 phy_id;
+ __u16 reg_num;
+ __u16 val_in;
+ __u16 val_out;
+};
+
+#ifdef __KERNEL__
+
+#include linux/if.h
+
+struct ethtool_cmd;
+
+struct mii_if_info {
+ int phy_id;
+ int advertising;
+ int phy_id_mask;
+ int reg_num_mask;
+
+ unsigned int full_duplex : 1; /* is full duplex? */
+ unsigned int force_media : 1; /* is autoneg. disabled? */
+ unsigned int supports_gmii : 1; /* are GMII registers supported? */
+
+ struct net_device *dev;
+ int (*mdio_read) (struct net_device *dev, int phy_id, int location);
+ void (*mdio_write) (struct net_device *dev, int phy_id, int location,
int
val); +};
+
+extern int mii_link_ok (struct mii_if_info *mii);
+extern int mii_nway_restart (struct mii_if_info *mii);
+extern int mii_ethtool_gset(struct mii_if_info *mii, struct ethtool_cmd
*ecmd); +extern int mii_ethtool_sset(struct mii_if_info *mii, struct
ethtool_cmd *ecmd); +extern int mii_check_gmii_support(struct mii_if_info
*mii);
+extern void mii_check_link (struct mii_if_info *mii);
+extern unsigned int mii_check_media (struct mii_if_info *mii,
+ unsigned int ok_to_print,
+ unsigned int init_media);
+extern int generic_mii_ioctl(struct mii_if_info *mii_if,
+struct mii_ioctl_data *mii_data, int cmd,
+unsigned int *duplex_changed);
+
+
+static inline struct mii_ioctl_data *if_mii(struct ifreq *rq)
+{
+ return (struct mii_ioctl_data *) rq-ifr_ifru;
+}
i dont think any of this makes sense in u-boot
-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] [STATUS] v2010.12-rc2 released
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Carlo Caione Sent: Friday, December 03, 2010 3:11 AM To: U-Boot@lists.denx.de Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released Some of the times, the boot hung after printing DRAM: 128 MiB, but never did it hang without printing anything. The same here. Beagleboard xM rev.A hangs after DRAM: 256 MiB For fix this, needs to change global variables in timer.c REF: http://lists.denx.de/pipermail/u-boot/2010-December/082834.html Regards.. Prafulla .. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] [REPOST] add Multi Function Pin configuration support for ARMADA100
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 02, 2010 5:05 PM To: Lei Wen Cc: Prafulla Wadaskar; Eric Miao; Manas Saksena; Lei Wen; Yu Tang; u- b...@lists.denx.de; Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH v3 3/7] [REPOST] add Multi Function Pin configuration support for ARMADA100 Dear Lei Wen, In message aanlktimztfsml0bzbti+exrzjkg5jh9kxqzukevrc...@mail.gmail.com you wrote: Do we really need this? I think the better way to configure GPIO MFP is doing like below. That is create each GPIO name, and define its MFPD and MFP_AF. There should be no issue defining as MFP_GPIO(16) or MFP16_GPIO, but it saves hundreds of lines in the code. +/* UART2 */ +#define MFP47_UART2_RXDMFPD(47) | MFP_AF(6) +#define MFP48_UART2_TXDMFPD(48) | MFP_AF(6) +#define MFP88_UART2_RXDMFPD(88) | MFP_AF(2) ... No. This is exactly what I do not want to see. We will end up with zillions of #defines, and only a tiny percentage of them will ever be used. I agree with Wolfgang, On armada168 there are 118 MFPs each can have several programming options, I have defined few of them which will be generally used. Regards.. Prafulla .. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include/linux/mii.h: update for supporting GE
Mike Frysinger [mailto:vap...@gentoo.org] ???: u-boot@lists.denx.de Macpaul Chih-Pin Lin Re: [U-Boot] [PATCH] include/linux/mii.h: update for supporting GE On Thursday, December 02, 2010 22:25:53 Macpaul Lin wrote: This file has been synced (copy) from Linux source code. pulling in updates is fine, but i dont think it makes sense to pull in types/prototypes that arent used in u-boot Okay, I will fix this patch then resend the patch. Also replace the whitespace to tab characters. Because I'm wondering when next time we update the same file from Linux kernel to u-boot, We will might need extra effort to reduce the size of diff (patch) file. i dont think any of this makes sense in u-boot -mike Thanks for your comment. I will send a newer (clean up) patch later. Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB cardreader issue
Hi All, I am trying to read images from SD cards attached to a USB card reader. usb start command shows errors as per logs copied below. Is there any known issue in supporting usb card readers In general or it's compatibility issue with few card readers? Regards, Ajay 1) Card reader - [A] == U-Boot usb start (Re)start USB... USB: scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... READ_CAP ERROR 1 Storage Device(s) found U-Boot usb tree Device Tree: 1 Mass Storage (12 Mb/s, 500mA) Generic USB2.0-CRW 2006041309210 U-Boot fatinfo usb 0:1 ** Can't read from device 0 ** ** Unable to use usb 0:1 for fatinfo ** U-Boot usb info 1: Mass Storage, USB Revision 2.0 - Generic USB2.0-CRW 2006041309210 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x0bda Product 0x0158 Version 81.149 Configuration: 1 - Interfaces: 1 Bus Powered 500mA - String: CARD READER Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - String: Bulk-In, Bulk-Out, Interface - Endpoint 1 Out Bulk MaxPacket 512 - Endpoint 2 In Bulk MaxPacket 512 2) Card reader - [B] == U-Boot # usb start (Re)start USB... USB: scanning bus for devices... 1 USB Device(s) found scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 1 Storage Device(s) found U-Boot # usb tree Device Tree: 1 Mass Storage (12 Mb/s, 100mA) Generic Mass Storage Device 058F312D81B U-Boot # usb info 1: Mass Storage, USB Revision 2.0 - Generic Mass Storage Device 058F312D81B - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x058f Product 0x6362 Version 1.38 Configuration: 1 - Interfaces: 1 Bus Powered 100mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 Out Bulk MaxPacket 512 - Endpoint 2 In Bulk MaxPacket 512 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] include/linux/mii.h: update for supporting GE
This file has been synced (copy) from Linux source code. This commit was based on kernel 2.6.32. It updates gigabit related phy registers and basic definitions. Signed-off-by: Macpaul Lin macp...@andestech.com --- Change v1: pull header file from Linux. Change v2: clean up unused code for u-boot. include/linux/mii.h | 181 ++- 1 files changed, 107 insertions(+), 74 deletions(-) diff --git a/include/linux/mii.h b/include/linux/mii.h index 7c63095..6e7ffab 100644 --- a/include/linux/mii.h +++ b/include/linux/mii.h @@ -10,98 +10,132 @@ /* Generic MII registers. */ -#define MII_BMCR 0x00/* Basic mode control register */ -#define MII_BMSR 0x01/* Basic mode status register */ -#define MII_PHYSID10x02/* PHYS ID 1 */ -#define MII_PHYSID20x03/* PHYS ID 2 */ -#define MII_ADVERTISE 0x04/* Advertisement control reg */ -#define MII_LPA0x05/* Link partner ability reg */ -#define MII_EXPANSION 0x06/* Expansion register */ -#define MII_DCOUNTER 0x12/* Disconnect counter */ -#define MII_FCSCOUNTER 0x13/* False carrier counter */ -#define MII_NWAYTEST 0x14/* N-way auto-neg test reg */ -#define MII_RERRCOUNTER 0x15 /* Receive error counter */ -#define MII_SREVISION 0x16/* Silicon revision*/ -#define MII_RESV1 0x17/* Reserved... */ -#define MII_LBRERROR 0x18/* Lpback, rx, bypass error*/ -#define MII_PHYADDR0x19/* PHY address */ -#define MII_RESV2 0x1a/* Reserved... */ -#define MII_TPISTATUS 0x1b/* TPI status for 10mbps */ -#define MII_NCONFIG0x1c/* Network interface config*/ +#define MII_BMCR0x00/* Basic mode control register */ +#define MII_BMSR0x01/* Basic mode status register */ +#define MII_PHYSID1 0x02/* PHYS ID 1 */ +#define MII_PHYSID2 0x03/* PHYS ID 2 */ +#define MII_ADVERTISE 0x04/* Advertisement control reg */ +#define MII_LPA 0x05/* Link partner ability reg*/ +#define MII_EXPANSION 0x06/* Expansion register */ +#define MII_CTRL10000x09/* 1000BASE-T control */ +#define MII_STAT10000x0a/* 1000BASE-T status */ +#define MII_ESTATUS0x0f/* Extended Status */ +#define MII_DCOUNTER0x12/* Disconnect counter */ +#define MII_FCSCOUNTER 0x13/* False carrier counter */ +#define MII_NWAYTEST0x14/* N-way auto-neg test reg */ +#define MII_RERRCOUNTER 0x15/* Receive error counter */ +#define MII_SREVISION 0x16/* Silicon revision*/ +#define MII_RESV1 0x17/* Reserved... */ +#define MII_LBRERROR0x18/* Lpback, rx, bypass error*/ +#define MII_PHYADDR 0x19/* PHY address */ +#define MII_RESV2 0x1a/* Reserved... */ +#define MII_TPISTATUS 0x1b/* TPI status for 10mbps */ +#define MII_NCONFIG 0x1c/* Network interface config*/ /* Basic mode control register. */ -#define BMCR_RESV 0x003f /* Unused... */ -#define BMCR_SPEED1000 0x0040 /* MSB of Speed (1000) */ -#define BMCR_CTST 0x0080 /* Collision test */ -#define BMCR_FULLDPLX 0x0100 /* Full duplex */ -#define BMCR_ANRESTART 0x0200 /* Auto negotiation restart*/ -#define BMCR_ISOLATE 0x0400 /* Disconnect DP83840 from MII */ -#define BMCR_PDOWN 0x0800 /* Powerdown the DP83840 */ -#define BMCR_ANENABLE 0x1000 /* Enable auto negotiation */ -#define BMCR_SPEED100 0x2000 /* Select 100Mbps */ -#define BMCR_LOOPBACK 0x4000 /* TXD loopback bits */ -#define BMCR_RESET 0x8000 /* Reset the DP83840 */ +#define BMCR_RESV 0x003f /* Unused... */ +#define BMCR_SPEED1000 0x0040 /* MSB of Speed (1000) */ +#define BMCR_CTST 0x0080 /* Collision test */ +#define BMCR_FULLDPLX 0x0100 /* Full duplex */ +#define BMCR_ANRESTART 0x0200 /* Auto negotiation restart*/ +#define BMCR_ISOLATE0x0400 /* Disconnect DP83840 from MII */ +#define BMCR_PDOWN 0x0800 /* Powerdown the DP83840 */ +#define BMCR_ANENABLE 0x1000 /* Enable auto negotiation */ +#define
Re: [U-Boot] USB cardreader issue
Hi, I am trying to read images from SD cards attached to a USB card reader. usb start command shows errors as per logs copied below. I tested with uboot version 2009.11 and will try with latest Uboot and update the results. Ajay Is there any known issue in supporting usb card readers In general or it's compatibility issue with few card readers? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
This patch introduces an extra mask-field in spansion_spi_flash_params to support flash chips with 1-byte extended ID (like the S25FL032P). Signed-off-by: David Jander da...@protonic.nl The extension ID has been checked with the datasheet. http://www.spansion.com/Support/Datasheets/S25FL032P_00_05_e.pdf at Table 9.2 Manufacturer Device ID - RDID (JEDEC 9Fh): # Extended bytes: byte 3: 4Dh However S25FL128P series has 2 extended bytes. http://www.spansion.com/Support/Datasheets/S25FL128P_00_08_e.pdf --- drivers/mtd/spi/spansion.c | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) +#define SPSN_EXT_ID_S25FL032P 0x4d00 -- Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91rm9200: fix lowlevel_init() SMRDATA size
SMRDATA in a/a/c/arm920t/at91/lowlevel_init.c has wrong size. This patch reduces it to correct size of 40 byte. Signed-off-by: Andreas Bießmann biessm...@corscience.de --- Dear all, I thougt about a problem in lowlevel_init() cause of errornous booting from NOR flash on at91rm9200ek last night . This morning I detected this, but the patch is untested! I can not test it til sunday, if one can test it before please send a mail (Jens?). regards Andreas Bießmann arch/arm/cpu/arm920t/at91/lowlevel_init.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/arm920t/at91/lowlevel_init.S b/arch/arm/cpu/arm920t/at91/lowlevel_init.S index eaea9d2..6e397c2 100644 --- a/arch/arm/cpu/arm920t/at91/lowlevel_init.S +++ b/arch/arm/cpu/arm920t/at91/lowlevel_init.S @@ -65,7 +65,7 @@ LoopOsc: ldr r0, =SMRDATA ldr r1, _MTEXT_BASE sub r0, r0, r1 - add r2, r0, #80 + add r2, r0, #40 pllloop: /* the address */ ldr r1, [r0], #4 -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
