Re: [U-Boot] [PATCH] MIPS: Add VCT board series support (Part 1/3)
On Monday 15 December 2008, Andrew Dyer wrote:
On Mon, Dec 15, 2008 at 8:51 AM, Stefan Roese s...@denx.de wrote:
This patch adds support for the Micronas VCT board series.
Currently the following platforms are supported:
vct_premium
snip
+/*
+OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-bigmips)
+*/
+OUTPUT_FORMAT(elf32-tradbigmips, elf32-tradbigmips,
elf32-tradbigmips)
I believe that this should be:
OUTPUT_FORMAT(elf32-tradbigmips, elf32-tradbigmips,
elf32-tradlittlemips)
as the parameters are for default, big, little endian compilation.
I copied this from another MIPS platform (purple). So other existing ports
will have the same problem.
I'll fix this in the next patch version.
+OUTPUT_ARCH(mips)
+ENTRY(_start)
+SECTIONS
+{
+ . = 0x;
+
+ . = ALIGN(4);
+ .text :
+ {
+ *(.text)
+ }
+
+ . = ALIGN(4);
+ .rodata : { *(.rodata) }
+
+ . = ALIGN(4);
+ .data : { *(.data) }
+
+ . = .;
+ _gp = ALIGN(16) + 0x7ff0;
+
+ .got : {
+ __got_start = .;
+ *(.got)
+ __got_end = .;
+ }
+
I would force alignment here for sdata
ok.
+ .sdata : { *(.sdata) }
+
and here
ok.
+ .u_boot_cmd : {
+ __u_boot_cmd_start = .;
+ *(.u_boot_cmd)
+ __u_boot_cmd_end = .;
+ }
+
uboot_end_data is assumed to be word aligned in cpu/mips/start.S,
enforce the alignment here
ok.
+ uboot_end_data = .;
+ num_got_entries = (__got_end - __got_start) 2;
+
+ . = ALIGN(4);
+ .sbss (NOLOAD) : { *(.sbss) }
I believe .bss is also expected to be word aligned
ok.
+ .bss (NOLOAD) : { *(.bss) }
+ uboot_end = .;
+}
I'll fix this in the next patch version.
Thanks.
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC5121 MSCAN Peripheral in U-Boot
Hi sirs, I'm implementing a driver for the MSCAN peripheral of the mpc5121 in Das U-Boot. I'm wondering if there's anyone who has already done some work on it. Thank you Matteo Canella Digitek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] common: Iteration limit for memory test.
The iteration limit is passed to mtest as a fourth parameter:
[start [end [pattern [iterations
If no fourth parameter is supplied, there is no iteration limit and the
test will loop forever.
Signed-off-by: Dirk Eibach eib...@gdsys.de
---
- Beautified commit message
- Whitespace cleanup
- Linelength cleanup
common/cmd_mem.c | 225 +
1 files changed, 123 insertions(+), 102 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index d7666c2..405d45f 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -38,9 +38,9 @@
#include watchdog.h
#ifdef CMD_MEM_DEBUG
-#definePRINTF(fmt,args...) printf (fmt ,##args)
+#definePRINTF(fmt, args...)printf(fmt, ##args)
#else
-#define PRINTF(fmt,args...)
+#define PRINTF(fmt, args...)
#endif
static int mod_mem(cmd_tbl_t *, int, int, int, char *[]);
@@ -60,7 +60,7 @@ staticulong base_address = 0;
* md{.b, .w, .l} {addr} {len}
*/
#define DISP_LINE_LEN 16
-int do_mem_md ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mem_md(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
ulong addr, length;
#if defined(CONFIG_HAS_DATAFLASH)
@@ -77,7 +77,7 @@ int do_mem_md ( cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
length = dp_last_length;
if (argc 2) {
- printf (Usage:\n%s\n, cmdtp-usage);
+ printf(Usage:\n%s\n, cmdtp-usage);
return 1;
}
@@ -155,25 +155,25 @@ int do_mem_md ( cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
dp_last_addr = addr;
dp_last_length = length;
dp_last_size = size;
- return (rc);
+ return rc;
}
-int do_mem_mm ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mem_mm(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
- return mod_mem (cmdtp, 1, flag, argc, argv);
+ return mod_mem(cmdtp, 1, flag, argc, argv);
}
-int do_mem_nm ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mem_nm(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
- return mod_mem (cmdtp, 0, flag, argc, argv);
+ return mod_mem(cmdtp, 0, flag, argc, argv);
}
-int do_mem_mw ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mem_mw(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
ulong addr, writeval, count;
int size;
if ((argc 3) || (argc 4)) {
- printf (Usage:\n%s\n, cmdtp-usage);
+ printf(Usage:\n%s\n, cmdtp-usage);
return 1;
}
@@ -211,24 +211,24 @@ int do_mem_mw ( cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
}
#ifdef CONFIG_MX_CYCLIC
-int do_mem_mdc ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mem_mdc(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
int i;
ulong count;
if (argc 4) {
- printf (Usage:\n%s\n, cmdtp-usage);
+ printf(Usage:\n%s\n, cmdtp-usage);
return 1;
}
count = simple_strtoul(argv[3], NULL, 10);
for (;;) {
- do_mem_md (NULL, 0, 3, argv);
+ do_mem_md(NULL, 0, 3, argv);
/* delay for count ms... */
for (i=0; icount; i++)
- udelay (1000);
+ udelay(1000);
/* check for ctrl-c to abort... */
if (ctrlc()) {
@@ -240,24 +240,24 @@ int do_mem_mdc ( cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
return 0;
}
-int do_mem_mwc ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mem_mwc(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
int i;
ulong count;
if (argc 4) {
- printf (Usage:\n%s\n, cmdtp-usage);
+ printf(Usage:\n%s\n, cmdtp-usage);
return 1;
}
count = simple_strtoul(argv[3], NULL, 10);
for (;;) {
- do_mem_mw (NULL, 0, 3, argv);
+ do_mem_mw(NULL, 0, 3, argv);
/* delay for count ms... */
for (i=0; icount; i++)
- udelay (1000);
+ udelay(1000);
/* check for ctrl-c to abort... */
if (ctrlc()) {
@@ -270,14 +270,14 @@ int do_mem_mwc ( cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
}
#endif /* CONFIG_MX_CYCLIC */
-int do_mem_cmp (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_mem_cmp(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
ulong addr1, addr2, count, ngood;
int size;
int rcode = 0;
if (argc != 4) {
- printf (Usage:\n%s\n, cmdtp-usage);
+ printf(Usage:\n%s\n, cmdtp-usage);
return 1;
}
@@ -296,14 +296,15 @@ int do_mem_cmp (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
#ifdef
[U-Boot] [PATCH 1/6] usb : musb : Add high speed field in usb_device structure
This patch adds support for identification of high speed devices.
For high spped devices that are connected via hubs, the information
that the device is high speed is recorded. This is required by Mentor
USB Host controller driver.
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Thomas Abraham t-abra...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
common/usb.c |1 +
include/usb.h |1 +
include/usb_defs.h |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/common/usb.c b/common/usb.c
index ee18152..f8379c9 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1137,6 +1137,7 @@ void usb_hub_port_connect_change(struct usb_device *dev,
int port)
/* Allocate a new device struct for it */
usb = usb_alloc_new_device();
usb-slow = (portstatus USB_PORT_STAT_LOW_SPEED) ? 1 : 0;
+ usb-high = (portstatus USB_PORT_STAT_HIGH_SPEED) ? 1 : 0;
dev-children[port] = usb;
usb-parent = dev;
diff --git a/include/usb.h b/include/usb.h
index 510df95..e6aa551 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -139,6 +139,7 @@ enum {
struct usb_device {
int devnum; /* Device number on USB bus */
int slow; /* Slow device? */
+ int high; /* High speed device? */
charmf[32]; /* manufacturer */
charprod[32]; /* product */
charserial[32]; /* serial number */
diff --git a/include/usb_defs.h b/include/usb_defs.h
index 353019f..500a0ad 100644
--- a/include/usb_defs.h
+++ b/include/usb_defs.h
@@ -216,6 +216,7 @@
#define USB_PORT_STAT_RESET 0x0010
#define USB_PORT_STAT_POWER 0x0100
#define USB_PORT_STAT_LOW_SPEED 0x0200
+#define USB_PORT_STAT_HIGH_SPEED0x0400
/* wPortChange bits */
#define USB_PORT_STAT_C_CONNECTION 0x0001
--
1.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] usb : musb : Enabling DM6446 (TI DaVinci) USB module power.
Enabling DM6446 (TI DaVinci) USB module power and MUSB low-level
controller hook up to USB core layer.
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Thomas Abraham t-abra...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
board/davinci/dvevm/dvevm.c |1 +
include/usb.h |3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/board/davinci/dvevm/dvevm.c b/board/davinci/dvevm/dvevm.c
index a756098..64641fc 100644
--- a/board/davinci/dvevm/dvevm.c
+++ b/board/davinci/dvevm/dvevm.c
@@ -52,6 +52,7 @@ int board_init(void)
lpsc_on(DAVINCI_LPSC_UART0);
lpsc_on(DAVINCI_LPSC_TIMER1);
lpsc_on(DAVINCI_LPSC_GPIO);
+ lpsc_on(DAVINCI_LPSC_USB);
#if !defined(CONFIG_SYS_USE_DSPLINK)
/* Powerup the DSP */
diff --git a/include/usb.h b/include/usb.h
index e6aa551..495f28e 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -182,7 +182,8 @@ struct usb_device {
#if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
defined(CONFIG_USB_OHCI_NEW) || defined(CONFIG_USB_SL811HS) || \
- defined(CONFIG_USB_ISP116X_HCD) || defined(CONFIG_USB_R8A66597_HCD)
+ defined(CONFIG_USB_ISP116X_HCD) || defined(CONFIG_USB_R8A66597_HCD) || \
+ defined(CONFIG_USB_DAVINCI)
int usb_lowlevel_init(void);
int usb_lowlevel_stop(void);
--
1.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot-Users] TFTP server support in U-boot
Ben Warren wrote: Hello Santosh, santosh pattar wrote: Dear All, As of now in the U-boot only TFTP client is supported. I am planning to have TFTP server support in the u-boot. Can you please help me in this regarding? Please provide me few links if this has been done already, or links from where i can take some information and start working on it. I believe this has come up before, so search the mail archives. I don't remember anybody posting a patch, though. In general, U-boot doesn't 'serve', so you have quite a bit of work to do. Luckily, TFTP is one of the more trivial protocols, hence the name. Do search the archives because my memory isn't what it used to be, but I don't recall a TFTP server coming up. Periodically FTP support comes up and then silently disappears when the requester figures out how much work it would be. Despite sharing 3/4 of the characters and supporting the same concept, TFTP and FTP are totally different animals. I'm curious why you want to do this. People generally use U-boot as transient software for loading operating systems that are much more suitable for serving images. Do you have a situation where you have several identical devices and want to reduce the upstream network load? In that case, you may want to look into the multicast TFTP instead. regards, Ben If you really need this, I would suggest adding a simple (modal) tftp server command so that, when you execute the command all u-boot is doing is TFTP server work until something indicates done (e.g. a file was successfully transfered) and then the command exits. This would fit well into the u-boot restricted architecture that is characterized by being single threaded with no tasking. Trying to do a full fledged tftp server that runs independently in the background is going to be a lot harder because there is no background in u-boot. Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] include/autoconf.mk:212: *** missing separator. Stop.
On Dec 16, 2008, at 6:35 AM, Wolfgang Denk wrote: Hi all... When running MAKEALL, I see occasional /home/wd/git/u-boot/work/include/autoconf.mk:212: *** missing separator. Stop. errors for some boards. The line numbers are changing (57, 85, 113, 129, 183, 212, 215 etc.), and so are the affected boards (barco, kilauea, MPC8544DS, neo, PM856, sequoia). But the build continues to run and completes successfully without additional warnigns or errors. Repeating the build will show the problem with other line numbers and other boards. The problem is obviously related to running parallel build (this happens on a 4 core system); if I use a single make job it goes away. It looks as if some build step was using autoconf.mk before the task building it has completed. I've searched, but did not find any place where this could happen. Is anybody else experiencing this problem? Now that you mention this, I've occasionally seen this as well on various ppc boards, and I always run a parallel build (4-way). In my case, repeating the build usually results in no errors. But I haven't looked into it at all, so I'm afraid I'm not too helpful here except to say that it's not just you. Cheers, B ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
k...@koi8.net wrote:
That looks similar. But why do you want to remove i2c_set_bus_num()? I think
it would be less work to keep it.
Perhaps, but it would be even better to get rid of it. IMHO, it's a kludge. It
was a hack added to allow existing I2C routines to function while adding minimal
support for multiple buses on those platforms that needed it.
This way you can leave 90% or so of
existing I2C code unchanged by setting bus number to 0 at init.
I only intend on exporting the multiple-bus versions of the I2C function if
CONFIG_I2C_MULTI_BUS is defined.
My idea is to have global bus number variable in a single place and a single
i2c_set_bus_num() that can be excluded for most boards with a single bus
with #ifdef...
We already have something like that. A global variable is inconvenient because
every time you want to access the bus, you need to do something like this:
bus = i2c_get_bus_num();
i2c_set_bus_num(x);
i2c_write(...)
i2c_set_bus_num(bus);
We need to save/restore the current bus number, because the I2C command-line has
the concept of a
Then, we could use some kind of array of I2C structures each containing
pointers to appropriate i2c-{read,write,probe,init}() functions with generic
i2c functions just calling those pointers using bus number as index into
that array.
Sounds complicated.
That would allow for unlimited number of different adapters for any board.
Ah, now this is something else entirely. I don't think U-boot supports this at
all. I think you're being too ambitious. It's a noble idea, and I think U-boot
should support it, but I think we need to simplify the support for multiple
buses first.
Initial code for initializing such an array would have to go into each and
every $(BOARD).c board specific file.
Ugh.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] Introduce addr_map library
Dear Becky, In message 6389dd2f-9a4e-4caa-a1fe-804939140...@kernel.crashing.org you wrote: ... Configuring for katmai board... In file included from 44x_spd_ddr2.c:46: /home/wd/git/u-boot/work/include/asm/io.h: In function 'virt_to_phys': /home/wd/git/u-boot/work/include/asm/io.h:303: warning: cast from pointer to integer of different size There was a patch in my series that fixed this: [PATCH 01/11] powerpc: fix io.h build warning with CONFIG_PHYS_64BIT That really needs to become part of Kumar's series since katmai has 64bit enabled. Thanks for the pointer. I'll pick up that patch now directly. Hm... Applying: powerpc: fix io.h build warning with CONFIG_PHYS_64BIT error: patch failed: include/asm-ppc/io.h:311 error: include/asm-ppc/io.h: patch does not apply fatal: sha1 information is lacking or useless (include/asm-ppc/io.h). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001. Hm... manually applied. 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 Violence in reality is quite different from theory. -- Spock, The Cloud Minders, stardate 5818.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] powerpc: fix io.h build warning with CONFIG_PHYS_64BIT
Dear Becky Bruce, In message 1228367087-27268-2-git-send-email-bec...@kernel.crashing.org you wrote: Casting a pointer to a phys_addr_t when it's an unsigned long long on a 32-bit system without first casting to a non-pointer type generates a compiler warning. Fix this. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- include/asm-ppc/io.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Digital computers are themselves more complex than most things people build: They have very large numbers of states. This makes conceiving, describing, and testing them hard. Software systems have orders-of- magnitude more states than computers do. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC5121 MSCAN Peripheral in U-Boot
Dear Matteo, In message 000901c95f58$36a73ba0$a3f5b2...@canella@selcomgroup.com you wrote: I'm implementing a driver for the MSCAN peripheral of the mpc5121 in Das U-Boot. I'm wondering if there's anyone who has already done some work on it. What would be the purpose of such a driver? In the boot loader? Wouldn't it make much more sense to focus on accelerating the Linux boot time and use the existing socketcan driver there? 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 know engineers. They love to change things. - Dr. McCoy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] jffs2: include linux/mtd/compat.h instead of defining own min_t
Dear Ilya Yanok, In message 1228963917-11820-1-git-send-email-ya...@emcraft.com you wrote: Include linux/mtd/compat.h header for min_t definition instead of providing our own one. Removes warnings in case of OneNAND support enabled. Although I thinks it's a bit silly to include linux/mtd/compat.h just for min_t... Signed-off-by: Ilya Yanok ya...@emcraft.com --- fs/jffs2/jffs2_1pass.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Who is the oldest inhabitant of this village? We haven't got one; we had one, but he died three weeks ago. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] CFI: increase performance
Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Thanks, Jens --- Jens Gehrlein (2): CFI: increase performance of function find_sector() CFI: avoid redundant function call in single word programming mode drivers/mtd/cfi_flash.c | 33 +++-- 1 files changed, 23 insertions(+), 10 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] CFI: avoid redundant function call in single word programming mode
The function find_sector() doesn't need to be called twice in
the case of AMD command set.
Tested on TQM5200S-BD with Samsung K8P2815UQB.
Signed-off-by: Jens Gehrlein se...@tqs.de
---
drivers/mtd/cfi_flash.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index e8afe99..1bd0e2b 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -795,7 +795,8 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
{
void *dstaddr;
int flag;
- flash_sect_t sect;
+ flash_sect_t sect = 0;
+ char sect_found = 0;
dstaddr = map_physmem(dest, info-portwidth, MAP_NOCACHE);
@@ -840,6 +841,7 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
sect = find_sector(info, dest);
flash_unlock_seq (info, sect);
flash_write_cmd (info, sect, info-addr_unlock1, AMD_CMD_WRITE);
+ sect_found = 1;
break;
}
@@ -864,8 +866,10 @@ static int flash_write_cfiword (flash_info_t * info, ulong
dest,
unmap_physmem(dstaddr, info-portwidth);
- return flash_full_status_check (info, find_sector (info, dest),
- info-write_tout, write);
+ if (!sect_found)
+ sect = find_sector (info, dest);
+
+ return flash_full_status_check (info, sect, info-write_tout, write);
}
#ifdef CONFIG_SYS_FLASH_USE_BUFFER_WRITE
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] CFI: increase performance of function find_sector()
Tested on TQM5200S-BD with Samsung K8P2815UQB
Signed-off-by: Jens Gehrlein se...@tqs.de
---
drivers/mtd/cfi_flash.c | 23 ---
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 1bd0e2b..bc5e151 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -774,17 +774,26 @@ static void flash_add_byte (flash_info_t * info,
cfiword_t * cword, uchar c)
}
}
-/* loop through the sectors from the highest address when the passed
- * address is greater or equal to the sector address we have a match
+/*
+ * Loop through the sector table starting from the previously found sector.
+ * Searches forwards or backwards, dependent on the passed address.
*/
static flash_sect_t find_sector (flash_info_t * info, ulong addr)
{
- flash_sect_t sector;
+ static flash_sect_t saved_sector = 0; /* previously found sector */
+ flash_sect_t sector = saved_sector;
- for (sector = info-sector_count - 1; sector = 0; sector--) {
- if (addr = info-start[sector])
- break;
- }
+ while ((info-start[sector] addr)
+(sector info-sector_count - 1))
+ sector++;
+ while ((info-start[sector] addr) (sector 0))
+ /*
+* also decrements the sector in case of an overshot
+* in the first loop
+*/
+ sector--;
+
+ saved_sector = sector;
return sector;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] CFI: increase performance
On 17:25 Tue 16 Dec , Jens Gehrlein wrote: Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Could you try it against the qemu SVN HEAD Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] CFI: increase performance
Jean-Christophe PLAGNIOL-VILLARD schrieb: On 17:25 Tue 16 Dec , Jens Gehrlein wrote: Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Could you try it against the qemu SVN HEAD ??? Sorry, what is qemu SVN HEAD ??? P.S.: I still can't reply to your e-mail address... Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] common: Iteration limit for memory test.
The iteration limit is passed to mtest as a fourth parameter:
[start [end [pattern [iterations
If no fourth parameter is supplied, there is no iteration limit and the
test will loop forever.
Signed-off-by: Dirk Eibach eib...@gdsys.de
---
- removed whitespace messup
- removed all cleanup that does not belong here
common/cmd_mem.c | 45 +++--
1 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index d7666c2..7038716 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -672,6 +672,8 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
ulong val;
ulong readback;
int rcode = 0;
+ int iterations = 1;
+ int iteration_limit;
#if defined(CONFIG_SYS_ALT_MEMTEST)
vu_long len;
@@ -687,7 +689,6 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
vu_long *dummy = 0; /* yes, this is address 0x0, not NULL */
#endif
int j;
- int iterations = 1;
static const ulong bitpattern[] = {
0x0001, /* single bit */
@@ -704,23 +705,25 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
ulong pattern;
#endif
- if (argc 1) {
+ if (argc 1)
start = (ulong *)simple_strtoul(argv[1], NULL, 16);
- } else {
+ else
start = (ulong *)CONFIG_SYS_MEMTEST_START;
- }
- if (argc 2) {
+ if (argc 2)
end = (ulong *)simple_strtoul(argv[2], NULL, 16);
- } else {
+ else
end = (ulong *)(CONFIG_SYS_MEMTEST_END);
- }
- if (argc 3) {
+ if (argc 3)
pattern = (ulong)simple_strtoul(argv[3], NULL, 16);
- } else {
+ else
pattern = 0;
- }
+
+ if (argc 4)
+ iteration_limit = (ulong)simple_strtoul(argv[4], NULL, 16);
+ else
+ iteration_limit = 0;
#if defined(CONFIG_SYS_ALT_MEMTEST)
printf (Testing %08x ... %08x:\n, (uint)start, (uint)end);
@@ -733,8 +736,15 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
return 1;
}
+
+ if (iteration_limit iterations iteration_limit) {
+ printf(Tested %d iteration(s) without errors.\n,
+ iterations-1);
+ return 0;
+ }
+
printf(Iteration: %6d\r, iterations);
- PRINTF(Iteration: %6d\n, iterations);
+ PRINTF(\n);
iterations++;
/*
@@ -926,6 +936,13 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
return 1;
}
+ if (iteration_limit iterations iteration_limit) {
+ printf(Tested %d iteration(s) without errors.\n,
+ iterations-1);
+ return 0;
+ }
+ ++iterations;
+
printf (\rPattern %08lX Writing...
%12s
\b\b\b\b\b\b\b\b\b\b,
@@ -1277,9 +1294,9 @@ U_BOOT_CMD(
#endif /* CONFIG_LOOPW */
U_BOOT_CMD(
- mtest, 4, 1, do_mem_mtest,
- mtest - simple RAM test\n,
- [start [end [pattern]]]\n
+ mtest, 5, 1, do_mem_mtest,
+ mtest - simple RAM test\n,
+ [start [end [pattern [iterations\n
- simple RAM read/write test\n
);
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] usb : musb : Adding host controller driver for Mentor USB controller
Adding Mentor USB core functionality and Mentor USB Host controller
functionality for Mentor USB OTG controller (musbhdrc).
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Thomas Abraham t-abra...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/Makefile|1 +
drivers/usb/musb_core.c | 158 +++
drivers/usb/musb_core.h | 322 +
drivers/usb/musb_hcd.c | 707 +++
drivers/usb/musb_hcd.h | 49
5 files changed, 1237 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/musb_core.c
create mode 100644 drivers/usb/musb_core.h
create mode 100644 drivers/usb/musb_hcd.c
create mode 100644 drivers/usb/musb_hcd.h
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 856f51a..d93be2b 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_USB_OHCI_NEW) += usb_ohci.o
COBJS-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
COBJS-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o
COBJS-$(CONFIG_USB_SL811HS) += sl811_usb.o
+COBJS-$(CONFIG_MUSB_HCD) += musb_hcd.o musb_core.o
# device
ifdef CONFIG_USB_DEVICE
diff --git a/drivers/usb/musb_core.c b/drivers/usb/musb_core.c
new file mode 100644
index 000..4f3aff3
--- /dev/null
+++ b/drivers/usb/musb_core.c
@@ -0,0 +1,158 @@
+/*
+ * Mentor USB OTG Core functionality common for both host and Device
+ * functionality.
+ *
+ * Copyright (c) 2008 Texas Instruments
+ *
+ * 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
+ *
+ * Author: Thomas Abraham t-abra...@ti.com, Texas Instruments
+ */
+
+#include common.h
+
+#if defined(CONFIG_MUSB_HCD) || defined(CONFIG_MUSB_DEVICE)
+#include musb_core.h
+
+/*
+ * program the mentor core to start (enable interrupts, dma, etc.)
+ */
+void musb_start(void)
+{
+ u8 devctl;
+
+ /* disable all interrupts */
+ musb_writew(MUSB_INTRTXE, 0);
+ musb_writew(MUSB_INTRRXE, 0);
+ musb_writeb(MUSB_INTRUSBE, 0);
+ musb_writeb(MUSB_TESTMODE, 0);
+
+ /* put into basic highspeed mode and start session */
+ musb_writeb(MUSB_POWER, MUSB_POWER_HSENAB);
+#if defined(CONFIG_MUSB_HCD)
+ devctl = musb_readb(MUSB_DEVCTL);
+ musb_writeb(MUSB_DEVCTL, devctl | MUSB_DEVCTL_SESSION);
+#endif
+}
+
+/*
+ * This function configures the endpoint configuration. The musb hcd or musb
+ * device implementation can use this function to configure the Endpoints
+ * and set the FIFO sizes. Note: The summation of FIFO sizes of all endpoints
+ * should not be more than the available FIFO size.
+ *
+ * epinfo - Pointer to EP configuration table
+ * cnt - Number of entries in the EP conf table.
+ */
+void musb_configure_ep(struct musb_epinfo *epinfo, u8 cnt)
+{
+ u16 csr;
+ u16 fifoaddr = 64; /* First 64 bytes of FIFO reserved for EP0 */
+ u32 fifosize;
+ u8 idx;
+
+ while (cnt--) {
+ /* prepare fifosize to write to register */
+ fifosize = epinfo-epsize 3;
+ idx = ffs(fifosize) - 1;
+
+ musb_writeb(MUSB_INDEX, epinfo-epnum);
+ if (epinfo-epdir) {
+ /* Configure fifo size and fifo base address */
+ musb_writeb(MUSB_TXFIFOSZ, idx);
+ musb_writew(MUSB_TXFIFOADD, fifoaddr 3);
+
+#if defined(CONFIG_MUSB_HCD)
+ /* clear the data toggle bit */
+ csr = musb_readw(MUSB_INDEXED_OFFSET(MUSB_TXCSR));
+ musb_writew(MUSB_INDEXED_OFFSET(MUSB_TXCSR),
+ csr | MUSB_TXCSR_CLRDATATOG);
+#endif
+
+ /* Flush fifo if required */
+ if (csr MUSB_TXCSR_TXPKTRDY) {
+ musb_writew(MUSB_INDEXED_OFFSET(MUSB_TXCSR),
+ csr | MUSB_TXCSR_FLUSHFIFO);
+ }
+ } else {
+ /* Configure fifo size and fifo base address */
+ musb_writeb(MUSB_RXFIFOSZ, idx);
+ musb_writew(MUSB_RXFIFOADD, fifoaddr 3);
+
+#if defined(CONFIG_MUSB_HCD)
+ /* clear the data toggle bit */
+
Re: [U-Boot] [PATCH 0/6] usb : musb : Add MUSB contorller driver and enable Davinci MSC support
Thomas, Thomas Abraham wrote: This patch series adds Mentor Graphics USB OTG host controller driver support and MSC support for DM6446 (TI DaVinci) platform. Any plans to support OMAP(3), too? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] CFI: increase performance
On 17:46 Tue 16 Dec , Jens Gehrlein wrote: Jean-Christophe PLAGNIOL-VILLARD schrieb: On 17:25 Tue 16 Dec , Jens Gehrlein wrote: Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Could you try it against the qemu SVN HEAD ??? Sorry, what is qemu SVN HEAD ??? In qemu you have 2 boards emulated with u-boot support qemu_mips and SX1 it'll be nice to test them also please note they are only in the SVN tree of qemu Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC5121 MSCAN Peripheral in U-Boot
Matteo Canella wrote: Hi sirs, I'm implementing a driver for the MSCAN peripheral of the mpc5121 in Das U-Boot. I'm wondering if there's anyone who has already done some work on it. $ find . -name '*.c'| xargs grep -i MSCAN reports two boards implementing a simple CAN command for loopback testing, I guess. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] trab: make trab_fkt standalone code independent of libgcc
Use our own local functions in lib_arm/ instead.
Signed-off-by: Wolfgang Denk w...@denx.de
---
This patch avoids compilation problems with recent toolchains like:
arm-linux-ld: ERROR: Source object
/opt/eldk-4.2-2008-12-07/usr/bin/../lib/gcc/arm-linux-gnueabi/4.2.2/libgcc.a(_udivsi3.o)
has EABI version 4, but target trab_fkt has EABI version 0
arm-linux-ld: failed to merge target specific data of file
/opt/eldk-4.2-2008-12-07/usr/bin/../lib/gcc/arm-linux-gnueabi/4.2.2/libgcc.a(_udivsi3.o)
board/trab/Makefile |3 ++-
board/trab/trab_fkt.c |6 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 6dfcb87..30e5fbb 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -51,7 +51,8 @@ $(obj)trab_fkt.srec: $(OBJS_FKT) $(LIB)
$(LD) -g -Ttext $(LOAD_ADDR) -o $(:.o=) -e trab_fkt $^ $(LIB) \
-L$(obj)../../examples -lstubs \
-L$(obj)../../lib_generic -lgeneric \
- -L$(gcclibdir) -lgcc
+ $(obj)../../lib_arm/div0.o \
+ $(obj)../../lib_arm/_*.o
$(OBJCOPY) -O srec $(:.o=) $@
$(obj)trab_fkt.bin:$(obj)trab_fkt.srec
diff --git a/board/trab/trab_fkt.c b/board/trab/trab_fkt.c
index 93b9490..53cdb5a 100644
--- a/board/trab/trab_fkt.c
+++ b/board/trab/trab_fkt.c
@@ -294,6 +294,12 @@ int trab_fkt (int argc, char *argv[])
return 1;
}
+void hang (void)
+{
+ puts (### ERROR ### Please RESET the board ###\n);
+ for (;;);
+}
+
int do_info (void)
{
printf (Stand-alone application for TRAB board function test\n);
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] usb : musb : Enabling USB MSC support for DM6446 (TI DaVinci) platform
Enabling USB MSC support for DM6446 (TI DaVinci) platform in the configuration file. Signed-off-by: Ravi Babu ravib...@ti.com Signed-off-by: Swaminathan S swami.i...@ti.com Signed-off-by: Thomas Abraham t-abra...@ti.com Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- include/configs/davinci_dvevm.h | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h index 6885b2c..106900f 100644 --- a/include/configs/davinci_dvevm.h +++ b/include/configs/davinci_dvevm.h @@ -172,6 +172,8 @@ #define CONFIG_SYS_LONGHELP #define CONFIG_CRC32_VERIFY #define CONFIG_MX_CYCLIC +#define CONFIG_MUSB_HCD +#define CONFIG_USB_DAVINCI /*===*/ /* Linux Information */ /*===*/ @@ -204,6 +206,18 @@ #else #error Either CONFIG_SYS_USE_NAND or CONFIG_SYS_USE_NOR _MUST_ be defined !!! #endif +/*==*/ +/* USB MSC support (if any) */ +/*==*/ +#ifdef CONFIG_USB_DAVINCI +#define CONFIG_CMD_USB +#ifdef CONFIG_MUSB_HCD +#define CONFIG_USB_STORAGE +#define CONFIG_CMD_STORAGE +#define CONFIG_CMD_FAT +#define CONFIG_DOS_PARTITION +#endif +#endif /*===*/ /* KGDB support (if any) */ /*===*/ -- 1.5.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
On Mon, Dec 15, 2008 at 04:24:26PM -0800, k...@koi8.net wrote:
Then, we could use some kind of array of I2C structures each containing
pointers to appropriate i2c-{read,write,probe,init}() functions with generic
i2c functions just calling those pointers using bus number as index into
that array.
Why not just pass a pointer to the i2c device, rather than an index?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] 85xx: Fix the wrong CSIZE mask bit
On Dec 15, 2008, at 10:09 PM, Dave Liu wrote: The CSIZE is L1CFG0[56-63] in the e500 and e500mc core, so we should mask 0xff, not 0x1ff. Signed-off-by: Dave Liu dave...@freescale.com --- cpu/mpc85xx/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) was code breaking or just fixing it up to match the docs? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Move the LAW definition to fsl_law.h
On Dec 15, 2008, at 10:09 PM, Dave Liu wrote: some code need the LAWAR_EN, make them sharable. what code? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb : musb : Add MUSB contorller driver and enable Davinci MSC support
Dirk, OMAP patches are ready and will be submitted today. Can we submit the OMAP patches in this list itself ? I thought there is a different list acceptance of U-Boot OMAP patches. Regards swami -Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Tuesday, December 16, 2008 6:23 PM To: Abraham, Thomas Cc: u-boot@lists.denx.de; Gupta, Ajay Kumar; Subbrathnam, Swaminathan; B, Ravi Subject: Re: [U-Boot] [PATCH 0/6] usb : musb : Add MUSB contorller driver and enable Davinci MSC support Thomas, Thomas Abraham wrote: This patch series adds Mentor Graphics USB OTG host controller driver support and MSC support for DM6446 (TI DaVinci) platform. Any plans to support OMAP(3), too? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
On Tue, 16 Dec 2008, Timur Tabi wrote:
k...@koi8.net wrote:
That looks similar. But why do you want to remove i2c_set_bus_num()? I
think
it would be less work to keep it.
Perhaps, but it would be even better to get rid of it. IMHO, it's a
kludge. It
was a hack added to allow existing I2C routines to function while adding
minimal
support for multiple buses on those platforms that needed it.
I have nothing against changing parameters list for i2c_read/write(), it's
just more work and less elegant.
This way you can leave 90% or so of
existing I2C code unchanged by setting bus number to 0 at init.
I only intend on exporting the multiple-bus versions of the I2C function
if
CONFIG_I2C_MULTI_BUS is defined.
That looks messy... Why would we use two different versions if we can make
everything uniform?
My idea is to have global bus number variable in a single place and a
single
i2c_set_bus_num() that can be excluded for most boards with a single
bus
with #ifdef...
We already have something like that. A global variable is inconvenient
because
every time you want to access the bus, you need to do something like
this:
bus = i2c_get_bus_num();
i2c_set_bus_num(x);
i2c_write(...)
i2c_set_bus_num(bus);
We need to save/restore the current bus number, because the I2C
command-line has
the concept of a
Eh, you can just set bus number every time you're gonna do i2c read/write...
That i2c_get_bus_num() doesn't make any sence at all. Just set bus number
every time you access i2c device. U-boot is single-task so there is no other
process that can change it from under you and you do not save anything with
checking that bus number. I can't see any practical use for
i2c_get_bus_num() except for showing it with an interactive command. That
is, in turn, is also redundant -- one would not save any keystrokes by
typing something like i2c bus and not typing i2c bus X if that X is what
he wants. Just type the second command every time when in doubt and you
won't have to type the first one :)
Also, for all boards with a single I2C bus we can assume bus=0 so there is
no need for bus-related functions/commands at all...
Then, we could use some kind of array of I2C structures each
containing
pointers to appropriate i2c-{read,write,probe,init}() functions with
generic
i2c functions just calling those pointers using bus number as index
into
that array.
Sounds complicated.
What is complicated? It is something like 3-4 lines of code per I2C bus.
Look how e.g. NAND subsystem is initialized...
And, BTW, this initialization can even go into include/configs/$(BOARD).h.
That would allow for unlimited number of different adapters for any
board.
Ah, now this is something else entirely. I don't think U-boot supports
this at
all. I think you're being too ambitious. It's a noble idea, and I
think U-boot
should support it, but I think we need to simplify the support for
multiple
buses first.
It ain't rocket science :) The reason why I'm doing this is exactly what you
said -- U-boot does NOT support it at all. And I do really need this and I
think I'm not the only one.
Initial code for initializing such an array would have to go into each
and
every $(BOARD).c board specific file.
Ugh.
Ah, that's not biggie. And I volunteer to do this and come up with patches.
---
**
* k...@homeKOI8 Net The impossible we do immediately. *
* Las Vegas NV, USA Miracles require 24-hour notice. *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] usb : musb : Add MUSB contorller driver and enable Davinci MSC support
This patch series adds Mentor Graphics USB OTG host controller driver support and MSC support for DM6446 (TI DaVinci) platform. - [PATCH 1/6] usb : musb : Add high speed field in usb_device structure. - [PATCH 2/6] usb : musb : Adding host controller driver for Mentor USB controller. - [PATCH 3/6] usb : musb : Adding USB VBUS enable functionality for DM6446 DVEVM. - [PATCH 4/6] usb : musb : Adding DM6446 (TI DaVinci) platform specific USB support. - [PATCH 5/6] usb : musb : Enabling DM6446 (TI DaVinci) USB module power. - [PATCH 6/6] usb : musb : Enabling USB MSC support for DM6446 (TI DaVinci) platform. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
On Tue, 16 Dec 2008, Scott Wood wrote:
On Mon, Dec 15, 2008 at 04:24:26PM -0800, k...@koi8.net wrote:
Then, we could use some kind of array of I2C structures each
containing
pointers to appropriate i2c-{read,write,probe,init}() functions with
generic
i2c functions just calling those pointers using bus number as index
into
that array.
Why not just pass a pointer to the i2c device, rather than an index?
Because it is easier to change bus with i2c_set_bus() function and then use
regular i2c_{read,write,probe}() functions. We are NOT passing anything. One
global variable, bus_num or so, that is changed with i2c_set_bus() is used
as an index for any i2c_{read,write,probe}() function. Those functions are
just one line inlines calling appropriate pointers in i2c_func[bus_num]
area. This way one can still use regular e.g. i2c_write() that translates to
i2c_func[bus_num].i2c_write.
---
**
* k...@homeKOI8 Net The impossible we do immediately. *
* Las Vegas NV, USA Miracles require 24-hour notice. *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] usb : musb : Adding DM6446 (TI DaVinci) platform specific USB support
Adding DM6446 (TI DaVinci) platform specific USB functionality for
USB Phy and VBUS initialization.
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Thomas Abraham t-abra...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/Makefile |1 +
drivers/usb/davinci_usb.c | 139 +
drivers/usb/davinci_usb.h | 98 +++
3 files changed, 238 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/davinci_usb.c
create mode 100644 drivers/usb/davinci_usb.h
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index d93be2b..64cc591 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -34,6 +34,7 @@ COBJS-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
COBJS-$(CONFIG_USB_R8A66597_HCD) += r8a66597-hcd.o
COBJS-$(CONFIG_USB_SL811HS) += sl811_usb.o
COBJS-$(CONFIG_MUSB_HCD) += musb_hcd.o musb_core.o
+COBJS-$(CONFIG_USB_DAVINCI) += davinci_usb.o
# device
ifdef CONFIG_USB_DEVICE
diff --git a/drivers/usb/davinci_usb.c b/drivers/usb/davinci_usb.c
new file mode 100644
index 000..9c50606
--- /dev/null
+++ b/drivers/usb/davinci_usb.c
@@ -0,0 +1,139 @@
+/*
+ * TI's Davinci platform specific usb wrapper functions.
+ *
+ * Copyright (c) 2008 Texas Instruments
+ *
+ * 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
+ *
+ * Author: Thomas Abraham t-abra...@ti.com, Texas Instruments
+ */
+
+#include common.h
+
+#ifdef CONFIG_USB_DAVINCI
+#include asm/io.h
+#include davinci_usb.h
+
+/* This function writes to a 32-bit register of platform usb wrapper */
+inline void pusb_writel(u32 offset, u32 value)
+{
+ writel(value, DAVINCI_USB0_BASE + offset);
+}
+
+/* This function reads a 32-bit register of platform usb wrapper */
+inline u32 pusb_readl(u32 offset)
+{
+ return readl(DAVINCI_USB0_BASE + offset);
+}
+
+/* This function writes to a 16-bit register of platform musb core */
+inline void musb_writew(u32 offset, u16 value)
+{
+ writew(value, MENTOR_USB0_BASE + offset);
+}
+
+/* This function writes to a 8-bit register of platform musb core */
+inline void musb_writeb(u32 offset, u8 value)
+{
+ writeb(value, MENTOR_USB0_BASE + offset);
+}
+
+/* This function reads a 16-bit register of platform usb wrapper */
+inline u16 musb_readw(u32 offset)
+{
+ return readw(MENTOR_USB0_BASE + offset);
+}
+
+/* This function reads a 8-bit register of platform usb wrapper */
+inline u8 musb_readb(u32 offset)
+{
+ return readb(MENTOR_USB0_BASE + offset);
+}
+
+/*
+ * Enable the usb phy
+ */
+static u8 phy_on(void)
+{
+ u32 timeout;
+
+ /* Wait until the usb phy is turned on */
+ writel(USBPHY_SESNDEN | USBPHY_VBDTCTEN, USBPHY_CTL_PADDR);
+ timeout = DAVINCI_USB_TIMEOUT;
+ while (timeout--)
+ if (readl(USBPHY_CTL_PADDR) USBPHY_PHYCLKGD)
+ return 1;
+
+ /* usb phy was not turned on */
+ return 0;
+}
+
+/*
+ * Disable the usb phy
+ */
+static void phy_off(void)
+{
+ /* powerdown the on-chip PHY and its oscillator */
+ writel(USBPHY_OSCPDWN | USBPHY_PHYPDWN, USBPHY_CTL_PADDR);
+}
+
+
+/*
+ * This function performs Davinci platform specific initialization for usb0.
+ */
+int musb_platform_init(void)
+{
+ u32 revision;
+
+ /* enable usb vbus */
+ enable_vbus();
+
+ /* start the on-chip usb phy and its pll */
+ if (!phy_on())
+ return -1;
+
+ /* reset the controller */
+ pusb_writel(DAVINCI_USB_CTRL_REG, 1);
+ udelay(5000);
+
+ /* Returns zero if e.g. not clocked */
+ revision = pusb_readl(DAVINCI_USB_VERSION_REG);
+ if (!revision)
+ return -1;
+
+ /* Disable all interrupts */
+ pusb_writel(DAVINCI_USB_INT_MASK_SET_REG, DAVINCI_USB_USBINT_MASK |
+ DAVINCI_USB_RXINT_MASK | DAVINCI_USB_TXINT_MASK);
+ return 0;
+}
+
+
+/*
+ * This function performs Davinci platform specific deinitialization for usb0.
+ */
+void musb_platform_deinit(void)
+{
+ /* Turn of the phy */
+ phy_off();
+
+ /* flush any interrupts */
+ pusb_writel(DAVINCI_USB_INT_MASK_CLR_REG, DAVINCI_USB_USBINT_MASK |
+ DAVINCI_USB_TXINT_MASK |
[U-Boot] header intact
___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] usb : musb : Adding USB VBUS enable functionality for DM644x DVEVM
Adding USB VBUS enable functionality for DM644x DVEVM (TI DaVinci)
platform.
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Swaminathan S swami.i...@ti.com
Signed-off-by: Thomas Abraham t-abra...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
board/davinci/dvevm/dvevm.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/board/davinci/dvevm/dvevm.c b/board/davinci/dvevm/dvevm.c
index abf60b3..a756098 100644
--- a/board/davinci/dvevm/dvevm.c
+++ b/board/davinci/dvevm/dvevm.c
@@ -101,3 +101,26 @@ int misc_init_r(void)
return(0);
}
+
+#ifdef CONFIG_USB_DAVINCI
+
+/* IO Expander I2C address and USB VBUS enable mask */
+#define IOEXP_I2C_ADDR 0x3A
+#define IOEXP_VBUSEN_MASK 1
+
+/*
+ * This function enables USB VBUS by writting to IO expander using I2C.
+ * Note that the I2C is already initialized at this stage. This
+ * function is used by davinci specific USB wrapper code.
+ */
+void enable_vbus(void)
+{
+ uchar data; /* IO Expander data to enable VBUS */
+
+ /* Write to IO expander to enable VBUS */
+ i2c_read(IOEXP_I2C_ADDR, 0, 0, data, 1);
+ data = ~IOEXP_VBUSEN_MASK;
+ i2c_write(IOEXP_I2C_ADDR, 0, 0, data, 1);
+}
+#endif
+
--
1.5.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC5121 MSCAN Peripheral in U-Boot
Hi Wolfgang, I need the CAN driver in the boot loader because I need to handle a CAN request in a very short time... I doubt I can boot Linux and make the CAN driver work in the order of a few hundreds of milliseconds... Matteo Canella -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: martedì 16 dicembre 2008 10.51 To: Matteo Canella Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] MPC5121 MSCAN Peripheral in U-Boot Dear Matteo, In message 000901c95f58$36a73ba0$a3f5b2...@canella@selcomgroup.com you wrote: I'm implementing a driver for the MSCAN peripheral of the mpc5121 in Das U-Boot. I'm wondering if there's anyone who has already done some work on it. What would be the purpose of such a driver? In the boot loader? Wouldn't it make much more sense to focus on accelerating the Linux boot time and use the existing socketcan driver there? 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 know engineers. They love to change things. - Dr. McCoy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] usb : musb : Add MUSB contorller driver and enable Davinci MSC support
Subbrathnam, Swaminathan wrote: Dirk, OMAP patches are ready and will be submitted today. Can we submit the OMAP patches in this list itself ? Yes, u-boot@lists.denx.de is the correct list for U-Boot OMAP(3) MUSB patches. I thought there is a different list acceptance of U-Boot OMAP patches. We did coordination of OMAP3 clean up at some other lists/IRC. But now that the recent OMAP3 patches are at this list for review, this list is the right one for OMAP3 MUSB, too. As OMAP3 patches are not in mainline, yet, I propose to do/test OMAP3 U-Boot MUSB patches against OMAP3 v6 patch series http://lists.denx.de/pipermail/u-boot/2008-December/044787.html available by git from http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/omap3-dev Many thanks for your work! Dirk -Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Tuesday, December 16, 2008 6:23 PM To: Abraham, Thomas Cc: u-boot@lists.denx.de; Gupta, Ajay Kumar; Subbrathnam, Swaminathan; B, Ravi Subject: Re: [U-Boot] [PATCH 0/6] usb : musb : Add MUSB contorller driver and enable Davinci MSC support Thomas, Thomas Abraham wrote: This patch series adds Mentor Graphics USB OTG host controller driver support and MSC support for DM6446 (TI DaVinci) platform. Any plans to support OMAP(3), too? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_ENV_ADDR incorrect in MPC8313ERDB.h
I built the latest u-boot for MPC8313E-RDB, flashed it, and ran into trouble
after saving my environment to flash.
I'm using git://git.denx.de/u-boot-nand-flash.git (I believe the problem is in
other gits as well).
I'm booting from NOR flash ('make MPC8313ERDB_33_config')
The problem is CONFIG_ENV_ADDR in MPC8313ERDB.h, it says:
#define CONFIG_SYS_MONITOR_BASE TEXT_BASE /* start of monitor */
#define CONFIG_SYS_MONITOR_LEN (256 * 1024)/* Reserve 256 kB for
Mon */
#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)
I'm not sure what 'monitor' is, but the above makes CONFIG_ENV_ADDR =
0xfe04.
This is incorrect since the resulting u-boot.bin is (in my case) 265356=0x40c8c
bytes.
So the saveenv overwrites u-boot itself (in my case the av_ variable, causing
(k)malloc to crash every next reboot).
Although it is only a customization, setting the default CONFIG_ENV_ADDR to a
correct
value would save 8313E-RDB u-boot users like me the trouble finding this.
#define CONFIG_ENV_ADDR 0xfe08 works fine for me.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: fix dependency problem with parallel builds
Parallel builds (using make -jN) would occasionally fail with error messages like include/autoconf.mk:212: *** missing separator. Stop. Line numbers and affected boards were changing. Obviously some Makefiles included autoconf.mk while it was still being written to. As a fix, we now write to a temporary file first and then rename it, so that it is really ready to use as soon as it appears. Signed-off-by: Wolfgang Denk w...@denx.de --- Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index d6cd91a..1fd03a0 100644 --- a/Makefile +++ b/Makefile @@ -463,7 +463,8 @@ $(obj)include/autoconf.mk: $(obj)include/config.h set -e ; \ : Extract the config macros ; \ $(CPP) $(CFLAGS) -DDO_DEPS_ONLY -dM include/common.h | \ - sed -n -f tools/scripts/define2mk.sed $@ + sed -n -f tools/scripts/define2mk.sed $...@.tmp \ + mv $...@.tmp $@ sinclude $(obj)include/autoconf.mk.dep -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] include/autoconf.mk:212: *** missing separator. Stop.
Hi all... When running MAKEALL, I see occasional /home/wd/git/u-boot/work/include/autoconf.mk:212: *** missing separator. Stop. errors for some boards. The line numbers are changing (57, 85, 113, 129, 183, 212, 215 etc.), and so are the affected boards (barco, kilauea, MPC8544DS, neo, PM856, sequoia). But the build continues to run and completes successfully without additional warnigns or errors. Repeating the build will show the problem with other line numbers and other boards. The problem is obviously related to running parallel build (this happens on a 4 core system); if I use a single make job it goes away. It looks as if some build step was using autoconf.mk before the task building it has completed. I've searched, but did not find any place where this could happen. Is anybody else experiencing this problem? Any ideas where to look at? 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 Old programmers never die, they just branch to a new address. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
k...@koi8.net wrote: That looks messy... Why would we use two different versions if we can make everything uniform? Because we already have something that makes it uniform, and it's broken. The idea of having a current i2c bus that needs to be set before read/write operations can be performed is the broken part! Eh, you can just set bus number every time you're gonna do i2c read/write... Not with the current i2c command line. We would need another global variable in the i2c command line code to store what IT thinks is the current bus. That i2c_get_bus_num() doesn't make any sence at all. Just set bus number every time you access i2c device. That's risky. Sooner or later, you will want to know what the current bus number is, at least for debugging or status purposes. U-boot is single-task so there is no other process that can change it from under you and you do not save anything with checking that bus number. Sounds to me like you haven't really looked at the U-Boot code. There are plenty of places where one function does I2C operations, then calls another function that does its own. I think all this boils down to one core disagreement we have: I think the idea of a current i2c bus is a bad one. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common: nvedit to protect additional ethernet addresses Part 1/1
Dear Wolfgang Denk Dear =?iso-8859-15?Q?Stefan_Alth=F6fer?=, In message 531234...@web.de you wrote: Then maybe we should have #define CONFIG_ENV_PROTECTED_ITEM ethaddr1,ethaddr2, in board configuration to have the greatest flexibility? Jerry Van Baren already showed you an elegant way to solve this using scanf(). Is scanf() available in u-boot? I couldn't find it. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-usb
The following changes since commit 7f202217356f19e519e6ec57a29de9af73067037: Wolfgang Denk (1): Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master are available in the git repository at: git://git.denx.de/u-boot-usb.git master Jean-Christophe PLAGNIOL-VILLARD (1): usb_kbd: fix usb_kbd_deregister when DEVICE_DEREGISTER not enable common/usb_kbd.c |4 include/devices.h |2 ++ 2 files changed, 6 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
k...@koi8.net wrote:
On Tue, 16 Dec 2008, Timur Tabi wrote:
k...@koi8.net wrote:
That looks messy... Why would we use two different versions if we can
make
everything uniform?
Because we already have something that makes it uniform, and it's
broken. The
idea of having a current i2c bus that needs to be set before
read/write
operations can be performed is the broken part!
Eh, we don't have any uniformity. That uniformity we do have is only for a
trivial case of a single I2C bus. Everything else is a bunch of SoC specific
hacks made differently fo different platforms. The fsl-i2c.c e.g. uses local
bus number variable.
[snip]
I think all this boils down to one core disagreement we have: I think
the idea
of a current i2c bus is a bad one.
I can see nothing wrong with that but I also have nothing against changing
all i2c_{read,write,probe}() functions to take bus number as an argument.
I offered 4 possible scenarios and additional parameter to i2c functions was
one of them. Wolfgang said that current bus approach looks better than
others and I agree with him. But it is not rocket science to use an
additional parameter either. The only thing is it MUST be consistent, i.e.
we should NOT have 2 different sets of functions based on CONFIG_MULTIBUS or
whatever. If we are to make this change ALL boards must be multibus with
majority of them having bus count of 1.
Does anybody else have something to say on this? I'm going to write code so
let's make some decision. I don't want this to end up as a company hack and
making it properly affects a lot of U-boot...
IMHO Sergey's approach is reasonable. It is pragmatic in that it builds
on and improves the existing method. It only touches boards with
multiple i2c buses.
The best is the enemy of the good. - Voltaire
http://www.bartleby.com/66/2/63002.html
My two cents,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] NAND: Mark the BBT as scanned prior to calling scan_bbt.
Otherwise, recursion can occur if scan_bbt does not find a bad block
table, and tries to write one, and the attempt to erase the BBT area
causes a bad block check.
Signed-off-by: Scott Wood scottw...@freescale.com
---
Applied to u-boot-nand-flash.
drivers/mtd/nand/nand_base.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ba05b76..94a65d4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -460,8 +460,8 @@ static int nand_block_checkbad(struct mtd_info *mtd, loff_t
ofs, int getchip,
struct nand_chip *chip = mtd-priv;
if (!(chip-options NAND_BBT_SCANNED)) {
- chip-scan_bbt(mtd);
chip-options |= NAND_BBT_SCANNED;
+ chip-scan_bbt(mtd);
}
if (!chip-bbt)
--
1.5.6.rc1.6.gc53ad
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] trab: make trab_fkt standalone code independent of libgcc
On 16:29 Tue 16 Dec , Wolfgang Denk wrote: Use our own local functions in lib_arm/ instead. I've plan to remove the libgcc depedancy at all for ARM so I'll prefer to do it this way if possible Patch neartly ready I'll send it soon Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
Dear Timur, In message 4947f8b4.8070...@freescale.com you wrote: k...@koi8.net wrote: That looks messy... Why would we use two different versions if we can make everything uniform? Because we already have something that makes it uniform, and it's broken. The idea of having a current i2c bus that needs to be set before read/write operations can be performed is the broken part! Hm... what exactly is broken with the concept of having a current device or a current bus? We use it elasewhere, too (like for selection IDE or S-ATA devices and such), and so far I am not aware of fundamental issues because of that. You sound as if we were designing a system where tens of independend users could log in simultaneously and concurrently access different devices on different busses. But this is NOT the case. We're strictly single user, single threaded, and when one command is runnign we are certain that there cannot be any interference from other I2C accesses. Eh, you can just set bus number every time you're gonna do i2c read/write... Not with the current i2c command line. We would need another global variable in the i2c command line code to store what IT thinks is the current bus. Not really. It is really sufficient to set the bus for each command. There is no need to save and restore any previous state, because accesses cannot be nested because of the way how U-Boot is designed. That i2c_get_bus_num() doesn't make any sence at all. Just set bus number every time you access i2c device. That's risky. Sooner or later, you will want to know what the current bus number is, at least for debugging or status purposes. The design has been discussed before, and I see little reason why we should not throw all this away and come up with something new, more complicated. Sounds to me like you haven't really looked at the U-Boot code. There are plenty of places where one function does I2C operations, then calls another function that does its own. Really? Where exactly does such a thing happen? I tend to call this a bug that needs to be fixed, if there is ssuch code. I think all this boils down to one core disagreement we have: I think the idea of a current i2c bus is a bad one. This statement is probably correct: I don't share your point of view here, either. 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 Be wiser than other people if you can, but do not tell them so. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common: nvedit to protect additional ethernet addresses Part 1/1
Dear Ben, In message 4947ffdb.9040...@gmail.com you wrote: Jerry Van Baren already showed you an elegant way to solve this using scanf(). Is scanf() available in u-boot? I couldn't find it. ... I think he meant sscanf(), which should be there. No, we don't have this yet in U-Boot. But that's a small problem - as long as we just need to parse for an expression like eth\d*addr we can easily do this with ten lines of C or so. If we find we might need sscanf() more often, we might een go as far and borrow some 200+ lines of code for Linux (i.e., from lib/vsprintf.c) :-) 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 Don't think; let the machine do it for you!- E. C. Berkeley ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
Dear k...@koi8.net, In message pine.lnx.4.64ksi.0812161102580.28...@home-gw.koi8.net you wrote: I offered 4 possible scenarios and additional parameter to i2c functions was one of them. Wolfgang said that current bus approach looks better than others and I agree with him. But it is not rocket science to use an You and me agree on this. additional parameter either. The only thing is it MUST be consistent, i.e. we should NOT have 2 different sets of functions based on CONFIG_MULTIBUS or We agree on this, too. whatever. If we are to make this change ALL boards must be multibus with majority of them having bus count of 1. I don't think this makes sense - it would just add complexity and memory footprint without added benefit. Does anybody else have something to say on this? I'm going to write code so let's make some decision. I don't want this to end up as a company hack and making it properly affects a lot of U-boot... I support your position, not Timur's. 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 We fight only when there is no other choice. We prefer the ways of peaceful contact. -- Kirk, Spectre of the Gun, stardate 4385.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] 85xx: Add support to populate addr map based on TLB settings
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
cpu/mpc85xx/tlb.c | 34 ++
include/asm-ppc/mmu.h |3 +++
lib_ppc/board.c |8
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc85xx/tlb.c b/cpu/mpc85xx/tlb.c
index a2d16ae..5b5f791 100644
--- a/cpu/mpc85xx/tlb.c
+++ b/cpu/mpc85xx/tlb.c
@@ -26,6 +26,11 @@
#include common.h
#include asm/processor.h
#include asm/mmu.h
+#ifdef CONFIG_ADDR_MAP
+#include addr_map.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
void set_tlb(u8 tlb, u32 epn, u64 rpn,
u8 perms, u8 wimge,
@@ -47,6 +52,11 @@ void set_tlb(u8 tlb, u32 epn, u64 rpn,
mtspr(MAS7, _mas7);
#endif
asm volatile(isync;msync;tlbwe;isync);
+
+#ifdef CONFIG_ADDR_MAP
+ if ((tlb == 1) (gd-flags GD_FLG_RELOC))
+ addrmap_set_entry(epn, rpn, (1UL ((tsize * 2) + 10)), esel);
+#endif
}
void disable_tlb(u8 esel)
@@ -67,6 +77,11 @@ void disable_tlb(u8 esel)
mtspr(MAS7, _mas7);
#endif
asm volatile(isync;msync;tlbwe;isync);
+
+#ifdef CONFIG_ADDR_MAP
+ if (gd-flags GD_FLG_RELOC)
+ addrmap_set_entry(0, 0, 0, esel);
+#endif
}
void invalidate_tlb(u8 tlb)
@@ -91,6 +106,25 @@ void init_tlbs(void)
return ;
}
+#ifdef CONFIG_ADDR_MAP
+void init_addr_map(void)
+{
+ int i;
+
+ for (i = 0; i num_tlb_entries; i++) {
+ if (tlb_table[i].tlb == 0)
+ continue;
+
+ addrmap_set_entry(tlb_table[i].epn,
+ tlb_table[i].rpn,
+ (1UL ((tlb_table[i].tsize * 2) + 10)),
+ tlb_table[i].esel);
+ }
+
+ return ;
+}
+#endif
+
unsigned int setup_ddr_tlbs(unsigned int memsize_in_meg)
{
unsigned int tlb_size;
diff --git a/include/asm-ppc/mmu.h b/include/asm-ppc/mmu.h
index 8975e6c..6d942d0 100644
--- a/include/asm-ppc/mmu.h
+++ b/include/asm-ppc/mmu.h
@@ -431,6 +431,9 @@ extern void set_tlb(u8 tlb, u32 epn, u64 rpn,
extern void disable_tlb(u8 esel);
extern void invalidate_tlb(u8 tlb);
extern void init_tlbs(void);
+#ifdef CONFIG_ADDR_MAP
+extern void init_addr_map(void);
+#endif
extern unsigned int setup_ddr_tlbs(unsigned int memsize_in_meg);
#define SET_TLB_ENTRY(_tlb, _epn, _rpn, _perms, _wimge, _ts, _esel, _sz,
_iprot) \
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 289a32a..61c29b5 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -75,6 +75,10 @@
#include keyboard.h
#endif
+#ifdef CONFIG_ADDR_MAP
+#include asm/mmu.h
+#endif
+
#ifdef CONFIG_SYS_UPDATE_FLASH_SIZE
extern int update_flash_size (int flash_size);
#endif
@@ -694,6 +698,10 @@ void board_init_r (gd_t *id, ulong dest_addr)
*/
trap_init (dest_addr);
+#if defined(CONFIG_ADDR_MAP) defined(CONFIG_E500)
+ init_addr_map();
+#endif
+
#if defined(CONFIG_BOARD_EARLY_INIT_R)
board_early_init_r ();
#endif
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ppc: Use addrmap in virt_to_phys and map_physmem.
If we have addr map support enabled use the mapping functions to
implement virt_to_phys() and map_physmem().
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
include/asm-ppc/io.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/io.h b/include/asm-ppc/io.h
index 64cb746..4ddad26 100644
--- a/include/asm-ppc/io.h
+++ b/include/asm-ppc/io.h
@@ -10,6 +10,10 @@
#include linux/config.h
#include asm/byteorder.h
+#ifdef CONFIG_ADDR_MAP
+#include addr_map.h
+#endif
+
#define SIO_CONFIG_RA 0x398
#define SIO_CONFIG_RD 0x399
@@ -287,7 +291,11 @@ extern inline void out_be32(volatile unsigned __iomem
*addr, int val)
static inline void *
map_physmem(phys_addr_t paddr, unsigned long len, unsigned long flags)
{
+#ifdef CONFIG_ADDR_MAP
+ return (void *)(addrmap_phys_to_virt(paddr));
+#else
return (void *)((unsigned long)paddr);
+#endif
}
/*
@@ -300,7 +308,11 @@ static inline void unmap_physmem(void *vaddr, unsigned
long flags)
static inline phys_addr_t virt_to_phys(void * vaddr)
{
+#ifdef CONFIG_ADDR_MAP
+ return addrmap_virt_to_phys(vaddr);
+#else
return (phys_addr_t)((unsigned long)vaddr);
+#endif
}
#endif
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] NAND FSL elbc: Use virt_to_phys to determine which bank is in use
The current code that determines which bank/chipselect is used for a
given NAND instance only worked for 32-bit addresses and assumed
a 1:1 mapping. This breaks in 36-bit physical configs.
The proper way to handle this is to use the virt_to_phys() and
BR_PHYS_ADDR() routinues to match the 34-bit lbc bus address
with the the virtual address the NAND code uses.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Acked-by: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/fsl_elbc_nand.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 367c7d7..3f318e0 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -718,7 +718,7 @@ static void fsl_elbc_ctrl_init(void)
int board_nand_init(struct nand_chip *nand)
{
struct fsl_elbc_mtd *priv;
- uint32_t br, or;
+ uint32_t br = 0, or = 0;
if (!elbc_ctrl) {
fsl_elbc_ctrl_init();
@@ -737,11 +737,13 @@ int board_nand_init(struct nand_chip *nand)
* if we could pass more than one datum to the NAND driver...
*/
for (priv-bank = 0; priv-bank MAX_BANKS; priv-bank++) {
+ phys_addr_t base_addr = virt_to_phys(nand-IO_ADDR_R);
+
br = in_be32(elbc_ctrl-regs-bank[priv-bank].br);
or = in_be32(elbc_ctrl-regs-bank[priv-bank].or);
if ((br BR_V) (br BR_MSEL) == BR_MS_FCM
- (br or BR_BA) == (phys_addr_t)nand-IO_ADDR_R)
+ (br or BR_BA) == BR_PHYS_ADDR(base_addr))
break;
}
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] qemu_mips: update doc to generate and to use qemu flash, ide file
On 00:02 Wed 10 Dec , Shinya Kuribayashi wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:27 Mon 08 Sep , Jean-Christophe PLAGNIOL-VILLARD wrote: Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- doc/README.qemu_mips | 67 +++-- 1 files changed, 58 insertions(+), 9 deletions(-) ping Hmm, the patch above can't be applied to the current git. Could you confirm it? this patch apply against the 2 new I've re-send Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] qemu_mips: update doc to use all disk and boot linux kernel
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- doc/README.qemu_mips | 37 - 1 files changed, 36 insertions(+), 1 deletions(-) diff --git a/doc/README.qemu_mips b/doc/README.qemu_mips index 2fdd2b0..8fa4907 100644 --- a/doc/README.qemu_mips +++ b/doc/README.qemu_mips @@ -17,12 +17,47 @@ create image: start it: # qemu-system-mips -M mips -pflash flash -monitor null -nographic +Ide Disk + +# dd of=ide bs=1k cout=100k if=/dev/zero + +# sfdisk -C 261 -d ide +# partition table of ide +unit: sectors + + ide1 : start= 63, size=32067, Id=83 + ide2 : start=32130, size=32130, Id=83 + ide3 : start=64260, size= 4128705, Id=83 + ide4 : start=0, size=0, Id= 0 + +# Generate uImage +# tools/mkimage -A mips -O linux -T kernel -C gzip -a 0x8001 -e 0x80245650 -n Linux 2.6.24.y -d vmlinux.bin.gz uImage +# Copy to Flash +# dd if=uImage bs=1k conv=notrunc seek=224 of=flash +# Copy to ide +# dd if=uImage bs=512 conv=notrunc seek=63 of=ide + +# Generate ext2 on part 2 +# Attached as loop device ide offset = 32130 * 512 +# losetup -o 16450560 -f ide +# Format as ext2 ( arg2 : nb blocks) +# mke2fs /dev/loop0 16065 +# losetup -d /dev/loop0 +# Mount and copy uImage and initrd.gz to it +# mount -o loop,offset=16450560 -t ext2 ide /mnt +# Umount it +# umount /mnt + +Now you can boot from flash, ide, ide+ext2 and tfp + +# qemu-system-mips -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide + II) How to debug U-Boot In order to debug U-Boot you need to start qemu with gdb server support (-s) and waiting the connection to start the CPU (-S) -# qemu-system-mips -S -s -M mips -pflash flash -monitor null -nographic +# qemu-system-mips -S -s -M mips -pflash flash -monitor null -nographic -net nic -net user -tftp `pwd` -hda ide in an other console you start gdb -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] IDE: Improving speed on reading data Part 1/1
IDE: Improving speed on reading data
This patch improves the speed when reading blocks from
IDE devices by reading more than one block at a time. Up to
128 blocks are requested in one read command.
The ide_wait() code was rewritten to have lower latency
by polling more frequently for status.
On my testplatform (Janz emPC-A400 with CompactFLASH card)
this nearly doubled speed.
Also, error handling has been improved, so that ide_read does not
attempt to read beyond the last sector of the device.
Signed-off-by: Stefan Althoefer stefan.althoe...@web.de
---
Can you please use git-format-patch to format the patch? I don't know
how you created the diff, but it looks strange to me (and harldy
readable).
Sorry I wasn't fully aware of the wonderful world of git-* when
I prepared the first patches ... ok I'm still not (fully).
-ide_outb (device, ATA_SECT_CNT, 1);
+scnt = (blkcnt 128) ? 128 : blkcnt;
+ide_outb (device, ATA_SECT_CNT, scnt);
What happens if you try to read at or beyond the end of the device?
Good point. The old code wasn't very smart with this either (it did not
check for bounds but let the device decide). My code added a deadlock
to this behaviour (break did not work in a inner loop).
I added some checks against block_dev_desc_t-lba to fix this.
common/cmd_ide.c | 63 ++---
1 files changed, 40 insertions(+), 23 deletions(-)
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index dd62c87..ec64767 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -1361,6 +1361,8 @@ ulong ide_read (int device, lbaint_t blknr, ulong blkcnt,
void *buffer)
ulong n = 0;
unsigned char c;
unsigned char pwrsave=0; /* power save */
+ ulong scnt;
+ lbaint_t blkrem;
#ifdef CONFIG_LBA48
unsigned char lba48 = 0;
@@ -1372,6 +1374,12 @@ ulong ide_read (int device, lbaint_t blknr, ulong
blkcnt, void *buffer)
debug (ide_read dev %d start %qX, blocks %lX buffer at %lX\n,
device, blknr, blkcnt, (ulong)buffer);
+ if( blknr = ide_get_dev(device)-lba ){
+ printf (IDE read: device %d read beyond last block\n, device);
+ goto IDE_READ_E;
+ }
+ blkrem = ide_get_dev(device)-lba - blknr;
+
ide_led (DEVICE_LED(device), 1);/* LED on */
/* Select device
@@ -1405,7 +1413,7 @@ ulong ide_read (int device, lbaint_t blknr, ulong blkcnt,
void *buffer)
}
- while (blkcnt-- 0) {
+ while (blkcnt 0) {
c = ide_wait (device, IDE_TIME_OUT);
@@ -1427,7 +1435,9 @@ ulong ide_read (int device, lbaint_t blknr, ulong blkcnt,
void *buffer)
#endif
}
#endif
- ide_outb (device, ATA_SECT_CNT, 1);
+ scnt = (blkcnt 128) ? 128 : blkcnt;
+ scnt = (scnt blkrem) ? blkrem : scnt;
+ ide_outb (device, ATA_SECT_CNT, scnt);
ide_outb (device, ATA_LBA_LOW, (blknr 0) 0xFF);
ide_outb (device, ATA_LBA_MID, (blknr 8) 0xFF);
ide_outb (device, ATA_LBA_HIGH, (blknr 16) 0xFF);
@@ -1446,32 +1456,39 @@ ulong ide_read (int device, lbaint_t blknr, ulong
blkcnt, void *buffer)
ide_outb (device, ATA_COMMAND, ATA_CMD_READ);
}
- udelay (50);
+ while (scnt 0) {
+ udelay (50);
- if(pwrsave) {
- c = ide_wait (device, IDE_SPIN_UP_TIME_OUT);/* may
take up to 4 sec */
- pwrsave=0;
- } else {
- c = ide_wait (device, IDE_TIME_OUT);/* can't take
over 500 ms */
- }
+ if(pwrsave) {
+ c = ide_wait (device, IDE_SPIN_UP_TIME_OUT);
/* may take up to 4 sec */
+ pwrsave=0;
+ } else {
+ c = ide_wait (device, IDE_TIME_OUT);/*
can't take over 500 ms */
+ }
- if ((c(ATA_STAT_DRQ|ATA_STAT_BUSY|ATA_STAT_ERR)) !=
ATA_STAT_DRQ) {
+ if ((c(ATA_STAT_DRQ|ATA_STAT_BUSY|ATA_STAT_ERR)) !=
ATA_STAT_DRQ) {
#if defined(CONFIG_SYS_64BIT_LBA) defined(CONFIG_SYS_64BIT_VSPRINTF)
- printf (Error (no IRQ) dev %d blk %qd: status
0x%02x\n,
- device, blknr, c);
+ printf (Error (no IRQ) dev %d blk %qd: status
0x%02x\n,
+ device, blknr, c);
#else
- printf (Error (no IRQ) dev %d blk %ld: status
0x%02x\n,
- device, (ulong)blknr, c);
+ printf (Error (no IRQ) dev %d blk %ld: status
0x%02x\n,
+ device, (ulong)blknr, c);
#endif
- break;
-
[U-Boot] [PATCH] board/trab/memory.c: Fix compile problems.
Apply changes from commit 44b4dbed to board/trab/memory.c, too.
Actually we'd need a major cleanup here - as it turns out,
board/trab/memory.c is more or less a verbatim copy of
post/drivers/memory.c ... but then, trab is EOL anyway,r
so this is not worth the effort.
Signed-off-by: Wolfgang Denk w...@denx.de
---
board/trab/memory.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/trab/memory.c b/board/trab/memory.c
index 8fb3d2c..895b68e 100644
--- a/board/trab/memory.c
+++ b/board/trab/memory.c
@@ -184,7 +184,7 @@
*
* For other processors, let the compiler generate the best code it can.
*/
-static void move64(unsigned long long *src, unsigned long long *dest)
+static void move64(const unsigned long long *src, unsigned long long *dest)
{
#if defined(CONFIG_MPC8260) || defined(CONFIG_MPC824X)
asm (lfd 0, 0(3)\n\t /* fpr0 = *scr */
@@ -231,12 +231,12 @@ static int memory_post_dataline(unsigned long long * pmem)
int ret = 0;
for ( i = 0; i num_patterns; i++) {
- move64((unsigned long long *)(pattern[i]), pmem++);
+ move64((pattern[i]), pmem++);
/*
* Put a different pattern on the data lines: otherwise they
* may float long enough to read back what we wrote.
*/
- move64((unsigned long long *)otherpattern, pmem--);
+ move64(otherpattern, pmem--);
move64(pmem, temp64);
#ifdef INJECT_DATA_ERRORS
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
Hi, Is it possible to load a initramfs compress CPIO image via u-boot like we can do with a ramdisk image (replace the uRamdisk by a uInitramfs in the command bellow)? nand_all=chpart Kernel;fsload 0x20 uImage;chpart Config;fsload 0x40 uRamdisk;run ramargs addip addtty;bootm 20 40 If it is possible, I guest we need to generate a different image type via the mkimage utility? Thanks Sylvain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] IXP425: Fixing timer code Part 1/1
Wolfgang Denk schrieb: Dear Stefan Althoefer, In message 49384728.lmggwd1otzmugoap%stefan.althoe...@web.de you wrote: With this patch, this is nonsense. Instead you should use: #ifdef CONFIG_USE_IRQ /* Interrupt driven timer wants system tick here */ #define CONFIG_SYS_HZ 1000 #else /* The code in cpu/ixp/timer.c needs timer clock tick in HZ */ #define CONFIG_SYS_HZ #endif No, this is wrong. CONFIG_SYS_HZ should always be 1000, without exceptions. Best regards, Wolfgang Denk Should I then hide the in the code, or define something like #define CONFIG_SYS_CLK_FREQ ? In /cpu/ixp/interrupts.c #define FREQ is used privately, but I don't like this. However, this frequency is the same for all IXP clock speeds so it does not really need to be in the config file. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] IXP425: Improving print_cpuinfo code Part 1/1
On 22:09 Thu 04 Dec , Stefan Althoefer wrote:
[PATCH] IXP425: Improving print_cpuinfo code
The existing version of print_cpuinfo did read the
processor ID and detects clock speed from this.
This is not correct, as the IXP425 has the ability
to downgrade clock speed by using strapping resistors.
The improved code reads strapping information from
register and corrects the actual clock speed. Both
information are displayed.
The patch is against latest u-boot git-repository
Please (still) be patient if style of submission or patches are
offending.
Signed-off-by: Stefan Althoefer stefan.althoe...@web.de
diff -uprN u-boot-orig//cpu/ixp/cpu.c u-boot/cpu/ixp/cpu.c
--- u-boot-orig//cpu/ixp/cpu.c2008-12-02 17:25:31.0 +0100
+++ u-boot/cpu/ixp/cpu.c 2008-12-03 11:35:37.0 +0100
@@ -45,32 +45,68 @@ DECLARE_GLOBAL_DATA_PTR;
int print_cpuinfo (void)
{
unsigned long id;
+ unsigned long cfg_clk;
int speed = 0;
+ int model = 0;
asm (mrc p15, 0, %0, c0, c0, 0:=r (id));
+ cfg_clk = *IXP425_EXP_CFG0 21;
please use readx/writex
- puts(CPU: Intel IXP425 at );
+ puts(CPU: Intel IXP42X);
switch ((id 0x03f0) 4) {
case 0x1c:
- loops_per_jiffy = 887467;
- speed = 533;
+ model = 533;
+ switch (cfg_clk) {
+ case 0x1:
+ speed = 400;
+ break;
+ case 0x3:
+ speed = 266;
+ break;
+ default:
+ speed = 533;
+ break;
+ }
break;
case 0x1d:
- loops_per_jiffy = 666016;
- speed = 400;
+ model = 400;
+ switch (cfg_clk) {
+ case 0x3:
+ speed = 266;
+ break;
+ default:
+ speed = 400;
+ break;
+ }
break;
case 0x1f:
- loops_per_jiffy = 442901;
+ model = 266;
speed = 266;
break;
}
+ /* FIXME: is there any need for the jiffies? */
for the IRQ delay
+ switch (speed) {
+ case 266:
+ loops_per_jiffy = 442901;
+ break;
+ case 400:
+ loops_per_jiffy = 666016;
+ break;
+ case 533:
+ loops_per_jiffy = 887467;
+ break;
+ }
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Part 1/0
On 22:09 Thu 04 Dec , Stefan Althoefer wrote: please use git and send your patch as thread to avoid patch forgetting Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] include/configs/at91cap9adk.h: fix typo.
Signed-off-by: Wolfgang Denk w...@denx.de --- include/configs/at91cap9adk.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h index 363df67..b2baf1b 100644 --- a/include/configs/at91cap9adk.h +++ b/include/configs/at91cap9adk.h @@ -32,7 +32,7 @@ #define AT91_MAIN_CLOCK1200/* 12 MHz crystal */ #define AT91_MASTER_CLOCK 1 /* peripheral */ #define AT91_CPU_CLOCK 2 /* cpu */ -#define CONFUG_SYS_AT91_PLLB 0x10073e01 /* PLLB settings for USB */ +#define CONFIG_SYS_AT91_PLLB 0x10073e01 /* PLLB settings for USB */ #define CONFIG_SYS_HZ 100 /* 1us resolution */ #define AT91_SLOW_CLOCK32768 /* slow clock */ -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] IXP425: Improving print_cpuinfo code Part 1/1
Jean-Christophe PLAGNIOL-VILLARD schrieb: +cfg_clk = *IXP425_EXP_CFG0 21; please use readx/writex The pointer dereference style is used throughout the other files in the IXP port as well. Shouldn't this be handled the same way in all files? +/* FIXME: is there any need for the jiffies? */ for the IRQ delay Ok, I overlooked it is used in start.S. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] powerpc: fix io.h build warning with CONFIG_PHYS_64BIT
In message 20081216155539.6345f832e...@gemini.denx.de I wrote: In message 1228367087-27268-2-git-send-email-bec...@kernel.crashing.org you wrote: Casting a pointer to a phys_addr_t when it's an unsigned long long on a 32-bit system without first casting to a non-pointer type generates a compiler warning. Fix this. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- include/asm-ppc/io.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Unfortunately this leaves problems on some MIPS based systems: ... au1x00_eth.c: In function 'au1x00_send': au1x00_eth.c:158: warning: passing argument 1 of 'virt_to_phys' discards qualifiers from pointer target type au1x00_eth.c: In function 'au1x00_recv': au1x00_eth.c:211: warning: passing argument 1 of 'virt_to_phys' discards qualifiers from pointer target type au1x00_eth.c: In function 'au1x00_init': au1x00_eth.c:252: warning: passing argument 1 of 'virt_to_phys' discards qualifiers from pointer target type (for dbau1000, dbau1100, dbau1500, dbau1550, dbau1550_el and gth2) 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 Celestial navigation is based on the premise that the Earth is the center of the universe. The premise is wrong, but the navigation works. An incorrect model can be a useful tool. - Kelvin Throop III ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] cmd_i2c: rename EDO, DDR and SDRAM to avoid conflict with at91 memory setup
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Timo Tuunainen timo.tuunai...@sysart.fi
---
common/cmd_i2c.c | 58 +++---
1 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 448f2fe..a662b53 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -712,7 +712,7 @@ static void decode_bits (u_char const b, char const *str[],
int const do_once)
*/
int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
- enum { unknown, EDO, SDRAM, DDR2 } type;
+ enum { unknown, _EDO, _SDRAM, _DDR2 } type;
u_char chip;
u_char data[128];
@@ -793,15 +793,15 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
puts (Memory type );
switch (data[2]) {
case 2:
- type = EDO;
+ type = _EDO;
puts (EDO\n);
break;
case 4:
- type = SDRAM;
+ type = _SDRAM;
puts (SDRAM\n);
break;
case 8:
- type = DDR2;
+ type = _DDR2;
puts (DDR2\n);
break;
default:
@@ -823,7 +823,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
printf (%d/%d\n, data[4] 0x0F, (data[4] 4) 0x0F);
switch (type) {
- case DDR2:
+ case _DDR2:
printf (Number of ranks %d\n,
(data[5] 0x07) + 1);
break;
@@ -833,7 +833,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
switch (type) {
- case DDR2:
+ case _DDR2:
printf (Module data width%d bits\n, data[6]);
break;
default:
@@ -854,7 +854,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
switch (type) {
- case DDR2:
+ case _DDR2:
printf (SDRAM cycle time );
print_ddr2_tcyc (data[9]);
break;
@@ -865,7 +865,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
switch (type) {
- case DDR2:
+ case _DDR2:
printf (SDRAM access time0.%d%d ns\n,
(data[10] 4) 0x0F, data[10] 0x0F);
break;
@@ -899,7 +899,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
switch (type) {
- case DDR2:
+ case _DDR2:
printf (SDRAM width (primary)%d\n, data[13]);
break;
default:
@@ -912,7 +912,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
switch (type) {
- case DDR2:
+ case _DDR2:
if (data[14] != 0)
printf (EDC width%d\n, data[14]);
break;
@@ -929,7 +929,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
break;
}
- if (DDR2 != type) {
+ if (_DDR2 != type) {
printf (Min clock delay, back-to-back random column addresses
%d\n, data[15]);
}
@@ -944,7 +944,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
printf (Number of banks %d\n, data[17]);
switch (type) {
- case DDR2:
+ case _DDR2:
puts (CAS latency(s) );
decode_bits (data[18], decode_CAS_DDR2, 0);
putc ('\n');
@@ -956,20 +956,20 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
break;
}
- if (DDR2 != type) {
+ if (_DDR2 != type) {
puts (CS latency(s) );
decode_bits (data[19], decode_CS_WE_default, 0);
putc ('\n');
}
- if (DDR2 != type) {
+ if (_DDR2 != type) {
puts (WE latency(s) );
decode_bits (data[20], decode_CS_WE_default, 0);
putc ('\n');
}
switch (type) {
- case DDR2:
+ case _DDR2:
puts (Module attributes:\n);
if (data[21] 0x80)
puts ( TBD (bit 7)\n);
@@ -995,7 +995,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
switch (type) {
- case DDR2:
+ case _DDR2:
decode_bits (data[22], decode_byte22_DDR2, 0);
break;
default:
@@ -1014,7 +1014,7 @@ int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
switch (type) {
- case DDR2:
+ case _DDR2:
printf (SDRAM cycle time (2nd highest CAS latency));
Re: [U-Boot] [PATCH] IXP425: Improving print_cpuinfo code Part 1/1
On 23:28 Tue 16 Dec , Stefan Althoefer wrote: Jean-Christophe PLAGNIOL-VILLARD schrieb: + cfg_clk = *IXP425_EXP_CFG0 21; please use readx/writex The pointer dereference style is used throughout the other files in the IXP port as well. Shouldn't this be handled the same way in all files? yes it's old wrong way code for new we to use the good accessor for old code patch are welcome Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] v2009.01-rc1 is out - update of release schedule
Hi everybody... first the good news: v2009.01-rc1 has just been released. Not the not so good news: as you can see from the release name we have shifted the schedule by nearly a full month. There were several reasons for doing so: - We are (actually: I am) late with merging all the patches that have been submitted for this release. - The remaining time would not allow for thorough testing, especially since most people are not available because of Christmas vacation. - Shifting the release date allows us to get re-synced with the LInux release cycle, i. e. we try to avoid an overlap of the Linux and the U-Boot merge windows. Thus, the new planned release date is January 17, 2009. Sorry for the delay... 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 On the subject of C program indentation: In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. - Blair P. Houghton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master Scott Wood (1): NAND: Mark the BBT as scanned prior to calling scan_bbt. Scott, could you pick the patch [PATCH v3] nand: Fix cache and memory inconsistent issue Thank, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
Wolfgang Denk wrote: Hm... what exactly is broken with the concept of having a current device or a current bus? We use it elasewhere, too (like for selection IDE or S-ATA devices and such), and so far I am not aware of fundamental issues because of that. I think it's a kludge because you have to set the current device before you can access it. It seems ridiculous that you have to do this: i2c_set_bus_num(x) i2c_write(...) when you could do this: i2c_write(x, ...) Sounds to me like you haven't really looked at the U-Boot code. There are plenty of places where one function does I2C operations, then calls another function that does its own. Really? Where exactly does such a thing happen? Well, I can't find a real example, but here's something close. Take a look at function pib_init() in mpc8568mds.c. This function needs to talk to the 2nd I2C bus. It has no idea who called it, so it has no idea what the current I2C bus is. Therefore, it has to save and restore it. Now consider the code that calls pib_init(). Technically, this code cannot know that pib_init() does I2C operations. So it doesn't know that pib_init() could change the current I2C bus. So it wouldn't know to save and restore what it needs. This situation could happen anywhere. I tend to call this a bug that needs to be fixed, if there is ssuch code. It's not a bug. Function X does I2C operations, and function Y also does I2C operations, but on a different device. If function X calls function Y, then Y needs to save and restore the current bus number. You will never get rid of this requirement as long as you have the concept of a current I2C bus number. So you're still going to need i2c_get_bus_num() and i2c_set_bus_num(), and you're still going to have code like this: bus = i2c_get_bus_num(); i2c_set_bus_num(x); i2c_write(...) i2c_set_bus_num(bus); This statement is probably correct: I don't share your point of view here, either. In that case, I have no interest in working on this new I2C design. You guys obviously have everything under control, so good luck. -- Timur Tabi Linux Kernel Developer @ Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] 85xx: Fix the wrong CSIZE mask bit
was code breaking or just fixing it up to match the docs? not break the system, because the bit[55] is reserved zero for e500/e500mc. so just fixied it to match the e500/e500mc docs. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
On Tue, 16 Dec 2008, Timur Tabi wrote: Wolfgang Denk wrote: Hm... what exactly is broken with the concept of having a current device or a current bus? We use it elasewhere, too (like for selection IDE or S-ATA devices and such), and so far I am not aware of fundamental issues because of that. I think it's a kludge because you have to set the current device before you can access it. It seems ridiculous that you have to do this: i2c_set_bus_num(x) i2c_write(...) when you could do this: i2c_write(x, ...) Only if you have more than one I2C bus that 95% of supported boards don't have (95% is a wild guess; in reality, methinks, it is even closer to 99%.) That means you should only do this for less than 5% of existing boards. Adding a parameter would require you to make changes for 100% of boards. common/cmd_i2c.c is a single file, common for all platforms so it is a special case. Sounds to me like you haven't really looked at the U-Boot code. There are plenty of places where one function does I2C operations, then calls another function that does its own. Really? Where exactly does such a thing happen? Well, I can't find a real example, but here's something close. Take a look at function pib_init() in mpc8568mds.c. This function needs to talk to the 2nd I2C bus. It has no idea who called it, so it has no idea what the current I2C bus is. Therefore, it has to save and restore it. Now consider the code that calls pib_init(). Technically, this code cannot know that pib_init() does I2C operations. So it doesn't know that pib_init() could change the current I2C bus. So it wouldn't know to save and restore what it needs. This situation could happen anywhere. No, that is not an issue. That pib_init() does not happen out of a blue, it is YOU who call it in $(BOARD).c file so you MUST know what you are doing. I tend to call this a bug that needs to be fixed, if there is ssuch code. It's not a bug. Function X does I2C operations, and function Y also does I2C operations, but on a different device. If function X calls function Y, then Y needs to save and restore the current bus number. You will never get rid of this requirement as long as you have the concept of a current I2C bus number. So you're still going to need i2c_get_bus_num() and i2c_set_bus_num(), and you're still going to have code like this: bus = i2c_get_bus_num(); i2c_set_bus_num(x); i2c_write(...) i2c_set_bus_num(bus); This statement is probably correct: I don't share your point of view here, either. In that case, I have no interest in working on this new I2C design. You guys obviously have everything under control, so good luck. -- Timur Tabi Linux Kernel Developer @ Freescale --- ** * k...@homeKOI8 Net The impossible we do immediately. * * Las Vegas NV, USA Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] cmd_i2c: rename EDO, DDR and SDRAM to avoid conflict with at91 memory setup
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 1229469026-7344-1-git-send-email-plagn...@jcrosoft.com you wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Timo Tuunainen timo.tuunai...@sysart.fi
---
common/cmd_i2c.c | 58
+++---
1 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index 448f2fe..a662b53 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -712,7 +712,7 @@ static void decode_bits (u_char const b, char const
*str[], int const do_once)
*/
int do_sdram (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
- enum { unknown, EDO, SDRAM, DDR2 } type;
+ enum { unknown, _EDO, _SDRAM, _DDR2 } type;
Please do not use leading underscores in regular variable names. They
are reserved in C.
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 must be remembered that there is nothing more difficult to plan,
more doubtful of success, nor more dangerous to manage, than the
creation of a new system. For the initiator has the enmity of all who
would profit by the preservation of the old institutions and merely
lukewarm defenders in those who would gain by the new ones.
- Machiavelli
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] li r0,__got2_entr...@sectoff@l
hi all: i am a u-boot beginner, i found a line code li r0,__got2_entr...@sectoff@l in almost all mpc start.s.i have tried to delete sectoff and i got same result of uboot with li r0,__got2_entr...@l. could you tell me what difference between li r0,__got2_entr...@sectoff@l and li r0,__got2_entr...@l and why the author use li r0,__got2_entr...@sectoff@l but not li r0,__got2_entr...@l.thanks very much. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] i2c: merge all i2c_reg_read() and i2c_reg_write() into inline functions
On Tue, 16 Dec 2008, Wolfgang Denk wrote: Dear k...@koi8.net, In message pine.lnx.4.64ksi.0812161102580.28...@home-gw.koi8.net you wrote: I offered 4 possible scenarios and additional parameter to i2c functions was one of them. Wolfgang said that current bus approach looks better than others and I agree with him. But it is not rocket science to use an You and me agree on this. additional parameter either. The only thing is it MUST be consistent, i.e. we should NOT have 2 different sets of functions based on CONFIG_MULTIBUS or We agree on this, too. whatever. If we are to make this change ALL boards must be multibus with majority of them having bus count of 1. I don't think this makes sense - it would just add complexity and memory footprint without added benefit. Does anybody else have something to say on this? I'm going to write code so let's make some decision. I don't want this to end up as a company hack and making it properly affects a lot of U-boot... I support your position, not Timur's. OK, so I'm on it. It might take a couple of weeks for patches to show up. --- ** * k...@homeKOI8 Net The impossible we do immediately. * * Las Vegas NV, USA Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot-Users] TFTP server support in U-boot
Dear Ben, Thank you very much for the suggestion. Actually i could able to get the TFTP server up in u-boot. This Server wont run in the background all the time. The senario is like this, Board comes up and checks for validation of the image on the flash. If the validation fails it switches to the server mode that is its in the listening mode. If any read/write (RRQ/WRQ) requests come to the board, it services them and as you suggested if complete/done command(file) comes it switches from server mode and continues with the regular operation. Now i am able to service Read and write operations which come from TFTP client(PC based) .But this needs still lot of testing and validation. Can we make this as part of u-boot main line release? please let me know your views. And if you say yes , we can make this as part of u-boot main line release then i would need help from your side in finding out the different test cases to test this fully. Thank you very much for your suggestion. Regards, santosh On 12/16/08, Jerry Van Baren gerald.vanba...@ge.com wrote: Ben Warren wrote: Hello Santosh, santosh pattar wrote: Dear All, As of now in the U-boot only TFTP client is supported. I am planning to have TFTP server support in the u-boot. Can you please help me in this regarding? Please provide me few links if this has been done already, or links from where i can take some information and start working on it. I believe this has come up before, so search the mail archives. I don't remember anybody posting a patch, though. In general, U-boot doesn't 'serve', so you have quite a bit of work to do. Luckily, TFTP is one of the more trivial protocols, hence the name. Do search the archives because my memory isn't what it used to be, but I don't recall a TFTP server coming up. Periodically FTP support comes up and then silently disappears when the requester figures out how much work it would be. Despite sharing 3/4 of the characters and supporting the same concept, TFTP and FTP are totally different animals. I'm curious why you want to do this. People generally use U-boot as transient software for loading operating systems that are much more suitable for serving images. Do you have a situation where you have several identical devices and want to reduce the upstream network load? In that case, you may want to look into the multicast TFTP instead. regards, Ben If you really need this, I would suggest adding a simple (modal) tftp server command so that, when you execute the command all u-boot is doing is TFTP server work until something indicates done (e.g. a file was successfully transfered) and then the command exits. This would fit well into the u-boot restricted architecture that is characterized by being single threaded with no tasking. Trying to do a full fledged tftp server that runs independently in the background is going to be a lot harder because there is no background in u-boot. Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] CFI: increase performance
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD schrieb: On 17:46 Tue 16 Dec , Jens Gehrlein wrote: Jean-Christophe PLAGNIOL-VILLARD schrieb: On 17:25 Tue 16 Dec , Jens Gehrlein wrote: Hi list, The following patches should increase the performance of the CFI driver, particularly with regard to single word programming mode. I tested it on TQM5200S with NOR-Flash Samsung K8P2815UQB, which has no write buffer. At least no write buffer, that could be programmed using standard commands. Performance increase on this TQM is about factor 2.6 (37 KiB/s - 95 KiB/s). On the same module with Spansion S29GL128N (with write buffer) it is about factor 1.2 (455 KiB/s - 585 KiB/s). TQM5200 is a bottom boot module with 2x16 Bit Flash connection. Could someone test the patches on other HW, particularly top boot, other CPU, other flash width, please? Could you try it against the qemu SVN HEAD ??? Sorry, what is qemu SVN HEAD ??? In qemu you have 2 boards emulated with u-boot support qemu_mips and SX1 Now, I understand, what you meant. it'll be nice to test them also please note they are only in the SVN tree of qemu Because I'm neither familiar with qemu nor with svn I can't do that with little effort (installation, familiarization, etc.). Beside that, how could a virtual machine simulate the real bus access with it's bus timing? If I'm right in this point, only testing on another architecture is possible, but no performance test. Shortly, I will get a TQM8548 with Samsung Flash. It's a top boot system, but also has a 2x16 Bit Flash connection. For my part, I can only offer you a test on this board. Stefan, as the CFI custodian, how is your procedure to check such kind of common code patches? Kind regards, Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Move the LAW definition to fsl_law.h
NAND boot -Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: 2008?12?17? 1:54 AM To: Liu Dave-R63238 Cc: u-boot@lists.denx.de; Loeliger Jon-LOELIGER; Fleming Andy-AFLEMING Subject: Re: [U-Boot] [PATCH 3/3] Move the LAW definition to fsl_law.h On Dec 15, 2008, at 10:09 PM, Dave Liu wrote: some code need the LAWAR_EN, make them sharable. what code? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: add IDE init to lib_arm/board.c Part 1/1
Jean-Christophe PLAGNIOL-VILLARD wrote: On 22:08 Thu 04 Dec , Stefan Althoefer wrote: [PATCH] ARM: add IDE init to lib_arm/board.c This patch adds ide_init() to the arm boot process. The patch is against latest u-boot git-repository Please (still) be patient if style of submission or patches are offending. Signed-off-by: Stefan Althoefer stefan.althoe...@web.de diff -uprN u-boot-orig//lib_arm/board.c u-boot/lib_arm/board.c --- u-boot-orig//lib_arm/board.c 2008-12-02 17:25:32.0 +0100 +++ u-boot/lib_arm/board.c 2008-12-02 23:29:36.0 +0100 @@ -441,6 +441,11 @@ extern void davinci_eth_set_mac_addr (co } #endif +#if defined(CONFIG_CMD_IDE) +puts(IDE: ); +ide_init(); +#endif /* CONFIG_CMD_IDE */ are you sure it will work? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot I submit a patch series for ide support in ARM. I don't think that it will work Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
