Re: [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
On 03/01/2012 06:32 PM, Scott Wood wrote: I'm saying that right now it's an OMAP-specific requirement and the implementation of necessity involves the OMAP driver. If another driver grows this as a requirement, we can consider refactoring so the command line frontend is common. Different ECC modes for different parts of the flash is unfortunate, but sometimes mandated by circumstance. The NAND subsystem isn't really set up to handle this, though changing it temporally is a hackish substitute. Ok, thanks for clarifying. -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
On 02/29/2012 10:00 PM, Scott Wood wrote: ECC mode is normally not something that you want to be runtime switchable, as changing it usually changes the on-flash format. It also requires driver cooperation -- the actual implementation (as opposed to the command-line wrapper) is in drivers/mtd/nand/omap_gpmc.c. Are you saying that it shouldn't be switchable through a command line option (but rather based on information in the partition table or something similar), or are you saying that we shouldn't need different ECC modes for different parts of the flash (boot ROM vs. software implementations, whether block 0 has different ECC requirement etc)? -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Broken ecc.size when switching between sw and hw ecc (beagleboard)
For the beagleboard, ecc.size is not explicitly set when doing 'nandecc sw'. If it's not set for the NAND_ECC_SOFT case in nand_scan_tail, it's set to 256 bytes. When doing 'nandecc hw', ecc.size is set to 512 bytes. Hence, when changing back to 'nandecc sw' ecc.size remains at 512 bytes and suddenly the format has changed. It seems the current nandecc command needs to set this explicitly, but also needs to be augmented to be able to select the newly added 4/8-bit BCH ECC. But it also seems like nandecc selection should be more generic than for omap3 (currently it lives in arch/arm/cpu/armv7/omap3/board.c). I have seen that TI did some work on this previously in the PSP04.02.00.07 release of u-boot and linux (2.6.37). Is there ongoing work in this area? I'd be happy to help out if I can. (I noticed the nand dump.oob seems to have been fixed in the u-boot-nand-flash repo.) Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatload accepting wildcard in filename?
On 2011-11-08 09:49, Wolfgang Denk wrote: >> Their release is from a few years back (2008-06-11); the same fatload + >> wildcard construct doesn't work with 2011.03. I'm trying to find out >> how this was implemented, and if it was ever part of mainline or if it >> was a local hack. (I couldn't find it in the ml archives.) > > This has never been supported in mainline code. Ok, thanks. I'm going to give it a shot and see if I can come up with something sensible. -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fatload accepting wildcard in filename?
Hi, I came across this page http://boundarydevices.com/upgradeU.php where the linked Xenon "upgrade package" contains a script that does if fatload mmc 0 80008000 u-boot-xenon*.bin ; then ... Their release is from a few years back (2008-06-11); the same fatload + wildcard construct doesn't work with 2011.03. I'm trying to find out how this was implemented, and if it was ever part of mainline or if it was a local hack. (I couldn't find it in the ml archives.) Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MUSB timeout broken
On 2011-08-08 21:37, Remy Bohmer wrote: > Whoops... Not applied to u-boot-usb, since the timeout code is broken. > It should wait for a certain time, not a certain count. Agreed, patch withdrawn. -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)
On 2011-07-07 14:27, Orjan Friberg wrote: > On 2011-07-07 11:37, Orjan Friberg wrote: >> It seems the boot rom must be doing some initialization of the USB phy >> (this is with a TPS65920). > > I forgot to add that I'm using a configuration header and not x-loader > as the 1st stage bootloader. > > On a BeagleBoard xM (with x-loader), usb reset works fine coming out of > a cold reset. > > I'd better check my configuration header. Ok, so I've booted a u-boot with a configuration header on the xM board and 'usb reset' works fine after a cold boot. Vice versa, using x-loader + u-boot on our own board, 'usb reset' does not work. I'm looking at the silicon erratas for the 3730 and the TPS chip and found a couple of entries relating to the OTG functionality. However, they don't correlate with silicon revision differences between the xM board and our own board (and they don't seem to apply here). What other stuff should I be looking into? (The xM board uses a 65950 whereas we are using the 65920, but the errata is for all 659x0 devices.) The 3730 TRM talks about the boot ROM doing USB PHY initialization, but it doesn't list any details. Thanks for any suggestions, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)
On 2011-07-07 11:37, Orjan Friberg wrote: > It seems the boot rom must be doing some initialization of the USB phy > (this is with a TPS65920). I forgot to add that I'm using a configuration header and not x-loader as the 1st stage bootloader. On a BeagleBoard xM (with x-loader), usb reset works fine coming out of a cold reset. I'd better check my configuration header. -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)
Hi, I'm seeing some weird behaviour with host mode USB on the OTG port in u-boot (2011.03), and just wondering if anyone else seen this. Booting from NAND after a power cycle, host mode USB doesn't work (the 'usb reset' command times out). However, if I change the boot order (external button) to go through USB and UART before NAND it does work (it enters host mode, and devices are discovered). After that, USB continues to work after warm-resetting the board. It's not until after a cold reset/power cycle that it stops working again. It seems the boot rom must be doing some initialization of the USB phy (this is with a TPS65920). Dumping the I2C regs of the USB phy in u-boot shows a lot of differences between the two boot modes. This is on a custom board, BeagleBoard derived but with a 3730. Any ideas? Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v3] musb: Add Phy programming for usingexternal Vbus
On 2011-07-05 16:16, Gupta, Ajay Kumar wrote: >> (On our custom board, we have added an external vbus supply to be able >> to draw> 100 mA.) > So it seems you are using PHY inside TPS659x but external Vbus for which > I think you need to, > 1. Explicitly set "OTG_CTRL.D5 = 0" so that PHY doesn't drive 5V. > 2. Do not set musb_cfg.extvbus Great, thanks for clarifying (and agreed on all points). It seems the best I can do is turn off DRVVBUS as soon as the chip has entered host mode (and turned thus it on). Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v3] musb: Add Phy programming for usingexternal Vbus
On 2011-07-05 13:15, Gupta, Ajay Kumar wrote: > OMAP3EVM doesn't use TPS PHY but it has ISP1507 PHY and uses external Vbus > And so it needs extvbus programming (musb_cfg.extvbus =1)in OTG_CTRL > register. As for as I know it is not needed for boards using usb PHY on TPS > device. Can you clarify what you mean by "not needed for boards using usb PHY on TPS device"? How does that differ from the ISP1507? From what I'm reading, the ISP1507 does have an integrated 5V charge pump. Or is it simply a matter of how the board is designed? (On our custom board, we have added an external vbus supply to be able to draw > 100 mA.) Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4 v3] musb: Add Phy programming for usingexternal Vbus
On 2010-06-10 07:50, Ajay Kumar Gupta wrote: > MUSB PHY on OMAP3EVM Rev>= E uses external Vbus supply to support > 500mA of power.We need to program MUSB PHY to use external Vbus > for this purpose. > > Adding 'extvbus' member in musb_config structure which should be set > by all the boards where MUSB interface is using external Vbus supply. Ajay, How does the DRVVBUS bit behave on the OMAP3 EVM board on issuing the 'usb reset' command (with musb_cfg.extvbus being set)? This post has a few more details, but in short it seems that DRVVBUS is automatically set by the TPS chip when doing the bus reset: http://lists.denx.de/pipermail/u-boot/2011-June/095221.html (And indeed, on a board with *no* external vbus, setting musb_cfg.extvbus and reading from a memory stick works just fine.) I checked the u-boot in the current DVSDK (4.02.00.06) and the git repo for u-boot-ti and they all have the same construct. Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MUSB timeout broken
Use pre-decrement to leave timeout at 0 when the timeout happens (which is what the timeout detecting code expects). Signed-off-by: Orjan Friberg --- drivers/usb/musb/musb_hcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c index 974bb31..adcf7f7 100644 --- a/drivers/usb/musb/musb_hcd.c +++ b/drivers/usb/musb/musb_hcd.c @@ -1114,7 +1114,7 @@ int usb_lowlevel_init(void) * should be a usb device connected. */ timeout = musb_cfg.timeout; - while (timeout--) + while (--timeout) if (readb(&musbr->devctl) & MUSB_DEVCTL_HM) break; -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MUSB timeout broken
The following construct (musb_hcd.c, usb_lowlevel_init)
timeout = musb_cfg.timeout;
while (timeout--)
if (readb(&musbr->devctl) & MUSB_DEVCTL_HM)
break;
will leave timeout == -1 when the timeout is reached, hence the timeout
detecting code that follows will not trigger:
/* if musb core is not in host mode, then return */
if (!timeout)
return -1;
Without the patch below, doing a 'usb reset' without a device connected
makes it impossible to discover connected devices later. I have not
investigated why this happens since the timeout logic was broken (and
correcting that fixed the issue at hand).
Changed to pre-decrement since I assume the timeout value is not *that*
exact.
Thanks,
Orjan
diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c
index 974bb31..adcf7f7 100644
--- a/drivers/usb/musb/musb_hcd.c
+++ b/drivers/usb/musb/musb_hcd.c
@@ -1114,7 +1114,7 @@ int usb_lowlevel_init(void)
* should be a usb device connected.
*/
timeout = musb_cfg.timeout;
- while (timeout--)
+ while (--timeout)
if (readb(&musbr->devctl) & MUSB_DEVCTL_HM)
break;
--
Orjan Friberg
FlatFrog Laboratories AB
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] musb_cfg.extvbus = 1 reverted by bus reset?
Hi, Using external VBUS on the OTG port in host mode, I have set musb_cfg.extvbus = 1. However, after a 'usb start', the DRVVBUS bit in OTG_CTRL is always set to 1 (regardless of the value of musb_cfg.extvbus). Immediately after boot it is 0. (I ran 'i2c md 0x48 0xa 1'.) In musb_hcd.c, the extvbus setting is done *before* the usb bus is reset. The TPS65920 TRM says that DRVVBUS is turned on when the chip acts as a host. It seems to me that the DRVVBUS setting is reverted by the chip going into host mode. Any ideas? (This is on 2011.03, but latest git seems to have the same construct.) Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Beagle mux config: nCS5 vs. DMAREQ2?
Hi, The mux configuration in board/ti/beagle/beagle.h says MUX_VAL(CP(GPMC_NCS5), (IDIS | PTD | DIS | M0)) /*GPMC_nCS5*/ MUX_VAL(CP(GPMC_NCS6), (IEN | PTD | DIS | M1)) /*SYS_nDMA_REQ2*/ The TRM (spruf98p) says sys_ndmareq2 is mux mode 1 for ncs5, not ncs6. (Possibly not a concern for the BeagleBoard; I'm trying to get dmareq2 working on a custom 3730 board.) Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
