Re: [U-Boot] printf in uboot
Hi,
On Mon, Dec 12, 2011 at 12:59:43, Sidharth Baisane wrote:
hi,
How can i use print statement in uboot ???
I tried printf in following program but its not executing it and my
program hangs afterwards.
void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
unsigned long addr;
#endif
*
printf(starting armboot);*
Serial Console is yet to be initialized at this point. And hence the board
seems to freeze here.
/* Pointer is writable since we allocated a register for it */
gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
/* compiler optimization barrier needed for GCC = 3.4 */
__asm__ __volatile__(: : :memory);
memset ((void*)gd, 0, sizeof (gd_t));
gd-bd = (bd_t*)((char*)gd - sizeof(bd_t));
memset (gd-bd, 0, sizeof (bd_t));
gd-flags |= GD_FLG_RELOC;
monitor_flash_len = _bss_start - _armboot_start;
Regards,
Gururaja
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] printf in uboot
hi,
I am trying to print statement in uboot.
but whenever I add *printf *statement board hangs.
For example in *u-boot/lib_arm/board.c* i added prinf statement and board
hags.
void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
unsigned long addr;
#endif
*printf(armboot starts\n);*
/* Pointer is writable since we allocated a register for it */
gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
/* compiler optimization barrier needed for GCC = 3.4 */
__asm__ __volatile__(: : :memory);
memset ((void*)gd, 0, sizeof (gd_t));
gd-bd = (bd_t*)((char*)gd - sizeof(bd_t));
memset (gd-bd, 0, sizeof (bd_t));
gd-flags |= GD_FLG_RELOC;
monitor_flash_len = _bss_start - _armboot_start;
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Add a pointer to the global data structure to point to the device tree
Hi Gabe, On 06/12/11 13:04, Gabe Black wrote: On Mon, Dec 5, 2011 at 5:49 PM, Graeme Russ graeme.r...@gmail.com mailto:graeme.r...@gmail.com wrote: Hi Gabe, On Tue, Dec 6, 2011 at 12:43 PM, Gabe Black gabebl...@chromium.org mailto:gabebl...@chromium.org wrote: This change adds a pointer to the global data structure in x86 to point to the device tree. This mirrors an identical pointer in ARM. Out of curiosity, is this paving the way for FDT support in general? If so, to what extent does the Linux kernel support FDT for x86? I have had thoughts about looking into what Device Tree / FDT is all about, and I'm wondering what it is going to bring to the table (positive and negative) for x86. For example, would this, in theory, depricate the boot_params structure, e820 map etc... Regards, Graeme The device tree can be used in two different ways, by u-boot and by the kernel. This is for use by u-boot itself and is one mechanism coreboot can use to make its own runtime modification to how u-boot is set up (if there's a serial console it can use, for instance), and it is fairly Hmmm, I'm now looking at PCI interrupt routing and I've had to do a bit of reading on the subject. It looks like I could do it via a table in EBDA or via ACPI. Since I'm booting Linux, I'm thinking the ACPI method which brings me to an interesting thought - Could (should?) I use the device tree to provide the ACPI data? On first glance though, it looks to me that FDT and ACPI provide related functionality, but on different platforms - Maybe I should provide the ACPI data directly in the uImage like the FDT is? Thoughts? useful. The kernel has some very minimal provisions for passing in a device tree in x86 through, if I remember correctly, basically a linked list of entries which hang off the end of the boot_params structure. The kernel doesn't take advantage of it at all, so it wouldn't really be useful to pass one in. There are times when it would be a good solution to certain problems but the kernel would have to actually be set up to take advantage of it first. Gabe Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm926ejs: remove noop flush_dcache_all function
Am 12.12.2011 00:09, schrieb Ilya Yanok: Commit 2f3427c added noop cache functions implementation for arm926ejs to fix compilation of drivers depending on these functions (DaVinci EMAC in particular). Unfortunately, the bug was introduced: noop implementation calls dcache_disable which calls flush_dcache_all which in turn calls dcache_disable thus creating an infinite loop. This patch removes noop implementation for flush_dcache_all, we already have default one in arch/arm/lib/cache.c and it should be used instead. Signed-off-by: Ilya Yanokya...@emcraft.com --- Hi Matthias, thanks for cathing this. Surely my initial patch was totally wrong. Could you please test this one? This patches solves at least my problem. Thanks. Tested-by: Matthias Weisser weiss...@arcor.de Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
On 12/07/2011 11:02 PM, Simon Glass wrote:
[...]
/*
- * Set a new environment variable,
- * or replace or delete an existing one.
+ * Performs consistency checking before setting, replacing,
+ * or deleting an environment variable, then (if successful)
+ * apply the changes to internals so to make them effective.
+ * Code for this function was taken out of _do_env_set(),
+ * which now calls it.
+ * Also called as a callback function by himport_r().
+ * Returns 0 in case of success, 1 in case of failure.
+ * When (flag H_FORCE) is set, force overwriting of
+ * write-once variables.
can you word-wrap that to 72 columns perhaps?
Sorry, I am little confused now. What is the maximum line length?
[...]
+/* Check whether variable name is amongst vars[] */
+static int process_var(const char *name, int nvars, char * const vars[])
+{
+ int i = 0;
blank line here.
Thanks, I didn't know about this.
Can part of this function be #ifdefed to reduce code
size when the feature is not required?
Uhm, I don't think so. This would be a common feature for selectively
importing setting back to default. Unless we want to #ifdef both of
them. Personally, I would #ifdef neither.
[...]
+ if (!process_var(name, nvars, vars))
+ continue;
if (hdelete_r(name, htab) == 0)
debug(DELETE ERROR
##\n);
perhaps:
if (process_var(name, nvars, vars)
hdelete_r(name, htab) == 0)
debug(DELETE ERROR ##\n);
I think it's easier to read it the original way, and it should not make
any difference as far as code size is concerned.
himport_r() is getting a bit overloaded,
Actually, I believe it makes no longer sense to have it called _r, as
it was the original reference to the function being recursively
calleable (i.e. reentrant) as opposed to other versions which were not.
and it's a shame but I can't
think of an easy way to refactor it to reduce the number of args. In a
way you are adding a processing option and so you could put the three
extra args in a structure and pass a pointer to it (or NULL to skip
this feature). Not sure though...
Can't think of any other way either, except maybe renaming it and
re-implementing the shorter version as a wrapper around the newly named
function. I had already done that, but there would be very few places
where the old syntax would be kept, so it just didn't make much sense.
Also, for me this patch adds 500 bytes. I wonder if more of the code
could made optional?
Frankly, I'm surprised to hear this adds that much overhead.
Actually, I can't see this increase in code size as you mention.
What architecture are you referring to?
In my workspace (ppc_6xx) u-boot.bin and a stripped u-boot ELF file are
surprisingly unchanged in size, even with debug #defined!
Only place I can experience such growth is within unstripped u-boot ELF,
which I believe shouldn't really matter... or should it?
Best,
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] env: check and apply changes on delete/destroy
On 12/07/2011 11:02 PM, Simon Glass wrote: diff --git a/include/search.h b/include/search.h index 2a59e03..7ad4261 100644 --- a/include/search.h +++ b/include/search.h @@ -142,7 +142,8 @@ int hcreate_r(size_t nel, struct hsearch_data *htab) * be freed and the local static variable can be marked as not used. */ -void hdestroy_r(struct hsearch_data *htab) +void hdestroy_r(struct hsearch_data *htab, + int(*apply)(const char *, const char *, const char *, int))\ You could just use 'apply_cb apply' for that param I think. Absolutely. I introduced the typedef at a later stage and forgot to update it there too. Good catch, thanks! Best, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] env: make env default selective, check and apply
On 12/07/2011 11:02 PM, Simon Glass wrote: Hi Gerlando, [...] diff --git a/include/environment.h b/include/environment.h index 3a3e6b8..8f0d4db 100644 --- a/include/environment.h +++ b/include/environment.h @@ -190,6 +190,11 @@ void env_crc_update(void); /* [re]set to the default environment */ void set_default_env(const char *s); +#ifdef CONFIG_CMD_DEFAULTENV_VARS +/* [re]set individual variables to their value in the default environment */ +int env_default_vars(int nvars, char * const vars[]); How about env_set_vars_to_default? Hmm... sounds too long to me. But if you insist... Best, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] pm9261: init serial console before relocation
On Fri, 9 Dec 2011 22:59:07 +0200 Asen Chavdarov Dimov di...@ronetix.at wrote: The early messages can be seen on the debug console. Signed-off-by: Asen Chavdarov Dimov di...@ronetix.at --- Change since v1 - rebased over master board/ronetix/pm9261/pm9261.c | 17 - include/configs/pm9261.h |1 + 2 files changed, 13 insertions(+), 5 deletions(-) Applied to u-boot-staging/ag...@denx.de. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] pm9g45: init serial console before relocation
On Fri, 9 Dec 2011 23:00:07 +0200 Asen Chavdarov Dimov di...@ronetix.at wrote: The early messages can be seen on the debug console. Signed-off-by: Asen Chavdarov Dimov di...@ronetix.at --- Change since v1 - rebased over master board/ronetix/pm9g45/pm9g45.c | 16 +++- include/configs/pm9g45.h |1 + 2 files changed, 12 insertions(+), 5 deletions(-) Applied to u-boot-staging/ag...@denx.de. Thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Cleanups and updates for ULPI
This series encorporates comments from Simon Glass [1] regarding the arguments types and return error types used in generic ULPI code. Adds a documentation for the new CONFIG_* options. In addition it improves the verbosity of the error path. [1] http://www.mail-archive.com/u-boot@lists.denx.de/msg72060.html Igor Grinberg (4): USB: ULPI: switch argument type from u8 to unsigned USB: ULPI: clean a mixup of return types USB: ULPI: increase error case verbosity README: add documentation for CONFIG_USB_ULPI* README |8 drivers/usb/ulpi/ulpi-viewport.c |4 ++-- drivers/usb/ulpi/ulpi.c | 30 +++--- include/usb/ulpi.h |8 4 files changed, 29 insertions(+), 21 deletions(-) -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] USB: ULPI: clean a mixup of return types
Clean a mixup between u32 and int as a return type
for functions returning error values.
Use int as it is native (and widely used) return type.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
drivers/usb/ulpi/ulpi-viewport.c |4 ++--
drivers/usb/ulpi/ulpi.c |8
include/usb/ulpi.h |2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/ulpi/ulpi-viewport.c b/drivers/usb/ulpi/ulpi-viewport.c
index fa2e004..490fb0e 100644
--- a/drivers/usb/ulpi/ulpi-viewport.c
+++ b/drivers/usb/ulpi/ulpi-viewport.c
@@ -98,7 +98,7 @@ static int ulpi_request(u32 ulpi_viewport, u32 value)
return err;
}
-u32 ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value)
+int ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value)
{
u32 val = ULPI_RWRUN | ULPI_RWCTRL | ((u32)reg 16) | (value 0xff);
@@ -107,7 +107,7 @@ u32 ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value)
u32 ulpi_read(u32 ulpi_viewport, u8 *reg)
{
- u32 err;
+ int err;
u32 val = ULPI_RWRUN | ((u32)reg 16);
err = ulpi_request(ulpi_viewport, val);
diff --git a/drivers/usb/ulpi/ulpi.c b/drivers/usb/ulpi/ulpi.c
index 1371aa6..f3f293f 100644
--- a/drivers/usb/ulpi/ulpi.c
+++ b/drivers/usb/ulpi/ulpi.c
@@ -39,8 +39,8 @@ static struct ulpi_regs *ulpi = (struct ulpi_regs *)0;
static int ulpi_integrity_check(u32 ulpi_viewport)
{
- u32 err, val, tval = ULPI_TEST_VALUE;
- int i;
+ u32 val, tval = ULPI_TEST_VALUE;
+ int err, i;
/* Use the 'special' test value to check all bits */
for (i = 0; i 2; i++, tval = 1) {
@@ -171,7 +171,7 @@ int ulpi_serial_mode_enable(u32 ulpi_viewport, unsigned
smode)
int ulpi_suspend(u32 ulpi_viewport)
{
- u32 err;
+ int err;
err = ulpi_write(ulpi_viewport, ulpi-function_ctrl_clear,
ULPI_FC_SUSPENDM);
@@ -214,7 +214,7 @@ int ulpi_reset_wait(u32) __attribute__((weak,
alias(__ulpi_reset_wait)));
int ulpi_reset(u32 ulpi_viewport)
{
- u32 err;
+ int err;
err = ulpi_write(ulpi_viewport,
ulpi-function_ctrl_set, ULPI_FC_RESET);
diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h
index dc78a59..802f077 100644
--- a/include/usb/ulpi.h
+++ b/include/usb/ulpi.h
@@ -108,7 +108,7 @@ int ulpi_reset(u32 ulpi_viewport);
*
* returns 0 on success, ULPI_ERROR on failure.
*/
-u32 ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value);
+int ulpi_write(u32 ulpi_viewport, u8 *reg, u32 value);
/*
* Read the ULPI PHY register content via the viewport.
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] USB: ULPI: switch argument type from u8 to unsigned
There is no benefit in usign u8, so switch to unsinged to reduce the
binary image size (by 20 bytes).
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
drivers/usb/ulpi/ulpi.c | 10 +-
include/usb/ulpi.h |6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/ulpi/ulpi.c b/drivers/usb/ulpi/ulpi.c
index 805e29d..1371aa6 100644
--- a/drivers/usb/ulpi/ulpi.c
+++ b/drivers/usb/ulpi/ulpi.c
@@ -79,9 +79,9 @@ int ulpi_init(u32 ulpi_viewport)
return ulpi_integrity_check(ulpi_viewport);
}
-int ulpi_select_transceiver(u32 ulpi_viewport, u8 speed)
+int ulpi_select_transceiver(u32 ulpi_viewport, unsigned speed)
{
- u8 tspeed = ULPI_FC_FULL_SPEED;
+ u32 tspeed = ULPI_FC_FULL_SPEED;
u32 val;
switch (speed) {
@@ -127,9 +127,9 @@ int ulpi_set_pd(u32 ulpi_viewport, int enable)
return ulpi_write(ulpi_viewport, reg, val);
}
-int ulpi_opmode_sel(u32 ulpi_viewport, u8 opmode)
+int ulpi_opmode_sel(u32 ulpi_viewport, unsigned opmode)
{
- u8 topmode = ULPI_FC_OPMODE_NORMAL;
+ u32 topmode = ULPI_FC_OPMODE_NORMAL;
u32 val;
switch (opmode) {
@@ -154,7 +154,7 @@ int ulpi_opmode_sel(u32 ulpi_viewport, u8 opmode)
return ulpi_write(ulpi_viewport, ulpi-function_ctrl, val);
}
-int ulpi_serial_mode_enable(u32 ulpi_viewport, u8 smode)
+int ulpi_serial_mode_enable(u32 ulpi_viewport, unsigned smode)
{
switch (smode) {
case ULPI_IFACE_6_PIN_SERIAL_MODE:
diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h
index d871290..dc78a59 100644
--- a/include/usb/ulpi.h
+++ b/include/usb/ulpi.h
@@ -41,7 +41,7 @@ int ulpi_init(u32 ulpi_viewport);
*ULPI_FC_LOW_SPEED, ULPI_FC_FS4LS
* returns 0 on success, ULPI_ERROR on failure.
*/
-int ulpi_select_transceiver(u32 ulpi_viewport, u8 speed);
+int ulpi_select_transceiver(u32 ulpi_viewport, unsigned speed);
/*
* Enable/disable VBUS.
@@ -66,7 +66,7 @@ int ulpi_set_pd(u32 ulpi_viewport, int enable);
*
* returns 0 on success, ULPI_ERROR on failure.
*/
-int ulpi_opmode_sel(u32 ulpi_viewport, u8 opmode);
+int ulpi_opmode_sel(u32 ulpi_viewport, unsigned opmode);
/*
* Switch to Serial Mode.
@@ -78,7 +78,7 @@ int ulpi_opmode_sel(u32 ulpi_viewport, u8 opmode);
* Switches immediately to Serial Mode.
* To return from Serial Mode, STP line needs to be asserted.
*/
-int ulpi_serial_mode_enable(u32 ulpi_viewport, u8 smode);
+int ulpi_serial_mode_enable(u32 ulpi_viewport, unsigned smode);
/*
* Put PHY into low power mode.
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] USB: ULPI: increase error case verbosity
Add the argument value to the error message. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- drivers/usb/ulpi/ulpi.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/ulpi/ulpi.c b/drivers/usb/ulpi/ulpi.c index f3f293f..6202227 100644 --- a/drivers/usb/ulpi/ulpi.c +++ b/drivers/usb/ulpi/ulpi.c @@ -92,8 +92,8 @@ int ulpi_select_transceiver(u32 ulpi_viewport, unsigned speed) tspeed = speed; break; default: - printf(ULPI: %s: wrong transceiver speed specified, - falling back to full speed\n, __func__); + printf(ULPI: %s: wrong transceiver speed specified: %u, + falling back to full speed\n, __func__, speed); } val = ulpi_read(ulpi_viewport, ulpi-function_ctrl); @@ -140,8 +140,8 @@ int ulpi_opmode_sel(u32 ulpi_viewport, unsigned opmode) topmode = opmode; break; default: - printf(ULPI: %s: wrong OpMode specified, - falling back to OpMode Normal\n, __func__); + printf(ULPI: %s: wrong OpMode specified: %u, + falling back to OpMode Normal\n, __func__, opmode); } val = ulpi_read(ulpi_viewport, ulpi-function_ctrl); @@ -161,8 +161,8 @@ int ulpi_serial_mode_enable(u32 ulpi_viewport, unsigned smode) case ULPI_IFACE_3_PIN_SERIAL_MODE: break; default: - printf(ULPI: %s: unrecognized Serial Mode specified\n, - __func__); + printf(ULPI: %s: unrecognized Serial Mode specified: %u\n, + __func__, smode); return ULPI_ERROR; } -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] README: add documentation for CONFIG_USB_ULPI*
Add documentation for CONFIG_USB_ULPI and CONFIG_USB_ULPI_VIEWPORT configuration options. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- README |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/README b/README index ff72e47..6fe1e0f 100644 --- a/README +++ b/README @@ -1185,6 +1185,14 @@ The following options need to be configured: for your device - CONFIG_USBD_PRODUCTID 0x +- ULPI Layer Support: + The ULPI (UTMI Low Pin (count) Interface) PHYs are supported via + the generic ULPI layer. The generic layer accesses the ULPI PHY + via the platform viewport, so you need both the genric layer and + the viewport enabled. Currently only Chipidea/ARC based + viewport is supported. + To enable the ULPI layer support, define CONFIG_USB_ULPI and + CONFIG_USB_ULPI_VIEWPORT in your board configuration file. - MMC Support: The MMC controller on the Intel PXA is supported. To -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] NET: NE2000: Cleanup IO accessors
On Sunday 11 December 2011 08:42:07 Marek Vasut wrote: On Saturday 10 December 2011 20:09:30 Marek Vasut wrote: Introduce ne2k_register_io(in, out), which allows user to supply two functions. One for reading data from the card, the other for writing data to the card. Then introduce drivers' private data, which carry pointers to these functions and are passed throughout the driver. where are the users of this new API ? as it stands, i just see bloat. every register access is now an indirect function call ? what's the point Go to ... drivers/net/ax88796.h ... and check how it's done now. It's just wrong. Now for .03 release I have pxa3xx support ready which uses just this chip and adding more sh^Htuff to that fill would be even worse bloat. i agree, that code is terrible. however, those code paths can be trivially merged without the proposed bloat yours brings in. So what's your suggested awesome clean solution? further, that code base isn't even used by the ne2000 driver. What are you talking about, did you even bother to look? so again, the question stands: what exactly do you need to do different ? looks to me like the DP_* macros should get punted in favor of io.h accessors, and the register offsets rewritten into C structs. Sure, but not every hardware accesses the registers the same way. So I'm open for your suggestions on how to do it properly, apparently you have much better idea up your sleeve. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5 v2] mtd/nand: remove CONFIG_SYS_NAND_ONFI_DETECTION to enable ONFI detection
remove CONFIG_SYS_NAND_ONFI_DETECTION to enable ONFI detection.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
drivers/mtd/nand/nand_base.c |9 -
include/linux/mtd/nand.h |2 --
2 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index fd38477..80c9e5c 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2415,7 +2415,6 @@ static void nand_set_defaults(struct nand_chip *chip, int
busw)
chip-controller = chip-hwcontrol;
}
-#ifdef CONFIG_SYS_NAND_ONFI_DETECTION
static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
{
int i;
@@ -2493,14 +2492,6 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd,
return 1;
}
-#else
-static inline int nand_flash_detect_onfi(struct mtd_info *mtd,
- struct nand_chip *chip,
- int *busw)
-{
- return 0;
-}
-#endif
static void nand_flash_detect_non_onfi(struct mtd_info *mtd,
struct nand_chip *chip,
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 1cdc7ae..fc35102 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -472,9 +472,7 @@ struct nand_chip {
uint8_t cellinfo;
int badblockpos;
int onfi_version;
-#ifdef CONFIG_SYS_NAND_ONFI_DETECTION
struct nand_onfi_params onfi_params;
-#endif
int state;
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5 v2] mtd/nand: Add ONFI support for FSL NAND controller
- fix NAND_CMD_READID command for ONFI detect. - add NAND_CMD_PARAM command to read the ONFI parameter page. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- drivers/mtd/nand/fsl_elbc_nand.c | 17 ++--- 1 files changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index 4d1e527..99d1061 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -340,18 +340,21 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command, /* READID must read all 5 possible bytes while CEB is active */ case NAND_CMD_READID: - vdbg(fsl_elbc_cmdfunc: NAND_CMD_READID.\n); + case NAND_CMD_PARAM: + vdbg(fsl_elbc_cmdfunc: NAND_CMD 0x%x.\n, command); out_be32(lbc-fir, (FIR_OP_CW0 FIR_OP0_SHIFT) | (FIR_OP_UA FIR_OP1_SHIFT) | (FIR_OP_RBW FIR_OP2_SHIFT)); - out_be32(lbc-fcr, NAND_CMD_READID FCR_CMD0_SHIFT); - /* 5 bytes for manuf, device and exts */ - out_be32(lbc-fbcr, 5); - ctrl-read_bytes = 5; + out_be32(lbc-fcr, command FCR_CMD0_SHIFT); + /* +* although currently it's 8 bytes for READID, we always read +* the maximum 256 bytes(for PARAM) +*/ + out_be32(lbc-fbcr, 256); + ctrl-read_bytes = 256; ctrl-use_mdr = 1; - ctrl-mdr = 0; - + ctrl-mdr = column; set_addr(mtd, 0, 0, 0); fsl_elbc_run_command(mtd); return; -- 1.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5 v2] mtd/nand: Add function board_nand_init_tail() for some special NAND controllers
In some NAND controllers there is a size limitation of RAM buffer(2K bytes).
To support large-page NAND chips with greater than 2K pagesize, we need a large
buffer, but we don't know pagesize before calling nand_scan_ident(), for more
flexible and to identify different cases of large-page greater than 2K bytes,
we have a board_nand_init_tail() between nand_scan_ident() and nand_scan_tail().
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
drivers/mtd/nand/nand.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c
index d987f4c..14b4d67 100644
--- a/drivers/mtd/nand/nand.c
+++ b/drivers/mtd/nand/nand.c
@@ -39,6 +39,14 @@ static ulong base_address[CONFIG_SYS_MAX_NAND_DEVICE] =
CONFIG_SYS_NAND_BASE_LIS
static const char default_nand_name[] = nand;
static __attribute__((unused)) char dev_name[CONFIG_SYS_MAX_NAND_DEVICE][8];
+int __board_nand_init_tail(struct mtd_info *mtd)
+{
+ /* Allow for init at tail in controller-specific file for some reason */
+ return 0;
+}
+int board_nand_init_tail(struct mtd_info *mtd)
+__attribute__((weak, alias(__board_nand_init_tail)));
+
static void nand_init_chip(struct mtd_info *mtd, struct nand_chip *nand,
ulong base_addr)
{
@@ -51,7 +59,16 @@ static void nand_init_chip(struct mtd_info *mtd, struct
nand_chip *nand,
nand-IO_ADDR_R = nand-IO_ADDR_W = (void __iomem *)base_addr;
if (board_nand_init(nand) == 0) {
- if (nand_scan(mtd, maxchips) == 0) {
+ if (!nand_scan_ident(mtd, maxchips, NULL)) {
+ if (board_nand_init_tail(mtd)) {
+ mtd-name = NULL;
+ return;
+ }
+
+ if (nand_scan_tail(mtd)) {
+ mtd-name = NULL;
+ return;
+ }
if (!mtd-name)
mtd-name = (char *)default_nand_name;
#ifdef CONFIG_NEEDS_MANUAL_RELOC
--
1.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip with pagesize larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Liu Shuo b35...@freescale.com
---
drivers/mtd/nand/fsl_elbc_nand.c | 283 +
1 files changed, 252 insertions(+), 31 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 99d1061..a2d8067 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -64,7 +64,6 @@ struct fsl_elbc_mtd {
struct device *dev;
int bank; /* Chip select bank number */
u8 __iomem *vbase; /* Chip select base virtual address */
- int page_size; /* NAND page size (0=512, 1=2048)*/
unsigned int fmr; /* FCM Flash Mode Register value */
};
@@ -85,6 +84,8 @@ struct fsl_elbc_ctrl {
unsigned int mdr;/* UPM/FCM Data Register value */
unsigned int use_mdr;/* Non zero if the MDR is to be set */
unsigned int oob;/* Non zero if operating on OOB data */
+ char *buffer;/* Just used when pagesize is greater*/
+/* than FCM RAM 2K limitation*/
};
/* These map to the positions used by the FCM hardware ECC generator */
@@ -159,6 +160,35 @@ static struct nand_bbt_descr bbt_mirror_descr = {
.pattern = mirror_pattern,
};
+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd-priv;
+ struct fsl_elbc_mtd *priv = chip-priv;
+ struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+ void *src, *dst;
+ int len = oob ? 64 : 2048;
+
+ /* for emulating 4096+ bytes NAND using 2048-byte FCM RAM */
+ dst = ctrl-buffer + (oob ? mtd-writesize : 0) + subpage * len;
+ src = ctrl-addr + (oob ? 2048 : 0);
+ memcpy_fromio(dst, src, len);
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+ struct nand_chip *chip = mtd-priv;
+ struct fsl_elbc_mtd *priv = chip-priv;
+ struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+ void *src, *dst;
+ int len = oob ? 64 : 2048;
+
+ src = ctrl-buffer + (oob ? mtd-writesize : 0) + subpage * len;
+ dst = ctrl-addr + (oob ? 2048 : 0);
+ memcpy_toio(dst, src, len);
+ /* See the in_8() in fsl_elbc_write_buf() */
+ in_8(ctrl-addr);
+}
+
/*=*/
/*
@@ -175,7 +205,7 @@ static void set_addr(struct mtd_info *mtd, int column, int
page_addr, int oob)
ctrl-page = page_addr;
- if (priv-page_size) {
+ if (mtd-writesize = 2048) {
out_be32(lbc-fbar, page_addr 6);
out_be32(lbc-fpar,
((page_addr FPAR_LP_PI_SHIFT) FPAR_LP_PI) |
@@ -194,7 +224,7 @@ static void set_addr(struct mtd_info *mtd, int column, int
page_addr, int oob)
/* for OOB data point to the second half of the buffer */
if (oob)
- ctrl-index += priv-page_size ? 2048 : 512;
+ ctrl-index += mtd-writesize;
vdbg(set_addr: bank=%d, ctrl-addr=0x%p (0x%p),
index %x, pes %d ps %d\n,
@@ -256,13 +286,14 @@ static int fsl_elbc_run_command(struct mtd_info *mtd)
return ctrl-status == LTESR_CC ? 0 : -EIO;
}
-static void fsl_elbc_do_read(struct nand_chip *chip, int oob)
+static void fsl_elbc_do_read(struct mtd_info *mtd, int oob)
{
+ struct nand_chip *chip = mtd-priv;
struct fsl_elbc_mtd *priv = chip-priv;
struct fsl_elbc_ctrl *ctrl = priv-ctrl;
fsl_lbc_t *lbc = ctrl-regs;
- if (priv-page_size) {
+ if (mtd-writesize = 2048) {
out_be32(lbc-fir,
(FIR_OP_CW0 FIR_OP0_SHIFT) |
(FIR_OP_CA FIR_OP1_SHIFT) |
@@ -295,6 +326,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned
int command,
struct fsl_elbc_mtd *priv = chip-priv;
struct fsl_elbc_ctrl *ctrl = priv-ctrl;
fsl_lbc_t *lbc = ctrl-regs;
+ int i, nps = mtd-writesize / 2048;
ctrl-use_mdr = 0;
@@ -319,8 +351,28 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd,
unsigned int command,
ctrl-read_bytes = mtd-writesize + mtd-oobsize;
ctrl-index += column;
- fsl_elbc_do_read(chip, 0);
+ fsl_elbc_do_read(mtd, 0);
fsl_elbc_run_command(mtd);
+
+ if (mtd-writesize = 2048)
+ return;
+
+ /* Continue to read the rest bytes if writesize 2048 */
+ io_to_buffer(mtd, 0, 0);
+ io_to_buffer(mtd, 0, 1);
+ /*
+* Maybe there are
[U-Boot] test mail
Test mail to mailing list. Please ignore. Sorry for the spam. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Subject: [PATCH 0/2] ** Add ext4 filesystem support in uboot **
Hi All, We at Samsung have implemented ext4 file system support in uboot. Please review the subsequent patches. Thanks Regards, Uma Shankar Manjunatha C Achar From: Uma Shankar uma.shan...@samsung.com Date: Mon, 12 Dec 2011 12:01:23 +0530 Subject: [PATCH 0/2] *** Add ext4 filesystem support in uboot *** *** This patch series adds support for ext4 ls,load and write features in uboot Journaling is supported for write feature. To Enable EXT4 commands, modify the board specific config file with #define CONFIG_CMD_EXT2 1 #define CONFIG_CMD_EXT4 1 Steps to test: 1. After applying the patch, ext4 specific commands can be seen in the boot loader prompt using UBOOT #help ext4load- load binary file from a Ext4 file system ext4ls - list files in a directory (default /) ext4write- create a file in ext4 formatted partition 2. To list the files in ext4 formatted partition, execute ext4ls interface dev[:part] [directory] For example: UBOOT #ext4ls mmc 0:5 /usr/lib 3. To read and load a file from an ext4 formatted partition to RAM, execute ext4load interface dev[:part] [addr] [filename] [bytes] For example: UBOOT #ext4load mmc 2:2 0x30007fc0 uImage 4. To write a file to a ext4 formatted partition. a) First load a file to RAM at a particular address for example 0x30007fc0. Now execute ext4write command ext4write interface dev[:part] [filename] [Address] [sizebytes] For example: UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120 (here 6183120 is the size of the file to be written) Note: Absolute path is required for the file to be written *** Uma Shankar (2): ext4fs ls load support ext4fs write support Makefile |2 +- common/Makefile|1 + common/cmd_ext4.c | 388 ++ fs/Makefile|1 + fs/ext2/ext2fs.c | 303 + fs/ext4/Makefile | 51 ++ fs/ext4/crc16.c| 61 ++ fs/ext4/crc16.h| 17 + fs/ext4/ext4_common.c | 1954 fs/ext4/ext4_common.h | 61 ++ fs/ext4/ext4_journal.c | 657 fs/ext4/ext4_journal.h | 147 fs/ext4/ext4fs.c | 1252 +++ include/ext2fs.h | 177 +- include/ext4fs.h | 172 + 15 files changed, 4937 insertions(+), 307 deletions(-) create mode 100644 common/cmd_ext4.c create mode 100644 fs/ext4/Makefile create mode 100644 fs/ext4/crc16.c create mode 100644 fs/ext4/crc16.h create mode 100644 fs/ext4/ext4_common.c create mode 100644 fs/ext4/ext4_common.h create mode 100644 fs/ext4/ext4_journal.c create mode 100644 fs/ext4/ext4_journal.h create mode 100644 fs/ext4/ext4fs.c create mode 100644 include/ext4fs.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Subject: [PATCH 1/2] ext4fs ls load support
From: Uma Shankar uma.shan...@samsung.com
Date: Mon, 12 Dec 2011 12:01:22 +0530
Subject: [PATCH 1/2] ext4fs ls load support
Signed-off-by: Uma Shankar uma.shan...@samsung.com, Manjunatha C Achar
a.manjuna...@samsung.com
Signed-off-by: Iqbal Shareef iqbal@samsung.com
Signed-off-by: Hakgoo Lee goodguy@samsung.com
---
Makefile |2 +-
common/Makefile |1 +
common/cmd_ext4.c | 255 ++
fs/Makefile |1 +
fs/ext2/ext2fs.c | 303 +--
fs/ext4/Makefile | 51 +
fs/ext4/ext4_common.c | 572
+
fs/ext4/ext4_common.h | 44
fs/ext4/ext4fs.c | 215 ++
include/ext2fs.h | 177 +++-
include/ext4fs.h | 164 ++
11 files changed, 1478 insertions(+), 307 deletions(-)
create mode 100644 common/cmd_ext4.c
create mode 100644 fs/ext4/Makefile
create mode 100644 fs/ext4/ext4_common.c
create mode 100644 fs/ext4/ext4_common.h
create mode 100644 fs/ext4/ext4fs.c
create mode 100644 include/ext4fs.h
diff --git a/Makefile b/Makefile
index fb658f4..5f29812 100644
--- a/Makefile
+++ b/Makefile
@@ -235,7 +235,7 @@ LIBS += dts/libdts.o
endif
LIBS += arch/$(ARCH)/lib/lib$(ARCH).o
LIBS += fs/cramfs/libcramfs.o fs/fat/libfat.o fs/fdos/libfdos.o
fs/jffs2/libjffs2.o \
- fs/reiserfs/libreiserfs.o fs/ext2/libext2fs.o fs/yaffs2/libyaffs2.o \
+ fs/reiserfs/libreiserfs.o fs/ext2/libext2fs.o fs/ext4/libext4fs.o
fs/yaffs2/libyaffs2.o \
fs/ubifs/libubifs.o
LIBS += net/libnet.o
LIBS += disk/libdisk.o
diff --git a/common/Makefile b/common/Makefile
index 1b672ad..d7fd4a8 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -90,6 +90,7 @@ COBJS-$(CONFIG_CMD_EEPROM) += cmd_eeprom.o
COBJS-$(CONFIG_CMD_ELF) += cmd_elf.o
COBJS-$(CONFIG_SYS_HUSH_PARSER) += cmd_exit.o
COBJS-$(CONFIG_CMD_EXT2) += cmd_ext2.o
+COBJS-$(CONFIG_CMD_EXT4) += cmd_ext4.o
COBJS-$(CONFIG_CMD_FAT) += cmd_fat.o
COBJS-$(CONFIG_CMD_FDC)$(CONFIG_CMD_FDOS) += cmd_fdc.o
COBJS-$(CONFIG_OF_LIBFDT) += cmd_fdt.o fdt_support.o
diff --git a/common/cmd_ext4.c b/common/cmd_ext4.c
new file mode 100644
index 000..b223443
--- /dev/null
+++ b/common/cmd_ext4.c
@@ -0,0 +1,255 @@
+/*
+ * (C) Copyright 2011 Samsung Electronics
+ * EXT4 filesystem implementation in Uboot by
+ * Uma Shankar uma.shan...@samsung.com
+ * Manjunatha C Achar a.manjuna...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+/*
+ * Ext4fs support
+ * made from existing cmd_ext2.c file of Uboot
+ */
+#include common.h
+#include part.h
+#include config.h
+#include command.h
+#include image.h
+#include linux/ctype.h
+#include asm/byteorder.h
+#include ext2fs.h
+#include ext4fs.h
+#include linux/stat.h
+#include ../disk/part_dos.h
+#include malloc.h
+
+#if defined(CONFIG_CMD_USB) defined(CONFIG_USB_STORAGE)
+#include usb.h
+#endif
+
+#if !defined(CONFIG_DOS_PARTITION) !defined(CONFIG_EFI_PARTITION)
+#error DOS or EFI partition support must be selected
+#endif
+
+uint64_t total_sector;
+uint64_t part_offset;
+static uint64_t part_size;
+static uint16_t cur_part = 1;
+
+#define DOS_PART_MAGIC_OFFSET 0x1fe
+#define DOS_FS_TYPE_OFFSET 0x36
+#define DOS_FS32_TYPE_OFFSET 0x52
+
+int do_ext4_load(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
+{
+ char *filename = NULL;
+ char *ep;
+ int dev, part = 1;
+ ulong addr = 0, part_length;
+ int filelen;
+ disk_partition_t info;
+ ExtFileSystem *fs;
+ char buf[12];
+ unsigned long count;
+ char *addr_str;
+
+ switch (argc) {
+ case 3:
+ addr_str = getenv(loadaddr);
+ if (addr_str != NULL)
+ addr = strict_strtoul(addr_str, NULL, 16);
+ else
+ addr = CONFIG_SYS_LOAD_ADDR;
+
+ filename = getenv(bootfile);
+ count = 0;
+ break;
+ case 4:
+ addr = strict_strtoul(argv[3], NULL, 16);
+ filename = getenv(bootfile);
+ count = 0;
+ break;
+ case 5:
+ addr = strict_strtoul(argv[3], NULL, 16);
+ filename = argv[4];
+ count = 0;
+ break;
+ case 6:
+ addr = strict_strtoul(argv[3], NULL, 16);
+ filename = argv[4];
+ count = strict_strtoul(argv[5], NULL, 16);
+ break;
+
+ default:
+ return cmd_usage(cmdtp);
+ }
+
+ if (!filename) {
+ puts(** No boot file defined **\n);
+ return 1;
+ }
+
+ dev = (int)strict_strtoul(argv[2], ep, 16);
+ ext4_dev_desc =
Re: [U-Boot] Subject: [PATCH 0/2] ** Add ext4 filesystem support in uboot **
Hi Uma, On 12/12/11 21:37, uma.shan...@samsung.com wrote: Hi All, We at Samsung have implemented ext4 file system support in uboot. Please review the subsequent patches. Thanks Regards, Uma Shankar Manjunatha C Achar From: Uma Shankar uma.shan...@samsung.com Date: Mon, 12 Dec 2011 12:01:23 +0530 Subject: [PATCH 0/2] *** Add ext4 filesystem support in uboot *** *** This patch series adds support for ext4 ls,load and write features in uboot Journaling is supported for write feature. To Enable EXT4 commands, modify the board specific config file with #define CONFIG_CMD_EXT2 1 #define CONFIG_CMD_EXT4 1 Steps to test: 1. After applying the patch, ext4 specific commands can be seen in the boot loader prompt using UBOOT #help ext4load- load binary file from a Ext4 file system ext4ls - list files in a directory (default /) ext4write- create a file in ext4 formatted partition 2. To list the files in ext4 formatted partition, execute ext4ls interface dev[:part] [directory] For example: UBOOT #ext4ls mmc 0:5 /usr/lib 3. To read and load a file from an ext4 formatted partition to RAM, execute ext4load interface dev[:part] [addr] [filename] [bytes] For example: UBOOT #ext4load mmc 2:2 0x30007fc0 uImage 4. To write a file to a ext4 formatted partition. a) First load a file to RAM at a particular address for example 0x30007fc0. Now execute ext4write command ext4write interface dev[:part] [filename] [Address] [sizebytes] For example: UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120 (here 6183120 is the size of the file to be written) Note: Absolute path is required for the file to be written *** Uma Shankar (2): ext4fs ls load support ext4fs write support I notice different coding styles in the two patches - In particular, the first patch uses spaces for indentation and the second (correctly) uses tabs Can you please run the 'checkpatch' script (it in the root of the u-boot tree) on both and correct any errors and warnings Regards, Graeme Makefile |2 +- common/Makefile|1 + common/cmd_ext4.c | 388 ++ fs/Makefile|1 + fs/ext2/ext2fs.c | 303 + fs/ext4/Makefile | 51 ++ fs/ext4/crc16.c| 61 ++ fs/ext4/crc16.h| 17 + fs/ext4/ext4_common.c | 1954 fs/ext4/ext4_common.h | 61 ++ fs/ext4/ext4_journal.c | 657 fs/ext4/ext4_journal.h | 147 fs/ext4/ext4fs.c | 1252 +++ include/ext2fs.h | 177 +- include/ext4fs.h | 172 + 15 files changed, 4937 insertions(+), 307 deletions(-) create mode 100644 common/cmd_ext4.c create mode 100644 fs/ext4/Makefile create mode 100644 fs/ext4/crc16.c create mode 100644 fs/ext4/crc16.h create mode 100644 fs/ext4/ext4_common.c create mode 100644 fs/ext4/ext4_common.h create mode 100644 fs/ext4/ext4_journal.c create mode 100644 fs/ext4/ext4_journal.h create mode 100644 fs/ext4/ext4fs.c create mode 100644 include/ext4fs.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix building for mx51evk board
Fix:
mx51evk.c:206:6: error: conflicting types for 'board_ehci_hcd_init'
/u-boot/include/usb/ehci-fsl.h:254:5: note: previous declaration of
'board_ehci_hcd_init' was here
We also fix board_ehci_hcd_init() for mx53loco board.
Building for mx53loco worked since usb/ehci-fsl.h is
not included here.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
board/freescale/mx51evk/mx51evk.c |3 ++-
board/freescale/mx53loco/mx53loco.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 13c5941..e43aaf7 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -203,7 +203,7 @@ static void setup_usb_h1(void)
mxc_iomux_set_pad(MX51_PIN_EIM_D21, GPIO_PAD);
}
-void board_ehci_hcd_init(int port)
+int board_ehci_hcd_init(int port)
{
/* Set USBH1_STP to GPIO and toggle it */
mxc_request_iomux(MX51_PIN_USBH1_STP, IOMUX_CONFIG_GPIO);
@@ -228,6 +228,7 @@ void board_ehci_hcd_init(int port)
gpio_direction_output(MX51EVK_USBH1_HUB_RST, 0);
mdelay(2);
gpio_set_value(MX51EVK_USBH1_HUB_RST, 1);
+ return 0;
}
#endif
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index 57170ce..ea4d354 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -79,12 +79,13 @@ static void setup_iomux_uart(void)
}
#ifdef CONFIG_USB_EHCI_MX5
-void board_ehci_hcd_init(int port)
+int board_ehci_hcd_init(int port)
{
/* request VBUS power enable pin, GPIO[8}, gpio7 */
mxc_request_iomux(MX53_PIN_ATA_DA_2, IOMUX_CONFIG_ALT1);
gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_ATA_DA_2), 0);
gpio_set_value(IOMUX_TO_GPIO(MX53_PIN_ATA_DA_2), 1);
+ return 0;
}
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Subject: [PATCH 0/2] ** Add ext4 filesystem support inuboot **
Hi Graeme, Thanks for your inputs. Actually, the first patch [PATCH 0/2] is the cover patch containing only the description about the changes in the subsequent patches. (This patch contains information on how to test ext4 implementation) The other two patches [PATCH 1/2] and [PATCH 2/2] containing the code are properly aligned and tested using checkpatch.pl script. I think we can ignore the indentation in the cover patch. Please share your comments. Thanks Regards, Uma Shankar -- From: Graeme Russ graeme.r...@gmail.com Sent: Monday, December 12, 2011 4:42 PM To: uma.shan...@samsung.com Cc: u-boot@lists.denx.de; iqbal@samsung.com; a.manjuna...@samsung.com; goodguy@samsung.com; w...@denx.de Subject: Re: [U-Boot] Subject: [PATCH 0/2] ** Add ext4 filesystem support inuboot ** Hi Uma, On 12/12/11 21:37, uma.shan...@samsung.com wrote: Hi All, We at Samsung have implemented ext4 file system support in uboot. Please review the subsequent patches. Thanks Regards, Uma Shankar Manjunatha C Achar From: Uma Shankar uma.shan...@samsung.com Date: Mon, 12 Dec 2011 12:01:23 +0530 Subject: [PATCH 0/2] *** Add ext4 filesystem support in uboot *** *** This patch series adds support for ext4 ls,load and write features in uboot Journaling is supported for write feature. To Enable EXT4 commands, modify the board specific config file with #define CONFIG_CMD_EXT2 1 #define CONFIG_CMD_EXT4 1 Steps to test: 1. After applying the patch, ext4 specific commands can be seen in the boot loader prompt using UBOOT #help ext4load- load binary file from a Ext4 file system ext4ls - list files in a directory (default /) ext4write- create a file in ext4 formatted partition 2. To list the files in ext4 formatted partition, execute ext4ls interface dev[:part] [directory] For example: UBOOT #ext4ls mmc 0:5 /usr/lib 3. To read and load a file from an ext4 formatted partition to RAM, execute ext4load interface dev[:part] [addr] [filename] [bytes] For example: UBOOT #ext4load mmc 2:2 0x30007fc0 uImage 4. To write a file to a ext4 formatted partition. a) First load a file to RAM at a particular address for example 0x30007fc0. Now execute ext4write command ext4write interface dev[:part] [filename] [Address] [sizebytes] For example: UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120 (here 6183120 is the size of the file to be written) Note: Absolute path is required for the file to be written *** Uma Shankar (2): ext4fs ls load support ext4fs write support I notice different coding styles in the two patches - In particular, the first patch uses spaces for indentation and the second (correctly) uses tabs Can you please run the 'checkpatch' script (it in the root of the u-boot tree) on both and correct any errors and warnings Regards, Graeme Makefile |2 +- common/Makefile|1 + common/cmd_ext4.c | 388 ++ fs/Makefile|1 + fs/ext2/ext2fs.c | 303 + fs/ext4/Makefile | 51 ++ fs/ext4/crc16.c| 61 ++ fs/ext4/crc16.h| 17 + fs/ext4/ext4_common.c | 1954 fs/ext4/ext4_common.h | 61 ++ fs/ext4/ext4_journal.c | 657 fs/ext4/ext4_journal.h | 147 fs/ext4/ext4fs.c | 1252 +++ include/ext2fs.h | 177 +- include/ext4fs.h | 172 + 15 files changed, 4937 insertions(+), 307 deletions(-) create mode 100644 common/cmd_ext4.c create mode 100644 fs/ext4/Makefile create mode 100644 fs/ext4/crc16.c create mode 100644 fs/ext4/crc16.h create mode 100644 fs/ext4/ext4_common.c create mode 100644 fs/ext4/ext4_common.h create mode 100644 fs/ext4/ext4_journal.c create mode 100644 fs/ext4/ext4_journal.h create mode 100644 fs/ext4/ext4fs.c create mode 100644 include/ext4fs.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Subject: [PATCH 0/2] ** Add ext4 filesystem support inuboot **
Hi Uma, On 12/12/11 22:27, uma.shan...@samsung.com wrote: Hi Graeme, Thanks for your inputs. Actually, the first patch [PATCH 0/2] is the cover patch containing only the description about the changes in the subsequent patches. (This patch contains information on how to test ext4 implementation) The other two patches [PATCH 1/2] and [PATCH 2/2] containing the code are properly aligned and tested using checkpatch.pl script. I was referring to Patch 1/2 when I mentioned indentation using spaces - I responded to this cover letter as my comments relate to both patches I think we can ignore the indentation in the cover patch. Please share your comments. That is correct (and the cover letter is mostly auto-generated by git anyway) But please run all 'actual patches' through checkpatch - They are highly unlikely to be accepted if they have checkpatch warnings, and practically guaranteed to be rejected if they have checkpatch errors. If checkpatch generates warning and/or errors that you believe cannot be resolved, make a note of why in the patch comments (below the ---) Regards, Graeme Thanks Regards, Uma Shankar -- From: Graeme Russ graeme.r...@gmail.com Sent: Monday, December 12, 2011 4:42 PM To: uma.shan...@samsung.com Cc: u-boot@lists.denx.de; iqbal@samsung.com; a.manjuna...@samsung.com; goodguy@samsung.com; w...@denx.de Subject: Re: [U-Boot] Subject: [PATCH 0/2] ** Add ext4 filesystem support inuboot ** Hi Uma, On 12/12/11 21:37, uma.shan...@samsung.com wrote: Hi All, We at Samsung have implemented ext4 file system support in uboot. Please review the subsequent patches. Thanks Regards, Uma Shankar Manjunatha C Achar From: Uma Shankar uma.shan...@samsung.com Date: Mon, 12 Dec 2011 12:01:23 +0530 Subject: [PATCH 0/2] *** Add ext4 filesystem support in uboot *** *** This patch series adds support for ext4 ls,load and write features in uboot Journaling is supported for write feature. To Enable EXT4 commands, modify the board specific config file with #define CONFIG_CMD_EXT2 1 #define CONFIG_CMD_EXT4 1 Steps to test: 1. After applying the patch, ext4 specific commands can be seen in the boot loader prompt using UBOOT #help ext4load- load binary file from a Ext4 file system ext4ls - list files in a directory (default /) ext4write- create a file in ext4 formatted partition 2. To list the files in ext4 formatted partition, execute ext4ls interface dev[:part] [directory] For example: UBOOT #ext4ls mmc 0:5 /usr/lib 3. To read and load a file from an ext4 formatted partition to RAM, execute ext4load interface dev[:part] [addr] [filename] [bytes] For example: UBOOT #ext4load mmc 2:2 0x30007fc0 uImage 4. To write a file to a ext4 formatted partition. a) First load a file to RAM at a particular address for example 0x30007fc0. Now execute ext4write command ext4write interface dev[:part] [filename] [Address] [sizebytes] For example: UBOOT #ext4write mmc 2:2 /boot/uImage 0x30007fc0 6183120 (here 6183120 is the size of the file to be written) Note: Absolute path is required for the file to be written *** Uma Shankar (2): ext4fs ls load support ext4fs write support I notice different coding styles in the two patches - In particular, the first patch uses spaces for indentation and the second (correctly) uses tabs Can you please run the 'checkpatch' script (it in the root of the u-boot tree) on both and correct any errors and warnings Regards, Graeme Makefile |2 +- common/Makefile|1 + common/cmd_ext4.c | 388 ++ fs/Makefile|1 + fs/ext2/ext2fs.c | 303 + fs/ext4/Makefile | 51 ++ fs/ext4/crc16.c| 61 ++ fs/ext4/crc16.h| 17 + fs/ext4/ext4_common.c | 1954 fs/ext4/ext4_common.h | 61 ++ fs/ext4/ext4_journal.c | 657 fs/ext4/ext4_journal.h | 147 fs/ext4/ext4fs.c | 1252 +++ include/ext2fs.h | 177 +- include/ext4fs.h | 172 + 15 files changed, 4937 insertions(+), 307 deletions(-) create mode 100644 common/cmd_ext4.c create mode 100644 fs/ext4/Makefile create mode 100644 fs/ext4/crc16.c create mode 100644 fs/ext4/crc16.h create mode 100644 fs/ext4/ext4_common.c create mode 100644 fs/ext4/ext4_common.h create mode 100644 fs/ext4/ext4_journal.c create mode 100644 fs/ext4/ext4_journal.h create mode 100644 fs/ext4/ext4fs.c create mode 100644 include/ext4fs.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
Dear Gerlando Falauto, In message 4ee5ca38.6090...@keymile.com you wrote: if (process_var(name, nvars, vars) hdelete_r(name, htab) == 0) debug(DELETE ERROR ##\n); This is incorrect indentation. I think it's easier to read it the original way, and it should not make any difference as far as code size is concerned. The Coding Style makes an explicit exception regarding the line length for user visible strings: 83 Statements longer than 80 columns will be broken into sensible chunks, unless 84 exceeding 80 columns significantly increases readability and does not hide 85 information. Descendants are always substantially shorter than the parent and 86 are placed substantially to the right. The same applies to function headers 87 with a long argument list. However, never break user-visible strings such as 88 printk messages, because that breaks the ability to grep for them. himport_r() is getting a bit overloaded, Actually, I believe it makes no longer sense to have it called _r, as it was the original reference to the function being recursively calleable (i.e. reentrant) as opposed to other versions which were not. Has this changed? Also, for me this patch adds 500 bytes. I wonder if more of the code could made optional? Frankly, I'm surprised to hear this adds that much overhead. Actually, I can't see this increase in code size as you mention. What architecture are you referring to? In my workspace (ppc_6xx) u-boot.bin and a stripped u-boot ELF file are surprisingly unchanged in size, even with debug #defined! Don't look at file size. Use the size command and compare code / data / bss sizes. 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 As of 1992, they're called European Economic Community fries. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] env: check and apply changes on delete/destroy
Dear Gerlando Falauto, In message 4ee5ca4a.8050...@keymile.com you wrote: You could just use 'apply_cb apply' for that param I think. Absolutely. I introduced the typedef at a later stage and forgot to update it there too. Good catch, thanks! Run checkpatch, and mind the CodingStyle section about typedefs! 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 can call spirits from the vasty deep. Why so can I, or so can any man; but will they come when you do call for them? - Shakespeare, 1 King Henry IV, Act III, Scene I. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] env: make env default selective, check and apply
Dear Gerlando Falauto, In message 4ee5ca57.6070...@keymile.com you wrote: /* [re]set to the default environment */ void set_default_env(const char *s); +#ifdef CONFIG_CMD_DEFAULTENV_VARS +/* [re]set individual variables to their value in the default environment */ +int env_default_vars(int nvars, char * const vars[]); How about env_set_vars_to_default? Hmm... sounds too long to me. But if you insist... Too long, indeed. We already have set_default_env() for the whole environment, so maybe set_default_vars() for a set of variables? 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 paid too much for it, but its worth it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fs/reiserfs/reiserfs.c: Fix compiler warning
Fix:
reiserfs.c: In function 'reiserfs_mount':
reiserfs.c:360:22: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Note:
- checkpatch warnings intentionally not fixed to preserve
coding style used in the file. Otherwise it would look
ugly.
fs/reiserfs/reiserfs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/fs/reiserfs/reiserfs.c b/fs/reiserfs/reiserfs.c
index d84fb20..efab8fa 100644
--- a/fs/reiserfs/reiserfs.c
+++ b/fs/reiserfs/reiserfs.c
@@ -282,6 +282,7 @@ reiserfs_mount (unsigned part_length)
{
struct reiserfs_super_block super;
int superblock = REISERFS_DISK_OFFSET_IN_BYTES SECTOR_BITS;
+ char *cache;
if (part_length superblock + (sizeof (super) SECTOR_BITS)
|| ! reiserfs_devread (superblock, 0, sizeof (struct
reiserfs_super_block),
@@ -357,7 +358,8 @@ reiserfs_mount (unsigned part_length)
if (! block_read (sb_root_block(super), 0, INFO-blocksize, (char*) ROOT))
return 0;
- INFO-tree_depth = __le16_to_cpu(BLOCKHEAD (ROOT)-blk_level);
+ cache = ROOT;
+ INFO-tree_depth = __le16_to_cpu(BLOCKHEAD (cache)-blk_level);
#ifdef REISERDEBUG
printf (root read_in: block=%d, depth=%d\n,
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Subject: [PATCH 0/2] ** Add ext4 filesystem support in uboot **
Dear Uma Shankar, In message 54ed165ef2fa426a95951c4785717...@sisodomain.com you wrote: We at Samsung have implemented ext4 file system support in uboot. Please review the subsequent patches. Please see http://www.denx.de/wiki/U-Boot/CodingStyle and http://www.denx.de/wiki/U-Boot/Patches for some hints how to submit code. Your patches have a number of Coding Style issues. Please run them through checkpatch: WARNING: Avoid line continuations in quoted strings WARNING: do not add new typedefs WARNING: please, no spaces at the start of a line WARNING: suspect code indent for conditional statements NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or ERROR: code indent should use tabs where possible ERROR: trailing whitespace ERROR: patch seems to be corrupt (line wrapped?) etc. etc. Themost critical problem is the white space corruption (line wrapped) which causes that we cannot apply or test these patches. Please clean up and resubmit usign git send-email to avoid such white space corruptions. 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 They say, well, meybe it _is_ smelly, maybe it _is_ overcrowded, may- be it _is_ a bit like Hell would be if they shut the fires off and stabled a herd of incontinent cows there for a year, but you must admit that it is full of sheer, vibrant, dynamic _life_. - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/mpl/common/isa.c: Fix GCC 4.6 build warnings
Dear =?UTF-8?q?David=20M=C3=BCller?=, In message 1323689813-21224-1-git-send-email-d.muel...@elsoft.ch you wrote: Fix: ../common/isa.c: In function 'handle_isa_int': ../common/isa.c:385:21: warning: variable 'isr2' set but not used [-Wunused-but-set-variable] ../common/isa.c:385:16: warning: variable 'isr1' set but not used [-Wunused-but-set-variable] Signed-off-by: David Mueller d.muel...@elsoft.ch --- board/mpl/common/isa.c |6 +++--- 1 files changed, 3 insertions(+), 3 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 Even historians fail to learn from history -- they repeat the same mistakes. -- John Gill, Patterns of Force, stardate 2534.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs/reiserfs/reiserfs.c: Fix compiler warning
Dear Anatolij Gustschin, In message 1323695777-4107-1-git-send-email-ag...@denx.de you wrote: Fix: reiserfs.c: In function 'reiserfs_mount': reiserfs.c:360:22: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] Signed-off-by: Anatolij Gustschin ag...@denx.de --- Note: - checkpatch warnings intentionally not fixed to preserve coding style used in the file. Otherwise it would look ugly. fs/reiserfs/reiserfs.c |4 +++- 1 files changed, 3 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 Make it right before you make it faster. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/ti/omap2420h4/omap2420h4.c: Fix GC 4.6 build warning
Dear Wolfgang Denk, In message 1323674180-30359-1-git-send-email...@denx.de you wrote: Fix: omap2420h4.c: In function 'dram_init': omap2420h4.c:196:25: warning: variable 'cpu' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de Cc: Richard Woodruff r-woodru...@ti.com Cc: Tom Rini tr...@ti.com --- board/ti/omap2420h4/omap2420h4.c |3 +-- 1 files changed, 1 insertions(+), 2 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 Absolute: Independent, irresponsible. An absolute monarchy is one in which the sovereign does as he pleases so long as he pleases the assassins. Not many absolute monarchies are left, most of them having been replaced by limited monarchies, where the soverign's power for evil (and for good) is greatly curtailed, and by republics, which are governed by chance. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: remove broken tb0229 board
Dear Wolfgang Denk, In message 1323676699-31614-1-git-send-email...@denx.de you wrote: The tb0229 board has long been unmaintained, and is broken. Remove it. Signed-off-by: Wolfgang Denk w...@denx.de --- board/tb0229/Makefile| 47 -- board/tb0229/config.mk | 30 - board/tb0229/flash.c | 1197 -- board/tb0229/lowlevel_init.S | 70 --- board/tb0229/tb0229.c| 54 -- board/tb0229/u-boot.lds | 70 --- board/tb0229/vr4131-pci.c| 254 - boards.cfg |1 - doc/README.scrapyard |7 +- 9 files changed, 4 insertions(+), 1726 deletions(-) delete mode 100644 board/tb0229/Makefile delete mode 100644 board/tb0229/config.mk delete mode 100644 board/tb0229/flash.c delete mode 100644 board/tb0229/lowlevel_init.S delete mode 100644 board/tb0229/tb0229.c delete mode 100644 board/tb0229/u-boot.lds delete mode 100644 board/tb0229/vr4131-pci.c 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 A direct quote from the Boss: We passed over a lot of good people to get the ones we hired. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
On 12/12/2011 01:18 PM, Wolfgang Denk wrote: Dear Gerlando Falauto, I think it's easier to read it the original way, and it should not make any difference as far as code size is concerned. The Coding Style makes an explicit exception regarding the line length for user visible strings: 83 Statements longer than 80 columns will be broken into sensible chunks, unless 84 exceeding 80 columns significantly increases readability and does not hide 85 information. Descendants are always substantially shorter than the parent and 86 are placed substantially to the right. The same applies to function headers 87 with a long argument list. However, never break user-visible strings such as 88 printk messages, because that breaks the ability to grep for them. I don't understand: why are you quoting this here and now? The chunk we are referring to doesn't change a bit about the printable string. himport_r() is getting a bit overloaded, Actually, I believe it makes no longer sense to have it called _r, as it was the original reference to the function being recursively calleable (i.e. reentrant) as opposed to other versions which were not. Has this changed? Of course it hasn't. But I don't see any point in keeping this notation anyway. Also, for me this patch adds 500 bytes. I wonder if more of the code could made optional? Frankly, I'm surprised to hear this adds that much overhead. Actually, I can't see this increase in code size as you mention. What architecture are you referring to? In my workspace (ppc_6xx) u-boot.bin and a stripped u-boot ELF file are surprisingly unchanged in size, even with debug #defined! Don't look at file size. Use the size command and compare code / data / bss sizes. Yep, sorry, I'll look into that to see what part is mostly reponsible for this. Best, Gerlando ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-staging
Hello Wolfgang, please pull some patches which initially have been submitted before last merge window opened and re-based quite recently. I hope it is not too late. Thanks! The following changes since commit d798a9b5d50527713adc6309206a8d9f287593fb: common/cmd_nvedit.c: Add missing 'env save' preproc guard (2011-12-12 08:25:38 +0100) are available in the git repository at: git://git.denx.de/u-boot-staging.git ag...@denx.de Asen Dimov (3): pm9263: init serial console before relocation pm9261: init serial console before relocation pm9g45: init serial console before relocation board/ronetix/pm9261/pm9261.c | 17 - board/ronetix/pm9263/pm9263.c | 22 ++ board/ronetix/pm9g45/pm9g45.c | 16 +++- include/configs/pm9261.h |1 + include/configs/pm9263.h |1 + include/configs/pm9g45.h |1 + 6 files changed, 40 insertions(+), 18 deletions(-) Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2011.12-rc1 is out - release date Dec 23
Hi everybody, after long struggeling we finally have a -rc1. Please help testing, so we can fix the remaining issues before the release, which I decided to shift to December 23. Thanks to all who helped. 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 Real programmers don't comment their code. It was hard to write, it should be hard to understand. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
Dear Gerlando Falauto, In message 4ee603d0.5010...@keymile.com you wrote: I don't understand: why are you quoting this here and now? The chunk we are referring to doesn't change a bit about the printable string. Please use proper indentation for it, even if it exceeds the line length then - although I wonder if the string actually makes any sense or is needed / useful as is. 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 e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-staging
Dear Anatolij Gustschin, In message 20111212144152.771419ff@wker you wrote: Hello Wolfgang, please pull some patches which initially have been submitted before last merge window opened and re-based quite recently. I hope it is not too late. Thanks! The following changes since commit d798a9b5d50527713adc6309206a8d9f287593fb: common/cmd_nvedit.c: Add missing 'env save' preproc guard (2011-12-12 08:25:38 +0100) are available in the git repository at: git://git.denx.de/u-boot-staging.git ag...@denx.de Asen Dimov (3): pm9263: init serial console before relocation pm9261: init serial console before relocation pm9g45: init serial console before relocation board/ronetix/pm9261/pm9261.c | 17 - board/ronetix/pm9263/pm9263.c | 22 ++ board/ronetix/pm9g45/pm9g45.c | 16 +++- include/configs/pm9261.h |1 + include/configs/pm9263.h |1 + include/configs/pm9g45.h |1 + 6 files changed, 40 insertions(+), 18 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 Be careful what you wish for. You never know who will be listening. - Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] env: check and apply changes on delete/destroy
On 12/12/2011 02:08 PM, Wolfgang Denk wrote: Dear Gerlando Falauto, In message4ee5ca4a.8050...@keymile.com you wrote: You could just use 'apply_cb apply' for that param I think. Absolutely. I introduced the typedef at a later stage and forgot to update it there too. Good catch, thanks! Run checkpatch, and mind the CodingStyle section about typedefs! I did run checkpatch, it didn't say a word about this. What is your recommendation about typedef'ining a function pointer? I immediately suspected that using a callback function might sound like heresy, so if you have any better suggestion please put it forward before I rework this changeset for the fifth time... please. I just think having the whole, expanded signature as the type for a function-pointer parameter or local variable would just make things too long and redundant. Just off the top of my head: perhaps a struct with a single function pointer element might look better than a typedef? Thanks, Gerlando Falauto ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/mmc/mv_sdhci.c: Fix build warning
Hi Anatolij, On Thu, Dec 8, 2011 at 5:47 AM, Anatolij Gustschin ag...@denx.de wrote: Fix: mv_sdhci.c: In function 'mv_sdh_init': mv_sdhci.c:47:22: warning: the comparison will always evaluate as 'true' for the address of 'mv_sdhci_writeb' will never be NULL [-Waddress] Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Lei Wen lei...@marvell.com Cc: Andy Fleming aflem...@freescale.com --- drivers/mmc/mv_sdhci.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c index 1501974..2fe34b6 100644 --- a/drivers/mmc/mv_sdhci.c +++ b/drivers/mmc/mv_sdhci.c @@ -44,8 +44,7 @@ int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks) host-quirks = quirks; #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS memset(mv_ops, 0, sizeof(struct sdhci_ops)); - if (mv_sdhci_writeb != NULL) - mv_ops.write_b = mv_sdhci_writeb; + mv_ops.write_b = mv_sdhci_writeb; host-ops = mv_ops; #endif if (quirks SDHCI_QUIRK_REG32_RW) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Thanks for pointing it out! Acked-by: Lei Wen lei...@marvell.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc1 is out - release date Dec 23
Dear Reinhard Meyer, On 12.12.2011 14:48, Wolfgang Denk wrote: Hi everybody, after long struggeling we finally have a -rc1. Please help testing, so we can fix the remaining issues before the release, which I decided to shift to December 23. AVR32 arch is still broken due to missing http://patchwork.ozlabs.org/patch/117688/ best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] PXA: Fix building for lubbock board
Fix:
drivers/mmc/libmmc.o: In function `mmc_legacy_init':
drivers/mmc/pxa_mmc.c:565: undefined reference to `set_GPIO_mode'
drivers/mmc/pxa_mmc.c:566: undefined reference to `set_GPIO_mode'
Re-add set_GPIO_mode() which has been removed by commit
d10237d275300562bbfecbbe2f59a97cfb9dc180 (PXA: Separate
PXA2xx CPU init).
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
---
arch/arm/cpu/pxa/pxa2xx.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c
index 09e8177..42fb4fc 100644
--- a/arch/arm/cpu/pxa/pxa2xx.c
+++ b/arch/arm/cpu/pxa/pxa2xx.c
@@ -299,3 +299,28 @@ void reset_cpu(ulong ignored)
for (;;)
;
}
+
+#ifndef CONFIG_CPU_MONAHANS
+void set_GPIO_mode(int gpio_mode)
+{
+ int gpio = gpio_mode GPIO_MD_MASK_NR;
+ int fn = (gpio_mode GPIO_MD_MASK_FN) 8;
+ int val;
+
+ /* This below changes direction setting of GPIO gpio */
+ val = readl(GPDR(gpio));
+
+ if (gpio_mode GPIO_MD_MASK_DIR)
+ val |= GPIO_bit(gpio);
+ else
+ val = ~GPIO_bit(gpio);
+
+ writel(val, GPDR(gpio));
+
+ /* This below updates only AF of GPIO gpio */
+ val = readl(GAFR(gpio));
+ val = ~(0x3 (((gpio) 0xf) * 2));
+ val |= fn (((gpio) 0xf) * 2);
+ writel(val, GAFR(gpio));
+}
+#endif /* CONFIG_CPU_MONAHANS */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.12-rc1 is out - release date Dec 23
Hi everybody, in message 20111212134828.bbcd4183a...@gemini.denx.de I wrote: after long struggeling we finally have a -rc1. Note that this also means that I will accept pull requests for the next branch. 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 Single tasking: Just Say No. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] PXA: Fix building for lubbock board
Fix:
drivers/mmc/libmmc.o: In function `mmc_legacy_init':
drivers/mmc/pxa_mmc.c:565: undefined reference to `set_GPIO_mode'
drivers/mmc/pxa_mmc.c:566: undefined reference to `set_GPIO_mode'
Re-add set_GPIO_mode() which has been removed by commit
d10237d275300562bbfecbbe2f59a97cfb9dc180 (PXA: Separate
PXA2xx CPU init).
Signed-off-by: Anatolij Gustschin ag...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
---
arch/arm/cpu/pxa/pxa2xx.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c
index 09e8177..42fb4fc 100644
--- a/arch/arm/cpu/pxa/pxa2xx.c
+++ b/arch/arm/cpu/pxa/pxa2xx.c
@@ -299,3 +299,28 @@ void reset_cpu(ulong ignored)
for (;;)
;
}
+
+#ifndef CONFIG_CPU_MONAHANS
+void set_GPIO_mode(int gpio_mode)
+{
+ int gpio = gpio_mode GPIO_MD_MASK_NR;
+ int fn = (gpio_mode GPIO_MD_MASK_FN) 8;
+ int val;
+
+ /* This below changes direction setting of GPIO gpio */
+ val = readl(GPDR(gpio));
+
+ if (gpio_mode GPIO_MD_MASK_DIR)
+ val |= GPIO_bit(gpio);
+ else
+ val = ~GPIO_bit(gpio);
+
+ writel(val, GPDR(gpio));
+
+ /* This below updates only AF of GPIO gpio */
+ val = readl(GAFR(gpio));
+ val = ~(0x3 (((gpio) 0xf) * 2));
+ val |= fn (((gpio) 0xf) * 2);
+ writel(val, GAFR(gpio));
+}
+#endif /* CONFIG_CPU_MONAHANS */
NAK, this is insane and should die. I'll submit a proper patch.
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] PXA: Kill last remnants of set_GPIO_mode function
GPIO configuration shall never be done inside a driver, never. Signed-off-by: Marek Vasut marek.va...@gmail.com Cc: Anatolij Gustschin ag...@denx.de Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- board/lubbock/lubbock.c |6 ++ drivers/mmc/pxa_mmc.c |5 - 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/board/lubbock/lubbock.c b/board/lubbock/lubbock.c index 437f944..3527b38 100644 --- a/board/lubbock/lubbock.c +++ b/board/lubbock/lubbock.c @@ -28,6 +28,8 @@ #include common.h #include netdev.h #include asm/arch/pxa.h +#include asm/arch/pxa-regs.h +#include asm/io.h DECLARE_GLOBAL_DATA_PTR; @@ -47,6 +49,10 @@ int board_init (void) /* adress of boot parameters */ gd-bd-bi_boot_params = 0xa100; + /* Configure GPIO6 and GPIO8 as OUT, AF1. */ + setbits_le32(GPDR0, (1 6) | (1 8)); + clrsetbits_le32(GAFR0_L, (3 12) | (3 16), (1 12) | (1 16)); + return 0; } diff --git a/drivers/mmc/pxa_mmc.c b/drivers/mmc/pxa_mmc.c index 2b58a98..80c4445 100644 --- a/drivers/mmc/pxa_mmc.c +++ b/drivers/mmc/pxa_mmc.c @@ -560,11 +560,6 @@ mmc_legacy_init(int verbose) /* Reset device interface type */ mmc_dev.if_type = IF_TYPE_UNKNOWN; -#if defined(CONFIG_LUBBOCK) || \ - (defined(CONFIG_GUMSTIX) !defined(CONFIG_CPU_PXA27X)) - set_GPIO_mode(GPIO6_MMCCLK_MD); - set_GPIO_mode(GPIO8_MMCCS0_MD); -#endif #ifdef CONFIG_CPU_MONAHANS /* pxa3xx */ writel(readl(CKENA) | CKENA_12_MMC0 | CKENA_13_MMC1, CKENA); #else /* pxa2xx */ -- 1.7.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] mcx: support for HTKW mcx board
Hi Igor,
thanks for your comments.
On 30.11.2011 12:21, Igor Grinberg wrote:
+#if defined(CONFIG_GENERIC_MMC) defined(CONFIG_OMAP_HSMMC) \
+!defined(CONFIG_SPL_BUILD)
+int board_mmc_init(bd_t *bis)
+{
+omap_mmc_init(0);
+return 0;
return omap_mmc_init(0);
I would also define this function (weak) in some common place,
so we will not need to copy/paste it all over the boards, but
of course, it is not a blocker and I don't request this from you.
Only if you want to... :-)
Well, we can use cpu_mmc_init() for this. But what slot(s) should we
initialized in this common function? First? All?
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] mcx: support for HTKW mcx board
On Mon, Dec 12, 2011 at 8:39 AM, Ilya Yanok ya...@emcraft.com wrote:
Hi Igor,
thanks for your comments.
On 30.11.2011 12:21, Igor Grinberg wrote:
+#if defined(CONFIG_GENERIC_MMC) defined(CONFIG_OMAP_HSMMC) \
+ !defined(CONFIG_SPL_BUILD)
+int board_mmc_init(bd_t *bis)
+{
+ omap_mmc_init(0);
+ return 0;
return omap_mmc_init(0);
I would also define this function (weak) in some common place,
so we will not need to copy/paste it all over the boards, but
of course, it is not a blocker and I don't request this from you.
Only if you want to... :-)
Well, we can use cpu_mmc_init() for this. But what slot(s) should we
initialized in this common function? First? All?
The problem we have here is that board_mmc_init and cpu_mmc_init are
already both weak and you can't replace one weak function with another
weak function (or if you can, you need to play linker games). I had
given this a quick stab but not reported back since I hadn't finished
the rest of the related task (SPL and MMC support for am335x).
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
Hi Gerlando,
On Mon, Dec 12, 2011 at 1:32 AM, Gerlando Falauto
gerlando.fala...@keymile.com wrote:
On 12/07/2011 11:02 PM, Simon Glass wrote:
[...]
/*
- * Set a new environment variable,
- * or replace or delete an existing one.
+ * Performs consistency checking before setting, replacing,
+ * or deleting an environment variable, then (if successful)
+ * apply the changes to internals so to make them effective.
+ * Code for this function was taken out of _do_env_set(),
+ * which now calls it.
+ * Also called as a callback function by himport_r().
+ * Returns 0 in case of success, 1 in case of failure.
+ * When (flag H_FORCE) is set, force overwriting of
+ * write-once variables.
can you word-wrap that to 72 columns perhaps?
Sorry, I am little confused now. What is the maximum line length?
What I meant was that it seems like it you could put more characters
on each line, and then would take up less vertical space. You could
also use the doxygen @param formal to make it quicker for people to
read.
[...]
+/* Check whether variable name is amongst vars[] */
+static int process_var(const char *name, int nvars, char * const vars[])
+{
+ int i = 0;
blank line here.
Thanks, I didn't know about this.
Can part of this function be #ifdefed to reduce code
size when the feature is not required?
Uhm, I don't think so. This would be a common feature for selectively
importing setting back to default. Unless we want to #ifdef both of them.
Personally, I would #ifdef neither.
OK, just a thought, it is up to you.
[...]
+ if (!process_var(name, nvars, vars))
+ continue;
if (hdelete_r(name, htab) == 0)
debug(DELETE ERROR
##\n);
perhaps:
if (process_var(name, nvars, vars)
hdelete_r(name, htab) == 0)
debug(DELETE ERROR ##\n);
I think it's easier to read it the original way, and it should not make any
difference as far as code size is concerned.
OK
himport_r() is getting a bit overloaded,
Actually, I believe it makes no longer sense to have it called _r, as it
was the original reference to the function being recursively calleable (i.e.
reentrant) as opposed to other versions which were not.
OK I'm not sure about that.
and it's a shame but I can't
think of an easy way to refactor it to reduce the number of args. In a
way you are adding a processing option and so you could put the three
extra args in a structure and pass a pointer to it (or NULL to skip
this feature). Not sure though...
Can't think of any other way either, except maybe renaming it and
re-implementing the shorter version as a wrapper around the newly named
function. I had already done that, but there would be very few places where
the old syntax would be kept, so it just didn't make much sense.
Packaging up a lot of zero arguments to a function does chew up code space.
Also, for me this patch adds 500 bytes. I wonder if more of the code
could made optional?
Frankly, I'm surprised to hear this adds that much overhead.
Actually, I can't see this increase in code size as you mention.
What architecture are you referring to?
ARMv7. Ideally if your feature is optional it shouldn't add much size
when it is turned off.
In my workspace (ppc_6xx) u-boot.bin and a stripped u-boot ELF file are
surprisingly unchanged in size, even with debug #defined!
Only place I can experience such growth is within unstripped u-boot ELF,
which I believe shouldn't really matter... or should it?
As Wolfgang says, use your tool chain's size tool for this.
Regards,
Simon
Best,
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
On 12/10/2011 03:42 PM, Linus Walleij wrote:
...
Since this was so convenient I made a patch to attach a DTB
the same way which was floated on devicetree-discuss:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg07256.html
Nico didn't like that:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg06828.html
Alas, I'm still using that patch though. For systems where I cannot
influence the boot loader it's easiest, since I just add another
config snippet when I want to run them with DT:
scripts/config --file .config \
--enable USE_OF \
--enable ARM_APPENDED_DTB \
--enable ARM_ATAG_DTB_COMPAT \
--enable PROC_DEVICETREE \
--set-str ARM_APPENDED_DTB_FILE my-device-tree.dtb
Jut as an FYI, there's also:
git://git.secretlab.ca/git/linux-2.6 devicetree/test
fbae2702ae21ad8d1de5f135647c30b250782060 Build a uImage with dtb
already appended.
I tend to use this all the time for device-tree.
I find this significantly easier than using U-Boot's
pass-an-FDT-to-the-kernel feature, because right now half the time I'm
passing an FDT and half not, and making U-Boot's script support either
option automatically isn't something I really want to get into when I
can simply make uImage or make uImage-dtb.tegra-${board} to select
which option I want when building the kernel.
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] tegra: Add tegra keyboard support
On 12/08/2011 02:56 PM, Simon Glass wrote: Hi Stephen, On Wed, Dec 7, 2011 at 2:02 PM, Stephen Warren swar...@nvidia.com wrote: On 12/02/2011 07:57 PM, Simon Glass wrote: Add support for internal matrix keyboard controller for Nvidia Tegra platforms. This driver uses the fdt decode function to obtain its key codes. ... From a purely HW perspective, the only thing that exists is a single mapping from (row, col) to keycode. I believe that's all the KBC driver's binding should define. I'll amend that slightly: keyboards commonly implement the Fn key internally in HW, since it causes keys to emit completely different raw codes, so I can see this driver wanting both keycode-plain and keycode-fn. However, keycode-shift and keycode-ctrl are purely SW concepts. As such, they shouldn't be part of the KBC's own mapping table. Witness how the kernel's Tegra KBC driver only contains the plain and fn tables (albeit merged into a single array for ease of use), and the input core is what interpets e.g. KEY_LEFTSHIFT as a modifier. Yes, certainly for ctrl I agree that we can simply calculate it. Although interestingly the other two keyboard drivers in U-Boot use the same approach as here, so maybe there is a fish hook somewhere (I have not written this code before). So specifically what I'd like to see changed in this binding is: a) We need binding documentation for the Tegra KBC binding, in the same style as found in the kernel's Documentation/devicetree/bindings. OK will do - should I just put that in the cover letter? There is no such file in U-Boot. Right now, the canonical location for binding documentation appears to be the kernel's Documentation/devicetree/bindings/ directory. Perhaps we should add the documentation there first? At least, we should post the binding document in the standard kernel style to the linux-input and devicetree-discuss mailing lists even if it doesn't get immediately checked in. I recall from the kernel summit that Grant Likely was thinking of creating an outside-the-kernel repository for either/both of binding documentation and .dts/.dtsi. I'm not sure if any progress has been made there yet. b) The Tegra KBC binding should include only the keycode-plain and keycode-fn properties; nothing to do with shift/ctrl/alt/ (Well, also any standardized properties such as compatible, reg, interrupts). OK. I'm not sure how I specify what happens when you press shift... c) We need binding documentation for the data that is/could-be common across multiple keyboards: i.e. what does each key code value represent; which is KEY_A, KEY_LEFTSHIFT, etc.? These values should be common across (1) all keyboards (2) some standardized meaning for DT that can be used by U-Boot, the Linux kernel, etc. Perhaps there is already such a standard? I'm not aware of it. I looked around for any kind of existing keyboard mapping binding, and I couldn't find anything. I did find a Samsung matrix KBC binding in the kernel (Documentation/devicetree/bindings/input/samsung-keypad.txt) which is conceptually at the same level as having a plain table, although no fn table in their case. I prefer the proposed Tegra binding's table approach rather than having a separate node per key myself. d) Shift/Ctrl/Alt/... modifier mapping tables should be specified by a separate binding that can be common to any/all keyboards (probably the same document as (b) above). The input to this table should be the raw codes from keycode-plain/keycode-fn. The output would be the values sent to whatever consumes keyboard input. The naming of these properties should make it obvious that it's something not specific to Tegra's KBC, and SW oriented. Perhaps something semantically similar to loadkeys' or xkbcomp's input, although I haven't looked at those in detail. While I agree this would be nice, it involves adding a layer of software into U-Boot which doesn't currently exist (converting key codes + modifies into ASCII codes). It doesn't have to be a separate lyaer in U-Boot; the binding just has to be defined in a way that doesn't tie it to the Tegra KBC driver, so it can be re-used. In other words: Tegra KBC's binding defines: nvidia,keycode-plain nvidia,keycode-fn (these should output shift and ctrl keycodes for later processing) Generic key mapping binding defines: modifier-mapping-shift modifier-mapping-ctrl ... which take as input the values generated by keycode-plain/keycode-fn and output the rewritten keycodes. (the difference here is that the input to those tables is the output from the nvidia,keycode-foo tables, rather than the raw HW keycodes) As far as implementation goes, all of that can be handled inside the Tegra KBC driver for now, so no new layer is required. I think we should run this plan, and both binding definitions past the linux-input mailing list; people there will be far more aware of any previous work in this area, whether this plan makes
Re: [U-Boot] [PATCH 4/6] tegra: Add tegra keyboard support
Hi Stephen, On Mon, Dec 12, 2011 at 10:00 AM, Stephen Warren swar...@nvidia.com wrote: On 12/08/2011 02:56 PM, Simon Glass wrote: Hi Stephen, On Wed, Dec 7, 2011 at 2:02 PM, Stephen Warren swar...@nvidia.com wrote: On 12/02/2011 07:57 PM, Simon Glass wrote: Add support for internal matrix keyboard controller for Nvidia Tegra platforms. This driver uses the fdt decode function to obtain its key codes. ... From a purely HW perspective, the only thing that exists is a single mapping from (row, col) to keycode. I believe that's all the KBC driver's binding should define. I'll amend that slightly: keyboards commonly implement the Fn key internally in HW, since it causes keys to emit completely different raw codes, so I can see this driver wanting both keycode-plain and keycode-fn. However, keycode-shift and keycode-ctrl are purely SW concepts. As such, they shouldn't be part of the KBC's own mapping table. Witness how the kernel's Tegra KBC driver only contains the plain and fn tables (albeit merged into a single array for ease of use), and the input core is what interpets e.g. KEY_LEFTSHIFT as a modifier. Yes, certainly for ctrl I agree that we can simply calculate it. Although interestingly the other two keyboard drivers in U-Boot use the same approach as here, so maybe there is a fish hook somewhere (I have not written this code before). So specifically what I'd like to see changed in this binding is: a) We need binding documentation for the Tegra KBC binding, in the same style as found in the kernel's Documentation/devicetree/bindings. OK will do - should I just put that in the cover letter? There is no such file in U-Boot. Right now, the canonical location for binding documentation appears to be the kernel's Documentation/devicetree/bindings/ directory. Perhaps we should add the documentation there first? At least, we should post the binding document in the standard kernel style to the linux-input and devicetree-discuss mailing lists even if it doesn't get immediately checked in. I recall from the kernel summit that Grant Likely was thinking of creating an outside-the-kernel repository for either/both of binding documentation and .dts/.dtsi. I'm not sure if any progress has been made there yet. Not enough that it is done, but I believe it is happening. b) The Tegra KBC binding should include only the keycode-plain and keycode-fn properties; nothing to do with shift/ctrl/alt/ (Well, also any standardized properties such as compatible, reg, interrupts). OK. I'm not sure how I specify what happens when you press shift... c) We need binding documentation for the data that is/could-be common across multiple keyboards: i.e. what does each key code value represent; which is KEY_A, KEY_LEFTSHIFT, etc.? These values should be common across (1) all keyboards (2) some standardized meaning for DT that can be used by U-Boot, the Linux kernel, etc. Perhaps there is already such a standard? I'm not aware of it. I looked around for any kind of existing keyboard mapping binding, and I couldn't find anything. I did find a Samsung matrix KBC binding in the kernel (Documentation/devicetree/bindings/input/samsung-keypad.txt) which is conceptually at the same level as having a plain table, although no fn table in their case. I prefer the proposed Tegra binding's table approach rather than having a separate node per key myself. d) Shift/Ctrl/Alt/... modifier mapping tables should be specified by a separate binding that can be common to any/all keyboards (probably the same document as (b) above). The input to this table should be the raw codes from keycode-plain/keycode-fn. The output would be the values sent to whatever consumes keyboard input. The naming of these properties should make it obvious that it's something not specific to Tegra's KBC, and SW oriented. Perhaps something semantically similar to loadkeys' or xkbcomp's input, although I haven't looked at those in detail. While I agree this would be nice, it involves adding a layer of software into U-Boot which doesn't currently exist (converting key codes + modifies into ASCII codes). It doesn't have to be a separate lyaer in U-Boot; the binding just has to be defined in a way that doesn't tie it to the Tegra KBC driver, so it can be re-used. In other words: Tegra KBC's binding defines: nvidia,keycode-plain nvidia,keycode-fn (these should output shift and ctrl keycodes for later processing) Generic key mapping binding defines: modifier-mapping-shift modifier-mapping-ctrl ... which take as input the values generated by keycode-plain/keycode-fn and output the rewritten keycodes. (the difference here is that the input to those tables is the output from the nvidia,keycode-foo tables, rather than the raw HW keycodes) I'm not sure this passes the 'simple' test. But OK. If we limit it to characters 128 then we can avoid doubling the size of each mapping. As
Re: [U-Boot] [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports
On 12/08/2011 02:10 PM, Simon Glass wrote:
Hi Stephen,
On Wed, Dec 7, 2011 at 3:36 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/06/2011 02:09 PM, Simon Glass wrote:
On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/05/2011 05:55 PM, Simon Glass wrote:
On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
This adds peripheral IDs and timing information to the USB part of the
device tree for U-Boot.
The peripheral IDs provide easy access to clock registers. We will
likely
remove this in favor of a full clock tree when it is available in the
kernel (but probably still retain the peripheral ID, just move it into
a clock node).
The USB timing information does apparently vary between boards
sometimes,
so is include in the fdt for convenience.
usb@c500 {
compatible = nvidia,tegra20-ehci, usb-ehci;
reg = 0xc500 0x4000;
interrupts = 52 ;
phy_type = utmi;
+ periph-id = 22; // PERIPH_ID_USBD
Given this is a temporary U-Boot-specific solution, can the property be
named u-boot,periph-id so it's obvious that when writing a .dts for the
kernel only, you don't care about this value.
ok. I suggest the kernel does something similar.
The kernel will use the standardized clock bindings once they're ready
and we convert Tegra over to use them. The kernel is extremely unlikely
to ever use periph-id or u-boot,periph-id.
What is the time frame on this working be completed and merged?
Sorry, I have no idea. I've been focusing on other subsystems (pinmux,
audio) and haven't been following the clock stuff at all. Hopefully
someone will start driving Tegra kernel towards common clock soon, but I
don't think exactly who and when has been nailed down yet.
Right now, the kernel's clock driver contains a mapping table from
device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
the kernel USB driver to work without any explicit periph-id or similar
DT property.
Where does tegra-ehci.2 come from? I don't see that in the fdt.
Pre-DT, everything was instantiated from platform devices. Each one had
a name (tegra-ehci) and an instance number (2), which concatenate to
tegra-ehci.2. All the clocks (and I think other resources like
regulators) in the kernel were marked as being for use by a particular
device name. For example in arch/arm/mach-tegra/tegra2_clocks.c:
static struct clk tegra_list_clks[] = {
...
PERIPH_CLK(usb3, tegra-ehci.2, ...),
With DT, the device names typically don't follow this format (in this
case, it'd be something more like /usb@c5008000). However, this
prevented the clock lookups by device name from working, so a temporary
scheme was put in place to keep the same device names. This is driven by
AUXDATA, for example in arch/arm/mach-tegra/board-dt.c:
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
...
// compatible, unit address, device name
OF_DEV_AUXDATA(nvidia,tegra20-ehci, TEGRA_USB3_BASE, tegra-ehci.2,
This means that any device with the given compatible property value, the
given unit address will be named accordingly.
This allows the existing clock/regulator lookups to work unmodified.
Once DT bindings are in place for clocks, regulators, etc., the clock
tables can be derived from DT, phandles will be used to match clocks and
devices rather than device names, and the AUXDATA table can go away.
The equivalent in U-Boot would be a table that maps from driver type
(e.g. COMPAT_NVIDIA_TEGRA20_USB or perhaps NVIDIA_TEGRA20_USB?) and
address to periph id. Again, once the clock bindings are complete and
the nodes present in the .dts file, that mapping table can be removed
and everything will work based on phandles.
I'd like to point out here that everything is in a pretty big state of
flux/development, since DT support for ARM is new. Temporary workarounds
like AUXDATA allow us to make as much work as possible using device
tree, but without having to put temporary nodes/properties into the .dts
files themselves. That way, the DT bindings will only ever get added to
in a compatible fashion, rather than going through multiple incompatible
sets of requirements.
Gosh.
I have to say that I feel that peripheral IDs are the best solution
for Tegra U-Boot until everything is worked out in the kernel.
The problem here is that it requires the DT to change incompatibly
later; it adds a property to the DT now that will be at best
meaningless/unused in the future.
If we simply don't add anything to the DT now, there's nothing to remove
from the DT later. Newer U-Boots might require additional information in
the DT (i.e. perhaps rely on full clock bindings) but won't deprecate
any existing fields.
We can't rely on phandles since they don't exist without an fdt,
unless we mandate that everyone
Re: [U-Boot] [PATCH 10/14] tegra: usb: Add support for USB peripheral
On 12/08/2011 02:24 PM, Simon Glass wrote: On Wed, Dec 7, 2011 at 3:46 PM, Stephen Warren swar...@nvidia.com wrote: On 12/06/2011 02:23 PM, Simon Glass wrote: ... I think the best implementation would be to enumerate everything solely based on compatible flags, and allowing usb start to accept either an alias name (which would be fixed) or a DT unit address or node name (which would be fixed) or a controller index (which might vary based on enumeration order) to select the controller. The next best implementation would be to enumerate solely based on compatible flags, then sort the list based on alias, thus allowing alias to cause a static order. However, enumerating based on alias, then enumerating based on compatible flags and adding any missing nodes would be fine. Well ok. Since this is basically a small *addition* to the code (scanning things that don't have an alias), and will have no effect with the device tree as included in this series, I would like to do this as a follow-on patch after the series. I hope you can live with that also? I suppose it'll have to do. It's totally the wrong way to go about it though, and will provide a bad example that'll probably end up proliferating itself through the code since it's the first example. In other words rather than: Now: Scan /aliases for USB, add then all. Later: Scan device nodes for any that weren't in /aliases, add them all I'd prefer to see: Now: Scan /aliases for USB, add then all. Later: Remove all the /aliases scanning code, fix the code to scan all child nodes of the SoC node, find all nodes matching the USB compatible flag, add them all. While adding a USB controller, check the /alias node and honor any alias there if there is one. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] tegra: Add tegra keyboard support
On 12/12/2011 11:10 AM, Simon Glass wrote: On Mon, Dec 12, 2011 at 10:00 AM, Stephen Warren swar...@nvidia.com wrote: On 12/08/2011 02:56 PM, Simon Glass wrote: ... I'd like to ask for comments in linux-input in case they have any other ideas, e.g. whether a set of separately documented modifier mapping properties makes sense. If not, I suppose the following set of properties would suffice: nvidia,keycode-plain nvidia,keycode-fn u-boot,keycode-shift u-boot,keycode-ctrl (although the last two seem to want both nvidia, and u-boot, prefixes) OK. Since this seems to be a kernel issue and Nvidia-specific can I ask if you can please send this email? I will wait for confirmation that this is OK before going further. OK, I'll send the email. I would like to point out though that this is neither a kernel issue nor NVIDIA-specific: It's a device tree issue dealing with how to best represent certain HW features, and it will apply equally to any HW that has a keyboard with modifier keys; essentially all of them. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix compilation warnings when building eNET
On Sat, Dec 10, 2011 at 2:42 AM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Vadim,
Oops, dropped the ML...
On Dec 10, 2011 9:20 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Vadim,
On Dec 10, 2011 12:14 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Vadim,
On Dec 10, 2011 12:08 PM, Vadim Bendebury vben...@chromium.org
wrote:
On Fri, Dec 9, 2011 at 3:57 PM, Graeme Russ graeme.r...@gmail.com
wrote:
Hi Vadim,
On Dec 10, 2011 10:31 AM, Vadim Bendebury vben...@chromium.org
wrote:
There have been a couple of unused variable cases, causing
compilation
warnings when building the eNET target.
While the board/eNET/eNET.c:last_stage_init() case seems a
leftover
from a quick edit, the
arch/x86/cpu/sc520/sc520_timer.c:sc520_udelay()
seems to actually require accessing the registers discarding the
values.
Thanks for picking this up, I've been a bit preoccupie lately.
I'll need to look a bit more closely, but there should be no need
for such trickery...
Regards,
Graeme
Hi Graeme, thank you for a quick response.
Do you mean that there is no need to read the registers before the
actual udelay functionality or do you have another way of pacifying
the compiler in mind?
On closer inspection, I can't think of a better way
Acked-by: Graeme Russ graeme.r...@gmail.com
Sorry, bit I just had a closer look at this and after reading the
datasheet I've come to the realization that the udelay function is broken -
not badly, but it can timeout up to 1ms early.
The read of swtmrmilli reads the current value of the millisecond timer,
latches the value of the internal microsecond timer and resets the
millisecond timer to zero
The read of swtmrmicro reads the latched microsecond value
The code assumes that reading swtmrmicro resets the microsecond counter,
which it does not. So if the internal microsecond timer is, say, 900 then
udelay(500) for example will return without any delay at all
I need to fix this, but cannot do so any time soon...
I have no objection to the compiler warning fix, but is there any point in
applying a cosmetic fix to broken code?
I'm not near my dev PC so the formatting is all wrong, but this should fix
the bug and the compiler warning:
void sc520_udelay(unsigned long usec)
{
int m;
long u;
long start_us;
/* Reset millisecond counter */
m = readw(sc520_mmcr-swtmrmilli);
m = 0;
Looks reasonable, not much difference from the original submission IMO.
The important thing is that there should be no compilation warnings
allowed, as if there are a few 'legitimate' ones, it becomes easy to
let the illegitimate ones to slip through :P
cheers,
/vb
/* Read initial microsecond count */
start_us = readw(sc520_mmcr-swtmrmicro);
do {
m += readw(sc520_mmcr-swtmrmilli);
u = readw(sc520_mmcr-swtmrmicro) + (m * 1000);
} while ((u - start_us) usec);
}
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot v2011.12-rc1 hang on pandaboard
Hello, I'm trying to boot the current version of u-boot (both the MLO and u-boot.img) on the pandaboard 4430. However, it always hangs up right after Using default environment, and before Hit any key to stop autoboot. I bisected the problem down to commit 9792987721c7980453fe6447c3fa6593b44f8458; if I revert that USB commit, then the boot proceeds as normal. I can't say I quite understand why this is a problem for the Panda, but aside from reverting the commit, does anyone have a suggestion for fixing this? Thanks, Chris Lalancette ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5 v2] mtd/nand: remove CONFIG_SYS_NAND_ONFI_DETECTION to enable ONFI detection
On 12/12/2011 03:49 AM, Shengzhou Liu wrote: remove CONFIG_SYS_NAND_ONFI_DETECTION to enable ONFI detection. Signed-off-by: Shengzhou Liu shengzhou@freescale.com Why? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/14] tegra: usb: Add support for USB peripheral
Hi Stephen, On Mon, Dec 12, 2011 at 10:18 AM, Stephen Warren swar...@nvidia.com wrote: On 12/08/2011 02:24 PM, Simon Glass wrote: On Wed, Dec 7, 2011 at 3:46 PM, Stephen Warren swar...@nvidia.com wrote: On 12/06/2011 02:23 PM, Simon Glass wrote: ... I think the best implementation would be to enumerate everything solely based on compatible flags, and allowing usb start to accept either an alias name (which would be fixed) or a DT unit address or node name (which would be fixed) or a controller index (which might vary based on enumeration order) to select the controller. The next best implementation would be to enumerate solely based on compatible flags, then sort the list based on alias, thus allowing alias to cause a static order. However, enumerating based on alias, then enumerating based on compatible flags and adding any missing nodes would be fine. Well ok. Since this is basically a small *addition* to the code (scanning things that don't have an alias), and will have no effect with the device tree as included in this series, I would like to do this as a follow-on patch after the series. I hope you can live with that also? I suppose it'll have to do. It's totally the wrong way to go about it though, and will provide a bad example that'll probably end up proliferating itself through the code since it's the first example. In other words rather than: Now: Scan /aliases for USB, add then all. Later: Scan device nodes for any that weren't in /aliases, add them all I'd prefer to see: Now: Scan /aliases for USB, add then all. Later: Remove all the /aliases scanning code, fix the code to scan all child nodes of the SoC node, find all nodes matching the USB compatible flag, add them all. While adding a USB controller, check the /alias node and honor any alias there if there is one. OK, perhaps I am thinking too closely about an efficient algorithm as separate from the required function. This patch series does the 'Now' but, and the 'Later' bit can be done as you say I think. Issues that come include someone having an alias for port 2 but not 1, and having to detect this and move things down at the end. I will need to think about support in fdtdec to make this easy. That's why I want to do it later as this patch series is already large and we are well aware of its limitations in several areas (e.g. there is no way to use port 1 in U-Boot yet). Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports
Hi Stephen,
On Mon, Dec 12, 2011 at 10:13 AM, Stephen Warren swar...@nvidia.com wrote:
On 12/08/2011 02:10 PM, Simon Glass wrote:
Hi Stephen,
On Wed, Dec 7, 2011 at 3:36 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/06/2011 02:09 PM, Simon Glass wrote:
On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren swar...@nvidia.com wrote:
On 12/05/2011 05:55 PM, Simon Glass wrote:
On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren swar...@nvidia.com
wrote:
On 12/02/2011 07:11 PM, Simon Glass wrote:
This adds peripheral IDs and timing information to the USB part of the
device tree for U-Boot.
The peripheral IDs provide easy access to clock registers. We will
likely
remove this in favor of a full clock tree when it is available in the
kernel (but probably still retain the peripheral ID, just move it into
a clock node).
The USB timing information does apparently vary between boards
sometimes,
so is include in the fdt for convenience.
usb@c500 {
compatible = nvidia,tegra20-ehci, usb-ehci;
reg = 0xc500 0x4000;
interrupts = 52 ;
phy_type = utmi;
+ periph-id = 22; // PERIPH_ID_USBD
Given this is a temporary U-Boot-specific solution, can the property be
named u-boot,periph-id so it's obvious that when writing a .dts for the
kernel only, you don't care about this value.
ok. I suggest the kernel does something similar.
The kernel will use the standardized clock bindings once they're ready
and we convert Tegra over to use them. The kernel is extremely unlikely
to ever use periph-id or u-boot,periph-id.
What is the time frame on this working be completed and merged?
Sorry, I have no idea. I've been focusing on other subsystems (pinmux,
audio) and haven't been following the clock stuff at all. Hopefully
someone will start driving Tegra kernel towards common clock soon, but I
don't think exactly who and when has been nailed down yet.
Right now, the kernel's clock driver contains a mapping table from
device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
the kernel USB driver to work without any explicit periph-id or similar
DT property.
Where does tegra-ehci.2 come from? I don't see that in the fdt.
Pre-DT, everything was instantiated from platform devices. Each one had
a name (tegra-ehci) and an instance number (2), which concatenate to
tegra-ehci.2. All the clocks (and I think other resources like
regulators) in the kernel were marked as being for use by a particular
device name. For example in arch/arm/mach-tegra/tegra2_clocks.c:
static struct clk tegra_list_clks[] = {
...
PERIPH_CLK(usb3, tegra-ehci.2, ...),
With DT, the device names typically don't follow this format (in this
case, it'd be something more like /usb@c5008000). However, this
prevented the clock lookups by device name from working, so a temporary
scheme was put in place to keep the same device names. This is driven by
AUXDATA, for example in arch/arm/mach-tegra/board-dt.c:
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
...
// compatible, unit address, device name
OF_DEV_AUXDATA(nvidia,tegra20-ehci, TEGRA_USB3_BASE, tegra-ehci.2,
This means that any device with the given compatible property value, the
given unit address will be named accordingly.
This allows the existing clock/regulator lookups to work unmodified.
Once DT bindings are in place for clocks, regulators, etc., the clock
tables can be derived from DT, phandles will be used to match clocks and
devices rather than device names, and the AUXDATA table can go away.
The equivalent in U-Boot would be a table that maps from driver type
(e.g. COMPAT_NVIDIA_TEGRA20_USB or perhaps NVIDIA_TEGRA20_USB?) and
address to periph id. Again, once the clock bindings are complete and
the nodes present in the .dts file, that mapping table can be removed
and everything will work based on phandles.
I'd like to point out here that everything is in a pretty big state of
flux/development, since DT support for ARM is new. Temporary workarounds
like AUXDATA allow us to make as much work as possible using device
tree, but without having to put temporary nodes/properties into the .dts
files themselves. That way, the DT bindings will only ever get added to
in a compatible fashion, rather than going through multiple incompatible
sets of requirements.
Gosh.
I have to say that I feel that peripheral IDs are the best solution
for Tegra U-Boot until everything is worked out in the kernel.
The problem here is that it requires the DT to change incompatibly
later; it adds a property to the DT now that will be at best
meaningless/unused in the future.
If we simply don't add anything to the DT now, there's nothing to remove
from the DT later. Newer U-Boots might require additional information in
the DT (i.e. perhaps rely on full clock bindings) but won't deprecate
any existing fields.
I
Re: [U-Boot] [PATCH v2 2/3] env: check and apply changes on delete/destroy
Dear Gerlando Falauto, In message 4ee60729.4020...@keymile.com you wrote: Run checkpatch, and mind the CodingStyle section about typedefs! I did run checkpatch, it didn't say a word about this. If you add new tyedef's, it will complain. What is your recommendation about typedef'ining a function pointer? I immediately suspected that using a callback function might sound like heresy, so if you have any better suggestion please put it forward before I rework this changeset for the fifth time... please. Sorry, I'm in the middle of -rc1 release work and testing, and also right in the final steps of releasing the next version of our ELDK (v5.1). Plus a few other tasks, including trips to customers. I don't have time for a thorough review now. I understand this is very bad for you, but I cannot change it. I just think having the whole, expanded signature as the type for a function-pointer parameter or local variable would just make things too long and redundant. Hm... probbaly. Just off the top of my head: perhaps a struct with a single function pointer element might look better than a typedef? I'm not convinced. I'd have to see the code, and compare. But to do so, I'd need a bit of time... 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 A supercomputer is a machine that runs an endless loop in 2 seconds. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf in uboot
Hi,
On Sun, Dec 11, 2011 at 11:51 PM, siddharth baisane
nov15twenty...@gmail.com wrote:
hi,
I am trying to print statement in uboot.
but whenever I add *printf *statement board hangs.
For example in *u-boot/lib_arm/board.c* i added prinf statement and board
hags.
void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
unsigned long addr;
#endif
*printf(armboot starts\n);*
/* Pointer is writable since we allocated a register for it */
gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
/* compiler optimization barrier needed for GCC = 3.4 */
__asm__ __volatile__(: : :memory);
memset ((void*)gd, 0, sizeof (gd_t));
gd-bd = (bd_t*)((char*)gd - sizeof(bd_t));
memset (gd-bd, 0, sizeof (bd_t));
gd-flags |= GD_FLG_RELOC;
monitor_flash_len = _bss_start - _armboot_start;
You can use the CONFIG_PRE_CONSOLE_BUFFER feature to support printf()
prior to console_init_f().
Regards,
Simon
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools/setlocalversion: Update from the Linux Kernel
Several bugfixes have occurred upstream since this script was imported
into U-Boot.
In particular, the script currently in U-Boot does not correctly decode
the localversion for commit f8bbb4dad0e9d91b7a51d6cc54dcf66d142f50fe,
because git name-rev --tags HEAD gives this:
HEAD tags/v2011.12-rc1~30^2
Then this regex does not match because of the trailing '^2':
grep -E '^HEAD[[:space:]]+(.*~[0-9]*|undefined)$'
The kernel has a bit of extra support for CONFIG_LOCALVERSION set up in
a .config file which is unnecessary in U-Boot, so it isn't exactly
identical, but it is very close to the version in Linux v3.2-rc4.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
tools/setlocalversion | 138 -
1 files changed, 113 insertions(+), 25 deletions(-)
diff --git a/tools/setlocalversion b/tools/setlocalversion
index e11f54f..70ab70d 100755
--- a/tools/setlocalversion
+++ b/tools/setlocalversion
@@ -1,40 +1,128 @@
#!/bin/sh
-# Print additional version information for non-release trees.
+#
+# This scripts adds local version information from the version
+# control systems git, mercurial (hg) and subversion (svn).
+#
+# It was originally copied from the Linux kernel v3.2.0-rc4 and modified
+# to support the U-Boot build-system.
+#
usage() {
- echo Usage: $0 [srctree] 2
+ echo Usage: $0 [--save-scmversion] [srctree] 2
exit 1
}
-cd ${1:-.} || usage
+scm_only=false
+srctree=.
+if test $1 = --save-scmversion; then
+ scm_only=true
+ shift
+fi
+if test $# -gt 0; then
+ srctree=$1
+ shift
+fi
+if test $# -gt 0 -o ! -d $srctree; then
+ usage
+fi
+
+scm_version()
+{
+ local short
+ short=false
+
+ cd $srctree
+ if test -e .scmversion; then
+ cat .scmversion
+ return
+ fi
+ if test $1 = --short; then
+ short=true
+ fi
+
+ # Check for git and a git repo.
+ if test -e .git head=`git rev-parse --verify --short HEAD
2/dev/null`; then
+
+ # If we are at a tagged commit (like v2.6.30-rc6), we ignore
+ # it, because this version is defined in the top level Makefile.
+ if [ -z `git describe --exact-match 2/dev/null` ]; then
+
+ # If only the short version is requested, don't bother
+ # running further git commands
+ if $short; then
+ echo +
+ return
+ fi
+ # If we are past a tagged commit (like
+ # v2.6.30-rc5-302-g72357d5), we pretty print it.
+ if atag=`git describe 2/dev/null`; then
+ echo $atag | awk -F- '{printf(-%05d-%s,
$(NF-1),$(NF))}'
-# Check for git and a git repo.
-if head=`git rev-parse --verify HEAD 2/dev/null`; then
- # Do we have an untagged version?
- if git name-rev --tags HEAD | \
- grep -E '^HEAD[[:space:]]+(.*~[0-9]*|undefined)$' /dev/null; then
- (git describe || git describe --tags || git describe --all
--long) \
- 2/dev/null | awk -F- '{printf(-%05d-%s,
$(NF-1),$(NF))}'
+ # If we don't have a tag at all we print -g{commitish}.
+ else
+ printf '%s%s' -g $head
+ fi
+ fi
+
+ # Is this git on svn?
+ if git config --get svn-remote.svn.url /dev/null; then
+ printf -- '-svn%s' `git svn find-rev $head`
+ fi
+
+ # Update index only on r/w media
+ [ -w . ] git update-index --refresh --unmerged /dev/null
+
+ # Check for uncommitted changes
+ if git diff-index --name-only HEAD | grep -v ^scripts/package
\
+ | read dummy; then
+ printf '%s' -dirty
+ fi
+
+ # All done with git
+ return
fi
- # Are there uncommitted changes?
- git update-index --refresh --unmerged /dev/null
- if git diff-index --name-only HEAD | grep -v ^scripts/package \
- | read dummy; then
- printf '%s' -dirty
+ # Check for mercurial and a mercurial repo.
+ if test -d .hg hgid=`hg id 2/dev/null`; then
+ # Do we have an tagged version? If so, latesttagdistance == 1
+ if [ `hg log -r . --template '{latesttagdistance}'` == 1 ];
then
+ id=`hg log -r . --template '{latesttag}'`
+ printf '%s%s' -hg $id
+ else
+ tag=`printf '%s' $hgid | cut -d' ' -f2`
+ if [ -z $tag -o $tag = tip ]; then
+ id=`printf '%s' $hgid | sed 's/[+ ].*//'`
+ printf
Re: [U-Boot] [PATCH 4/6] tegra: Add tegra keyboard support
Hi Stephen, On Mon, Dec 12, 2011 at 10:31 AM, Stephen Warren swar...@nvidia.com wrote: On 12/12/2011 11:10 AM, Simon Glass wrote: On Mon, Dec 12, 2011 at 10:00 AM, Stephen Warren swar...@nvidia.com wrote: On 12/08/2011 02:56 PM, Simon Glass wrote: ... I'd like to ask for comments in linux-input in case they have any other ideas, e.g. whether a set of separately documented modifier mapping properties makes sense. If not, I suppose the following set of properties would suffice: nvidia,keycode-plain nvidia,keycode-fn u-boot,keycode-shift u-boot,keycode-ctrl (although the last two seem to want both nvidia, and u-boot, prefixes) OK. Since this seems to be a kernel issue and Nvidia-specific can I ask if you can please send this email? I will wait for confirmation that this is OK before going further. OK, I'll send the email. Thanks. I would like to point out though that this is neither a kernel issue nor NVIDIA-specific: It's a device tree issue dealing with how to best represent certain HW features, and it will apply equally to any HW that has a keyboard with modifier keys; essentially all of them. Sorry I don't quite understand what you mean by that, given your comments that we should ask on linux-input. While it could apply to the two existing keyboard drivers, they each do their own thing at present. Regards, Simon -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5 v2] mtd/nand: workaround for Freescale FCM to support 4k pagesize Nand chip
On 12/12/2011 03:49 AM, Shengzhou Liu wrote:
Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip with pagesize larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Liu Shuo b35...@freescale.com
---
drivers/mtd/nand/fsl_elbc_nand.c | 283 +
1 files changed, 252 insertions(+), 31 deletions(-)
I've asked you several times what you're planning on doing for bad block
marker migration. I am not going to let you ignore this. NACK until
you have a migration tool, and a scheme for marking the flash as having
been migrated.
Also please mention below the --- what has changed since v1.
@@ -393,9 +468,28 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd,
unsigned int command,
page_addr, column);
ctrl-column = column;
- ctrl-oob = 0;
+ if (column = mtd-writesize) {
+ /* OOB area */
+ column -= mtd-writesize;
+ ctrl-oob = 1;
+ } else {
+ ctrl-oob = 0;
+ }
[snip]
@@ -432,12 +524,19 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd,
unsigned int command,
}
out_be32(lbc-fcr, fcr);
- set_addr(mtd, column, page_addr, ctrl-oob);
+ if (column = mtd-writesize mtd-writesize 2048) {
How can column = mtd-writesize be true at this point? You've already
subtracted it out.
if (ctrl-oob || ctrl-column != 0 ||
- ctrl-index != mtd-writesize + mtd-oobsize)
- out_be32(lbc-fbcr, ctrl-index);
- else
+ ctrl-index != mtd-writesize + mtd-oobsize) {
+ if (ctrl-oob mtd-writesize 2048) {
+ out_be32(lbc-fbcr, 64);
+ } else {
+ out_be32(lbc-fbcr, ctrl-index -
+ ctrl-column);
+ }
+ } else {
out_be32(lbc-fbcr, 0);
+ }
Again, if we're going to make an API assumption that we get either a
full page access or a full OOB access, then make the assumption fully.
Don't half-implement partial accessses.
+int board_nand_init_tail(struct mtd_info *mtd)
+{
+ struct nand_chip *nand = mtd-priv;
+ struct fsl_elbc_mtd *priv = nand-priv;
+ struct fsl_elbc_ctrl *ctrl = priv-ctrl;
+
+ /* adjust Option Register and ECC to match Flash page size */
+ if (mtd-writesize == 512) {
+ clrbits_be32(ctrl-regs-bank[priv-bank].or, OR_FCM_PGS);
+ } else if (mtd-writesize = 2048 mtd-writesize = 8192) {
+ setbits_be32(ctrl-regs-bank[priv-bank].or, OR_FCM_PGS);
+ /* adjust ecc setup if needed */
+ if ((in_be32(ctrl-regs-bank[priv-bank].br) BR_DECC) ==
+ BR_DECC_CHK_GEN) {
+ nand-ecc.size = 512;
Please find some way to indent the continuation line so it doesn't line
up with the if-body.
+ nand-ecc.layout = (priv-fmr FMR_ECCM) ?
+fsl_elbc_oob_lp_eccm1 : fsl_elbc_oob_lp_eccm0;
+ nand-badblock_pattern = largepage_memorybased;
Those oob layouts won't be quite right for larger page sizes.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] printf in uboot
Hi Siddharth,
On Tue, Dec 13, 2011 at 6:51 AM, Simon Glass s...@chromium.org wrote:
Hi,
On Sun, Dec 11, 2011 at 11:51 PM, siddharth baisane
nov15twenty...@gmail.com wrote:
hi,
I am trying to print statement in uboot.
but whenever I add *printf *statement board hangs.
For example in *u-boot/lib_arm/board.c* i added prinf statement and board
hags.
void start_armboot (void)
{
init_fnc_t **init_fnc_ptr;
char *s;
#if defined(CONFIG_VFD) || defined(CONFIG_LCD)
unsigned long addr;
#endif
*printf(armboot starts\n);*
/* Pointer is writable since we allocated a register for it */
gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
/* compiler optimization barrier needed for GCC = 3.4 */
__asm__ __volatile__(: : :memory);
memset ((void*)gd, 0, sizeof (gd_t));
gd-bd = (bd_t*)((char*)gd - sizeof(bd_t));
memset (gd-bd, 0, sizeof (bd_t));
gd-flags |= GD_FLG_RELOC;
monitor_flash_len = _bss_start - _armboot_start;
You can use the CONFIG_PRE_CONSOLE_BUFFER feature to support printf()
prior to console_init_f().
Which raises questions about the version you are running - Prior to
the implementation of CONFIG_PRE_CONSOLE_BUFFER, a change was made to
squelch console output prior to console init which turned printf(),
puts() and friends into a nop prior to console init, so the addition
of a printf() should not have caused the board to hang (although I do
admit these changes were after 2011.09)
I suggest upgrading to latest top-of-tree, or wait another 10 days for 2011.12
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot v2011.12-rc1 hang on pandaboard
On Mon, Dec 12, 2011 at 11:27 AM, Chris Lalancette clalance...@gmail.com wrote: Hello, I'm trying to boot the current version of u-boot (both the MLO and u-boot.img) on the pandaboard 4430. However, it always hangs up right after Using default environment, and before Hit any key to stop autoboot. I bisected the problem down to commit 9792987721c7980453fe6447c3fa6593b44f8458; if I revert that USB commit, then the boot proceeds as normal. I can't say I quite understand why this is a problem for the Panda, but aside from reverting the commit, does anyone have a suggestion for fixing this? Reverting that same commit also fixes the beagleboard xm.. For reference, I'm using, linaro's arm gcc: gcc version 4.6.2 20110908 (prerelease) (Linaro GCC 4.6-2011.09-1) Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 0/2] Support for HTKW mcx board
Hi All, these patches introduce support for HTKW mcx board (AM3517-based) including OMAP3 EHCI support. Regards, Ilya. Ilya Yanok (2): ehci-omap: driver for EHCI host on OMAP3 mcx: support for HTKW mcx board MAINTAINERS|4 + board/htkw/mcx/Makefile| 38 board/htkw/mcx/mcx.c | 91 + board/htkw/mcx/mcx.h | 408 board/ti/beagle/beagle.c | 101 -- boards.cfg |1 + drivers/usb/host/Makefile |1 + drivers/usb/host/ehci-omap.c | 156 +++ include/configs/mcx.h | 371 include/configs/omap3_beagle.h |3 + 10 files changed, 1073 insertions(+), 101 deletions(-) create mode 100644 board/htkw/mcx/Makefile create mode 100644 board/htkw/mcx/mcx.c create mode 100644 board/htkw/mcx/mcx.h create mode 100644 drivers/usb/host/ehci-omap.c create mode 100644 include/configs/mcx.h -- 1.7.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 2/2] mcx: support for HTKW mcx board
This patch adds support for the HTKW mcx AM3517-based board. Serial, Ethernet, NAND, MMC, RTC, EHCI USB host and both NAND and MMC SPLs are supported. Requires updated mach-types file. Signed-off-by: Ilya Yanok ya...@emcraft.com --- I'm sorry for non-consistent version history, I will give links to my previous posts along with version numbers. The last (Support for HTKW mcx) series: Changes from V3 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/118530 - Comment for misc_init_r function fixed - Added check for gpio_request return value. - Removed #if defined(CONFIG_GENERIC_MMC) around board_mmc_init - CONFIG_USE_IRQ and related stuff removed from config - CONFIG_OMAP3_MICRON_DDR removed - CONFIG_SYS_MAXRAGS changed 32 - 16 - Incorrect multiline comments (/*--- ones) fixed - CONFIG_SPL_MAX_SIZE rewritten 0xB400 - (45 10) - CONFIG_SPL_NAND_WORKSPACE removed Changes from V2 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/116548 - None Changes from V1 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/115026 - Calls to gpio_set_value after gpio_direction_output removed - Minor style problem (tab instead of space) fixed SPL series: Changes from V1 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112892 - OMAP EHCI support enabled in config - MMC SPL support enabled in config DaVinci EMAC and HTKW mcx support series: Changes from V3 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112884 - NAND SPL support enabled in config Changes from V2 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112317 - removed dead code from board/htkw/mcx/Makefile as Mike suggested - removed EMAC reset (now done in generic cpu_eth_init()) - removed some unsuned defines from configuration header Changes from V1 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/97 - various style fixes to make checkpatch (almost) happy - FSF address removed from GPL comments - CONFIG_SYS_TEXT_BASE moved to configuration header, config.mk droped - CONFIG_MACH_TYPE is used instead of setting mach type from board code - i2c_init removed from misc_init_r - cpu_eth_init removed (added to generic place by another patch) - CONTROL_PADCONF defines removed - Fixed boolean config options not to have a value - CONFIG_MUSB_* and related defines removed MAINTAINERS |4 + board/htkw/mcx/Makefile | 38 + board/htkw/mcx/mcx.c| 91 +++ board/htkw/mcx/mcx.h| 408 +++ boards.cfg |1 + include/configs/mcx.h | 371 ++ 6 files changed, 913 insertions(+), 0 deletions(-) create mode 100644 board/htkw/mcx/Makefile create mode 100644 board/htkw/mcx/mcx.c create mode 100644 board/htkw/mcx/mcx.h create mode 100644 include/configs/mcx.h diff --git a/MAINTAINERS b/MAINTAINERS index a56ca10..c7fcc10 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -903,6 +903,10 @@ Richard Woodruff r-woodru...@ti.com omap2420h4 ARM1136EJS +Ilya Yanok ya...@emcraft.com + + mcx ARM ARMV7 (AM35x SoC) + Syed Mohammed Khasim sm.kha...@gmail.com Sughosh Ganu urwithsugh...@gmail.com diff --git a/board/htkw/mcx/Makefile b/board/htkw/mcx/Makefile new file mode 100644 index 000..4c8db10 --- /dev/null +++ b/board/htkw/mcx/Makefile @@ -0,0 +1,38 @@ +# +# Copyright (C) 2011 Ilya Yanok, Emcraft Systems +# +# Based on ti/evm/Makefile +# +# 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. +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS := $(BOARD).o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend diff --git a/board/htkw/mcx/mcx.c b/board/htkw/mcx/mcx.c new file mode 100644 index 000..163ae98 --- /dev/null +++ b/board/htkw/mcx/mcx.c @@ -0,0 +1,91 @@ +/* + * Copyright (C) 2011 Ilya Yanok, Emcraft Systems + * + * Based on ti/evm/evm.c + * + * 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
Re: [U-Boot] [PATCH v2] powerpc/mpc83xx: set TXEQA/TXEQE value for mpc837XE sata
On Sun, 11 Dec 2011 21:26:34 -0600 Huang Changming-R66093 r66...@freescale.com wrote: From: Huang Changming-R66093 Sent: Thursday, November 17, 2011 10:16 AM In the current u-boot code, the value of these fields are the reserved value (0b100), through the signal integrity measurement on freescale's board with these reserved setting, the signal eye is out of the recommended spec for non-transition amplitude at 500mV nominal. According to the errata for MPC8379E, we should make a change to the recommended setting from essentially nothing at this time to 0b001 for SATA. Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com CC: Kim Phillips kim.phill...@freescale.com --- changes for v2: - use clrsetbits_be32 to clear and set the value applied to 83xx/master, thanks. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Please pull powerpc/mpc83xx: set TXEQA/TXEQE value for mpc837XE sata
Wolfgang Denk, Please pull, for u-boot v2011.12: The following changes since commit 06e42c6e2ce269667daecd6229d0b7c813838203: Merge branch 'ag...@denx.de' of git://git.denx.de/u-boot-staging (2011-12-12 14:51:16 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Jerry Huang (1): powerpc/mpc83xx: set TXEQA/TXEQE value for mpc837XE sata arch/powerpc/cpu/mpc83xx/serdes.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 1/4] gpio: Modify common gpio.h to more closely match Linux
On Fri, 11 Nov 2011 15:55:35 -0600 Joe Hershberger joe.hershber...@ni.com wrote: Change int gp to unsigned gpio Add request and free entry-points Signed-off-by: Joe Hershberger joe.hershber...@ni.com Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Kim Phillips kim.phill...@freescale.com --- I've fixed a merge conflict in #2 for da8xx_gpio.c, tegra2_gpio.c, and extended it to the new mxs_gpio.c, and applied all four patches to u-boot-mpc83xx/next. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Request for Help: How to save data to an SD/MMC card
Hi All, I have a need to dump memory contents to a filesystem on an SD/MMC card so I can transfer it to my dev PC. I don't have a working network driver, so TFTP is out Now I notice that U-Boot has code to support writing to FAT filesystems, but it does not appear to be plumbed in Alternatively, I could patch up the recently posted ext4 code and give that a go Is there any other existing mechanism to write a file to a filesystem on an SD/MMC card in U-Boot? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs/fat/fat.c: fix warning: 'part_size' defined but not used
On Thursday, October 27, 2011 02:10:58 PM Wolfgang Denk wrote:
Commit c30a15e FAT: Add FAT write feature introduced a compiler
warning. Fix this.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Donggeun Kim dg77@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
---
fs/fat/fat.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7cf173c..756ac64 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -46,7 +46,6 @@ static void downcase (char *str)
static block_dev_desc_t *cur_dev = NULL;
static unsigned long part_offset = 0;
-static unsigned long part_size;
static int cur_part = 1;
@@ -100,7 +99,6 @@ int fat_register_device (block_dev_desc_t * dev_desc,
int part_no) if (!get_partition_info(dev_desc, part_no, info)) {
part_offset = info.start;
cur_part = part_no;
- part_size = info.size;
} else if ((strncmp((char *)buffer[DOS_FS_TYPE_OFFSET], FAT, 3) == 0)
|| (strncmp((char *)buffer[DOS_FS32_TYPE_OFFSET], FAT32, 5) == 0)) { /*
ok, we assume we are on a PBR only */
Hi Wolfgang,
I know it's rather late to comment on this, but this patch breaks FAT write
support.
-Aaron
--
Aaron Williams aaron.willi...@cavium.com
(408) 943-7198
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/cmd_pxe.c: Fix GCC 4.6 build warnings
Fix:
cmd_pxe.c: In function 'parse_pxefile_top':
cmd_pxe.c:941:5: warning: 'err' may be used uninitialized in this
function [-Wuninitialized]
cmd_pxe.c:921:6: note: 'err' was declared here
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Jason Hobbs jason.ho...@calxeda.com
---
common/cmd_pxe.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index 9426f5b..7c0cb66 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -918,7 +918,7 @@ static int parse_menu(char **c, struct pxe_menu *cfg, char
*b, int nest_level)
{
struct token t;
char *s = *c;
- int err;
+ int err = 0;
get_token(c, t, L_KEYWORD);
--
1.7.6.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Devkit8000: Switch over to enable_gpmc_cs_config
Hello Tom,
On 07.12.2011 18:14, Tom Rini wrote:
On Wed, Dec 7, 2011 at 2:38 AM, Thomas Weber we...@corscience.de wrote:
Use enable_gpmc_cs_config instead of local writing
timing configuration for GPMC.
Signed-off-by: Thomas Weber we...@corscience.de
---
board/timll/devkit8000/devkit8000.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/board/timll/devkit8000/devkit8000.c
b/board/timll/devkit8000/devkit8000.c
index bcadfc4..dd46c35 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -48,6 +48,16 @@
DECLARE_GLOBAL_DATA_PTR;
+static u32 gpmc_net_config[GPMC_MAX_REG] = {
+ NET_GPMC_CONFIG1,
+ NET_GPMC_CONFIG2,
+ NET_GPMC_CONFIG3,
+ NET_GPMC_CONFIG4,
+ NET_GPMC_CONFIG5,
+ NET_GPMC_CONFIG6,
+ NET_GPMC_CONFIG7,
+};
Value 7 is computed in enable_gpmc_cs_config() so it should be a 0 in
the struct (or just a comment for clarity, I've seen both I think).
The calculated value in enable_gpmc_cs_config() is same as
NET_GPMC_CONFIG7. The gpmc_net_config[6] is ignored and not used in
enable_gpmc_cs_config(). If you want a 0 at this position I will send a
second version with a 0 for NET_GPMC_CONFIG7.
Thomas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
