Re: [U-Boot] [PATCH] TRATS: Fix uart gpio config
Dear Chander Kashyap,
On 25 January 2012 14:25, Chander Kashyap wrote:
> It updates the missing gpio configuration of UART port.
>
> Signed-off-by: Chander Kashyap
> Cc: HeungJun, Kim
> ---
> board/samsung/trats/trats.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
> index f795ff0..4c9773d 100644
> --- a/board/samsung/trats/trats.c
> +++ b/board/samsung/trats/trats.c
> @@ -337,7 +337,7 @@ static void board_uart_init(void)
> int i;
>
> /* UART0-UART1 GPIOs (part1) : 0x */
> - for (i = 0; i < 7; i++) {
> + for (i = 0; i < 8; i++) {
> s5p_gpio_set_pull(&gpio1->a0, i, GPIO_PULL_NONE);
> s5p_gpio_cfg_pin(&gpio1->a0, i, GPIO_FUNC(0x2));
> }
> @@ -347,7 +347,7 @@ static void board_uart_init(void)
> * GPA1CON[3] = I2C_3_SCL (3)
> * GPA1CON[2] = I2C_3_SDA (3)
> */
> - for (i = 0; i < 5; i++) {
> + for (i = 0; i < 6; i++) {
> s5p_gpio_set_pull(&gpio1->a1, i, GPIO_PULL_NONE);
> s5p_gpio_cfg_pin(&gpio1->a1, i,
> GPIO_FUNC((i == 2 || i == 3) ? 0x3 : 0x2));
> --
Actually we don't have to set all of UARTs.
Because, we only use UART2 for serial.
I will post new patch for it.
Thanks
Minkyu Kang.
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support
Hi Marek, On 01/26/2012 04:59 AM, Marek Vasut wrote: >> This patch series add support for new board Nokia RX-51 (aka N900). >> Last two patches adding on screen bootmenu support. > > Isn't on-screen bootmenu already supported by common/menu.c stuff ? >> >> This series supersedes the last sent version. > > So ... this is V2? What are the changes from previous version of the series? > Please read Submitting patches on the wiki next time. I've been through the revision/submission for this series extensively off-list with Pali in order to attempt to fix-up the initial revision non-compliance issues (as well as commit messages, trivial style issues etc) It got to the point were maintaining the revision history consistent with the previous series was a bit of a 'train wreck' so let's all forget about it (call the last lot an RFC) and move on :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/28] Add link-local addressing support
On 26/01/2012 00:40, Joe Hershberger wrote: >> I have a basic question about your patchset. RFC3927 requires that >> addresses are continuosly checked to avoid conflicts - this is a strict >> requirement. > > True. It cannot be 100% compliant in every use-case. It is important that these limitations are well documented > Any time we are processing NetLoop, we will handle conflict correctly. Yes, but NetLoop is running only when there some activity on the network. > In the case of actually doing something on the network, (generally > happens at least some of the time the device is on the network) > conflicts are monitored for. In the use case for the devices I use > this on, I also run NetConsole, which means the NetLoop is always > being run. In that case, it is compliant with the RFC. Right - I think this is the best case. > >> I can imagine we can get conflicts, when several targets are running at >> the same time in u_boot and they are attached to a network where >> local-link addressing is active. Then we can have two or more system >> using the same ip address, making the network unreliable. > > That is true. I believe there are some cases you could contrive that > could allow a device to pick the same address as another device, but > it is quite unlikely. Initial address selections are based on > MAC-seeded random number, making it hard to get a conflicting address > in general. It depends on the number of devices attached to the network - in a small environment, it is not probable. Anyway, if we document well how this feature should be used and which are the limitations, anybody is warned about its usage and about the best conditions to run the feature. > >> Which are the limitations of this implementation ? They should also >> described in your patchset, maybe with a README file. Is is thought to >> connect the target directly to a PC ? > > The most likely use-case is connecting directly to a PC, I have supposed also this is the best use-case. > but it also > works on any generic network. I added documentation to the README. Ok - please add a separate file doc/README.link-local (or whatever filename you want) Best regards, Stefano Babic -- = 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
[U-Boot] [RFC Patch] e1000: Fix PCI memory addressing and fix for receive data polling
Hi all, I had some problem when using your e1000-code on a MIPS target. Attached you will find two fixes which I would like to propose for discussion. - Fix 1: this has the same reason as in commit f81ecb5d3300bf92d17302d3712f30585c182da9 - Fix 2: has to do with "C Language Operator Precedence". I would say the expression taken by the ! operator has precedence before the & operator. So any bit in rd->status other than E1000_RXD_STAT_DD stops correct detection of data reception. (What i do not know is, if it is possible that any other bit than E1000_RXD_STAT_DD can get active) Please leave me in CC, because i'm not subscribed to this list. Thanks a lot for providing u-boot. Best regards Ralf -- Roesch & Walter___ Industrie-Elektronik GmbH * Tel.: +49-7824 / 6628-0 Wörtelweg 2b/c* Fax: +49-7824 / 6628-29 D-77963 Schwanau * mailto:ralf.roe...@rw-gmbh.de Germany * WWW: http://www.rw-gmbh.de Amtsgericht Freiburg i.Br. HRB 391345 Geschäftsführer: Dipl.Ing.(FH) Ralf Rösch, Dipl.Ing.(FH) Martin Walter GnuPG key: 52ECD70F 2010-09-04 [expires: 2012-12-31] Fingerprint: 8415 9113 5F05 D579 6685 D5AD 5CE7 5429 52EC D70F ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
>> My 'fix' as it is now, doesn't fix any real problem. It's not finished yet. >> As it looks now, it makes the JTAG connection unreliable. Data is getting >> corrupted when it's read or written. However, the system no longer hangs >> up itself. > > That IS a progress. Progress is made, but no completely working solution is found yet. I've just found out that registers hw_clkctrl_frac0 and hw_clkctrl_frac1 should be accessed as bytes only. It's in the manual (page 886 and 887), but I completely missed that the first 10 times. We access hw_clkctrl_frac0 as a word, though I doubt if this has any serious consequences. >> I will post a patch when I've found a working solution. It's in my best >> interest to have it tested and reviewed by you guys, as you understand the >> clock tree of this SoC a lot better than I. Besides that, I'd like to have >> it in the mainline as well, so we don't have to maintain our patches. > > But we can also test and review the current solution ;-) I hope I can offer a patch up for review later today, but definitely before the end of the week. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC Patch] e1000: Fix PCI memory addressing and fix for receive data polling
Sorry, you will find now my fixes in attachment
Hi all,
I had some problem when using your e1000-code on a MIPS target.
Attached you will find two fixes which I would like to propose for
discussion.
- Fix 1: this has the same reason as in commit
f81ecb5d3300bf92d17302d3712f30585c182da9
- Fix 2: has to do with "C Language Operator Precedence".
I would say the expression taken by the ! operator has precedence before
the & operator.
So any bit in rd->status other than E1000_RXD_STAT_DD stops correct
detection of data reception.
(What i do not know is, if it is possible that any other bit than
E1000_RXD_STAT_DD can get active)
Please leave me in CC, because i'm not subscribed to this list.
Thanks a lot for providing u-boot.
Best regards
Ralf
--
Roesch & Walter___
Industrie-Elektronik GmbH * Tel.: +49-7824 / 6628-0
Wörtelweg 2b/c* Fax: +49-7824 / 6628-29
D-77963 Schwanau * mailto:ralf.roe...@rw-gmbh.de
Germany * WWW: http://www.rw-gmbh.de
Amtsgericht Freiburg i.Br. HRB 391345
Geschäftsführer: Dipl.Ing.(FH) Ralf Rösch, Dipl.Ing.(FH) Martin Walter
GnuPG key: 52ECD70F 2010-09-04 [expires: 2012-12-31]
Fingerprint: 8415 9113 5F05 D579 6685 D5AD 5CE7 5429 52EC D70F
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index e726f39..293ff1d 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4837,7 +4837,7 @@ fill_rx(struct e1000_hw *hw)
rd = rx_base + rx_tail;
rx_tail = (rx_tail + 1) % 8;
memset(rd, 0, 16);
- rd->buffer_addr = cpu_to_le64((u32) & packet);
+ rd->buffer_addr = cpu_to_le64(virt_to_bus(hw->pdev, packet));
E1000_WRITE_REG(hw, RDT, rx_tail);
}
@@ -5020,7 +5020,7 @@ e1000_poll(struct eth_device *nic)
struct e1000_rx_desc *rd;
/* return true if there's an ethernet packet ready to read */
rd = rx_base + rx_last;
- if (!(le32_to_cpu(rd->status)) & E1000_RXD_STAT_DD)
+ if (!(le32_to_cpu(rd->status) & E1000_RXD_STAT_DD))
return 0;
/*DEBUGOUT("recv: packet len=%d \n", rd->length); */
NetReceive((uchar *)packet, le32_to_cpu(rd->length));
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TRATS: set gpio of UART correctly
Signed-off-by: Minkyu Kang
Signed-off-by: HeungJun, Kim
Cc: Chander Kashyap
---
board/samsung/trats/trats.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index f795ff0..aa4291d 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -336,21 +336,17 @@ static void board_uart_init(void)
(struct exynos4_gpio_part2 *)samsung_get_base_gpio_part2();
int i;
- /* UART0-UART1 GPIOs (part1) : 0x */
- for (i = 0; i < 7; i++) {
- s5p_gpio_set_pull(&gpio1->a0, i, GPIO_PULL_NONE);
- s5p_gpio_cfg_pin(&gpio1->a0, i, GPIO_FUNC(0x2));
- }
-
/*
-* UART2-UART3 GPIOs (part2) : 0x00223322
-* GPA1CON[3] = I2C_3_SCL (3)
+* UART2 GPIOs
+* GPA1CON[0] = UART_2_RXD(2)
+* GPA1CON[1] = UART_2_TXD(2)
* GPA1CON[2] = I2C_3_SDA (3)
+* GPA1CON[3] = I2C_3_SCL (3)
*/
- for (i = 0; i < 5; i++) {
+
+ for (i = 0; i < 4; i++) {
s5p_gpio_set_pull(&gpio1->a1, i, GPIO_PULL_NONE);
- s5p_gpio_cfg_pin(&gpio1->a1, i,
- GPIO_FUNC((i == 2 || i == 3) ? 0x3 : 0x2));
+ s5p_gpio_cfg_pin(&gpio1->a1, i, GPIO_FUNC((i > 1) ? 0x3 : 0x2));
}
/* UART_SEL GPY4[7] (part2) at EXYNOS4 */
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] net: ll_temac: Add LL TEMAC driver to u-boot
Hi Stephan, Stephan Linz wrote: Xilinx LocalLink Tri-Mode Ether MAC driver can be used by Xilinx Microblaze or Xilinx ppc405/440 in SDMA and FIFO mode. DCR or XPS bus can be used. The driver uses and requires MII and PHYLIB. CP: 4 warnings: 'Use of volatile is usually wrong' I won't fix this, because it depends on the network driver subsystem. Signed-off-by: Stephan Linz --- v9: Remove private Rx/Tx transfer buffer for SDMA and FIFO. Use the PktBuf infrastruct from upper network layer. Review all the recv/send functions for SDMA and FIFO mode and insert more detailed comments. Test with tftp put/get on ML605 and SP3ADSP1800. v8: Remove deprecated interface: miiphy_register() Implement MDIO bus/phy access code as independent part of driver. Make the direct PHY access code accessible for upper layer like the MDIO command. Define proper device names for TEMAC and MII interfaces. Support of TEMAC0 and TEMAC1 at same time is prepared and should work. v7: Call udelay() in polling loops to avoid unintended watchdog reset Define well known timeout values in usec Handle timeouts as error situations Reduce duplicated code in SDMA operations Add a real and plausible PHY detect mask Remove ETH_HALTING code exclusion Code cleanup as recommended Fix typos v6: Code cleanup with ./tools/checkpatch.pl v5: Remove more endless loops Remove useless parenthesis in pointer operations Move phyaddr predefinition on top Remove supernumerary newlines Remove parenthesis around numbers (globally) v4: Separate fifo and sdma code from driver core Split sdma code into separate DCR and XPS bus access code Add extensive register struct definitions and enumerations Add new callbacks into fifo an sdma code Prepare CDMAC buffer handling to be unique for every instance Separate Xilinx specific indirect DCR access, so we can move to arch Remove useless 'emac' parameter from indirect access helper functions Correct MDIO clock setup. Remove endless loops Common code beautifying v3: Use helper functions for fifo mode Use helper functions for indirect accesses Code cleanup Add comments for MAGIC values Simplify code in fifo mode v2: Remove helper function for access to temac Remove SDMA/FIFO/DCR macros and configure it in board Setup mac by write_hwaddr --- drivers/net/Makefile |2 + drivers/net/xilinx_ll_temac.c | 386 drivers/net/xilinx_ll_temac_fifo.c | 143 drivers/net/xilinx_ll_temac_mdio.c | 165 ++ drivers/net/xilinx_ll_temac_sdma.c | 370 +++ include/netdev.h |1 + include/xilinx_ll_temac.h | 430 include/xilinx_ll_temac_fifo.h | 122 ++ include/xilinx_ll_temac_mdio.h | 53 + include/xilinx_ll_temac_sdma.h | 281 +++ 10 files changed, 1953 insertions(+), 0 deletions(-) create mode 100644 drivers/net/xilinx_ll_temac.c create mode 100644 drivers/net/xilinx_ll_temac_fifo.c create mode 100644 drivers/net/xilinx_ll_temac_mdio.c create mode 100644 drivers/net/xilinx_ll_temac_sdma.c create mode 100644 include/xilinx_ll_temac.h create mode 100644 include/xilinx_ll_temac_fifo.h create mode 100644 include/xilinx_ll_temac_mdio.h create mode 100644 include/xilinx_ll_temac_sdma.h Wolfgang: I just wanted to know what it is the rule for adding headers. I would prefer to add these headers to drivers/net/ folder instead include. diff --git a/drivers/net/Makefile b/drivers/net/Makefile index f4f7ea3..430f90c 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -77,6 +77,8 @@ COBJS-$(CONFIG_ULI526X) += uli526x.o COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o COBJS-$(CONFIG_XILINX_AXIEMAC) += xilinx_axi_emac.o COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o +COBJS-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o xilinx_ll_temac_mdio.o \ + xilinx_ll_temac_fifo.o xilinx_ll_temac_sdma.o COBJS := $(sort $(COBJS-y)) SRCS := $(COBJS:.o=.c) diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.c new file mode 100644 index 000..7124561 --- /dev/null +++ b/drivers/net/xilinx_ll_temac.c @@ -0,0 +1,386 @@ +/* + * Xilinx xps_ll_temac ethernet driver for u-boot + * + * supports SDMA or FIFO access and MDIO bus communication + * + * Copyright (C) 2011 - 2012 Stephan Linz + * Copyright (C) 2008 - 2011 Michal Simek + * Copyright (C) 2008 - 2011 PetaLogix + * + * Based on Yoshio Kashiwagi kashiw...@co-nss.co.jp driver + * Copyright (C) 2008 Nissin Systems Co.,Ltd. + * March 2008 created + * + * 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)
Re: [U-Boot] [RFC Patch] e1000: Fix PCI memory addressing and fix for receive data polling
On 26/01/2012 14:19, Ralf Rösch wrote: > Sorry, you will find now my fixes in attachment > > Hi all, Hi Ralf, > > I had some problem when using your e1000-code on a MIPS target. > Attached you will find two fixes which I would like to propose for > discussion. > > - Fix 1: this has the same reason as in commit > f81ecb5d3300bf92d17302d3712f30585c182da9 Anyway, can you also describe *which* bug / behavior have you found ? > - Fix 2: has to do with "C Language Operator Precedence". > I would say the expression taken by the ! operator has precedence before > the & operator. > So any bit in rd->status other than E1000_RXD_STAT_DD stops correct > detection of data reception. > (What i do not know is, if it is possible that any other bit than > E1000_RXD_STAT_DD can get active) This seems to me a bug. However, you must send right patches for review / discussion. You find two issues, and you must send one patch for each issue that will be fixed. Please have a look at: http://www.denx.de/wiki/U-Boot/Patches It describes how to submit patches in the right format. Best regards, Stefano Babic -- = 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
[U-Boot] changes in uEnv.txt does not work
Hi,
I am Manish and i have recently started working on beagleboard xm.
I am facing certain issues. Need guidance to solve it.
Background:
I am using beagleboard xm, uboot version 9 of 2011
Intention:
Current version of uboot has the environment variable loaduimage set for
ext3 partition.Now i want the uboot to pick the uimage from fat partition.
I can do it by modifying the uboot code and use the rebuilt uboot but i
want to remove dependency on building uboot for future version. So i was
trying to play around with uEnv.txt
Exercise:
Initially i tried to update loaduimage to fatload mmc ${mmcdev} ${loadaddr}
uImage and tried booting but was unsuccessful.
I tried to uncover the problem by echo statements to track the code flow.
I observed that the
1.Same command works when i change the omap3_beagle.h and rebuild the uboot
but it does not work if i change it using uEnv.txt.
2.Also that the error is returned from mmcboot->bootm command saying the
image is in wrong format. But i am using the same image as in case 1.
Can some on guide me how do i achive this. I want to use uEnv.txt for
better maintanibilty
Manish Kanchan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support
On Wed, Jan 25, 2012 at 11:00:34PM +0100, Marek Vasut wrote: > > On Wednesday 25 January 2012 22:29:16 Marek Vasut wrote: > > > > On Wednesday 25 January 2012 21:56:37 Marek Vasut wrote: > > > > > > On Wednesday 25 January 2012 19:20:01 Marek Vasut wrote: > > > > > > > So why not just replace the bootloader right away? > > > > > > > > > > > > Booting process on n900: > > > > > > 1. Omap bootrom > > > > > > 2. Nokia X-Loader > > > > > > 3. Nokia NOLO Bootloader > > > > > > 4. Linux kernel > > > > > > ... > > > > > > > > > > To make it clear, I own N900 myself ;-) > > > > > > > > > > > Nokia X-Loader and NOLO are stored in first nand part. It has size > > > > > > 128kB. Nokia X-Loader is signed (size 14.5kB), so cannot be > > > > > > replaced. NOLO bootloader is not signed (so theoretically can be > > > > > > replaced), but size is limited to 113kB. I do not know how to > > > > > > compile U-Boot binary with size < 113kB... > > > > > > > > > > > > Size of part where is stored linux kernel has 2MB and it is enought > > > > > > for > > > > > > U-Boot with kernel image (~200kB + ~1.6MB). Also U-Boot can boot > > > > > > kernel > > > > > > from eMMC/SD. > > > > > > > > > > You didn't answer my question, so again ... why can't you replace > > > > > NOLO? Because there's the 113kb limit? Use SPL then. > > > > > > > > I only tried to boot U-Boot in qemu wich increased boot part - but not > > > > worked. (NOLO in qemu can boot u-boot without problems). So NOLO do > > > > some extra work - which I do not know... Also limit is problem to test > > > > on real n900. > > > > > > What do you mean? Did you crack yours open? Can you connect JTAG to the > > > device? I didn't check on mine. > > > > I have no idea if N900 has JTAG. And I think that nobody cracked X-Loader > > yet. > > What do you mean, you don't need xloader, u-boot SPL can replace it. Yes and no. No, becaue you nor I have no Nokia's signing key(s) to sign SPL binary for OMAP's secure boot ROM. IIRC N950/N9 is even more strict regarding that, am I right? > > > > NOLO bootloader can be replaced/flashed via flasher-3.5 app throw USB. Also > > when NOLO is damaged (or cleared/replaced) it can restored - coldflashed > > again via flasher-3.5. > > I know. So ... ? Basically you can use the TI flashes too since it all goes > through the bootrom, right? Butrom requires signed binary. > > > > What I tried: > > I created mtd image where was X-Loader, NOLO and U-Boot. QEmu RX51 > > successfull booted this image and I got serial console and video screen > > output. > > > > But when I created mtd image where was only X-Loader an U-Boot, QEmu RX51 > > was unable to boot (it freezed). > > Why? Where? You know you can debug U-Boot in QEMU with GDB and diag the > problem > properly? Any volunteers? (I own N900 too, ah, I own 3 of tham, damnit) > > > > > So NOLO executing some code which inilialize board or someting else which > > must be done in U-Boot board code. There is no documentation or info about > > NOLO, so I cannot create working NOLO replacement. > > Yes you can, either observe it or disas it. > > M All the best, S. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support
On Thursday 26 January 2012 11:25:59 Sergey Lapin wrote: > On Wed, Jan 25, 2012 at 11:00:34PM +0100, Marek Vasut wrote: > > > > What do you mean, you don't need xloader, u-boot SPL can replace it. > > Yes and no. No, becaue you nor I have no Nokia's signing key(s) to sign > SPL binary for OMAP's secure boot ROM. IIRC N950/N9 is even more strict > regarding that, am I right? You are right, we cannot sign SPL binary for N900 because we do not have key. Signing key has only somebody in Nokia (or in TI). I do not have N950/N9 so I do not know anything about new devices. > > > > I know. So ... ? Basically you can use the TI flashes too since it all > > goes > > through the bootrom, right? > > Butrom requires signed binary. > Yes and format of signed binary is not published by TI (there are only some RE info about Motorola Omap devices). > > > What I tried: > > > I created mtd image where was X-Loader, NOLO and U-Boot. QEmu RX51 > > > successfull booted this image and I got serial console and video screen > > > output. > > > > > > But when I created mtd image where was only X-Loader an U-Boot, QEmu > > > RX51 > > > was unable to boot (it freezed). > > > > Why? Where? You know you can debug U-Boot in QEMU with GDB and diag the > > problem properly? > > Any volunteers? (I own N900 too, ah, I own 3 of tham, damnit) > I can try to play with SPL U-Boot binary and X-Loader in qemu. But this and next month I do not have time for it... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/14] New config variable CONFIG_MENUCMD
On Wednesday 25 January 2012 21:53:02 Marek Vasut wrote: > > On Wednesday 25 January 2012 19:12:29 Marek Vasut wrote: > > > So this is just to interrupt autoboot? Why not just report the "menukey" > > > as any other keypress and do it that way? > > > > Usefull for interrupt autoboot and run some menu (script/booting) only > > with > > specific key (for example with key M on device keyboard). > > what's the difference between this and CONFIG_MENUKEY? See commit message CONFIG_MENUCMD define if U-Boot will run env variable "menucmd" CONFIG_MENUKEY define if some key must be pressed (and which) to run "menucmd" -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support
> On Wed, Jan 25, 2012 at 11:00:34PM +0100, Marek Vasut wrote: > > > On Wednesday 25 January 2012 22:29:16 Marek Vasut wrote: > > > > > On Wednesday 25 January 2012 21:56:37 Marek Vasut wrote: > > > > > > > On Wednesday 25 January 2012 19:20:01 Marek Vasut wrote: > > > > > > > > So why not just replace the bootloader right away? > > > > > > > > > > > > > > Booting process on n900: > > > > > > > 1. Omap bootrom > > > > > > > 2. Nokia X-Loader > > > > > > > 3. Nokia NOLO Bootloader > > > > > > > 4. Linux kernel > > > > > > > ... > > > > > > > > > > > > To make it clear, I own N900 myself ;-) > > > > > > > > > > > > > Nokia X-Loader and NOLO are stored in first nand part. It has > > > > > > > size 128kB. Nokia X-Loader is signed (size 14.5kB), so cannot > > > > > > > be replaced. NOLO bootloader is not signed (so theoretically > > > > > > > can be replaced), but size is limited to 113kB. I do not know > > > > > > > how to compile U-Boot binary with size < 113kB... > > > > > > > > > > > > > > Size of part where is stored linux kernel has 2MB and it is > > > > > > > enought for > > > > > > > U-Boot with kernel image (~200kB + ~1.6MB). Also U-Boot can > > > > > > > boot kernel > > > > > > > from eMMC/SD. > > > > > > > > > > > > You didn't answer my question, so again ... why can't you replace > > > > > > NOLO? Because there's the 113kb limit? Use SPL then. > > > > > > > > > > I only tried to boot U-Boot in qemu wich increased boot part - but > > > > > not worked. (NOLO in qemu can boot u-boot without problems). So > > > > > NOLO do some extra work - which I do not know... Also limit is > > > > > problem to test on real n900. > > > > > > > > What do you mean? Did you crack yours open? Can you connect JTAG to > > > > the device? I didn't check on mine. > > > > > > I have no idea if N900 has JTAG. And I think that nobody cracked > > > X-Loader yet. > > > > What do you mean, you don't need xloader, u-boot SPL can replace it. > > Yes and no. No, becaue you nor I have no Nokia's signing key(s) to sign > SPL binary for OMAP's secure boot ROM. IIRC N950/N9 is even more strict > regarding that, am I right? Yea ... I was explained later how messed up it is ... so it'd probably be for the best now to replace NOLO with U-Boot SPL. M > > > > NOLO bootloader can be replaced/flashed via flasher-3.5 app throw USB. > > > Also when NOLO is damaged (or cleared/replaced) it can restored - > > > coldflashed again via flasher-3.5. > > > > I know. So ... ? Basically you can use the TI flashes too since it all > > goes through the bootrom, right? > > Butrom requires signed binary. > > > > What I tried: > > > I created mtd image where was X-Loader, NOLO and U-Boot. QEmu RX51 > > > successfull booted this image and I got serial console and video screen > > > output. > > > > > > But when I created mtd image where was only X-Loader an U-Boot, QEmu > > > RX51 was unable to boot (it freezed). > > > > Why? Where? You know you can debug U-Boot in QEMU with GDB and diag the > > problem properly? > > Any volunteers? (I own N900 too, ah, I own 3 of tham, damnit) > > > > So NOLO executing some code which inilialize board or someting else > > > which must be done in U-Boot board code. There is no documentation or > > > info about NOLO, so I cannot create working NOLO replacement. > > > > Yes you can, either observe it or disas it. > > > > M > > All the best, > S. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support
> On Thursday 26 January 2012 11:25:59 Sergey Lapin wrote: > > On Wed, Jan 25, 2012 at 11:00:34PM +0100, Marek Vasut wrote: > > > What do you mean, you don't need xloader, u-boot SPL can replace it. > > > > Yes and no. No, becaue you nor I have no Nokia's signing key(s) to sign > > SPL binary for OMAP's secure boot ROM. IIRC N950/N9 is even more strict > > regarding that, am I right? > > You are right, we cannot sign SPL binary for N900 because we do not have > key. Signing key has only somebody in Nokia (or in TI). I do not have > N950/N9 so I do not know anything about new devices. > > > > I know. So ... ? Basically you can use the TI flashes too since it all > > > goes > > > through the bootrom, right? > > > > Butrom requires signed binary. > > Yes and format of signed binary is not published by TI (there are only some > RE info about Motorola Omap devices). > > > > > What I tried: > > > > I created mtd image where was X-Loader, NOLO and U-Boot. QEmu RX51 > > > > successfull booted this image and I got serial console and video > > > > screen output. > > > > > > > > But when I created mtd image where was only X-Loader an U-Boot, QEmu > > > > RX51 > > > > was unable to boot (it freezed). > > > > > > Why? Where? You know you can debug U-Boot in QEMU with GDB and diag the > > > problem properly? > > > > Any volunteers? (I own N900 too, ah, I own 3 of tham, damnit) > > I can try to play with SPL U-Boot binary and X-Loader in qemu. But this and > next month I do not have time for it... You're just lazy ... what exam can take you so much time ? :-p ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Wed, Jan 25, 2012 at 1:06 PM, wilsonjonathan wrote: > The u-boot loader is showing an incorrect size in the memory, and > passing the invalid information to the kernel. What revision of the board do you have? Is this a 'classic' rev C4? Thanks. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question regarding NAND environment
I'm trying to have a robust environment stored in NAND, and three blocks of space available to store it in. Looking at the REDUND code, I see it only keeps two copies of the environment regardless of the amount of space available. Instead I'm looking to use CONFIG_ENV_RANGE to handle the extra blocks. Can/does the code save multiple copies of the environment across the three blocks, and can readenv read copies of the environment (skipping bad blocks) until it finds one good environment? I'm trying to prevent any corruption from happening if (unlikely but possible) power fails while saving the environment. In my case the environment is 32K and each block is 128K, so I should be able to write six copies into NAND (if all three blocks are good), and if one block then goes bad I can still erase one of the other blocks (while the other remaining good block holds at least one valid copy of the environment). If u-boot doesn't do this currently is there any interest in a patch for such? -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question regarding NAND environment
On 01/26/2012 11:05 AM, Peter Barada wrote: > I'm trying to have a robust environment stored in NAND, and three blocks > of space available to store it in. > > Looking at the REDUND code, I see it only keeps two copies of the > environment regardless of the amount of space available. Instead I'm > looking to use CONFIG_ENV_RANGE to handle the extra blocks. CONFIG_ENV_RANGE and CONFIG_ENV_*_REDUND are orthogonal, not alternatives. > Can/does the code save multiple copies of the environment across the > three blocks, No. Its purpose is to provide room to skip blocks that are formally marked as bad. If you want REDUND with more than two copies, you'll have to modify the REDUND code to support that. > and can readenv read copies of the environment (skipping > bad blocks) until it finds one good environment? I'm trying to prevent > any corruption from happening if (unlikely but possible) power fails > while saving the environment. Why are two copies insufficient for that? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question regarding NAND environment
On 01/26/2012 12:27 PM, Scott Wood wrote: > On 01/26/2012 11:05 AM, Peter Barada wrote: >> I'm trying to have a robust environment stored in NAND, and three blocks >> of space available to store it in. >> >> Looking at the REDUND code, I see it only keeps two copies of the >> environment regardless of the amount of space available. Instead I'm >> looking to use CONFIG_ENV_RANGE to handle the extra blocks. > CONFIG_ENV_RANGE and CONFIG_ENV_*_REDUND are orthogonal, not alternatives. > >> Can/does the code save multiple copies of the environment across the >> three blocks, > No. Its purpose is to provide room to skip blocks that are formally > marked as bad. > > If you want REDUND with more than two copies, you'll have to modify the > REDUND code to support that. > >> and can readenv read copies of the environment (skipping >> bad blocks) until it finds one good environment? I'm trying to prevent >> any corruption from happening if (unlikely but possible) power fails >> while saving the environment. > Why are two copies insufficient for that? Two copies are sufficient, if none of the blocks ever go bad. To simplify things, suppose the environment is the same size as a block and you have only two blocks (and two copies) to hold the environment. If one block goes bad then there is a window between when the one remaining block is erased and written with the environment that if power fails then there is no environment in NAND. To solve this I can crank up the number of blocks to three which allows one block to go bad and still at all times have one good copy of the environment in NAND. But looking at writeenv(), it stops as soon as either nand_write fails, or one copy of the environment is written. So it could make sense to modify writeenv to write as many copies of the environment that fit into CONFIG_ENV_RANGE, and have readenv read out copies and verify them until it finds one good one. To prevent a "buried update", the order of reads/writes (by either u-boot or u-boot-tools in Linux) would have to be in the same order. Then if power fails while writing, either no valid data was written (while still having a copy of the previous good environment in a following block of NAND), or at least one new copy is written and on the next reboot u-boot will find it. I guess what I'm proposing to is much like REDUND, but I think more flexible... -- Peter Barada peter.bar...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] USB: Armada100: ECHI Driver for Armada100 SOCs
> -Original Message-
> From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com]
> Sent: 25 January 2012 17:50
> To: li...@bohmer.net
> Cc: Prafulla Wadaskar; marek.va...@gmail.com; u-boot@lists.denx.de;
> Ajay Bhargav
> Subject: [PATCH 2/3] USB: Armada100: ECHI Driver for Armada100 SOCs
>
> This patch adds support for USB EHCI driver for Armada100 SOCs.
>
> Signed-off-by: Ajay Bhargav
> ---
> arch/arm/include/asm/arch-armada100/armada100.h |1 +
> drivers/usb/host/Makefile |1 +
> drivers/usb/host/ehci-armada100.c | 62
> +++
> 3 files changed, 64 insertions(+), 0 deletions(-)
> create mode 100644 drivers/usb/host/ehci-armada100.c
>
> diff --git a/arch/arm/include/asm/arch-armada100/armada100.h
> b/arch/arm/include/asm/arch-armada100/armada100.h
> index d6984dc..26f836e 100644
> --- a/arch/arm/include/asm/arch-armada100/armada100.h
> +++ b/arch/arm/include/asm/arch-armada100/armada100.h
> @@ -67,6 +67,7 @@
> #define ARMD1_SSP5_BASE 0xD4021000
> #define ARMD1_UART3_BASE 0xD4026000
> #define ARMD1_MPMU_BASE 0xD405
> +#define ARMD1_USB_HOST_BASE 0xD4209000
> #define ARMD1_APMU_BASE 0xD4282800
> #define ARMD1_CPU_BASE 0xD4282C00
>
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 77e217f..94e72c3 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -35,6 +35,7 @@ COBJS-$(CONFIG_USB_SL811HS) += sl811-hcd.o
>
> # echi
> COBJS-$(CONFIG_USB_EHCI) += ehci-hcd.o
> +COBJS-$(CONFIG_USB_EHCI_ARMADA100) += ehci-armada100.o utmi-
> armada100.o
> ifdef CONFIG_MPC512X
> COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-mpc512x.o
> else
> diff --git a/drivers/usb/host/ehci-armada100.c
> b/drivers/usb/host/ehci-armada100.c
> new file mode 100644
> index 000..cf05d1a
> --- /dev/null
> +++ b/drivers/usb/host/ehci-armada100.c
> @@ -0,0 +1,62 @@
> +/*
> + * (C) Copyright 2012
> + * eInfochips Ltd.
> + * Written-by: Ajay Bhargav
> + *
> + * This driver is based on Kirkwood echi driver
> + * (C) Copyright 2009
> + * Marvell Semiconductor
> + * Written-by: Prafulla Wadaskar
> + *
> + * 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
> +#include
> +#include
> +#include "ehci.h"
> +#include "ehci-core.h"
> +#include
> +#include
> +#include "utmi-armada100.h"
> +
> +/*
> + * EHCI host controller init
> + */
> +int ehci_hcd_init(void)
> +{
> + utmi_init();
> + hccr = (struct ehci_hccr *)(ARMD1_USB_HOST_BASE + 0x100);
> + hcor = (struct ehci_hcor *)((uint32_t) hccr
> + + HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
> +
> + printf("Kirkwood-ehci: init hccr %x and hcor %x hc_length %d\n",
Wrong printf message, it's not Kirkwood.
Regards..
Prafulla . . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] USB: Armada100: Add UTMI PHY interface driver
> -Original Message- > From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com] > Sent: 25 January 2012 17:50 > To: li...@bohmer.net > Cc: Prafulla Wadaskar; marek.va...@gmail.com; u-boot@lists.denx.de; > Ajay Bhargav > Subject: [PATCH 1/3] USB: Armada100: Add UTMI PHY interface driver > > This patch adds USB host controller's UTMI PHY interface driver for > Armada100 SOCs. > > Signed-off-by: Ajay Bhargav > --- > arch/arm/include/asm/arch-armada100/armada100.h |7 ++ > drivers/usb/host/utmi-armada100.c | 87 > +++ > drivers/usb/host/utmi-armada100.h | 79 > > 3 files changed, 173 insertions(+), 0 deletions(-) > create mode 100644 drivers/usb/host/utmi-armada100.c > create mode 100644 drivers/usb/host/utmi-armada100.h > > diff --git a/arch/arm/include/asm/arch-armada100/armada100.h > b/arch/arm/include/asm/arch-armada100/armada100.h > index 0ed3a8e..d6984dc 100644 > --- a/arch/arm/include/asm/arch-armada100/armada100.h > +++ b/arch/arm/include/asm/arch-armada100/armada100.h > @@ -43,6 +43,13 @@ > #define SSP2_APBCLK 0x01 > #define SSP2_FNCLK 0x02 > > +/* USB Clock/reset control bits */ > +#define USB_SPH_AXICLK_EN0x10 > +#define USB_SPH_AXI_RST 0x02 > + > +/* MPMU Clocks */ > +#define MPMU_EN_ALL_CLKS 0x1E Turning on all clocks is not logical to enable this support, only relevant clock necessary for this components SHOULD BE enabled. Enabling clocks for unused peripherals/components may result in unnecessarily extra power consumption Otherwise ack for rest of the patch Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Armada100: gplugD: Add USB command support
> -Original Message- > From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com] > Sent: 25 January 2012 17:50 > To: li...@bohmer.net > Cc: Prafulla Wadaskar; marek.va...@gmail.com; u-boot@lists.denx.de; > Ajay Bhargav > Subject: [PATCH 3/3] Armada100: gplugD: Add USB command support > > This patch adds support for USB commands and USB storage device for > Marvell gplugD > > Signed-off-by: Ajay Bhargav > --- > include/configs/gplugd.h | 17 + > 1 files changed, 17 insertions(+), 0 deletions(-) > > diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h > index 9813309..f8dc74f 100644 > --- a/include/configs/gplugd.h > +++ b/include/configs/gplugd.h > @@ -134,4 +134,21 @@ > #define CONFIG_CMD_EDITENV > #define CONFIG_CMD_SAVEENV > > +#define CONFIG_CMD_USB This line should be moved up where all the commands are defined (below config_cmd_default.h) > + > +#ifdef CONFIG_CMD_USB > +#define CONFIG_USB_EHCI > +#define CONFIG_USB_EHCI_ARMADA100 > +#define CONFIG_EHCI_IS_TDI > +#define CONFIG_USB_STORAGE > + > +#ifndef CONFIG_DOS_PARTITION Does this undef needed? remove it you can. Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
> Hi Robert, > > On 1/25/12, Marek Vasut wrote: > >> Shouldn't we configure clkctrl_frac0 - or at least disable CPU clock > >> gating - before disabling PLL bypass? > > > > This seems reasonable. Fabio, can you comment? > > Could you please post a patch with your proposed change so that we can test > it? > Hi Fabio, I bought a really crappy custom board a few days ago (some china-made crap) sporting mx287, but apparently I'm hitting similar issue you do here. When I swap power_init and mem_init though, the board boots fine, othervise it hangs. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Thu, 2012-01-26 at 10:08 -0700, Tom Rini wrote: > On Wed, Jan 25, 2012 at 1:06 PM, wilsonjonathan > wrote: > > The u-boot loader is showing an incorrect size in the memory, and > > passing the invalid information to the kernel. > > What revision of the board do you have? Is this a 'classic' rev C4? Thanks. > As far as I'm aware yes, standard C4 from digikey. I've done a little more searching, and found that adding #define DEBUG to /arc/arm/lib/board.c brings up more detailed info. > U-Boot SPL 2011.12-dirty (Jan 26 2012 - 18:21:33) > Texas Instruments Revision detection unimplemented > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.bin > mkimage signature not found - ih_magic = ea14 > Assuming u-boot.bin .. > reading u-boot.bin > > > U-Boot 2011.12-dirty (Jan 26 2012 - 18:45:06) > > U-Boot code: 8010 -> 8014BC20 BSS: -> 8018F824 > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz > OMAP3 Beagle board + LPDDR/NAND > I2C: ready > monitor len: 0008F824 > ramsize: 4000 > TLB table at: bfff > Top of RAM usable for U-Boot at: bfff > Reserving 574k for U-Boot at: bff6 > Reserving 384k for malloc() at: bff0 > Reserving 32 Bytes for Board Info at: bfefffe0 > Reserving 120 Bytes for Global Data at: bfefff68 > New Stack Pointer is: bfefff58 > RAM Configuration: > Bank #0: 8000 512 MiB > Bank #1: a000 512 MiB > relocation Offset is: 3fe6 > WARNING: Caches not enabled > monitor flash len: 000532D8 > Now running in RAM - U-Boot at: bff6 > NAND: 256 MiB > MMC: OMAP SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In:serial > Out: serial > Err: serial > Beagle Rev C4 > timed out in wait_for_pin: I2C_STAT=0 > I2C read: I/O error > Unrecognized expansion board: 0 > Die ID #54680024040365fa12014003 > Net: No ethernet found. > Hit any key to stop autoboot: 0 > OMAP3 beagleboard.org # > At that point my total lack of c knowledge kicked in and I gave up! I'm currently downloading the denx u-boot from git, so will give that a try and see if it reports anything different. The reason for going for a source option is I have an odd problem with my pandaboard not reading the mmc with various versions of u-boot so decided to go back to the beagleboard to see if the problem was the same, and if not then at least have an idea where to start from with the pandaboard... but I digress! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Thu, 2012-01-26 at 10:08 -0700, Tom Rini wrote: > On Wed, Jan 25, 2012 at 1:06 PM, wilsonjonathan > wrote: > > The u-boot loader is showing an incorrect size in the memory, and > > passing the invalid information to the kernel. > > What revision of the board do you have? Is this a 'classic' rev C4? Thanks. > Using the denx u-boot, if it doesn't find u-boot.img it halts instead of then testing for u-boot.bin... so I put u-boot.img onto the mmc and the following came up. > U-Boot SPL 2011.12-00201-g137703b (Jan 26 2012 - 19:15:07) > Texas Instruments Revision detection unimplemented > OMAP SD/MMC: 0 > reading u-boot.img > reading u-boot.img > > > U-Boot 2011.12-00201-g137703b (Jan 26 2012 - 19:15:07) > > OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz > OMAP3 Beagle board + LPDDR/NAND > I2C: ready > DRAM: 1 GiB > NAND: 256 MiB > MMC: OMAP SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In:serial > Out: serial > Err: serial > Beagle Rev C4 > timed out in wait_for_pin: I2C_STAT=0 > I2C read: I/O error > Unrecognized expansion board: 0 > Die ID #54680024040365fa12014003 > Net: Net Initialization Skipped > No ethernet found. > Hit any key to stop autoboot: 0 > OMAP3 beagleboard.org # ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Thu, Jan 26, 2012 at 12:14 PM, wilsonjonathan wrote: > On Thu, 2012-01-26 at 10:08 -0700, Tom Rini wrote: >> On Wed, Jan 25, 2012 at 1:06 PM, wilsonjonathan >> wrote: >> > The u-boot loader is showing an incorrect size in the memory, and >> > passing the invalid information to the kernel. >> >> What revision of the board do you have? Is this a 'classic' rev C4? Thanks. >> > As far as I'm aware yes, standard C4 from digikey. > > I've done a little more searching, and found that adding #define DEBUG > to /arc/arm/lib/board.c brings up more detailed info. I will re-confirm with mine then. Previous versions of U-Boot/MLO report how much memory, 512MB? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Thu, 2012-01-26 at 12:28 -0700, Tom Rini wrote: > On Thu, Jan 26, 2012 at 12:14 PM, wilsonjonathan > wrote: > > On Thu, 2012-01-26 at 10:08 -0700, Tom Rini wrote: > >> On Wed, Jan 25, 2012 at 1:06 PM, wilsonjonathan > >> wrote: > >> > The u-boot loader is showing an incorrect size in the memory, and > >> > passing the invalid information to the kernel. > >> > >> What revision of the board do you have? Is this a 'classic' rev C4? > >> Thanks. > >> > > As far as I'm aware yes, standard C4 from digikey. > > > > I've done a little more searching, and found that adding #define DEBUG > > to /arc/arm/lib/board.c brings up more detailed info. > > I will re-confirm with mine then. Previous versions of U-Boot/MLO > report how much memory, 512MB? > I don't have an older version to hand, but according to the specs it should be 256MB using a 2Gb MDDR SDRAM and I seem to recall it did display that. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: nand flash
These patches were posted before the close of the merge window. The following changes since commit 137703b811502dfea364650fb3e17f20b4c21333: overo: add SPL support (2012-01-16 08:40:13 +0100) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master Christian Hitz (7): nand: Merge BCH code from Linux nand driver nand: Add more NAND types from Linux nand driver nand: cleanup whitespace nand: Merge changes from Linux nand driver nand: Merge changes to BBT from Linux nand driver nand: Sanitize ONFI strings. nand: make 1-bit software ECC configurable Scott Wood (4): NAND: Remove additional (CONFIG_SYS)_NAND_MAX_CHIPS nand_spl: store ecc data on the stack nand: Introduce CONFIG_SYS_NAND_SELF_INIT nand/fsl_elbc: Convert to self-init Shengzhou Liu (1): mtd/nand: Add ONFI support for FSL NAND controller Stefano Babic (1): nand_spl_simple: store ecc data on the stack Vladimir Zapolskiy (1): NAND: remove NAND_MAX_CHIPS definitions doc/README.nand| 62 ++ drivers/mtd/nand/Makefile |3 +- drivers/mtd/nand/fsl_elbc_nand.c | 60 ++- drivers/mtd/nand/nand.c| 96 ++- drivers/mtd/nand/nand_base.c | 677 +++-- drivers/mtd/nand/nand_bbt.c| 427 --- drivers/mtd/nand/nand_bch.c| 236 ++ drivers/mtd/nand/nand_ids.c| 35 + drivers/mtd/nand/nand_spl_simple.c | 42 +- include/configs/P1_P2_RDB.h|3 +- include/configs/PMC440.h |2 - include/configs/SIMPC8313.h|3 +- include/configs/VCMA9.h|1 - include/configs/acadia.h |2 - include/configs/am3517_crane.h |4 - include/configs/am3517_evm.h |4 - include/configs/aria.h |4 - include/configs/at91sam9m10g45ek.h |1 - include/configs/bamboo.h |2 - include/configs/bf526-ezbrd.h |1 - include/configs/bf527-ad7160-eval.h|1 - include/configs/bf527-ezkit.h |1 - include/configs/bf548-ezkit.h |1 - include/configs/cam_enc_4xx.h |4 - include/configs/canyonlands.h |2 - include/configs/cm-bf527.h |1 - include/configs/cpu9260.h |1 - include/configs/da830evm.h |1 - include/configs/da850evm.h |1 - include/configs/davinci_dm355leopard.h |1 - include/configs/devkit8000.h |5 - include/configs/ea20.h |1 - include/configs/eb_cpux9k2.h |1 - include/configs/enbw_cmc.h |1 - include/configs/hawkboard.h|6 +- include/configs/kilauea.h |2 - include/configs/km/km_arm.h|1 - include/configs/m28evk.h |1 - include/configs/mecp5123.h |2 - include/configs/mpc5121ads.h |1 - include/configs/mv-common.h|1 - include/configs/omap3_beagle.h |4 - include/configs/omap3_evm.h|4 - include/configs/omap3_evm_quick_nand.h |4 - include/configs/pdm360ng.h |2 - include/configs/pm9261.h |1 - include/configs/pm9263.h |1 - include/configs/pm9g45.h |1 - include/configs/qi_lb60.h |5 - include/configs/sequoia.h |2 - include/configs/smdk2410.h |1 - include/configs/smdk6400.h |4 - include/configs/tam3517-common.h |5 - include/configs/tnetv107x_evm.h|1 - include/configs/tt01.h |1 - include/linux/bch.h| 79 ++ include/linux/mtd/bbm.h| 25 +- include/linux/mtd/nand.h | 374 + include/linux/mtd/nand_bch.h | 72 ++ include/linux/mtd/nand_ecc.h | 25 + include/linux/string.h |4 + include/nand.h | 16 + lib/Makefile |1 + lib/bch.c | 1358 lib/string.c | 39 + nand_spl/nand_boot.c | 42 +- 66 files changed, 3082 insertions(+), 690 deletions(-) create mode 100644 drivers/mtd/nand/nand_bch.c create mode 100644 include/linux/bch.h create mode 100644 include/linux/mtd/nand_bch.h create mode 100644 lib/bch.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] net: ll_temac: Add LL TEMAC driver to u-boot
Am Donnerstag, den 26.01.2012, 16:07 +0100 schrieb Michal Simek:
> Hi Stephan,
Hi Michal,
>
> Stephan Linz wrote:
> > Xilinx LocalLink Tri-Mode Ether MAC driver can be
> > used by Xilinx Microblaze or Xilinx ppc405/440 in
> > SDMA and FIFO mode. DCR or XPS bus can be used.
> >
> > --snip--
> > ---
> > drivers/net/Makefile |2 +
> > drivers/net/xilinx_ll_temac.c | 386
> > drivers/net/xilinx_ll_temac_fifo.c | 143
> > drivers/net/xilinx_ll_temac_mdio.c | 165 ++
> > drivers/net/xilinx_ll_temac_sdma.c | 370 +++
> > include/netdev.h |1 +
> > include/xilinx_ll_temac.h | 430
> >
> > include/xilinx_ll_temac_fifo.h | 122 ++
> > include/xilinx_ll_temac_mdio.h | 53 +
> > include/xilinx_ll_temac_sdma.h | 281 +++
> > 10 files changed, 1953 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/net/xilinx_ll_temac.c
> > create mode 100644 drivers/net/xilinx_ll_temac_fifo.c
> > create mode 100644 drivers/net/xilinx_ll_temac_mdio.c
> > create mode 100644 drivers/net/xilinx_ll_temac_sdma.c
> > create mode 100644 include/xilinx_ll_temac.h
> > create mode 100644 include/xilinx_ll_temac_fifo.h
> > create mode 100644 include/xilinx_ll_temac_mdio.h
> > create mode 100644 include/xilinx_ll_temac_sdma.h
>
> Wolfgang: I just wanted to know what it is the rule for adding headers.
> I would prefer to add these headers to drivers/net/ folder instead include.
Hm, the reason was the more and more growing up of public interfaces,
for example xilinx_ll_temac_mdio_initialize() and
xilinx_ll_temac_initialize() can be used outside of the driver instead
of it's own standard setup. Yes, I've read your consider, see below. But
if I want to use the xilinx_ll_temac_initialize() outside I need to
export the interface, especially mode flag definitions (FIFO/SDMA/DCR).
So I need public access to the header.
@Wolfgang: What will be the best solution here?
>
>
> >
> > diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> > index f4f7ea3..430f90c 100644
> > --- a/drivers/net/Makefile
> > +++ b/drivers/net/Makefile
> > @@ -77,6 +77,8 @@ COBJS-$(CONFIG_ULI526X) += uli526x.o
> > COBJS-$(CONFIG_VSC7385_ENET) += vsc7385.o
> > COBJS-$(CONFIG_XILINX_AXIEMAC) += xilinx_axi_emac.o
> > COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
> > +COBJS-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o
> > xilinx_ll_temac_mdio.o \
> > + xilinx_ll_temac_fifo.o xilinx_ll_temac_sdma.o
> > --snip--
> > +
> > +/*
> > + * Initialize a single ll_temac device with its mdio bus behind ll_temac
> > + *
> > + * Returns 1 if the ll_temac device and the mdio bus were initialized
> > + * otherwise returns 0
> > + */
> > +static int xilinx_ll_temac_eth_init(bd_t *bis, struct ll_temac_info
> > *devinf)
> > +{
> > + struct ll_temac_mdio_info mdioinf;
> > + int ret;
> > +
> > + mdioinf.name = devinf->mdio_busname;
> > + mdioinf.regs = (struct temac_reg *)devinf->base_addr;
> > + ret = xilinx_ll_temac_mdio_initialize(bis, &mdioinf);
> > + if (ret >= 0) {
> > + ret = xilinx_ll_temac_initialize(bis, devinf);
> > + if (ret > 0)
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Initialize all the ll_temac devices
> > + *
> > + * Returns the number of ll_temac devices that were initialized
> > + */
> > +int xilinx_ll_temac_standard_init(bd_t *bis)
> > +{
>
> name seems to me bogus because I can't see any non-standard init.
>
>
> > + struct ll_temac_info devinf;
> > + int count = 0;
> > +
> > +#if defined(CONFIG_XILINX_LL_TEMAC0_BASE_ADDR)
> > + SET_STD_LL_TEMAC_INFO(devinf, 0);
> > + count += xilinx_ll_temac_eth_init(bis, &devinf);
> > +#endif
> > +
> > +#if defined(CONFIG_XILINX_LL_TEMAC1_BASE_ADDR)
> > + SET_STD_LL_TEMAC_INFO(devinf, 1);
> > + count += xilinx_ll_temac_eth_init(bis, &devinf);
> > +#endif
>
> I understand what you want to do but it seems to me better
> to call xilinx_ll_temac_eth_init(bis, BASE_ADDR, DMA/FIFO, flags, phyaddr)
I believe, function with more than three arguments is bad code. So I've
introduced a driver information struct, We can bundle all the specific
IP options in this struct.
> or similar instead of trying to do it in smarter way which must be
> extend if you want to use more than 2 IPs.
The same problem would be in board init code. You must decide which
address, mode, and subaddress you have to use. By implementation of a
"standard initialization" we can avoid a blow out board init code.
I think there is a natural limit of available IPs. We just need to find
this and adapt the code. Here I've typed on 2 IPs. We can easly expand
to 4 or 6 IPs as default.
Please note, this function should implement THE standard case. You are
free to use the underlaying functions for MDIO and MAC in
Re: [U-Boot] u-boot on beagleboard finds incorrect memory size.
On Thu, Jan 26, 2012 at 12:35 PM, wilsonjonathan
wrote:
> On Thu, 2012-01-26 at 12:28 -0700, Tom Rini wrote:
>> On Thu, Jan 26, 2012 at 12:14 PM, wilsonjonathan
>> wrote:
>> > On Thu, 2012-01-26 at 10:08 -0700, Tom Rini wrote:
>> >> On Wed, Jan 25, 2012 at 1:06 PM, wilsonjonathan
>> >> wrote:
>> >> > The u-boot loader is showing an incorrect size in the memory, and
>> >> > passing the invalid information to the kernel.
>> >>
>> >> What revision of the board do you have? Is this a 'classic' rev C4?
>> >> Thanks.
>> >>
>> > As far as I'm aware yes, standard C4 from digikey.
>> >
>> > I've done a little more searching, and found that adding #define DEBUG
>> > to /arc/arm/lib/board.c brings up more detailed info.
>>
>> I will re-confirm with mine then. Previous versions of U-Boot/MLO
>> report how much memory, 512MB?
>>
>
> I don't have an older version to hand, but according to the specs it
> should be 256MB using a 2Gb MDDR SDRAM and I seem to recall it did
> display that.
OK, thanks. Does the following fix it for you?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 5c04b34..1efdbb0 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -161,7 +161,7 @@ void get_board_mem_timings(u32 *mcfg, u32 *ctrla,
u32 *ctrlb, u32 *rfr_ctrl,
case REVISION_C4:
if (pop_mfr == NAND_MFR_STMICRO && pop_id == 0xba) {
/* 512MB DDR */
- *mcfg = NUMONYX_V_MCFG_165(512 << 20);
+ *mcfg = NUMONYX_V_MCFG_165(256 << 20);
*ctrla = NUMONYX_V_ACTIMA_165;
*ctrlb = NUMONYX_V_ACTIMB_165;
*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
On Thu, Jan 26, 2012 at 4:32 PM, Marek Vasut wrote: > Hi Fabio, > > I bought a really crappy custom board a few days ago (some china-made crap) > sporting mx287, but apparently I'm hitting similar issue you do here. > > When I swap power_init and mem_init though, the board boots fine, othervise it > hangs. Ok, so looks like this is not compiler related issue then. Do you know if m28 board can reboot fine or not? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] net: fec_mxc: add PHYLIB support
Signed-off-by: Troy Kisky
---
drivers/net/fec_mxc.c | 35 ++-
drivers/net/fec_mxc.h |1 +
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3fffe79..4d7a38d 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -371,6 +371,20 @@ static int fec_set_hwaddr(struct eth_device *dev)
return 0;
}
+static void fec_eth_phy_config(struct eth_device *dev)
+{
+#ifdef CONFIG_PHYLIB
+ struct fec_priv *fec = (struct fec_priv *)dev->priv;
+ struct phy_device *phydev;
+
+ phydev = phy_connect(miiphy_get_dev_by_name(dev->name),
+ fec->phy_id, dev, PHY_INTERFACE_MODE_RGMII);
+ fec->phydev = phydev;
+ if (phydev)
+ phy_config(phydev);
+#endif
+}
+
/**
* Start the FEC engine
* @param[in] dev Our device to handle
@@ -427,9 +441,19 @@ static int fec_open(struct eth_device *edev)
}
#endif
- miiphy_wait_aneg(edev);
- speed = miiphy_speed(edev->name, fec->phy_id);
- miiphy_duplex(edev->name, fec->phy_id);
+ if (fec->phydev) {
+ /* Start up the PHY */
+#ifdef CONFIG_PHYLIB
+ phy_startup(fec->phydev);
+#endif
+ speed = fec->phydev->speed;
+ } else {
+ miiphy_wait_aneg(edev);
+ speed = miiphy_speed(edev->name, fec->phy_id);
+ miiphy_duplex(edev->name, fec->phy_id);
+ }
+
+
#ifdef CONFIG_MX6Q
{
u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
@@ -556,7 +580,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
fec_tbd_init(fec);
- if (fec->xcv_type != SEVENWIRE)
+ if (!fec->phydev && fec->xcv_type != SEVENWIRE)
miiphy_restart_aneg(dev);
fec_open(dev);
@@ -842,7 +866,8 @@ static int fec_probe(bd_t *bd, int dev_id, int phy_id,
uint32_t base_addr)
debug("got MAC address from fuse: %pM\n", ethaddr);
memcpy(edev->enetaddr, ethaddr, 6);
}
-
+ /* Configure phy */
+ fec_eth_phy_config(edev);
return ret;
err3:
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 1d6ab06..36125b5 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -286,6 +286,7 @@ struct fec_priv {
void *base_ptr;
int dev_id;
int phy_id;
+ struct phy_device *phydev;
int (*mii_postcall)(int);
};
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] net: phy: add support for Micrel's KSZ9021
Add the gigabit phy KSZ9021.
Signed-off-by: Troy Kisky
---
drivers/net/phy/Makefile |1 +
drivers/net/phy/micrel_ksz9021.c | 124 ++
drivers/net/phy/phy.c|3 +
3 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/phy/micrel_ksz9021.c
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index feced39..86ec3c5 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -36,6 +36,7 @@ COBJS-$(CONFIG_PHY_DAVICOM) += davicom.o
COBJS-$(CONFIG_PHY_LXT) += lxt.o
COBJS-$(CONFIG_PHY_MARVELL) += marvell.o
COBJS-$(CONFIG_PHY_MICREL) += micrel.o
+COBJS-$(CONFIG_PHY_MICREL_KSZ9021) += micrel_ksz9021.o
COBJS-$(CONFIG_PHY_NATSEMI) += natsemi.o
COBJS-$(CONFIG_PHY_REALTEK) += realtek.o
COBJS-$(CONFIG_PHY_SMSC) += smsc.o
diff --git a/drivers/net/phy/micrel_ksz9021.c b/drivers/net/phy/micrel_ksz9021.c
new file mode 100644
index 000..f17b798
--- /dev/null
+++ b/drivers/net/phy/micrel_ksz9021.c
@@ -0,0 +1,124 @@
+/*
+ * Micrel KSZ9021 PHY driver
+ *
+ * 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
+ *
+ * Copyright 2012 Boundary Devices
+ *
+ */
+#include
+#include
+#include
+
+/* ksz9021 PHY Registers */
+#define MII_KSZ9021_EXTENDED_CTRL 0x0b
+#define MII_KSZ9021_EXTENDED_DATAW 0x0c
+#define MII_KSZ9021_PHY_CTL0x1f
+#define MIIM_KSZ9021_PHYCTL_1000 (1 << 6)
+#define MIIM_KSZ9021_PHYCTL_100(1 << 5)
+#define MIIM_KSZ9021_PHYCTL_10 (1 << 4)
+#define MIIM_KSZ9021_PHYCTL_DUPLEX (1 << 3)
+
+#define CTRL1000_PREFER_MASTER (1 << 10)
+#define CTRL1000_CONFIG_MASTER (1 << 11)
+#define CTRL1000_MANUAL_CONFIG (1 << 12)
+
+/* This is used to set board specific things like clock skew */
+unsigned short ksz9021_por_cmds[] = {
+#ifdef CONFIG_PHY_MICREL_KSZ9021_INIT_CMDS
+ CONFIG_PHY_MICREL_KSZ9021_INIT_CMDS
+#endif
+ 0, 0
+};
+
+int ksz9021_send_phy_cmds(struct phy_device *phydev, unsigned short* p)
+{
+ for (;;) {
+ unsigned reg = *p++;
+ unsigned val = *p++;
+ if (reg == 0 && val == 0)
+ break;
+ if (reg < 32) {
+ phy_write(phydev, MDIO_DEVAD_NONE, reg, val);
+ } else {
+ phy_write(phydev, MDIO_DEVAD_NONE,
+ MII_KSZ9021_EXTENDED_CTRL, reg);
+ phy_write(phydev, MDIO_DEVAD_NONE,
+ MII_KSZ9021_EXTENDED_DATAW, val);
+ }
+ }
+ return 0;
+}
+
+/* Micrel ksz9021 */
+static int ksz9021_config(struct phy_device *phydev)
+{
+ unsigned ctrl1000 = 0;
+ const unsigned master = CTRL1000_PREFER_MASTER |
+ CTRL1000_CONFIG_MASTER | CTRL1000_MANUAL_CONFIG;
+ unsigned features = phydev->drv->features;
+
+ ksz9021_send_phy_cmds(phydev, ksz9021_por_cmds);
+ if (getenv("disable_giga"))
+ features &= ~(SUPPORTED_1000baseT_Half |
+ SUPPORTED_1000baseT_Full);
+ /* force master mode for 1000BaseT due to chip errata */
+ if (features & SUPPORTED_1000baseT_Half)
+ ctrl1000 |= ADVERTISE_1000HALF | master;
+ if (features & SUPPORTED_1000baseT_Full)
+ ctrl1000 |= ADVERTISE_1000FULL | master;
+ phydev->advertising = phydev->supported = features;
+ phy_write(phydev, MDIO_DEVAD_NONE, MII_CTRL1000, ctrl1000);
+ genphy_config_aneg(phydev);
+ genphy_restart_aneg(phydev);
+ return 0;
+}
+
+static int ksz9021_startup(struct phy_device *phydev)
+{
+ unsigned phy_ctl;
+ genphy_update_link(phydev);
+ phy_ctl = phy_read(phydev, MDIO_DEVAD_NONE, MII_KSZ9021_PHY_CTL);
+
+ if (phy_ctl & MIIM_KSZ9021_PHYCTL_DUPLEX)
+ phydev->duplex = DUPLEX_FULL;
+ else
+ phydev->duplex = DUPLEX_HALF;
+
+ if (phy_ctl & MIIM_KSZ9021_PHYCTL_1000)
+ phydev->speed = SPEED_1000;
+ else if (phy_ctl & MIIM_KSZ9021_PHYCTL_100)
+ phydev->speed = SPEED_100;
+ else if (phy_ctl & MIIM_KSZ9021_PHYCTL_10)
+ phydev->speed = SPEED_10;
+ return 0;
+}
+
+static struct phy_driver k
[U-Boot] [PATCH 4/4] i.mx6q: mx6qsabrelite: Update the network configuration
Enable the usage of PHY_MICREL_KSZ9021, and
minimize the tx clock delay.
There is an issue with 1000 baseTx mode on early revs
of the SabreLite boards. The center tap pin 9 of the mag RJ45
USB combo was connected to the 3.3 filtered supply. Letting
this pin float solved the problem. Symptoms of the problem
were packets with many extra zeroes tacked on the end, and random
bit flips causing a high rate of CRC errors. 10/100 baseTx worked
fine on all revs. To disable 1000 baseTx for these boards, simply
define the environment variable disable_giga. ie.
setenv disable_giga 1
Signed-off-by: Troy Kisky
---
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 43 +---
include/configs/mx6qsabrelite.h |7
2 files changed, 9 insertions(+), 41 deletions(-)
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index e6c12a5..77fb79c 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -187,53 +187,14 @@ int board_mmc_init(bd_t *bis)
}
#endif
-#define MII_1000BASET_CTRL 0x9
-#define MII_EXTENDED_CTRL 0xb
-#define MII_EXTENDED_DATAW 0xc
-
-int fecmxc_mii_postcall(int phy)
-{
- /* prefer master mode */
- miiphy_write("FEC", phy, MII_1000BASET_CTRL, 0x0f00);
-
- /* min rx data delay */
- miiphy_write("FEC", phy, MII_EXTENDED_CTRL, 0x8105);
- miiphy_write("FEC", phy, MII_EXTENDED_DATAW, 0x);
-
- /* max rx/tx clock delay, min rx/tx control delay */
- miiphy_write("FEC", phy, MII_EXTENDED_CTRL, 0x8104);
- miiphy_write("FEC", phy, MII_EXTENDED_DATAW, 0xf0f0);
- miiphy_write("FEC", phy, MII_EXTENDED_CTRL, 0x104);
-
- return 0;
-}
-
int board_eth_init(bd_t *bis)
{
- struct eth_device *dev;
int ret;
-
setup_iomux_enet();
-
ret = cpu_eth_init(bis);
- if (ret) {
+ if (ret)
printf("FEC MXC: %s:failed\n", __func__);
- return ret;
- }
-
- dev = eth_get_dev_by_name("FEC");
- if (!dev) {
- printf("FEC MXC: Unable to get FEC device entry\n");
- return -EINVAL;
- }
-
- ret = fecmxc_register_mii_postcall(dev, fecmxc_mii_postcall);
- if (ret) {
- printf("FEC MXC: Unable to register FEC mii postcall\n");
- return ret;
- }
-
- return 0;
+ return ret;
}
int board_early_init_f(void)
diff --git a/include/configs/mx6qsabrelite.h b/include/configs/mx6qsabrelite.h
index 86b25d9..cbae4c3 100644
--- a/include/configs/mx6qsabrelite.h
+++ b/include/configs/mx6qsabrelite.h
@@ -66,6 +66,13 @@
#defineCONFIG_FEC_XCV_TYPE RGMII
#define CONFIG_ETHPRIME"FEC"
#define CONFIG_FEC_MXC_PHYADDR 6
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_MICREL_KSZ9021
+#define CONFIG_PHY_MICREL_KSZ9021_INIT_CMDS\
+ 0x8105, 0x, /* min rx data delay */ \
+ 0x8106, 0x, /* min tx data delay */ \
+ 0x8104, 0xf0f0, /* max rx/tx clock delay, min rx/tx control */
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] net: fec_mxc: add 1000 Mbps selection
Signed-off-by: Troy Kisky
---
drivers/net/fec_mxc.c | 18 +-
drivers/net/fec_mxc.h |2 ++
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3affda8..3fffe79 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -378,6 +378,7 @@ static int fec_set_hwaddr(struct eth_device *dev)
static int fec_open(struct eth_device *edev)
{
struct fec_priv *fec = (struct fec_priv *)edev->priv;
+ int speed;
debug("fec_open: fec_open(dev)\n");
/* full-duplex, heartbeat disabled */
@@ -427,8 +428,23 @@ static int fec_open(struct eth_device *edev)
#endif
miiphy_wait_aneg(edev);
- miiphy_speed(edev->name, fec->phy_id);
+ speed = miiphy_speed(edev->name, fec->phy_id);
miiphy_duplex(edev->name, fec->phy_id);
+#ifdef CONFIG_MX6Q
+ {
+ u32 ecr = readl(&fec->eth->ecntrl) & ~FEC_ECNTRL_SPEED;
+ u32 rcr = (readl(&fec->eth->r_cntrl) &
+ ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
+ FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
+ if (speed == _1000BASET)
+ ecr |= FEC_ECNTRL_SPEED;
+ else if (speed != _100BASET)
+ rcr |= FEC_RCNTRL_RMII_10T;
+ writel(ecr, &fec->eth->ecntrl);
+ writel(rcr, &fec->eth->r_cntrl);
+ }
+#endif
+ debug("%s:Speed=%i\n", __func__, speed);
/*
* Enable SmartDMA receive task
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 39337bf..1d6ab06 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -198,6 +198,7 @@ struct ethernet_regs {
#define FEC_RCNTRL_FCE 0x0020
#define FEC_RCNTRL_RGMII 0x0040
#define FEC_RCNTRL_RMII0x0100
+#define FEC_RCNTRL_RMII_10T0x0200
#define FEC_TCNTRL_GTS 0x0001
#define FEC_TCNTRL_HBC 0x0002
@@ -207,6 +208,7 @@ struct ethernet_regs {
#define FEC_ECNTRL_RESET 0x0001 /* reset the FEC */
#define FEC_ECNTRL_ETHER_EN0x0002 /* enable the FEC */
+#define FEC_ECNTRL_SPEED 0x0020
#define FEC_ECNTRL_DBSWAP 0x0100
#define FEC_X_WMRK_STRFWD 0x0100
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28 spl power cpu clock configuration
> On Thu, Jan 26, 2012 at 4:32 PM, Marek Vasut wrote: > > Hi Fabio, > > > > I bought a really crappy custom board a few days ago (some china-made > > crap) sporting mx287, but apparently I'm hitting similar issue you do > > here. > > > > When I swap power_init and mem_init though, the board boots fine, > > othervise it hangs. > > Ok, so looks like this is not compiler related issue then. > > Do you know if m28 board can reboot fine or not? > Yes, M28 is ok. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/6] sf command: allow default chip select through CONFIG_SPI_FLASH_CS
On 01/24/2012 11:08 AM, Mike Frysinger wrote:
On Tuesday 24 January 2012 11:18:22 Eric Nelson wrote:
This patch allows a board configuration file to provide a default
chip-select for serial flash so that first argument to the 'sf' command
is optional.
On boards that use the mxc_spi driver and a GPIO for chip select, this
allows a much simpler command line:
U-Boot> sf probe
instead of
U-Boot> sf probe 0x5300
NAK (to this version of the patch): missing README update, and other issues
below
Which README? The only references I find to serial flash support
are in board-specific README files.
~/u-boot$ find . -iname \*readme\* | xargs grep -w sf
./doc/README.p2041rdb: => sf erase 0 10
./doc/README.p2041rdb: => sf write 100 0 $filesize
./doc/README.p2041rdb: => sf erase 11 1
./doc/README.p2041rdb: => sf write 100 11 $filesize
./doc/README.sh7757lcr: => sf probe 0
./doc/README.sh7757lcr: => sf erase 0 8
./doc/README.sh7757lcr: => sf write 0x8900 0 8
I can start one of those for the SabreLite board, but that's un-related
to this patch.
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
+#ifndef CONFIG_SPI_FLASH_CS
+ if (argc< 2) {
+ printf("%s: missing arguments\n", __func__);
return -1;
return cmd_usage(cmdtp);
- if (*endp == ':') {
- if (endp[1] == 0)
- return -1;
+ }
+#else
+ cs = CONFIG_SPI_FLASH_CS ;
+#endif
you're setting the default CS, not locking it in. so a better config knob name
would be something like:
CONFIG_SF_DEFAULT_CS
this matches the existing CONFIG_SF_XXX defines
also, you have a spurious space before the semicolon there
Thanks Mike,
FWIW, I chose this name on purpose to make life easier on a couple of
other boards immediately (efika and vision2):
~/u-boot$ grep CONFIG_SPI_FLASH_CS include/configs/*
include/configs/efikamx.h:#define CONFIG_SPI_FLASH_CS (1 | 121 << 8)
include/configs/m28evk.h:#defineCONFIG_SPI_FLASH_CS 2
include/configs/mx6qsabrelite.h.rej:#define CONFIG_SPI_FLASH_CS 1
include/configs/vision2.h:#define CONFIG_SPI_FLASH_CS (1 | (121 << 8))
U_BOOT_CMD(
sf, 5, 1, do_spi_flash,
"SPI flash sub-system",
+#ifndef CONFIG_SPI_FLASH_CS
"probe [bus:]cs [hz] [mode]- init flash device on given SPI
bus\n"
+#else
+ "probe [[bus:]cs] [hz] [mode] - init flash device on given SPI
bus\n"
+#endif
"and chip select\n"
"sf read addr offset len - read `len' bytes starting at\n"
"`offset' to memory at `addr'\n"
this is ugly. i'd rather just omit it and not worry about the syntax being
perfect.
Works for me.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/6] sf command: allow default chip select through CONFIG_SPI_FLASH_CS
On 01/25/2012 08:10 AM, Matthias Fuchs wrote:
Hi Eric,
please see my comments below.
On 24.01.2012 17:18, Eric Nelson wrote:
This patch allows a board configuration file to provide a default
chip-select for serial flash so that first argument to the 'sf' command
is optional.
On boards that use the mxc_spi driver and a GPIO for chip select, this allows
a much simpler command line:
U-Boot> sf probe
instead of
U-Boot> sf probe 0x5300
Signed-off-by: Eric Nelson
Acked-by: Dirk Behme
Acked-by: Stefano Babic
---
common/cmd_sf.c | 34 +++---
1 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 7225656..4b32171 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -70,20 +70,28 @@ static int do_spi_flash_probe(int argc, char * const argv[])
char *endp;
struct spi_flash *new;
- if (argc< 2)
- return -1;
-
- cs = simple_strtoul(argv[1],&endp, 0);
- if (*argv[1] == 0 || (*endp != 0&& *endp != ':'))
+#ifndef CONFIG_SPI_FLASH_CS
+ if (argc< 2) {
+ printf("%s: missing arguments\n", __func__);
I think this format for the error message is a little bit untypical for
u-boot. We do not show up the internal C function name. Better would be
to show the command usage, right?
Looking at this area of the code in more detail, there are quite
a few cases where improper usage silently return -1.
I'm inclined to either follow that lead or toss them together
with a "goto usage" as done in do_spi_flash().
Any preferences?
return -1;
- if (*endp == ':') {
- if (endp[1] == 0)
- return -1;
+ }
+#else
+ cs = CONFIG_SPI_FLASH_CS ;
Other options for the spi flash subsystem are called
CONFIG_SF_DEFAULT_MODE|SPEED. It think it make sense to call
this CONFIG_SF_DEFAULT_CS and CONFIG_SF_DEFAULT_BUS (see below).
See include/configs/efikamx.h (reference to unused symbol CONFIG_SPI_FLASH_CS).
+#endif
- bus = cs;
- cs = simple_strtoul(endp + 1,&endp, 0);
- if (*endp != 0)
+ if (argc>= 2) {
+ cs = simple_strtoul(argv[1],&endp, 0);
+ if (*argv[1] == 0 || (*endp != 0&& *endp != ':'))
return -1;
+ if (*endp == ':') {
+ if (endp[1] == 0)
+ return -1;
+
+ bus = cs;
+ cs = simple_strtoul(endp + 1,&endp, 0);
+ if (*endp != 0)
+ return -1;
+ }
}
if (argc>= 3) {
@@ -299,7 +307,11 @@ usage:
U_BOOT_CMD(
sf, 5, 1, do_spi_flash,
"SPI flash sub-system",
+#ifndef CONFIG_SPI_FLASH_CS
"probe [bus:]cs [hz] [mode]- init flash device on given SPI
bus\n"
+#else
+ "probe [[bus:]cs] [hz] [mode] - init flash device on given SPI
bus\n"
+#endif
"and chip select\n"
"sf read addr offset len - read `len' bytes starting at\n"
"`offset' to memory at `addr'\n"
Can you also add a config option for the SPI bus number? I think these
two need to handled in the same patch.
So you could add this stuff:
diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 9e97c8e..fa4312a 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -63,7 +63,11 @@ static int sf_parse_len_arg(char *arg, ulong *len)
static int do_spi_flash_probe(int argc, char * const argv[])
{
+#ifdef CONFIG_SF_DEFAULT_BUS
+ unsigned int bus = CONFIG_SF_DEFAULT_BUS;
+#else
unsigned int bus = 0;
+#endif
unsigned int cs;
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
Can do.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/6] sf command: allow default chip select through CONFIG_SPI_FLASH_CS
On Thursday 26 January 2012 20:22:22 Eric Nelson wrote:
> On 01/24/2012 11:08 AM, Mike Frysinger wrote:
> > On Tuesday 24 January 2012 11:18:22 Eric Nelson wrote:
> >> This patch allows a board configuration file to provide a default
> >> chip-select for serial flash so that first argument to the 'sf' command
> >> is optional.
> >>
> >> On boards that use the mxc_spi driver and a GPIO for chip select, this
> >>
> >> allows a much simpler command line:
> >>U-Boot> sf probe
> >>
> >> instead of
> >>
> >>U-Boot> sf probe 0x5300
> >
> > NAK (to this version of the patch): missing README update, and other
> > issues below
>
> Which README? The only references I find to serial flash support
> are in board-specific README files.
all new CONFIG_xxx defines should be documented in the top level README.
granted, the existin SF ones have slipped in without being documented, but
that's bad for them ;).
> >> --- a/common/cmd_sf.c
> >> +++ b/common/cmd_sf.c
> >>
> >> - if (*endp == ':') {
> >> - if (endp[1] == 0)
> >> - return -1;
> >> + }
> >> +#else
> >> + cs = CONFIG_SPI_FLASH_CS ;
> >> +#endif
> >
> > you're setting the default CS, not locking it in. so a better config
> > knob name
> >
> > would be something like:
> > CONFIG_SF_DEFAULT_CS
> >
> > this matches the existing CONFIG_SF_XXX defines
> >
> > also, you have a spurious space before the semicolon there
>
> Thanks Mike,
>
> FWIW, I chose this name on purpose to make life easier on a couple of
> other boards immediately (efika and vision2):
those boards are dumb -- that define isn't used anywhere, so that's just dead
code. cmd_sf has a standard already, so new defines specific to cmd_sf should
follow that.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 4/6] sf command: allow default chip select through CONFIG_SPI_FLASH_CS
On Thursday 26 January 2012 20:36:22 Eric Nelson wrote:
> On 01/25/2012 08:10 AM, Matthias Fuchs wrote:
> > On 24.01.2012 17:18, Eric Nelson wrote:
> >> --- a/common/cmd_sf.c
> >> +++ b/common/cmd_sf.c
> >>
> >>char *endp;
> >>struct spi_flash *new;
> >>
> >> - if (argc< 2)
> >> - return -1;
> >> -
> >> - cs = simple_strtoul(argv[1],&endp, 0);
> >> - if (*argv[1] == 0 || (*endp != 0&& *endp != ':'))
> >> +#ifndef CONFIG_SPI_FLASH_CS
> >> + if (argc< 2) {
> >> + printf("%s: missing arguments\n", __func__);
> >
> > I think this format for the error message is a little bit untypical for
> > u-boot. We do not show up the internal C function name. Better would be
> > to show the command usage, right?
>
> Looking at this area of the code in more detail, there are quite
> a few cases where improper usage silently return -1.
>
> I'm inclined to either follow that lead or toss them together
> with a "goto usage" as done in do_spi_flash().
>
> Any preferences?
invalid syntax should return cmd_usage(). errors should return non-zero, not
usage information.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] net: phy: add support for Micrel's KSZ9021
On Thursday 26 January 2012 17:21:44 Troy Kisky wrote:
> +/* This is used to set board specific things like clock skew */
> +unsigned short ksz9021_por_cmds[] = {
static const
> +int ksz9021_send_phy_cmds(struct phy_device *phydev, unsigned short* p)
static
> + for (;;) {
personally, i'd prefer:
while (1) {
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] microblaze: Enable several ethernet driver compilation
On Saturday 21 January 2012 16:02:54 Stephan Linz wrote: > NET_MULTI enables to use several ethernet drivers but > microblaze-generic platform config file select only > one driver. NET_MULTI no longer exists because the code is always enabled now :) > #define CONFIG_ETHADDR 00:E0:0C:00:00:FD > +#define CONFIG_ETH1ADDR 00:E0:0C:00:00:FC err, i think these need to get dropped. boards should not be hardcoding mac addresses in their configs. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] USB: Armada100: ECHI Driver for Armada100 SOCs
- "Prafulla Wadaskar" wrote:
[...snip...]
> > +
> > +printf("Kirkwood-ehci: init hccr %x and hcor %x hc_length %d\n",
>
> Wrong printf message, it's not Kirkwood.
>
> Regards..
> Prafulla . . .
>
I don't know how I missed that.. though, I did changed it :/
Any other comments on patches?
Regards,
Ajay Bhargav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-Boot-Users]-compilation error
hi.. i am new to u-boot and for my practice i compiled arm720t impa7 source code using abacus-anurag-linux compiler. i am getting the following errors.. could you help me to clear the errors. root@user-Invalid-entry-length-0-DMI-table-is-broken-Stop:/home/user/u-boot-1.1.6# ./exec make: arm-linux-gcc: Command not found find /home/user/u-boot-1.1.6 -type f \ \( -name 'core' -o -name '*.bak' -o -name '*~' \ -o -name '*.o' -o -name '*.a' \) -print \ | xargs rm -f rm -f examples/hello_world examples/timer \ examples/eepro100_eeprom examples/sched \ examples/mem_to_mem_idma2intr examples/82559_eeprom \ examples/smc9_eeprom examples/interrupt \ examples/test_burst rm -f tools/img2srec tools/mkimage tools/envcrc \ tools/gen_eth_addr rm -f tools/mpc86x_clk tools/ncb rm -f tools/easylogo/easylogo tools/bmp_logo rm -f tools/gdb/astest tools/gdb/gdbcont tools/gdb/gdbsend rm -f tools/env/fw_printenv tools/env/fw_setenv rm -f board/cray/L1/bootscript.c board/cray/L1/bootscript.image rm -f board/netstar/eeprom board/netstar/crcek board/netstar/crcit rm -f board/netstar/*.srec board/netstar/*.bin rm -f board/trab/trab_fkt board/voiceblue/eeprom rm -f board/integratorap/u-boot.lds board/integratorcp/u-boot.lds rm -f include/bmp_logo.h rm -f nand_spl/u-boot-spl nand_spl/u-boot-spl.map find /home/user/u-boot-1.1.6 -type f \( -name .depend \ -o -name '*.srec' -o -name '*.bin' -o -name u-boot.img \) \ -print0 \ | xargs -0 rm -f rm -f cpu/arm720t/start.o *.bak ctags etags TAGS include/version_autogenerated.h rm -fr *.*~ rm -f u-boot u-boot.map u-boot.hex u-boot.srec u-boot.bin System.map rm -f tools/crc32.c tools/environment.c tools/env/crc32.c rm -f tools/inca-swap-bytes cpu/mpc824x/bedbug_603e.c rm -f include/asm/proc include/asm/arch include/asm [ ! -d /home/user/u-boot-1.1.6/nand_spl ] || find nand_spl -lname "*" -print | xargs rm -f Configuring for impa7 board... for dir in tools examples post post/cpu ; do make -C $dir _depend ; done make[1]: Entering directory `/home/user/u-boot-1.1.6/tools' ln -s ../common/environment.c environment.c ln -s ../lib_generic/crc32.c crc32.c make[1]: Leaving directory `/home/user/u-boot-1.1.6/tools' make[1]: Entering directory `/home/user/u-boot-1.1.6/tools' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/user/u-boot-1.1.6/tools' make[1]: Entering directory `/home/user/u-boot-1.1.6/examples' abacus-anurag-linux-gcc: hello_world.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: stubs.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' make[1]: *** No rule to make target `.depend', needed by `_depend'. Stop. make[1]: Leaving directory `/home/user/u-boot-1.1.6/examples' make[1]: Entering directory `/home/user/u-boot-1.1.6/post' abacus-anurag-linux-gcc: cache_8xx.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: cache.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: codec.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: cpu.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: dsp.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: ether.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: i2c.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: memory.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: post.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: rtc.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: spr.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: sysmon.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: tests.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: uart.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: usb.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-linux-gcc: watchdog.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' make[1]: *** No rule to make target `.depend', needed by `_depend'. Stop. make[1]: Leaving directory `/home/user/u-boot-1.1.6/post' make[1]: Entering directory `/home/user/u-boot-1.1.6/post/cpu' abacus-anurag-linux-gcc: asm.o: No such file or directory abacus-anurag-linux-gcc: unrecognized option `-MQ' abacus-anurag-
Re: [U-Boot] [PATCH 1/3] USB: Armada100: Add UTMI PHY interface driver
- "Prafulla Wadaskar" wrote: > > + > > +/* MPMU Clocks */ > > +#define MPMU_EN_ALL_CLKS0x1E > > Turning on all clocks is not logical to enable this support, only > relevant clock necessary for this components SHOULD BE enabled. > > Enabling clocks for unused peripherals/components may result in > unnecessarily extra power consumption > > Otherwise ack for rest of the patch > > Regards.. > Prafulla . . . > I followed programming guidlines as per Armada_16x software manual. section: 20.4.3.1 snip of pseudo code from Programming guidlines section: [...snip...] print "**main PMU turn on all clocks\n" set val *(unsigned long *)PMUM_ACGR=0x001E print "**PMUap USBCLK Reset Control\n" set val *(unsigned long *)PMUA_USB_CLK_RES_CTRL=0x1B print "**UTMI ID\n" eval /hex *(unsigned long *)UTMI_REVISION [...snip...] There is nothing mentioned in specific which clock is used/required by USB host controller. Regards, Ajay Bhargav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Armada100: gplugD: Add USB command support
- "Prafulla Wadaskar" wrote: > > -Original Message- > > From: Ajay Bhargav [mailto:ajay.bhar...@einfochips.com] > > Sent: 25 January 2012 17:50 > > To: li...@bohmer.net > > Cc: Prafulla Wadaskar; marek.va...@gmail.com; u-boot@lists.denx.de; > > Ajay Bhargav > > Subject: [PATCH 3/3] Armada100: gplugD: Add USB command support > > > > This patch adds support for USB commands and USB storage device for > > Marvell gplugD [...snip...] > > > > +#ifdef CONFIG_CMD_USB > > +#define CONFIG_USB_EHCI > > +#define CONFIG_USB_EHCI_ARMADA100 > > +#define CONFIG_EHCI_IS_TDI > > +#define CONFIG_USB_STORAGE > > + > > +#ifndef CONFIG_DOS_PARTITION > > Does this undef needed? remove it you can. > > Regards.. > Prafulla . . . > I will review it again and remove it if not needed. Regards, Ajay Bhargav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
