Re: [U-Boot] [PATCH v3] Marvell MV88F6281GTW_GE Board support
Hi Jean
Thanks for your review feedback
Pls see my in lined comments
-Original Message-
From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
Sent: Monday, April 27, 2009 4:06 AM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Ashish Karkare; Ronen Shitrit;
Prabhanjan Sarnaik
Subject: Re: [PATCH v3] Marvell MV88F6281GTW_GE Board support
On 07:19 Thu 23 Apr , Prafulla Wadaskar wrote:
This is Marvell's 88F6281_A0 based custom board developed
for wireless
access point product
v3: updated as per review comments for v2 added
mv88f6281gtw_ge.h file
removed BITxx macros
first a general comment
I do not known if it's your mailer but all tab are converted
in whitespace please fix it
This should be mailer problem, I will fix it for all next patch send
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ /* Board Parameters initializations */
could explain what you do a few more?
This is explained in detail in Kirkwood support file (i.e.
cpu/arm926ejs/kirkwood/kwcore.c) in Kirkwood SOC support patch
I will put some explanation here too for each init call
+ kw_window_ctrl_reg_init();
+ kw_gpio_init(MV88F6281GTW_GE_OE_VAL_LOW,
+MV88F6281GTW_GE_OE_VAL_HIGH,
+MV88F6281GTW_GE_OE_LOW,
MV88F6281GTW_GE_OE_HIGH);
+
+ kw_mpp_control_init(MV88F6281GTW_GE_MPP0_7,
+ MV88F6281GTW_GE_MPP8_15,
+ MV88F6281GTW_GE_MPP16_23,
+ MV88F6281GTW_GE_MPP24_31,
+ MV88F6281GTW_GE_MPP32_39,
+ MV88F6281GTW_GE_MPP40_47,
+ MV88F6281GTW_GE_MPP48_55);
+
from
+ /* serial config */
+ gd-baudrate = CONFIG_BAUDRATE;
+ gd-have_console = 1;
no need please remove
Okay I will remove this
+ /*
+* arch number of USED SOC
+*/
+ gd-bd-bi_arch_number = MACH_TYPE_MV88F6281GTW_GE;
+
+ /* adress of boot parameters */
+ gd-bd-bi_boot_params = 0x0100;
please be more consistant with the other arm boards RAM_BASE + 0x100
Okay..
+
+ return 0;
+}
+
+int dram_init(void)
+{
+ int i;
+
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ gd-bd-bi_dram[i].start = kw_sdram_bar(i);
+ gd-bd-bi_dram[i].size = kw_sdram_bs(i);
+ }
+ return 0;
+}
+
+int last_stage_init(void)
+{
+ return 0;
+}
no need please remove
Okay
+
+#if defined(CONFIG_MISC_INIT_R)
+/* miscellaneous platform dependent init */ int misc_init_r(void) {
+ return kw_misc_init_r();
+}
if it's really arch late init please create a generic
function like arch_late_init or arch_misc_init and call it
from lib_arm/board.c
+
+void reset_phy(void)
+{
+#ifdef CONFIG_MV88E61XX_SWITCH
+ /* configure and initialize switch */
+ struct mv88e61xx_config swcfg = {
+ .name = egiga0,
+ .vlancfg = MV88E61XX_VLANCFG_ROUTER,
+ .rgmii_delay = MV88E61XX_RGMII_DELAY_EN,
+ .portstate = MV88E61XX_PORTSTT_FORWARDING,
+ .cpuport = 5,
+ .ports_enabled = (PORT(0) | PORT(1) | PORT(2)
+ | PORT(3) | PORT(4) | PORT(5))
+ };
+
+ mv88e61xx_switch_initialize(swcfg);
+#endif
+}
please only call reset_phy when the SWITCH is enable. it will
reduce the size of u-boot whenyou do not use the switch
Yes... I will do it
+/*
+ * Default values for MPP registers
+ */
+#define MV88F6281GTW_GE_MPP0_7 0x0111
+#define MV88F6281GTW_GE_MPP8_150x11103311
+#define MV88F6281GTW_GE_MPP16_23 0x
+#define MV88F6281GTW_GE_MPP24_31 0x
+#define MV88F6281GTW_GE_MPP32_39 0x40440222
+#define MV88F6281GTW_GE_MPP40_47 0x
+#define MV88F6281GTW_GE_MPP48_55 0x
could explain a few more these value
I will put explanation for this
GbePort0/1 for kernel */
+#define CONFIG_KIRKWOOD_PCIE_INIT /* Enable PCIE
Port0 for kernel */
+#define CONFIG_KIRKWOOD_RGMII_PAD_1V8 /* Set RGMII Pad voltage to
+1.8V */ #endif
why?
this boards is not a KIRWOOD?
No, This board is MV88F6281GTW_GE which uses 88F6281 belongs to kirkwood family
of SoCs.
Soc has provision to configure RGMII pad voltages to 1.8 or 3.3 Volts connected
to Gbe interface (i.e. switch used on this board).
Also kernel switch and Gbe controller driver does not take care of this since
they are generic.
+#define CONFIG_BOOTCOMMAND
$(x_bootcmd_kernel); setenv bootargs \
IIRC please use ${} instead of $()
Okay
+ $(x_bootargs) $(x_bootargs_root); bootm 0x640;
+#define CONFIG_EXTRA_ENV_SETTINGS
x_bootargs=console=ttyS0,115200 \
+
Re: [U-Boot] [PATCH 1/2] ubifs: BUG realpath string must be ended with ZERO
On Friday 24 April 2009 10:36:05 Ricardo Ribalda Delgado wrote: If the memory used to copy the link_make is dirty the string wont be ended with Zero, throwing out multiple memory bugs. use NULL or NUL, not Zero. same goes for subject. + link_name[ui-data_len]='\0'; need spaces around the equal sign. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib
On Friday 24 April 2009 10:36:06 Ricardo Ribalda Delgado wrote: Blocks compressed with zlib dont have the full gzip header. This patch adds a new function to properly handle blocks compressed with zlib. Without this patch, block compressed with zlib cannot be readed! this really should be a common function not specific to ubifs as there are many other opportunities for things to be compressed directly with zlib and not through gzip (splash/video images come to mind). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib
Hello Mike: Who is in charge of the lib_generic stuff? Meanwhile there is no such a function I will leave it as an extra function. This must be solved ASAP, it is a simply bug that avoid many fs to be mounted properly. Best regards On Mon, Apr 27, 2009 at 08:59, Mike Frysinger vap...@gentoo.org wrote: On Friday 24 April 2009 10:36:06 Ricardo Ribalda Delgado wrote: Blocks compressed with zlib dont have the full gzip header. This patch adds a new function to properly handle blocks compressed with zlib. Without this patch, block compressed with zlib cannot be readed! this really should be a common function not specific to ubifs as there are many other opportunities for things to be compressed directly with zlib and not through gzip (splash/video images come to mind). -mike -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ubifs: BUG realpath string must be ended with NULL
If the memory used to copy the link_make is dirty the string wont
be ended with NULL, throwing out multiple memory bugs.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v3: s/ZERO/NULL/, s/=/ = /
v2: better doc and remove duplicated memcpy
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 32f9ff8..427d84a 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -641,6 +641,7 @@ int ubifs_load(char *filename, u32 addr, u32 size)
ui = ubifs_inode(inode);
if (((inode-i_mode S_IFMT) == S_IFLNK) ui-data_len) {
memcpy(link_name, ui-data, ui-data_len);
+ link_name[ui-data_len] = '\0';
printf(%s is linked to %s!\n, filename, link_name);
ubifs_iput(inode);
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot mtest hang on mx31
When i do a memtest without any args, it crashes after printing the first line. = mtest Pattern Writing... After reboot, when i do and md for the base address 0x0, i get the following, which proabbly is the uboot image itself in RAM. Not exactly. At address 0 you have the internal boot ROM. That code is not u-boot, as you can see from comparing with the u-boot.bin you compiled. Actually, your ram start at 2GB physical (CSD0_BASE, 0x8000) but the MX31 config file in current git says: #define CONFIG_SYS_MEMTEST_START 0/* memtest works on */ #define CONFIG_SYS_MEMTEST_END 0x1 So, most likely memtest without arguments has never been used on the board. [disclaimer: I have mx21 but not mx31, I just assume it's similar] /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] LPC2468 support
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote: In message 20090424215804.gc10...@game.jcrosoft.org you wrote: ... +#define COPY_BUFFER_LOCATION 0x4000fde0 evenif it's soc specific flash support I think they need to be store with the other flash and need to have the ack of Stefan No, not really. Stefan cares only about the CFI driver, and this is clearly not a CFI conformant flash type. ok but I steel wish to have Stefan opinion I took a quick look at the flash driver. The main functions lpc24xx_flash_erase() and lpc24xx_write_buff() are not even referenced somewhere in this patch. They seem to be used in the 2nd patch (2/2) though. It's hard to really understand what's going on here. So this flash driver part really needs some sort of documentation how it's supposed to work. And I also think this driver (as all FLASH related drivers) should be moved into drivers/mtd instead. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib
On Monday 27 April 2009 03:06:26 Ricardo Ribalda Delgado wrote: fix your top posting. which is to say dont. Who is in charge of the lib_generic stuff? if there is no one specified in the MAINTAINERS file, then Wolfgang maintains it all. just send it to the u-boot list and someone will pick it up. Meanwhile there is no such a function I will leave it as an extra function. This must be solved ASAP, it is a simply bug that avoid many fs to be mounted properly. by the by, your definition of ASAP rarely lines up with anyone else's. you already have a fix so your ASAP is taken care of. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] cfi_flash.c fails to program NOR Flash SST39LF040
On Friday 24 April 2009, Po-Yu Chuang wrote: I have a board on which there is a NOR Flash SST39LF040. Previously, I copied flash.c from other boards. Now I am trying to migrate NOR Flash driver to use CFI, but it fails to program sectors which are not on the 0x1 boundaries. I found that in function flash_write_cfiword() @drivers/mtd/cfi_flash.c it issues command with address relative to sector address. However, according to SST39 series data sheet, it seems that we should issue command with address relative to flash base address? After I modified flash_write_cfiword() to issue command to sector 0, everything works fine. Is it a bug? Did you define CONFIG_FLASH_CFI_LEGACY (and CONFIG_SYS_FLASH_LEGACY_512Kx8)? IIRC then the SST FLASH chips are not completely CFI compatible. So you need to enable the JEDEC framework. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib
On Monday 27 April 2009, Mike Frysinger wrote: Who is in charge of the lib_generic stuff? if there is no one specified in the MAINTAINERS file, then Wolfgang maintains it all. just send it to the u-boot list and someone will pick it up. Yes, Wolfgang is ion charge for all this stuff. Meanwhile there is no such a function I will leave it as an extra function. This must be solved ASAP, it is a simply bug that avoid many fs to be mounted properly. We should really fix this properly, as Mike suggested, by moving this function into a common/generic file. It shouldn't be a problem to get it accepted in this release since it's a bug fix. So please resubmit again, this time in lib_generic. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ubifs: BUG realpath string must be ended with NULL
On Monday 27 April 2009, Ricardo Ribalda Delgado wrote: If the memory used to copy the link_make is dirty the string wont be ended with NULL, throwing out multiple memory bugs. Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es Acked-by: Stefan Roese s...@denx.de Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Canyonlands SATA harddisk driver
Hi Kazuaki Ichinohe, On Monday 27 April 2009, Kazuaki Ichinohe wrote: I sent the SATA patch mail on April 17. However, the following content is not confirmed, and there is not a reply either. Could you confirm it? I re-send the SATA driver patch. Sorry, I forgot about reviewing it. I'll do this today or tomorrow. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib
Hello I am creating a new function (zunzip). Where this function should be placed. In zlib.c or in gunzip.c? Best regards On Mon, Apr 27, 2009 at 09:36, Stefan Roese s...@denx.de wrote: On Monday 27 April 2009, Mike Frysinger wrote: Who is in charge of the lib_generic stuff? if there is no one specified in the MAINTAINERS file, then Wolfgang maintains it all. just send it to the u-boot list and someone will pick it up. Yes, Wolfgang is ion charge for all this stuff. Meanwhile there is no such a function I will leave it as an extra function. This must be solved ASAP, it is a simply bug that avoid many fs to be mounted properly. We should really fix this properly, as Mike suggested, by moving this function into a common/generic file. It shouldn't be a problem to get it accepted in this release since it's a bug fix. So please resubmit again, this time in lib_generic. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib
On Monday 27 April 2009 03:48:15 Ricardo Ribalda Delgado wrote: Hello you're still top posting. please fix the e-mail composer. I am creating a new function (zunzip). Where this function should be placed. In zlib.c or in gunzip.c? probably the latter since the former is more code straight from zlib -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] I2C cleanup before removal of deprecated commands
Hello Peter, Peter Tyser wrote: Hi Heiko, These 5 patches should clean up the compile issues that you noticed after application of the [PATCH v2 0/7] Remove individual I2C commands and cleanup series. Thanks. I only have a build environment for powerpc boards so it'd be much appreciated if other architectures could do some basic compile testing after the Remove individual I2C commands and cleanup series is applied to the i2c repository. I did a powerpc and an arm MAKEALL ... Hmm.. maybe we should add somewhere in the tree a documentation, where toolchains can be found? Assuming these patches are accepted, the original v2 Remove individual I2C commands and cleanup series should then be applied. Applied to u-boot-i2c next branch, also the v2 Remove individual I2C commands and cleanup series, see: http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=shortlog;h=refs/heads/next bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
lib_generic/gunzip.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/lib_generic/gunzip.c b/lib_generic/gunzip.c
index 01a4031..d59a448 100644
--- a/lib_generic/gunzip.c
+++ b/lib_generic/gunzip.c
@@ -39,6 +39,8 @@
int gunzip(void *, int, unsigned char *, unsigned long *);
void *zalloc(void *, unsigned, unsigned);
void zfree(void *, void *, unsigned);
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset);
void *zalloc(void *x, unsigned items, unsigned size)
{
@@ -59,8 +61,7 @@ void zfree(void *x, void *addr, unsigned nb)
int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp)
{
- z_stream s;
- int r, i, flags;
+ int i, flags;
/* skip header */
i = 10;
@@ -84,6 +85,18 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
return (-1);
}
+ return zunzip(dst, dstlen, src, lenp, 1, i);
+}
+
+/*
+ * Uncompress blocks compressed with zlib without headers
+ */
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset)
+{
+ z_stream s;
+ int r;
+
s.zalloc = zalloc;
s.zfree = zfree;
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
@@ -95,14 +108,14 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
r = inflateInit2(s, -MAX_WBITS);
if (r != Z_OK) {
printf (Error: inflateInit2() returned %d\n, r);
- return (-1);
+ return -1;
}
- s.next_in = src + i;
- s.avail_in = *lenp - i;
+ s.next_in = src + offset;
+ s.avail_in = *lenp - offset;
s.next_out = dst;
s.avail_out = dstlen;
r = inflate(s, Z_FINISH);
- if (r != Z_STREAM_END) {
+ if ((r != Z_STREAM_END) (stoponerr==1)) {
printf (Error: inflate() returned %d\n, r);
inflateEnd(s);
return (-1);
@@ -110,5 +123,5 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
*lenp = s.next_out - (unsigned char *) dst;
inflateEnd(s);
- return (0);
+ return 0;
}
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Hello Wolfgang UBI fs blocks can be compresed in lzo, zlib or no-compression. The current implementation of u-boot supported all the compressions but there was a bug in the implementation of zlib. UBIFS's Zlib blocks do not have header but they were compressed using gunzip, a function used to decompress gunzip files/sectors with a header. This patch creates a functions that is able of decompress such a blocks. Please comment what it means. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To the systems programmer, users and applications serve only to provide a test load. -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Dear Ricardo Ribalda Delgado,
In message 1240823996-10418-1-git-send-email-ricardo.riba...@uam.es you wrote:
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
What is the needed for? Maybe you should provide a use case so we can
see why this change makes sense.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
lib_generic/gunzip.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/lib_generic/gunzip.c b/lib_generic/gunzip.c
index 01a4031..d59a448 100644
--- a/lib_generic/gunzip.c
+++ b/lib_generic/gunzip.c
@@ -39,6 +39,8 @@
int gunzip(void *, int, unsigned char *, unsigned long *);
void *zalloc(void *, unsigned, unsigned);
void zfree(void *, void *, unsigned);
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset);
void *zalloc(void *x, unsigned items, unsigned size)
{
@@ -59,8 +61,7 @@ void zfree(void *x, void *addr, unsigned nb)
int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp)
{
- z_stream s;
- int r, i, flags;
+ int i, flags;
/* skip header */
i = 10;
@@ -84,6 +85,18 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
return (-1);
}
+ return zunzip(dst, dstlen, src, lenp, 1, i);
+}
+
+/*
+ * Uncompress blocks compressed with zlib without headers
+ */
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset)
+{
+ z_stream s;
+ int r;
+
s.zalloc = zalloc;
s.zfree = zfree;
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
@@ -95,14 +108,14 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
r = inflateInit2(s, -MAX_WBITS);
if (r != Z_OK) {
printf (Error: inflateInit2() returned %d\n, r);
- return (-1);
+ return -1;
}
- s.next_in = src + i;
- s.avail_in = *lenp - i;
+ s.next_in = src + offset;
+ s.avail_in = *lenp - offset;
s.next_out = dst;
s.avail_out = dstlen;
r = inflate(s, Z_FINISH);
- if (r != Z_STREAM_END) {
+ if ((r != Z_STREAM_END) (stoponerr==1)) {
Seems this is an unrelated change. Maybe this should be split out into
a separate patch?
Please comment what it means.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
To the systems programmer, users and applications serve only to
provide a test load.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [82xx] ids8247: Remove legacy NAND defines
because legacy NAND support is deprecated converting to current
NAND interface. !This just compile, because I have no more the
hardware to test it.
Signed-off-by: Heiko Schocher h...@denx.de
---
board/ids8247/ids8247.c | 92 +
include/configs/IDS8247.h | 55 ---
2 files changed, 84 insertions(+), 63 deletions(-)
diff --git a/board/ids8247/ids8247.c b/board/ids8247/ids8247.c
index 68b7070..79fe9da 100644
--- a/board/ids8247/ids8247.c
+++ b/board/ids8247/ids8247.c
@@ -304,21 +304,97 @@ phys_size_t initdram (int board_type)
int misc_init_r (void)
{
gd-bd-bi_flashstart = 0xff80;
+ return 0;
}
#if defined(CONFIG_CMD_NAND)
-extern ulong
-nand_probe (ulong physadr);
+#include nand.h
+#include linux/mtd/mtd.h
+#include asm/io.h
+
+static u8 hwctl;
+
+static void ids_nand_hwctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+
+ if (ctrl NAND_CTRL_CHANGE) {
+ if ( ctrl NAND_CLE ) {
+ hwctl |= 0x1;
+ writeb(0x00, (this-IO_ADDR_W + 0x0a));
+ } else {
+ hwctl = ~0x1;
+ writeb(0x00, (this-IO_ADDR_W + 0x08));
+ }
+ if ( ctrl NAND_ALE ) {
+ hwctl |= 0x2;
+ writeb(0x00, (this-IO_ADDR_W + 0x09));
+ } else {
+ hwctl = ~0x2;
+ writeb(0x00, (this-IO_ADDR_W + 0x08));
+ }
+ if ( (ctrl NAND_NCE) != NAND_NCE)
+ writeb(0x00, (this-IO_ADDR_W + 0x0c));
+ else
+ writeb(0x00, (this-IO_ADDR_W + 0x08));
+ }
+ if (cmd != NAND_CMD_NONE)
+ writeb(cmd, this-IO_ADDR_W);
+
+}
-void
-nand_init (void)
+static u_char ids_nand_read_byte(struct mtd_info *mtd)
{
- ulong totlen = 0;
+ struct nand_chip *this = mtd-priv;
- debug (Probing at 0x%.8x\n, CONFIG_SYS_NAND0_BASE);
- totlen += nand_probe (CONFIG_SYS_NAND0_BASE);
+ return readb(this-IO_ADDR_R);
+}
+
+static void ids_nand_write_buf(struct mtd_info *mtd, const u_char *buf, int
len)
+{
+ struct nand_chip *nand = mtd-priv;
+ int i;
+
+ for (i = 0; i len; i++) {
+ if (hwctl 0x1)
+ writeb(buf[i], (nand-IO_ADDR_W + 0x02));
+ else if (hwctl 0x2)
+ writeb(buf[i], (nand-IO_ADDR_W + 0x01));
+ else
+ writeb(buf[i], nand-IO_ADDR_W);
+ }
+}
- printf (%4lu MB\n, totlen 20);
+static void ids_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ struct nand_chip *this = mtd-priv;
+ int i;
+
+ for (i = 0; i len; i++) {
+ buf[i] = readb(this-IO_ADDR_R);
+ }
+}
+
+static int ids_nand_dev_ready(struct mtd_info *mtd)
+{
+ /* constant delay (see also tR in the datasheet) */
+ udelay(12);
+ return 1;
+}
+
+int board_nand_init(struct nand_chip *nand)
+{
+ nand-ecc.mode = NAND_ECC_SOFT;
+
+ /* Reference hardware control function */
+ nand-cmd_ctrl = ids_nand_hwctrl;
+ nand-read_byte = ids_nand_read_byte;
+ nand-write_buf = ids_nand_write_buf;
+ nand-read_buf = ids_nand_read_buf;
+ nand-dev_ready = ids_nand_dev_ready;
+ nand-chip_delay = 12;
+
+ return 0;
}
#endif /* CONFIG_CMD_NAND */
diff --git a/include/configs/IDS8247.h b/include/configs/IDS8247.h
index fbcbddb..51e012c 100644
--- a/include/configs/IDS8247.h
+++ b/include/configs/IDS8247.h
@@ -262,63 +262,8 @@
*/
#if defined(CONFIG_CMD_NAND)
-#define CONFIG_NAND_LEGACY
#define CONFIG_SYS_NAND0_BASE 0xE100
-
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND devices
*/
-#define SECTORSIZE 512
-#define NAND_NO_RB
-
-#define ADDR_COLUMN 1
-#define ADDR_PAGE 2
-#define ADDR_COLUMN_PAGE 3
-
-#define NAND_ChipID_UNKNOWN 0x00
-#define NAND_MAX_FLOORS 1
-
-#define NAND_DISABLE_CE(nand) do \
-{ \
- *(((volatile __u8 *)(nand-IO_ADDR)) + 0xc) = 0; \
-} while(0)
-
-#define NAND_ENABLE_CE(nand) do \
-{ \
- *(((volatile __u8 *)(nand-IO_ADDR)) + 0x8) = 0; \
-} while(0)
-
-#define NAND_CTL_CLRALE(nandptr) do \
-{ \
- *(((volatile __u8 *)nandptr) + 0x8) = 0; \
-} while(0)
-
-#define NAND_CTL_SETALE(nandptr) do \
-{ \
- *(((volatile __u8 *)nandptr) + 0x9) = 0; \
-} while(0)
-
-#define NAND_CTL_CLRCLE(nandptr) do \
-{ \
- *(((volatile __u8 *)nandptr) + 0x8) = 0; \
-} while(0)
-
-#define NAND_CTL_SETCLE(nandptr) do \
-{ \
- *(((volatile __u8 *)nandptr) + 0xa) = 0; \
-} while(0)
-
-#ifdef NAND_NO_RB
-/* constant delay (see also tR in the datasheet) */
-#define NAND_WAIT_READY(nand) do { \
- udelay(12); \
-} while (0)
-#else
-/* use the R/B pin */
-#endif
-
-#define WRITE_NAND_COMMAND(d, adr) do{
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Hello Then please write this in the commit message of the patch. It is already written in the ubifs patch (#2) Shall I also add this to this patch (#1), that only touches the gunzip file? Regards 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 Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick- les Worth). Which is to say that Europeans call him by name, but Americans call him by value. -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Dear Ricardo, In message aa76a2be0904270234y4635b4dbj7de80cac751a2...@mail.gmail.com you wrote: UBI fs blocks can be compresed in lzo, zlib or no-compression. The current implementation of u-boot supported all the compressions but there was a bug in the implementation of zlib. UBIFS's Zlib blocks do not have header but they were compressed using gunzip, a function used to decompress gunzip files/sectors with a header. This patch creates a functions that is able of decompress such a blocks. BTW: what is patch 2/2 of this series? According to the References: header it's [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib. But then, what is the second patch for the [PATCH 1/2] ubifs: BUG realpath string must be ended with NULL posting? In other words, we have 2 x [PATCH 1/2] but only one [PATCH 2/2] - or am I missing something? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, Metamorphosis, stardate 3219.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Sorry for the mess. There were 2 patch 1/2 -: BUG realpath string must be ended with NULL posting? 2/2 -ubifs: BUG: Blocks commpressed with zlib Since 1/2 has been applied. And 2/2 needed to be separated in two patches 1/2 - lib_generic: gunzip: New function zunzip 2/2 - ubifs: BUG: Blocks commpressed with zlib 1/2 Creates a new zunzip function and 2/2 calls it. On Mon, Apr 27, 2009 at 12:26, Wolfgang Denk w...@denx.de wrote: Dear Ricardo, In message aa76a2be0904270234y4635b4dbj7de80cac751a2...@mail.gmail.com you wrote: UBI fs blocks can be compresed in lzo, zlib or no-compression. The current implementation of u-boot supported all the compressions but there was a bug in the implementation of zlib. UBIFS's Zlib blocks do not have header but they were compressed using gunzip, a function used to decompress gunzip files/sectors with a header. This patch creates a functions that is able of decompress such a blocks. BTW: what is patch 2/2 of this series? According to the References: header it's [PATCH 2/2] ubifs: BUG: Blocks commpressed with zlib. But then, what is the second patch for the [PATCH 1/2] ubifs: BUG realpath string must be ended with NULL posting? In other words, we have 2 x [PATCH 1/2] but only one [PATCH 2/2] - or am I missing something? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, Metamorphosis, stardate 3219.8 -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Dear Ricardo Ribalda Delgado, In message aa76a2be0904270317h531e626bn4be3423963aa...@mail.gmail.com you wrote: Then please write this in the commit message of the patch. It is already written in the ubifs patch (#2) Shall I also add this to this patch (#1), that only touches the gunzip file? How should anybody know why the gunzip file gets changed if there is no explanation given at all in the commit message? How should he know that some other patch might be related when all he has is the commit logs? Please add an explanation to the patch that says what the patch is changing, and why. Please re-read http://www.denx.de/wiki/U-Boot/Patches It says: In the message body, include a description of your changes. * For bug fixes: a description of the bug and how your patch fixes this bug. Please try to include a way of demonstrating that the patch actually fixes something. * For new features: a description of the feature and your implementation. 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 How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say I told you so when it doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Dear Ricardo Ribalda Delgado, In message aa76a2be0904270234y4635b4dbj7de80cac751a2...@mail.gmail.com you wrote: UBI fs blocks can be compresed in lzo, zlib or no-compression. The current implementation of u-boot supported all the compressions but there was a bug in the implementation of zlib. UBIFS's Zlib blocks do not have header but they were compressed using gunzip, a function used to decompress gunzip files/sectors with a header. This patch creates a functions that is able of decompress such a blocks. Then please write this in the commit message of the patch. 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 Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick- les Worth). Which is to say that Europeans call him by name, but Americans call him by value. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
On Monday 27 April 2009, Ricardo Ribalda Delgado wrote: There were 2 patch 1/2 -: BUG realpath string must be ended with NULL posting? 2/2 -ubifs: BUG: Blocks commpressed with zlib Since 1/2 has been applied. And 2/2 needed to be separated in two patches Just to clarify: Patch 1/2 hasn't been applied yet. I only acked it. Wolfgang needs to apply it when he finds time. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ubifs: BUG realpath string must be ended with NULL
If the memory used to copy the link_make is dirty the string wont
be ended with NULL, throwing out multiple memory bugs.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 32f9ff8..427d84a 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -641,6 +641,7 @@ int ubifs_load(char *filename, u32 addr, u32 size)
ui = ubifs_inode(inode);
if (((inode-i_mode S_IFMT) == S_IFLNK) ui-data_len) {
memcpy(link_name, ui-data, ui-data_len);
+ link_name[ui-data_len] = '\0';
printf(%s is linked to %s!\n, filename, link_name);
ubifs_iput(inode);
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] lib_generic: gunzip: New function zunzip
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
UBI fs blocks can be compresed in lzo, zlib or no-compression. The
current implementation of u-boot supported all the compressions but
there was a bug in the implementation of the zlib blocks.
UBIFS's Zlib blocks do not have header but they were compressed using
gunzip, a function used to decompress gunzip files/sectors with a
header.
This patch adds a new function zunzip that uncompress a zlib block with
no header.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v2: Better doc
lib_generic/gunzip.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/lib_generic/gunzip.c b/lib_generic/gunzip.c
index 01a4031..d59a448 100644
--- a/lib_generic/gunzip.c
+++ b/lib_generic/gunzip.c
@@ -39,6 +39,8 @@
int gunzip(void *, int, unsigned char *, unsigned long *);
void *zalloc(void *, unsigned, unsigned);
void zfree(void *, void *, unsigned);
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset);
void *zalloc(void *x, unsigned items, unsigned size)
{
@@ -59,8 +61,7 @@ void zfree(void *x, void *addr, unsigned nb)
int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp)
{
- z_stream s;
- int r, i, flags;
+ int i, flags;
/* skip header */
i = 10;
@@ -84,6 +85,18 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
return (-1);
}
+ return zunzip(dst, dstlen, src, lenp, 1, i);
+}
+
+/*
+ * Uncompress blocks compressed with zlib without headers
+ */
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset)
+{
+ z_stream s;
+ int r;
+
s.zalloc = zalloc;
s.zfree = zfree;
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
@@ -95,14 +108,14 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
r = inflateInit2(s, -MAX_WBITS);
if (r != Z_OK) {
printf (Error: inflateInit2() returned %d\n, r);
- return (-1);
+ return -1;
}
- s.next_in = src + i;
- s.avail_in = *lenp - i;
+ s.next_in = src + offset;
+ s.avail_in = *lenp - offset;
s.next_out = dst;
s.avail_out = dstlen;
r = inflate(s, Z_FINISH);
- if (r != Z_STREAM_END) {
+ if ((r != Z_STREAM_END) (stoponerr==1)) {
printf (Error: inflate() returned %d\n, r);
inflateEnd(s);
return (-1);
@@ -110,5 +123,5 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
*lenp = s.next_out - (unsigned char *) dst;
inflateEnd(s);
- return (0);
+ return 0;
}
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ubifs: BUG: Blocks commpressed with zlib
Blocks compressed with zlib dont have the full gzip header.
Without this patch, block compressed with zlib cannot be readed!
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v3: rename patch 2- patch 3
v2: remove unused parts..
fs/ubifs/ubifs.c |7 +--
fs/ubifs/ubifs.h |2 --
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 427d84a..739fb04 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -24,6 +24,7 @@
*/
#include ubifs.h
+#include u-boot/zlib.h
#if !defined(CONFIG_SYS_64BIT_VSPRINTF)
#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
@@ -33,15 +34,17 @@ DECLARE_GLOBAL_DATA_PTR;
/* compress.c */
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset);
/*
- * We need a wrapper for gunzip() because the parameters are
+ * We need a wrapper for zunzip() because the parameters are
* incompatible with the lzo decompressor.
*/
static int gzip_decompress(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
{
unsigned long len = in_len;
- return gunzip(out, *out_len, (unsigned char *)in, len);
+ return zunzip(out, *out_len, (unsigned char *)in, len, 0, 0);
}
/* Fake description object for the none compressor */
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 91351de..a68e4c1 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -2172,6 +2172,4 @@ int ubifs_decompress(const void *buf, int len, void *out,
int *out_len,
/* todo: Move these to a common U-Boot header */
int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len);
-int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp);
-
#endif /* !__UBIFS_H__ */
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib_generic: gunzip: New function zunzip
Dear Ricardo Ribalda Delgado, In message aa76a2be0904270333j75bc9489p74071622499db...@mail.gmail.com you wrote: Sorry for the mess. There were 2 patch 1/2 -: BUG realpath string must be ended with NULL posting? 2/2 -ubifs: BUG: Blocks commpressed with zlib Since 1/2 has been applied. And 2/2 needed to be separated in two patches The realpath string must be ended with NULL has been applied? This is news to me. I don't have it in my trees. Please explain what you mean? 1/2 - lib_generic: gunzip: New function zunzip 2/2 - ubifs: BUG: Blocks commpressed with zlib In such a situation it would have been much better if you has reposted a new patch series consisting of 3 parts (1/3, 2/3 and 3/3). On Mon, Apr 27, 2009 at 12:26, Wolfgang Denk w...@denx.de wrote: Dear Ricardo, In message aa76a2be0904270234y4635b4dbj7de80cac751a2...@mail.gmail.com = you wrote: ... PLEASE STOP TOP POSTING and FULL QUOTING. PLEASE STOP TOP POSTING and FULL QUOTING. PLEASE STOP TOP POSTING and FULL QUOTING. PLEASE STOP TOP POSTING and FULL QUOTING. PLEASE STOP TOP POSTING and FULL QUOTING. 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 father doesn't destroy his children. -- Lt. Carolyn Palamas, Who Mourns for Adonais?, stardate 3468.1. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ubifs: BUG realpath string must be ended with NULL
Dear Ricardo Ribalda Delgado,
In message 1240831297-15862-1-git-send-email-ricardo.riba...@uam.es you wrote:
If the memory used to copy the link_make is dirty the string wont
be ended with NULL, throwing out multiple memory bugs.
What is link_make ? Do you mean link_name ?
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 32f9ff8..427d84a 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -641,6 +641,7 @@ int ubifs_load(char *filename, u32 addr, u32 size)
ui = ubifs_inode(inode);
if (((inode-i_mode S_IFMT) == S_IFLNK) ui-data_len) {
memcpy(link_name, ui-data, ui-data_len);
+ link_name[ui-data_len] = '\0';
printf(%s is linked to %s!\n, filename, link_name);
ubifs_iput(inode);
--
1.6.2.4
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
Unix is like a toll road on which you have to stop every 50 feet to
pay another nickel. But hey! You only feel 5 cents poorer each time.
- Larry Wall in 1992aug13.192357.15...@netlabs.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] lib_generic: gunzip: New function zunzip
Dear Ricardo Ribalda Delgado,
In message 1240831297-15862-2-git-send-email-ricardo.riba...@uam.es you wrote:
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
UBI fs blocks can be compresed in lzo, zlib or no-compression. The
current implementation of u-boot supported all the compressions but
there was a bug in the implementation of the zlib blocks.
UBIFS's Zlib blocks do not have header but they were compressed using
gunzip, a function used to decompress gunzip files/sectors with a
header.
This patch adds a new function zunzip that uncompress a zlib block with
no header.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
...
- if (r != Z_STREAM_END) {
+ if ((r != Z_STREAM_END) (stoponerr==1)) {
I already asked about this change, which ios unrelated to this patch.
Please explain why this is needed, and why you think this should not
be split off into a separate commit?
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
More software projects have gone awry for lack of calendar time than
for all other causes combined.
- Fred Brooks, Jr., _The Mythical Man Month_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ubifs: BUG: Blocks commpressed with zlib
Dear Ricardo Ribalda Delgado,
In message 1240831297-15862-3-git-send-email-ricardo.riba...@uam.es you wrote:
Blocks compressed with zlib dont have the full gzip header.
Without this patch, block compressed with zlib cannot be readed!
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
...
#include ubifs.h
+#include u-boot/zlib.h
#if !defined(CONFIG_SYS_64BIT_VSPRINTF)
#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
@@ -33,15 +34,17 @@ DECLARE_GLOBAL_DATA_PTR;
/* compress.c */
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset);
The prototype declaration should be in the neader file. Please remove
here.
- * We need a wrapper for gunzip() because the parameters are
+ * We need a wrapper for zunzip() because the parameters are
* incompatible with the lzo decompressor.
*/
static int gzip_decompress(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
{
unsigned long len = in_len;
- return gunzip(out, *out_len, (unsigned char *)in, len);
+ return zunzip(out, *out_len, (unsigned char *)in, len, 0, 0);
}
If the only purpose of zunzip() is to be used here, then why do we not
make the parameters fit the intended purpose, thus avoiding an
additional wrapper?
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
panic: kernel trap (ignored)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision board/omap3/beagle/beagle.h|2 - board/omap3/evm/evm.h |2 - board/omap3/overo/overo.h |2 - board/omap3/pandora/pandora.h |2 - board/omap3/zoom1/zoom1.h |2 - cpu/arm_cortexa8/cpu.c |4 +- cpu/arm_cortexa8/omap3/board.c | 24 - cpu/arm_cortexa8/omap3/clock.c |5 +- cpu/arm_cortexa8/omap3/sys_info.c | 145 +++- include/asm-arm/arch-omap3/omap3.h | 22 ++--- include/asm-arm/arch-omap3/sys_proto.h |4 - include/configs/omap3_beagle.h |6 ++ include/configs/omap3_evm.h|7 ++- include/configs/omap3_overo.h |6 ++ include/configs/omap3_pandora.h|6 ++ include/configs/omap3_zoom1.h |6 ++ 16 files changed, 131 insertions(+), 114 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv3 1/3] OMAP3: Use functions print_cpuinfo() and checkboard()
Use the functions print_cpuinfo() and checkboard() to
display the cpu and board specific information.
These functions reuse content from the existing function
display_board_info() - which has been removed.
Also, updated the existig OMAP3 configurations to
define:
- CONFIG_DISPLAY_CPUINFO
- CONFIG_DISPLAY_BOARDINFO
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/board.c | 24 ++--
cpu/arm_cortexa8/omap3/sys_info.c | 103 +++-
include/asm-arm/arch-omap3/sys_proto.h |1 -
include/configs/omap3_beagle.h |6 ++
include/configs/omap3_evm.h|7 ++-
include/configs/omap3_overo.h |6 ++
include/configs/omap3_pandora.h|6 ++
include/configs/omap3_zoom1.h |6 ++
8 files changed, 97 insertions(+), 62 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 15ea936..22dbe08 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -272,11 +272,6 @@ int dram_init(void)
{
DECLARE_GLOBAL_DATA_PTR;
unsigned int size0 = 0, size1 = 0;
- u32 btype;
-
- btype = get_board_type();
-
- display_board_info(btype);
/*
* If a second bank of DDR is attached to CS1 this is
@@ -342,3 +337,22 @@ U_BOOT_CMD(
);
#endif /* CONFIG_NAND_OMAP_GPMC */
+
+#ifdef CONFIG_DISPLAY_BOARDINFO
+/**
+ * Print board information
+ */
+int checkboard (void)
+{
+ char *mem_s ;
+
+ if (is_mem_sdr())
+ mem_s = mSDR;
+ else
+ mem_s = LPDDR;
+
+ printf(%s + %s/%s\n, sysinfo.board_string, mem_s,
+ sysinfo.nand_string);
+
+}
+#endif /* CONFIG_DISPLAY_BOARDINFO */
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..f13f0be 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -185,61 +185,6 @@ u32 get_board_rev(void)
return 0x20;
}
-/*
- * display_board_info() - print banner with board info.
- */
-void display_board_info(u32 btype)
-{
- char *cpu_s, *mem_s, *sec_s;
-
- switch (get_cpu_type()) {
- case OMAP3503:
- cpu_s = 3503;
- break;
- case OMAP3515:
- cpu_s = 3515;
- break;
- case OMAP3525:
- cpu_s = 3525;
- break;
- case OMAP3530:
- cpu_s = 3530;
- break;
- default:
- cpu_s = 35XX;
- break;
- }
-
- if (is_mem_sdr())
- mem_s = mSDR;
- else
- mem_s = LPDDR;
-
- switch (get_device_type()) {
- case TST_DEVICE:
- sec_s = TST;
- break;
- case EMU_DEVICE:
- sec_s = EMU;
- break;
- case HS_DEVICE:
- sec_s = HS;
- break;
- case GP_DEVICE:
- sec_s = GP;
- break;
- default:
- sec_s = ?;
- }
-
-
- printf(OMAP%s-%s rev %d, CPU-OPP2 L3-165MHz\n, cpu_s,
- sec_s, get_cpu_rev());
- printf(%s + %s/%s\n, sysinfo.board_string,
- mem_s, sysinfo.nand_string);
-
-}
-
/
* get_base(); get upper addr of current execution
***/
@@ -305,3 +250,51 @@ u32 get_device_type(void)
{
return ((readl(ctrl_base-status) (DEVICE_MASK)) 8);
}
+
+#ifdef CONFIG_DISPLAY_CPUINFO
+/**
+ * Print CPU information
+ */
+int print_cpuinfo (void)
+{
+ char *cpu_s, *sec_s;
+
+ switch (get_cpu_type()) {
+ case OMAP3503:
+ cpu_s = 3503;
+ break;
+ case OMAP3515:
+ cpu_s = 3515;
+ break;
+ case OMAP3525:
+ cpu_s = 3525;
+ break;
+ case OMAP3530:
+ cpu_s = 3530;
+ break;
+ default:
+ cpu_s = 35XX;
+ break;
+ }
+
+ switch (get_device_type()) {
+ case TST_DEVICE:
+ sec_s = TST;
+ break;
+ case EMU_DEVICE:
+ sec_s = EMU;
+ break;
+ case HS_DEVICE:
+ sec_s = HS;
+ break;
+ case GP_DEVICE:
+ sec_s = GP;
+ break;
+ default:
+ sec_s = ?;
+ }
+
+ printf(OMAP%s-%s rev %d, CPU-OPP2 L3-165MHz\n, cpu_s,
+ sec_s, get_cpu_rev());
+}
+#endif /* CONFIG_DISPLAY_CPUINFO */
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index 8b554bb..830447b 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++
[U-Boot] [PATCHv3 2/3] OMAP3: Remove unused board-types
The board-types defined in struct omap3_sysinfo seem to be
unused. The function display_board_info() is passed
board type as an argument; which is ignored.
This patch removes all uses of board-type, related definitions
and functions.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/omap3/beagle/beagle.h|2 --
board/omap3/evm/evm.h |2 --
board/omap3/overo/overo.h |2 --
board/omap3/pandora/pandora.h |2 --
board/omap3/zoom1/zoom1.h |2 --
cpu/arm_cortexa8/omap3/sys_info.c | 17 -
include/asm-arm/arch-omap3/omap3.h |8
include/asm-arm/arch-omap3/sys_proto.h |3 ---
8 files changed, 0 insertions(+), 38 deletions(-)
diff --git a/board/omap3/beagle/beagle.h b/board/omap3/beagle/beagle.h
index d66f159..5d45f01 100644
--- a/board/omap3/beagle/beagle.h
+++ b/board/omap3/beagle/beagle.h
@@ -24,8 +24,6 @@
#define _BEAGLE_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
OMAP3 Beagle board,
#if defined(CONFIG_ENV_IS_IN_ONENAND)
diff --git a/board/omap3/evm/evm.h b/board/omap3/evm/evm.h
index 199824f..4a82a7f 100644
--- a/board/omap3/evm/evm.h
+++ b/board/omap3/evm/evm.h
@@ -24,8 +24,6 @@
#define _EVM_H_
const omap3_sysinfo sysinfo = {
- OMAP3EVM_V1,
- OMAP3EVM_V2,
DDR_DISCRETE,
OMAP3 EVM board,
#if defined(CONFIG_ENV_IS_IN_ONENAND)
diff --git a/board/omap3/overo/overo.h b/board/omap3/overo/overo.h
index e8ccc1d..b595f6a 100644
--- a/board/omap3/overo/overo.h
+++ b/board/omap3/overo/overo.h
@@ -24,8 +24,6 @@
#define _OVERO_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
Gumstix Overo board,
#if defined(CONFIG_ENV_IS_IN_ONENAND)
diff --git a/board/omap3/pandora/pandora.h b/board/omap3/pandora/pandora.h
index dd09f12..8f0838c 100644
--- a/board/omap3/pandora/pandora.h
+++ b/board/omap3/pandora/pandora.h
@@ -24,8 +24,6 @@
#define _PANDORA_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
OMAP3 Pandora,
NAND,
diff --git a/board/omap3/zoom1/zoom1.h b/board/omap3/zoom1/zoom1.h
index bc8fba8..4f49a41 100644
--- a/board/omap3/zoom1/zoom1.h
+++ b/board/omap3/zoom1/zoom1.h
@@ -28,8 +28,6 @@
#define _BOARD_ZOOM1_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
OMAP3 Zoom MDK Rev 1,
NAND,
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index f13f0be..3f7b5e4 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -130,23 +130,6 @@ u32 get_sdr_cs_offset(u32 cs)
return offset;
}
-/***
- * get_board_type() - get board type based on current production stats.
- * - NOTE-1-: 2 I2C EEPROMs will someday be populated with proper info.
- *when they are available we can get info from there. This should
- *be correct of all known boards up until today.
- * - NOTE-2- EEPROMs are populated but they are updated very slowly. To
- *avoid waiting on them we will use ES version of the chip to get info.
- *A later version of the FPGA migth solve their speed issue.
- /
-u32 get_board_type(void)
-{
- if (get_cpu_rev() == CPU_3430_ES2)
- return sysinfo.board_type_v2;
- else
- return sysinfo.board_type_v1;
-}
-
/***
* get_gpmc0_base() - Return current address hardware will be
* fetching from. The below effectively gives what is correct, its a bit
diff --git a/include/asm-arm/arch-omap3/omap3.h
b/include/asm-arm/arch-omap3/omap3.h
index 8c9656f..d0d2737 100644
--- a/include/asm-arm/arch-omap3/omap3.h
+++ b/include/asm-arm/arch-omap3/omap3.h
@@ -177,14 +177,6 @@ typedef struct gpio {
#define WIDTH_8BIT 0x
#define WIDTH_16BIT0x1000 /* bit pos for 16 bit in gpmc */
-/* SDP definitions according to FPGA Rev. Is this OK?? */
-#define SDP_3430_V10x1
-#define SDP_3430_V20x2
-
-/* EVM definitions */
-#define OMAP3EVM_V10x1
-#define OMAP3EVM_V20x2
-
/* I2C power management companion definitions */
#define PWRMGT_ADDR_ID10x48
#define PWRMGT_ADDR_ID20x49
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index 830447b..7361d08 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -22,8 +22,6 @@
#define _SYS_PROTO_H_
typedef struct {
- u32 board_type_v1;
- u32 board_type_v2;
u32 mtype;
char *board_string;
char *nand_string;
@@ -46,7 +44,6 @@ u32
[U-Boot] [PATCHv3 3/3] OMAP3: Print correct silicon revision
The function display_board_info() displays incorrect
silicon revision - based on the return value from
function get_cpu_rev().
This patch fixes the problem.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/cpu.c |4 ++--
cpu/arm_cortexa8/omap3/clock.c |5 +++--
cpu/arm_cortexa8/omap3/sys_info.c | 29 ++---
include/asm-arm/arch-omap3/omap3.h | 14 +-
4 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/cpu/arm_cortexa8/cpu.c b/cpu/arm_cortexa8/cpu.c
index 5e7b935..3e1780b 100644
--- a/cpu/arm_cortexa8/cpu.c
+++ b/cpu/arm_cortexa8/cpu.c
@@ -101,7 +101,7 @@ void l2cache_enable()
volatile unsigned int j;
/* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() == CPU_3430_ES2) {
+ if (get_cpu_rev() = CPU_3XX_ES20) {
__asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
__asm__ __volatile__(orr %0, %0, #0x2:=r(i));
__asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
@@ -131,7 +131,7 @@ void l2cache_disable()
volatile unsigned int j;
/* ES2 onwards we can disable/enable L2 ourselves */
- if (get_cpu_rev() == CPU_3430_ES2) {
+ if (get_cpu_rev() = CPU_3XX_ES20) {
__asm__ __volatile__(mrc p15, 0, %0, c1, c0, 1:=r(i));
__asm__ __volatile__(bic %0, %0, #0x2:=r(i));
__asm__ __volatile__(mcr p15, 0, %0, c1, c0, 1:=r(i));
diff --git a/cpu/arm_cortexa8/omap3/clock.c b/cpu/arm_cortexa8/omap3/clock.c
index 8ac31be..d035677 100644
--- a/cpu/arm_cortexa8/omap3/clock.c
+++ b/cpu/arm_cortexa8/omap3/clock.c
@@ -132,7 +132,7 @@ void prcm_init(void)
void (*f_lock_pll) (u32, u32, u32, u32);
int xip_safe, p0, p1, p2, p3;
u32 osc_clk = 0, sys_clkin_sel;
- u32 clk_index, sil_index;
+ u32 clk_index, sil_index = 0;
prm_t *prm_base = (prm_t *)PRM_BASE;
prcm_t *prcm_base = (prcm_t *)PRCM_BASE;
dpll_param *dpll_param_p;
@@ -170,7 +170,8 @@ void prcm_init(void)
* and sil_index will get the values for that SysClk for the
* appropriate silicon rev.
*/
- sil_index = get_cpu_rev() - 1;
+ if (get_cpu_rev())
+ sil_index = 1;
/* Unlock MPU DPLL (slows things down, and needed later) */
sr32(prcm_base-clken_pll_mpu, 0, 3, PLL_LOW_POWER_BYPASS);
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 3f7b5e4..39a48a1 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -35,6 +35,12 @@ extern omap3_sysinfo sysinfo;
static gpmc_csx_t *gpmc_cs_base = (gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char *rev_s[CPU_3XX_MAX_REV] = {
+ 1.0,
+ 2.0,
+ 2.1,
+ 3.0,
+ 3.1};
/*
* dieid_num_r(void) - read and set die ID
@@ -76,18 +82,27 @@ u32 get_cpu_type(void)
u32 get_cpu_rev(void)
{
u32 cpuid = 0;
+ ctrl_id_t *id_base;
/*
* On ES1.0 the IDCODE register is not exposed on L4
-* so using CPU ID to differentiate
-* between ES2.0 and ES1.0.
+* so using CPU ID to differentiate between ES1.0 and ES1.0.
*/
__asm__ __volatile__(mrc p15, 0, %0, c0, c0, 0:=r(cpuid));
if ((cpuid 0xf) == 0x0)
- return CPU_3430_ES1;
- else
- return CPU_3430_ES2;
+ return CPU_3XX_ES10;
+ else {
+ /* Decode the IDs on ES1.0 */
+ id_base = (ctrl_id_t *) OMAP34XX_ID_L4_IO_BASE;
+ cpuid = (readl(id_base-idcode) CPU_3XX_ID_SHIFT) 0xf;
+
+ /* Some early ES2.0 seem to report ID 0, fix this */
+ if(cpuid == 0)
+ cpuid = CPU_3XX_ES20;
+
+ return cpuid;
+ }
}
/
@@ -277,7 +292,7 @@ int print_cpuinfo (void)
sec_s = ?;
}
- printf(OMAP%s-%s rev %d, CPU-OPP2 L3-165MHz\n, cpu_s,
- sec_s, get_cpu_rev());
+ printf(OMAP%s-%s ES%s, CPU-OPP2 L3-165MHz\n,
+ cpu_s, sec_s, rev_s[get_cpu_rev()]);
}
#endif /* CONFIG_DISPLAY_CPUINFO */
diff --git a/include/asm-arm/arch-omap3/omap3.h
b/include/asm-arm/arch-omap3/omap3.h
index d0d2737..7c11019 100644
--- a/include/asm-arm/arch-omap3/omap3.h
+++ b/include/asm-arm/arch-omap3/omap3.h
@@ -167,12 +167,16 @@ typedef struct gpio {
* 343x real hardware:
* ES1 = rev 0
*
- * 343x code defines:
- * ES1 = 0+1 = 1
- * ES1 = 1+1 = 1
+ * ES2 onwards, the value maps to contents of IDCODE
[U-Boot] NAND JFFS2 support in U-Boot 2009.03
Hi, In previous versions of U-Boot, there were options for writing JFFS2 file systems to NAND (i.e., nand write.jffs2). Is this command no longer supported in the latest U-Boot release or is the command the same as the nand write command? In other words, was there something special about the nand write.jffs2 command? or is the same thing accomplished by just doing a nand write command and specifying the RAM address where a JFFS2 filesystem was downloaded? Thanks. Christopher M. Fairfax Sr. Software Engineer Rockwell Collins +1 540-428-3344 +1 540-428-3301 cmfai...@rockwellcollins.com This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee(s) named above. Any disclosure, distribution, copying or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include/ns16550.h: Unify structure declaration for registers
Dear Shinya,
Detlev Zundel wrote:
Instead of special casing the different access patterns, use common
code with light macros sprinkled in to accomodate for the different
layouts of the register structure.
Note that this also changes the types of the registers for the
positively packed (1) cases. As the registers truly are unsigned
chars, this is surely the Right Thing, but it is a semantic change.
Note that for this case depending on the endianness on the bus, we may
see a change of behaviour.
Signed-off-by: Detlev Zundel d...@denx.de
---
include/ns16550.h | 130
+++--
1 files changed, 37 insertions(+), 93 deletions(-)
Note, that I checked that the offsets are ok in the used cases
switching from the old to the new code. They *do* shift however in
the positive packed cases, because the old code uses data types
different than unsigned char. Note that doing this, I also noticed
that using unsigned long for 4 byte registers is also no longer true
on 64-bit architectures. One more reason to change the code.
Apart from that the code was also compile tested on several
configurations using different REG_SIZES and compiles without
warnings. The special interesting case of +4 was successfully tested
on CU824.
My hardware required 32-bit word access to NS16550 registers due to
byte-enable-lane reason (note that it's different from endian-ness).
I mean,
struct NS16550 {
unsigned char rbr;
unsigned char postpad_rbr[15];
:
:
};
if different from
struct NS16550 {
unsigned long rbr;
unsigned long postpad_rbr[3];
:
:
};
, at least for my hardware.
To be honest, I did not expect such problems, as I saw no hints from
comments on why this code was needed. Thinking afresh, it now makes at
least some sense why the code was. It nevertheless was inconsistent, as
the word access was only done in an asymmetric way regarding the
REG_SIZES parameter.
How do I supposed to configure UART in my board config file?
I'm not sure at all. I believe you tested with 4 and -4 and it doesn't
work, right?
Now we have the problem that we have byte registers (after all, there
are only 8 bits significant even for your platform) which need to be
accessed as 32-bit entities (or 16 bit for other platforms maybe).
I don't see any way out here than to probably re-introduce different
data-types again - which I certainly do not like too much as the
registers stay 8 bit wide.
Does anyone else have a good idea here?
Thanks
Detlev
--
Oh, didn't you know, the Lord did the original programming of the universe in
COBOL. - That's why the world is the evil work of Satan. A true divine being
would have used Scheme. - And, if so, Jesus would have been crucified on a
big lambda symbol. -- K. Chafin, K. Schilling D. Hanley, on comp.lang.lisp
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
Wolfgang Denk wrote: Dear David Brownell, In message 200904250105.41050.davi...@pacbell.net you wrote: Yes. The issue is needing to guess what's up ... so for example, I seem to observe that merge window closed must not be the same as first RC is out, which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work... Maybe I pout a little more meaning in the words release candiate. After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a release candiate. That's why we still have no rc in the current release cycle. Best regards, Wolfgang Denk Make sense on rc not really being a release candidate. How about tagging mc for Merge Closed? gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] reg. Ethernet operation
Hi experts, I just wanted to do some testing on ethernet driver in Uboot. I have a small program that will send a binary file through ethernet. But I don't have any clue on how to receive those packets in U-boot. I mean what are the API's to be used. It will be helpful if you could tell me how to do that in U-boot. Another thing is My target board is connected to eth1 of my host and i am able to ping the host from target saying it's alive. But i am not able to ping the target from the host. Does it mean, the target is restricted to send icmp responses back to host? Best Regards, Murali This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace's standard terms and conditions of sale which may have been provided to you, or in any event are available at http://www.pace.com/uktcsale.pdf (ii) all orders for goods and/or services placed by Pace are subject to Pace's standard terms and conditions of purchase which may have been provided to you, or in any event are available at http://www.pace.com/uktcpurch.pdf. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips
Dear Jerry Van Baren, In message 49f5b6af.5060...@ge.com you wrote: Maybe I pout a little more meaning in the words release candiate. After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a release candiate. That's why we still have no rc in the current release cycle. ... Make sense on rc not really being a release candidate. How about tagging mc for Merge Closed? OK - but we have not reached that state either yet, I think. As mentioned before, I have a problem to relate a deadline thing without any direct impact on the code (as the closing of the merge window) to a git tag which represents a certain state. Merge Closed definitely represents such a state, but then we could issue -rc1 as well (using the same free interpretation as in Linux), and it would not indicate what has been asked for: the closinf of the MW. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ... The prejudices people feel about each other disappear when then get to know each other. -- Kirk, Elaan of Troyius, stardate 4372.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] reg. Ethernet operation
Dear Muralitharan Perumal, In message 49f5b80b.2090...@pace.com you wrote: I just wanted to do some testing on ethernet driver in Uboot. I have a You may want to look into the Ethenret related POST code in U-Boot. small program that will send a binary file through ethernet. But I don't have any clue on how to receive those packets in U-boot. I mean what are the API's to be used. It will be helpful if you could tell me how to do that in U-boot. Why don't you just perform a TFTP and/or NFS file transfer? You can then check the file integrity for example using some checksumming - if you transfer a mkimage created image, this even comes for free. Another thing is My target board is connected to eth1 of my host and i am able to ping the host from target saying it's alive. But i am not able to ping the target from the host. Does it mean, the target is restricted to send icmp responses back to host? Please read the doc. U-Boot does not reply to OCMP packets. This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail o Please omit this crap when posting to a public mailing list. 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 believe the use of noise to make music will increase until we reach a music produced through the aid of electrical instruments which will make available for musical purposes any and all sounds that can be heard.- composer John Cage, 1937 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PCI on mpc832x?
On Apr 24, 2009, at 9:11 AM, Joakim Tjernlund wrote: Scott Wood scottw...@freescale.com wrote on 23/04/2009 18:40:01: On Thu, Apr 23, 2009 at 03:32:11PM +0200, Joakim Tjernlund wrote: Still trying to wrap my head around PCI and I wonder if I need to do some HW init in u-boot in order to use the PCI controller in Linux? Yes. See pci_init_board() in mpc8323erdb for an example. Thanks Scott, this was very helpful. I am trying to map the ranges property in the OF tree and I am looking at the dts files in the kernel tree. There are three that comes somewhat close but they all have somewhat different ranges propery: mpc832x_mds.dts: ranges = 0x0200 0x0 0x9000 0x9000 0x0 0x1000 this is PCI MMIO non-prefetch @ 0x9000 (cpu pci) of size 256M 0x4200 0x0 0x8000 0x8000 0x0 0x1000 this is PCI MMIO prefetch @ 0x8000 (cpu pci) of size 256M 0x0100 0x0 0x 0xd000 0x0 0x0010; this is PCI IO @ @ cpu phy 0xd000 pci io 0x0 of size 1M mpc832x_rdb.dts: ranges = 0x4200 0x0 0x8000 0x8000 0x0 0x1000 0x0200 0x0 0x9000 0x9000 0x0 0x1000 0x0100 0x0 0xd000 0xd000 0x0 0x0400; mpc8313erdb.dts: ranges = 0x0200 0x0 0x9000 0x9000 0x0 0x1000 0x4200 0x0 0x8000 0x8000 0x0 0x1000 0x0100 0x0 0x 0xe200 0x0 0x0010; Don't understand how I should do here. Just select the mpc832x_rdb.dts ranges and define my base addresses similarly? #define CFG_PCI1_MEM_BASE 0x8000 #define CFG_PCI1_MEM_PHYS CFG_PCI1_MEM_BASE #define CFG_PCI1_MEM_SIZE 0x1000 /* 256M */ #define CFG_PCI1_MMIO_BASE0x9000 #define CFG_PCI1_MMIO_PHYSCFG_PCI1_MMIO_BASE #define CFG_PCI1_MMIO_SIZE0x1000/* 256M */ #define CFG_PCI1_IO_BASE0xd000 #define CFG_PCI1_IO_PHYSCFG_PCI1_IO_BASE #define CFG_PCI1_IO_SIZE0x400 /* 64M */ this is overkill for IO, 64k is the max. (its probably inherited when we didn't know better). - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include/ns16550.h: Unify structure declaration for registers
Detlev Zundel wrote:
To be honest, I did not expect such problems, as I saw no hints from
comments on why this code was needed. Thinking afresh, it now makes at
least some sense why the code was. It nevertheless was inconsistent, as
the word access was only done in an asymmetric way regarding the
REG_SIZES parameter.
I used to define locally long + -16 variants.
How do I supposed to configure UART in my board config file?
I'm not sure at all. I believe you tested with 4 and -4 and it doesn't
work, right?
Right.
Now we have the problem that we have byte registers (after all, there
are only 8 bits significant even for your platform) which need to be
accessed as 32-bit entities (or 16 bit for other platforms maybe).
This is why Linux 8250 driver supports not only UPIO_MEM but also
UPIO_MEM32.
I don't see any way out here than to probably re-introduce different
data-types again - which I certainly do not like too much as the
registers stay 8 bit wide.
If there's no good alternatives, I think reverting is a good idea
because there must be other platforms affected by this change.
Does anyone else have a good idea here?
Hm, how about introducing serial_{in,out} concepts from Linux?
Shinya
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On Sun, Apr 26, 2009 at 11:14:06PM -0400, Mike Frysinger wrote: On Tuesday 21 April 2009 07:13:10 Daniel Mack wrote: On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote: Not if the MAC is stored in the volatile smc911x registers. Issuing a soft reset flushes these values - if U-Boot does that, the OS has no change getting them. then either your u-boot or your OS is misconfigured and you need to fix that. as clearly stated in docs/README.enetaddr, the environment is the place where mac addresses live when there is no dedicated storage (like an eeprom). ignoring that, the mac address doesnt magically get programmed. if no network operation was initiated, then the part wouldnt have been programmed anyways, so you're still left with an OS that cant get itself functional. Ok, true. Thanks for pointing this out. usually what i suggest to people are things like: - pass $(ethaddr) via kernel command line and parse /proc/cmdline - use the u-boot tools to read the u-boot env directly - set the hw address with `ifconfig` or similar tool ... which doesn't help much when it's about booting from NFS root. The particular problem here is that the MAC changes from what it's set to in U-Boot during the TFTP transaction and the randomly chosen one in Linux (which takes place because after the reset, the MAC is all 0xff). And that in turn confuses the ARP caches on other hosts. My patch solves that issue for that very case; that's why it's still in my local tree. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: Pending patches
Short status update after recent merges and patch updates. As usual, please correct if anything is wrong or missing. Dirk Behme wrote: To avoid loosing the overview, here my list of pending OMAP3 patches ready to be applied. From my point of view there are no open comments on these which will prevent to apply them. But please correct if I overlooked anything or add what (patches? comments?) I missed. 1. OMAP3: Beagle: Set pinmux conditionally for Rev C boards http://lists.denx.de/pipermail/u-boot/2009-April/051013.html Mail http://lists.denx.de/pipermail/u-boot/2009-April/051459.html tells us that this should be applied to u-boot-arm next. But I can't find it in gitweb http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next Did I miss something? Btw.: As initial patch and first update was sent ~1 day after merge window close (Apr 4?) I hoped to have a chance to still get it into master ;( 2. OMAP3: Remove legacy NAND defines http://lists.denx.de/pipermail/u-boot/2009-April/050882.html Applied to u-boot-arm next. Request to move to master by Wolfgang. 3. OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000 http://lists.denx.de/pipermail/u-boot/2009-April/051178.html 4. OMAP3: Fix changed mmc init command http://lists.denx.de/pipermail/u-boot/2009-April/051179.html Applied to u-boot-arm master. 5. OMAP3: Remove unused board-types http://lists.denx.de/pipermail/u-boot/2009-April/051338.html 6. OMAP3: Print correct silicon revision http://lists.denx.de/pipermail/u-boot/2009-April/051339.html Patches 5 6 replaced by update which includes switch to checkboard and print_cpuinfo: OMAP3: Board specific updates (3 patches) http://lists.denx.de/pipermail/u-boot/2009-April/051505.html http://lists.denx.de/pipermail/u-boot/2009-April/051506.html http://lists.denx.de/pipermail/u-boot/2009-April/051507.html 7. Zoom2 respin II (10 patches) Note: Initial patch series for this was sent 'Wed Apr 1 18:08:38 CEST 2009' http://lists.denx.de/pipermail/u-boot/2009-April/050094.html IMHO this was while open merge window. http://lists.denx.de/pipermail/u-boot/2009-April/050863.html http://lists.denx.de/pipermail/u-boot/2009-April/050864.html http://lists.denx.de/pipermail/u-boot/2009-April/050865.html http://lists.denx.de/pipermail/u-boot/2009-April/050866.html http://lists.denx.de/pipermail/u-boot/2009-April/050868.html http://lists.denx.de/pipermail/u-boot/2009-April/050867.html Applied to u-boot-arm next (see comment about merge window above). http://lists.denx.de/pipermail/u-boot/2009-April/050869.html Applied to u-boot-arm next (see comment about merge window above). http://lists.denx.de/pipermail/u-boot/2009-April/050870.html http://lists.denx.de/pipermail/u-boot/2009-April/050871.html Applied to u-boot-arm next. Request to move to master by Wolfgang. http://lists.denx.de/pipermail/u-boot/2009-April/050872.html For the rest of the Zoom2 patches (#1, #2, #3, #4, #5, #8 #10) http://lists.denx.de/pipermail/u-boot/2009-April/051383.html http://lists.denx.de/pipermail/u-boot/2009-April/051384.html http://lists.denx.de/pipermail/u-boot/2009-April/051385.html http://lists.denx.de/pipermail/u-boot/2009-April/051386.html http://lists.denx.de/pipermail/u-boot/2009-April/051455.html seem to apply. Note: There might be some dependencies between some of these patches. Different authors, sent at different time, unfortunately this can't be avoided. So dependent on the order the patches will be applied, there might be some conflicts. Let us know them, we will try to update/fix then as soon as possible! Most probably 5. and 7. will have some conflicts, as 5. removes some code 7. assumes it is still there. If this results in a conflict, let us apply the 10 patches from 7. first and then update 5. Many thanks and best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:29 Tue 21 Apr , Dirk Behme wrote: From: Manikandan Pillai mani.pil...@ti.com Signed-off-by: Dirk Behme dirk.be...@googlemail.com Signed-off-by: Manikandan Pillai mani.pil...@ti.com --- as Request precedently switch to 12Mhz source clock or As answered already in (unanswered) http://lists.denx.de/pipermail/u-boot/2009-April/050078.html switch to 12MHz will have a larger code and implementation impact while we won't win anything compared to well tested 13MHz usage http://lists.denx.de/pipermail/u-boot/2009-April/051258.html please specify the timer resolution precision of your implementation and put in the commit message code It seems to me that you mix here OMAP1 and OMAP3 patches? I remember about http://lists.denx.de/pipermail/u-boot/2009-April/051271.html which is regarding arm925/OMAP1 changes, not OMAP3 patch. I can't remember anything similar regarding OMAP3 patch. And similar comment for OMAP3 patch wouldn't make sense as http://lists.denx.de/pipermail/u-boot/2009-April/051178.html has clear info + * We run the counter with 13MHz, divided by 8, resulting in timer + * frequency of 1.625MHz. With 32bit counter register, counter + * overflows in ~44min Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
Hi Premi, Sanjeev Premi wrote: This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision Applying all 3 patches I get sys_info.c: In function 'print_cpuinfo': sys_info.c:297: warning: no return statement in function returning non-void board.c: In function 'checkboard': board.c:349: warning: implicit declaration of function 'is_mem_sdr' board.c:357: warning: no return statement in function returning non-void Not sure which patch it is, though. Best regards Dirk Btw.: You can easily check this by doing a ./MAKEALL ARM_CORTEX_A8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
-Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Monday, April 27, 2009 8:47 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates Hi Premi, Sanjeev Premi wrote: This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision Applying all 3 patches I get sys_info.c: In function 'print_cpuinfo': sys_info.c:297: warning: no return statement in function returning non-void board.c: In function 'checkboard': board.c:349: warning: implicit declaration of function 'is_mem_sdr' board.c:357: warning: no return statement in function returning non-void I usually do a distclean followed by make; but let me do this again. ~sanjeev Not sure which patch it is, though. Best regards Dirk Btw.: You can easily check this by doing a ./MAKEALL ARM_CORTEX_A8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot mtest hang on mx31
Hi Alessandro, Thanks! #define CONFIG_SYS_MEMTEST_START 0 /* memtest works on */ #define CONFIG_SYS_MEMTEST_END 0x1 So, is the config file wrong? So, most likely memtest without arguments has never been used on the board. Is it the cause for the hang, then? I thought it could be something wrong with the way i built my u-boot (linker script etc.) which was causing the crash/hang. Regards, Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, April 27, 2009 8:49 PM To: Dirk Behme Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates -Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Monday, April 27, 2009 8:47 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates Hi Premi, Sanjeev Premi wrote: This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision Applying all 3 patches I get sys_info.c: In function 'print_cpuinfo': sys_info.c:297: warning: no return statement in function returning non-void board.c: In function 'checkboard': board.c:349: warning: implicit declaration of function 'is_mem_sdr' board.c:357: warning: no return statement in function returning non-void I usually do a distclean followed by make; but let me do this again. Yeah. found it... a miss in interactive commit 3/3. Should I re-submit the whole series? OR Is it okay to re-send just the last one. ~sanjeev ~sanjeev Not sure which patch it is, though. Best regards Dirk Btw.: You can easily check this by doing a ./MAKEALL ARM_CORTEX_A8 ___ 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] include/ns16550.h: Unify structure declaration for registers
Hello Shinya,
Detlev Zundel wrote:
To be honest, I did not expect such problems, as I saw no hints from
comments on why this code was needed. Thinking afresh, it now makes at
least some sense why the code was. It nevertheless was inconsistent, as
the word access was only done in an asymmetric way regarding the
REG_SIZES parameter.
I used to define locally long + -16 variants.
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
Can you enlighten me, why exactly the 8-bit accesses do not work on your
hardware? Is this because of a too simplistic address decoding logic?
What endianness is your CPU using?
You see, I still do not understand the problem completely. There is a
board named ppmc7xx which uses REG_SIZE -8. The comment says 64-bit
accesses to 8-bit port and the definition is just like in the new
version with uchars and padding. Why did that work? Very likely the
comment is wrong, but still
How do I supposed to configure UART in my board config file?
I'm not sure at all. I believe you tested with 4 and -4 and it doesn't
work, right?
Right.
Now we have the problem that we have byte registers (after all, there
are only 8 bits significant even for your platform) which need to be
accessed as 32-bit entities (or 16 bit for other platforms maybe).
This is why Linux 8250 driver supports not only UPIO_MEM but also
UPIO_MEM32.
I see. Actually I was looking a lot at the Linux driver but was hoping
that we could away without introducing serial_{in,out}...
I don't see any way out here than to probably re-introduce different
data-types again - which I certainly do not like too much as the
registers stay 8 bit wide.
If there's no good alternatives, I think reverting is a good idea
because there must be other platforms affected by this change.
Reverting is not a long-term option if somebody wants to maintain the
source at all. Did you see all the different layout structures with
fields being defined only in one of the 5 alternatives (of the possible
8)? Bah...
Does anyone else have a good idea here?
Hm, how about introducing serial_{in,out} concepts from Linux?
Maybe, but maybe we can also do some more cheat^B^B^B^B^B creative
coding. I was think about something along those lines:
diff --git a/include/ns16550.h b/include/ns16550.h
index ce606b5..7924396 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -21,16 +21,20 @@
* will not allocate storage for arrays of size 0
*/
+#if !defined(CONFIG_SYS_NS16550_REG_TYPE)
+#define UART_REG_TYPE unsigned char
+#endif
+
#if !defined(CONFIG_SYS_NS16550_REG_SIZE) || (CONFIG_SYS_NS16550_REG_SIZE == 0)
#error Please define NS16550 registers size.
#elif (CONFIG_SYS_NS16550_REG_SIZE 0)
-#define UART_REG(x) \
- unsigned char prepad_##x[CONFIG_SYS_NS16550_REG_SIZE - 1]; \
- unsigned char x;
+#define UART_REG(x)\
+ UART_REG_TYPE prepad_##x[CONFIG_SYS_NS16550_REG_SIZE -
sizeof(UART_REG_TYPE)]; \
+ UART_REG_TYPE x;
#elif (CONFIG_SYS_NS16550_REG_SIZE 0)
#define UART_REG(x)\
- unsigned char x;\
- unsigned char postpad_##x[-CONFIG_SYS_NS16550_REG_SIZE - 1];
+ UART_REG_TYPE x;\
+ UART_REG_TYPE postpad_##x[-CONFIG_SYS_NS16550_REG_SIZE -
sizeof(UART_REG_TYPE)];
#endif
struct NS16550 {
Then you could do a
#define CONFIG_SYS_NS16550_REG_SIZE 4
#define CONFIG_SYS_NS16550_REG_TYPE unsigned long
This of course needs to be documented once it works ;)
What do you think?
Cheers
Detlev
--
config LGUEST
If unsure, say N. If curious, say M. If masochistic, say Y.
-- linux/drivers/lguest/Kconfig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, April 27, 2009 8:49 PM To: Dirk Behme Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates -Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Monday, April 27, 2009 8:47 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates Hi Premi, Sanjeev Premi wrote: This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision Applying all 3 patches I get sys_info.c: In function 'print_cpuinfo': sys_info.c:297: warning: no return statement in function returning non-void board.c: In function 'checkboard': board.c:349: warning: implicit declaration of function 'is_mem_sdr' board.c:357: warning: no return statement in function returning non-void I usually do a distclean followed by make; but let me do this again. Yeah. found it... a miss in interactive commit 3/3. Should I re-submit the whole series? OR Is it okay to re-send just the last one. I'm not a custodian, but last one marked with 'v4' should be sufficient from my point of view. Best regards Dirk ~sanjeev ~sanjeev Not sure which patch it is, though. Best regards Dirk Btw.: You can easily check this by doing a ./MAKEALL ARM_CORTEX_A8 ___ 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 3/3] ubifs: BUG: Blocks commpressed with zlib
On Monday 27 April 2009, Wolfgang Denk wrote: #include ubifs.h +#include u-boot/zlib.h #if !defined(CONFIG_SYS_64BIT_VSPRINTF) #warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output! @@ -33,15 +34,17 @@ DECLARE_GLOBAL_DATA_PTR; /* compress.c */ +int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp, +int stoponerr, int offset); The prototype declaration should be in the neader file. Please remove here. Ack. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv4 0/3] OMAP3: Board specific updates
This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information. This series fixes the compile warning pointed by Dirk Behme. These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision board/omap3/beagle/beagle.h|2 - board/omap3/evm/evm.h |2 - board/omap3/overo/overo.h |2 - board/omap3/pandora/pandora.h |2 - board/omap3/zoom1/zoom1.h |2 - cpu/arm_cortexa8/cpu.c |4 +- cpu/arm_cortexa8/omap3/board.c | 27 +- cpu/arm_cortexa8/omap3/clock.c |5 +- cpu/arm_cortexa8/omap3/sys_info.c | 147 +++- include/asm-arm/arch-omap3/omap3.h | 22 ++--- include/asm-arm/arch-omap3/sys_proto.h |4 - include/configs/omap3_beagle.h |6 ++ include/configs/omap3_evm.h|7 ++- include/configs/omap3_overo.h |6 ++ include/configs/omap3_pandora.h|6 ++ include/configs/omap3_zoom1.h |6 ++ 16 files changed, 136 insertions(+), 114 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCHv4 2/3] OMAP3: Remove unused board-types
The board-types defined in struct omap3_sysinfo seem to be
unused. The function display_board_info() is passed
board type as an argument; which is ignored.
This patch removes all uses of board-type, related definitions
and functions.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/omap3/beagle/beagle.h|2 --
board/omap3/evm/evm.h |2 --
board/omap3/overo/overo.h |2 --
board/omap3/pandora/pandora.h |2 --
board/omap3/zoom1/zoom1.h |2 --
cpu/arm_cortexa8/omap3/sys_info.c | 17 -
include/asm-arm/arch-omap3/omap3.h |8
include/asm-arm/arch-omap3/sys_proto.h |3 ---
8 files changed, 0 insertions(+), 38 deletions(-)
diff --git a/board/omap3/beagle/beagle.h b/board/omap3/beagle/beagle.h
index d66f159..5d45f01 100644
--- a/board/omap3/beagle/beagle.h
+++ b/board/omap3/beagle/beagle.h
@@ -24,8 +24,6 @@
#define _BEAGLE_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
OMAP3 Beagle board,
#if defined(CONFIG_ENV_IS_IN_ONENAND)
diff --git a/board/omap3/evm/evm.h b/board/omap3/evm/evm.h
index 199824f..4a82a7f 100644
--- a/board/omap3/evm/evm.h
+++ b/board/omap3/evm/evm.h
@@ -24,8 +24,6 @@
#define _EVM_H_
const omap3_sysinfo sysinfo = {
- OMAP3EVM_V1,
- OMAP3EVM_V2,
DDR_DISCRETE,
OMAP3 EVM board,
#if defined(CONFIG_ENV_IS_IN_ONENAND)
diff --git a/board/omap3/overo/overo.h b/board/omap3/overo/overo.h
index e8ccc1d..b595f6a 100644
--- a/board/omap3/overo/overo.h
+++ b/board/omap3/overo/overo.h
@@ -24,8 +24,6 @@
#define _OVERO_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
Gumstix Overo board,
#if defined(CONFIG_ENV_IS_IN_ONENAND)
diff --git a/board/omap3/pandora/pandora.h b/board/omap3/pandora/pandora.h
index dd09f12..8f0838c 100644
--- a/board/omap3/pandora/pandora.h
+++ b/board/omap3/pandora/pandora.h
@@ -24,8 +24,6 @@
#define _PANDORA_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
OMAP3 Pandora,
NAND,
diff --git a/board/omap3/zoom1/zoom1.h b/board/omap3/zoom1/zoom1.h
index bc8fba8..4f49a41 100644
--- a/board/omap3/zoom1/zoom1.h
+++ b/board/omap3/zoom1/zoom1.h
@@ -28,8 +28,6 @@
#define _BOARD_ZOOM1_H_
const omap3_sysinfo sysinfo = {
- SDP_3430_V1,
- SDP_3430_V2,
DDR_STACKED,
OMAP3 Zoom MDK Rev 1,
NAND,
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index d605d7c..fb240df 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -130,23 +130,6 @@ u32 get_sdr_cs_offset(u32 cs)
return offset;
}
-/***
- * get_board_type() - get board type based on current production stats.
- * - NOTE-1-: 2 I2C EEPROMs will someday be populated with proper info.
- *when they are available we can get info from there. This should
- *be correct of all known boards up until today.
- * - NOTE-2- EEPROMs are populated but they are updated very slowly. To
- *avoid waiting on them we will use ES version of the chip to get info.
- *A later version of the FPGA migth solve their speed issue.
- /
-u32 get_board_type(void)
-{
- if (get_cpu_rev() == CPU_3430_ES2)
- return sysinfo.board_type_v2;
- else
- return sysinfo.board_type_v1;
-}
-
/***
* get_gpmc0_base() - Return current address hardware will be
* fetching from. The below effectively gives what is correct, its a bit
diff --git a/include/asm-arm/arch-omap3/omap3.h
b/include/asm-arm/arch-omap3/omap3.h
index 8c9656f..d0d2737 100644
--- a/include/asm-arm/arch-omap3/omap3.h
+++ b/include/asm-arm/arch-omap3/omap3.h
@@ -177,14 +177,6 @@ typedef struct gpio {
#define WIDTH_8BIT 0x
#define WIDTH_16BIT0x1000 /* bit pos for 16 bit in gpmc */
-/* SDP definitions according to FPGA Rev. Is this OK?? */
-#define SDP_3430_V10x1
-#define SDP_3430_V20x2
-
-/* EVM definitions */
-#define OMAP3EVM_V10x1
-#define OMAP3EVM_V20x2
-
/* I2C power management companion definitions */
#define PWRMGT_ADDR_ID10x48
#define PWRMGT_ADDR_ID20x49
diff --git a/include/asm-arm/arch-omap3/sys_proto.h
b/include/asm-arm/arch-omap3/sys_proto.h
index 830447b..7361d08 100644
--- a/include/asm-arm/arch-omap3/sys_proto.h
+++ b/include/asm-arm/arch-omap3/sys_proto.h
@@ -22,8 +22,6 @@
#define _SYS_PROTO_H_
typedef struct {
- u32 board_type_v1;
- u32 board_type_v2;
u32 mtype;
char *board_string;
char *nand_string;
@@ -46,7 +44,6 @@ u32
Re: [U-Boot] [PATCH 3/3] ubifs: BUG: Blocks commpressed with zlib
On Monday 27 April 2009 08:36:55 Wolfgang Denk wrote:
In message Ricardo Ribalda Delgado wrote:
Blocks compressed with zlib dont have the full gzip header.
Without this patch, block compressed with zlib cannot be readed!
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
- * We need a wrapper for gunzip() because the parameters are
+ * We need a wrapper for zunzip() because the parameters are
* incompatible with the lzo decompressor.
*/
static int gzip_decompress(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
{
unsigned long len = in_len;
- return gunzip(out, *out_len, (unsigned char *)in, len);
+ return zunzip(out, *out_len, (unsigned char *)in, len, 0, 0);
}
If the only purpose of zunzip() is to be used here, then why do we not
make the parameters fit the intended purpose, thus avoiding an
additional wrapper?
not sure i follow ... what do you propose changing ?
easylogo can be changed to use this (a few Blackfin boards) because atm,
compression support with that is implemented by running `gzip`. this is
because i wasnt able to figure out how to get the decompression routines in u-
boot to play with a zlib compressed stream (i.e. no gzip header).
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND JFFS2 support in U-Boot 2009.03
On Monday 27 April 2009 08:59:11 cmfai...@rockwellcollins.com wrote: In previous versions of U-Boot, there were options for writing JFFS2 file systems to NAND (i.e., nand write.jffs2). the name was a misnomer. it didnt do anything jffs2 specific, it just handled bad block detection. Is this command no longer supported in the latest U-Boot release or is the command the same as the nand write command? reading 'nand help' indicates the latter This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended please fix your e-mail system so that this bogus crap is not included in your e-mails -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 0/3] OMAP3: Board specific updates
Sanjeev Premi wrote: This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information. This series fixes the compile warning pointed by Dirk Behme. These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision Signed-off-by: Dirk Behme dirk.be...@googlemail.com Tested-by: Dirk Behme dirk.be...@googlemail.com Tested on BeagleBoard. Thanks and best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ubifs: BUG: Blocks commpressed with zlib
Hello Wolfgang If the only purpose of zunzip() is to be used here, then why do we not make the parameters fit the intended purpose, thus avoiding an additional wrapper? The purpose of zunzip is to use it in more places. Like Mike Frysinger said: Mike this really should be a common function not specific to ubifs as there are many other opportunities for things to be compressed directly with zlib and not through gzip (splash/video images come to mind). /Mike Also, in order to be parameter compatible with lzo, we should keep this wrapper (am I right Stefan?) Best regards -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ubifs: BUG realpath string must be ended with NULL
If the memory used to copy the link_name is dirty the string wont
be ended with NULL, throwing out multiple memory bugs.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v3: link_make - link_name
fs/ubifs/ubifs.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 32f9ff8..427d84a 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -641,6 +641,7 @@ int ubifs_load(char *filename, u32 addr, u32 size)
ui = ubifs_inode(inode);
if (((inode-i_mode S_IFMT) == S_IFLNK) ui-data_len) {
memcpy(link_name, ui-data, ui-data_len);
+ link_name[ui-data_len] = '\0';
printf(%s is linked to %s!\n, filename, link_name);
ubifs_iput(inode);
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] lib_generic: gunzip: New function zunzip
Separate gunzip in
gunzip: Find the end of the header and call zunzip.
zunzip: Inflate gunzip block without header.
UBI fs blocks can be compresed in lzo, zlib or no-compression. The
current implementation of u-boot supported all the compressions but
there was a bug in the implementation of the zlib blocks.
UBIFS's Zlib blocks do not have header but they were compressed using
gunzip, a function used to decompress gunzip files/sectors with a
header.
This patch adds a new function zunzip that uncompress a zlib block with
no header.
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v2- rename to patch 2/3
lib_generic/gunzip.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/lib_generic/gunzip.c b/lib_generic/gunzip.c
index 01a4031..d59a448 100644
--- a/lib_generic/gunzip.c
+++ b/lib_generic/gunzip.c
@@ -39,6 +39,8 @@
int gunzip(void *, int, unsigned char *, unsigned long *);
void *zalloc(void *, unsigned, unsigned);
void zfree(void *, void *, unsigned);
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset);
void *zalloc(void *x, unsigned items, unsigned size)
{
@@ -59,8 +61,7 @@ void zfree(void *x, void *addr, unsigned nb)
int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp)
{
- z_stream s;
- int r, i, flags;
+ int i, flags;
/* skip header */
i = 10;
@@ -84,6 +85,18 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
return (-1);
}
+ return zunzip(dst, dstlen, src, lenp, 1, i);
+}
+
+/*
+ * Uncompress blocks compressed with zlib without headers
+ */
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset)
+{
+ z_stream s;
+ int r;
+
s.zalloc = zalloc;
s.zfree = zfree;
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
@@ -95,14 +108,14 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
r = inflateInit2(s, -MAX_WBITS);
if (r != Z_OK) {
printf (Error: inflateInit2() returned %d\n, r);
- return (-1);
+ return -1;
}
- s.next_in = src + i;
- s.avail_in = *lenp - i;
+ s.next_in = src + offset;
+ s.avail_in = *lenp - offset;
s.next_out = dst;
s.avail_out = dstlen;
r = inflate(s, Z_FINISH);
- if (r != Z_STREAM_END) {
+ if ((r != Z_STREAM_END) (stoponerr==1)) {
printf (Error: inflate() returned %d\n, r);
inflateEnd(s);
return (-1);
@@ -110,5 +123,5 @@ int gunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp)
*lenp = s.next_out - (unsigned char *) dst;
inflateEnd(s);
- return (0);
+ return 0;
}
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ubifs: BUG: Blocks commpressed with zlib
Blocks compressed with zlib dont have the full gzip header.
Without this patch, block compressed with zlib cannot be readed!
Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@uam.es
---
v3: Move the prototype to the header file
fs/ubifs/ubifs.c |5 +++--
fs/ubifs/ubifs.h |3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 427d84a..91fc574 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -24,6 +24,7 @@
*/
#include ubifs.h
+#include u-boot/zlib.h
#if !defined(CONFIG_SYS_64BIT_VSPRINTF)
#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
@@ -34,14 +35,14 @@ DECLARE_GLOBAL_DATA_PTR;
/* compress.c */
/*
- * We need a wrapper for gunzip() because the parameters are
+ * We need a wrapper for zunzip() because the parameters are
* incompatible with the lzo decompressor.
*/
static int gzip_decompress(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
{
unsigned long len = in_len;
- return gunzip(out, *out_len, (unsigned char *)in, len);
+ return zunzip(out, *out_len, (unsigned char *)in, len, 0, 0);
}
/* Fake description object for the none compressor */
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 91351de..43865aa 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -2172,6 +2172,7 @@ int ubifs_decompress(const void *buf, int len, void *out,
int *out_len,
/* todo: Move these to a common U-Boot header */
int lzo1x_decompress_safe(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len);
-int gunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp);
+int zunzip(void *dst, int dstlen, unsigned char *src, unsigned long *lenp,
+ int stoponerr, int offset);
#endif /* !__UBIFS_H__ */
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Net: Fec: Question about CONFIG_SYS_DISCOVER_PHY
Hello, My M5271EVB based board connects the SMI of the FEC PHY to an external entity and not to the SMI controller of the CPU. The MII bus is still connected between the CPU and the FEC PHY. The phy is then bootstrapped to be [100BaseT FullDuplex No AutoNeg]. I wanted to use something similar to CONFIG_FIXED_PHY as in the ppc driver, the one I found for ColdFire is CONFIG_SYS_DISCOVER_PHY However, when I tried to use it (by commenting out CONFIG_SYS_DISCOVER_PHY), I got this compile error: mcffec.c: In function 'mcffec_initialize': mcffec.c:615: error: 'mcffec_miiphy_read' undeclared (first use in this function) mcffec.c:615: error: (Each undeclared identifier is reported only once mcffec.c:615: error: for each function it appears in.) mcffec.c:615: error: 'mcffec_miiphy_write' undeclared (first use in this function) make[1]: *** [mcffec.o] Error 1 make: *** [drivers/net/libnet.a] Error 2 I manage to make it work using the diffs below and by #undef-ing CONFIG_MII, CONFIG_MII_INIT and CONFIG_CMD_MII, in by board header file. I am a bit ignorant as to how ugly my changes might be, if it has a hope of being mainlined, I can clean it up a bit. Also, I am kinda suprised that the network connection works anyway even when I still keep CONFIG_SYS_DISCOVER_PHY defined. I've been trying to find the 'magic' spot where even though the PHY is not being recognized, the system continue to work and assume/fallback to [100BaseT FullDuplex] Is this a known fallback method? where can I find the logic? my uClinux seems to work as well, so does Linux have the same fallback? Any feedback is appreciated. - Richard Retanubun. Start of patch diff --git a/drivers/net/mcffec.c b/drivers/net/mcffec.c index 64be5de..e3416b5 100644 --- a/drivers/net/mcffec.c +++ b/drivers/net/mcffec.c @@ -139,9 +139,11 @@ int fec_send(struct eth_device *dev, volatile void *packet, int length) struct fec_info_s *info = dev-priv; volatile fec_t *fecp = (fec_t *) (info-iobase); int j, rc; - u16 phyStatus; +#ifdef CONFIG_MII + u16 phyStatus; miiphy_read(dev-name, info-phy_addr, PHY_BMSR, phyStatus); +#endif /* CONFIG_MII */ /* section 16.9.23.3 * Wait for ready diff --git a/drivers/net/mcfmii.c b/drivers/net/mcfmii.c index 4f1c0a0..909e247 100644 --- a/drivers/net/mcfmii.c +++ b/drivers/net/mcfmii.c @@ -144,7 +144,6 @@ uint mii_send(uint mii_cmd) return (mii_reply 0x);/* data read from phy */ } -#endif /* CONFIG_SYS_DISCOVER_PHY || (CONFIG_MII) */ #if defined(CONFIG_SYS_DISCOVER_PHY) int mii_discover_phy(struct eth_device *dev) @@ -328,5 +327,5 @@ int mcffec_miiphy_write(char *devname, unsigned char addr, unsigned char reg, return 0; } - +#endif /* CONFIG_SYS_DISCOVER_PHY || (CONFIG_MII) */ #endif/* CONFIG_CMD_NET, FEC_ENET NET_MULTI */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fw_printenv - Bad CRC, using default environment
Hi All,
I have a u-boot version for Davinci 6446 and would like to access r/w the
u-boot environment from linux userpace.
I set the /etc/fw_env.config to /dev/mtd0 0
0x4000 0x200
When I execute fw_printenv, I got these error:
Warning: Bad CRC, using default environment
But, when I commented out the memcpy on the condition below, I could be able
to display my uboot environment.
Although, there were few enviroment variables where the values are corrupted
or missing few characters.
if (!crc1_ok) {
fprintf (stderr,
Warning: Bad CRC, using default environment\n);
/*memcpy(environment.data, default_environment, sizeof
default_environment);*/
}
Any one can give me a hints on how to fix it?
Thanks,
John
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
On Mon, Apr 27, 2009 at 12:51:29AM +0200, Wolfgang Denk wrote: Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090426224036.gl32...@game.jcrosoft.org you wrote: On 11:11 Sun 26 Apr , David Brownell wrote: I was looking at the DaVinci NAND support in current U-Boot code (i.e. 2009.03 plus patches merged since that release), and am puzzled by the above-named config option. Before I submit a patch to remove it from U-Boot GIT (nothing there enables it, and it will nastify 4-bit support), I thought I'd see if anyone knows exactly what software it was trying to emulate. Differences from the current NAND driver in GIT: It is for compatibility with a widely-deployed legacy ECC layout -- more details can be found in the list archives. Hm... I don't think this is needed. Since there are no users of this code in U-Boot, we can as well remove it without warning. You're assuming that it's not being used by users manually enabling it in their config.h. It should have been a CONFIG_ rather than CONFIG_SYS_. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Timer Qualification
On Thursday 23 April 2009 04:01:14 Ladislav Michl wrote: On Thu, Apr 23, 2009 at 12:18:00AM +0200, Wolfgang Denk wrote: In message Jean-Christophe PLAGNIOL-VILLARD wrote: Who needs this, and why and when, and why didn't we need it the past? a lot of actual timer are not correct and we have problem on network timeout as example. Hm... how muich of precision do we actuually need? Well, I already complained about all such a testing on the IRC yesterday, so I'm not going to repeat... if you want your points to have any meaning/usage, then they have to be on the mailing list. irc is useless for people trying to search for background information to a problem. as it stands, your e-mail simply reads as i agree with what Jean-Christophe said. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot -printk kernel crash dump using md on PDK
I think the first step would be to get MX31PDK into mainline U-boot. Are you willing to help on that? Of course, as long as i have it up and running and tested on my hardware. But in order to do that, i would need your help in answering my earlier question. Thanks for your help! -Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
Dear Dirk Behme, In message 49f5d1b5.8070...@googlemail.com you wrote: Should I re-submit the whole series? OR Is it okay to re-send just the last one. I'm not a custodian, but last one marked with 'v4' should be sufficient from my point of view. ACK, this is sufficient. Anything else would just be a waste of bandwidth and storage space. 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 think there's a world market for about five computers. -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Timer Qualification
On Wednesday 22 April 2009 16:49:36 Jean-Christophe PLAGNIOL-VILLARD wrote: For all Timer modification a minimun of qualification is mandatory as it will impact a lots of part of u-boot. So for this purpose I'll propose you to use one of this two approche to report the precition of your timer or update describing a method for testing on the list is destined to be ignored/rot. if there was a POST case people could enable and directions under doc/, that has a much higher likely hood of being used. a POST case that utilizes the RTC can be used to verify timer integrity to a pretty good degree. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot ARM merge strategy
Dear Detlev, In message m2hc0aqetd@ohwell.denx.de you wrote: And if we want to make it perfect, each -rc could get a similar announcement, too. Would ne not just add a lot of noise to the ML, without any real new information? If you want detailed information about each action, please feel free and register a RSS feed on the git repository. I think you mean the RSS feeds of the TWiki, right? No, I meant exactly what I wrote - the RSS feed on the git repo (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of the web page) so you get informed when new stuff gets in. 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 In any group of employed individuals the only naturally early riser is _always_ the office manager, who will _always_ leave reproachful little notes ... on the desks of their subordinates. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ubifs: BUG: Blocks commpressed with zlib
Dear Mike Frysinger,
In message 200904271200.39319.vap...@gentoo.org you wrote:
- * We need a wrapper for gunzip() because the parameters are
+ * We need a wrapper for zunzip() because the parameters are
* incompatible with the lzo decompressor.
*/
static int gzip_decompress(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
{
unsigned long len = in_len;
- return gunzip(out, *out_len, (unsigned char *)in, len);
+ return zunzip(out, *out_len, (unsigned char *)in, len, 0, 0);
}
If the only purpose of zunzip() is to be used here, then why do we not
make the parameters fit the intended purpose, thus avoiding an
additional wrapper?
not sure i follow ... what do you propose changing ?
The comment above seems to indicate that gzip_decompress() is only
(?) needed because the zunzip() parameters are incompatible with
those of the lzo decompressor.
So if we create zunzip() just for this purpose, then why not create
it in a way that the parameters are compatible with those of the lzo
decompressor, so we can omit this whole gzip_decompress() wrapper
function?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The philosophy exam was a piece of cake - which was a bit of a
surprise, actually, because I was expecting some questions on a sheet
of paper.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
On Monday 27 April 2009, Scott Wood wrote: It is for compatibility with a widely-deployed legacy ECC layout -- more details can be found in the list archives. See my original query, which IMO disproves that assertion. What this option enables differs in two ways from what the MontaVista code does. (Speaking here of the 1-bit HW ECC. The 4-bit support is another mess, which would be made far worse by needing to carry the BROKEN_ECC mode.) One could define a MONTAVISTA_COMPAT option, but it would not AFAICT be this BROKEN_ECC since it would only differ from the current Linux code in *one* of those three ways. (Which has in turn also been claimed to be broken, by mis-reporting some multi-bit errors as single-bit ones.) Which is why I'm wondering what that original U-Boot code for HW ECC was trying to be compatible with, since it clearly wasn't MontaVista Linux ... or even the U-Boot versions I've seen be distributed with it. - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot -printk kernel crash dump using md on PDK
Hi 2009/4/27 alfred steele alfred.jaq...@gmail.com: I think the first step would be to get MX31PDK into mainline U-boot. Are you willing to help on that? Of course, as long as i have it up and running and tested on my hardware. But in order to do that, i would need your help in answering my earlier question. And we need to know which U-boot patches you're using to boot the PDK board. In your original post you use the go command to boot the kernel, I use the bootm command. Using my latest set of patches (posted here a couple of weeks ago) I can boot Linux on the PDK using ethernet+tftp. The kernel (uImage) was compiled using Linux v2.6.24 + Freescale's patches from one of their BSPs (don't remember which actually, 1.3 or 1.4). /Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
David Brownell wrote: On Monday 27 April 2009, Scott Wood wrote: It is for compatibility with a widely-deployed legacy ECC layout -- more details can be found in the list archives. See my original query, which IMO disproves that assertion. The entire mess was presented as being for compatibility in these threads: http://lists.denx.de/pipermail/u-boot/2008-June/036055.html http://lists.denx.de/pipermail/u-boot/2008-August/039679.html If some portions of it aren't actually needed for compatibility, then we can remove them. Or we can remove the entire thing, if nobody cares anymore -- if anyone out there does care and is using this, please speak up now. What this option enables differs in two ways from what the MontaVista code does. (Speaking here of the 1-bit HW ECC. The 4-bit support is another mess, which would be made far worse by needing to carry the BROKEN_ECC mode.) I see no reason why new features would have to be supported on both sides of the ifdef. Which is why I'm wondering what that original U-Boot code for HW ECC was trying to be compatible with, since it clearly wasn't MontaVista Linux ... or even the U-Boot versions I've seen be distributed with it. MV 2.6.10 was the claim. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ubifs: BUG: Blocks commpressed with zlib
On Monday 27 April 2009 15:46:25 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
- * We need a wrapper for gunzip() because the parameters are
+ * We need a wrapper for zunzip() because the parameters are
* incompatible with the lzo decompressor.
*/
static int gzip_decompress(const unsigned char *in, size_t in_len,
unsigned char *out, size_t *out_len)
{
unsigned long len = in_len;
- return gunzip(out, *out_len, (unsigned char *)in, len);
+ return zunzip(out, *out_len, (unsigned char *)in, len, 0, 0);
}
If the only purpose of zunzip() is to be used here, then why do we not
make the parameters fit the intended purpose, thus avoiding an
additional wrapper?
not sure i follow ... what do you propose changing ?
The comment above seems to indicate that gzip_decompress() is only
(?) needed because the zunzip() parameters are incompatible with
those of the lzo decompressor.
So if we create zunzip() just for this purpose, then why not create
it in a way that the parameters are compatible with those of the lzo
decompressor, so we can omit this whole gzip_decompress() wrapper
function?
that should be a follow up change, but the wrapper already exists today
regardless of Ricardo's fixes. i dont think his changes should be held up to
address that.
that direction should probably cover:
- fix gunzip code to use size_t's instead of unsigned long
- re-order lzo arguments to match zlib rather than other way around since lzo
has very few consumers
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot -printk kernel crash dump using md on PDK
Dear Magnus,
Thanks for the reply!
And we need to know which U-boot patches you're using to boot the PDK
board.
I am using the internal git tree code supplied to me by freescale. The
tarball is called uboot-imx-imx_v2009.01.tar.gz. I can boot uboot
out of NAND successfully using that as the code base. I had started
using this even before Magnus had posted the patches and i had to
write a patch for the MMC/SD driver on top of that . To add to that ,
i tried downloading the mainline using GIT but it seems the corporate
firewall/proxy we have blocks it. Due to the shortage of time, i
continued to use the Freescale supplied code. It would be great if you
can supply me the code in a tarball(mainline git) with the patches you
posted if you want me to try it out.
In your original post you use the go command to boot the
kernel,
I use the bootm command now. My sole intention of using go was to
check whether or not zImage( instead of uImage) boots up as a generic
application. I tried verify the bootags in the U-boot environment. I
chacked on the machine id which gets registered with the kernel. They
all seemed to be the expected values.
Coming back to I am not sure about ,was when i tried dumping the
address(0x8100) which supposedly stores the bootargs, i get the
following :
= md 0x8100
8100: c100 c100 c108 c108
8110: c110 c110 c118 c118
8120: 92492492 24924924 0149 736e6f63.$I.$I.$I...cons
8130: 3d656c6f 6d797474 2c306378 32353131ole=ttymxc0,1152
8140: c140 c140 c148 c148@@...h...h...
It looks like the console is not set correctly to 115200, assuming its
in ASCII. Any clues as to what could be gone wrong?
Another quick question is do i have to supply the mem=XX argument
if my CONFIG_SETUP_MEMORY_TAGS is set in include/configs/mx31_pdk.h
BTW, following is an extract from the uboot linker script -u-boot.lds
which i had edited. Please let me know if you think something's wrong
with it.
OUTPUT_ARCH(arm)
ENTRY(reset)
SECTIONS
{
. = 0x;
. = ALIGN(4);
.text :
{
/* WARNING - the following is hand-optimized to fit within*/
/* the sector layout of our flash chips! XXX FIXME XXX */
* (.text.head)/* arm reset handler */
* (.text.init)/* lowlevel initial */
* (.text.load)/* nand copy and load */
* (.text.setup)
board/freescale/mx31_3stack/libmx31_3stack.a (.text)
lib_arm/libarm.a (.text)
net/libnet.a (.text)
drivers/mtd/libmtd.a (.text)
. = DEFINED(env_offset) ? env_offset : .;
common/env_embedded.o(.text)
*(.text)
}
. = ALIGN(4);
-Alfred.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Uboot bitmap utility
Wolfgang, Yes, I do see what U-boot is doing. I looked at bmp_logo.c and its output. It seems that the color palette entries are all 16 bits (unsigned short). For my application, I have 24 bit color, which expects each pixel to be 32 bits, of which only 24 bits are used. So the palette, I assume, should be unsigned longs for each color entry. Correct or am I missing something? Did I interpret the code correctly? Does it expect 16 bits per color? Thanks, Steve - wd wrote: Dear Steven Zedeck, In message 23217700.p...@talk.nabble.com you wrote: I'm referring to the palatte and bitmap structs. thanks again, Are you talking about the logo support? Noite that this is different from plain bitmap support. It seems that UBoot needs two data structures to display a bitmap in the framebuffer. Is there a utility that converts a Windows bitmap (BMP?) file and creates the 2 data structures that I can embedd in my code? Did you have a look at what U-Boot is doing? For example, how it uses the tools in the (he!) tools/ directory, for example tools/bmp_logo ? 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 HR Manager to job candidate I see you've had no computer training. Although that qualifies you for upper management, it means you're under-qualified for our entry level positions. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- View this message in context: http://www.nabble.com/Uboot-bitmap-utility-tp23217619p23265072.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot and CONFIG_SYS_DAVINCI_BROKEN_ECC
On Monday 27 April 2009, Scott Wood wrote: David Brownell wrote: On Monday 27 April 2009, Scott Wood wrote: It is for compatibility with a widely-deployed legacy ECC layout -- more details can be found in the list archives. See my original query, which IMO disproves that assertion. The entire mess was presented as being for compatibility in these threads: The *non*BROKEN stuff is certainly compatible with the NAND code in the DaVinci kernel GIT tree, which is now in mainline. The BROKEN stuff is somewhat compatible with the MV kernels, iff restricted to small-page support. But ... the U-Boot with which those kernels were shipped doesn't use 1-bit HW ECC, so that may not be much of a concern. (The original mainline u-boot large page support was very broken, and wasn't MV-compatible. So arguably there were two separate compatibility issues: MV, and large-page bugginess.) http://lists.denx.de/pipermail/u-boot/2008-June/036055.html http://lists.denx.de/pipermail/u-boot/2008-August/039679.html If some portions of it aren't actually needed for compatibility, then we can remove them. Or we can remove the entire thing, if nobody cares anymore -- if anyone out there does care and is using this, please speak up now. I'm hoping for the nobody cares any more option... Anyone who *does* can always use their current version of U-Boot ... or patch it back in. If there have been complaints due to lack of compatibility between current GIT kernels and the MV releases, I've not heard them. What this option enables differs in two ways from what the MontaVista code does. (Speaking here of the 1-bit HW ECC. The 4-bit support is another mess, which would be made far worse by needing to carry the BROKEN_ECC mode.) I see no reason why new features would have to be supported on both sides of the ifdef. I was referring to a textual mess. One clean way to add a broken ECC mode would be as a completely different set of functions, instead of a pile of #ifdefs. And 4-bit will be troublesome for other reasons. Which is why I'm wondering what that original U-Boot code for HW ECC was trying to be compatible with, since it clearly wasn't MontaVista Linux ... or even the U-Boot versions I've seen be distributed with it. MV 2.6.10 was the claim. Right. I looked at TI's 1.20 (MV 4.0/2.6.10) and 2.0 beta (MV 5.0/2.6.18) code, and their sibling U-Boot versions. If that compatibilty is actually needed, the simplest way to get it might be to define functions to mangle the the ECC words (standard ~PQRstu --- MV PsQRtu) and use the current *correction* code; the OOB bit pattern changes but not the algorithm. I think I'll add a comment about that. - Dave -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc83xx.git
Dear Kim Phillips, In message 20090424152306.aac80f94.kim.phill...@freescale.com you wrote: Wolfgang Denk, Please pull a couple of fixes for 83xx: The following changes since commit 7ee38c044ca5041d3378d6507580ea4ec344af96: David Brownell (1): fix DaVinci NS16550_REG_SIZE regression are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Anatolij Gustschin (1): mpc83xx: MPC8360ERDK: fix environment offset configuration bug Heiko Schocher (1): 83xx: searching muram-data by compatible property cpu/mpc83xx/fdt.c |4 ++-- include/configs/MPC8360ERDK.h |4 ++-- 2 files changed, 4 insertions(+), 4 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 Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, The Omega Glory, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: rename timer init callback timer_init
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 1240047101-6787-1-git-send-email-plagn...@jcrosoft.com you wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
The Subject: indicates a mere formal change (a rename of a function
name), but the patch actually does other things as well:
...
diff --git a/cpu/ixp/interrupts.c b/cpu/ixp/interrupts.c
index ee0129e..a05e439 100644
--- a/cpu/ixp/interrupts.c
+++ b/cpu/ixp/interrupts.c
@@ -33,14 +33,6 @@
#include asm/arch/ixp425.h
#include asm/proc-armv/ptrace.h
-/*
- * When interrupts are enabled, use timer 2 for time/delay generation...
- */
-
-#define FREQ
-#define CLOCK_TICK_RATE (((FREQ / CONFIG_SYS_HZ
~IXP425_OST_RELOAD_MASK) + 1) * CONFIG_SYS_HZ)
-#define LATCH((CLOCK_TICK_RATE + CONFIG_SYS_HZ/2) /
CONFIG_SYS_HZ) /* For divider */
-
struct _irq_handler {
void*m_data;
void (*m_func)( void *data);
@@ -48,8 +40,6 @@ struct _irq_handler {
static struct _irq_handler IRQ_HANDLER[N_IRQS];
-static volatile ulong timestamp;
-
static void default_isr(void *data)
{
printf(default_isr(): called for IRQ %d, Interrupt Status=%x PR=%x\n,
@@ -61,33 +51,20 @@ static int next_irq(void)
return (((*IXP425_ICIH 0x00fc) 2) - 1);
}
-static void timer_isr(void *data)
-{
- unsigned int *pTime = (unsigned int *)data;
-
- (*pTime)++;
-
- /*
- * Reset IRQ source
- */
- *IXP425_OSST = IXP425_OSST_TIMER_2_PEND;
-}
-
-ulong get_timer (ulong base)
+void do_irq (struct pt_regs *pt_regs)
{
- return timestamp - base;
-}
+ int irq = next_irq();
-void reset_timer (void)
-{
- timestamp = 0;
+ IRQ_HANDLER[irq].m_func(IRQ_HANDLER[irq].m_data);
}
-void do_irq (struct pt_regs *pt_regs)
+void irq_install_handler (int irq, interrupt_handler_t handle_irq, void
*data)
{
- int irq = next_irq();
+ if (irq = N_IRQS || !handle_irq)
+ return;
- IRQ_HANDLER[irq].m_func(IRQ_HANDLER[irq].m_data);
+ IRQ_HANDLER[irq].m_data = data;
+ IRQ_HANDLER[irq].m_func = handle_irq;
}
int interrupt_init (void)
@@ -95,23 +72,11 @@ int interrupt_init (void)
int i;
/* install default interrupt handlers */
- for (i = 0; i N_IRQS; i++) {
- IRQ_HANDLER[i].m_data = (void *)i;
- IRQ_HANDLER[i].m_func = default_isr;
- }
-
- /* install interrupt handler for timer */
- IRQ_HANDLER[IXP425_TIMER_2_IRQ].m_data = (void *)timestamp;
- IRQ_HANDLER[IXP425_TIMER_2_IRQ].m_func = timer_isr;
-
- /* setup the Timer counter value */
- *IXP425_OSRT2 = (LATCH ~IXP425_OST_RELOAD_MASK) | IXP425_OST_ENABLE;
+ for (i = 0; i N_IRQS; i++)
+ irq_install_handler(i, default_isr, (void *)i);
/* configure interrupts for IRQ mode */
*IXP425_ICLR = 0x;
- /* enable timer irq */
- *IXP425_ICMR = (1 IXP425_TIMER_2_IRQ);
-
return (0);
}
This is far beyond a mere rename. from the patch it is not even easy
to judge if the resulting code is equivalent or not.
I think the commit message should explain in more detail what exactly
is being changed here, and why.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The one who says it cannot be done should never interrupt the one who
is doing it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: Pending patches
Dear Dirk, In message 49f5c746.6040...@googlemail.com you wrote: Short status update after recent merges and patch updates. As usual, please correct if anything is wrong or missing. Thanks for the summary. Dirk Behme wrote: To avoid loosing the overview, here my list of pending OMAP3 patches ready to be applied. From my point of view there are no open comments on these which will prevent to apply them. But please correct if I overlooked anything or add what (patches? comments?) I missed. 1. OMAP3: Beagle: Set pinmux conditionally for Rev C boards http://lists.denx.de/pipermail/u-boot/2009-April/051013.html Mail http://lists.denx.de/pipermail/u-boot/2009-April/051459.html tells us that this should be applied to u-boot-arm next. But I can't find it in gitweb http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next Did I miss something? I cannot find it either. Btw.: As initial patch and first update was sent ~1 day after merge window close (Apr 4?) I hoped to have a chance to still get it into master ;( We don't have to bend much to consider this even a bug fix (it fixes a specific board configuration, doesn't it?). 2. OMAP3: Remove legacy NAND defines http://lists.denx.de/pipermail/u-boot/2009-April/050882.html Applied to u-boot-arm next. Request to move to master by Wolfgang. 3. OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000 http://lists.denx.de/pipermail/u-boot/2009-April/051178.html 4. OMAP3: Fix changed mmc init command http://lists.denx.de/pipermail/u-boot/2009-April/051179.html Applied to u-boot-arm master. 5. OMAP3: Remove unused board-types http://lists.denx.de/pipermail/u-boot/2009-April/051338.html 6. OMAP3: Print correct silicon revision http://lists.denx.de/pipermail/u-boot/2009-April/051339.html Patches 5 6 replaced by update which includes switch to checkboard and print_cpuinfo: OMAP3: Board specific updates (3 patches) http://lists.denx.de/pipermail/u-boot/2009-April/051505.html http://lists.denx.de/pipermail/u-boot/2009-April/051506.html http://lists.denx.de/pipermail/u-boot/2009-April/051507.html 7. Zoom2 respin II (10 patches) Note: Initial patch series for this was sent 'Wed Apr 1 18:08:38 CEST 2009' http://lists.denx.de/pipermail/u-boot/2009-April/050094.html IMHO this was while open merge window. http://lists.denx.de/pipermail/u-boot/2009-April/050863.html http://lists.denx.de/pipermail/u-boot/2009-April/050864.html http://lists.denx.de/pipermail/u-boot/2009-April/050865.html http://lists.denx.de/pipermail/u-boot/2009-April/050866.html http://lists.denx.de/pipermail/u-boot/2009-April/050868.html http://lists.denx.de/pipermail/u-boot/2009-April/050867.html Applied to u-boot-arm next (see comment about merge window above). http://lists.denx.de/pipermail/u-boot/2009-April/050869.html Applied to u-boot-arm next (see comment about merge window above). http://lists.denx.de/pipermail/u-boot/2009-April/050870.html http://lists.denx.de/pipermail/u-boot/2009-April/050871.html Applied to u-boot-arm next. Request to move to master by Wolfgang. I think all the patches listed above could and should go into master now. Jean-Cristophe, what do you think? Do you have any specific reasons for not pulling these into master now? http://lists.denx.de/pipermail/u-boot/2009-April/050872.html For the rest of the Zoom2 patches (#1, #2, #3, #4, #5, #8 #10) http://lists.denx.de/pipermail/u-boot/2009-April/051383.html http://lists.denx.de/pipermail/u-boot/2009-April/051384.html http://lists.denx.de/pipermail/u-boot/2009-April/051385.html http://lists.denx.de/pipermail/u-boot/2009-April/051386.html http://lists.denx.de/pipermail/u-boot/2009-April/051455.html seem to apply. I'm not sure what you mean here, Dirk. I understand that Jean-Cristophe requested changes, and we're waiting for a resubmit, right? Jean-Cristophe, I really would like to see some progress in this area, so I'd appreciate if you could apply the patches listed above to master and send me a pull request. 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 Brain off-line, please wait. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Bug] IXP425 and e1000 network driver
Dear Ben,
In message 49d68311.4090...@gmail.com you wrote:
Wolfgang Denk wrote:
Dear Ben,
In message gijdmd$vh...@ger.gmane.org Stefan Althoefer wrote:
Hi,
I found that IXP425 (big endian ARM) did not work with e1000 network
driver. The reason is broken access to controller registers.
I get it working with this patch:
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -105,12 +105,15 @@ static void e1000_phy_hw_reset(struct e1000_hw *hw);
static int e1000_phy_reset(struct e1000_hw *hw);
static int e1000_detect_gig_phy(struct e1000_hw *hw);
-#define E1000_WRITE_REG(a, reg, value) (writel((value), ((a)-hw_addr +
E1000_##reg)))
-#define E1000_READ_REG(a, reg) (readl((a)-hw_addr + E1000_##reg))
-#define E1000_WRITE_REG_ARRAY(a, reg, offset, value) (\
- writel((value), ((a)-hw_addr + E1000_##reg + ((offset)
2
-#define E1000_READ_REG_ARRAY(a, reg, offset) ( \
- readl((a)-hw_addr + E1000_##reg + ((offset) 2)))
+#define E1000_WRITE_REG(a, reg, value) \
+ (writel(cpu_to_le32(value), ((a)-hw_addr + E1000_##reg)))
+#define E1000_READ_REG(a, reg) \
+ (le32_to_cpu(readl((a)-hw_addr + E1000_##reg)))
+#define E1000_WRITE_REG_ARRAY(a, reg, offset, value) \
+ (writel(cpu_to_le32(value),\
+ ((a)-hw_addr + E1000_##reg + ((offset) 2
+#define E1000_READ_REG_ARRAY(a, reg, offset) \
+ (le32_to_cpu(readl((a)-hw_addr + E1000_##reg + ((offset) 2
#define E1000_WRITE_FLUSH(a) {uint32_t x; x = E1000_READ_REG(a, STATUS);}
#ifndef CONFIG_AP1000 /* remove for warnings */
-
However, I'm not sure it this is the correct fix.
Is readl supposed to read raw data?
Is le32_to_cpu/cpu_to_le32 a function or a macro? In the later case the
code is not save or slow due to multiple argument expansion.
-- Stefan
I have never seen any comments on this. Could you please have a look
at it?
Best regards,
Wolfgang Denk
Sure thing.
And what was the result of you having a look at thispatch?
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
In the beginning there was nothing.
And the Lord said Let There Be Light!
And still there was nothing, but at least now you could see it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] netloop: updates for NetLoop
Dear Heiko Schocher, In message 49a641e4.8000...@denx.de you wrote: [PATCH v2] netloop: updates for NetLoop Fix some issues introduced from commit: 2f70c49e5b9813635ad73666aa30f304c7fdeda9 suggested by Mike Frysinger. - added some comment for the env_id variable in common_cmd_nvedit.c - moved some variables in fn scope instead of file scope - NetInitLoop now static void Signed-off-by: Heiko Schocher h...@denx.de --- changes since v1: - added comments from Mike Frysinger I'm sorry, but this does not apply any more. Can you please rebase it? Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I must follow the people. Am I not their leader? - Benjamin Disraeli ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/envcrc: add --binary option to export embedded env
Dear Mike Frysinger,
In message 1239015670-28314-1-git-send-email-vap...@gentoo.org you wrote:
The --binary option to envcrc can be used to export the embedded env as a
binary blob so that it can be manipulated/examined/whatever externally.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
tools/envcrc.c | 45 +
1 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/tools/envcrc.c b/tools/envcrc.c
index 4334cdf..ac24967 100644
--- a/tools/envcrc.c
+++ b/tools/envcrc.c
@@ -24,6 +24,7 @@
#include stdio.h
#include stdint.h
#include stdlib.h
+#include string.h
#include unistd.h
#ifndef __ASSEMBLY__
@@ -77,19 +78,55 @@ extern unsigned char environment;
int main (int argc, char **argv)
{
#ifdef ENV_IS_EMBEDDED
+ unsigned char pad = 0x00;
Should we not rather use 0xFF for padding - given that the envrionment
is frequently stored in NOR flash?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Of all possible committee reactions to any given agenda item, the
reaction that will occur is the one which will liberate the greatest
amount of hot air.-- Thomas L. Martin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] rtl8169: fix cache coherency problem
Dear Yoshihiro Shimoda, In message 49a4d6bc.3010...@renesas.com you wrote: Fix the problem that cannot access actual data when CPU data cache enabled. Signed-off-by: Yoshihiro Shimoda shimoda.yoshih...@renesas.com --- drivers/net/rtl8169.c | 11 ++- 1 files changed, 10 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 I express preference for a chronological sequence of events which precludes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] SMC911x driver fixed for NFS boot
Dear Ben, In message 1239162275-13087-1-git-send-email-mani.pil...@ti.com Manikandan Pillai wrote: eth_halt() function in the smc911x drivers used to call the smc911x_reset() function. eth_halt() used to be called after tftp transfers. This used to put the ethernet chip in reset while the linux boots up resulting in the ethernet driver not coming up. NFS boot used to fail as a result. This patch calls smc911x_shutdown() instead of smc911x_reset(). Some comments received has also been fixed. Signed-off-by: Manikandan Pillai mani.pil...@ti.com --- drivers/net/smc911x.c | 23 ++- 1 files changed, 22 insertions(+), 1 deletions(-) Any comments on this patch? 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 haven't lost my mind - it's backed up on tape somewhere. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] [RESEND] Add imls utility command
Dear Marco, In message 49e2236f.1050...@gmail.com you wrote: Signed-off-by: Marco Stornelli marco.storne...@gmail.com Sorry, your patch is corrupt because your mailer wrapped long lines: ... +all: $(BINS) + +$(obj)imls: $(obj)imls.o $(obj)crc32.o $(obj)image.o $(obj)md5.o \ + $(obj)sha1.o $(LIBFDT_OBJS) + $(CC) $(CFLAGS) -o $@ $^ + $(STRIP) $@ + +# Some files complain if compiled with -pedantic, use FIT_CFLAGS +$(obj)image.o: $(SRCTREE)/common/image.c + $(CC) -g $(FIT_CFLAGS) -c -o $@ $ + +$(obj)imls.o: imls.c + $(CC) -g $(FIT_CFLAGS) -c -o $@ $ + +# Some of the tool objects need to be accessed from outside the tools directory ^^ Like here and elsewhere. Please fix your mailer setup and resubmit. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To take a significant step forward, you must make a series of finite improvements. - Donald J. Atwood, General Motors ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] dm9000 EEPROM reading bugfix
Dear David Brownell, In message 200904162315.15209.davi...@pacbell.net you wrote: From: David Brownell dbrown...@users.sourceforge.net Make the U-Boot dm9000 driver read addresses from EEPROM just like Linux does ... read six bytes, instead of reading twelve bytes and then discarding every other one. Using the right Ethernet address is a big win. Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- drivers/net/dm9000x.c | 12 ++-- 1 file changed, 6 insertions(+), 6 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 I have a very small mind and must live with it.-- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] minor DaVinci clock cleanup
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090417053719.gi31...@game.jcrosoft.org you wrote: On 15:40 Sun 12 Apr , David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Minor cleanup to clock-related defines for DaVinci DM6446 boards: - CONFIG_SYS_CLK_FREQ is unused; remove it. - CONFIG_SYS_NS16550_CLK must be the same as CONFIG_SYS_HZ_CLOCK On DM6446 both of those peripheral clocks actually come from the same source, the primary oscillator. Having them use the same symbol avoids bugs in the clone'n'modify development cycle. applied May I please have a pull request for this any time soon? 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 On my planet, to rest is to rest -- to cease using energy. To me, it is quite illogical to run up and down on green grass, using energy, instead of saving it. -- Spock, Shore Leave, stardate 3025.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] DaVinci Ethernet cleanup
Dear Jean-Christophe, In message 49ebf50a.6070...@gmail.com Ben Warren wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:49 Sun 12 Apr , David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Chips without the EMAC controller won't need the utilities it uses to read an Ethernet address from EEPROM; so don't include them needlessly. Use is_valid_ether() to validate the address from EEPROM. All-zero addresses aren't the only invalid addresses. A fully erased EEPROM returns all-ones, also invalid... Switch those Ethernet utilities to use %pM for printing MAC addresses; and not say ROM when they mean EEPROM. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Acked-by: Ben Warren biggerbadder...@gmail.com Looks fine Ben any comments? Best Regards, J. Please pull this in with the other changes. Is this in your queue? I would like to pull this soon, please. 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 There's another way to survive. Mutual trust -- and help. -- Kirk, Day of the Dove, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fs: Fix the wrong type of var
Dear Dave Liu, In message 1239691055-8360-1-git-send-email-dave...@freescale.com you wrote: From: Gao Guanhua b22...@freescale.com The filelen should be signed type, not unsigned type. otherwise, The condition as below never take. if (filelen 0) Signed-off-by: Gao Guanhua b22...@freescale.com Signed-off-by: Dave Liu dave...@freescale.com --- common/cmd_ext2.c |3 ++- 1 files changed, 2 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 Good morning. This is the telephone company. Due to repairs, we're giving you advance notice that your service will be cut off indefi- nitely at ten o'clock. That's two minutes from now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] UBIFS: Remove tnc_commit.c which is not used in the read-only version
Dear Stefan Roese, In message 1239724281-18241-1-git-send-email...@denx.de you wrote: --===0864082046== I missed removing this file while implementing the UBIFS support. It's not referenced at all, so let's remove it. Thanks to Artem Bityutskiy for spotting. Signed-off-by: Stefan Roese s...@denx.de --- fs/ubifs/tnc_commit.c | 1102 - 1 files changed, 0 insertions(+), 1102 deletions(-) delete mode 100644 fs/ubifs/tnc_commit.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 Time is fluid ... like a river with currents, eddies, backwash. -- Spock, The City on the Edge of Forever, stardate 3134.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools
Dear Peter Tyser, In message 1239749550.24099.147.ca...@localhost.localdomain you wrote: ... #1 is ugly in that 99.99% of the time an empty os_support.c file is processed. #2 is ugly in that the Makefile method to determine a target OS is somewhat hokey and will only get hokier if/when additional OS targets are supported. I'd vote for #1 as I think the wasted time of processing os_support.c is a drop in the bucket and it seems a bit cleaner than hacking up the Makefile. If others have any clever ideas let me know. It seems there were no really clever ideas, or did I miss them? Hm.. actually I lost track of which patch is missing. Could you please send me a pointer to the latest and greatest version? Sorry 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 Men don't talk peace unless they're ready to back it up with war. -- Col. Green, The Savage Curtain, stardate 5906.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Remove sa1100.h
Dear Shinya Kuribayashi, In message 49e68f07.5050...@necel.com you wrote: sa1100.h is not used anywhere, then remove it. $ find . -name '*.h' -empty -print ./include/sa1100.h $ git grep 'sa1100.h' . $ Signed-off-by: Shinya Kuribayashi shinya.kuribaya...@necel.com --- include/sa1100.h |0 1 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 include/sa1100.h 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 If all you have is a hammer, everything looks like a nail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/next v3 27/28] Add support for building native win32 tools
Hi Wolfgang, #1 is ugly in that 99.99% of the time an empty os_support.c file is processed. #2 is ugly in that the Makefile method to determine a target OS is somewhat hokey and will only get hokier if/when additional OS targets are supported. I'd vote for #1 as I think the wasted time of processing os_support.c is a drop in the bucket and it seems a bit cleaner than hacking up the Makefile. If others have any clever ideas let me know. It seems there were no really clever ideas, or did I miss them? Hm.. actually I lost track of which patch is missing. Could you please send me a pointer to the latest and greatest version? Sorry thanks. The original v3 of Add support for building native win32 tools has actually been merged already. After merging the patch, you had requested a cleanup patch to which I responded with the patch's rationale as well as a possible (in my opinion) dirtier cleanup. No one else suggested a cleaner way to implement the change, so what is currently committed should be correct. I'm still open to clever ideas if anyone has one though:) Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 V5] bdinfo: coding style cleanup
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 1238927618-15438-2-git-send-email-plagn...@jcrosoft.com you wrote:
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
...
#if defined(CONFIG_CMD_NET)
print_eth(0);
- printf (ip_addr = %pI4\n, bd-bi_ip_addr);
+ printf (ip_addr = %pI4\n, bd-bi_ip_addr);
Please do not insert TABs like here (,TAB).
printf (baudrate= %d bps\n, bd-bi_baudrate);
}
diff --git a/lib_avr32/bdinfo.c b/lib_avr32/bdinfo.c
index fac5b33..eae4b20 100644
--- a/lib_avr32/bdinfo.c
+++ b/lib_avr32/bdinfo.c
@@ -31,14 +31,14 @@ void arch_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
{
bd_t *bd = gd-bd;
- print_num (boot_params, (ulong)bd-bi_boot_params);
- print_num (memstart, (ulong)bd-bi_memstart);
- print_lnum (memsize, (u64)bd-bi_memsize);
- print_num (flashstart,(ulong)bd-bi_flashstart);
- print_num (flashsize, (ulong)bd-bi_flashsize);
- print_num (flashoffset, (ulong)bd-bi_flashoffset);
+ print_num(boot_params,(ulong)bd-bi_boot_params);
+ print_num(memstart, (ulong)bd-bi_memstart);
+ print_lnum(memsize, (u64)bd-bi_memsize);
+ print_num(flashstart, (ulong)bd-bi_flashstart);
+ print_num(flashsize, (ulong)bd-bi_flashsize);
+ print_num(flashoffset,(ulong)bd-bi_flashoffset);
If your intention was to make the code more readable, you might even
consider vertial alignment, for example like this:
+ print_num (boot_params, (ulong)bd-bi_boot_params);
+ print_num (memstart, (ulong)bd-bi_memstart);
+ print_lnum(memsize, (u64)bd-bi_memsize);
+ print_num (flashstart,(ulong)bd-bi_flashstart);
+ print_num (flashsize, (ulong)bd-bi_flashsize);
+ print_num (flashoffset, (ulong)bd-bi_flashoffset);
Looks *much* niver IMO. Ditto elsewhere.
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
Children are natural mimics who act like their parents despite every
effort to teach them good manners.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch u-boot git] mtdpart command: align output columns
Dear David Brownell, In message 200904161955.48211.davi...@pacbell.net you wrote: From: David Brownell dbrown...@users.sourceforge.net Make the headers in the mtdparts command output line up with their columns ... strike the extra TAB character. Signed-off-by: David Brownell dbrown...@users.sourceforge.net 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 God made the integers; all else is the work of Man. - Kronecker ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] s3c64xx: remove unnecessary definition
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090417060137.go31...@game.jcrosoft.org you wrote: On 19:59 Mon 06 Apr , Minkyu Kang wrote: CONFIG_S3C6400 is must defined at config header file That definition is unnecessary at this file Signed-off-by: Minkyu Kang mk7.k...@samsung.com --- include/s3c6400.h |4 1 files changed, 0 insertions(+), 4 deletions(-) applied May I see a pull request for this, please? 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 Do not follow where the path may leadgo instead where there is no path and leave a trail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Replace __attribute references with __attribute__
Dear Peter Tyser, In message 1240243726-17065-1-git-send-email-pty...@xes-inc.com you wrote: __attribute__ follows gcc's documented syntax and is generally more common than __attribute. This change is only asthetic and should not affect functionality. Signed-off-by: Peter Tyser pty...@xes-inc.com --- cpu/arm920t/at91rm9200/ether.c |5 +++-- cpu/arm920t/s3c24x0/usb_ohci.h |8 cpu/mips/au1x00_usb_ohci.h |8 cpu/mpc5xxx/usb_ohci.h |8 cpu/mpc86xx/cpu.c |2 +- cpu/ppc4xx/usb_ohci.h |8 drivers/mmc/mmc.c |4 ++-- drivers/usb/host/ohci.h|8 drivers/usb/musb/musb_core.h |2 +- include/asm-m68k/types.h |2 +- include/asm-ppc/types.h|2 +- include/asm-sparc/types.h |2 +- net/eth.c |4 ++-- 13 files changed, 32 insertions(+), 31 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 Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
