Re: [U-Boot] List of offending drivers
Dear Marek Vasut, board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2012.07-rc3 is out - release date July 30
Hi everybody, this is to let you know that the v2012.07-rc3 prerelease is out. Please help testing, so we can fix any remaining issues before the release, which is scheduled for July 30. Please also note that you can send pull requests for the next branch. Thanks to all. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To the systems programmer, users and applications serve only to provide a test load. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
With the code that skips the 5 msecond delay if the device is ready, my fat
load time went from 80 seconds to 8 seconds. This is actually fairly close
to what it takes to do the same transfer in Linux (5 seconds). So I assume
the 5 msdelay when the device is already ready is not necessary.
On Thu, Jul 26, 2012 at 8:43 PM, Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:
Hi Jim,
On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs every
10K of
data for fatload usb or 500ms of delay per 1MB of image size. This
adds up
to quite a bit of delay if you're loading a large ramdisk.
Does anyone know what the reason for the 5ms delay really is? I'm
assuming
that this delay is to debounce the 5V/100ma USB power up. I made
some
modification, where the delay is skipped if the device has already
been
queried as ready. This has save me 500ms/M on fatload times (eg,
140M=70seconds). Is there anything wrong with this tweak?
Here's a diff of what I've done to get the performance I need:
--- usb_storage.c.orig 2012-07-26 16:06:40.775251000 -0400
+++ usb_storage.c 2012-07-26 13:49:36.0 -0400
@@ -132,6 +132,7 @@ static block_dev_desc_t usb_dev_desc[USB
struct us_data;
typedef int (*trans_cmnd)(ccb *cb, struct us_data *data);
typedef int (*trans_reset)(struct us_data *data);
+typedef enum us_status { USB_NOT_READY, USB_READY} us_status;
struct us_data {
struct usb_device *pusb_dev; /* this usb_device */
@@ -154,6 +155,7 @@ struct us_data {
ccb *srb; /* current srb */
trans_reset transport_reset;/* reset routine */
trans_cmnd transport; /* transport routine
*/
+ us_status status;
};
static struct us_data usb_stor[USB_MAX_STOR_DEV];
@@ -691,7 +693,10 @@ int usb_stor_BBB_transport(ccb *srb, str
usb_stor_BBB_reset(us);
return USB_STOR_TRANSPORT_FAILED;
}
- wait_ms(5);
+ if(us-status != USB_READY)
+ {
+ wait_ms(5);
+ }
pipein = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
pipeout = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
/* DATA phase + error handling */
@@ -957,7 +962,10 @@ static int usb_test_unit_ready(ccb *srb,
srb-datalen = 0;
srb-cmdlen = 12;
if (ss-transport(srb, ss) ==
USB_STOR_TRANSPORT_GOOD)
+ {
+ ss-status = USB_READY;
return 0;
+ }
usb_request_sense(srb, ss);
wait_ms(100);
} while (retries--);
@@ -965,6 +973,11 @@ static int usb_test_unit_ready(ccb *srb,
return -1;
}
+static void usb_set_unit_not_ready(struct us_data *ss)
+{
+ ss-status = USB_NOT_READY;
+}
+
static int usb_read_capacity(ccb *srb, struct us_data *ss)
{
int retry;
@@ -1108,6 +1121,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(usb_read: end startblk %lx, blccnt %x buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1188,6 +1202,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(usb_write: end startblk %lx, blccnt %x
buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1398,6 +1413,7 @@ int usb_stor_get_info(struct usb_device
cap[0] = 2880;
cap[1] = 0x200;
}
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(Read Capacity returns: 0x%lx, 0x%lx\n,
cap[0],
cap[1]);
#if 0
I'd appreciate any feedback.
Regards
I have not looked into this delay issue, but I had similar performance
issues
that I fixed with the following series:
http://patchwork.ozlabs.org/patch/172052/
http://patchwork.ozlabs.org/patch/172204/
http://patchwork.ozlabs.org/patch/172054/
http://patchwork.ozlabs.org/patch/172055/
http://patchwork.ozlabs.org/patch/172056/
Your suggestion is interesting and might be a complement to my series. I
don't
have time to check its correctness right now, but I'll try soon.
Best regards,
Benoît
--
*James H Shimer*
Motorola Mobility T3-12-HH72
900 Chelmsford Street
Lowell MA 08151
978-614-3550
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: avoid Generating asm-offsets.h message with -s
make would spit out a message like Generating /tmp/build/include/generated/asm-offsets.h even when running with option -s. Fix this. Signed-off-by: Wolfgang Denk w...@denx.de --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index d57c15e..4356b22 100644 --- a/Makefile +++ b/Makefile @@ -617,7 +617,7 @@ $(obj)lib/asm-offsets.s:$(obj)include/autoconf.mk.dep \ $(obj)include/generated/asm-offsets.h: $(obj)include/autoconf.mk.dep \ $(obj)$(CPUDIR)/$(SOC)/asm-offsets.s - @echo Generating $@ + @$(XECHO) Generating $@ tools/scripts/make-asm-offsets $(obj)$(CPUDIR)/$(SOC)/asm-offsets.s $@ $(obj)$(CPUDIR)/$(SOC)/asm-offsets.s: $(obj)include/autoconf.mk.dep -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with running commands
On Tue Jul 03, 2012 at 12:54:04AM +0530, Sughosh Ganu wrote: hi, While testing on hawkboard with the latest commit, i hit an issue of commands not being accepted. hawkboard reset Unknown command '�' - try 'help' hawkboard Running git bisect showed that this is caused due to commit 054ea170f271: cmd_mem: cmp: unify size code paths. Has anyone seen this issue -- i don't think this is board/arch specific. Worked with my friend during the last week to figure out the issue. That he had a jtag debugger with him actually helped us track down the issue. The issue was that the board was using the wrong version of the nand_read_page function in spl -- we are supposed to use the page read version with oob read first, while the other version was being used. This resulted in corruptions being introduced in the u-boot image that was being copied from the nand. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
New abstraction layer for performing MMC and FAT operations has been added. It is necessary for using MMC and FAT operations from other subsystems without the need to call sprintf and run_command afterwards. MMC/FAT function call allows for better type checking during compilation time. For FAT, common code has been encapsulated to a separate function. Lukasz Majewski (2): mmc: New abstract function (do_mmcops_safe) for MMC subsystem fat: New abstract function (do_fat_safe) for FAT subsystem common/cmd_fat.c | 89 +++--- common/cmd_mmc.c | 69 ++--- common/env_fat.c | 20 +--- include/fat.h|7 include/mmc.h|9 + 5 files changed, 106 insertions(+), 88 deletions(-) -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mmc: New abstract function (do_mmcops_safe) for MMC subsystem
The new do_mmcops_safe function has been added to the mmc subsystem.
It is necessary to decouple the core mmc read/write operation from
code responsible for parsing user input.
The do_mmcops_safe function shall be used from other subsystems to
read/write data to MMC devices.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Andy Fleming aflem...@gmail.com
---
common/cmd_mmc.c | 69 +-
include/mmc.h|9 +++
2 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 750509d..60e6873 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -87,12 +87,6 @@ U_BOOT_CMD(
);
#else /* !CONFIG_GENERIC_MMC */
-enum mmc_state {
- MMC_INVALID,
- MMC_READ,
- MMC_WRITE,
- MMC_ERASE,
-};
static void print_mmcinfo(struct mmc *mmc)
{
printf(Device: %s\n, mmc-name);
@@ -148,7 +142,42 @@ U_BOOT_CMD(
);
-int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+u32 do_mmcops_safe(enum mmc_state state, int curr_device, u32 blk,
+ u32 cnt, void *addr)
+{
+ struct mmc *mmc = find_mmc_device(curr_device);
+ u32 n = 0;
+
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, curr_device);
+ return 1;
+ }
+
+ mmc_init(mmc);
+
+ switch (state) {
+ case MMC_READ:
+ n = mmc-block_dev.block_read(curr_device, blk,
+ cnt, addr);
+ /* flush cache after read */
+ flush_cache((ulong)addr, cnt * 512); /* FIXME */
+ break;
+ case MMC_WRITE:
+ n = mmc-block_dev.block_write(curr_device, blk,
+ cnt, addr);
+ break;
+ case MMC_ERASE:
+ n = mmc-block_dev.block_erase(curr_device, blk, cnt);
+ break;
+ default:
+ BUG();
+ }
+
+ return n;
+}
+
+int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
{
enum mmc_state state;
@@ -261,7 +290,6 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
state = MMC_INVALID;
if (state != MMC_INVALID) {
- struct mmc *mmc = find_mmc_device(curr_device);
int idx = 2;
u32 blk, cnt, n;
void *addr;
@@ -274,33 +302,10 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
blk = simple_strtoul(argv[idx], NULL, 16);
cnt = simple_strtoul(argv[idx + 1], NULL, 16);
- if (!mmc) {
- printf(no mmc device at slot %x\n, curr_device);
- return 1;
- }
-
printf(\nMMC %s: dev # %d, block # %d, count %d ... ,
argv[1], curr_device, blk, cnt);
- mmc_init(mmc);
-
- switch (state) {
- case MMC_READ:
- n = mmc-block_dev.block_read(curr_device, blk,
- cnt, addr);
- /* flush cache after read */
- flush_cache((ulong)addr, cnt * 512); /* FIXME */
- break;
- case MMC_WRITE:
- n = mmc-block_dev.block_write(curr_device, blk,
- cnt, addr);
- break;
- case MMC_ERASE:
- n = mmc-block_dev.block_erase(curr_device, blk, cnt);
- break;
- default:
- BUG();
- }
+ n = do_mmcops_safe(state, curr_device, blk, cnt, addr);
printf(%d blocks %s: %s\n,
n, argv[1], (n == cnt) ? OK : ERROR);
diff --git a/include/mmc.h b/include/mmc.h
index 2305986..5686e1b 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -199,6 +199,13 @@
#define PART_ACCESS_MASK (0x7)
#define PART_SUPPORT (0x1)
+enum mmc_state {
+ MMC_INVALID,
+ MMC_READ,
+ MMC_WRITE,
+ MMC_ERASE,
+};
+
struct mmc_cid {
unsigned long psn;
unsigned short oid;
@@ -274,6 +281,8 @@ int board_mmc_getcd(struct mmc *mmc);
int mmc_switch_part(int dev_num, unsigned int part_num);
int mmc_getcd(struct mmc *mmc);
+u32 do_mmcops_safe(enum mmc_state state, int curr_device, u32 blk,
+ u32 cnt, void *addr);
#ifdef CONFIG_GENERIC_MMC
#define mmc_host_is_spi(mmc) ((mmc)-host_caps MMC_MODE_SPI)
struct mmc *mmc_spi_init(uint bus, uint cs, uint speed, uint mode);
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH 2/2] fat: New abstract function (do_fat_safe) for FAT subsystem
The new do_fat_safe function has been added to the FAT handling command.
It is necessary to decouple the core fat command read/write operation from
code responsible for parsing user input.
The do_fat_safe function shall be used from other subsystems willing to
read/write data to FAT file system.
Due to code reorganization a common code has been removed from env_fat.c.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
common/cmd_fat.c | 89 +++---
common/env_fat.c | 20 +---
include/fat.h|7
3 files changed, 60 insertions(+), 56 deletions(-)
diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index 559a16d..a197393 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -32,6 +32,48 @@
#include part.h
#include fat.h
+long do_fat_safe(enum fat_op op, char *iname, char *file, int dev, int part,
+ void *addr, unsigned long count)
+{
+ block_dev_desc_t *dev_desc = NULL;
+ long size = 0;
+
+ dev_desc = get_dev(iname, dev);
+ if (dev_desc == NULL) {
+ puts(\n** Invalid boot device **\n);
+ return -1;
+ }
+
+ if (fat_register_device(dev_desc, part) != 0) {
+ printf(\n** Unable to use %s %d:%d for fat%s **\n,
+ iname, dev, part, op == FAT_READ ? load : write);
+ return -1;
+ }
+
+ switch (op) {
+ case FAT_READ:
+ size = file_fat_read(file, addr, count);
+ break;
+#ifdef CONFIG_FAT_WRITE
+ case FAT_WRITE:
+ size = file_fat_write(file, addr, count);
+ break;
+#endif
+ default:
+ puts(Operation not supported!\n);
+ return -1;
+ }
+
+ if (size == -1) {
+ printf(\n** Unable to %s \%s\ from %s %d:%d **\n,
+ op == FAT_READ ? read : write,
+ file, iname, dev, part);
+ return -1;
+ }
+ printf(%ld bytes %s\n, size, op == FAT_READ ? read : written);
+
+ return size;
+}
int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
@@ -39,7 +81,6 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
unsigned long offset;
unsigned long count;
char buf [12];
- block_dev_desc_t *dev_desc=NULL;
int dev=0;
int part=1;
char *ep;
@@ -51,11 +92,6 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
dev = (int)simple_strtoul(argv[2], ep, 16);
- dev_desc = get_dev(argv[1],dev);
- if (dev_desc == NULL) {
- puts(\n** Invalid boot device **\n);
- return 1;
- }
if (*ep) {
if (*ep != ':') {
puts(\n** Invalid boot device, use `dev[:part]' **\n);
@@ -63,25 +99,17 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
part = (int)simple_strtoul(++ep, NULL, 16);
}
- if (fat_register_device(dev_desc,part)!=0) {
- printf(\n** Unable to use %s %d:%d for fatload **\n,
- argv[1], dev, part);
- return 1;
- }
offset = simple_strtoul(argv[3], NULL, 16);
if (argc == 6)
count = simple_strtoul(argv[5], NULL, 16);
else
count = 0;
- size = file_fat_read(argv[4], (unsigned char *)offset, count);
- if(size==-1) {
- printf(\n** Unable to read \%s\ from %s %d:%d **\n,
- argv[4], argv[1], dev, part);
- return 1;
- }
+ size = do_fat_safe(FAT_READ, argv[1], argv[4], dev, part,
+(void *)offset, count);
- printf(\n%ld bytes read\n, size);
+ if (size == -1)
+ return 1;
sprintf(buf, %lX, size);
setenv(filesize, buf);
@@ -134,7 +162,7 @@ int do_fat_ls (cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
else
ret = file_fat_ls(filename);
- if(ret!=0)
+ if (ret != 0)
printf(No Fat FS detected\n);
return ret;
}
@@ -189,10 +217,9 @@ U_BOOT_CMD(
static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
{
- long size;
unsigned long addr;
unsigned long count;
- block_dev_desc_t *dev_desc = NULL;
+
int dev = 0;
int part = 1;
char *ep;
@@ -201,11 +228,6 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
return cmd_usage(cmdtp);
dev = (int)simple_strtoul(argv[2], ep, 16);
- dev_desc = get_dev(argv[1], dev);
- if (dev_desc == NULL) {
- puts(\n** Invalid boot device **\n);
- return 1;
-
Re: [U-Boot] [U-Boot-DM] List of offending drivers
Dear Wolfgang Denk, Dear Marek Vasut, In message 201207270118.19524.ma...@denx.de you wrote: Check the following list, it's the list of drivers scattered (misplaced) across the tree. The list is not complete and might be inaccurate. But it should give a good impression of what I'm going to break soon: [...] All these are either 1) old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this) Well, can they not be replaced either way? Someone will eventually complain if they care enough. or 2) very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories. Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later replaced with platform data) ? Best regards, Wolfgang Denk Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] List of offending drivers
Dear Lukasz Majewski, Dear Marek Vasut, board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are. That's fairy possible, I did only quick inspection and I'll be taking further look this weekend. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] i.MX28: bug fixes in PMU configuration code
Fixed some typos in the i.MX28 PMU code that sets up the VDDD and VDDIO power
rails. In addition the VDDD and VDDIO brownout offset values should be divided
by a step size before being programmed to the corresponding registers.
Signed-off-by: Stathis Voukelatos stathis.voukela...@linn.co.uk
Cc: Stefano Babic sba...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
---
Changes for v2:
- White space cleanup
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
index 4b09b0c..cc71af8 100644
--- arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
+++ arch/arm/cpu/arm926ejs/mx28/spl_power_init.c
@@ -716,7 +716,7 @@ int mx28_get_vddio_power_source_off(void)
tmp = readl(power_regs-hw_power_vddioctrl);
if (tmp POWER_VDDIOCTRL_DISABLE_FET) {
if ((tmp POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
- POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+ POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -724,7 +724,7 @@ int mx28_get_vddio_power_source_off(void)
if (!(readl(power_regs-hw_power_5vctrl)
POWER_5VCTRL_ENABLE_DCDC)) {
if ((tmp POWER_VDDIOCTRL_LINREG_OFFSET_MASK) ==
- POWER_VDDDCTRL_LINREG_OFFSET_0STEPS) {
+ POWER_VDDIOCTRL_LINREG_OFFSET_0STEPS) {
return 1;
}
}
@@ -772,7 +772,7 @@ void mx28_power_set_vddio(uint32_t new_target, uint32_t
new_brownout)
uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
- new_brownout = new_target - new_brownout;
+ new_brownout = (new_target - new_brownout + 25) / 50;
cur_target = readl(power_regs-hw_power_vddioctrl);
cur_target = POWER_VDDIOCTRL_TRG_MASK; @@ -858,8 +858,8 @@ void
mx28_power_set_vddio(uint32_t new_target, uint32_t new_brownout)
}
clrsetbits_le32(power_regs-hw_power_vddioctrl,
- POWER_VDDDCTRL_BO_OFFSET_MASK,
- new_brownout POWER_VDDDCTRL_BO_OFFSET_OFFSET);
+ POWER_VDDIOCTRL_BO_OFFSET_MASK,
+ new_brownout POWER_VDDIOCTRL_BO_OFFSET_OFFSET);
}
void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout) @@ -869,7
+869,7 @@ void mx28_power_set_vddd(uint32_t new_target, uint32_t new_brownout)
uint32_t cur_target, diff, bo_int = 0;
uint32_t powered_by_linreg = 0;
- new_brownout = new_target - new_brownout;
+ new_brownout = (new_target - new_brownout + 12) / 25;
cur_target = readl(power_regs-hw_power_vdddctrl);
cur_target = POWER_VDDDCTRL_TRG_MASK;
--
1.7.2.5
Stathis Voukelatos
Senior Software Engineer
Linn Products Ltd.
Glasgow Road
Eaglesham, Glasgow
G76 0EQ, UK
Tel: +44 (0)141 3035191
Email: stathis.voukela...@linn.co.uk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [SOLVED] Need help to get u-boot running on the taskit stamp9g20
On Tue, Jul 24, 2012 at 05:43:28PM +0200, Markus Hubig wrote: I looked at every single byte on the internet an I found some information that in order to get this bad-ass relocation to work, one needs to adapt at91bootstrap to work with u-boot. Could this be my problem? At the moment I'm using the original at91bootstrap from taskit. Here is what I think the problem could, maybe, be: 1. Board gets powered on. 2. at91bootstrap magically starts. 3. It reads IMG_SIZE from IMG_ADDRESS and writes it to JUMP_ADDR in RAM. - IMG_ADDRESS is where I write u-boot to inside NAND? - IMG_SIZE should be the size of u-boot.bin? (exactly or is a bigger size OK?) - JUMP_ADDR is where u-boot is relocated to in RAM. Should be CONFIG_SYS_TEXT_BASE? 4. at91bootstrap sets the PC to JUMP_ADDR and starts u-boot. Since IMG_SIZE in at91bootstrap is not the size of my new u-boot.bin it crashes after relocation! Year! This was exactly my problem! Building a new at91bootstrap with a bigger IMG_SIZE solved it. Now U-Boot starts up! Im getting closer to a patch! ;-) Cheers, Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] hawkboard: Fix SPL Nand driver misconfiguration
Hawkboard was using the wrong nand_read_page version for SPL image. As a side effect, the u-boot image loaded by the SPL from nand was getting corrupted. Enable CONFIG_SYS_NAND_HW_ECC_OOBFIRST to select the correct nand_read_page algorithm for SPL. Signed-off-by: Linu Cherian linucher...@gmail.com --- include/configs/hawkboard.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/hawkboard.h b/include/configs/hawkboard.h index c6e8859..c6e9ce5 100644 --- a/include/configs/hawkboard.h +++ b/include/configs/hawkboard.h @@ -123,6 +123,7 @@ #define CONFIG_SYS_NAND_USE_FLASH_BBT #define CONFIG_NAND_DAVINCI #define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST +#define CONFIG_SYS_NAND_HW_ECC_OOBFIRST /* SPL nand driver configuration */ #define CFG_DAVINCI_STD_NAND_LAYOUT #define CONFIG_SYS_NAND_CS 3 #define CONFIG_SYS_NAND_PAGE_2K -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Strange / Unreadable console output
Hi @all, one minor Problem I often read about in this list is some crappy / unreadable console output at beginning of the U-Boot start procedure. Now I have the same visual Problem. | H�NAND: 128 MiB | *** Warning - bad CRC, using default environment | | In:serial | Out: serial | Err: serial | Net: macb0 | macb0: Starting autonegotiation... | macb0: Autonegotiation timed out (status=0x7849) | macb0: link down (status: 0x7849) | Hit any key to stop autoboot: 0 | ... Sometimes I get a good readable output, which looks like so: | U-Boot 2012.04.01-3-gab465ef-dirty (Jul 23 2012 - 14:44:29) | | U-Boot code: 23F0 - 23F30464 BSS: - 23F72128 | CPU: AT91SAM9G20 | Crystal frequency: 18.432 MHz | CPU clock: 396.288 MHz | Master clock : 132.096 MHz | RAM Configuration: | Bank #0: 2000 64 MiB | WARNING: Caches not enabled | NAND: 128 MiB | ... Has anyone an ideea how to fix this? Or what's the cause of it? Is it even related to u-boot or is it something at91bootstrap is doing wrong? Cheers, Markus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] USB: EHCI: Initialize multiple USB controllers at once
Dear Jim Lin, Wolfgang, Is there any chance to get this feature in after Stephen explained to you? Thanks. [...] I'll poke into it. Can we not get rid of the added ifdef, eg. by setting up the controller number to 1 for those that don't define CONFIG_USB_MULTI now (everyone) and adding some wrapping goo? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
Dear Lukasz Majewski, In message 1343378116-5569-1-git-send-email-l.majew...@samsung.com you wrote: New abstraction layer for performing MMC and FAT operations has been added. It is necessary for using MMC and FAT operations from other subsystems without the need to call sprintf and run_command afterwards. MMC/FAT function call allows for better type checking during compilation time. For FAT, common code has been encapsulated to a separate function. Lukasz Majewski (2): mmc: New abstract function (do_mmcops_safe) for MMC subsystem fat: New abstract function (do_fat_safe) for FAT subsystem Sorry if I don't understand, but what exactly is special with MMC and FAT here? Why are the same changes as to the MMC code not also needed for example for the IDE, SATA, SCSI or USB code? Why are the same changes as for FAT not also needed for the other file systems? And what exactly are you changing anyway? The commit messages in the patches give neither sufficient information to understand why you make a change at all, nor how the new code is supposed to be used, nor in which way he is better (more safe ?) than the existing code? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You ain't experienced... Well, nor are you. That's true. But the point is ... the point is ... the point is we've been not experienced for a lot longer than you. We've got a lot of experience of not having any experience. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot-DM] List of offending drivers
Dear Marek Vasut, In message 201207271042.48099.ma...@denx.de you wrote: All these are either 1) old versions of flash drivers that predate the cfi flash implementation, so they could be replaced by the CFI driver (if there was someone to test this) Well, can they not be replaced either way? Someone will eventually complain if they care enough. No. I will not accept moving reduindant crap into the drivers/ hierarchy. If this is code that can be replaced by using the CFI driver, this reorganization is the point to do it. If the boards are uinmaintained, then so be it, we will remove broken stuff. 2) very special versions of flash drivers dealing with board specific details that prevent the use of the CFI flash driver, in which case they should remain in the board directories. Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later replaced with platform data) ? I don't see how this could be done, and it seems not worth the effort to me. I smell most of these are unmaintained boards, and it's easier to clean this up once for all. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Of course there's no reason for it, it's just our policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] hawkboard: Fix SPL Nand driver misconfiguration
On Fri Jul 27, 2012 at 01:51:53PM +0530, Linu Cherian wrote: Hawkboard was using the wrong nand_read_page version for SPL image. As a side effect, the u-boot image loaded by the SPL from nand was getting corrupted. Enable CONFIG_SYS_NAND_HW_ECC_OOBFIRST to select the correct nand_read_page algorithm for SPL. Signed-off-by: Linu Cherian linucher...@gmail.com Acked-by: Sughosh Ganu urwithsugh...@gmail.com Tom, since this is a bug fix, can this go to the 2012.07 release. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Board-specific commands unintentionally linked into SPL?
Hi Tyler/Christian, On Fri, Jul 27, 2012 at 00:24:20, Tyler Olmstead wrote: Hi Christian, On Thu, Jul 26, 2012 at 10:03 AM, Christian Riesch christian.rie...@omicron.at wrote: [cc'd Prabhakar Lad, Tom Rini, and Scott Wood] Tyler, On Thu, Jul 26, 2012 at 5:37 PM, Tyler Olmstead tyler.j.olmst...@gmail.com wrote: Hi all, I have encountered some issues adding a board-specific command to the board file of a project I have been working on. Specifically, after adding a U-Boot shell command to my board file, I have been seeing link-stage failures when attempting to build SPL. It's hard to tell without having your code, but I think this problem was already discussed in [1]. However I do not remember how Prabhakar solved it in the end. #ifndef CONFIG_SPL_BUILD solved my problem. Thx, --Prabhakar Lad Yes, I ran into this thread while debugging the problem, which ultimately lead me to my solution. From that same thread [1], Wolfgang Denk writes: quote *I want to add a command using U_BOOT_CMD in uboot, where SPL_BUILD is enabled for example for da850evm in spl frame work how can i do that * This makes no sense. Commands can only be executed when we have full U-Boot running (actually even only after relocation). You cannot run commands in the SPL. /quote I understand of course why it makes no sense to have command support in the SPL. However, the crux of this problem is that U-Boot and SPL both link in the same board object file, so in that sense compile-time switches wont work. From later in [1], Scott Wood writes: quote Maybe we should poke command.h to nop out U_BOOT_CMD for CONFIG_SPL_BUILD? OTOH, #ifndef'ing U_BOOT_CMD and the code itself gets us a space savings we wouldn't get otherwise (I suspect giving the MTD/NAND issue I've mentioned before)... Commands should be stripped out already with the new SPL -- that's what the (unfortunately uncommented) sed command in GEN_UBOOT appears to be doing. -Scott /quote Unfortunately, this is incorrect. From the ld man page [2]: -u symbol --undefined=symbol Force symbol to be entered in the output file as an undefined symbol. Doing this may, for example, trigger linking of additional modules from standard libraries. -u may be repeated with different option arguments to enter additional undefined symbols. This option is equivalent to the EXTERN linker script command. Which means that the sed command in GEN_UBOOT in the SPL makefile actually forces the *inclusion* of the command table, and therefore forces the resolution of any undefined symbols in the command function (hence my problem). This same command also appears in the top-level U-Boot makefile, and I find it likely that it was included in the SPL makefile as the result of a copy-paste error. This problem would only arise for commands in object files that are linked into the SPL image, such as the board file. -- Tyler [2] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld In [1] I suggested to put an #ifndef CONFIG_SPL_BUILD U_BOOT_CMD( ... ); #endif around the command definition in the board file. But also other solutions were discussed in that thread, please have a look. Regards, Christian [1] http://marc.info/?t=13274854893 snip UNDEF_SYM=`arm-arago-linux-gnueabi-objdump -x /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/davinci/libdavinci.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/cpu/arm926ejs/libarm926ejs.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/libarm.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/board/davinci/da8xxevm/libda8xxevm.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/mtd/nand/libnand.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/drivers/serial/libserial.o /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/lib/libgeneric.o | sed -n -e 's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`; cd /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/ arm-arago-linux-gnueabi-ld -T /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/u-boot-spl.lds --gc-sections -Bstatic -Ttext 0xc108 $UNDEF_SYM arch/arm/cpu/arm926ejs/start.o --start-group arch/arm/cpu/arm926ejs/davinci/libdavinci.o arch/arm/cpu/arm926ejs/libarm926ejs.o arch/arm/lib/libarm.o board/davinci/da8xxevm/libda8xxevm.o drivers/mtd/nand/libnand.o drivers/serial/libserial.o lib/libgeneric.o --end-group /home/tolmstead/tolmstead_lab-OptiPlex-380/uboot/uboot_nand/spl/arch/arm/lib/eabi_compat.o -L /usr/local/ti-sdk-am180x-evm/linux-devkit/bin/../lib/gcc/arm-arago-linux-gnueabi/4.3.3 -lgcc -Map u-boot-spl.map -o u-boot-spl board/davinci/da8xxevm/libda8xxevm.o: In function `do_mycmd':
Re: [U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
Dear Wolfgang Denk, Dear Lukasz Majewski, In message 1343378116-5569-1-git-send-email-l.majew...@samsung.com you wrote: New abstraction layer for performing MMC and FAT operations has been added. It is necessary for using MMC and FAT operations from other subsystems without the need to call sprintf and run_command afterwards. MMC/FAT function call allows for better type checking during compilation time. For FAT, common code has been encapsulated to a separate function. Lukasz Majewski (2): mmc: New abstract function (do_mmcops_safe) for MMC subsystem fat: New abstract function (do_fat_safe) for FAT subsystem Sorry if I don't understand, but what exactly is special with MMC and FAT here? Those patches are a follow up of a discussion about DFU support in u-boot. [PATCH 4/7] dfu: MMC specific routines for DFU operation http://article.gmane.org/gmane.comp.boot-loaders.u-boot/134401/match=dfu+mmc+specific+routines+dfu+operation In short - during this discussion it has been suggested, that sprintf() + run_command() call shall be replaced with a _safe function call, which decouples real e.g. MMC write from parsing user data from prompt. Why are the same changes as to the MMC code not also needed for example for the IDE, SATA, SCSI or USB code? I need the FAT and MMC for DFU patches, on which I work now. Those patches (actually v2) have already been posted to ML and are under review. Why are the same changes as for FAT not also needed for the other file systems? It is because DFU is not supporting other file systems for now. I only changed the code which I use. And what exactly are you changing anyway? The commit messages in the patches give neither sufficient information to understand why you make a change at all, nor how the new code is supposed to be used, nor in which way he is better (more safe ?) than the existing code? The problem is as follows: 1. DFU patches requires access to FAT and MMC 2. I'm using sprintf() + run_command() approach to execute e.g. mmc write 0x4400 60 100 to store data from DFU in a proper place. 3. The approach presented at 2. was under discussion on ML. Reviewers suggested, that run_command() approach is unsafe and for compilation time type checking I shall write mmc with using special _safe function. For more details, please visit link, which I've posted. In this discussion we are arguing about pros and cons of using sprintf + run_command approach. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] DaVinci DA8xx: fix set_cpu_clk_info()
For the DA8xx family of SoCs, the set_cpu_clk_info() function was not
initialising the DSP frequency, leading to 'bdinfo' command output such as:
[...snip...]
ARM frequency = 300 MHz
DSP frequency = -536870913 MHz
DDR frequency = 300 MHz
This commit provides a separate implementation of set_cpu_clk_info() for
the DA8xx SoCs that initialises the DSP frequency to zero (since
currently the DSP is not enabled by U-Boot on any DA8xx platform). The
separate implementation is justified because there is no common code
between DA8xx and the other SoC families. It is now much easier to
understand the flow of the two separate functions.
Signed-off-by: Laurence Withers lwith...@guralp.com
Cc: Tom Rini tr...@ti.com
Cc: Hadli, Manjunath manjunath.ha...@ti.com
Cc: Heiko Schocher h...@denx.de
---
arch/arm/cpu/arm926ejs/davinci/cpu.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/cpu.c
b/arch/arm/cpu/arm926ejs/davinci/cpu.c
index 6cb857a..4bdb08b 100644
--- a/arch/arm/cpu/arm926ejs/davinci/cpu.c
+++ b/arch/arm/cpu/arm926ejs/davinci/cpu.c
@@ -117,6 +117,16 @@ int clk_get(enum davinci_clk_ids id)
out:
return pll_out;
}
+
+int set_cpu_clk_info(void)
+{
+ gd-bd-bi_arm_freq = clk_get(DAVINCI_ARM_CLKID) / 100;
+ /* DDR PHY uses an x2 input clock */
+ gd-bd-bi_ddr_freq = clk_get(0x10001) / 100;
+ gd-bd-bi_dsp_freq = 0;
+ return 0;
+}
+
#else /* CONFIG_SOC_DA8XX */
static unsigned pll_div(volatile void *pllbase, unsigned offset)
@@ -187,16 +197,9 @@ unsigned int davinci_clk_get(unsigned int div)
return pll_sysclk_mhz(DAVINCI_PLL_CNTRL0_BASE, div) * 100;
}
#endif
-#endif /* !CONFIG_SOC_DA8XX */
int set_cpu_clk_info(void)
{
-#ifdef CONFIG_SOC_DA8XX
- gd-bd-bi_arm_freq = clk_get(DAVINCI_ARM_CLKID) / 100;
- /* DDR PHY uses an x2 input clock */
- gd-bd-bi_ddr_freq = clk_get(0x10001) / 100;
-#else
-
unsigned int pllbase = DAVINCI_PLL_CNTRL0_BASE;
#if defined(CONFIG_SOC_DM365)
pllbase = DAVINCI_PLL_CNTRL1_BASE;
@@ -215,10 +218,12 @@ int set_cpu_clk_info(void)
pllbase = DAVINCI_PLL_CNTRL0_BASE;
#endif
gd-bd-bi_ddr_freq = pll_sysclk_mhz(pllbase, DDR_PLLDIV) / 2;
-#endif
+
return 0;
}
+#endif /* !CONFIG_SOC_DA8XX */
+
/*
* Initializes on-chip ethernet controllers.
* to override, implement board_eth_init()
--
1.7.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
Dear Lukasz Majewski, In message 20120727123832.69195dcd@amdc308.digital.local you wrote: Sorry if I don't understand, but what exactly is special with MMC and FAT here? Those patches are a follow up of a discussion about DFU support in u-boot. [PATCH 4/7] dfu: MMC specific routines for DFU operation OK, I see. Guess I will have to start reading these patches then (which I didn't so far). In short - during this discussion it has been suggested, that sprintf() + run_command() call shall be replaced with a _safe function call, which decouples real e.g. MMC write from parsing user data from prompt. ... I need the FAT and MMC for DFU patches, on which I work now. Those patches (actually v2) have already been posted to ML and are under review. This makes no sense to me. MMC is just one of the storagte devices we support, and especially with the upcoming support of a clean device model it makes no sense to handle it special in any way. The same holds for FAT - it is just one out of a number of file systems we support, and it makes no sense to add any code to FAT support that makes it incompatible with other file systems. Any such addition should be implemented in a generic way, that is agnostic of the underlying storage device and the file system used on top of it. It is OK if you then test with one combination only, but the implementation shall be generic. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Intel's new motto: United we stand. Divided we fall! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
Dear Wolfgang Denk, Dear Lukasz Majewski, In message 20120727123832.69195dcd@amdc308.digital.local you wrote: Sorry if I don't understand, but what exactly is special with MMC and FAT here? Those patches are a follow up of a discussion about DFU support in u-boot. [PATCH 4/7] dfu: MMC specific routines for DFU operation OK, I see. Guess I will have to start reading these patches then (which I didn't so far). In short - during this discussion it has been suggested, that sprintf() + run_command() call shall be replaced with a _safe function call, which decouples real e.g. MMC write from parsing user data from prompt. ... I need the FAT and MMC for DFU patches, on which I work now. Those patches (actually v2) have already been posted to ML and are under review. This makes no sense to me. MMC is just one of the storagte devices we support, and especially with the upcoming support of a clean device model it makes no sense to handle it special in any way. Sure, but that might still be a release or so away. So let's not hinder people from doing so, rather let's coordinate. Also, I consider there patches helpful, as we can use that abstraction during the DM work. The same holds for FAT - it is just one out of a number of file systems we support, and it makes no sense to add any code to FAT support that makes it incompatible with other file systems. It's not incompatible, how? Any such addition should be implemented in a generic way, that is agnostic of the underlying storage device and the file system used on top of it. Should, that's the proper word here. It isn't in most of FSs in uboot though and I think this is better than nothing. It is OK if you then test with one combination only, but the implementation shall be generic. I still consider it better than nothing -- if we have to pick this up and tear it apart during the DM, it's also OK, because we will easily figure out what parts to put where. So I'm quite fine with these patches. Best regards, Wolfgang Denk Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
Dear Marek, In message 201207271330.46967.ma...@denx.de you wrote: This makes no sense to me. MMC is just one of the storagte devices we support, and especially with the upcoming support of a clean device model it makes no sense to handle it special in any way. Sure, but that might still be a release or so away. So let's not hinder people from doing so, rather let's coordinate. Also, I consider there patches helpful, as we can use that abstraction during the DM work. Fine. But why adding special code to only one storage media, and one file system type? The same holds for FAT - it is just one out of a number of file systems we support, and it makes no sense to add any code to FAT support that makes it incompatible with other file systems. It's not incompatible, how? I cannot use - say - a USB storage device instead of MMC. Why is this so? I will reply to that in the context of the DFU thread, it makes more sense there. Any such addition should be implemented in a generic way, that is agnostic of the underlying storage device and the file system used on top of it. Should, that's the proper word here. It isn't in most of FSs in uboot though and I think this is better than nothing. Wrong. Adding special code to one file system which makes it special compared to other file systems is actually really, really bad. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Romulan women are not like Vulcan females. We are not dedicated to pure logic and the sterility of non-emotion. -- Romulan Commander, The Enterprise Incident, stardate 5027.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
Dear Wolfgang Denk, Dear Marek, In message 201207271330.46967.ma...@denx.de you wrote: This makes no sense to me. MMC is just one of the storagte devices we support, and especially with the upcoming support of a clean device model it makes no sense to handle it special in any way. Sure, but that might still be a release or so away. So let's not hinder people from doing so, rather let's coordinate. Also, I consider there patches helpful, as we can use that abstraction during the DM work. Fine. But why adding special code to only one storage media, and one file system type? Well, that's other thing. But I hope Lukasz will eventually extend this work over other media as the DFU gains support for more stuff. Right, Lukasz? The same holds for FAT - it is just one out of a number of file systems we support, and it makes no sense to add any code to FAT support that makes it incompatible with other file systems. It's not incompatible, how? I cannot use - say - a USB storage device instead of MMC. Not _yet_ . Why is this so? Because it's not implemented yet. I will reply to that in the context of the DFU thread, it makes more sense there. Any such addition should be implemented in a generic way, that is agnostic of the underlying storage device and the file system used on top of it. Should, that's the proper word here. It isn't in most of FSs in uboot though and I think this is better than nothing. Wrong. Adding special code to one file system which makes it special compared to other file systems is actually really, really bad. I hope it'll not only be fat over the time. Best regards, Wolfgang Denk Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] dfu: DFU backend implementation
Dear Lukasz Majewski,
In message 1341416922-13792-4-git-send-email-l.majew...@samsung.com you wrote:
New, separate driver at ./drivers/dfu has been added. It allows platform
and storage independent operation of DFU.
Sorry for a probably stupid question, but I know basicly zero about
DFU. We are talking about storage independent here. Does this
also mean file system independent?
+static char *dfu_get_dev_type(enum dfu_device_type t)
+{
+ static char *dev_t[] = {NULL, MMC, ONENAND, NAND };
+ return dev_t[t];
+}
So this currently supports MMC, OneNAND and NAND as storage devices?
+static char *dfu_get_layout(enum dfu_device_type l)
+{
+ static char *dfu_layout[] = {NULL, RAW_ADDR, FAT, EXT };
+ return dfu_layout[l];
+}
And FAT (or VFAT?) and EXT (as in EXT2? or EXT3? or ... ?) as file
systems?
+enum dfu_device_type {
+ MMC = 1,
+ ONENAND,
+ NAND
+};
+
+enum dfu_layout {
+ RAW_ADDR = 1,
+ FAT,
+ EXT,
+};
MMC, NAND, FAT and EXT are very generic names that heavily pollute on
the global name space. Please chose more specific names, probaly also
indicating the meaning (EXT could be some extension or external or
whatever - the name does not indicate that this is a file system type
here.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is your destiny. - Darth Vader
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] New abstraction layer for handling MMC and FAT commands
Dear Marek Vasut, Dear Wolfgang Denk, Dear Lukasz Majewski, In message 20120727123832.69195dcd@amdc308.digital.local you wrote: Sorry if I don't understand, but what exactly is special with MMC and FAT here? Those patches are a follow up of a discussion about DFU support in u-boot. [PATCH 4/7] dfu: MMC specific routines for DFU operation OK, I see. Guess I will have to start reading these patches then (which I didn't so far). In short - during this discussion it has been suggested, that sprintf() + run_command() call shall be replaced with a _safe function call, which decouples real e.g. MMC write from parsing user data from prompt. ... I need the FAT and MMC for DFU patches, on which I work now. Those patches (actually v2) have already been posted to ML and are under review. This makes no sense to me. MMC is just one of the storagte devices we support, and especially with the upcoming support of a clean device model it makes no sense to handle it special in any way. Sure, but that might still be a release or so away. So let's not hinder people from doing so, rather let's coordinate. Also, I consider there patches helpful, as we can use that abstraction during the DM work. The same holds for FAT - it is just one out of a number of file systems we support, and it makes no sense to add any code to FAT support that makes it incompatible with other file systems. It's not incompatible, how? Any such addition should be implemented in a generic way, that is agnostic of the underlying storage device and the file system used on top of it. Should, that's the proper word here. It isn't in most of FSs in uboot though and I think this is better than nothing. It is OK if you then test with one combination only, but the implementation shall be generic. I still consider it better than nothing -- if we have to pick this up and tear it apart during the DM, it's also OK, because we will easily figure out what parts to put where. So I'm quite fine with these patches. Nice to hear. Anyway I think, that we shall wait for Wolfgang's opinion. -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation
Dear Lukasz Majewski,
In message 1341416922-13792-5-git-send-email-l.majew...@samsung.com you wrote:
Support for MMC storage devices to work with DFU framework.
Sorry for jumping in late.
+ switch (dfu-layout) {
+ case RAW_ADDR:
+ sprintf(cmd_buf, mmc write 0x%x %x %x, (unsigned int) buf,
+ dfu-data.mmc.lba_start, dfu-data.mmc.lba_size);
+ break;
+ case FAT:
+ sprintf(cmd_buf, fatwrite mmc %d:%d 0x%x %s %lx,
+ dfu-data.mmc.dev, dfu-data.mmc.part,
+ (unsigned int) buf, dfu-name, *len);
+ break;
+ default:
+ printf(%s: Wrong layout!\n, __func__);
+ }
In case of error, you should always print what the unexpected data
was. The end user who receives an Wrong layout! error is probably
pretty much surpised and doesn't know what he did wrong. If you
print instead: EXT2 layout not supported (yet) he would know exactly
what to change to make it work.
There has been some dicussion already if using this sprintf() /
run_command() approach is good or not, or how it should be fixed.
It appears, all this discussion forgot to take into account that
patch 3/7 dfu: DFU backend implementation promised to add platform
and storage independent operation of DFU. Here we are breaking this
promise.
And by adding special functions to the FAT file system code thing sget
just worse, as now not only the DFU code needs to be extended when we
want to use this with any other file system type, but suddenly this
also bleeds into all supported file system code.
I am aware that the current implementation suffers from the fact that
we don't have a unified access to file systems - each comes with it's
own set of commands and more or less (in)compatible command line and
function call interfaces. This will hopefully improve in the context
of the device model rework, but we don't want to block you until then.
But considering that this is going to change in a foreseeable future,
it also makes littel sense to invest big efforts into generic code
that covers all potential future uses.
Here is my poposal:
Let's introduce a thin shim layer to abstract the file system
interface from the accesses you need here. As far as I can see here,
you need exactly 4 functions:
- block_read()
- block_write()
- file_read()
- file_write()
These names could be function pointers to implement the device I/O in
a both device and file system agnostic way; you can implement
specific versions of the functions like mmc_block_read(),
usb_block_read(), ... etc. and use the settings of dfu_device_type
and dfu_layout to set the pointers to these functions.
For this shim layer I would actually prefer the original approach
(shown above) to use sprintf() to build commands based on the existing
command interface - this is the minimal intrusive way to implement
this for now. With this approach, no modifications to file system
and/or device driver code are needed, and we still maintain full
flexibility here in the DFU code. Yes, error checking may not be
perfect, and we my not win a price for elegance of design either, but
we should get mostly clean, working code quickly.
The advantage I see for this code is that we have separated all
this device interface stuff from both the generic DFU code and from
the device and file system code as well. As soon as we have a better
implementation below, all we need to adjust (or potentially even
remove) is this shim layer.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
To the systems programmer, users and applications serve only to
provide a test load.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation
Dear Wolfgang Denk,
Dear Lukasz Majewski,
In message 1341416922-13792-5-git-send-email-l.majew...@samsung.com you
wrote:
Support for MMC storage devices to work with DFU framework.
Sorry for jumping in late.
+ switch (dfu-layout) {
+ case RAW_ADDR:
+ sprintf(cmd_buf, mmc write 0x%x %x %x, (unsigned int) buf,
+ dfu-data.mmc.lba_start, dfu-data.mmc.lba_size);
+ break;
+ case FAT:
+ sprintf(cmd_buf, fatwrite mmc %d:%d 0x%x %s %lx,
+ dfu-data.mmc.dev, dfu-data.mmc.part,
+ (unsigned int) buf, dfu-name, *len);
+ break;
+ default:
+ printf(%s: Wrong layout!\n, __func__);
+ }
In case of error, you should always print what the unexpected data
was. The end user who receives an Wrong layout! error is probably
pretty much surpised and doesn't know what he did wrong. If you
print instead: EXT2 layout not supported (yet) he would know exactly
what to change to make it work.
There has been some dicussion already if using this sprintf() /
run_command() approach is good or not, or how it should be fixed.
It appears, all this discussion forgot to take into account that
patch 3/7 dfu: DFU backend implementation promised to add platform
and storage independent operation of DFU. Here we are breaking this
promise.
And by adding special functions to the FAT file system code thing sget
just worse, as now not only the DFU code needs to be extended when we
want to use this with any other file system type, but suddenly this
also bleeds into all supported file system code.
I am aware that the current implementation suffers from the fact that
we don't have a unified access to file systems - each comes with it's
own set of commands and more or less (in)compatible command line and
function call interfaces. This will hopefully improve in the context
of the device model rework, but we don't want to block you until then.
But considering that this is going to change in a foreseeable future,
it also makes littel sense to invest big efforts into generic code
that covers all potential future uses.
Here is my poposal:
Let's introduce a thin shim layer to abstract the file system
interface from the accesses you need here. As far as I can see here,
you need exactly 4 functions:
- block_read()
- block_write()
- file_read()
- file_write()
These names could be function pointers to implement the device I/O in
a both device and file system agnostic way; you can implement
specific versions of the functions like mmc_block_read(),
usb_block_read(), ... etc. and use the settings of dfu_device_type
and dfu_layout to set the pointers to these functions.
For this shim layer I would actually prefer the original approach
(shown above) to use sprintf() to build commands based on the existing
command interface
We discussed it for a while ... figure out the missing typechecking and abuse
of
the command line interface is not a way to go.
this is the minimal intrusive way to implement
this for now. With this approach, no modifications to file system
and/or device driver code are needed, and we still maintain full
flexibility here in the DFU code. Yes, error checking may not be
perfect, and we my not win a price for elegance of design either, but
we should get mostly clean, working code quickly.
But now that we started going in the typechecking way, I'd prefer to go all the
way. And once DFU extends properly towards other supported filesystems/devices,
the rest of the interface can get cleaned along the way.
The advantage I see for this code is that we have separated all
this device interface stuff from both the generic DFU code and from
the device and file system code as well. As soon as we have a better
implementation below, all we need to adjust (or potentially even
remove) is this shim layer.
Shim layer is cool -- abusing command line is not cool ;-)
Best regards,
Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ehci-hcd: Boost transfer speed
Dear Benoît Thébaudeau,
This patch takes advantage of the hardware EHCI qTD queuing mechanism to
avoid software overhead and to make transfers as fast as possible.
The only drawback is a call to memalign. However, this is fast compared to
the transfer timings, and the heap size to allocate is small, e.g. a
little bit more than 100 kB for a transfer length of 65535 packets of 512
bytes.
Tested on i.MX25 and i.MX35. In my test conditions, the speedup was about
15x using page-aligned buffers, which is really appreciable when accessing
large files.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Marek Vasut ma...@denx.de
Cc: Ilya Yanok ilya.ya...@cogentembedded.com
Cc: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
---
.../drivers/usb/host/ehci-hcd.c| 94
++-- 1 file changed, 65 insertions(+), 29 deletions(-)
diff --git u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c index 5b3b906..b5645fa
100644
--- u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
+++ u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c
@@ -208,7 +208,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long
pipe, void *buffer, int length, struct devrequest *req)
{
ALLOC_ALIGN_BUFFER(struct QH, qh, 1, USB_DMA_MINALIGN);
- ALLOC_ALIGN_BUFFER(struct qTD, qtd, 3, USB_DMA_MINALIGN);
+ struct qTD *qtd;
+ int qtd_count = 0;
int qtd_counter = 0;
volatile struct qTD *vtd;
@@ -229,8 +230,25 @@ ehci_submit_async(struct usb_device *dev, unsigned
long pipe, void *buffer, le16_to_cpu(req-value), le16_to_cpu(req-value),
le16_to_cpu(req-index));
+ if (req != NULL)/* SETUP + ACK */
+ qtd_count += 1 + 1;
+ if (length 0 || req == NULL) {/* buffer */
+ if ((uint32_t)buffer 4095)/* page-unaligned */
+ qtd_count += (((uint32_t)buffer 4095) + length +
+ (QT_BUFFER_CNT - 1) * 4096 - 1) /
+ ((QT_BUFFER_CNT - 1) * 4096);
Ok, maybe you can please elaborate on this crazy calculation in here? Or
somehow
clarify it? Also, won't the macros in include/common.h help in a way? (like
ROUND() etc).
I don't really graps what you're trying to calculate here, so maybe even a
comment would help.
+ else/* page-aligned */
+ qtd_count += (length + QT_BUFFER_CNT * 4096 - 1) /
+ (QT_BUFFER_CNT * 4096);
Same here, also please avoid using those 4096 and such constants ... maybe
#define them in ehci.h ?
+ }
+ qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
So your code can alloc more than 5 qTDs ? How does it chain them then? Into
more
QHs ?
+ if (qtd == NULL) {
+ printf(unable to allocate TDs\n);
+ return -1;
+ }
+
memset(qh, 0, sizeof(struct QH));
- memset(qtd, 0, 3 * sizeof(*qtd));
+ memset(qtd, 0, qtd_count * sizeof(*qtd));
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe), usb_pipeout(pipe));
@@ -291,31 +309,46 @@ ehci_submit_async(struct usb_device *dev, unsigned
long pipe, void *buffer, }
if (length 0 || req == NULL) {
- /*
- * Setup request qTD (3.5 in ehci-r10.pdf)
- *
- * qt_next 03-00 H
- * qt_altnext . 07-04 H
- * qt_token ... 0B-08 H
- *
- * [ buffer, buffer_hi ] loaded with buffer.
- */
- qtd[qtd_counter].qt_next = cpu_to_hc32(QT_NEXT_TERMINATE);
- qtd[qtd_counter].qt_altnext = cpu_to_hc32(QT_NEXT_TERMINATE);
- token = (toggle 31) |
- (length 16) |
- ((req == NULL ? 1 : 0) 15) |
- (0 12) |
- (3 10) |
- ((usb_pipein(pipe) ? 1 : 0) 8) | (0x80 0);
- qtd[qtd_counter].qt_token = cpu_to_hc32(token);
- if (ehci_td_buffer(qtd[qtd_counter], buffer, length) != 0) {
- printf(unable construct DATA td\n);
- goto fail;
- }
- /* Update previous qTD! */
- *tdp = cpu_to_hc32((uint32_t)qtd[qtd_counter]);
- tdp = qtd[qtd_counter++].qt_next;
+ uint8_t *buf_ptr = buffer;
+ int left_length = length;
+
+ do {
+ int xfr_bytes = min(left_length,
+ (QT_BUFFER_CNT * 4096 -
+ ((uint32_t)buf_ptr 4095))
+ ~4095);
Magic formula yet again ... comment would again be welcome please.
+
Re: [U-Boot] [PATCH 4/5] usb_storage: Restore non-EHCI support
Dear Benoît Thébaudeau, The commit 5dd95cf made the MSC driver EHCI-specific. This patch restores a basic support of non-EHCI HCDs, like before that commit. The fallback transfer size is certainly not optimal, but at least it should work like before. [...] Please merge this with 3/5 or swap them, so this doesn't break bisect please. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] usb_storage: Adjust time-outs
Dear Benoît Thébaudeau, Adjust time-out value for the new EHCI mechanism. [...] Ok, I really like this set. I believe it's only one or two reposts away from upstream and I'd love to have it in next release (not this one, as we can't test it in 3 days). I admit I'm not the easiest and fastest custodian, so pardon me at that. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation
Dear Marek Vasut, In message 201207271443.45189.ma...@denx.de you wrote: For this shim layer I would actually prefer the original approach (shown above) to use sprintf() to build commands based on the existing command interface We discussed it for a while ... figure out the missing typechecking and abuse of the command line interface is not a way to go. I agree that this is not the preferred way for a permanent solution, but for now I cxonsider it acceptable, as it allows to easily deal with the inconsistent API of the misc file system handlers. For example instead of sprintf(cmd_buf, fatread mmc %d:%d 0x%x %s %lx, ... we can even do something like sprintf(cmd_buf, %s %s %d:%d 0x%x %s %lx, command, device, ... and set command as needed to fatread or ext2load or whatever, and device can be set to mmc or usb or ... this is the minimal intrusive way to implement this for now. With this approach, no modifications to file system and/or device driver code are needed, and we still maintain full flexibility here in the DFU code. Yes, error checking may not be perfect, and we my not win a price for elegance of design either, but we should get mostly clean, working code quickly. But now that we started going in the typechecking way, I'd prefer to go all the way. And once DFU extends properly towards other supported filesystems/devices, the rest of the interface can get cleaned along the way. You can implement the type checking code when you hav ea stable, well define API for storage devices and file systems. For now we don't have that, and it makes ZERO sense to add special code just for that just to throw it away in a few weeks. Shim layer is cool -- abusing command line is not cool ;-) Whether this is abuse or clever use remains to be defined, and this is probably largely a matter of taste. In any case, this will be a small piece of code that is of clearly transient nature, to be replaced or removed as soon as we can do better. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The nice thing about standards is that there are so many to choose from. - Andrew S. Tanenbaum ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
Dear Benoît Thébaudeau,
Hi Jim,
On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs every
10K of
data for fatload usb or 500ms of delay per 1MB of image size. This
adds up
to quite a bit of delay if you're loading a large ramdisk.
Does anyone know what the reason for the 5ms delay really is? I'm
assuming
that this delay is to debounce the 5V/100ma USB power up. I made
some
modification, where the delay is skipped if the device has already
been
queried as ready. This has save me 500ms/M on fatload times (eg,
140M=70seconds). Is there anything wrong with this tweak?
Here's a diff of what I've done to get the performance I need:
--- usb_storage.c.orig 2012-07-26 16:06:40.775251000 -0400
+++ usb_storage.c 2012-07-26 13:49:36.0 -0400
@@ -132,6 +132,7 @@ static block_dev_desc_t usb_dev_desc[USB
struct us_data;
typedef int (*trans_cmnd)(ccb *cb, struct us_data *data);
typedef int (*trans_reset)(struct us_data *data);
+typedef enum us_status { USB_NOT_READY, USB_READY} us_status;
struct us_data {
struct usb_device *pusb_dev; /* this usb_device */
@@ -154,6 +155,7 @@ struct us_data {
ccb *srb; /* current srb */
trans_reset transport_reset;/* reset routine */
trans_cmnd transport; /* transport routine
*/
+ us_status status;
};
static struct us_data usb_stor[USB_MAX_STOR_DEV];
@@ -691,7 +693,10 @@ int usb_stor_BBB_transport(ccb *srb, str
usb_stor_BBB_reset(us);
return USB_STOR_TRANSPORT_FAILED;
}
- wait_ms(5);
+ if(us-status != USB_READY)
+ {
+ wait_ms(5);
+ }
pipein = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
pipeout = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
/* DATA phase + error handling */
@@ -957,7 +962,10 @@ static int usb_test_unit_ready(ccb *srb,
srb-datalen = 0;
srb-cmdlen = 12;
if (ss-transport(srb, ss) ==
USB_STOR_TRANSPORT_GOOD)
+ {
+ ss-status = USB_READY;
return 0;
+ }
usb_request_sense(srb, ss);
wait_ms(100);
} while (retries--);
@@ -965,6 +973,11 @@ static int usb_test_unit_ready(ccb *srb,
return -1;
}
+static void usb_set_unit_not_ready(struct us_data *ss)
+{
+ ss-status = USB_NOT_READY;
+}
+
static int usb_read_capacity(ccb *srb, struct us_data *ss)
{
int retry;
@@ -1108,6 +1121,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(usb_read: end startblk %lx, blccnt %x buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1188,6 +1202,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(usb_write: end startblk %lx, blccnt %x
buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1398,6 +1413,7 @@ int usb_stor_get_info(struct usb_device
cap[0] = 2880;
cap[1] = 0x200;
}
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(Read Capacity returns: 0x%lx, 0x%lx\n,
cap[0],
cap[1]);
#if 0
I'd appreciate any feedback.
Regards
I have not looked into this delay issue, but I had similar performance
issues that I fixed with the following series:
http://patchwork.ozlabs.org/patch/172052/
http://patchwork.ozlabs.org/patch/172204/
http://patchwork.ozlabs.org/patch/172054/
http://patchwork.ozlabs.org/patch/172055/
http://patchwork.ozlabs.org/patch/172056/
Your suggestion is interesting and might be a complement to my series. I
don't have time to check its correctness right now, but I'll try soon.
Will you two have time to work these into V2 of your series somehow please?
Best regards,
Benoît
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building u-boot for iMX28 and getting error in mkimage of missing command line parameter CONFIG_IMX_CONFIG
Thanks. That did it! However, now my new U-boot built from the mainstream Uboot runs and also loads and unpacks the Linux kernel - but it dies after that. However, my original U-boot from tlib works fine. Are there some patches and/or settings I am missing? Thanks, Bills On 7/26/2012 3:24 PM, Fabio Estevam wrote: Bill, On Thu, Jul 26, 2012 at 3:28 PM, Billbsou...@techsi.com wrote: All, I am working on building the latest u-boot for the imx28evk board. I have done the following steps: 1. git clone git://git.denx.de/u-boot-imx.git 2. setup paths for finding my cross-compiler 1. make mx28evk_config 2. make u-boot.imx 'make u-boot.imx' is not correct for mx28. You should do: make u-boot.sb Please follow the instructions at doc/README.mx28_common for the correct process. Regards, Fabio Estevam -- William (Bill) L. Sousan, Ph.D. (w) 402.331.4977 ext. 4002 bsou...@techsi.com Technical Support Inc. 11253 John Galt Blvd Omaha, NE 68137 www.techsi.com 8(a) SDB Certified, ISO 9001:2008 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building u-boot for iMX28 and getting error in mkimage of missing command line parameter CONFIG_IMX_CONFIG
Bill, On Fri, Jul 27, 2012 at 10:07 AM, Bill bsou...@techsi.com wrote: Thanks. That did it! However, now my new U-boot built from the mainstream Uboot runs and also loads and unpacks the Linux kernel - but it dies after that. However, my original U-boot from tlib works fine. Are there some patches and/or settings I am missing? I suppose you are using the 2.6.35 kernel. In this FSL kernel the console is ttyAM0. In mainline kernel the console is ttyAMA0. This is probably the reason you don't see nothing in the console. I would suggest you to use the mainline kernel though. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] dfu: DFU backend implementation
Dear Wolfgang Denk,
Dear Lukasz Majewski,
In message 1341416922-13792-4-git-send-email-l.majew...@samsung.com
you wrote:
New, separate driver at ./drivers/dfu has been added. It allows
platform and storage independent operation of DFU.
Sorry for a probably stupid question, but I know basicly zero about
DFU. We are talking about storage independent here. Does this
also mean file system independent?
Some clarification is needed. I've divided DFU support (PATCH v2) to
three separate parts:
1. DFU transmission handling (via USB)
with ./drivers/usb/gadget/g_dnl.c|f_dfu.c
2. Generic DFU functions ./drivers/dfu/dfu.c - which try to abstract
DFU operation to be platform independent.
Generic dfu_{write|read} functions have been defined and are
accessible from USB code. On the other hand dfu_{write|read}
calls function pointers dfu-{read|write}_medium(), which points
to medium specific functions.
3. Code for MMC write/read - dfu_mmc.c.
It is possible to read/write raw data to MMC (with passing LBA address)
or to file systems (like FAT). For now MMC is only supported. It uses
(in my opinion) generic sprintf+run_command() calls, which can be
easily extended.
To support OneNAND one needs to define dfu_onenand.c file with OneNAND
specific functions.
Considering above, there are already defined generic access functions
- dfu_{write|read}.
+static char *dfu_get_dev_type(enum dfu_device_type t)
+{
+ static char *dev_t[] = {NULL, MMC, ONENAND, NAND };
+ return dev_t[t];
+}
So this currently supports MMC, OneNAND and NAND as storage devices?
It currently only supports MMC devices. Others (ONENAND/NAND) have been
added as place holders for future usage.
+static char *dfu_get_layout(enum dfu_device_type l)
+{
+ static char *dfu_layout[] = {NULL, RAW_ADDR, FAT,
EXT };
+ return dfu_layout[l];
+}
And FAT (or VFAT?) and EXT (as in EXT2? or EXT3? or ... ?) as file
systems?
+enum dfu_device_type {
+ MMC = 1,
+ ONENAND,
+ NAND
+};
+
+enum dfu_layout {
+ RAW_ADDR = 1,
+ FAT,
+ EXT,
+};
MMC, NAND, FAT and EXT are very generic names that heavily pollute on
the global name space. Please chose more specific names, probaly also
indicating the meaning (EXT could be some extension or external or
whatever - the name does not indicate that this is a file system type
here.
Ok, no problem with this.
Best regards,
Wolfgang Denk
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation
Dear Wolfgang Denk, Dear Marek Vasut, In message 201207271443.45189.ma...@denx.de you wrote: For this shim layer I would actually prefer the original approach (shown above) to use sprintf() to build commands based on the existing command interface We discussed it for a while ... figure out the missing typechecking and abuse of the command line interface is not a way to go. I agree that this is not the preferred way for a permanent solution, but for now I cxonsider it acceptable, as it allows to easily deal with the inconsistent API of the misc file system handlers. For example instead of sprintf(cmd_buf, fatread mmc %d:%d 0x%x %s %lx, ... we can even do something like sprintf(cmd_buf, %s %s %d:%d 0x%x %s %lx, command, device, ... and set command as needed to fatread or ext2load or whatever, and device can be set to mmc or usb or ... Given that they have slightly different syntax, this is crazy too. this is the minimal intrusive way to implement this for now. With this approach, no modifications to file system and/or device driver code are needed, and we still maintain full flexibility here in the DFU code. Yes, error checking may not be perfect, and we my not win a price for elegance of design either, but we should get mostly clean, working code quickly. But now that we started going in the typechecking way, I'd prefer to go all the way. And once DFU extends properly towards other supported filesystems/devices, the rest of the interface can get cleaned along the way. You can implement the type checking code when you hav ea stable, well define API for storage devices and file systems. For now we don't have that, and it makes ZERO sense to add special code just for that just to throw it away in a few weeks. Ad API -- adding Pavel to CC. Hope his GMail works better than mine (mine doesn't, crashed again, damned google stuff). Pavel, can you provide us with how the API will look maybe? Shim layer is cool -- abusing command line is not cool ;-) Whether this is abuse or clever use remains to be defined, and this is probably largely a matter of taste. In any case, this will be a small piece of code that is of clearly transient nature, to be replaced or removed as soon as we can do better. Best regards, Wolfgang Denk Well ... after this discussion, I feel like I'll just go dig me a grave again. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation
Dear Wolfgang Denk,
Dear Lukasz Majewski,
In message 1341416922-13792-5-git-send-email-l.majew...@samsung.com
you wrote:
Support for MMC storage devices to work with DFU framework.
Sorry for jumping in late.
+ switch (dfu-layout) {
+ case RAW_ADDR:
+ sprintf(cmd_buf, mmc write 0x%x %x %x, (unsigned
int) buf,
+ dfu-data.mmc.lba_start,
dfu-data.mmc.lba_size);
+ break;
+ case FAT:
+ sprintf(cmd_buf, fatwrite mmc %d:%d 0x%x %s %lx,
+ dfu-data.mmc.dev, dfu-data.mmc.part,
+ (unsigned int) buf, dfu-name, *len);
+ break;
+ default:
+ printf(%s: Wrong layout!\n, __func__);
+ }
In case of error, you should always print what the unexpected data
was. The end user who receives an Wrong layout! error is probably
pretty much surpised and doesn't know what he did wrong. If you
print instead: EXT2 layout not supported (yet) he would know exactly
what to change to make it work.
Ok, this can be easily corrected.
There has been some dicussion already if using this sprintf() /
run_command() approach is good or not, or how it should be fixed.
It appears, all this discussion forgot to take into account that
patch 3/7 dfu: DFU backend implementation promised to add platform
and storage independent operation of DFU. Here we are breaking this
promise.
And by adding special functions to the FAT file system code thing sget
just worse, as now not only the DFU code needs to be extended when we
want to use this with any other file system type, but suddenly this
also bleeds into all supported file system code.
I am aware that the current implementation suffers from the fact that
we don't have a unified access to file systems - each comes with it's
own set of commands and more or less (in)compatible command line and
function call interfaces. This will hopefully improve in the context
of the device model rework, but we don't want to block you until then.
But considering that this is going to change in a foreseeable future,
it also makes littel sense to invest big efforts into generic code
that covers all potential future uses.
Here is my poposal:
Let's introduce a thin shim layer to abstract the file system
interface from the accesses you need here. As far as I can see here,
you need exactly 4 functions:
- block_read()
- block_write()
- file_read()
- file_write()
These names could be function pointers to implement the device I/O in
a both device and file system agnostic way; you can implement
specific versions of the functions like mmc_block_read(),
usb_block_read(), ... etc. and use the settings of dfu_device_type
and dfu_layout to set the pointers to these functions.
For this shim layer I would actually prefer the original approach
(shown above) to use sprintf() to build commands based on the existing
command interface - this is the minimal intrusive way to implement
this for now. With this approach, no modifications to file system
and/or device driver code are needed, and we still maintain full
flexibility here in the DFU code. Yes, error checking may not be
perfect, and we my not win a price for elegance of design either, but
we should get mostly clean, working code quickly.
So I suppose, that you are proposing something like this (pseudo code):
int mmc_block_write() {
sprintf(cmd_buf, mmc write 0x%x %x %x)
run_command(cmd_buf, 0);
}
int mmc_file_write(enum fs_type) {
switch (fs_type)
case FAT:
sprintf(cmd_buf, fatwrite mmc %d:%d 0x%x %s %lx)
break;
case EXT4:
sprintf(cmd_buf, ext4write mmc %d:%d 0x%x %s %lx)
break;
run_command(cmd_buf);
}
int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len)
{
ALLOC_CACHE_ALIGN_BUFFER(char, cmd_buf, DFU_CMD_BUF_SIZE);
memset(cmd_buf, '\0', sizeof(cmd_buf));
switch (dfu-layout) {
case RAW_ADDR:
mmc_block_write()
break;
case FAT:
case EXT3:
case EXT4:
mmc_file_write(dfu-layout);
break;
default:
printf(%s: Wrong layout %s!\n, __func__,
layout_table[dfu-layout]); }
return 0;
}
The advantage I see for this code is that we have separated all
this device interface stuff from both the generic DFU code and from
the device and file system code as well. As soon as we have a better
implementation below, all we need to adjust (or potentially even
remove) is this shim layer.
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] dfu: DFU backend implementation
Dear Lukasz,
In message 20120727151523.41406989@amdc308.digital.local you wrote:
Some clarification is needed. I've divided DFU support (PATCH v2) to
three separate parts:
1. DFU transmission handling (via USB)
...
2. Generic DFU functions ./drivers/dfu/dfu.c - which try to abstract
DFU operation to be platform independent.
...
3. Code for MMC write/read - dfu_mmc.c.
OK, than my understanding was mostly correct.
It is possible to read/write raw data to MMC (with passing LBA address)
or to file systems (like FAT). For now MMC is only supported. It uses
(in my opinion) generic sprintf+run_command() calls, which can be
easily extended.
To support OneNAND one needs to define dfu_onenand.c file with OneNAND
specific functions.
Correct. And adaption for other devices (say, NAND or USB mass
storage) should be trivial as well.
Considering above, there are already defined generic access functions
- dfu_{write|read}.
OK - but the device specific stuff is only used in the sprintf()
command then. That's why I recommend to move just this very small
function into a separate file, which can be replaced or removed later.
So this currently supports MMC, OneNAND and NAND as storage devices?
It currently only supports MMC devices. Others (ONENAND/NAND) have been
added as place holders for future usage.
Yes, I understand. But then, adding such support looks pretty
straightforward, and even trivial to me. You provided a pretty clear
infrastructure for this, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I thought my people would grow tired of killing. But you were right,
they see it is easier than trading. And it has its pleasures. I feel
it myself. Like the hunt, but with richer rewards.
-- Apella, A Private Little War, stardate 4211.8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation
Dear Marek Vasut, In message 201207271515.36085.ma...@denx.de you wrote: sprintf(cmd_buf, %s %s %d:%d 0x%x %s %lx, command, device, ... and set command as needed to fatread or ext2load or whatever, and device can be set to mmc or usb or ... Given that they have slightly different syntax, this is crazy too. Draw the line between clever and crazy, genius and idiot :-) Well ... after this discussion, I feel like I'll just go dig me a grave again. Why? I think the discussion has been beneficial - we isolated a poor piece of code, discussed how it should be improved, and now ry to find an intermediate solution that adds not too much work for Lukasz while still keeing the existing code clean and allowing for easy adaption to the new DM interfaces - three worthwile goals at once. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Sorry, but my karma just ran over your dogma. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] dfu: DFU backend implementation
Dear Wolfgang Denk, Correct. And adaption for other devices (say, NAND or USB mass storage) should be trivial as well. USB Mass Storage is also under development. It is supposed to be a function (f_ums.c) for g_dnl.c composite gadget. I will postpone posting it to ML until we agree for the DFU shape (and thereof the g_dnl composite gadget driver). -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] dfu: MMC specific routines for DFU operation
Dear Lukasz,
In message 20120727153345.008fde41@amdc308.digital.local you wrote:
So I suppose, that you are proposing something like this (pseudo code):
Yes, very close.
int mmc_block_write() {
sprintf(cmd_buf, mmc write 0x%x %x %x)
run_command(cmd_buf, 0);
}
int mmc_file_write(enum fs_type) {
switch (fs_type)
case FAT:
sprintf(cmd_buf, fatwrite mmc %d:%d 0x%x %s %lx)
break;
case EXT4:
sprintf(cmd_buf, ext4write mmc %d:%d 0x%x %s %lx)
break;
run_command(cmd_buf);
}
int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len)
{
I suggest just use
int dfu_write_medium(struct dfu_entity *dfu, void *buf, long *len)
here; you can then so something like
switch (dfu-dev_type) {
case MMC: block_write = mmc_block_write;
file_write = mmc_file_write;
break;
#ifdef NAND_SUPPORT_AVAILABLE
case NAND: block_write = nand_block_write;
file_write = nand_block_write;
break;
#endif
...
and use block_write() resp. file_write() in the rest. So the code is
really trivial to extend for other storage devices and file systems.
I feel we are very close, thanks!
Let's see if Pavel adds some comments about the best API to chose to
be as compatible with possible with the upcoming block device layer,
and then we can go for it.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Houston, Tranquillity Base here. The Eagle has landed.
-- Neil Armstrong
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ehci-hcd: Boost transfer speed
Dear Marek Vasut,
On Fri, Jul 27, 2012 at 02:54:07 PM, Marek Vasut wrote:
This patch takes advantage of the hardware EHCI qTD queuing
mechanism to
avoid software overhead and to make transfers as fast as possible.
The only drawback is a call to memalign. However, this is fast
compared to
the transfer timings, and the heap size to allocate is small, e.g.
a
little bit more than 100 kB for a transfer length of 65535 packets
of 512
bytes.
Tested on i.MX25 and i.MX35. In my test conditions, the speedup was
about
15x using page-aligned buffers, which is really appreciable when
accessing
large files.
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Marek Vasut ma...@denx.de
Cc: Ilya Yanok ilya.ya...@cogentembedded.com
Cc: Stefan Herbrechtsmeier ste...@herbrechtsmeier.net
---
.../drivers/usb/host/ehci-hcd.c| 94
++-- 1 file changed, 65 insertions(+), 29
deletions(-)
diff --git u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c index
5b3b906..b5645fa
100644
--- u-boot-usb-1b4bd0e.orig/drivers/usb/host/ehci-hcd.c
+++ u-boot-usb-1b4bd0e/drivers/usb/host/ehci-hcd.c
@@ -208,7 +208,8 @@ ehci_submit_async(struct usb_device *dev,
unsigned long
pipe, void *buffer, int length, struct devrequest *req)
{
ALLOC_ALIGN_BUFFER(struct QH, qh, 1, USB_DMA_MINALIGN);
- ALLOC_ALIGN_BUFFER(struct qTD, qtd, 3, USB_DMA_MINALIGN);
+ struct qTD *qtd;
+ int qtd_count = 0;
int qtd_counter = 0;
volatile struct qTD *vtd;
@@ -229,8 +230,25 @@ ehci_submit_async(struct usb_device *dev,
unsigned
long pipe, void *buffer, le16_to_cpu(req-value),
le16_to_cpu(req-value),
le16_to_cpu(req-index));
+ if (req != NULL)/* SETUP + ACK */
+ qtd_count += 1 + 1;
+ if (length 0 || req == NULL) {/* buffer */
+ if ((uint32_t)buffer 4095)/* page-unaligned */
+ qtd_count += (((uint32_t)buffer 4095) + length +
+ (QT_BUFFER_CNT - 1) * 4096 - 1) /
+ ((QT_BUFFER_CNT - 1) * 4096);
Ok, maybe you can please elaborate on this crazy calculation in here?
Or somehow
clarify it? Also, won't the macros in include/common.h help in a way?
(like
ROUND() etc).
I have already posted a v2 for this specific patch (only 2/5) that does exactly
that. Please review only the latest versions of patches.
I don't really graps what you're trying to calculate here, so maybe
even a
comment would help.
I'll do that.
+ else/* page-aligned */
+ qtd_count += (length + QT_BUFFER_CNT * 4096 - 1) /
+ (QT_BUFFER_CNT * 4096);
Same here, also please avoid using those 4096 and such constants ...
maybe
#define them in ehci.h ?
Yes. It was already everywhere, so I went on the same way. Do you think using
PAGE_SIZE from linux/compat.h would be fine since these 4096 are nothing more
than page sizes?
+ }
+ qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
So your code can alloc more than 5 qTDs ? How does it chain them
then? Into more
QHs ?
It's done in exactly the same way as for the original 3 qTDs, only with more
qTDs, but still with 5 qt_buffers per qTD.
+ if (qtd == NULL) {
+ printf(unable to allocate TDs\n);
+ return -1;
+ }
+
memset(qh, 0, sizeof(struct QH));
- memset(qtd, 0, 3 * sizeof(*qtd));
+ memset(qtd, 0, qtd_count * sizeof(*qtd));
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe),
usb_pipeout(pipe));
@@ -291,31 +309,46 @@ ehci_submit_async(struct usb_device *dev,
unsigned
long pipe, void *buffer, }
if (length 0 || req == NULL) {
- /*
-* Setup request qTD (3.5 in ehci-r10.pdf)
-*
-* qt_next 03-00 H
-* qt_altnext . 07-04 H
-* qt_token ... 0B-08 H
-*
-* [ buffer, buffer_hi ] loaded with buffer.
-*/
- qtd[qtd_counter].qt_next = cpu_to_hc32(QT_NEXT_TERMINATE);
- qtd[qtd_counter].qt_altnext = cpu_to_hc32(QT_NEXT_TERMINATE);
- token = (toggle 31) |
- (length 16) |
- ((req == NULL ? 1 : 0) 15) |
- (0 12) |
- (3 10) |
- ((usb_pipein(pipe) ? 1 : 0) 8) | (0x80 0);
- qtd[qtd_counter].qt_token = cpu_to_hc32(token);
- if (ehci_td_buffer(qtd[qtd_counter], buffer, length) != 0) {
- printf(unable construct DATA td\n);
- goto fail;
- }
- /* Update previous qTD! */
- *tdp =
Re: [U-Boot] ETH RBPTR incorrect mapping for rtx volatile structure
Pins and clocks was misconfigured. It works well now. Bye. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] usb_storage: Restore non-EHCI support
Dear Marek, On Fri, Jul 27, 2012 at 02:55:38 PM, Marek Vasut wrote: The commit 5dd95cf made the MSC driver EHCI-specific. This patch restores a basic support of non-EHCI HCDs, like before that commit. The fallback transfer size is certainly not optimal, but at least it should work like before. [...] Please merge this with 3/5 or swap them, so this doesn't break bisect please. OK, I'll swap them then. Regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] usb_storage: Adjust time-outs
Dear Marek, On Fri, Jul 27, 2012 at 02:56:50 PM, Marek Vasut wrote: Adjust time-out value for the new EHCI mechanism. [...] Ok, I really like this set. Nice to read. I believe it's only one or two reposts away from upstream and I'd love to have it in next release (not this one, as we can't test it in 3 days). I admit I'm not the easiest and fastest custodian, so pardon me at that. I pardon you. Regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ehci-hcd: Boost transfer speed
Dear Benoît Thébaudeau, [...] Ok, maybe you can please elaborate on this crazy calculation in here? Or somehow clarify it? Also, won't the macros in include/common.h help in a way? (like ROUND() etc). I have already posted a v2 for this specific patch (only 2/5) that does exactly that. Please review only the latest versions of patches. I don't really graps what you're trying to calculate here, so maybe even a comment would help. I'll do that. + else/* page-aligned */ + qtd_count += (length + QT_BUFFER_CNT * 4096 - 1) / + (QT_BUFFER_CNT * 4096); Same here, also please avoid using those 4096 and such constants ... maybe #define them in ehci.h ? Yes. It was already everywhere, so I went on the same way. I'm not exactly proud of the state of the usb stack, you know :( Do you think using PAGE_SIZE from linux/compat.h would be fine since these 4096 are nothing more than page sizes? Isn't that intel-specific? + } + qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD)); So your code can alloc more than 5 qTDs ? How does it chain them then? Into more QHs ? It's done in exactly the same way as for the original 3 qTDs, only with more qTDs, but still with 5 qt_buffers per qTD. I'm starting to see what you're trying to do. That's really cool :) [...] + token = (toggle 31) | + (xfr_bytes 16) | + ((req == NULL ? 1 : 0) 15) | + (0 12) | + (3 10) | + ((usb_pipein(pipe) ? 1 : 0) 8) | (0x80 0); If you could fix all this magic afterwards (not in these patches), that'd be great. Do you only mean #defining all those values? Yes, but let's do this in a subsequent patch. It can wait for later. [...] Best regards, Benoît Thébaudeau ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
Dear Marek,
On Fri, Jul 27, 2012 at 02:59:29 PM, Marek Vasut wrote:
Hi Jim,
On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs
every
10K of
data for fatload usb or 500ms of delay per 1MB of image size.
This
adds up
to quite a bit of delay if you're loading a large ramdisk.
Does anyone know what the reason for the 5ms delay really is?
I'm
assuming
that this delay is to debounce the 5V/100ma USB power up. I made
some
modification, where the delay is skipped if the device has
already
been
queried as ready. This has save me 500ms/M on fatload times (eg,
140M=70seconds). Is there anything wrong with this tweak?
Here's a diff of what I've done to get the performance I need:
--- usb_storage.c.orig 2012-07-26 16:06:40.775251000 -0400
+++ usb_storage.c 2012-07-26 13:49:36.0 -0400
@@ -132,6 +132,7 @@ static block_dev_desc_t usb_dev_desc[USB
struct us_data;
typedef int (*trans_cmnd)(ccb *cb, struct us_data *data);
typedef int (*trans_reset)(struct us_data *data);
+typedef enum us_status { USB_NOT_READY, USB_READY} us_status;
struct us_data {
struct usb_device *pusb_dev; /* this usb_device */
@@ -154,6 +155,7 @@ struct us_data {
ccb *srb; /* current srb */
trans_reset transport_reset;/* reset routine
*/
trans_cmnd transport; /* transport
routine
*/
+ us_status status;
};
static struct us_data usb_stor[USB_MAX_STOR_DEV];
@@ -691,7 +693,10 @@ int usb_stor_BBB_transport(ccb *srb, str
usb_stor_BBB_reset(us);
return USB_STOR_TRANSPORT_FAILED;
}
- wait_ms(5);
+ if(us-status != USB_READY)
+ {
+ wait_ms(5);
+ }
pipein = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
pipeout = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
/* DATA phase + error handling */
@@ -957,7 +962,10 @@ static int usb_test_unit_ready(ccb *srb,
srb-datalen = 0;
srb-cmdlen = 12;
if (ss-transport(srb, ss) ==
USB_STOR_TRANSPORT_GOOD)
+ {
+ ss-status = USB_READY;
return 0;
+ }
usb_request_sense(srb, ss);
wait_ms(100);
} while (retries--);
@@ -965,6 +973,11 @@ static int usb_test_unit_ready(ccb *srb,
return -1;
}
+static void usb_set_unit_not_ready(struct us_data *ss)
+{
+ ss-status = USB_NOT_READY;
+}
+
static int usb_read_capacity(ccb *srb, struct us_data *ss)
{
int retry;
@@ -1108,6 +1121,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(usb_read: end startblk %lx, blccnt %x
buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1188,6 +1202,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(usb_write: end startblk %lx, blccnt %x
buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1398,6 +1413,7 @@ int usb_stor_get_info(struct usb_device
cap[0] = 2880;
cap[1] = 0x200;
}
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
USB_STOR_PRINTF(Read Capacity returns: 0x%lx, 0x%lx\n,
cap[0],
cap[1]);
#if 0
I'd appreciate any feedback.
Regards
I have not looked into this delay issue, but I had similar
performance
issues that I fixed with the following series:
http://patchwork.ozlabs.org/patch/172052/
http://patchwork.ozlabs.org/patch/172204/
http://patchwork.ozlabs.org/patch/172054/
http://patchwork.ozlabs.org/patch/172055/
http://patchwork.ozlabs.org/patch/172056/
Your suggestion is interesting and might be a complement to my
series. I
don't have time to check its correctness right now, but I'll try
soon.
Will you two have time to work these into V2 of your series somehow
please?
Are you asking me to integrate Jim's patch in my series with his SoB once
reviewed?
Since I have already issued a v2 for 2/5, do you want a v3
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Dear Benoît Thébaudeau,
[...]
@@ -229,8 +230,23 @@ ehci_submit_async(struct usb_device *dev, unsigned
long pipe, void *buffer, le16_to_cpu(req-value), le16_to_cpu(req-value),
le16_to_cpu(req-index));
+ if (req != NULL)/* SETUP + ACK */
+ qtd_count += 1 + 1;
+ if (length 0 || req == NULL) {/* buffer */
+ if ((uint32_t)buffer 4095)/* page-unaligned */
+ qtd_count += DIV_ROUND_UP(((uint32_t)buffer 4095) +
+ length, (QT_BUFFER_CNT - 1) * 4096);
+ else/* page-aligned */
+ qtd_count += DIV_ROUND_UP(length, QT_BUFFER_CNT * 4096);
+ }
Ok, now I almost see it.
+ qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
+ if (qtd == NULL) {
+ printf(unable to allocate TDs\n);
+ return -1;
+ }
+
memset(qh, 0, sizeof(struct QH));
- memset(qtd, 0, 3 * sizeof(*qtd));
+ memset(qtd, 0, qtd_count * sizeof(*qtd));
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe), usb_pipeout(pipe));
[...]
I'm cool with the rest, I'll think about the calculation a bit though, since
I'm
not certain about it right away and let you know. Will you be submitting the
series again or shall I just merge 3/5 and 4/5, apply this one and be done with
it?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ehci-hcd: Boost transfer speed
Dear Marek, On Fri, Jul 27, 2012 at 04:01:11 PM, Marek Vasut wrote: Do you think using PAGE_SIZE from linux/compat.h would be fine since these 4096 are nothing more than page sizes? Isn't that intel-specific? I don't know. The code does not say so. What is sure is that page sizes should be arch-specific, even with several possible page sizes per arch. But this #define seems to fit our needs, so why not use it? The only thing that would make me reluctant to using it is that this code might change without further notice. + } + qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD)); So your code can alloc more than 5 qTDs ? How does it chain them then? Into more QHs ? It's done in exactly the same way as for the original 3 qTDs, only with more qTDs, but still with 5 qt_buffers per qTD. I'm starting to see what you're trying to do. That's really cool :) OK. [...] + token = (toggle 31) | + (xfr_bytes 16) | + ((req == NULL ? 1 : 0) 15) | + (0 12) | + (3 10) | + ((usb_pipein(pipe) ? 1 : 0) 8) | (0x80 0); If you could fix all this magic afterwards (not in these patches), that'd be great. Do you only mean #defining all those values? Yes, but let's do this in a subsequent patch. It can wait for later. OK. Regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
Dear Benoמt Thיbaudeau, [...] Your suggestion is interesting and might be a complement to my series. I don't have time to check its correctness right now, but I'll try soon. Will you two have time to work these into V2 of your series somehow please? Are you asking me to integrate Jim's patch in my series with his SoB once reviewed? If you can negotiate ... Since I have already issued a v2 for 2/5, do you want a v3 of the whole series to be more clear? Otherwise I'm fine with picking up your series and applying Jims patch afterwards ... though I'm not quite sure if it'll apply then. So guys, what do you think? Regards, Benoמt Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Dear Marek,
On Fri, Jul 27, 2012 at 04:07:01 PM, Marek Vasut wrote:
+ qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
+ if (qtd == NULL) {
+ printf(unable to allocate TDs\n);
+ return -1;
+ }
+
memset(qh, 0, sizeof(struct QH));
- memset(qtd, 0, 3 * sizeof(*qtd));
+ memset(qtd, 0, qtd_count * sizeof(*qtd));
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe),
usb_pipeout(pipe));
[...]
I'm cool with the rest, I'll think about the calculation a bit
though, since I'm
not certain about it right away and let you know. Will you be
submitting the
series again or shall I just merge 3/5 and 4/5, apply this one and be
done with
it?
I'll resubmit the whole series. I'll first answer Stefan in this thread when
possible.
Regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cfi: Problem with Intel Strata 28F320 flash
Hi all, On 03/09/2011 02:21 PM, Detlev Zundel wrote: Hi Heiko, Maybe a way to go ... more comments? Below a patch, which introduces a function, which checks for protection bugfixes, and if no bugfix is found the old code is executed. Just a fast RFC patch. bye, Heiko [...] Can't we introduce a field chip_quirk in flash_info_t, and upon flash enumeration check for the specific chip version and for example put a CFI_QUIRK_PROTECT in it for this chip. The core code can then check for this flag and call functions appropriately. In other words, why not introduce a generic infrastructure for handling chip quirks that may need different handling for other functions also. Cheers Detlev Have there been (since the original posting) other instances of flash parts requiring quirks (like the original one introduced by Philippe De Muyter for the Numonyx chip)? Is there any ongoing activity on this or any other reason to suggest it might be necessary to introduce such generic infrastructure (like the one in linux mtd, the way I understand it)? If that's not the case, wouldn't Heicho's original patch in this thread (http://patchwork.ozlabs.org/patch/86063/) just be good enough for the purpose? Thanks, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
Dear Marek, On Fri, Jul 27, 2012 at 04:09:42 PM, Marek Vasut wrote: [...] Your suggestion is interesting and might be a complement to my series. I don't have time to check its correctness right now, but I'll try soon. Will you two have time to work these into V2 of your series somehow please? Are you asking me to integrate Jim's patch in my series with his SoB once reviewed? If you can negotiate ... Since I have already issued a v2 for 2/5, do you want a v3 of the whole series to be more clear? Otherwise I'm fine with picking up your series and applying Jims patch afterwards ... though I'm not quite sure if it'll apply then. So guys, what do you think? I'm fine with merging Jim's patch once reviewed if he agrees. Regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] FAT: cosmetic: Remove extra spaces
Dear Mike, On Sat, Jul 21, 2012 at 07:23:57 PM, Mike Frysinger wrote: Acked-by: Mike Frysinger vap...@gentoo.org If it's ack'ed, why does nobody apply it? What is the normal life cycle of patches like these that don't have a custodian? Regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Dear Tom Rini, On Mon, Jul 23, 2012 at 08:16:12AM +0200, Wolfgang Denk wrote: [snip] Running a full MAKEALL for all architectures and boards, for all ( 40) repositories, every 24 hours, requires more CPU and I/O cycles that we can currently afford. MAKEALL is indeed consuming. But I wanted to follow up here on something I've talked a little about on IRC now. On my local box I've cut the time it takes for MAKEALL -a powerpc down from 60min to 33min by using BUILD_NBUILDS=6 BUILD_NCPUS=1 (on a 6 processor (grep -c processor /proc/cpuinfo)) box. I've seen similar reductions on my just TI parts builds. Not that this solves all of our problems, but it should help. So, we discussed with WD on jabber (yay, so many communication protocols involved ;-) ) and we figured out that some boards will simply get broken by the DM. So we'll be able to carve those out and trim down the build times. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] i.MX28: bug fixes in PMU configuration code
Dear Stathis Voukelatos, Fixed some typos in the i.MX28 PMU code that sets up the VDDD and VDDIO power rails. In addition the VDDD and VDDIO brownout offset values should be divided by a step size before being programmed to the corresponding registers. Signed-off-by: Stathis Voukelatos stathis.voukela...@linn.co.uk Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut marek.va...@gmail.com [...] Acked-by: Marek Vasut ma...@denx.de Stefano, can you please apply? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] FAT: cosmetic: Remove extra spaces
Dear =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=, In message 845266616.705298.1343398892482.javamail.r...@advansee.com you wrote: On Sat, Jul 21, 2012 at 07:23:57 PM, Mike Frysinger wrote: Acked-by: Mike Frysinger vap...@gentoo.org If it's ack'ed, why does nobody apply it? What is the normal life cycle of patches like these that don't have a custodian? They end on my table, and probably get merged when the next merge window opens. See http://www.denx.de/wiki/U-Boot/ReleaseCycle Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What is wanted is not the will to believe, but the will to find out, which is the exact opposite. -- Bertrand Russell, Skeptical Essays, 1928 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] List of offending drivers
Dear Igor Grinberg, Hi Marek, On 07/27/12 11:43, Marek Vasut wrote: Dear Lukasz Majewski, Dear Marek Vasut, board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are. That's fairy possible, I did only quick inspection and I'll be taking further look this weekend. May be you should do a further look before sending a heads up about everything you see... Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed
Dear Benoît Thébaudeau,
Dear Marek,
On Fri, Jul 27, 2012 at 04:07:01 PM, Marek Vasut wrote:
+ qtd = memalign(USB_DMA_MINALIGN, qtd_count * sizeof(struct qTD));
+ if (qtd == NULL) {
+ printf(unable to allocate TDs\n);
+ return -1;
+ }
+
memset(qh, 0, sizeof(struct QH));
- memset(qtd, 0, 3 * sizeof(*qtd));
+ memset(qtd, 0, qtd_count * sizeof(*qtd));
toggle = usb_gettoggle(dev, usb_pipeendpoint(pipe),
usb_pipeout(pipe));
[...]
I'm cool with the rest, I'll think about the calculation a bit
though, since I'm
not certain about it right away and let you know. Will you be
submitting the
series again or shall I just merge 3/5 and 4/5, apply this one and be
done with
it?
I'll resubmit the whole series. I'll first answer Stefan in this thread
when possible.
Please do, and see how Jim is with the timeout patch please.
Regards,
Benoît
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ehci-hcd: Boost transfer speed
Dear Benoît Thébaudeau, Dear Marek, On Fri, Jul 27, 2012 at 04:01:11 PM, Marek Vasut wrote: Do you think using PAGE_SIZE from linux/compat.h would be fine since these 4096 are nothing more than page sizes? Isn't that intel-specific? I don't know. The code does not say so. What is sure is that page sizes should be arch-specific, even with several possible page sizes per arch. But this #define seems to fit our needs, so why not use it? The only thing that would make me reluctant to using it is that this code might change without further notice. That's exactly my point. And it'll break anything with pages smaller than 4k. Please define it in ehci.h [..] Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot on the POGO-E02
On 07/27/2012 12:18:48 AM, Prafulla Wadaskar wrote: The appended patch is to the latest U-Boot release, 2012-04. I'll see about sending a patch with git as described in the FAQ if I get something working. This patch is not to apply, but I'm having a problem because the patch wraps. boards.cfg contains long lines, and some of the original source has long lines as well. What to do? You may send this patch as RFC for review. Is there anything special, besides using git, that I need to do to send a patch as RFC for review? And I think I should wait to see if it works on the device, right? Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] List of offending drivers
On 07/27/12 17:30, Marek Vasut wrote: Dear Igor Grinberg, Hi Marek, On 07/27/12 11:43, Marek Vasut wrote: Dear Lukasz Majewski, Dear Marek Vasut, board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are. That's fairy possible, I did only quick inspection and I'll be taking further look this weekend. May be you should do a further look before sending a heads up about everything you see... Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits Probably, if you send the heads up email after taking a further look, the list would be shorter and hit the right people? Don't you think? Because, if you are going to look into this deeper, then what the point in sending the quick look list? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] List of offending drivers
Dear Igor Grinberg, On 07/27/12 17:30, Marek Vasut wrote: Dear Igor Grinberg, Hi Marek, On 07/27/12 11:43, Marek Vasut wrote: Dear Lukasz Majewski, Dear Marek Vasut, board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are. That's fairy possible, I did only quick inspection and I'll be taking further look this weekend. May be you should do a further look before sending a heads up about everything you see... Where are you aiming with this exactly? I clearly stated I didn't do deep inspection of these and that there might be mishits Probably, if you send the heads up email after taking a further look, the list would be shorter and hit the right people? Don't you think? Because, if you are going to look into this deeper, then what the point in sending the quick look list? http://en.wikipedia.org/wiki/Release_early,_release_often ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cosmetic doc typo fixes to the kwbimage feature docs
On 07/26/2012 11:15:32 PM, Karl O. Pinc wrote: Hi, I'm looking into the kirkwood docs and found some typos. I'm not proficent in git. If there's a problem with my git-age, or anything else, please let me know. I used git send-mail to send the above and it sent 2 emails (?), of which this was the first. The actual patch was the second email and it did not show up on this list, perhaps because this was my first post and needed moderation. Should I send the patch again? (Trivial stuff, but I've another doc fix waiting and wanted to get this right first.) Thanks. Karl k...@meme.com Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] km/common: remove printfs for i2c deblocking code
From: Holger Brunck holger.bru...@keymile.com
This code will also be used before reallocation and during this time we
are not allowed to do these printings.
Signed-off-by: Holger Brunck holger.bru...@keymile.com
---
board/keymile/common/common.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c
index 1013f42..a90f112 100644
--- a/board/keymile/common/common.c
+++ b/board/keymile/common/common.c
@@ -151,7 +151,6 @@ int i2c_make_abort(void)
sda_state = get_sda();
if (scl_state sda_state) {
ret = 0;
- printf([INFO] i2c abort after %d clocks\n, i);
break;
}
}
@@ -159,8 +158,6 @@ int i2c_make_abort(void)
if (ret == 0)
for (i = 0; i 5; i++)
i2c_write_start_seq();
- else
- printf([ERROR] i2c abort failed\n);
/* respect stop setup time */
udelay(DELAY_ABORT_SEQ);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] List of offending drivers
Hi Marek, On 07/27/12 11:43, Marek Vasut wrote: Dear Lukasz Majewski, Dear Marek Vasut, board/samsung/goni/onenand.c board/samsung/smdkc100/onenand.c board/samsung/universal_c210/onenand.c Those files aren't drivers. Those are board specific init functions and in my opinion shall stay where they are. That's fairy possible, I did only quick inspection and I'll be taking further look this weekend. May be you should do a further look before sending a heads up about everything you see... -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
Dear Benoît Thébaudeau,
Hi Jim,
On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs every
10K of
data for fatload usb or 500ms of delay per 1MB of image size. This
adds up
to quite a bit of delay if you're loading a large ramdisk.
Does anyone know what the reason for the 5ms delay really is? I'm
assuming
that this delay is to debounce the 5V/100ma USB power up. I made
some
modification, where the delay is skipped if the device has already
been
queried as ready. This has save me 500ms/M on fatload times (eg,
140M=70seconds). Is there anything wrong with this tweak?
Here's a diff of what I've done to get the performance I need:
--- usb_storage.c.orig 2012-07-26 16:06:40.775251000 -0400
+++ usb_storage.c 2012-07-26 13:49:36.0 -0400
@@ -132,6 +132,7 @@ static block_dev_desc_t usb_dev_desc[USB
struct us_data;
typedef int (*trans_cmnd)(ccb *cb, struct us_data *data);
typedef int (*trans_reset)(struct us_data *data);
+typedef enum us_status { USB_NOT_READY, USB_READY} us_status;
Can we possibly avoid the typedef?
struct us_data {
struct usb_device *pusb_dev; /* this usb_device */
@@ -154,6 +155,7 @@ struct us_data {
ccb *srb; /* current srb */
trans_reset transport_reset;/* reset routine */
trans_cmnd transport; /* transport routine
*/
+ us_status status;
Don't we have some flags for it already?
};
static struct us_data usb_stor[USB_MAX_STOR_DEV];
@@ -691,7 +693,10 @@ int usb_stor_BBB_transport(ccb *srb, str
usb_stor_BBB_reset(us);
return USB_STOR_TRANSPORT_FAILED;
}
- wait_ms(5);
+ if(us-status != USB_READY)
+ {
+ wait_ms(5);
+ }
pipein = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
pipeout = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
/* DATA phase + error handling */
@@ -957,7 +962,10 @@ static int usb_test_unit_ready(ccb *srb,
srb-datalen = 0;
srb-cmdlen = 12;
if (ss-transport(srb, ss) ==
USB_STOR_TRANSPORT_GOOD)
+ {
+ ss-status = USB_READY;
return 0;
+ }
usb_request_sense(srb, ss);
wait_ms(100);
} while (retries--);
@@ -965,6 +973,11 @@ static int usb_test_unit_ready(ccb *srb,
return -1;
}
+static void usb_set_unit_not_ready(struct us_data *ss)
+{
+ ss-status = USB_NOT_READY;
+}
+
We don't need a setter function really.
static int usb_read_capacity(ccb *srb, struct us_data *ss)
{
int retry;
@@ -1108,6 +1121,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
I think we should be much more careful about these typecasts.
USB_STOR_PRINTF(usb_read: end startblk %lx, blccnt %x buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1188,6 +1202,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
Same here.
USB_STOR_PRINTF(usb_write: end startblk %lx, blccnt %x
buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1398,6 +1413,7 @@ int usb_stor_get_info(struct usb_device
cap[0] = 2880;
cap[1] = 0x200;
}
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
The rest is cool.
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] powerpc/82xx: remove unused define for mgcoge3ne
From: Holger Brunck holger.bru...@keymile.com Signed-off-by: Holger Brunck holger.bru...@keymile.com --- include/configs/mgcoge3ne.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/include/configs/mgcoge3ne.h b/include/configs/mgcoge3ne.h index 6fa1584..43d14ba 100644 --- a/include/configs/mgcoge3ne.h +++ b/include/configs/mgcoge3ne.h @@ -90,7 +90,4 @@ /* include further common stuff for all keymile 82xx boards */ #include km/km82xx-common.h -/* bfticu address */ -#define CONFIG_SYS_BFTICU_BASE 0x4000 - #endif /* __MGCOGE3NE */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] km82xx and mgcogeXxx reworking
Hello, this patch series does a bit of housekeeping on our mgcogeXxx boards. First we do some due code cleanups which just move code around, then we introduce dynamic SDRAM detection so the same u-boot binary can be used on different boards. Gerlando Falauto (6): powerpc/82xx: move mgcoge, mgcoge3ne defines to ease subsequent merge powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h powerpc/82xx: move km/km82xx-common.h within km82xx.h powerpc/82xx: add SDRAM detection for km82xx powerpc/82xx: use SDRAM detection for mgcoge2ne powerpc/82xx: adapt SDRAM settings for mgcoge3ne Holger Brunck (1): powerpc/82xx: remove unused define for mgcoge3ne board/keymile/km82xx/km82xx.c | 51 - boards.cfg |4 +- include/configs/km/km82xx-common.h | 317 - include/configs/km82xx.h | 448 include/configs/mgcoge.h | 93 include/configs/mgcoge3ne.h| 96 6 files changed, 499 insertions(+), 510 deletions(-) delete mode 100644 include/configs/km/km82xx-common.h create mode 100644 include/configs/km82xx.h delete mode 100644 include/configs/mgcoge.h delete mode 100644 include/configs/mgcoge3ne.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] powerpc/82xx: move mgcoge, mgcoge3ne defines to ease subsequent merge
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- include/configs/mgcoge.h| 34 +- include/configs/mgcoge3ne.h | 34 +- 2 files changed, 34 insertions(+), 34 deletions(-) diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h index b736c56..ad3b58e 100644 --- a/include/configs/mgcoge.h +++ b/include/configs/mgcoge.h @@ -33,6 +33,7 @@ #define CONFIG_MGCOGE #define CONFIG_HOSTNAMEmgcoge #define CONFIG_KM_82XX +#define CONFIG_KM_BOARD_EXTRA_ENV #defineCONFIG_SYS_TEXT_BASE0xFE00 @@ -68,25 +69,24 @@ /* SDRAM initialization values */ -#define CONFIG_SYS_OR1((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \ -ORxS_SDAM_MSK) |\ -ORxS_BPD_8 |\ -ORxS_ROWST_PBI0_A7 |\ -ORxS_NUMR_13) - -#define CONFIG_SYS_PSDMR (PSDMR_SDAM_A14_IS_A5 |\ -PSDMR_BSMA_A14_A16 |\ -PSDMR_SDA10_PBI0_A9|\ -PSDMR_RFRC_5_CLK |\ -PSDMR_PRETOACT_2W |\ -PSDMR_ACTTORW_2W |\ -PSDMR_LDOTOPRE_1C |\ -PSDMR_WRC_1C |\ -PSDMR_CL_2) +#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \ + ORxS_SDAM_MSK) |\ + ORxS_BPD_8 |\ + ORxS_ROWST_PBI0_A7 |\ + ORxS_NUMR_13) + +#define CONFIG_SYS_PSDMR ( \ + PSDMR_SDAM_A14_IS_A5 |\ + PSDMR_BSMA_A14_A16 |\ + PSDMR_SDA10_PBI0_A9 |\ + PSDMR_RFRC_5_CLK|\ + PSDMR_PRETOACT_2W |\ + PSDMR_ACTTORW_2W|\ + PSDMR_LDOTOPRE_1C |\ + PSDMR_WRC_1C|\ + PSDMR_CL_2) -#define CONFIG_KM_BOARD_EXTRA_ENV - /* include further common stuff for all keymile 82xx boards */ #include km/km82xx-common.h diff --git a/include/configs/mgcoge3ne.h b/include/configs/mgcoge3ne.h index 43d14ba..7ab03a0 100644 --- a/include/configs/mgcoge3ne.h +++ b/include/configs/mgcoge3ne.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2011 + * (C) Copyright 2007-2011 * Heiko Schocher, DENX Software Engineering, h...@denx.de. * * See file CREDITS for list of people who contributed to this @@ -21,8 +21,8 @@ * MA 02111-1307 USA */ -#ifndef __MGCOGE3NE -#define __MGCOGE3NE +#ifndef __CONFIG_H +#define __CONFIG_H /* * High Level Configuration Options @@ -33,6 +33,7 @@ #define CONFIG_MGCOGE3NE #define CONFIG_HOSTNAMEmgcoge3ne #define CONFIG_KM_82XX +#define CONFIG_KM_BOARD_EXTRA_ENV bobcatreset=true\0 #defineCONFIG_SYS_TEXT_BASE0xFE00 @@ -68,26 +69,25 @@ #define SDRAM_MAX_SIZE 0x1000 /* max. 256 MB */ #define CONFIG_SYS_GLOBAL_SDRAM_LIMIT (512 20) /* less than 512 MB */ -#define CONFIG_SYS_OR1((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \ - ORxS_SDAM_MSK) |\ +#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \ + ORxS_SDAM_MSK) |\ ORxS_BPD_4 |\ ORxS_ROWST_PBI1_A4 |\ ORxS_NUMR_13) -#define CONFIG_SYS_PSDMR (PSDMR_PBI |\ - PSDMR_SDAM_A17_IS_A5|\ - PSDMR_BSMA_A13_A15 |\ - PSDMR_SDA10_PBI1_A6 |\ - PSDMR_RFRC_5_CLK|\ - PSDMR_PRETOACT_2W |\ - PSDMR_ACTTORW_2W|\ - PSDMR_LDOTOPRE_1C |\ - PSDMR_WRC_2C|\ +#define CONFIG_SYS_PSDMR ( \ + PSDMR_PBI |\ + PSDMR_SDAM_A17_IS_A5|\ + PSDMR_BSMA_A13_A15 |\ + PSDMR_SDA10_PBI1_A6 |\ + PSDMR_RFRC_5_CLK|\ + PSDMR_PRETOACT_2W |\ + PSDMR_ACTTORW_2W|\ + PSDMR_LDOTOPRE_1C |\ + PSDMR_WRC_2C|\ PSDMR_CL_2)
[U-Boot] [PATCH 4/7] powerpc/82xx: move km/km82xx-common.h within km82xx.h
The only file including km82xx-common.h is km82xx.h. So there is no need to have it as a separate file. Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- include/configs/km/km82xx-common.h | 317 include/configs/km82xx.h | 290 - 2 files changed, 289 insertions(+), 318 deletions(-) delete mode 100644 include/configs/km/km82xx-common.h diff --git a/include/configs/km/km82xx-common.h b/include/configs/km/km82xx-common.h deleted file mode 100644 index 2c763bb..000 --- a/include/configs/km/km82xx-common.h +++ /dev/null @@ -1,317 +0,0 @@ -/* - * (C) Copyright 2007-2010 - * Heiko Schocher, DENX Software Engineering, h...@denx.de. - * - * See file CREDITS for list of people who contributed to this - * project. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA - */ - -#ifndef __KM82XX_COMMON -#define __KM82XX_COMMON - -/* - * Select serial console configuration - * - * If either CONFIG_CONS_ON_SMC or CONFIG_CONS_ON_SCC is selected, then - * CONFIG_CONS_INDEX must be set to the channel number (1-2 for SMC, 1-4 - * for SCC). - */ -#defineCONFIG_CONS_ON_SMC /* Console is on SMC */ -#undef CONFIG_CONS_ON_SCC /* It's not on SCC */ -#undef CONFIG_CONS_NONE/* It's not on external UART */ -#define CONFIG_CONS_INDEX 2 /* SMC2 is used for console */ -#define CONFIG_SYS_SMC_RXBUFLEN128 -#define CONFIG_SYS_MAXIDLE 10 - -/* - * Select ethernet configuration - * - * If either CONFIG_ETHER_ON_SCC or CONFIG_ETHER_ON_FCC is selected, - * then CONFIG_ETHER_INDEX must be set to the channel number (1-4 for - * SCC, 1-3 for FCC) - * - * If CONFIG_ETHER_NONE is defined, then either the ethernet routines - * must be defined elsewhere (as for the console), or CONFIG_CMD_NET - * must be unset. - */ -#defineCONFIG_ETHER_ON_SCC /* Ethernet is on SCC */ -#undef CONFIG_ETHER_ON_FCC /* Ethernet is not on FCC */ -#undef CONFIG_ETHER_NONE /* No external Ethernet */ - -#define CONFIG_ETHER_INDEX 4 -#define CONFIG_HAS_ETH0 -#define CONFIG_SYS_SCC_TOUT_LOOP 1000 - -#define CONFIG_SYS_CMXSCR_VALUE(CMXSCR_RS4CS_CLK7 | CMXSCR_TS4CS_CLK8) - -#ifndef CONFIG_8260_CLKIN -#define CONFIG_8260_CLKIN 6600/* in Hz */ -#endif - -#define BOOTFLASH_START0xFE00 - -#define CONFIG_KM_CONSOLE_TTY ttyCPM0 - -#define MTDPARTS_DEFAULT mtdparts= \ - app: \ - 768k(u-boot), \ - 128k(env),\ - 128k(envred), \ - 3072k(free), \ - -( CONFIG_KM_UBI_PARTITION_NAME_BOOT ) - -/* - * Default environment settings - */ -#defineCONFIG_EXTRA_ENV_SETTINGS \ - CONFIG_KM_BOARD_EXTRA_ENV \ - CONFIG_KM_DEF_ENV \ - EEprom_ivm=pca9544a:70:4 \0 \ - unlock=yes\0 \ - newenv= \ - prot off 0xFE0C +0x4\ - era 0xFE0C +0x4\0 \ - arch=ppc_82xx\0 \ - - -#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE -#if (CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE) -#define CONFIG_SYS_RAMBOOT -#endif - -#define CONFIG_SYS_MONITOR_LEN (768 10) - -#define CONFIG_ENV_IS_IN_FLASH - -#ifdef CONFIG_ENV_IS_IN_FLASH -#define CONFIG_ENV_SECT_SIZE 0x2 -#define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE + \ - CONFIG_SYS_MONITOR_LEN) -#define CONFIG_ENV_OFFSET CONFIG_SYS_MONITOR_LEN - -/* Address and size of Redundant Environment Sector*/ -#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + \
[U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need
to keep them as separate .h config files.
Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h
file.
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
boards.cfg |4 +-
include/configs/km82xx.h| 149 +++
include/configs/mgcoge.h| 93 ---
include/configs/mgcoge3ne.h | 93 ---
4 files changed, 151 insertions(+), 188 deletions(-)
create mode 100644 include/configs/km82xx.h
delete mode 100644 include/configs/mgcoge.h
delete mode 100644 include/configs/mgcoge3ne.h
diff --git a/boards.cfg b/boards.cfg
index 2d36d83..1af87c0 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -577,8 +577,8 @@ PQ2FADS-ZU_66MHz powerpc mpc8260
mpc8260ads freesca
PQ2FADS-ZU_66MHz_lowboot powerpc mpc8260 mpc8260ads
freescale -
MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,8260_CLKIN=6600,SYS_TEXT_BASE=0xFF80
PQ2FADS-ZU_lowboot powerpc mpc8260 mpc8260ads
freescale -
MPC8260ADS:ADSTYPE=CONFIG_SYS_PQ2FADS,SYS_TEXT_BASE=0xFF80
VoVPN-GW_66MHz powerpc mpc8260 vovpn-gw
funkwerk - VoVPN-GW:CLKIN_66MHz
-mgcoge powerpc mpc8260 km82xx
keymile
-mgcoge3nepowerpc mpc8260 km82xx
keymile
+mgcoge powerpc mpc8260 km82xx
keymile- km82xx:MGCOGE
+mgcoge3nepowerpc mpc8260 km82xx
keymile- km82xx:MGCOGE3NE
SCM powerpc mpc8260 -
siemens
TQM8255_AA powerpc mpc8260 tqm8260 tqc
- TQM8260:MPC8255,300MHz
TQM8260_AA powerpc mpc8260 tqm8260 tqc
- TQM8260:MPC8260,200MHz
diff --git a/include/configs/km82xx.h b/include/configs/km82xx.h
new file mode 100644
index 000..5d62f4b
--- /dev/null
+++ b/include/configs/km82xx.h
@@ -0,0 +1,149 @@
+/*
+ * (C) Copyright 2007-2011
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * High Level Configuration Options
+ * (easy to change)
+ */
+
+#define CONFIG_MPC8247
+/* MGCOGE */
+#if defined(CONFIG_MGCOGE)
+#define CONFIG_HOSTNAMEmgcoge
+#define CONFIG_KM_BOARD_EXTRA_ENV
+
+/* MGCOGE3NE */
+#elif defined(CONFIG_MGCOGE3NE)
+#define CONFIG_HOSTNAMEmgcoge3ne
+#define CONFIG_KM_82XX
+#define CONFIG_KM_BOARD_EXTRA_ENV bobcatreset=true\0
+
+#else
+#error (Board unsupported)
+#endif
+
+#defineCONFIG_SYS_TEXT_BASE0xFE00
+
+/* include common defines/options for all Keymile boards */
+#include km/keymile-common.h
+#include km/km-powerpc.h
+
+#define CONFIG_SYS_SDRAM_BASE 0x
+#define CONFIG_SYS_FLASH_BASE 0xFE00
+#define CONFIG_SYS_FLASH_SIZE 32
+#define CONFIG_SYS_FLASH_CFI
+#define CONFIG_FLASH_CFI_DRIVER
+
+/* MGCOGE */
+#if defined(CONFIG_MGCOGE)
+#define CONFIG_SYS_MAX_FLASH_BANKS 3
+/* max num of sects on one chip */
+#define CONFIG_SYS_MAX_FLASH_SECT 512
+
+#define CONFIG_SYS_FLASH_BASE_10x5000
+#define CONFIG_SYS_FLASH_SIZE_132
+#define CONFIG_SYS_FLASH_BASE_20x5200
+#define CONFIG_SYS_FLASH_SIZE_232
+
+#define CONFIG_SYS_FLASH_BANKS_LIST { CONFIG_SYS_FLASH_BASE, \
+ CONFIG_SYS_FLASH_BASE_1, \
+ CONFIG_SYS_FLASH_BASE_2 }
+#define MTDIDS_DEFAULT nor3=app
+
+/*
+ * Bank 1 - 60x bus SDRAM
+ */
+#define SDRAM_MAX_SIZE 0x0800 /* max. 128 MB */
+#define CONFIG_SYS_GLOBAL_SDRAM_LIMIT (256 20) /* less than 256 MB */
+
+/* SDRAM initialization values
+*/
+
+#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \
+
[U-Boot] [PATCH 5/7] powerpc/82xx: add SDRAM detection for km82xx
This patch adds SDRAM detection feature to km82xx boards.
To enable this feature, define CONFIG_SYS_SDRAM_LIST as the initializer
for an array of struct sdram_conf_s.
These structs will expose the bitfields within registers PSDMR and OR1 which
have to be different between configurations; common bitfields will be
defined, as usual, within CONFIG_SYS_PSDMR and CONFIG_SYS_OR1.
If CONFIG_SYS_SDRAM_LIST is not defined, then the usual behavior is retained.
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
board/keymile/km82xx/km82xx.c | 51 +++-
1 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/board/keymile/km82xx/km82xx.c b/board/keymile/km82xx/km82xx.c
index 0e50b0b..67b69f6 100644
--- a/board/keymile/km82xx/km82xx.c
+++ b/board/keymile/km82xx/km82xx.c
@@ -261,6 +261,54 @@ static long int try_init(memctl8260_t *memctl, ulong sdmr,
return size;
}
+#ifdef CONFIG_SYS_SDRAM_LIST
+
+/*
+ * If CONFIG_SYS_SDRAM_LIST is defined, we cycle through all SDRAM
+ * configurations therein (should be from high to lower) to find the
+ * one actually matching the current configuration.
+ * CONFIG_SYS_PSDMR and CONFIG_SYS_OR1 will contain the base values which are
+ * common among all possible configurations; values in CONFIG_SYS_SDRAM_LIST
+ * (defined as the initialization value for the array of struct sdram_conf_s)
+ * will then be ORed with such base values.
+ */
+
+struct sdram_conf_s {
+ ulong size;
+ int or1;
+ int psdmr;
+};
+
+static struct sdram_conf_s sdram_conf[] = CONFIG_SYS_SDRAM_LIST;
+
+static long probe_sdram(memctl8260_t *memctl)
+{
+ int n = 0;
+ long psize = 0;
+
+ for (n = 0; n ARRAY_SIZE(sdram_conf); psize = 0, n++) {
+ psize = try_init(memctl,
+ CONFIG_SYS_PSDMR | sdram_conf[n].psdmr,
+ CONFIG_SYS_OR1 | sdram_conf[n].or1,
+ (uchar *) CONFIG_SYS_SDRAM_BASE);
+ debug(Probing %ld bytes returned %ld\n,
+ sdram_conf[n].size, psize);
+ if (psize == sdram_conf[n].size)
+ break;
+ }
+ return psize;
+}
+
+#else /* CONFIG_SYS_SDRAM_LIST */
+
+static long probe_sdram(memctl8260_t *memctl)
+{
+ return try_init(memctl, CONFIG_SYS_PSDMR, CONFIG_SYS_OR1,
+ (uchar *) CONFIG_SYS_SDRAM_BASE);
+}
+#endif /* CONFIG_SYS_SDRAM_LIST */
+
+
phys_size_t initdram(int board_type)
{
immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
@@ -274,8 +322,7 @@ phys_size_t initdram(int board_type)
#ifndef CONFIG_SYS_RAMBOOT
/* 60x SDRAM setup:
*/
- psize = try_init(memctl, CONFIG_SYS_PSDMR, CONFIG_SYS_OR1,
- (uchar *) CONFIG_SYS_SDRAM_BASE);
+ psize = probe_sdram(memctl);
#endif /* CONFIG_SYS_RAMBOOT */
icache_enable();
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] powerpc/82xx: use SDRAM detection for mgcoge2ne
mgcoge2ne was an intermediate step towards mgcoge3ne. One difference is the
smaller SDRAM on mgcoge2ne (128MB). To support both boards with the same
u-boot we use here the SDRAM detection.
This patch enables SDRAM detection between 256MB and 128MB.
So in addition to the existing 256MB geometry:
4 chips x 8M (13 rows, 10 cols) x 16 bit x 4 banks
we can now also have 128MB geometry:
4 chips x 4M (13 rows, 9 cols) x 16 bit x 4 banks
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
include/configs/km82xx.h | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/include/configs/km82xx.h b/include/configs/km82xx.h
index 9bfb8df..f046337 100644
--- a/include/configs/km82xx.h
+++ b/include/configs/km82xx.h
@@ -119,7 +119,8 @@
/*
* Bank 1 - 60x bus SDRAM
- * mgcoge3ne has 256M.
+ * mgcoge3ne has 256MB
+ * mgcoge2ne has 128MB
*/
#define SDRAM_MAX_SIZE 0x1000 /* max. 256 MB */
#define CONFIG_SYS_GLOBAL_SDRAM_LIMIT (512 20) /* less than 512 MB */
@@ -127,20 +128,28 @@
#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \
ORxS_SDAM_MSK) |\
ORxS_BPD_4 |\
- ORxS_ROWST_PBI1_A4 |\
ORxS_NUMR_13)
#define CONFIG_SYS_PSDMR ( \
PSDMR_PBI |\
- PSDMR_SDAM_A17_IS_A5|\
PSDMR_BSMA_A13_A15 |\
- PSDMR_SDA10_PBI1_A6 |\
PSDMR_RFRC_5_CLK|\
PSDMR_PRETOACT_2W |\
PSDMR_ACTTORW_2W|\
PSDMR_LDOTOPRE_1C |\
PSDMR_WRC_2C|\
PSDMR_CL_2)
+
+#define CONFIG_SYS_SDRAM_LIST { \
+ { .size = 256 20,\
+ .or1= ORxS_ROWST_PBI1_A4, \
+ .psdmr = PSDMR_SDAM_A17_IS_A5 | PSDMR_SDA10_PBI1_A6, \
+ }, \
+ { .size = 128 20,\
+ .or1= ORxS_ROWST_PBI1_A5, \
+ .psdmr = PSDMR_SDAM_A16_IS_A5 | PSDMR_SDA10_PBI1_A7, \
+ }, \
+}
#endif /* defined(CONFIG_MGCOGE3NE) */
/* include further common stuff for all keymile 82xx boards */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] powerpc/82xx: adapt SDRAM settings for mgcoge3ne
The HW guys suggested to change these two values. And these values are
now identical to the values we use on mgcoge.
PSDMR_WRC was set to 1C as it should lead to better performance.
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
Signed-off-by: Holger Brunck holger.bru...@keymile.com
---
include/configs/km82xx.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/configs/km82xx.h b/include/configs/km82xx.h
index f046337..3c2117f 100644
--- a/include/configs/km82xx.h
+++ b/include/configs/km82xx.h
@@ -128,16 +128,18 @@
#define CONFIG_SYS_OR1 ((~(CONFIG_SYS_GLOBAL_SDRAM_LIMIT-1) \
ORxS_SDAM_MSK) |\
ORxS_BPD_4 |\
- ORxS_NUMR_13)
+ ORxS_NUMR_13|\
+ ORxS_IBID)
#define CONFIG_SYS_PSDMR ( \
PSDMR_PBI |\
+ PSDMR_RFEN |\
PSDMR_BSMA_A13_A15 |\
PSDMR_RFRC_5_CLK|\
PSDMR_PRETOACT_2W |\
PSDMR_ACTTORW_2W|\
PSDMR_LDOTOPRE_1C |\
- PSDMR_WRC_2C|\
+ PSDMR_WRC_1C|\
PSDMR_CL_2)
#define CONFIG_SYS_SDRAM_LIST { \
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building u-boot for iMX28 and getting error in mkimage of missing command line parameter CONFIG_IMX_CONFIG
Thanks. I tried that and got the same results. Are there any debug/logging that I can use to see what's going on? Also, I'm not sure which console parameters are passed to the kernel. I've seen console, console_mainline, console_fsl, etc... Which one is actually passed as command line params to the kernel? Thanks, Bill On 7/27/2012 8:11 AM, Fabio Estevam wrote: Bill, On Fri, Jul 27, 2012 at 10:07 AM, Billbsou...@techsi.com wrote: Thanks. That did it! However, now my new U-boot built from the mainstream Uboot runs and also loads and unpacks the Linux kernel - but it dies after that. However, my original U-boot from tlib works fine. Are there some patches and/or settings I am missing? I suppose you are using the 2.6.35 kernel. In this FSL kernel the console is ttyAM0. In mainline kernel the console is ttyAMA0. This is probably the reason you don't see nothing in the console. I would suggest you to use the mainline kernel though. Regards, Fabio Estevam -- William (Bill) L. Sousan, Ph.D. (w) 402.331.4977 ext. 4002 bsou...@techsi.com Technical Support Inc. 11253 John Galt Blvd Omaha, NE 68137 www.techsi.com 8(a) SDB Certified, ISO 9001:2008 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
Feel free to merge it into your work. Thanks. On Fri, Jul 27, 2012 at 10:17 AM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Dear Marek, On Fri, Jul 27, 2012 at 04:09:42 PM, Marek Vasut wrote: [...] Your suggestion is interesting and might be a complement to my series. I don't have time to check its correctness right now, but I'll try soon. Will you two have time to work these into V2 of your series somehow please? Are you asking me to integrate Jim's patch in my series with his SoB once reviewed? If you can negotiate ... Since I have already issued a v2 for 2/5, do you want a v3 of the whole series to be more clear? Otherwise I'm fine with picking up your series and applying Jims patch afterwards ... though I'm not quite sure if it'll apply then. So guys, what do you think? I'm fine with merging Jim's patch once reviewed if he agrees. Regards, Benoît -- *James H Shimer* Motorola Mobility T3-12-HH72 900 Chelmsford Street Lowell MA 08151 978-614-3550 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
I agree with everything, its up to you how to apply the change.
I did see a flags field but thought having a new one was conservative (I
had no real reason to have a new field). As for the typecasts I was
following the API which tests for device ready (Monkey See Monkey Do).
Also I have no compelling reason to need a setter function either. I
have no compelling feelings towards the implementation other than the 5ms
adds an unnecessary delay when the device is already known to be ready, and
this delay accumulates to a very poor performance for large files.
Thanks for working on this!
On Fri, Jul 27, 2012 at 11:06 AM, Marek Vasut ma...@denx.de wrote:
Dear Benoît Thébaudeau,
Hi Jim,
On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs every
10K of
data for fatload usb or 500ms of delay per 1MB of image size. This
adds up
to quite a bit of delay if you're loading a large ramdisk.
Does anyone know what the reason for the 5ms delay really is? I'm
assuming
that this delay is to debounce the 5V/100ma USB power up. I made
some
modification, where the delay is skipped if the device has already
been
queried as ready. This has save me 500ms/M on fatload times (eg,
140M=70seconds). Is there anything wrong with this tweak?
Here's a diff of what I've done to get the performance I need:
--- usb_storage.c.orig 2012-07-26 16:06:40.775251000 -0400
+++ usb_storage.c 2012-07-26 13:49:36.0 -0400
@@ -132,6 +132,7 @@ static block_dev_desc_t usb_dev_desc[USB
struct us_data;
typedef int (*trans_cmnd)(ccb *cb, struct us_data *data);
typedef int (*trans_reset)(struct us_data *data);
+typedef enum us_status { USB_NOT_READY, USB_READY} us_status;
Can we possibly avoid the typedef?
struct us_data {
struct usb_device *pusb_dev; /* this usb_device */
@@ -154,6 +155,7 @@ struct us_data {
ccb *srb; /* current srb */
trans_reset transport_reset;/* reset routine */
trans_cmnd transport; /* transport routine
*/
+ us_status status;
Don't we have some flags for it already?
};
static struct us_data usb_stor[USB_MAX_STOR_DEV];
@@ -691,7 +693,10 @@ int usb_stor_BBB_transport(ccb *srb, str
usb_stor_BBB_reset(us);
return USB_STOR_TRANSPORT_FAILED;
}
- wait_ms(5);
+ if(us-status != USB_READY)
+ {
+ wait_ms(5);
+ }
pipein = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
pipeout = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
/* DATA phase + error handling */
@@ -957,7 +962,10 @@ static int usb_test_unit_ready(ccb *srb,
srb-datalen = 0;
srb-cmdlen = 12;
if (ss-transport(srb, ss) ==
USB_STOR_TRANSPORT_GOOD)
+ {
+ ss-status = USB_READY;
return 0;
+ }
usb_request_sense(srb, ss);
wait_ms(100);
} while (retries--);
@@ -965,6 +973,11 @@ static int usb_test_unit_ready(ccb *srb,
return -1;
}
+static void usb_set_unit_not_ready(struct us_data *ss)
+{
+ ss-status = USB_NOT_READY;
+}
+
We don't need a setter function really.
static int usb_read_capacity(ccb *srb, struct us_data *ss)
{
int retry;
@@ -1108,6 +1121,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
I think we should be much more careful about these typecasts.
USB_STOR_PRINTF(usb_read: end startblk %lx, blccnt %x buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1188,6 +1202,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
Same here.
USB_STOR_PRINTF(usb_write: end startblk %lx, blccnt %x
buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1398,6 +1413,7 @@ int usb_stor_get_info(struct usb_device
cap[0] = 2880;
cap[1] = 0x200;
}
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
The rest is cool.
[...]
--
*James H Shimer*
Motorola Mobility T3-12-HH72
900 Chelmsford Street
Lowell MA 08151
978-614-3550
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 3/7] powerpc/82xx: merge mgcoge.h and mgcoge3ne.h into km82xx.h
Dear Gerlando Falauto, In message 1343402200-32020-4-git-send-email-gerlando.fala...@keymile.com you wrote: Since mgcoge and mgcoge3ne are the only km82xx boards, there is no need to keep them as separate .h config files. Therefore, make mgcoge3ne.h and mgcoge.h converge into a single km82xx.h file. Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- boards.cfg |4 +- include/configs/km82xx.h| 149 +++ include/configs/mgcoge.h| 93 --- include/configs/mgcoge3ne.h | 93 --- 4 files changed, 151 insertions(+), 188 deletions(-) create mode 100644 include/configs/km82xx.h delete mode 100644 include/configs/mgcoge.h delete mode 100644 include/configs/mgcoge3ne.h Can you please try creating this patch with git format-patch with options -M and -C, please? I think git should do better to recognize this rename / merge of two files. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Vor allem kein Gedanke! Nichts ist kompromittierender als ein Gedan- ke!- Friedrich Wilhelm Nietzsche _Der Fall Wagner_ (1888) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] powerpc/82xx: move km/km82xx-common.h within km82xx.h
Dear Gerlando Falauto, In message 1343402200-32020-5-git-send-email-gerlando.fala...@keymile.com you wrote: The only file including km82xx-common.h is km82xx.h. So there is no need to have it as a separate file. Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com --- include/configs/km/km82xx-common.h | 317 include/configs/km82xx.h | 290 - 2 files changed, 289 insertions(+), 318 deletions(-) delete mode 100644 include/configs/km/km82xx-common.h Please also try with -M -C and see if this changes anything. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Obviously, a major malfunction has occurred. -- Steve Nesbitt, voice of Mission Control, January 28, 1986, as the shuttle Challenger exploded within view of the grandstands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] pxa255: Add UDC registers definitions
This patch starts series of patches adding support for USB support on PXA255 chips. Signed-off-by: Łukasz Dałek luk0...@gmail.com --- arch/arm/include/asm/arch-pxa/pxa-regs.h | 247 ++ 1 files changed, 247 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-pxa/pxa-regs.h b/arch/arm/include/asm/arch-pxa/pxa-regs.h index b81b42c..114e9a2 100644 --- a/arch/arm/include/asm/arch-pxa/pxa-regs.h +++ b/arch/arm/include/asm/arch-pxa/pxa-regs.h @@ -2498,6 +2498,253 @@ typedef void(*ExcpHndlr) (void) ; #endif /* CONFIG_CPU_PXA27X */ +#if defined(CONFIG_CPU_PXA25X) + +#ifdef CONFIG_PXA25X_UDC_LINUX +# define UDCCR *((volatile u32 *)0x4060) +#else +# define UDCCR 0x4060 +#endif + +#define UDCCR_UDE (1 0) +#define UDCCR_UDA (1 1) +#define UDCCR_RSM (1 2) +#define UDCCR_RESIR(1 3) +#define UDCCR_SUSIR(1 4) +#define UDCCR_SRM (1 5) +#define UDCCR_RSTIR(1 6) +#define UDCCR_REM (1 7) + +#ifdef CONFIG_PXA25X_UDC_LINUX +# define UDCCFR*((volatile u32 *)0x4068) +#else +# define UDCCFR0x4068 +#endif + +#define UDCCFR_AREN(1 7) +#define UDCCFR_ACM (1 2) +#define UDCCFR_MB1 (0xff ~(UDCCFR_AREN | UDCCFR_ACM)) + +#ifdef CONFIG_PXA25X_UDC_LINUX +# define UICR0 *((volatile u32 *)0x40600050) +#else +# define UICR0 0x40600050 +#endif + +#define UICR0_MASK 0xf +#define UICR0_IM0 (1 0) + +#ifdef CONFIG_PXA25X_UDC_LINUX +# define UICR1 *((volatile u32 *)0x40600054) +#else +# define UICR1 0x40600054 +#endif + +#define UICR1_MASK 0xf + +#ifdef CONFIG_PXA25X_UDC_LINUX +# define USIR0 *((volatile u32 *)0x40600058) +#else +# define USIR0 0x40600058 +#endif + +#define USIR0_MASK 0xf +#define USIR0_IR0 (1 0) +#define USIR0_IR1 (1 1) +#define USIR0_IR2 (1 2) +#define USIR0_IR3 (1 3) +#define USIR0_IR4 (1 4) +#define USIR0_IR5 (1 5) +#define USIR0_IR6 (1 6) +#define USIR0_IR7 (1 7) + +#ifdef CONFIG_PXA25X_UDC_LINUX +# define USIR1 *((volatile u32 *)0x4060005c) +#else +# define USIR1 0x4060005c +#endif + +#define USIR1_MASK 0xf +#define USIR1_IR8 (1 0) +#define USIR1_IR9 (1 1) +#define USIR1_IR10 (1 2) +#define USIR1_IR11 (1 3) +#define USIR1_IR12 (1 4) +#define USIR1_IR13 (1 5) +#define USIR1_IR14 (1 6) +#define USIR1_IR15 (1 7) + +#ifdef CONFIG_PXA25X_UDC_LINUX +# define UDCCS0*((volatile u32 *)0x40600010) +# define UDCCS1*((volatile u32 *)0x40600014) +# define UDCCS2*((volatile u32 *)0x40600018) +# define UDCCS3*((volatile u32 *)0x4060001c) +# define UDCCS4*((volatile u32 *)0x40600020) +# define UDCCS5*((volatile u32 *)0x40600024) +# define UDCCS6*((volatile u32 *)0x40600028) +# define UDCCS7*((volatile u32 *)0x4060002c) +# define UDCCS8*((volatile u32 *)0x40600030) +# define UDCCS9*((volatile u32 *)0x40600034) +# define UDCCS10 *((volatile u32 *)0x40600038) +# define UDCCS11 *((volatile u32 *)0x4060003c) +# define UDCCS12 *((volatile u32 *)0x40600040) +# define UDCCS13 *((volatile u32 *)0x40600044) +# define UDCCS14 *((volatile u32 *)0x40600048) +# define UDCCS15 *((volatile u32 *)0x4060004c) +#else +# define UDCCS(x) (0x40600010 + 4 * (x)) +# define UDCCS0UDCCS(0) +#endif + +/* Control endpoint 0 */ +#define UDCCS_CTRL_OPR (1 0) +#define UDCCS_CTRL_IPR (1 1) +#define UDCCS_CTRL_FTF (1 2) +#define UDCCS_CTRL_DRWF(1 3) +#define UDCCS_CTRL_SST (1 4) +#define UDCCS_CTRL_FST (1 5) +#define UDCCS_CTRL_RNE (1 6) +#define UDCCS_CTRL_SA (1 7) + +/* Linux compat */ +#define UDCCS0_SA UDCCS_CTRL_SA +#define UDCCS0_RNE UDCCS_CTRL_RNE +#define UDCCS0_FST UDCCS_CTRL_FST +#define UDCCS0_SST UDCCS_CTRL_SST +#define UDCCS0_DRWFUDCCS_CTRL_DRWF +#define UDCCS0_FTF UDCCS_CTRL_FTF +#define UDCCS0_IPR UDCCS_CTRL_IPR +#define UDCCS0_OPR UDCCS_CTRL_OPR + +/* Bulk IN endpoint 1/6/11 */ +#define UDCCS_BULK_IN_TSP (1 7) +#define UDCCS_BULK_IN_FST (1 5) +#define UDCCS_BULK_IN_SST (1 4) +#define UDCCS_BULK_IN_TUR (1 3) +#define UDCCS_BULK_IN_FTF (1 2) +#define
[U-Boot] [PATCH 2/5] drivers/usb/gadget/Makefile: Add UDC ACM and Ether
Compile USB ttyACM and Ethernet drivers on pxa255. Signed-off-by: Łukasz Dałek luk0...@gmail.com --- drivers/usb/gadget/Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 87d1918..7307595 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,6 +34,7 @@ ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o COBJS-$(CONFIG_USB_ETH_RNDIS) += rndis.o COBJS-$(CONFIG_MV_UDC) += mv_udc.o +COBJS-$(CONFIG_CPU_PXA25X) += pxa25x_udc_linux.o else # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE ifdef CONFIG_USB_DEVICE @@ -43,6 +44,7 @@ COBJS-$(CONFIG_DW_UDC) += designware_udc.o COBJS-$(CONFIG_OMAP1510) += omap1510_udc.o COBJS-$(CONFIG_OMAP1610) += omap1510_udc.o COBJS-$(CONFIG_MPC885_FAMILY) += mpc8xx_udc.o +COBJS-$(CONFIG_CPU_PXA25X) += pxa25x_udc.o COBJS-$(CONFIG_CPU_PXA27X) += pxa27x_udc.o endif endif -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] pxa255: Add USB CDC ACM driver
Signed-off-by: Łukasz Dałek luk0...@gmail.com
---
drivers/serial/usbtty.h |2 +
drivers/usb/gadget/pxa25x_udc.c | 939 +++
include/usb/pxa25x_udc.h| 65 +++
3 files changed, 1006 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/gadget/pxa25x_udc.c
create mode 100644 include/usb/pxa25x_udc.h
diff --git a/drivers/serial/usbtty.h b/drivers/serial/usbtty.h
index eb670da..632b54e 100644
--- a/drivers/serial/usbtty.h
+++ b/drivers/serial/usbtty.h
@@ -31,6 +31,8 @@
#include usb/omap1510_udc.h
#elif defined(CONFIG_MUSB_UDC)
#include usb/musb_udc.h
+#elif defined(CONFIG_CPU_PXA25X)
+#include usb/pxa25x_udc.h
#elif defined(CONFIG_CPU_PXA27X)
#include usb/pxa27x_udc.h
#elif defined(CONFIG_DW_UDC)
diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c
new file mode 100644
index 000..4ff98cc
--- /dev/null
+++ b/drivers/usb/gadget/pxa25x_udc.c
@@ -0,0 +1,939 @@
+/*
+ * PXA25x USB device driver for u-boot.
+ *
+ * Copyright (C) 2012 Łukasz Dałek luk0...@gmail.com
+ *
+ * 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
+ *
+ * based on drivers/usb/gadget/pxa27x_udc.c
+ *
+ */
+
+#include common.h
+#include config.h
+#include usb/pxa25x_udc.h
+#include asm/io.h
+#include asm/arch/hardware.h
+#include ep0.h
+
+struct pxa25x_endpoint {
+ u8 num;
+ u32 uddr;
+ u32 udccs;
+ u32 ubcr;
+};
+
+static struct pxa25x_endpoint eps[] = {
+ { 0, UDDR0, UDCCS(0), 0 },
+ { 1, UDDR1, UDCCS(1), 0 },
+ { 2, UDDR2, UDCCS(2), UBCR2 },
+ { 3, UDDR3, UDCCS(3), 0 },
+ { 4, UDDR4, UDCCS(4), UBCR4 },
+ { 5, UDDR5, UDCCS(5), 0 },
+ { 6, UDDR6, UDCCS(6), 0 },
+ { 7, UDDR7, UDCCS(7), UBCR7 },
+ { 8, UDDR8, UDCCS(8), 0 },
+ { 9, UDDR9, UDCCS(9), UBCR9 },
+ { 10, UDDR10, UDCCS(10), 0 },
+ { 11, UDDR11, UDCCS(11), 0 },
+ { 12, UDDR12, UDCCS(12), UBCR12 },
+ { 13, UDDR13, UDCCS(13), 0 },
+ { 14, UDDR14, UDCCS(14), UBCR14 },
+ { 15, UDDR15, UDCCS(15), 0 },
+};
+
+static struct usb_device_instance *udc_device;
+static struct urb *ep0_urb;
+static int ep0state = EP0_IDLE;
+static int ep0laststate = EP0_IDLE;
+
+static inline void udc_set_reg(u32 reg, u32 mask)
+{
+ u32 val;
+
+ val = readl(reg);
+ val |= mask;
+ writel(val, reg);
+}
+
+static inline void udc_clear_reg(u32 reg, u32 mask)
+{
+ u32 val;
+
+ val = readl(reg);
+ val = ~mask;
+ writel(val, reg);
+}
+
+/* static void udc_dump_buffer(char *name, u8 *buf, int len)
+{
+ usbdbg(%s - buf %p, len %d, name, buf, len);
+ print_buffer(0, buf, 1, len, 0);
+} */
+
+static void udc_dump_buffer(u8 *data, int len)
+{
+ u8 buff[8 * 5 + 1]; /* 8 characters 0x??_ + null */
+ int i;
+
+ for (i = 0; i len; ++i) {
+ int n = i % 8;
+ buff[n * 5 + 0] = '0';
+ buff[n * 5 + 1] = 'x';
+
+ u8 ch = data[i] 4;
+ buff[n * 5 + 2] = (ch 10)?(ch + '0'):(ch - 10 + 'a');
+ ch = data[i] 0xf;
+ buff[n * 5 + 3] = (ch 10)?(ch + '0'):(ch - 10 + 'a');
+ buff[n * 5 + 4] = ' ';
+
+ buff[n * 5 + 5] = 0x0;
+
+ if (n == 7)
+ usbdbg(%s, buff);
+ }
+
+}
+
+static void udc_flush_fifo(struct usb_endpoint_instance *endpoint)
+{
+ int ep_num = endpoint-endpoint_address USB_ENDPOINT_NUMBER_MASK,
+ isout =
+ (endpoint-endpoint_address USB_ENDPOINT_DIR_MASK) ==
USB_DIR_OUT;
+ int ep_type;
+ u32 val;
+
+ if (ep_num 15) {
+ usberr(%s: endpoint out of range %d, __func__, ep_num);
+ return ;
+ }
+
+ if (!ep_num) {
+ while (readl(UDCCS0) UDCCS_CTRL_RNE)
+ readl(UDDR0);
+ writel(UDCCS_CTRL_FTF, UDCCS0);
+ usbdbg(flushed endpoint 0 (udccs0 0x%02X),
+ readl(UDCCS0) 0xff);
+ return ;
+ }
+
+ if (isout) {
+ while (readl(eps[ep_num].udccs) UDCCS_BULK_OUT_RNE)
+ readl(eps[ep_num].uddr);
+ usbdbg(out endpoint %d flushed, ep_num);
+ return ;
[U-Boot] [PATCH 5/5] usbether: Fixed bug when using with PXA25X chips
PXA25X chips don't support alternate settings so code in ether.c
disables usage of CDC.
But only code defined between DEV_CONFIG_CDC signals that network is up.
This patch is fixing this bug by addding pxa_connect_gadget() which on
pxa25x chips signals that network is up and do nothing on any other
chips.
Signed-off-by: Łukasz Dałek luk0...@gmail.com
---
drivers/usb/gadget/ether.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index d975fb6..964fe2e 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -44,7 +44,12 @@ extern struct platform_data brd;
unsigned packet_received, packet_sent;
-#define DEV_CONFIG_CDC 1
+#ifdef CONFIG_USB_GADGET_PXA2XX
+# undef DEV_CONFIG_CDC
+# define DEV_CONFIG_SUBSET 1
+#else
+# define DEV_CONFIG_CDC1
+#endif
#define GFP_ATOMIC ((gfp_t) 0)
#define GFP_KERNEL ((gfp_t) 0)
@@ -864,7 +869,9 @@ static struct usb_gadget_stringsstringtab = {
/**/
static u8 control_req[USB_BUFSIZ];
+#if defined(DEV_CONFIG_CDC) || defined(CONFIG_USB_ETH_RNDIS)
static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+#endif
/**
@@ -1252,6 +1259,17 @@ static void rndis_command_complete(struct usb_ep *ep,
struct usb_request *req)
#endif /* RNDIS */
+#ifdef CONFIG_USB_GADGET_PXA2XX
+static inline void pxa_connect_gadget(void)
+{
+ debug(PXA connecting gadget...\n);
+ l_ethdev.network_started = 1;
+ printf(USB network up!\n);
+}
+#else
+static inline void pxa_connect_gadget(void) { }
+#endif
+
/*
* The setup() callback implements all the ep0 functionality that's not
* handled lower down. CDC has a number of less-common features:
@@ -1352,6 +1370,7 @@ eth_setup(struct usb_gadget *gadget, const struct
usb_ctrlrequest *ctrl)
if (gadget_is_pxa(gadget)) {
value = eth_set_config(dev, DEV_CONFIG_VALUE,
GFP_ATOMIC);
+ pxa_connect_gadget();
goto done_set_intf;
}
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] dm: sparc: common: Fixup cmd_bdinfo warnings
cmd_bdinfo.c: In function ‘do_bdinfo’: cmd_bdinfo.c:220:9: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat] cmd_bdinfo.c:222:9: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat] cmd_bdinfo.c:224:9: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat] cmd_bdinfo.c:226:9: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat] cmd_bdinfo.c:228:9: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat] Signed-off-by: Marek Vasut ma...@denx.de Cc: Daniel Hellstrom dan...@gaisler.com Cc: u-boot...@lists.denx.de --- common/cmd_bdinfo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index 42f08fd..23bd8a5 100644 --- a/common/cmd_bdinfo.c +++ b/common/cmd_bdinfo.c @@ -216,15 +216,15 @@ int do_bdinfo(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) print_num(flashstart , bd-bi_flashstart); print_num(CONFIG_SYS_MONITOR_BASE , CONFIG_SYS_MONITOR_BASE); print_num(CONFIG_ENV_ADDR , CONFIG_ENV_ADDR); - printf(CONFIG_SYS_RELOC_MONITOR_BASE = 0x%lx (%d)\n, CONFIG_SYS_RELOC_MONITOR_BASE, + printf(CONFIG_SYS_RELOC_MONITOR_BASE = 0x%x (%d)\n, CONFIG_SYS_RELOC_MONITOR_BASE, CONFIG_SYS_MONITOR_LEN); - printf(CONFIG_SYS_MALLOC_BASE= 0x%lx (%d)\n, CONFIG_SYS_MALLOC_BASE, + printf(CONFIG_SYS_MALLOC_BASE= 0x%x (%d)\n, CONFIG_SYS_MALLOC_BASE, CONFIG_SYS_MALLOC_LEN); - printf(CONFIG_SYS_INIT_SP_OFFSET = 0x%lx (%d)\n, CONFIG_SYS_INIT_SP_OFFSET, + printf(CONFIG_SYS_INIT_SP_OFFSET = 0x%x (%d)\n, CONFIG_SYS_INIT_SP_OFFSET, CONFIG_SYS_STACK_SIZE); - printf(CONFIG_SYS_PROM_OFFSET= 0x%lx (%d)\n, CONFIG_SYS_PROM_OFFSET, + printf(CONFIG_SYS_PROM_OFFSET= 0x%x (%d)\n, CONFIG_SYS_PROM_OFFSET, CONFIG_SYS_PROM_SIZE); - printf(CONFIG_SYS_GBL_DATA_OFFSET= 0x%lx (%d)\n, CONFIG_SYS_GBL_DATA_OFFSET, + printf(CONFIG_SYS_GBL_DATA_OFFSET= 0x%x (%d)\n, CONFIG_SYS_GBL_DATA_OFFSET, GENERATED_GBL_DATA_SIZE); #if defined(CONFIG_CMD_NET) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] dm: sparc: net: Fixup greth compile warnings
greth.c: In function ‘greth_recv’:
greth.c:507:3: warning: format ‘%lx’ expects argument of type ‘long unsigned
int’, but argument 2 has type ‘unsigned int’ [-Wformat]
greth.c:507:3: warning: format ‘%lx’ expects argument of type ‘long unsigned
int’, but argument 3 has type ‘unsigned int’ [-Wformat]
greth.c:541:6: warning: pointer targets in assignment differ in signedness
[-Wpointer-sign]
greth.c: In function ‘greth_initialize’:
greth.c:623:2: warning: format ‘%lx’ expects argument of type ‘long unsigned
int’, but argument 2 has type ‘struct greth_regs *’ [-Wformat]
greth.c:655:3: warning: format ‘%x’ expects argument of type ‘unsigned int’,
but argument 2 has type ‘struct greth_regs *’ [-Wformat]
greth.c:684:2: warning: format ‘%x’ expects argument of type ‘unsigned int’,
but argument 2 has type ‘struct greth_regs *’ [-Wformat]
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Hellstrom dan...@gaisler.com
Cc: u-boot...@lists.denx.de
---
drivers/net/greth.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 08206c8..3103a74 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -483,7 +483,7 @@ int greth_recv(struct eth_device *dev)
greth_regs *regs = greth-regs;
greth_bd *rxbd;
unsigned int status, len = 0, bad;
- unsigned char *d;
+ char *d;
int enable = 0;
int i;
@@ -504,7 +504,7 @@ int greth_recv(struct eth_device *dev)
goto done;
}
- debug(greth_recv: packet 0x%lx, 0x%lx, len: %d\n,
+ debug(greth_recv: packet 0x%x, 0x%x, len: %d\n,
(unsigned int)rxbd, status, status GRETH_BD_LEN);
/* Check status for errors.
@@ -620,7 +620,7 @@ int greth_initialize(bd_t * bis)
greth-regs = (greth_regs *) apbdev.address;
greth-irq = apbdev.irq;
- debug(Found GRETH at 0x%lx, irq %d\n, greth-regs, greth-irq);
+ debug(Found GRETH at %p, irq %d\n, greth-regs, greth-irq);
dev-priv = (void *)greth;
dev-iobase = (unsigned int)greth-regs;
dev-init = greth_init;
@@ -652,7 +652,7 @@ int greth_initialize(bd_t * bis)
/* initiate PHY, select speed/duplex depending on connected PHY */
if (greth_init_phy(greth, bis)) {
/* Failed to init PHY (timedout) */
- debug(GRETH[0x%08x]: Failed to init PHY\n, greth-regs);
+ debug(GRETH[%p]: Failed to init PHY\n, greth-regs);
return -1;
}
@@ -681,6 +681,6 @@ int greth_initialize(bd_t * bis)
/* set and remember MAC address */
greth_set_hwaddr(greth, addr);
- debug(GRETH[0x%08x]: Initialized successfully\n, greth-regs);
+ debug(GRETH[%p]: Initialized successfully\n, greth-regs);
return 0;
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] dm: sparc: Fixup the compile warnings in sparc code
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Daniel Hellstrom dan...@gaisler.com
Cc: u-boot...@lists.denx.de
---
arch/sparc/cpu/leon2/interrupts.c |6 +++---
arch/sparc/cpu/leon3/interrupts.c |6 +++---
arch/sparc/lib/board.c|1 -
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/sparc/cpu/leon2/interrupts.c
b/arch/sparc/cpu/leon2/interrupts.c
index 5149550..f707efd 100644
--- a/arch/sparc/cpu/leon2/interrupts.c
+++ b/arch/sparc/cpu/leon2/interrupts.c
@@ -207,9 +207,9 @@ void do_irqinfo(cmd_tbl_t * cmdtp, bd_t * bd, int flag, int
argc, char * const a
for (irq = 0; irq NR_IRQS; irq++) {
if (irq_handlers[irq].handler != NULL) {
- printf(%02d %08lx %08lx %ld\n, irq,
- (unsigned int)irq_handlers[irq].handler,
- (unsigned int)irq_handlers[irq].arg,
+ printf(%02d %p %p %d\n, irq,
+ irq_handlers[irq].handler,
+ irq_handlers[irq].arg,
irq_handlers[irq].count);
}
}
diff --git a/arch/sparc/cpu/leon3/interrupts.c
b/arch/sparc/cpu/leon3/interrupts.c
index 4138f9b..4a3847d 100644
--- a/arch/sparc/cpu/leon3/interrupts.c
+++ b/arch/sparc/cpu/leon3/interrupts.c
@@ -209,9 +209,9 @@ void do_irqinfo(cmd_tbl_t * cmdtp, bd_t * bd, int flag, int
argc, char * const a
for (irq = 0; irq NR_IRQS; irq++) {
if (irq_handlers[irq].handler != NULL) {
- printf(%02d %08lx %08lx %ld\n, irq,
- (unsigned int)irq_handlers[irq].handler,
- (unsigned int)irq_handlers[irq].arg,
+ printf(%02d %p %p %d\n, irq,
+ irq_handlers[irq].handler,
+ irq_handlers[irq].arg,
irq_handlers[irq].count);
}
}
diff --git a/arch/sparc/lib/board.c b/arch/sparc/lib/board.c
index 7e48775..6f33666 100644
--- a/arch/sparc/lib/board.c
+++ b/arch/sparc/lib/board.c
@@ -166,7 +166,6 @@ char *str_init_seq_done = \n\rInit sequence
done...\r\n\r\n;
void board_init_f(ulong bootflag)
{
bd_t *bd;
- unsigned char *s;
init_fnc_t **init_fnc_ptr;
int j;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] mx28evk kernel does not boot with 2012.07-rc3
Hi, I have just tried the latest U-boot and I am getting the following when trying to load today's linux-next: U-Boot 2012.07-rc3 (Jul 27 2012 - 14:45:19) Freescale i.MX28 family at 454 MHz BOOT: SSP SD/MMC #0, 3V3 I2C: ready DRAM: 128 MiB MMC: MXS MMC: 0 In:serial Out: serial Err: serial Net: FEC0, FEC1 Hit any key to stop autoboot: 0 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.22 Using FEC0 device TFTP from server 10.29.240.146; our IP address is 10.29.244.22 Filename 'uImage'. Load address: 0x4200 Loading: ## Warning: gatewayip needed but not set # # # # # # # # # # done Bytes transferred = 3343968 (330660 hex) ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux-3.5.0-next-20120727+ Created: 2012-07-27 17:27:30 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3343904 Bytes = 3.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... data abort pc : [47fa74f0] lr : [47f86f44] sp : 47b80ca8 ip : 80338620 fp : r10: 42330660 r9 : 4240 r8 : 47b80f68 r7 : 4200 r6 : r5 : 47b80d1c r4 : r3 : r2 : 0033061f r1 : 42330660 r0 : 80008000 Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... If I use the latest stable kernel I get: U-Boot 2012.07-rc3 (Jul 27 2012 - 14:45:19) Freescale i.MX28 family at 454 MHz BOOT: SSP SD/MMC #0, 3V3 I2C: ready DRAM: 128 MiB MMC: MXS MMC: 0 In:serial Out: serial Err: serial Net: FEC0, FEC1 Hit any key to stop autoboot: 0 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.22 Using FEC0 device TFTP from server 10.29.240.146; our IP address is 10.29.244.22 Filename 'uImage'. Load address: 0x4200 Loading: ## Warning: gatewayip needed but not set # # # # # # # # # ### done Bytes transferred = 3170352 (306030 hex) ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux-3.4.6 Created: 2012-07-26 23:30:59 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3170288 Bytes = 3 MiB Load Address: 90008000 Entry Point: 90008000 Verifying Checksum ... OK Loading Kernel Image ... Is there any patch missing or any ideas? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building u-boot for iMX28 and getting error in mkimage of missing command line parameter CONFIG_IMX_CONFIG
On Fri, Jul 27, 2012 at 12:35 PM, Bill bsou...@techsi.com wrote: Thanks. I tried that and got the same results. Are there any debug/logging that I can use to see what's going on? I just tried it here and 2012.07-rc3 does not boot for me too. I started another thread on that. I suggest you to use 2012.04.01. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: mips: Import libgcc components from Linux
Import ashldr3, ashrdi3 and lshrdi3 to squash possible libgcc fp mismatch,
resulting in the following warning:
mips-linux-gnu-ld: Warning:
/usr/lib/gcc/mips-linux-gnu/4.7/libgcc.a(_lshrdi3.o) uses hard float, u-boot
uses soft float
mips-linux-gnu-ld: Warning:
/usr/lib/gcc/mips-linux-gnu/4.7/libgcc.a(_ashldi3.o) uses hard float, u-boot
uses soft float
Imported from Linux (linux-next 20120723) as of commit:
commit 72fbfb260197a52c2bc2583f3e8f15d261d0f924
Author: Ralf Baechle r...@linux-mips.org
Date: Wed Jun 7 13:25:37 2006 +0100
[MIPS] Fix optimization for size build.
It took a while longer than on other architectures but gcc has finally
started to strike us as well ...
This also fixes the damage by 6edfba1b33c701108717f4e036320fc39abe1912.
Signed-off-by: Ralf Baechle r...@linux-mips.org
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
---
arch/mips/lib/Makefile |2 ++
arch/mips/lib/ashldi3.c | 25 +
arch/mips/lib/ashrdi3.c | 27 +++
arch/mips/lib/libgcc.h | 25 +
arch/mips/lib/lshrdi3.c | 25 +
5 files changed, 104 insertions(+)
create mode 100644 arch/mips/lib/ashldi3.c
create mode 100644 arch/mips/lib/ashrdi3.c
create mode 100644 arch/mips/lib/libgcc.h
create mode 100644 arch/mips/lib/lshrdi3.c
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 9244f31..a469e30 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -34,6 +34,8 @@ else
COBJS-y+= bootm.o
endif
+COBJS-y+= ashldi3.o ashrdi3.o lshrdi3.o
+
SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/arch/mips/lib/ashldi3.c b/arch/mips/lib/ashldi3.c
new file mode 100644
index 000..9b50d86
--- /dev/null
+++ b/arch/mips/lib/ashldi3.c
@@ -0,0 +1,25 @@
+#include libgcc.h
+
+long long __ashldi3(long long u, word_type b)
+{
+ DWunion uu, w;
+ word_type bm;
+
+ if (b == 0)
+ return u;
+
+ uu.ll = u;
+ bm = 32 - b;
+
+ if (bm = 0) {
+ w.s.low = 0;
+ w.s.high = (unsigned int) uu.s.low -bm;
+ } else {
+ const unsigned int carries = (unsigned int) uu.s.low bm;
+
+ w.s.low = (unsigned int) uu.s.low b;
+ w.s.high = ((unsigned int) uu.s.high b) | carries;
+ }
+
+ return w.ll;
+}
diff --git a/arch/mips/lib/ashrdi3.c b/arch/mips/lib/ashrdi3.c
new file mode 100644
index 000..f30359b
--- /dev/null
+++ b/arch/mips/lib/ashrdi3.c
@@ -0,0 +1,27 @@
+#include libgcc.h
+
+long long __ashrdi3(long long u, word_type b)
+{
+ DWunion uu, w;
+ word_type bm;
+
+ if (b == 0)
+ return u;
+
+ uu.ll = u;
+ bm = 32 - b;
+
+ if (bm = 0) {
+ /* w.s.high = 1..1 or 0..0 */
+ w.s.high =
+ uu.s.high 31;
+ w.s.low = uu.s.high -bm;
+ } else {
+ const unsigned int carries = (unsigned int) uu.s.high bm;
+
+ w.s.high = uu.s.high b;
+ w.s.low = ((unsigned int) uu.s.low b) | carries;
+ }
+
+ return w.ll;
+}
diff --git a/arch/mips/lib/libgcc.h b/arch/mips/lib/libgcc.h
new file mode 100644
index 000..05909d5
--- /dev/null
+++ b/arch/mips/lib/libgcc.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_LIBGCC_H
+#define __ASM_LIBGCC_H
+
+#include asm/byteorder.h
+
+typedef int word_type __attribute__ ((mode (__word__)));
+
+#ifdef __BIG_ENDIAN
+struct DWstruct {
+ int high, low;
+};
+#elif defined(__LITTLE_ENDIAN)
+struct DWstruct {
+ int low, high;
+};
+#else
+#error I feel sick.
+#endif
+
+typedef union {
+ struct DWstruct s;
+ long long ll;
+} DWunion;
+
+#endif /* __ASM_LIBGCC_H */
diff --git a/arch/mips/lib/lshrdi3.c b/arch/mips/lib/lshrdi3.c
new file mode 100644
index 000..bb340ac
--- /dev/null
+++ b/arch/mips/lib/lshrdi3.c
@@ -0,0 +1,25 @@
+#include libgcc.h
+
+long long __lshrdi3(long long u, word_type b)
+{
+ DWunion uu, w;
+ word_type bm;
+
+ if (b == 0)
+ return u;
+
+ uu.ll = u;
+ bm = 32 - b;
+
+ if (bm = 0) {
+ w.s.high = 0;
+ w.s.low = (unsigned int) uu.s.high -bm;
+ } else {
+ const unsigned int carries = (unsigned int) uu.s.high bm;
+
+ w.s.high = (unsigned int) uu.s.high b;
+ w.s.low = ((unsigned int) uu.s.low b) | carries;
+ }
+
+ return w.ll;
+}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb_stor_BBB_transport 5 ms delay - performance
Dear Jim Shimer,
I agree with everything, its up to you how to apply the change.
Heh ;-)
I did see a flags field but thought having a new one was conservative (I
had no real reason to have a new field). As for the typecasts I was
following the API which tests for device ready (Monkey See Monkey Do).
Ouch, the API seems so broken then :-(
Also I have no compelling reason to need a setter function either. I
have no compelling feelings towards the implementation other than the 5ms
adds an unnecessary delay when the device is already known to be ready, and
this delay accumulates to a very poor performance for large files.
Correct!
Thanks for working on this!
No, thank you!
On Fri, Jul 27, 2012 at 11:06 AM, Marek Vasut ma...@denx.de wrote:
Dear Benoît Thébaudeau,
Hi Jim,
On Thu, Jul 26, 2012 at 10:20:48 PM, Jim Shimer wrote:
I'm seeing a 5ms delay in usb_stor_BBB_transport, which occurs every
10K of
data for fatload usb or 500ms of delay per 1MB of image size. This
adds up
to quite a bit of delay if you're loading a large ramdisk.
Does anyone know what the reason for the 5ms delay really is? I'm
assuming
that this delay is to debounce the 5V/100ma USB power up. I made
some
modification, where the delay is skipped if the device has already
been
queried as ready. This has save me 500ms/M on fatload times (eg,
140M=70seconds). Is there anything wrong with this tweak?
Here's a diff of what I've done to get the performance I need:
--- usb_storage.c.orig 2012-07-26 16:06:40.775251000 -0400
+++ usb_storage.c 2012-07-26 13:49:36.0 -0400
@@ -132,6 +132,7 @@ static block_dev_desc_t usb_dev_desc[USB
struct us_data;
typedef int (*trans_cmnd)(ccb *cb, struct us_data *data);
typedef int (*trans_reset)(struct us_data *data);
+typedef enum us_status { USB_NOT_READY, USB_READY} us_status;
Can we possibly avoid the typedef?
struct us_data {
struct usb_device *pusb_dev; /* this usb_device */
@@ -154,6 +155,7 @@ struct us_data {
ccb *srb; /* current srb */
trans_reset transport_reset;/* reset routine */
trans_cmnd transport; /* transport routine
*/
+ us_status status;
Don't we have some flags for it already?
};
static struct us_data usb_stor[USB_MAX_STOR_DEV];
@@ -691,7 +693,10 @@ int usb_stor_BBB_transport(ccb *srb, str
usb_stor_BBB_reset(us);
return USB_STOR_TRANSPORT_FAILED;
}
- wait_ms(5);
+ if(us-status != USB_READY)
+ {
+ wait_ms(5);
+ }
pipein = usb_rcvbulkpipe(us-pusb_dev, us-ep_in);
pipeout = usb_sndbulkpipe(us-pusb_dev, us-ep_out);
/* DATA phase + error handling */
@@ -957,7 +962,10 @@ static int usb_test_unit_ready(ccb *srb,
srb-datalen = 0;
srb-cmdlen = 12;
if (ss-transport(srb, ss) ==
USB_STOR_TRANSPORT_GOOD)
+ {
+ ss-status = USB_READY;
return 0;
+ }
usb_request_sense(srb, ss);
wait_ms(100);
} while (retries--);
@@ -965,6 +973,11 @@ static int usb_test_unit_ready(ccb *srb,
return -1;
}
+static void usb_set_unit_not_ready(struct us_data *ss)
+{
+ ss-status = USB_NOT_READY;
+}
+
We don't need a setter function really.
static int usb_read_capacity(ccb *srb, struct us_data *ss)
{
int retry;
@@ -1108,6 +1121,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
I think we should be much more careful about these typecasts.
USB_STOR_PRINTF(usb_read: end startblk %lx, blccnt %x buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1188,6 +1202,7 @@ retry_it:
blks -= smallblks;
buf_addr += srb-datalen;
} while (blks != 0);
+ usb_set_unit_not_ready((struct us_data *)dev-privptr);
Same here.
USB_STOR_PRINTF(usb_write: end startblk %lx, blccnt %x
buffer
%lx\n,
start, smallblks, buf_addr);
@@ -1398,6 +1413,7 @@ int usb_stor_get_info(struct usb_device
cap[0] = 2880;
cap[1] = 0x200;
Re: [U-Boot] mx28evk kernel does not boot with 2012.07-rc3
Dear Fabio Estevam, Hi, I have just tried the latest U-boot and I am getting the following when trying to load today's linux-next: Nhoo! :'-C Wakizashi, here I come ... U-Boot 2012.07-rc3 (Jul 27 2012 - 14:45:19) Freescale i.MX28 family at 454 MHz BOOT: SSP SD/MMC #0, 3V3 I2C: ready DRAM: 128 MiB MMC: MXS MMC: 0 In:serial Out: serial Err: serial Net: FEC0, FEC1 Hit any key to stop autoboot: 0 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.22 Using FEC0 device TFTP from server 10.29.240.146; our IP address is 10.29.244.22 Filename 'uImage'. Load address: 0x4200 Loading: ## Warning: gatewayip needed but not set # # # # # # # # # # done Bytes transferred = 3343968 (330660 hex) ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux-3.5.0-next-20120727+ Created: 2012-07-27 17:27:30 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3343904 Bytes = 3.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... data abort pc : [47fa74f0] lr : [47f86f44] sp : 47b80ca8 ip : 80338620 fp : r10: 42330660 r9 : 4240 r8 : 47b80f68 r7 : 4200 r6 : r5 : 47b80d1c r4 : r3 : r2 : 0033061f r1 : 42330660 r0 : 80008000 Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... If I use the latest stable kernel I get: U-Boot 2012.07-rc3 (Jul 27 2012 - 14:45:19) Freescale i.MX28 family at 454 MHz BOOT: SSP SD/MMC #0, 3V3 I2C: ready DRAM: 128 MiB MMC: MXS MMC: 0 In:serial Out: serial Err: serial Net: FEC0, FEC1 Hit any key to stop autoboot: 0 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.29.244.22 Using FEC0 device TFTP from server 10.29.240.146; our IP address is 10.29.244.22 Filename 'uImage'. Load address: 0x4200 Loading: ## Warning: gatewayip needed but not set # # # # # # # # # ### done Bytes transferred = 3170352 (306030 hex) ## Booting kernel from Legacy Image at 4200 ... Image Name: Linux-3.4.6 Created: 2012-07-26 23:30:59 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3170288 Bytes = 3 MiB Load Address: 90008000 Entry Point: 90008000 Verifying Checksum ... OK Loading Kernel Image ... Is there any patch missing or any ideas? I'm stuck at 20120723 for a bit ... I'll need to resync. Do you suspect uboot issue or kernel bug? Thanks, Fabio Estevam Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mx28evk kernel does not boot with 2012.07-rc3
Hi Marek, On Fri, Jul 27, 2012 at 3:39 PM, Marek Vasut ma...@denx.de wrote: I'm stuck at 20120723 for a bit ... I'll need to resync. Do you suspect uboot issue or kernel bug? Looks like a U-boot issue, as even the kernel from linux-stable is not booting with 2012.07-rc3 Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] dm: mips: Fix lb60 WDT control
Write the TSCR register via 32bit write instead of 16bit one. The register is 32bit wide and bit 16 is being set, triggering gcc overflow error and making the code broken. Signed-off-by: Marek Vasut ma...@denx.de Cc: Daniel z...@ingenic.cn Cc: Shinya Kuribayashi skuri...@pobox.com Cc: Xiangfu Liu xian...@openmobilefree.net --- arch/mips/cpu/xburst/cpu.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/cpu/xburst/cpu.c b/arch/mips/cpu/xburst/cpu.c index e976341..ddcbfaa 100644 --- a/arch/mips/cpu/xburst/cpu.c +++ b/arch/mips/cpu/xburst/cpu.c @@ -62,7 +62,7 @@ void __attribute__((weak)) _machine_restart(void) writew(100, wdt-tdr); /* wdt_set_data(100) */ writew(0, wdt-tcnt); /* wdt_set_count(0); */ - writew(TCU_TSSR_WDTSC, tcu-tscr); /* tcu_start_wdt_clock */ + writel(TCU_TSSR_WDTSC, tcu-tscr); /* tcu_start_wdt_clock */ writeb(readb(wdt-tcer) | WDT_TCER_TCEN, wdt-tcer); /* wdt start */ while (1) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] dm: mips: Fix lb60 timer code
The timer code contains more halfword writes which trigger gcc errors.
The registers are again 32bit, yet written by 16bit writes, fix this:
timer.c: In function ‘reset_timer_masked’:
timer.c:37:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
timer.c: In function ‘get_timer_masked’:
timer.c:43:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
timer.c: In function ‘timer_init’:
timer.c:86:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
timer.c:88:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
timer.c:89:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
timer.c:90:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Daniel z...@ingenic.cn
Cc: Shinya Kuribayashi skuri...@pobox.com
Cc: Xiangfu Liu xian...@openmobilefree.net
---
arch/mips/cpu/xburst/timer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/mips/cpu/xburst/timer.c b/arch/mips/cpu/xburst/timer.c
index de6f5da..b6b3855 100644
--- a/arch/mips/cpu/xburst/timer.c
+++ b/arch/mips/cpu/xburst/timer.c
@@ -34,13 +34,13 @@ static struct jz4740_tcu *tcu = (struct jz4740_tcu
*)JZ4740_TCU_BASE;
void reset_timer_masked(void)
{
/* reset time */
- gd-lastinc = readw(tcu-tcnt0);
+ gd-lastinc = readl(tcu-tcnt0);
gd-tbl = 0;
}
ulong get_timer_masked(void)
{
- ulong now = readw(tcu-tcnt0);
+ ulong now = readl(tcu-tcnt0);
if (gd-lastinc = now)
gd-tbl += now - gd-lastinc; /* normal mode */
@@ -83,11 +83,11 @@ void udelay_masked(unsigned long usec)
int timer_init(void)
{
- writew(TCU_TCSR_PRESCALE256 | TCU_TCSR_EXT_EN, tcu-tcsr0);
+ writel(TCU_TCSR_PRESCALE256 | TCU_TCSR_EXT_EN, tcu-tcsr0);
- writew(0, tcu-tcnt0);
- writew(0, tcu-tdhr0);
- writew(TIMER_FDATA, tcu-tdfr0);
+ writel(0, tcu-tcnt0);
+ writel(0, tcu-tdhr0);
+ writel(TIMER_FDATA, tcu-tdfr0);
/* mask irqs */
writel((1 TIMER_CHAN) | (1 (TIMER_CHAN + 16)), tcu-tmsr);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] dm: mips: Fix warnings in lb60 board
The lb60 board accesses the clkgr register, which is 32bit via
16bit IO ops. This causes malfunction. Fix this.
qi_lb60.c: In function ‘cpm_init’:
qi_lb60.c:72:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
qi_lb60.c:84:2: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Daniel z...@ingenic.cn
Cc: Shinya Kuribayashi skuri...@pobox.com
Cc: Xiangfu Liu xian...@openmobilefree.net
---
board/qi/qi_lb60/qi_lb60.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/qi/qi_lb60/qi_lb60.c b/board/qi/qi_lb60/qi_lb60.c
index 3583d01..d975209 100644
--- a/board/qi/qi_lb60/qi_lb60.c
+++ b/board/qi/qi_lb60/qi_lb60.c
@@ -69,7 +69,7 @@ static void gpio_init(void)
static void cpm_init(void)
{
struct jz4740_cpm *cpm = (struct jz4740_cpm *)JZ4740_CPM_BASE;
- uint32_t reg = readw(cpm-clkgr);
+ uint32_t reg = readl(cpm-clkgr);
reg |= CPM_CLKGR_IPU |
CPM_CLKGR_CIM |
@@ -81,7 +81,7 @@ static void cpm_init(void)
CPM_CLKGR_UDC |
CPM_CLKGR_AIC1;
- writew(reg, cpm-clkgr);
+ writel(reg, cpm-clkgr);
}
int board_early_init_f(void)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: mips: Import libgcc components from Linux
On Friday 27 July 2012 14:35:25 Marek Vasut wrote: --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -34,6 +34,8 @@ else COBJS-y += bootm.o endif +COBJS-y += ashldi3.o ashrdi3.o lshrdi3.o pretty sure this belongs behind USE_PRIVATE_LIBGCC -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] dm: mips: Import libgcc components from Linux
Dear Mike Frysinger, On Friday 27 July 2012 14:35:25 Marek Vasut wrote: --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -34,6 +34,8 @@ else COBJS-y+= bootm.o endif +COBJS-y+= ashldi3.o ashrdi3.o lshrdi3.o pretty sure this belongs behind USE_PRIVATE_LIBGCC Good point ... Mike, I was always wondering what this USE_PRIVATE_LIBGCC is, can you elaborate please (pour some of your knowledge on me ;-) ) ? -mike Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
