Re: [U-Boot] [PATCH V3] AT91 Fix: return value of get_tbclk
Hello Eric, On Wednesday 18 August 2010, 09:17:26 you wrote: Hello, Am Samstag, 7. August 2010, 19:49:42 schrieb Jens Scharsig: * Fix: return value of get_tbclk * this fixes issue with prematurely restart/retry, if BOOT_RETRY_TIMEOUT is used This issue also arises, if you use CONFIG_AUTOBOOT_KEYED friends I tried both BOOT_RETRY_TIMEOUT and CONFIG_AUTOBOOT_KEYED CONFIG_AUTOBOOT_STOP_STR, Both work well on AT91SAM9260EK Which board did you tried? That's some time ago and I don't remember which u-boot version that was. I think i came across that problem on the AT91SAM9G20EK and our own SAM9G20 board. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TFTP load for file over 50MB fails
Dear Marek, The thread ([U-Boot] TFTP timeout issue while downloading the linux kernel in openpxa vpac270 u-boot source code) is restarted to avoid the mess with new subject TFTP load for file over 50MB fails. Previous issue summary Test observations: Microcontroller used in the board- PXA270 Ethernet Controller- SMCS LAN91C111Ii-NU Microcontroller Ethernet interface - Static memory chip select 4 Speed - System Clock: 208MHz Memory Clock: 208MHz U-boot location in SDRAM - 0xa7F0 Issue: 1. When the board is connected to network, through tftp the u-boot is downloading only 9 MB size file. When tried to download 10 MB size file, the u-boot is displaying Retry count exceeded; starting again message and the file download is not getting completed. 2. When the board is connected to Linux machine directly using cross cable, through tftp the u-boot is downloading 47 MB size file without any retry, but when tried to download 53 MB size file, the u-boot is displaying Retry count exceeded; starting again message and download is not getting completed. Tests Performed: Memory test is performed to verify whether the memory was misconfigured, but the memory test executed from the start address 0xA000 to end address 0xA700 was successful without any error. Test concludes that the problem in downloading 50MB file is not because of memory error. Thanks and Regards Stephen Paulraj C DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-sh4
Dear Hello Wolfgang, The following changes since commit bd2313078114c4b44c4a5ce149af43bcb7fc8854: Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2010-08-18 21:16:35 +0200) are available in the git repository at: git://git.denx.de/u-boot-sh.git master Nobuhiro Iwamatsu (11): sh: Update lowlevel_init.S of rsk7203 sh: Update lowlevel_init.S of sh7785lcr sh: Update lowlevel_init.S of MigoR sh: Update lowlevel_init.S of sh7763rdp sh: Update lowlevel_init.S of espt-giga sh: Update lowlevel_init.S of r2dplus sh: Update lowlevel_init.S of ap325rxa sh: Add support do_bdinfo function sh: Update lowlevel_init.S of ms7720se sh: Update lowlevel_init.S of ms7750se sh: Update lowlevel_init.S of mpr2 board/espt/lowlevel_init.S | 46 +--- board/mpr2/lowlevel_init.S |8 ++-- board/ms7720se/lowlevel_init.S | 30 ++- board/ms7750se/lowlevel_init.S | 19 --- board/renesas/ap325rxa/lowlevel_init.S | 11 ++-- board/renesas/r2dplus/lowlevel_init.S |9 ++- board/renesas/rsk7203/lowlevel_init.S | 85 +- board/renesas/sh7763rdp/lowlevel_init.S |4 +- board/renesas/sh7785lcr/lowlevel_init.S | 54 --- common/cmd_bdinfo.c | 19 +++ 10 files changed, 162 insertions(+), 123 deletions(-) Best regards, Nobuhiro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELDK] Not able to Uncompress Multi Image
Hi, Thanks for your reply. yes same u-boot versions are used on the board. We have built 2 multi images and trying to boot on both boards. Image 1 boots on both boards fine and no problem. Image 2 boots on one board and stops uncompressing multi-image on 2nd board. Both Image1 and Image 2 are built out of same code base. So we do not undertstand what would be the difference as the 2nd board boots image 1 successfully. I also tried to verify the CRC and it is all fine On 2nd board it stops throwing out Uncompressing Multi-File Image ... Do let us know if there are any other methods !! ( We have 256 MB Ram and i am using 0x400 for download). Best Regards zoolu On Fri, Aug 27, 2010 at 1:53 PM, Detlev Zundel d...@denx.de wrote: Hi Zoolu, I am trying to boot my mutli image ( Kernel + Ramdisk) on my target and i am not able to boot beyond below given log. I can not see (Uncompressing Multi-File Image ... OK) .. OK does not come up. I guess the image is hung while uncompressing the image ??? But to my surprise the same image boots on a different board with all same hardware. So the problem is only with this board i guess any pointer on this would be of great help. Do you use the same U-Boot versions on both the good and the bad board? It's because in the last time we reworked the boot process thoroughly and the multi-image file is deprecated in favour of the FIT images (cf. doc/uImage.FIT). So maybe the non-working board has a U-Boot with a problem in the multi-image file handling... --- Load address: 0x400 Loading: # # # # # # # ## done Bytes transferred = 2583735 (276cb7 hex) ## Booting image at 0400 ... Image Name: Boot Image Image Type: PowerPC Linux Multi-File Image (gzip compressed) Data Size:2583671 Bytes = 2.5 MB Load Address: Entry Point: Contents: Image 0: 1268075 Bytes = 1.2 MB Image 1: 1315583 Bytes = 1.3 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... Thanks Regards, Zoolu Apart from that, you should use the U-Boot mailing list more appropriate for such topics (I added a CC and set f'up). Thanks Detlev -- A GNU manual should give a good introduction to a beginner reading through from the start, and should also provide all the details that hackers want. --- GNU Coding Standards -- 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] [PATCH] video: cfb_console: fix definition and usage of CURSOR_xxx macros
Hi Timur, The CURSOR_ON, CURSOR_OFF, and CURSOR_SET macros are defined incorrectly. If cursor support is disabled, then these macros are defined to nothing, but then they are used like this: if (console_col CONSOLE_COLS) CURSOR_OFF console_row++; which was compiled like this: if (console_col CONSOLE_COLS) console_row++; This is obviously not what was intended. Signed-off-by: Timur Tabi ti...@freescale.com Patch looks good, thanks! Acked-by: Detlev Zundel d...@denx.de --- This patch depends on video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB drivers/video/cfb_console.c | 24 ++-- 1 files changed, 14 insertions(+), 10 deletions(-) -- Man against god... God against Man... Man against nature... Nature against man... God against nature... Nature against god... a very, very funny religion. -- Zen Master D.T. Suzuki commenting on Christianity -- 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] [PATCH] display_buffer: fix misaligned buffer
Hi Reinhard,
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
lib/display_options.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..9048a8a 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
Sorry to jump in here late, but I do not like this change. How can a
reader of the code who has not followed the discussion here infer that
the datatype is there to ensure alignment?
I am willing to bet at least a few beers that it will not take long
until someone posts a patch changing the datatype back, because
c-strings are bytes.
I would much rather see an alignment attribute, which will _document_
the problem _and_ fix it, instead of only fixing it.
Cheers
Detlev
--
The GNU GPL makes sense in terms of its purpose: freedom and social
solidarity. Trying to understand it in terms of the goals and values of
open source is like trying understand a CD drive's retractable drawer as
a cupholder. You can use it for that, but that is not what it was
designed for. -- Richard Stallman
--
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] Debugging, Why USB is not stable
Hi Gérald, I have some few problems with usb start / reset commands on last uboot. USB hard drive are not always detected. Is there something I missed ? Only the fact that USB is a nightmare to work with. No, honestly, we have a continuous stream of USB related problems with the current USB code. As I understand it this results from the ever more diverging USB implementation in U-Boot and e.g. in the Linux kernel. The latter has received a lot of work which is simply not possible by reading datasheets and writing software according to those. This involves a lot of testing on literally thousands of different HW incarnations and on working around the discovered idosyncracies of the parts. Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat. For the problem at hand, you may try to test variations on your setup, e.g. by introducing different hubs in different combinations. I'm pretty sure that this will change the situation - sadly may be not for the better. Cheers Detlev -- Among the -) the .-) is king -- 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
Hi, hi, i would like to subscribe the news about u-boot ,thank you. Use the web-interface referenced in all mails: ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Cheers Detlev -- He thinks he's really smooth, but he's only C^1. -- 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] [PATCH] display_buffer: fix misaligned buffer
Hi Detlev,
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..9048a8a 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen)
{
-uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
Sorry to jump in here late, but I do not like this change. How can a
reader of the code who has not followed the discussion here infer that
the datatype is there to ensure alignment?
I am willing to bet at least a few beers that it will not take long
until someone posts a patch changing the datatype back, because
c-strings are bytes.
I would much rather see an alignment attribute, which will _document_
the problem _and_ fix it, instead of only fixing it.
One could add a comment above like:
/*
* it is mandatory that linebuf stays uint32_t aligned
* since we are going to slide along it with a uint32_t
* pointer
*/
uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
I personally prefer this above an attribute. Its disputeable but I prefer
to do things with normal C constructs where possible. You can already
see from the discussion that __aligned as a toolchain-abstracted
variant (defined in a toolchain header file) or attribute((__aligned__))
as a very toolchain dependant variant shall be used ;)
Anyway, both patches have been offered, any will work for me as long as
I can see ASCII properly on ARM machines...
without patch:
2200: 41424344 41424344 41424344 41424344ADCBADCBADCBAV4.
with patch:
2200: 41424344 41424344 41424344 41424344DCBADCBADCBADCBA
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] mkimage: Add compatibility option for legacy Multi-File images
Hi Thibaut,
generally I'm not a fan to include workarounds for bugs which we do not
have anymore in mainline U-Boot. Isn't there any other alternative for
this? What do other people think?
If nobody objects to the genereal principle, then I have some requests
below.
During a few months, offsets of files in multi-file images were miscalculated,
this has been fixed by 02b9b22446e3d7ad6a6382be17a1ce79a7de589b,
but unfortunatly, some devices (I'm thinking of the Neo FreeRunner) are using
a broken version of U-Boot.
This problem can easily be worked around at image creation time by adding one
byte of junk at the end of the first (and optionnally second) file, if its
size is a multiple of 4.
Hm, as I read it, you add 4 bytes (not one) in case the image is already
padded correctly to 32-bit, correct? If so, then please correct the
comment.
It's not really clean, but it shouldn't cause any problem. At least, I haven't
encountered any using this patch.
Signed-off-by: Thibaut Girka t...@sitedethib.com
---
tools/mkimage.c |9 -
tools/mkimage.h |1 +
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index f5859d7..239c1f0 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -243,6 +243,9 @@ main (int argc, char **argv)
usage ();
params.imagename = *++argv;
goto NXTARG;
+ case 'p':
+ params.pflag++;
+ break;
case 'v':
params.vflag++;
break;
@@ -383,6 +386,8 @@ NXTARG: ;
params.cmdname, file,
strerror(errno));
exit (EXIT_FAILURE);
}
+ if (params.pflag sep (sbuf.st_size % 4 ==
0))
+ sbuf.st_size += 1;
size = cpu_to_uimage (sbuf.st_size);
} else {
size = 0;
@@ -556,7 +561,8 @@ copy_file (int ifd, const char *datafile, int pad)
exit (EXIT_FAILURE);
}
- if (pad ((tail = size % 4) != 0)) {
+ tail = size % 4;
+ if (pad (params.pflag || tail != 0)) {
if (write(ifd, (char *)zero, 4-tail) != 4-tail) {
fprintf (stderr, %s: Write error on %s: %s\n,
@@ -586,6 +592,7 @@ usage ()
-e == set entry point to 'ep' (hex)\n
-n == set image name to 'name'\n
-d == use image data from 'datafile'\n
+-p == force padding in multi-file images\n
This is no real padding, so please don't make it look like it is. Maybe
use q(uirk) as an option character and change the description to
indicate that this is not a forced padding but a incorrect additional
32-bit padding to work around an old bug (see man-page). A fix to
doc/mkimage.1 which now exists is also mandatory.
-x == set XIP (execute in place)\n,
params.cmdname);
fprintf (stderr,%s [-D dtc_options] -f fit-image.its
fit-image\n,
diff --git a/tools/mkimage.h b/tools/mkimage.h
index 9033a7d..6e18750 100644
--- a/tools/mkimage.h
+++ b/tools/mkimage.h
@@ -58,6 +58,7 @@ struct mkimage_params {
int eflag;
int fflag;
int lflag;
+ int pflag;
int vflag;
int xflag;
int os;
Cheers
Detlev
--
Helena ist verhältnismäßig leicht zu besetzen. Eine Frau, zarteste Jugend
mit sinnlicher Reife verbindend; äußerst intelligent, indes von durchaus
weiblicher Denkart; phlegmatisch, aber sensibel; unübertrefflich schön und
dabei von sehr persönlichem Charme - mehr wird da nicht verlangt.
-- Peter Hacks
--
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] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 9:56 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines These are not used on this board, which uses soft I2C instead. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/km_arm.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/configs/km_arm.h b/include/configs/km_arm.h index 6519c90..1617e69 100644 --- a/include/configs/km_arm.h +++ b/include/configs/km_arm.h @@ -142,16 +142,8 @@ /* * I2C related stuff */ -#undef CONFIG_HARD_I2C /* I2C with hardware support */ #define CONFIG_SOFT_I2C /* I2C bit-banged */ -#if defined(CONFIG_HARD_I2C) -#define CONFIG_I2C_KIRKWOOD -#define CONFIG_I2C_KW_REG_BASE KW_TWSI_BASE -#define CONFIG_SYS_I2C_SLAVE0x0 -#define CONFIG_SYS_I2C_SPEED10 -#endif - #define CONFIG_KIRKWOOD_GPIO/* Enable GPIO Support */ #if defined(CONFIG_SOFT_I2C) #ifndef __ASSEMBLY__ Hi Heiko There are no issues to apply this patch. I hope this is okay with you? Pls ack. Regards.. Prafulla . . -- 1.7.1 ___ 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] android fastboot support on U-boot
Hi shulin, Now I working on porting android fastboot protocol to U-boot,does somebody add fastboot protocol patches to U-boot? Can yopu please tell me what the the android fastboot protocol is? Cheers Detlev -- Modern technique has made it possible for leisure, within limits, to be not the prerogative of small privileged classes, but a right evenly distributed throughout the community. The morality of work is the morality of slaves, and the modern world has no need of slavery.-- Bertrand Russell -- 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] Debugging, Why USB is not stable
On Mon, 30 Aug 2010 11:12:25 +0200, Detlev Zundel d...@denx.de wrote: Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat. If somebody starts over, it would be wise to find a way to use the Linux code unmodified or only automatically converted in U-Boot. Otherwise, every resync is painful again and again. With the use of wrapper functions, a few sed/awk/whatever scripts and all kinds of macro trickery, it is should be possible to use the Linux code without manually changing it for U-boot. -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines
Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 9:56 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines These are not used on this board, which uses soft I2C instead. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/km_arm.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/configs/km_arm.h b/include/configs/km_arm.h index 6519c90..1617e69 100644 --- a/include/configs/km_arm.h +++ b/include/configs/km_arm.h @@ -142,16 +142,8 @@ /* * I2C related stuff */ -#undef CONFIG_HARD_I2C /* I2C with hardware support */ #define CONFIG_SOFT_I2C /* I2C bit-banged */ -#if defined(CONFIG_HARD_I2C) -#define CONFIG_I2C_KIRKWOOD -#define CONFIG_I2C_KW_REG_BASE KW_TWSI_BASE -#define CONFIG_SYS_I2C_SLAVE0x0 -#define CONFIG_SYS_I2C_SPEED10 -#endif - #define CONFIG_KIRKWOOD_GPIO/* Enable GPIO Support */ #if defined(CONFIG_SOFT_I2C) #ifndef __ASSEMBLY__ Hi Heiko There are no issues to apply this patch. I hope this is okay with you? Pls ack. Acked-by: Heiko Schocherh...@denx.de If you ack the patchset, I can add it to u-boot-i2c.git 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
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Reinhard Meyer schrieb:
+uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
I personally prefer this above an attribute. Its disputeable but I prefer
to do things with normal C constructs where possible.
Reading this, after it had been sent, a perfect patch
should make the buffer an union:
union {
uint32_t ui[MAX.../4+1];
uint16_t us[MAX.../2+1];
uint8_t uc[MAX...+1];
} linebuf;
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines
-Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Monday, August 30, 2010 3:08 PM To: Prafulla Wadaskar Cc: Albert Aribaud; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 9:56 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines These are not used on this board, which uses soft I2C instead. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/km_arm.h |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/include/configs/km_arm.h b/include/configs/km_arm.h index 6519c90..1617e69 100644 --- a/include/configs/km_arm.h +++ b/include/configs/km_arm.h @@ -142,16 +142,8 @@ /* * I2C related stuff */ -#undefCONFIG_HARD_I2C /* I2C with hardware support */ #define CONFIG_SOFT_I2C /* I2C bit-banged */ -#if defined(CONFIG_HARD_I2C) -#define CONFIG_I2C_KIRKWOOD -#define CONFIG_I2C_KW_REG_BASE KW_TWSI_BASE -#define CONFIG_SYS_I2C_SLAVE0x0 -#define CONFIG_SYS_I2C_SPEED10 -#endif - #define CONFIG_KIRKWOOD_GPIO/* Enable GPIO Support */ #if defined(CONFIG_SOFT_I2C) #ifndef __ASSEMBLY__ Hi Heiko There are no issues to apply this patch. I hope this is okay with you? Pls ack. Acked-by: Heiko Schocherh...@denx.de If you ack the patchset, I can add it to u-boot-i2c.git Acked-by: Prafulla Wadaskar prafu...@marvell.com Regards.. Prafulla . . 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
Re: [U-Boot] [PATCH V4 2/4] i2c: rename kirkwood_i2c to mvtwsi
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
Sent: Friday, August 27, 2010 9:56 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V4 2/4] i2c: rename kirkwood_i2c to mvtwsi
This driver is not kirkwood-specific and can also be used
e.g. by orion5x. Rename to a SoC-neutral name.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
drivers/i2c/Makefile |2 +-
drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename drivers/i2c/{kirkwood_i2c.c = mvtwsi.c} (100%)
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index d2c2515..8921ff9 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -28,7 +28,7 @@ LIB := $(obj)libi2c.a
COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
-COBJS-$(CONFIG_I2C_KIRKWOOD) += kirkwood_i2c.o
+COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
diff --git a/drivers/i2c/kirkwood_i2c.c b/drivers/i2c/mvtwsi.c
similarity index 100%
rename from drivers/i2c/kirkwood_i2c.c
rename to drivers/i2c/mvtwsi.c
Acked-by: Prafulla Wadaskar prafu...@marvell.com
Regards..
Prafulla . .
--
1.7.1
___
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 V4 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 9:56 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V4 3/4] i2c: rewrite mvtwsi, support orion5x and kirkwood This rewrite of the mvtwsi driver is 25% smaller and much faster and simpler than the previous code. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- drivers/i2c/mvtwsi.c | 750 +++--- 1 files changed, 341 insertions(+), 409 deletions(-) Acked-by: Prafulla Wadaskar prafu...@marvell.com Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 4/4] edminiv2: add I2C support using mvtwsi driver
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, August 27, 2010 9:56 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH V4 4/4] edminiv2: add I2C support using mvtwsi driver Signed-off-by: Albert Aribaud albert.arib...@free.fr --- include/configs/edminiv2.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index 57dd165..ccfc660 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -132,6 +132,7 @@ */ #include config_cmd_default.h #define CONFIG_CMD_IDE +#define CONFIG_CMD_I2C /* * Network @@ -182,6 +183,16 @@ #endif /* CMD_IDE */ /* + * I2C related stuff + */ +#ifdef CONFIG_CMD_I2C +#define CONFIG_I2C_MVTWSI +#define CONFIG_I2C_MVTWSI_BASE ORION5X_TWSI_BASE +#define CONFIG_SYS_I2C_SLAVE 0x0 +#define CONFIG_SYS_I2C_SPEED 10 +#endif Acked-by: Prafulla Wadaskar prafu...@marvell.com Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Hi Reinhard,
Hi Detlev,
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..9048a8a 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,7 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+ uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
Sorry to jump in here late, but I do not like this change. How can a
reader of the code who has not followed the discussion here infer that
the datatype is there to ensure alignment?
I am willing to bet at least a few beers that it will not take long
until someone posts a patch changing the datatype back, because
c-strings are bytes.
I would much rather see an alignment attribute, which will _document_
the problem _and_ fix it, instead of only fixing it.
One could add a comment above like:
/*
* it is mandatory that linebuf stays uint32_t aligned
* since we are going to slide along it with a uint32_t
* pointer
*/
uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
I personally prefer this above an attribute. Its disputeable but I prefer
to do things with normal C constructs where possible. You can already
see from the discussion that __aligned as a toolchain-abstracted
variant (defined in a toolchain header file) or attribute((__aligned__))
as a very toolchain dependant variant shall be used ;)
Well of course, but we have need for such pragmas anyway:
[...@pollux u-boot-testing (master)]$ grep -re '__attribute__[ \t]*((packed' .
| wc -l
257
I agree that if we can fix something with standards, we should do it.
But if the standards do not provide a clean way for something, but
instead requires the misuse of the side-effect of a different thing,
then I much rather use the a non-standard construct _intended_ for the
problem.
No comment is neccessary when we use the attribute - this alone is a
positive aspect for me - code should always document itself. Whenever I
need a comment to describe the intention of a c statement, I rethink
what I try to do.
Anyway, both patches have been offered, any will work for me as long as
I can see ASCII properly on ARM machines...
without patch:
2200: 41424344 41424344 41424344 41424344ADCBADCBADCBAV4.
with patch:
2200: 41424344 41424344 41424344 41424344DCBADCBADCBADCBA
Sorry for being so late, but I really prefer the attribute variant.
Cheers
Detlev
--
Those who deny freedom to others deserve it not for themselves.
-- Abraham Lincoln
--
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] Debugging, Why USB is not stable
Hi Bas, On Mon, 30 Aug 2010 11:12:25 +0200, Detlev Zundel d...@denx.de wrote: Sometimes I get the impression that we would save a lot of headache by starting afresh and porting the current Linux code into U-Boot thus leverage all this, but nobody yet dared to start such a feat. If somebody starts over, it would be wise to find a way to use the Linux code unmodified or only automatically converted in U-Boot. Otherwise, every resync is painful again and again. Absolutely. With the use of wrapper functions, a few sed/awk/whatever scripts and all kinds of macro trickery, it is should be possible to use the Linux code without manually changing it for U-boot. In the past this turned out not to be as easy as it sounds. The devil lurks in the details which become apparant only when starting on the job. But of course if somebody accomplishes this, I cannot imagine anyone from stopping him :) Cheers Detlev -- The Speedo3 is very similar to other Intel network chips, that is to say apparently designed on a different planet. -- drivers/net/eepro100.c in Linux source -- 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] [PATCH 0/2] fix little endian build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Skuribay, Woflgang can we apply those patch to MIPS-branch first?? On 08/09/2010 11:13 PM, xian...@openmobilefree.net wrote: From: Xiangfu Liu xian...@openmobilefree.net those two patches fix the little endian build. done by Shinya Kuribayashi. Makefile |1 + arch/mips/config.mk | 27 +-- arch/mips/cpu/config.mk |8 board/dbau1x00/u-boot.lds|2 +- board/gth2/u-boot.lds|2 +- board/incaip/u-boot.lds |2 +- board/pb1x00/u-boot.lds |2 +- board/purple/u-boot.lds |2 +- board/qemu-mips/u-boot.lds |2 +- examples/standalone/mips.lds |2 +- include/configs/pb1x00.h |2 ++ 11 files changed, 35 insertions(+), 17 deletions(-) - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx7f34ACgkQRRAEFRxkgLTkIQCePWThBoVT5a5tt9vf81i4NRth pecAoIYPsUqBP7ZWiJo85vPkMsmnyUAd =Np7C -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] android fastboot support on U-boot
Resend, forgot to copy the list. On Mon, 30 Aug 2010 11:31:06 +0200, Detlev Zundel d...@denx.de wrote: Hi shulin, Now I working on porting android fastboot protocol to U-boot,does somebody add fastboot protocol patches to U-boot? Can yopu please tell me what the the android fastboot protocol is? http://android-dls.com/wiki/index.php?title=Fastboot Fastboot is protocol used to update the flash filesystem in Android devices from a host over USB. It allows flashing of unsigned partition images. I was already wondering how feasible it would be to have a board with USB slave behave like an USB memory stick to flash the firmware by simply copying a file from the host to it. -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fix the c_size, in CSD Version 2.0, it's 22 bits
Signed-off-by: Xiangfu Liu xian...@openmobilefree.net --- include/mmc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/mmc.h b/include/mmc.h index fcb237e..b913a60 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -189,12 +189,12 @@ struct mmc_csd u8 tran_speed; u16 ccc:12, read_bl_len:4; + u32 c_size:22; u64 read_bl_partial:1, write_blk_misalign:1, read_blk_misalign:1, dsr_imp:1, rsvd2:2, - c_size:12, vdd_r_curr_min:3, vdd_r_curr_max:3, vdd_w_curr_min:3, -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Hi Reinhard,
Reinhard Meyer schrieb:
+ uint32_t linebuf[MAX_LINE_LENGTH_BYTES/4 + 1];
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
I personally prefer this above an attribute. Its disputeable but I prefer
to do things with normal C constructs where possible.
Reading this, after it had been sent, a perfect patch
The quest for the perfect patch, now that's the spirit ;)
completely off-topic
Very likely it will be easier than the perfect pac-man game[1] and I
hope we don't have such a split screen waiting *lol*
/cot
should make the buffer an union:
union {
uint32_t ui[MAX.../4+1];
uint16_t us[MAX.../2+1];
uint8_t uc[MAX...+1];
} linebuf;
That also sounds good indeed - it even better documents the intention of
the code so by my own arguments I'd vote for it. I presume you will
follow up with such a patch once you tested it?
Thanks!
Detlev
[1] http://en.wikipedia.org/wiki/Pac-Man
--
``The number of UNIX installations has grown to 10,
with more expected.'' Unix Programmers Manual -- 1972
The number of UNIX variants has grown to dozens,
with more expected. -- 2001
--
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] android fastboot support on U-boot
Hi Bas, On Mon, 30 Aug 2010 11:31:06 +0200, Detlev Zundel d...@denx.de wrote: Hi shulin, Now I working on porting android fastboot protocol to U-boot,does somebody add fastboot protocol patches to U-boot? Can yopu please tell me what the the android fastboot protocol is? http://android-dls.com/wiki/index.php?title=Fastboot Fastboot is protocol used to update the flash filesystem in Android devices from a host over USB. It allows flashing of unsigned partition images. I was already wondering how feasible it would be to have a board with USB slave behave like an USB memory stick to flash the firmware by simply copying a file from the host to it. Yet another alternative for the problem already solved by DFU[1]? Damn, after some recent activity in this area again I was starting to raise my hopes that more people realize such a thing exists already :( Thanks Detlev [1] http://wiki.openmoko.org/wiki/USB_DFU -- You see, the best way to solve a problem is to rigorously define it in terms of other people's problems, and then run away quickly. -- Roland McGrath -- 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] Debugging, Why USB is not stable
On Mon, 30 Aug 2010 11:52:30 +0200, Detlev Zundel d...@denx.de wrote: In the past this turned out not to be as easy as it sounds. The devil lurks in the details which become apparent only when starting on the job. But of course if somebody accomplishes this, I cannot imagine anyone from stopping him :) Well, I vaguely recall a recent discussion here where a lot of changes to imported code were requested just to fulfil the U-boot code guidelines. That will not help particularly when the code needs to be synced again with the origin. And yes, nobody said it was easy :-) -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging, Why USB is not stable
Hi Bas, On Mon, 30 Aug 2010 11:52:30 +0200, Detlev Zundel d...@denx.de wrote: In the past this turned out not to be as easy as it sounds. The devil lurks in the details which become apparent only when starting on the job. But of course if somebody accomplishes this, I cannot imagine anyone from stopping him :) Well, I vaguely recall a recent discussion here where a lot of changes to imported code were requested just to fulfil the U-boot code guidelines. That will not help particularly when the code needs to be synced again with the origin. For code that we import en-bloc, we explicitely make expections to U-Boot rules[1]: Source files originating from different projects (for example the MTD subsystem or the hush shell code from the BusyBox project) may, after careful consideration, be exempted from these rules. For such files, the original coding style may be kept to ease subsequent migration to newer versions of those sources. And yes, nobody said it was easy :-) Well, at least I thought it at one moment in the past :) Cheers Detlev [1] http://www.denx.de/wiki/U-Boot/CodingStyle -- Paul Simon sang Fifty Ways to Lose Your Lover, because quite frankly, A Million Ways to Tell a Developer He Is a D*ckhead doesn't scan nearly as well. But I'm sure he thought about it. -- linux/Documentation/ManagementStyle -- 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] android fastboot support on U-boot
On Mon, 30 Aug 2010 12:09:48 +0200, Detlev Zundel d...@denx.de wrote: Yet another alternative for the problem already solved by DFU[1]? Damn, after some recent activity in this area again I was starting to raise my hopes that more people realize such a thing exists already :( OK, there appears to be U-boot support as well. It needs a util on the host, but for development purposes that would be fine. A usb-storage like solution would be more flexible. It could have the option to poke around in a jffs2 image while still in u-boot. Very nice when the firmware doesn't boot or let you log in due to a small mistake in the image. But I guess that jffs2 R/W support in U-Boot is a bridge or two to far :-)) -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Detlev Zundel wrote:
Hi Reinhard,
Hi Reinhard, hi Detlev,
should make the buffer an union:
union {
uint32_t ui[MAX.../4+1];
uint16_t us[MAX.../2+1];
uint8_t uc[MAX...+1];
} linebuf;
That also sounds good indeed - it even better documents the intention of
the code so by my own arguments I'd vote for it. I presume you will
follow up with such a patch once you tested it?
I agree this is a better solution as adding a simple comment. Some time
a comment is valid only at the time of the writing, and further patches
could drop its meaning if the comment is not updated, too.
Detlev, regarding the discussion I would only point out that we have to
be sure that such kind of patch will be merged in the current release.
It would be a real pity if a new official realease is published and then
even a simple md command does not work on ARM.
Stefano
--
=
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] display_buffer: fix misaligned buffer
Le 30/08/2010 12:31, Stefano Babic a écrit :
Detlev Zundel wrote:
Hi Reinhard,
Hi Reinhard, hi Detlev,
should make the buffer an union:
union {
uint32_t ui[MAX.../4+1];
uint16_t us[MAX.../2+1];
uint8_t uc[MAX...+1];
} linebuf;
That also sounds good indeed - it even better documents the intention of
the code so by my own arguments I'd vote for it. I presume you will
follow up with such a patch once you tested it?
I agree this is a better solution as adding a simple comment. Some time
a comment is valid only at the time of the writing, and further patches
could drop its meaning if the comment is not updated, too.
Do we have to pick one? I say the code should use union *and* a one-line
comment should mention how the union enforces the alignment requirement.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/4] suen3: remove CONFIG_HARD_I2C and related defines
Le 30/08/2010 11:44, Prafulla Wadaskar a écrit : Acked-by: Heiko Schocherh...@denx.de Acked-by: Prafulla Wadaskarprafu...@marvell.com Thanks to both of you. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TQM834x CFI flash question: Support for 1 or 2 flash banks?
Hi Marian, I'm in the process of cleaning up some of the CFI driver defines/implementation hacks, such as CONFIG_SYS_MAX_FLASH_BANKS_DETECT. While doing this I noticed that the TQM834x port uses this define and sets it to 2 (via the tqm834x_num_flash_banks variable) if a 2nd chip is detected. But I fail to see how this could really work, since the board port doesn't provide a 2nd base address via the an entry in the CONFIG_SYS_FLASH_BANKS_LIST define, where the probing of the 2nd bank should be done in the common CFI driver. I know that the board port was done quite some time ago, but perhaps you do remember some details. Has this ever been tested with 2 banks on this board? If yes, how? Could be that I'm missing something. Please enlighten me. :) Thanks. Cheers, 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] display_buffer: fix misaligned buffer
Albert ARIBAUD schrieb:
Le 30/08/2010 12:31, Stefano Babic a écrit :
Detlev Zundel wrote:
Hi Reinhard,
Hi Reinhard, hi Detlev,
should make the buffer an union:
union {
uint32_t ui[MAX.../4+1];
uint16_t us[MAX.../2+1];
uint8_t uc[MAX...+1];
} linebuf;
That also sounds good indeed - it even better documents the intention of
the code so by my own arguments I'd vote for it. I presume you will
follow up with such a patch once you tested it?
I agree this is a better solution as adding a simple comment. Some time
a comment is valid only at the time of the writing, and further patches
could drop its meaning if the comment is not updated, too.
Do we have to pick one? I say the code should use union *and* a one-line
comment should mention how the union enforces the alignment requirement.
I will do that. Test only on ARM9. Others must try to compile and see no
other arch gives warnings.
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix the c_size, in CSD Version 2.0, it's 22 bits
Xiangfu Liu schrieb: Signed-off-by: Xiangfu Liu xian...@openmobilefree.net --- include/mmc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/mmc.h b/include/mmc.h index fcb237e..b913a60 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -189,12 +189,12 @@ struct mmc_csd u8 tran_speed; u16 ccc:12, read_bl_len:4; + u32 c_size:22; u64 read_bl_partial:1, write_blk_misalign:1, read_blk_misalign:1, dsr_imp:1, rsvd2:2, - c_size:12, vdd_r_curr_min:3, vdd_r_curr_max:3, vdd_w_curr_min:3, NAK This structure approach is awfully broken. LE/BE issues, c_size spans over a 32 bit boundary! The generic MMC works fine with no such structure. I already proposed in earlier patches to finally remove that structure. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] android fastboot support on U-boot
Hi Bas, On Mon, 30 Aug 2010 12:09:48 +0200, Detlev Zundel d...@denx.de wrote: Yet another alternative for the problem already solved by DFU[1]? Damn, after some recent activity in this area again I was starting to raise my hopes that more people realize such a thing exists already :( OK, there appears to be U-boot support as well. It needs a util on the host, but for development purposes that would be fine. A usb-storage like solution would be more flexible. It could have the option to poke around in a jffs2 image while still in u-boot. Very nice when the firmware doesn't boot or let you log in due to a small mistake in the image. Is that fastboot usb-storage based? From the wiki-page that you referenced I only see that you also need a separate host tool to use it. So that's not much of a difference, is it? But I guess that jffs2 R/W support in U-Boot is a bridge or two to far :-)) And maybe a bridge I would not invest time anymore as UBI+UBIFS seems to be the weapon of choice against the fallability of NAND devices. Cheers Detlev -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. -- 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] android fastboot support on U-boot
On Mon, 30 Aug 2010 13:11:38 +0200, Detlev Zundel d...@denx.de wrote: Is that fastboot usb-storage based? From the wiki-page that you referenced I only see that you also need a separate host tool to use it. So that's not much of a difference, is it? No, the usb-storage based thing was something I had in mind as a solution for easy firmware update and manipulation. -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix the c_size, in CSD Version 2.0, it's 22 bits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Reinhard thanks for reply. On 08/30/2010 07:08 PM, Reinhard Meyer wrote: Xiangfu Liu schrieb: Signed-off-by: Xiangfu Liu xian...@openmobilefree.net --- include/mmc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/mmc.h b/include/mmc.h index fcb237e..b913a60 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -189,12 +189,12 @@ struct mmc_csd u8 tran_speed; u16 ccc:12, read_bl_len:4; +u32 c_size:22; u64 read_bl_partial:1, write_blk_misalign:1, read_blk_misalign:1, dsr_imp:1, rsvd2:2, -c_size:12, vdd_r_curr_min:3, vdd_r_curr_max:3, vdd_w_curr_min:3, NAK This structure approach is awfully broken. LE/BE issues, c_size spans over a 32 bit boundary! The generic MMC works fine with no such structure. I already proposed in earlier patches to finally remove that structure. Reinhard - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx7pNoACgkQRRAEFRxkgLRivQCglcRpN3tjUs2ptn3l4e6+JvW0 gV0Aniqr8mgjF3DjR+M70a66DSvte4ew =xfDj -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] fix little endian build
On 8/30/10 6:53 PM, Xiangfu Liu wrote: can we apply those patch to MIPS-branch first?? [PATCH 1/2] update the MIPS u-boot.lds I'll push 1/2 to u-boot-mips and request pull later. [PATCH 2/2] change the way of build little endian board but this 2/2 looks problematic. As said in the previous mail the patch is tentative and won't work with ELDK, and as fas as I could see nothing has been changed since my version. Let me make sure, have you confirmed it builds with ELDK? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, orion5x: fix comilerwarning for edminiv2 board
compiling edminiv2 board throws following warning:
Configuring for edminiv2 board...
In file included from /home/hs/i2c/u-boot-i2c/include/asm/arch/orion5x.h:39,
from cpu.c:32:
introduced from commit 4cfa0ab2c945f95e978a995721f193dd056e538d
Author: Albert Aribaud albert.arib...@free.fr
Date: Tue Jul 13 09:04:26 2010 +0200
orion5x: allow overriding default mappings windows
This patch fixes this issue.
Signed-off-by: Heiko Schocher h...@denx.de
CC: Albert Aribaud albert.arib...@free.fr
---
arch/arm/include/asm/arch-orion5x/cpu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-orion5x/cpu.h
b/arch/arm/include/asm/arch-orion5x/cpu.h
index 80717f8..6ce02a9 100644
--- a/arch/arm/include/asm/arch-orion5x/cpu.h
+++ b/arch/arm/include/asm/arch-orion5x/cpu.h
@@ -76,7 +76,7 @@ enum orion5x_cpu_attrib {
/*
* Device Address MAP BAR values
-/*
+ *
* All addresses and sizes not defined by board code
* will be given default values here.
*/
--
1.6.2.5
--
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
Re: [U-Boot] [PATCH V4 0/4] Improve I2C for orion5x, kirkwood and ED Mini V2
Hello Albert, Albert Aribaud wrote: SUMMARY: This patchset improves the driver for the Marvell TWSI interface found on orion5x and kirkwood SoCs and adds I2C support to the orion5x-based ED Mini V2 board. The mvtwsi driver is a complete rewrite, 50% shorter in source code lines, 25% smaller in object size, much simpler and way faster than the kirkwood_i2c driver it replaces. PATCH SET: Patch 1 removes dependencies on kirwkood_i2c from suen3, the only board that mentioned it. Patch 2 renames the driver from kirkwood_i2c to mvtwsi. Patch 3 replaces the old code with the new one. Patch 4 adds support for I2C in orion5x-based ED Mini V2. TESTS: This driver has been tested on an ED Mini V2 with basic u-boot i2c commands, on an 5C372a RTC and an HT24LC08 1 KB eeprom (read+write). HISTORY: V1: Initial submission as an addition rather than a replacement. V2: Fixed copyright line. Made mvtwsi a replacement for kirkwood_i2c. Made patches checkpatch-clean: 0 errors, 0 warnings. Various cosmetic changes. Removed useless i2c_end() function. V3: Reduced line lengths below 78 characters. Removed blank line after function description block comment. V4: Changed CONFIG_I2C_DRIVER_MVTWSI into CONFIG_I2C_MVTWSI. Really fixed copyright line. Added and documented kirkwood support. Shortened extended_slave_address into xtnd_slave_addr. Added explanation on default/init baudrate value. Moved I2C config settings under #ifdef CONFIG_CMD_I2C. Albert Aribaud (4): suen3: remove CONFIG_HARD_I2C and related defines i2c: rename kirkwood_i2c to mvtwsi i2c: rewrite mvtwsi, support orion5x and kirkwood edminiv2: add I2C support using mvtwsi driver drivers/i2c/Makefile |2 +- drivers/i2c/kirkwood_i2c.c | 496 drivers/i2c/mvtwsi.c | 428 ++ include/configs/edminiv2.h | 11 + include/configs/km_arm.h |8 - 5 files changed, 440 insertions(+), 505 deletions(-) delete mode 100644 drivers/i2c/kirkwood_i2c.c create mode 100644 drivers/i2c/mvtwsi.c applied to u-boot-i2c.git Thanks! 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
Re: [U-Boot] [PATCH] arm, orion5x: fix comilerwarning for edminiv2 board
Hi Heiko
This has been already fixed
Ref: http://lists.denx.de/pipermail/u-boot/2010-August/076253.html
Regards..
Prafulla . .
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heiko Schocher
Sent: Monday, August 30, 2010 7:00 PM
To: U-Boot user list
Subject: [U-Boot] [PATCH] arm, orion5x: fix comilerwarning
for edminiv2 board
compiling edminiv2 board throws following warning:
Configuring for edminiv2 board...
In file included from
/home/hs/i2c/u-boot-i2c/include/asm/arch/orion5x.h:39,
from cpu.c:32:
introduced from commit 4cfa0ab2c945f95e978a995721f193dd056e538d
Author: Albert Aribaud albert.arib...@free.fr
Date: Tue Jul 13 09:04:26 2010 +0200
orion5x: allow overriding default mappings windows
This patch fixes this issue.
Signed-off-by: Heiko Schocher h...@denx.de
CC: Albert Aribaud albert.arib...@free.fr
---
arch/arm/include/asm/arch-orion5x/cpu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-orion5x/cpu.h
b/arch/arm/include/asm/arch-orion5x/cpu.h
index 80717f8..6ce02a9 100644
--- a/arch/arm/include/asm/arch-orion5x/cpu.h
+++ b/arch/arm/include/asm/arch-orion5x/cpu.h
@@ -76,7 +76,7 @@ enum orion5x_cpu_attrib {
/*
* Device Address MAP BAR values
-/*
+ *
* All addresses and sizes not defined by board code
* will be given default values here.
*/
--
1.6.2.5
--
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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, orion5x: fix comilerwarning for edminiv2 board
Hello Prafulla, Prafulla Wadaskar wrote: This has been already fixed Ref: http://lists.denx.de/pipermail/u-boot/2010-August/076253.html Ups, sorry, missed that. Thanks! 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] Pull request v3: u-boot-i2c
Hello Wolfgang, The following changes since commit bd2313078114c4b44c4a5ce149af43bcb7fc8854: Wolfgang Denk (1): Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Albert Aribaud (4): suen3: remove CONFIG_HARD_I2C and related defines i2c: rename kirkwood_i2c to mvtwsi i2c: rewrite mvtwsi, support orion5x and kirkwood edminiv2: add I2C support using mvtwsi driver Nishanth Menon (3): i2c: omap2+: change header guard to be generic omap2: i2c: add syss offset omap2: i2c: remove redundant header definitions Reinhard Meyer (1): CMD_I2C: make alen=0 work arch/arm/include/asm/arch-omap24xx/i2c.h | 110 +--- common/cmd_i2c.c | 17 +- drivers/i2c/Makefile |2 +- drivers/i2c/kirkwood_i2c.c | 496 -- drivers/i2c/mvtwsi.c | 428 ++ drivers/i2c/omap24xx_i2c.h |4 +- include/configs/edminiv2.h | 11 + include/configs/km_arm.h |8 - 8 files changed, 452 insertions(+), 624 deletions(-) delete mode 100644 drivers/i2c/kirkwood_i2c.c create mode 100644 drivers/i2c/mvtwsi.c -- 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
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Detlev Zundel schrieb: Detlev, regarding the discussion I would only point out that we have to be sure that such kind of patch will be merged in the current release. It would be a real pity if a new official realease is published and then even a simple md command does not work on ARM. I don't see a problem here. All proposed patches (with/without attribute and union) surely fix a bug, so they will go into mainline when consent is reached on which one to use. This should well happen before the pending release on September 12th[1]. Am I misunderstanding anything here? No... but I would require that the union approach would be wanted, BEFORE I put effort into doing it. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] fix little endian build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2010 09:23 PM, Shinya Kuribayashi wrote: On 8/30/10 6:53 PM, Xiangfu Liu wrote: can we apply those patch to MIPS-branch first?? [PATCH 1/2] update the MIPS u-boot.lds I'll push 1/2 to u-boot-mips and request pull later. [PATCH 2/2] change the way of build little endian board but this 2/2 looks problematic. As said in the previous mail the patch is tentative and won't work with ELDK, and as fas as I could see nothing has been changed since my version. Let me make sure, have you confirmed it builds with ELDK? Hi Shinya yes, I think it not break the ELDK build. I have test with BUILD_DIR=../u-boot-build \ MAKEALL_LOGDIR=../u-boot-log \ ./MAKEALL mips_el mips all boards compile fine. - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx7tYoACgkQRRAEFRxkgLTqGQCeOFdXGSN3OE5Bb1dBIFwi+oqv 5goAoKjGIiKo7JQJlxpxOqGPA/W5aUEv =RU7F -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] android fastboot support on U-boot
The omapzoom project has a u-boot with fastboot support. http://git.omapzoom.org/?p=repo/u-boot.git;a=shortlog;h=refs/heads/omap4_dev_fastboot Beware, that the u-boot base rev is very old. On Mon, Aug 30, 2010 at 5:26 AM, Bas Mevissen ab...@basmevissen.nl wrote: On Mon, 30 Aug 2010 13:11:38 +0200, Detlev Zundel d...@denx.de wrote: Is that fastboot usb-storage based? From the wiki-page that you referenced I only see that you also need a separate host tool to use it. So that's not much of a difference, is it? No, the usb-storage based thing was something I had in mind as a solution for easy firmware update and manipulation. -- Bas ___ 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 0/2] fix little endian build
On 8/30/10 10:43 PM, Xiangfu Liu wrote: [PATCH 2/2] change the way of build little endian board but this 2/2 looks problematic. As said in the previous mail the patch is tentative and won't work with ELDK, and as fas as I could see nothing has been changed since my version. Let me make sure, have you confirmed it builds with ELDK? Hi Shinya yes, I think it not break the ELDK build. I have test with BUILD_DIR=../u-boot-build \ MAKEALL_LOGDIR=../u-boot-log \ ./MAKEALL mips_el mips all boards compile fine. What about the endianness of generated u-boot ELF image then? $ CROSS_COMPILE=mips_4KCle- ./MAKEALL dbau1550_el_config $ file u-boot And could you also provide the version info, please? $ mips_4KCle-gcc --version ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] at91_emac.h: fix typo in register definition
Am 29.08.2010 13:54, schrieb Andreas Bießmann:
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---
arch/arm/include/asm/arch-at91/at91_emac.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_emac.h
b/arch/arm/include/asm/arch-at91/at91_emac.h
index 45ae333..0e2ff78 100644
--- a/arch/arm/include/asm/arch-at91/at91_emac.h
+++ b/arch/arm/include/asm/arch-at91/at91_emac.h
@@ -61,7 +61,7 @@ typedef struct at91_emac {
u32 reserved2[3];
u32 hsh;
u32 hsl;
- u32 sh1l;
+ u32 sa1l;
u32 sa1h;
u32 sa2l;
u32 sa2h;
Ack,
regards Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELDK] Not able to Uncompress Multi Image
Hi Zoolu, Thanks for your reply. yes same u-boot versions are used on the board. We have built 2 multi images and trying to boot on both boards. Image 1 boots on both boards fine and no problem. Image 2 boots on one board and stops uncompressing multi-image on 2nd board. Both Image1 and Image 2 are built out of same code base. So we do not undertstand what would be the difference as the 2nd board boots image 1 successfully. I also tried to verify the CRC and it is all fine On 2nd board it stops throwing out Uncompressing Multi-File Image ... Do let us know if there are any other methods !! ( We have 256 MB Ram and i am using 0x400 for download). Well the obvious method is to attach a JTAG debugger and step through the code. If you don't have such a debugger it will be more complicated, but you can try to use the poor man debugger, i.e. printf statements in the code. The other method is to think again what differences there are between both boards. If they behave differently, then there have to be differences. If the software is completely the same, then maybe the sequence of events before you boot the image is different. Try to execute _exactly_ the same commands from power-on-reset and note any differenc in output. Sorry, this is as much as we can do from the distance. Cheers Detlev -- The structure of a system reflects the structure of the organization that built it. -- Richard E. Fairley -- 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] [PATCH] display_buffer: fix misaligned buffer
Hi Reinhard, Detlev Zundel schrieb: Detlev, regarding the discussion I would only point out that we have to be sure that such kind of patch will be merged in the current release. It would be a real pity if a new official realease is published and then even a simple md command does not work on ARM. I don't see a problem here. All proposed patches (with/without attribute and union) surely fix a bug, so they will go into mainline when consent is reached on which one to use. This should well happen before the pending release on September 12th[1]. Am I misunderstanding anything here? No... but I would require that the union approach would be wanted, BEFORE I put effort into doing it. I'd very much appreciate your effort as I want the solution now that you did whet my appetite. Thanks Detlev -- The fact is, volatile on data structures is a bug. It's a wart in the C language. It shouldn't be used. -- Linus Torvalds -- 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] [PATCH 1/8] APM82xxx: Add CPU support
Stefan,
Thanks for the review. I will fix accordingly.
Regards,
Marri
-Original Message-
From: Stefan Roese [mailto:s...@denx.de]
Sent: Friday, August 27, 2010 2:02 AM
To: u-boot@lists.denx.de
Cc: tma...@apm.com; open-source-rev...@apm.com
Subject: Re: [U-Boot] [PATCH 1/8] APM82xxx: Add CPU support
Hi Marri,
On Thursday 26 August 2010 23:05:44 tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
APM82XXX is a new line of SoCs which are derivatives of
PPC44X family of processors. This patch adds support of CPU, cache,
tlb, 32k ocm, bootstraps, PLB and AHB bus.
Thanks. General comment: Please add me on Cc on these PPC4xx
related patches. More comments below.
Signed-off-by: Tirumala R Marri tma...@apm.com
---
arch/powerpc/cpu/ppc4xx/cpu.c| 35
+++-- arch/powerpc/cpu/ppc4xx/cpu_init.c
|
9 ---
arch/powerpc/cpu/ppc4xx/start.S | 10 +++-
arch/powerpc/include/asm/processor.h |1 +
4 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/cpu/ppc4xx/cpu.c
b/arch/powerpc/cpu/ppc4xx/cpu.c
index 851065c..5fe5d8c 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu.c
@@ -80,7 +80,8 @@ static int pci_async_enabled(void)
#endif /* CONFIG_PCI */
#if defined(CONFIG_PCI) !defined(CONFIG_IOP480) \
-!defined(CONFIG_405) !defined(CONFIG_405EX)
+!defined(CONFIG_405) !defined(CONFIG_405EX) \
+!defined(CONFIG_APM82XXX)
int pci_arbiter_enabled(void)
{
#if defined(CONFIG_405GP)
@@ -250,6 +251,21 @@ static char *bootstrap_str[] = {
};
static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'G', 'F',
'H' };
#endif
+#if defined(CONFIG_APM82XXX)
+#define SDR0_PINSTP_SHIFT 29
+static char *bootstrap_str[] = {
+ RESERVED,
+ RESERVED,
+ RESERVED,
+ NAND (8 bits),
+ NOR (8 bits),
+ NOR (8 bits) w/PLL Bypassed,
+ I2C (Addr 0x54),
+ I2C (Addr 0x52),
+};
+static char bootstrap_char[] = { 'A', 'B', 'C', 'D', 'E', 'F', 'G',
'H' };
+#endif
+
#if defined(SDR0_PINSTP_SHIFT)
static int bootstrap_option(void)
@@ -285,7 +301,7 @@ int checkcpu (void)
uint pvr = get_pvr();
ulong clock = gd-cpu_clk;
char buf[32];
-#if defined(CONFIG_460EX) || defined(CONFIG_460GT)
+#if defined(CONFIG_460EX) || defined(CONFIG_460GT) ||
defined(CONFIG_APM82XXX) u32 reg;
#endif
@@ -304,6 +320,8 @@ int checkcpu (void)
#if defined(CONFIG_XILINX_440)
puts(IBM PowerPC 4);
+#elif defined(CONFIG_APM82XXX)
+ puts(APM PowerPC APM82);
#else
puts(AMCC PowerPC 4);
#endif
@@ -316,7 +334,7 @@ int checkcpu (void)
#if defined(CONFIG_440)
#if defined(CONFIG_460EX) || defined(CONFIG_460GT)
puts(60);
-#else
+#elif !defined(CONFIG_APM82XXX)
puts(40);
#endif
#endif
@@ -598,7 +616,18 @@ int checkcpu (void)
puts(GX Rev. A);
strcpy(addstr, No Security support);
break;
+#if defined(CONFIG_APM82XXX)
+ case PVR_APM82XXX_RA:
+ mfsdr(SDR0_ECID3, reg);
+ if (reg 0x0020)
+ puts(181 Rev. A);
+ if (reg 0x0010)
+ strcpy(addstr, No Security support);
+ else
+ strcpy(addstr, Security support);
+ break;
+#endif
case PVR_VIRTEX5:
puts(x5 VIRTEX5);
break;
diff --git a/arch/powerpc/cpu/ppc4xx/cpu_init.c
b/arch/powerpc/cpu/ppc4xx/cpu_init.c index c04eede..2308051 100644
--- a/arch/powerpc/cpu/ppc4xx/cpu_init.c
+++ b/arch/powerpc/cpu/ppc4xx/cpu_init.c
@@ -35,7 +35,6 @@ DECLARE_GLOBAL_DATA_PTR;
#ifndef CONFIG_SYS_PLL_RECONFIG
#define CONFIG_SYS_PLL_RECONFIG0
#endif
-
Why did you remove this empty line?
Please fix and resubmit. Thanks.
Cheers,
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 v5 1/5] mtdparts: regroup calls to get_mtd_device_nm
The get_mtd_device_nm function is called in a couple places and the
string that is passed to it is not really used after the calls.
This patch regroups the calls to this function into a new function,
get_mtd_info.
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
Acked-by: Stefan Roese s...@denx.de
CC: Wolfgang Denk w...@denx.de
---
V2:
* formatting: add space after 'if'
* added acked-by tag as requested by Stefan
V3:
* rebased to 54841ab50c20d6fa6c9cc3eb826989da3a22d934 of
git://git.denx.de/u-boot.git
V4:
* rebased to b417260d871d4d8d336c160d95ed40cc8c0fb0fa of
git://git.denx.de/u-boot.git
* fixed multi-line comment style
V5:
* rebased to 962ad59e25640e586e2bceabf67a628a27f8f508 of
git://git.denx.de/u-boot.git
* renumbered from 1/4 to 1/5
---
common/cmd_mtdparts.c | 45 ++---
1 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index ceec5a9..772ad54 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -286,6 +286,29 @@ static void current_save(void)
index_partitions();
}
+
+/**
+ * Produce a mtd_info given a type and num.
+ *
+ * @param type mtd type
+ * @param num mtd number
+ * @param mtd a pointer to an mtd_info instance (output)
+ * @return 0 if device is valid, 1 otherwise
+ */
+static int get_mtd_info(u8 type, u8 num, struct mtd_info **mtd)
+{
+ char mtd_dev[16];
+
+ sprintf(mtd_dev, %s%d, MTD_DEV_TYPE(type), num);
+ *mtd = get_mtd_device_nm(mtd_dev);
+ if (IS_ERR(*mtd)) {
+ printf(Device %s not found!\n, mtd_dev);
+ return 1;
+ }
+
+ return 0;
+}
+
/**
* Performs sanity check for supplied flash partition.
* Table of existing MTD flash devices is searched and partition device
@@ -297,17 +320,12 @@ static void current_save(void)
*/
static int part_validate_eraseblock(struct mtdids *id, struct part_info *part)
{
- struct mtd_info *mtd;
- char mtd_dev[16];
+ struct mtd_info *mtd = NULL;
int i, j;
ulong start;
- sprintf(mtd_dev, %s%d, MTD_DEV_TYPE(id-type), id-num);
- mtd = get_mtd_device_nm(mtd_dev);
- if (IS_ERR(mtd)) {
- printf(Partition %s not found on device %s!\n, part-name,
mtd_dev);
+ if (get_mtd_info(id-type, id-num, mtd))
return 1;
- }
part-sector_size = mtd-erasesize;
@@ -684,20 +702,17 @@ static int part_parse(const char *const partdef, const
char **ret, struct part_i
/**
* Check device number to be within valid range for given device type.
*
- * @param dev device to validate
+ * @param type mtd type
+ * @param num mtd number
+ * @param size a pointer to the size of the mtd device (output)
* @return 0 if device is valid, 1 otherwise
*/
int mtd_device_validate(u8 type, u8 num, u32 *size)
{
- struct mtd_info *mtd;
- char mtd_dev[16];
+ struct mtd_info *mtd = NULL;
- sprintf(mtd_dev, %s%d, MTD_DEV_TYPE(type), num);
- mtd = get_mtd_device_nm(mtd_dev);
- if (IS_ERR(mtd)) {
- printf(Device %s not found!\n, mtd_dev);
+ if (get_mtd_info(type, num, mtd))
return 1;
- }
*size = mtd-size;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/5] mtd: add an mtd method for get_len_incl_bad()
The logic to 'spread' mtd partitions needs to calculate the length in
the mtd device, including bad blocks.
This patch introduces a new function, mtd_get_len_incl_bad that can
return both the length including bad blocks and whether that length
was truncated on the device. This new function will be used by the
mtdparts spread command later in this series. The definition of the
function is #ifdef'd out in configurations that do not use the new
'mtdparts spread' command.
Signed-off-by: Ben Gardinerbengardi...@nanometrics.ca
CC: Scott Wood scottw...@freescale.com
---
Note: the mtd_get_len_incl_bad() function could also be used by the
get_len_incl_bad() function in nand_util.c except for the fact that
boards can enable NAND support without enabling MTD support. A note
has been added to get_len_incl_bad() to remind us to refactor when/if
MTD support is available whenever NAND support is enabled.
V5:
* introduced in v5 of this patchset
---
drivers/mtd/mtdcore.c| 44 ++
drivers/mtd/nand/nand_util.c |6 +
include/linux/mtd/mtd.h |4 ++-
3 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 6eb52ed..cb86657 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -142,3 +142,47 @@ void put_mtd_device(struct mtd_info *mtd)
c = --mtd-usecount;
BUG_ON(c 0);
}
+
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+/**
+ * mtd_get_len_incl_bad
+ *
+ * Check if length including bad blocks fits into device.
+ *
+ * @param mtd an MTD device
+ * @param offset offset in flash
+ * @param length image length
+ * @return image length including bad blocks in *len_incl_bad and whether or
not
+ * the length returned was truncated in *truncated
+ */
+void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t offset,
+ const uint64_t length, uint64_t *len_incl_bad,
+ int *truncated)
+{
+ *truncated = 0;
+ *len_incl_bad = 0;
+
+ if (!mtd-block_isbad) {
+ *len_incl_bad = length;
+ return;
+ }
+
+ uint64_t len_excl_bad = 0;
+ uint64_t block_len;
+
+ while (len_excl_bad length) {
+ block_len = mtd-erasesize - (offset (mtd-erasesize - 1));
+
+ if (!mtd-block_isbad(mtd, offset ~(mtd-erasesize - 1)))
+ len_excl_bad += block_len;
+
+ *len_incl_bad += block_len;
+ offset += block_len;
+
+ if (offset = mtd-size) {
+ *truncated = 1;
+ break;
+ }
+ }
+}
+#endif /* defined(CONFIG_CMD_MTDPARTS_SPREAD) */
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 29c42f7..622237f 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -435,6 +435,12 @@ int nand_unlock(struct mtd_info *mtd, ulong start, ulong
length)
static size_t get_len_incl_bad (nand_info_t *nand, loff_t offset,
const size_t length)
{
+ /*
+* TODO: replace this implementation with a call to
+* mtd_get_len_incl_bad((struct mtd_info *) nand, ...)
+* when CONFIG_MTD_DEVICE is required for NAND support
+*/
+
size_t len_incl_bad = 0;
size_t len_excl_bad = 0;
size_t block_len;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 16556c4..8e8ec7c 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -259,7 +259,9 @@ extern struct mtd_info *get_mtd_device(struct mtd_info
*mtd, int num);
extern struct mtd_info *get_mtd_device_nm(const char *name);
extern void put_mtd_device(struct mtd_info *mtd);
-
+extern void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t offset,
+const uint64_t length, uint64_t *len_incl_bad,
+int *truncated);
/* XXX U-BOOT XXX */
#if 0
struct mtd_notifier {
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/5] mtdparts: show net size in mtdparts list
This patch adds an additional column to the output of list_partitions. The
additional column will contain the net size and a '(!)' beside it if the net
size is not equal to the partition size.
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
CC: Wolfgang Denk w...@denx.de
CC: Scott Wood scottw...@freescale.com
---
V2:
* formatting: spaces after 'if' and 'for'
* the entire new feature is conditional on a macro, there is now a zero-byte
binary size impact when the macro is not defined.
* return the net parition size directly from net_part_size instead of using
an output variable
V3:
* rebased to 54841ab50c20d6fa6c9cc3eb826989da3a22d934 of
git://git.denx.de/u-boot.git
* fix line length over 80 chars
* update copyright of cmd_mtdparts.c
V4:
* rebased to b417260d871d4d8d336c160d95ed40cc8c0fb0fa of
git://git.denx.de/u-boot.git
* removed copyright statement and changelog from file header
* re-grouped list_partition #ifdefs into one
* fixed multi-line comment style
V5:
* rebased to 962ad59e25640e586e2bceabf67a628a27f8f508 of
git://git.denx.de/u-boot.git
* renumbered from 2/4 to 3/5
* return uint64_t instead of u32 for net_size
* do a quick if((cond) return
* calculate net_size by adding-up good blocks instead of subtracting bad
blocks
* try to strike a balance; reuse more code between the branches of
#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) in
print_partition_table
---
common/cmd_mtdparts.c | 74 +++-
drivers/mtd/mtdcore.c |5 ++-
2 files changed, 69 insertions(+), 10 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 772ad54..a8912ed 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -1215,38 +1215,96 @@ static int generate_mtdparts_save(char *buf, u32 buflen)
return ret;
}
+#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES)
/**
- * Format and print out a partition list for each device from global device
- * list.
+ * Get the net size (w/o bad blocks) of the given partition.
+ *
+ * @param mtd the mtd info
+ * @param part the partition
+ * @return the calculated net size of this partition
*/
-static void list_partitions(void)
+static uint64_t net_part_size(struct mtd_info *mtd, struct part_info *part)
+{
+ uint64_t gross_size, trailing_bad_size = 0;
+ int truncated = 0;
+
+ mtd_get_len_incl_bad(mtd, part-offset, part-size, gross_size,
+truncated);
+
+ if (!truncated) {
+ mtd_get_len_incl_bad(mtd, part-offset + part-size,
+mtd-erasesize, trailing_bad_size,
+truncated);
+ trailing_bad_size -= mtd-erasesize;
+ }
+
+ return part-size - (gross_size - trailing_bad_size - part-size);
+}
+#endif
+
+static void print_partition_table(void)
{
struct list_head *dentry, *pentry;
struct part_info *part;
struct mtd_device *dev;
int part_num;
- debug(\n---list_partitions---\n);
- list_for_each(dentry, devices) {
+list_for_each(dentry, devices) {
dev = list_entry(dentry, struct mtd_device, link);
+ /* list partitions for given device */
+ part_num = 0;
+#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES)
+ struct mtd_info *mtd;
+
+ if (get_mtd_info(dev-id-type, dev-id-num, mtd))
+ return;
+
+ printf(\ndevice %s%d %s, # parts = %d\n,
+ MTD_DEV_TYPE(dev-id-type), dev-id-num,
+ dev-id-mtd_id, dev-num_parts);
+ printf( #: name\t\tsize\t\tnet size\toffset\t\tmask_flags\n);
+
+ list_for_each(pentry, dev-parts) {
+ u32 net_size;
+ char *size_note;
+
+ part = list_entry(pentry, struct part_info, link);
+ net_size = net_part_size(mtd, part);
+ size_note = part-size == net_size ? : (!);
+ printf(%2d: %-20s0x%08x\t0x%08x%s\t0x%08x\t%d\n,
+ part_num, part-name, part-size,
+ net_size, size_note, part-offset,
+ part-mask_flags);
+#else /* !defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
printf(\ndevice %s%d %s, # parts = %d\n,
MTD_DEV_TYPE(dev-id-type), dev-id-num,
dev-id-mtd_id, dev-num_parts);
printf( #: name\t\tsize\t\toffset\t\tmask_flags\n);
- /* list partitions for given device */
- part_num = 0;
list_for_each(pentry, dev-parts) {
part = list_entry(pentry, struct part_info, link);
printf(%2d: %-20s0x%08x\t0x%08x\t%d\n,
[U-Boot] [PATCH v5 5/5] mtdparts: new add.spread: add part skipping bad blocks
This patch adds a new 'mtdparts add' variant: add.spread. This command variant
adds a new partition to the mtdparts variable but also increases the partitions
size by skipping bad blocks and aggregating any additional bad blocks found at
the end of the partition.
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
CC: Wolfgang Denk w...@denx.de
CC: Scott Wood scottw...@freescale.com
---
V2:
* formatting: spaces after 'if' and 'for'
* trailing whitespace removed
V3:
* rebased to 54841ab50c20d6fa6c9cc3eb826989da3a22d934 of
git://git.denx.de/u-boot.git
* fix more checkpatch errors
* updating copyright to include addition of add.e command
V4:
* rebased to b417260d871d4d8d336c160d95ed40cc8c0fb0fa of
git://git.denx.de/u-boot.git
* removed changelog from file header
* check for s == NULL when looking for '.' in command
* do not include support for the '.i' synonym
* rename to 'add.spread' to match 'mtdparts spread' as per Scott Wood's
suggestion.
V5:
* rebased to 962ad59e25640e586e2bceabf67a628a27f8f508 of
git://git.denx.de/u-boot.git
* renumbered from 4/4 to 5/5
* don't reproduce the same call to spread_partitions on either side
of the check for existing device -- as per Scott Wood's comments.
---
common/cmd_mtdparts.c | 34 ++
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index fb8c77b..d8cda77 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -1950,9 +1950,13 @@ int do_mtdparts(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
/* mtdparts add mtd-dev size[@offset] name [ro] */
- if (((argc == 5) || (argc == 6)) (strcmp(argv[1], add) == 0)) {
+ if (((argc == 5) || (argc == 6)) (strncmp(argv[1], add, 3) == 0)) {
#define PART_ADD_DESC_MAXLEN 64
char tmpbuf[PART_ADD_DESC_MAXLEN];
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+ struct mtd_info *mtd;
+ uint64_t next_offset;
+#endif
u8 type, num, len;
struct mtd_device *dev;
struct mtd_device *dev_tmp;
@@ -1987,15 +1991,25 @@ int do_mtdparts(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
debug(+ %s\t%d\t%s\n, MTD_DEV_TYPE(dev-id-type),
dev-id-num, dev-id-mtd_id);
- if ((dev_tmp = device_find(dev-id-type, dev-id-num)) ==
NULL) {
+ p = list_entry(dev-parts.next, struct part_info, link);
+
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+ if (get_mtd_info(dev-id-type, dev-id-num, mtd))
+ return 1;
+
+ if (!strcmp(argv[1][3], .spread)) {
+ spread_partition(mtd, p, next_offset);
+ debug(increased %s to %d bytes\n, p-name, p-size);
+ }
+#endif
+
+ dev_tmp = device_find(dev-id-type, dev-id-num);
+ if (dev_tmp == NULL) {
device_add(dev);
- } else {
+ } else if (part_add(dev_tmp, p) != 0) {
/* merge new partition with existing ones*/
- p = list_entry(dev-parts.next, struct part_info, link);
- if (part_add(dev_tmp, p) != 0) {
- device_del(dev);
- return 1;
- }
+ device_del(dev);
+ return 1;
}
if (generate_mtdparts_save(last_parts, MTDPARTS_MAXLEN) != 0) {
@@ -2040,6 +2054,10 @@ U_BOOT_CMD(
- delete partition (e.g. part-id = nand0,1)\n
mtdparts add mtd-dev size[@offset] [name] [ro]\n
- add partition\n
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+ mtdparts add.spread mtd-dev size[@offset] [name] [ro]\n
+ - add partition, padding size by skipping bad blocks\n
+#endif
mtdparts default\n
- reset partition table to defaults\n
#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] APM82xxx: Add top level common file changes
On Thursday 26 August 2010 23:06:20 tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com Add bluestone board name to the board.cfg. Change Makefile to include bluestone board support. Not needed with board.cfg now. Please remove your changes to Makefile. Compiling bluestone results in this warning: [Marri] Sure will fix it. [ste...@stefan-desktop u-boot (apm82xxx)]$ ./MAKEALL bluestone Configuring for bluestone board... cpu_init.c: In function 'cpu_init_f': cpu_init.c:226: warning: unused variable 'val' Please fix and resubmit. Thanks. Cheers, Stefan Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] APM82xxx: Add UIC support
This patch adds Universal Interrupt Controller support for APM82XXX processor. Signed-off-by: Tirumala R Marri tma...@apm.com [...] diff --git a/arch/powerpc/include/asm/ppc4xx-uic.h b/arch/powerpc/include/asm/ppc4xx-uic.h index 782d045..238b70b 100644 --- a/arch/powerpc/include/asm/ppc4xx-uic.h +++ b/arch/powerpc/include/asm/ppc4xx-uic.h [...] @@ -252,7 +252,8 @@ #define VECNUM_ETH0(32 + 28) #endif /* CONFIG_440SPE */ -#if defined(CONFIG_460EX) || defined(CONFIG_460GT) +#if defined(CONFIG_460EX) || defined(CONFIG_460GT) ||\ Please add space before \ to keep the style consistent. [Marri] Sure will fix it. Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] APM82xxx: Add SRAM support
Signed-off-by: Tirumala R Marri tma...@apm.com [...] diff --git a/arch/powerpc/include/asm/ppc4xx-isram.h b/arch/powerpc/include/asm/ppc4xx-isram.h index d6d17ac..b723401 100644 --- a/arch/powerpc/include/asm/ppc4xx-isram.h +++ b/arch/powerpc/include/asm/ppc4xx-isram.h @@ -25,7 +25,8 @@ /* * Internal SRAM */ -#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) +#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) ||\ Please add space before \ to keep the style consistent. [Marri] Sure will do +defined(CONFIG_APM82XXX) #define ISRAM0_DCR_BASE 0x380 #else #define ISRAM0_DCR_BASE 0x020 @@ -42,7 +43,8 @@ #define ISRAM0_REVID (ISRAM0_DCR_BASE+0x09) /* SRAM bus revision id reg */ #define ISRAM0_DPC (ISRAM0_DCR_BASE+0x0a) /* SRAM data parity check reg */ -#if defined(CONFIG_460EX) || defined(CONFIG_460GT) +#if defined(CONFIG_460EX) || defined(CONFIG_460GT) ||\ Same here... [Marri] Ok +defined(CONFIG_APM82XXX) #define ISRAM1_DCR_BASE 0x0B0 #define ISRAM1_SB0CR (ISRAM1_DCR_BASE+0x00) /* SRAM1 bank config 0*/ #define ISRAM1_BEAR(ISRAM1_DCR_BASE+0x04) /* SRAM1 bus error addr reg */ Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/5] mtdparts: add new sub-command spread
This patch introduces the 'spread' sub-command of the mtdparts command.
This command will modify the existing mtdparts variable by increasing
the size of the partitions such that 1) each partition's net size is at
least as large as the size specified in the mtdparts variable and 2)
each partition starts on a good block.
The new subcommand is implemented by iterating over the mtd device
partitions and collecting a bad blocks count in each -- including any
trailing bad blocks -- and then modifying that partitions's part_info
structure and checking if the modification affects the next partition.
This patch is based on a port of the 'dynnamic partitions' feature by
Harald Welte lafo...@gnumonks.org; ported from commit
e05835df019027391f58f9d8ce5e1257d6924798 of
git://git.openmoko.org/u-boot.git. Whereas Harald's feature used a
compile-time array to specify partitions, the feature introduced by
this patch uses the mtdparts environment variable.
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
Signed-off-by: Harald Welte lafo...@gnumonks.org
CC: Wolfgang Denk w...@denx.de
CC: Scott Wood scottw...@freescale.com
---
V2:
* formatting: spaces after 'if' and 'for'
* trailing whitespace removed
* check for null mtd-block_isbad before dereferencing
V3:
* rebased to 54841ab50c20d6fa6c9cc3eb826989da3a22d934 of
git://git.denx.de/u-boot.git
* fix more checkpatch errors
* update copyright statement of cmd_mtdparts.c to include openmoko's
copyright of the 'dynamic partitions' functionality using commit
e05835df019027391f58f9d8ce5e1257d6924798 of
git://git.openmoko.org/u-boot.git as reference.
V4:
* rebased to b417260d871d4d8d336c160d95ed40cc8c0fb0fa of
git://git.denx.de/u-boot.git
* fixed multi-line comment style
* removed changelog and my (C) from file header
* added source of port to the commit message
* fixed multi-line comment style
* indentation only by tabs
V5:
* rebased to 962ad59e25640e586e2bceabf67a628a27f8f508 of
git://git.denx.de/u-boot.git
* renumbered from 3/4 to 4/5
* use uint64_t for net_size
* don't push dangling lines to the right
* offsets to uint64_t
* fix spelling errors in comments
* more hanging arguments alignment
* refactor the spread_partition function so that it delegates the
bad-block counting to the mtd_get_len_incl_bad function -- as per
Scott Woods' suggestion.
---
common/cmd_mtdparts.c | 110 -
1 files changed, 109 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index a8912ed..fb8c77b 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -15,6 +15,9 @@
* Parsing routines are based on driver/mtd/cmdline.c from the linux 2.4
* kernel tree.
*
+ * (C) Copyright 2008
+ * Harald Welte, OpenMoko, Inc., Harald Welte lafo...@openmoko.org
+ *
* $Id: cmdlinepart.c,v 1.17 2004/11/26 11:18:47 lavinen Exp $
* Copyright 2002 SYSGO Real-Time Solutions GmbH
*
@@ -1428,6 +1431,98 @@ static int delete_partition(const char *id)
return 1;
}
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+/**
+ * Increase the size of the given partition so that it's net size is at least
+ * as large as the size member and such that the next partition would start on
a
+ * good block if it were adjacent to this partition.
+ *
+ * @param mtd the mtd device
+ * @param part the partition
+ * @param next_offset pointer to the offset of the next partition after this
+ *partition's size has been modified (output)
+ */
+static void spread_partition(struct mtd_info *mtd, struct part_info *part,
+uint64_t *next_offset)
+{
+ uint64_t net_size, padding_size = 0;
+ int truncated;
+
+ mtd_get_len_incl_bad(mtd, part-offset, part-size, net_size,
+truncated);
+
+ /*
+* Absorb bad blocks immediately following this
+* partition also into the partition, such that
+* the next partition starts with a good block.
+*/
+ if (!truncated) {
+ mtd_get_len_incl_bad(mtd, part-offset + net_size,
+mtd-erasesize, padding_size, truncated);
+ padding_size -= mtd-erasesize;
+ }
+
+ if (truncated) {
+ printf(truncated partition %s to %lld bytes\n, part-name,
+ (uint64_t) net_size + padding_size);
+ }
+
+ part-size = net_size + padding_size;
+ *next_offset = part-offset + part-size;
+}
+
+/**
+ * Adjust all of the partition sizes, such that all partitions are at least
+ * as big as their mtdparts environment variable sizes and they each start
+ * on a good block.
+ *
+ * @return 0 on success, 1 otherwise
+ */
+static int spread_partitions(void)
+{
+ struct list_head *dentry, *pentry;
+ struct mtd_device *dev;
+ struct part_info *part;
+ struct mtd_info *mtd;
+ int part_num;
+ uint64_t
[U-Boot] [PATCH v5 0/5] mtdparts: add bad-block skipping
Ben Gardiner (5): mtdparts: regroup calls to get_mtd_device_nm mtd: add an mtd method for get_len_incl_bad() mtdparts: show net size in mtdparts list mtdparts: add new sub-command spread mtdparts: new add.spread: add part skipping bad blocks common/cmd_mtdparts.c| 263 - drivers/mtd/mtdcore.c| 45 +++ drivers/mtd/nand/nand_util.c |6 + include/linux/mtd/mtd.h |4 +- 4 files changed, 285 insertions(+), 33 deletions(-) This patch series is based on the idea of Harald Welte lafo...@gnumonks.org and the comments of Wolfgang Denk w...@denx.de [1]. I started with Harald's original patch and migrated it to a new mtdparts sub-command and added an interface to the new functionality via a 'mtdparts add' variant. I tried to keep it at the level of the mtd subsystem. Whereas the dynparts patch was limited to NAND flashes, I believe this patch will work on any mtd device that can report bad blocks. These new commands can be useful when gang programming NAND chips where the gang programmer is capable only of skipping bad blocks. One can use a master image that contains images of each of the partitions padded-out to their spec'd sizes; when u-boot first comes up 'mtdparts default; mtdparts spread' (or a seq of 'mtdpart add.spread' commands) will produce a partition table that matches what was put there by the gang-programmer. It can also be useful when doing in-situ programming with u-boot being the flash programmer as demonstrated by the openmoko project's use of the 'dynpart' command [2] upon which this patch series was based. Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/43549 [2] http://wiki.openmoko.org/wiki/NAND_bad_blocks --- V2: * formating: spaces after 'if' and for * printing net partition sizes feature is now conditional on the new CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES macro; patch 2/4 was adding 264 bytes to the virtlab2 build -- now it adds 0 bytes -- see below for more binary size impact details * changed the net_part_size method to return the net size instead of using an output variable * checking mtd-block_isbad function pointer before dereferencing * there were some trailing whitespace errors when applying 3/4 and 4/4 that I have fixed now V3: * rebased to 54841ab50c20d6fa6c9cc3eb826989da3a22d934 of git://git.denx.de/u-boot.git * more checkpatch fixes * adding openmoko to the copyright statements in cmd_mtdparts.c V4: * rebased to b417260d871d4d8d336c160d95ed40cc8c0fb0fa of git://git.denx.de/u-boot.git * re-grouped list_partition #ifdefs into one * removed changelog and my (C) from file header * added source of port to the commit message * fixed multi-line comment style * indentation only by tabs * check for s == NULL when looking for '.' in command * do not include support for the '.i' synonym * rename to 'add.spread' to match 'mtdparts spread' as per Scott Wood's suggestion. V5: * rebased to 962ad59e25640e586e2bceabf67a628a27f8f508 of git://git.denx.de/u-boot.git * renumbered patches; V5 introduces patch 2/5 * return uint64_t instead of u32 for net_size * do a quick if((cond) return * calculate net_size by adding-up good blocks instead of subtracting bad blocks * try to strike a balance; reuse more code between the branches of #if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) in print_partition_table * don't push dangling lines to the right * fix spelling errors in comments * more hanging arguments alignment * refactor the spread_partition function so that it delegates the bad-block counting to the mtd_get_len_incl_bad function -- as per Scott Woods' suggestion. * don't reproduce the same call to spread_partitions on either side of the check for existing device -- as per Scott Wood's comments. Testing was performed with da850evm.h plus NAND enabled. Here is an example u-boot console session to demonstrate how the commands work: --- U-Boot mtdparts default U-Boot nand bad Device 0 bad blocks: 062c 0a14 128a 12e2 18bc 1ff8 1ffa 1ffc 1ffe U-Boot mtdparts device nand0 davinci_nand.1, # parts = 11 #: namesizenet sizeoffset mask_flags 0: zero0x000c 0x000c 0x 1 1: conf0x0020 0x0020 0x000c 0 2: kernel_a0x0040 0x0040 0x002c 0 3: initrd_a0x0040 0x0040 0x006c 0 4: rootfs_a0x0702 0x0700 (!) 0x00ac 0 5: kernel_b0x0040 0x0040 0x07ae 0 6: initrd_b0x0040 0x0040 0x07ee 0 7: rootfs_b0x0702 0x0700 (!)
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Le 30/08/2010 18:47, Detlev Zundel a écrit : Hi Reinhard, Detlev Zundel schrieb: Detlev, regarding the discussion I would only point out that we have to be sure that such kind of patch will be merged in the current release. It would be a real pity if a new official realease is published and then even a simple md command does not work on ARM. I don't see a problem here. All proposed patches (with/without attribute and union) surely fix a bug, so they will go into mainline when consent is reached on which one to use. This should well happen before the pending release on September 12th[1]. Am I misunderstanding anything here? No... but I would require that the union approach would be wanted, BEFORE I put effort into doing it. I'd very much appreciate your effort as I want the solution now that you did whet my appetite. Besides, re: 'fixing with the side-effect of a different thing': I think the alignment caused by using an union is not actually a side effect of it but an intended effect of it, as the compiler must ensure correct alignment of each union member -- on architectures where alignment of 32-bit ints is unnecessary, the union will not cause undue alignment, whereas the __aligned__ attribute would. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Board support patches for the eXMeritus HWW-1U-1A devices
Hello all! I posted this patch series a few weeks back on the u-boot mailing list and never got any responses, so I'm resubmitting it again with a couple more folks on the CC list. This is my first U-Boot submission, so my apologies if there are any coding style or conventions issues. Please let me know and I'll get them fixed up quickly. In addition, these patches were initially based on v2010.03 and I realize that upstream may have diverged a bit since then. Please let me know what GIT tree I should rebase these patches on for future submissions. The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis with 3 independent TEMPEST zones. Two independent P2020 computers may be found inside each zone. Complete hardware support is included. There are a couple preliminary patches to common code, but basically everything else is limited to our own board-support code. A GIT tree containing these patches may be found here: git://opensource.exmeritus.com/hww-1u-1a/u-boot.git master http://opensource.exmeritus.com/git/hww-1u-1a/u-boot.git/master I look forward to your comments and criticisms. Cheers, Kyle Moffett -- Overall diffstat below: MAKEALL |2 + Makefile |4 + board/exmeritus/hww-1u-1a/Makefile| 54 +++ board/exmeritus/hww-1u-1a/config.mk | 31 ++ board/exmeritus/hww-1u-1a/ddr.c | 136 +++ board/exmeritus/hww-1u-1a/gpios.h | 131 ++ board/exmeritus/hww-1u-1a/hww-1u-1a.c | 697 + board/exmeritus/hww-1u-1a/law.c | 40 ++ board/exmeritus/hww-1u-1a/tlb.c | 93 + common/ddr_spd.c |4 +- cpu/mpc85xx/cpu.c |7 +- cpu/mpc8xxx/ddr/ddr2_dimm_params.c| 30 +- drivers/net/e1000.c |7 + include/configs/HWW_1U_1A.h | 478 ++ 14 files changed, 1702 insertions(+), 12 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC][PATCH 2/3] e1000: Intel 82571EB: Don't wait for MNG cycle on unmanaged chips
The Intel 82571EB chipset can be used in an unmanaged configuration as a
fast dual-port Gig-E controller. Unfortunately a board consturcted that
way would fail to correctly come up because the driver polls for the
completion of a management cycle that will never occur.
To resolve this problem, we disable the poll and error return on chips
whose EEPROMS indicate no management. As a protection against
misconfigured chipsets, we still delay for the entire management poll
timeout.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
Jeff Kirsher jeffrey.t.kirs...@intel.com has already accepted a similar
patch to the Linux kernel into his e1000e patch queue.
drivers/net/e1000.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 2825342..c9677b4 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4266,6 +4266,13 @@ e1000_get_phy_cfg_done(struct e1000_hw *hw)
/* Fall Through */
case e1000_82571:
case e1000_82572:
+ /* Don't bother polling the management regs if unmanaged */
+ if (!e1000_check_mng_mode(hw)) {
+ DEBUGOUT(Unmanaged chip... skipping MNG polling\n);
+ mdelay(timeout);
+ return 0;
+ }
+
while (timeout) {
if (E1000_READ_REG(hw, EEMNGCTL) cfg_mask)
break;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC][PATCH 1/3] DDR2: Support new JEDEC DDR2 SPD 1.3 spec
The new DDR2 SPD spec is backwards-compatible with the old one, but
there are DIMMs which are being produced which have new SPD version
fields that fail to work with U-boot.
To make the code a bit more readable, we add some human-readable
SPD_DIMM_TYPE_* constants.
Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com
---
common/ddr_spd.c |4 ++--
cpu/mpc8xxx/ddr/ddr2_dimm_params.c | 30 ++
2 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/common/ddr_spd.c b/common/ddr_spd.c
index c058e4f..f7a482e 100644
--- a/common/ddr_spd.c
+++ b/common/ddr_spd.c
@@ -18,9 +18,9 @@ spd_check(const u8 *buf, u8 spd_rev, u8 spd_cksum)
/*
* Check SPD revision supported
-* Rev 1.2 or less supported by this code
+* Rev 1.3 or less supported by this code
*/
- if (spd_rev 0x12) {
+ if (spd_rev 0x13) {
printf(SPD revision %02X not supported by this code\n,
spd_rev);
return 1;
diff --git a/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
b/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
index d9d0fa7..2d40a60 100644
--- a/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
+++ b/cpu/mpc8xxx/ddr/ddr2_dimm_params.c
@@ -9,6 +9,17 @@
#include common.h
#include asm/fsl_ddr_sdram.h
+/* These are all the types defined by the JEDEC DDR2 SPD 1.3 spec */
+#define SPD_DIMM_TYPE_UNDEFINED0x00
+#define SPD_DIMM_TYPE_RDIMM0x01
+#define SPD_DIMM_TYPE_UDIMM0x02
+#define SPD_DIMM_TYPE_SO_DIMM 0x04
+#define SPD_DIMM_TYPE_72B_SO_CDIMM 0x06
+#define SPD_DIMM_TYPE_72B_SO_RDIMM 0x07
+#define SPD_DIMM_TYPE_MICRO_DIMM 0x08
+#define SPD_DIMM_TYPE_MINI_RDIMM 0x10
+#define SPD_DIMM_TYPE_MINI_UDIMM 0x20
+
#include ddr.h
/*
* Calculate the Density of each Physical Rank.
@@ -250,20 +261,23 @@ ddr_compute_dimm_parameters(const ddr2_spd_eeprom_t *spd,
pdimm-primary_sdram_width = spd-primw;
pdimm-ec_sdram_width = spd-ecw;
- /* FIXME: what about registered SO-DIMM? */
+ /* These are all the types defined by the JEDEC DDR2 SPD 1.3 spec */
switch (spd-dimm_type) {
- case 0x01: /* RDIMM */
- case 0x10: /* Mini-RDIMM */
- pdimm-registered_dimm = 1; /* register buffered */
+ case SPD_DIMM_TYPE_RDIMM:
+ case SPD_DIMM_TYPE_72B_SO_RDIMM:
+ case SPD_DIMM_TYPE_MINI_RDIMM:
+ /* Registered/buffered DIMMs */
+ pdimm-registered_dimm = 1;
break;
- case 0x02: /* UDIMM */
- case 0x04: /* SO-DIMM */
- case 0x08: /* Micro-DIMM */
- case 0x20: /* Mini-UDIMM */
+ case SPD_DIMM_TYPE_UDIMM:
+ case SPD_DIMM_TYPE_SO_DIMM:
+ case SPD_DIMM_TYPE_MICRO_DIMM:
+ case SPD_DIMM_TYPE_MINI_UDIMM:
pdimm-registered_dimm = 0; /* unbuffered */
break;
+ case SPD_DIMM_TYPE_72B_SO_CDIMM:
default:
printf(unknown dimm_type 0x%02X\n, spd-dimm_type);
return 1;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
On 30.08.2010 20:03, Albert ARIBAUD wrote: Le 30/08/2010 18:47, Detlev Zundel a écrit : Hi Reinhard, Detlev Zundel schrieb: Detlev, regarding the discussion I would only point out that we have to be sure that such kind of patch will be merged in the current release. It would be a real pity if a new official realease is published and then even a simple md command does not work on ARM. I don't see a problem here. All proposed patches (with/without attribute and union) surely fix a bug, so they will go into mainline when consent is reached on which one to use. This should well happen before the pending release on September 12th[1]. Am I misunderstanding anything here? No... but I would require that the union approach would be wanted, BEFORE I put effort into doing it. I'd very much appreciate your effort as I want the solution now that you did whet my appetite. Besides, re: 'fixing with the side-effect of a different thing': I think the alignment caused by using an union is not actually a side effect of it but an intended effect of it, as the compiler must ensure correct alignment of each union member -- on architectures where alignment of 32-bit ints is unnecessary, the union will not cause undue alignment, whereas the __aligned__ attribute would. Amicalement, I'll provide a patch tomorrow, right now I am not near a LinuX system ;) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] APM82xxx: Add UIC support
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sunday, August 29, 2010 1:57 AM To: tma...@apm.com Cc: u-boot@lists.denx.de; open-source-rev...@apm.com Subject: Re: [U-Boot] [PATCH 5/8] APM82xxx: Add UIC support Dear tma...@apm.com, In message 1282856765-24544-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com This patch adds Universal Interrupt Controller support for APM82XXX processor. Again. This is NOT a separate, independent commit. Please reread the documentation andfix your patch splitting. Mr Wolfgang, Sure will fix it. Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] APM82xxx: Add bluestone board support
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sunday, August 29, 2010 1:57 AM To: tma...@apm.com Cc: u-boot@lists.denx.de; open-source-rev...@apm.com Subject: Re: [U-Boot] [PATCH 7/8] APM82xxx: Add bluestone board support Dear tma...@apm.com, In message 1282856775-24619-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com Add support code for bluestone board wth APM82XXX processor based. This patch includes early board init, misc init, configure EBC, and initializes UIC. Signed-off-by: Tirumala R Marri tma...@apm.com --- arch/powerpc/include/asm/ppc4xx-ebc.h |4 + board/amcc/bluestone/Makefile | 52 board/amcc/bluestone/bluestone.c | 213 board/amcc/bluestone/config.mk| 40 ++ board/amcc/bluestone/init.S | 55 include/configs/bluestone.h | 218 + 6 files changed, 582 insertions(+), 0 deletions(-) Entry to boards.cfg, MAINTAINERS and MAKEALL missing. Best regards, Wolfgang Denk Mr Wolfgang, Sure will fix it. Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] APM82xxx: Add Common register definitions
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sunday, August 29, 2010 1:57 AM To: tma...@apm.com Cc: u-boot@lists.denx.de; open-source-rev...@apm.com Subject: Re: [U-Boot] [PATCH 2/8] APM82xxx: Add Common register definitions Dear tma...@apm.com, In message 1282856749-24425-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com This patch adds APM82XXX specific definitions, which include clock and boot strap. Signed-off-by: Tirumala R Marri tma...@apm.com --- include/ppc440.h | 57 - include/ppc4xx.h |7 +++-- 2 files changed, 59 insertions(+), 5 deletions(-) It makes no sense to split this into a spearate patch. Please squash into the commit where these defines are first referenced. Mr Wolfgang, Sure will fix it. Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] APM82xxx: Add DDR support
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sunday, August 29, 2010 1:57 AM To: tma...@apm.com Cc: u-boot@lists.denx.de; open-source-rev...@apm.com Subject: Re: [U-Boot] [PATCH 4/8] APM82xxx: Add DDR support Dear tma...@apm.com, In message 1282856759-24503-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com This patch adds 32bit DDR2 static as well as dynamic setting of different DRAM parameters like CAS and read/write delays. Signed-off-by: Tirumala R Marri tma...@apm.com --- arch/powerpc/include/asm/ppc4xx-sdram.h | 25 +++-- 1 files changed, 19 insertions(+), 6 deletions(-) This is not a separate, independent commit either. Mr Wolfgang, Sure I will fix it. Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] APM82xxx: Add top level common file changes
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Sunday, August 29, 2010 1:57 AM To: tma...@apm.com Cc: u-boot@lists.denx.de; open-source-rev...@apm.com Subject: Re: [U-Boot] [PATCH 8/8] APM82xxx: Add top level common file changes Dear tma...@apm.com, In message 1282856780-24660-1-git-send-email-tma...@apm.com you wrote: From: Tirumala Marri tma...@apm.com Add bluestone board name to the board.cfg. NAK. This must not ne a separate commit. Change Makefile to include bluestone board support. NAK. This is not needed and not allowed any more. Best regards, Wolfgang Denk Mr Wolfgang, Sure I will fix it. Regards, Marri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UnCorrectable RS-ECC Error occurs when reading NAND flash under u-boot 2009.08 for i.mx25
On Fri, 27 Aug 2010 20:35:12 -0700 dajiang.zh...@tektronix.com wrote: This is my first time of posting a message here, firstly , thanks for any body who builds such a nice platform give help. In recent two weeks, I added a NAND flash driver support for Micron's MT29F2G08ABD (SLC;page size: x8 2048+64bytes; Block size: 64 pages; Device size: 2Gb) memory chip base on u-boot 2009.08 for i.mx25. Could you try it on current U-Boot? It should already have support for i.mx25's NAND controller in drivers/mtd/nand/mxc_nand.c. I make a simply testing process, what I do is, firstly, I only erase page 0 of block 0, You cannot erase only page 0. You have to erase a whole block at a time. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] Expand POST memory test to support arch-depended implementation.
On Sun, 29 Aug 2010 10:56:47 +0200 Wolfgang Denk w...@denx.de wrote: Dear York Sun, In message 1282944356-4020-2-git-send-email-york...@freescale.com you wrote: Add progress indicator for slow test. It is useful when the testing takes too longer to finish. The indicator is reused from flash programming. Hwconfig is used to turn on slow test when not enabled by flag. NAK. POST is supposed to be an automatic, unmonitored functionality. Results are suposed to be reported through a mechanism compatible to Linux' syslog system. There is no place for progress indicators here. Why did you insist that he use the POST subsystem if you don't consider it appropriate for what he's doing? Or is it your opinion that it's absolutely useless to have a progress indicator on a memory test[1], or that such things have no place anywhere in U-Boot? -Scott [1] I don't care how automatic it is, if something is taking more than a few seconds during boot, I'm going to be monitoring it as I sit there twiddling my thumbs -- and if it takes that long, I'd rather it not be automatic at all. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] mtdparts: add new sub-command spread
On Fri, 27 Aug 2010 23:59:13 -0400 Ben Gardiner bengardi...@nanometrics.ca wrote: On Fri, Aug 27, 2010 at 5:59 PM, Scott Wood scottw...@freescale.com wrote: On 08/27/2010 04:46 PM, Scott Wood wrote: For now, I guess don't worry about sharing the code. Plus, I've got some changes to the NAND command/util code I'm about to send out that touch this -- if sharing is going to be a pain, I can go back to the version that only passes back fits with bad blocks, fits with no bad blocks, or doesn't fit, and doesn't deal with 64-bit sizes because it's only used by read/write which is limited by pointer size. That simpler version is 128 bytes smaller in my build. I imagine you don't have to go back. I already did; it's smaller and slightly simpler for what it currently needs to do. It would still be easy to switch to using the MTD function later. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/5] mtdparts: show net size in mtdparts list
On Mon, 30 Aug 2010 13:38:58 -0400
Ben Gardiner bengardi...@nanometrics.ca wrote:
+#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES)
/**
- * Format and print out a partition list for each device from global device
- * list.
+ * Get the net size (w/o bad blocks) of the given partition.
+ *
+ * @param mtd the mtd info
+ * @param part the partition
+ * @return the calculated net size of this partition
*/
-static void list_partitions(void)
+static uint64_t net_part_size(struct mtd_info *mtd, struct part_info *part)
+{
+ uint64_t gross_size, trailing_bad_size = 0;
+ int truncated = 0;
+
+ mtd_get_len_incl_bad(mtd, part-offset, part-size, gross_size,
+ truncated);
+
+ if (!truncated) {
+ mtd_get_len_incl_bad(mtd, part-offset + part-size,
+ mtd-erasesize, trailing_bad_size,
+ truncated);
+ trailing_bad_size -= mtd-erasesize;
+ }
+
+ return part-size - (gross_size - trailing_bad_size - part-size);
I'm not sure I follow the logic here...
You're trying to find net size given gross size, but you first treat
the gross size as a net size and get the gross size of *that*.
If it was truncated, then you'll return a value that
is still probably greater than the partition's true net size. For
example, suppose you called this on the final partition, which includes
at least one bad block (or the BBT, which is marked bad).
mtd_get_len_incl_bad() will return the full partition size and set
truncated. You'll end up with part-size - (part-size - 0 -
part-size), which evaluates to part-size. The function should have
returned something less than part-size.
If it was not truncated, suppose the partition had two bad blocks, and
the next partition had its second block bad. mtd_get_len_incl_bad()
will return part-size plus 3, since it ran into the next partition's
bad block. The second call to mtd_get_len_incl_bad() will return one
block, since it never got to the next partition's second block. Thus
net_part_size() will return part-size - ((part-size + 3) - 0 -
part-size), or part-size - 3. The right answer was part-size - 2.
I don't think a net-to-gross transformation is useful as a base for a
gross-to-net transformation.
+}
+#endif
+
+static void print_partition_table(void)
{
struct list_head *dentry, *pentry;
struct part_info *part;
struct mtd_device *dev;
int part_num;
- debug(\n---list_partitions---\n);
- list_for_each(dentry, devices) {
+list_for_each(dentry, devices) {
Wrong indentation.
dev = list_entry(dentry, struct mtd_device, link);
+ /* list partitions for given device */
+ part_num = 0;
+#if defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES)
+ struct mtd_info *mtd;
+
+ if (get_mtd_info(dev-id-type, dev-id-num, mtd))
+ return;
+
+ printf(\ndevice %s%d %s, # parts = %d\n,
+ MTD_DEV_TYPE(dev-id-type), dev-id-num,
+ dev-id-mtd_id, dev-num_parts);
+ printf( #: name\t\tsize\t\tnet size\toffset\t\tmask_flags\n);
+
+ list_for_each(pentry, dev-parts) {
+ u32 net_size;
+ char *size_note;
+
+ part = list_entry(pentry, struct part_info, link);
+ net_size = net_part_size(mtd, part);
+ size_note = part-size == net_size ? : (!);
+ printf(%2d: %-20s0x%08x\t0x%08x%s\t0x%08x\t%d\n,
+ part_num, part-name, part-size,
+ net_size, size_note, part-offset,
+ part-mask_flags);
+#else /* !defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
printf(\ndevice %s%d %s, # parts = %d\n,
MTD_DEV_TYPE(dev-id-type), dev-id-num,
dev-id-mtd_id, dev-num_parts);
printf( #: name\t\tsize\t\toffset\t\tmask_flags\n);
- /* list partitions for given device */
- part_num = 0;
list_for_each(pentry, dev-parts) {
part = list_entry(pentry, struct part_info, link);
printf(%2d: %-20s0x%08x\t0x%08x\t%d\n,
part_num, part-name, part-size,
part-offset, part-mask_flags);
-
+#endif /* defined(CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES) */
I'll let Wolfgang speak up if this really is how he wants it done, but
this seems like too much duplication to me. And what if someone else
wants to add another optional field, do we end up with 4 versions?
Then 8 versions the next time?
Is this really worth ifdeffing at all?
diff --git a/drivers/mtd/mtdcore.c
Re: [U-Boot] [PATCH v5 2/5] mtd: add an mtd method for get_len_incl_bad()
On Mon, 30 Aug 2010 13:38:57 -0400
Ben Gardiner bengardi...@nanometrics.ca wrote:
The logic to 'spread' mtd partitions needs to calculate the length in
the mtd device, including bad blocks.
This patch introduces a new function, mtd_get_len_incl_bad that can
return both the length including bad blocks and whether that length
was truncated on the device. This new function will be used by the
mtdparts spread command later in this series. The definition of the
function is #ifdef'd out in configurations that do not use the new
'mtdparts spread' command.
Signed-off-by: Ben Gardinerbengardi...@nanometrics.ca
CC: Scott Wood scottw...@freescale.com
---
Note: the mtd_get_len_incl_bad() function could also be used by the
get_len_incl_bad() function in nand_util.c except for the fact that
boards can enable NAND support without enabling MTD support. A note
has been added to get_len_incl_bad() to remind us to refactor when/if
MTD support is available whenever NAND support is enabled.
V5:
* introduced in v5 of this patchset
---
drivers/mtd/mtdcore.c| 44
++
drivers/mtd/nand/nand_util.c |6 +
include/linux/mtd/mtd.h |4 ++-
3 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 6eb52ed..cb86657 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -142,3 +142,47 @@ void put_mtd_device(struct mtd_info *mtd)
c = --mtd-usecount;
BUG_ON(c 0);
}
+
+#if defined(CONFIG_CMD_MTDPARTS_SPREAD)
+/**
+ * mtd_get_len_incl_bad
+ *
+ * Check if length including bad blocks fits into device.
+ *
+ * @param mtd an MTD device
+ * @param offset offset in flash
+ * @param length image length
+ * @return image length including bad blocks in *len_incl_bad and whether or
not
+ * the length returned was truncated in *truncated
+ */
+void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t offset,
+ const uint64_t length, uint64_t *len_incl_bad,
+ int *truncated)
+{
+ *truncated = 0;
+ *len_incl_bad = 0;
+
+ if (!mtd-block_isbad) {
+ *len_incl_bad = length;
+ return;
+ }
+
+ uint64_t len_excl_bad = 0;
+ uint64_t block_len;
+
+ while (len_excl_bad length) {
+ block_len = mtd-erasesize - (offset (mtd-erasesize - 1));
+
+ if (!mtd-block_isbad(mtd, offset ~(mtd-erasesize - 1)))
+ len_excl_bad += block_len;
+
+ *len_incl_bad += block_len;
+ offset += block_len;
+
+ if (offset = mtd-size) {
+ *truncated = 1;
+ break;
+ }
+ }
If this function is called with offset == mtd-size, you should return
length zero and truncated, without calling block_isbad().
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] mtdparts: add new sub-command spread
On Mon, 30 Aug 2010 13:38:59 -0400
Ben Gardiner bengardi...@nanometrics.ca wrote:
+static void spread_partition(struct mtd_info *mtd, struct part_info *part,
+ uint64_t *next_offset)
+{
+ uint64_t net_size, padding_size = 0;
+ int truncated;
+
+ mtd_get_len_incl_bad(mtd, part-offset, part-size, net_size,
+ truncated);
+
+ /*
+ * Absorb bad blocks immediately following this
+ * partition also into the partition, such that
+ * the next partition starts with a good block.
+ */
Why is the first block of a partition special?
+ if (!truncated) {
+ mtd_get_len_incl_bad(mtd, part-offset + net_size,
+ mtd-erasesize, padding_size, truncated);
+ padding_size -= mtd-erasesize;
What if this is the last partition? You're relying on an
implementation quick (bug?) that mtd_get_len_incl_bad() will let you
exceed the device size by a block if you start there. If it returned
the more expected zero in such a case, you'll end up subtracting a
block from net_size.
+ }
+
+ if (truncated) {
} else {
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/5] mtdparts: add new sub-command spread
On Mon, 30 Aug 2010 16:01:05 -0500
Scott Wood scottw...@freescale.com wrote:
On Mon, 30 Aug 2010 13:38:59 -0400
Ben Gardiner bengardi...@nanometrics.ca wrote:
+ if (!truncated) {
+ mtd_get_len_incl_bad(mtd, part-offset + net_size,
+mtd-erasesize, padding_size, truncated);
+ padding_size -= mtd-erasesize;
What if this is the last partition? You're relying on an
implementation quick (bug?)
Grr, s/quick/quirk/
-Scot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UEC/NET patch status?
On 8/30/2010 2:22 PM, Joakim Tjernlund wrote: some time ago I submitted: [PATCH 1/2] UEC: Don't udelay needlessly [PATCH 2/2] UEC PHY: Remove strange 0.5 sec delay [PATCHv2] net: Fix faulty definition of uec_initialize() [PATCH] UEC PHY: Speed up initial PHY neg. The two first got an Ack from Kim, but the other two has not. None of them have showed up the the u-boot repo. I have tried to get some feedback(read prodding) but no such luck. The NET part in u-boot is moving really slow and I suspect my patches are already forgotten? No, not forgotten, just in a queue. I'm acutely aware that this is moving slowly, and will pull yours and other peoples stuff in *soon*. Sorry, but other things that do have open merge windows have gotten priority lately. Jocke regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Hi Albert, Le 30/08/2010 18:47, Detlev Zundel a écrit : Hi Reinhard, Detlev Zundel schrieb: Detlev, regarding the discussion I would only point out that we have to be sure that such kind of patch will be merged in the current release. It would be a real pity if a new official realease is published and then even a simple md command does not work on ARM. I don't see a problem here. All proposed patches (with/without attribute and union) surely fix a bug, so they will go into mainline when consent is reached on which one to use. This should well happen before the pending release on September 12th[1]. Am I misunderstanding anything here? No... but I would require that the union approach would be wanted, BEFORE I put effort into doing it. I'd very much appreciate your effort as I want the solution now that you did whet my appetite. Besides, re: 'fixing with the side-effect of a different thing': I think the alignment caused by using an union is not actually a side effect of it but an intended effect of it, as the compiler must ensure correct alignment of each union member -- on architectures where alignment of 32-bit ints is unnecessary, the union will not cause undue alignment, whereas the __aligned__ attribute would. Absolutely and that's why I like the solution. It clearly states the intentions of the code. The 'side effect of another thing' that I was talking about was the proposed local change of using an uint32_t array for something which originally was an uint8_t array in order to gain the alignment. Cheers Detlev -- Greenspun's Tenth Rule of Programming: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common 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] [PATCH] display_buffer: fix misaligned buffer
Hi Reinhard, I'll provide a patch tomorrow, Thanks! right now I am not near a LinuX system ;) Well at least you have the comfort a somewhat sensible mail user agent there ;) Cheers Detlev -- ... what [Microsoft] Exchange provides is *like* email, but it is *not* email. Once you start trying to use it for real email, you find it's broken by design in a large number of ways. It makes no sense for [a company] to require that you use Exchange for Internet email, because that's not what Exchange does. -- David Woodhouse 1281348164.12908.47.ca...@localhost -- 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] [PATCH] video: cfb_console: fix definition and usage of CURSOR_xxx macros
On Fri, 27 Aug 2010 15:45:47 -0500 Timur Tabi ti...@freescale.com wrote: The CURSOR_ON, CURSOR_OFF, and CURSOR_SET macros are defined incorrectly. If cursor support is disabled, then these macros are defined to nothing, but then they are used like this: if (console_col CONSOLE_COLS) CURSOR_OFF console_row++; which was compiled like this: if (console_col CONSOLE_COLS) console_row++; This is obviously not what was intended. Signed-off-by: Timur Tabi ti...@freescale.com --- This patch depends on video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB drivers/video/cfb_console.c | 24 ++-- 1 files changed, 14 insertions(+), 10 deletions(-) Applied to u-boot-video/master. Thanks! Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] nand util: read/write: accept unaligned length
The underlying code in nand_base.c already supports non-page-aligned reads
and writes, but the block-skipping wrapper code did not.
With block skipping, an unaligned start address is not useful since you
really want to be starting at the beginning of a partition -- or at least
that's where you want to start checking for blocks to skip, but we don't
(yet) support that. So we still require the start address to be aligned.
An unaligned length, though, is useful for passing $filesize to the
read/write command, and handling it does not complicate block skipping.
Signed-off-by: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/nand_base.c |7 ---
drivers/mtd/nand/nand_util.c | 93 -
2 files changed, 63 insertions(+), 37 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ed1c9c9..48ba892 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2001,13 +2001,6 @@ static int nand_do_write_ops(struct mtd_info *mtd,
loff_t to,
if (!writelen)
return 0;
- /* reject writes, which are not page aligned */
- if (NOTALIGNED(to) || NOTALIGNED(ops-len)) {
- printk(KERN_NOTICE nand_write:
- Attempt to write not page aligned data\n);
- return -EINVAL;
- }
-
column = to (mtd-writesize - 1);
subpage = column || (writelen (mtd-writesize - 1));
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 29c42f7..0f67790 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -28,6 +28,12 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*
+ * Copyright 2010 Freescale Semiconductor
+ * The portions of this file whose copyright is held by Freescale and which
+ * are not considered a derived work of GPL v2-only code may be distributed
+ * and/or modified under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
*/
#include common.h
@@ -423,36 +429,43 @@ int nand_unlock(struct mtd_info *mtd, ulong start, ulong
length)
#endif
/**
- * get_len_incl_bad
+ * check_skip_len
*
- * Check if length including bad blocks fits into device.
+ * Check if there are any bad blocks, and whether length including bad
+ * blocks fits into device
*
* @param nand NAND device
* @param offset offset in flash
* @param length image length
- * @return image length including bad blocks
+ * @return 0 if the image fits and there are no bad blocks
+ * 1 if the image fits, but there are bad blocks
+ *-1 if the image does not fit
*/
-static size_t get_len_incl_bad (nand_info_t *nand, loff_t offset,
- const size_t length)
+static int check_skip_len(nand_info_t *nand, loff_t offset, size_t length)
{
- size_t len_incl_bad = 0;
size_t len_excl_bad = 0;
- size_t block_len;
+ int ret = 0;
while (len_excl_bad length) {
- block_len = nand-erasesize - (offset (nand-erasesize - 1));
+ size_t block_len, block_off;
+ loff_t block_start;
- if (!nand_block_isbad (nand, offset ~(nand-erasesize - 1)))
- len_excl_bad += block_len;
+ if (offset = nand-size)
+ return -1;
- len_incl_bad += block_len;
- offset += block_len;
+ block_start = offset ~(loff_t)(nand-erasesize - 1);
+ block_off = offset (nand-erasesize - 1);
+ block_len = nand-erasesize - block_off;
- if (offset = nand-size)
- break;
+ if (!nand_block_isbad(nand, block_start))
+ len_excl_bad += block_len;
+ else
+ ret = 1;
+
+ offset += block_len;
}
- return len_incl_bad;
+ return ret;
}
/**
@@ -474,29 +487,41 @@ int nand_write_skip_bad(nand_info_t *nand, loff_t offset,
size_t *length,
{
int rval;
size_t left_to_write = *length;
- size_t len_incl_bad;
u_char *p_buffer = buffer;
+ int need_skip;
- /* Reject writes, which are not page aligned */
- if ((offset (nand-writesize - 1)) != 0 ||
- (*length (nand-writesize - 1)) != 0) {
+ /*
+* nand_write() handles unaligned, partial page writes.
+*
+* We allow length to be unaligned, for convenience in
+* using the $filesize variable.
+*
+* However, starting at an unaligned offset makes the
+* semantics of bad block skipping ambiguous (really,
+* you should only start a block skipping access at a
+* partition boundary). So don't try to handle that.
+*/
+ if
[U-Boot] [PATCH 2/5] cmd_nand: some infrastructure fixes and refactoring
- If the current device is overridden by a named partition,
- update the caller's pointer/index, rather than copy over the
nand_info struct, and
- be sure to call board_nand_select_device even when the device
is overridden by a named partition.
- Support 64-bit offsets/sizes in a few more places.
- Refactor arg_off_size for added readability and flexibility,
and some added checks such as partition size.
- Remove redundant check for bad subcommands -- if there's no match
it'll print usage when it gets to the end anyway.
Signed-off-by: Scott Wood scottw...@freescale.com
---
common/cmd_nand.c | 274 -
1 files changed, 167 insertions(+), 107 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 3f1d077..41aaf7f 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -10,6 +10,13 @@
* (C) Copyright 2006-2007 OpenMoko, Inc.
* Added 16-bit nand support
* (C) 2004 Texas Instruments
+ *
+ * Copyright 2010 Freescale Semiconductor
+ * The portions of this file whose copyright is held by Freescale and which
+ * are not considered a derived work of GPL v2-only code may be distributed
+ * and/or modified under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
*/
#include common.h
@@ -85,74 +92,132 @@ static int nand_dump(nand_info_t *nand, ulong off, int
only_oob)
/* - */
-static inline int str2long(char *p, ulong *num)
+static int set_dev(int dev)
+{
+ if (dev 0 || dev = CONFIG_SYS_MAX_NAND_DEVICE ||
+ !nand_info[dev].name) {
+ puts(No such device\n);
+ return -1;
+ }
+
+ if (nand_curr_device == dev)
+ return 0;
+
+ printf(Device %d: %s, dev, nand_info[dev].name);
+ puts(... is now current device\n);
+ nand_curr_device = dev;
+
+#ifdef CONFIG_SYS_NAND_SELECT_DEVICE
+ board_nand_select_device(nand_info[dev].priv, dev);
+#endif
+
+ return 0;
+}
+
+static inline int str2off(const char *p, loff_t *num)
+{
+ char *endptr;
+
+ *num = simple_strtoull(p, endptr, 16);
+ return *p != '\0' *endptr == '\0';
+}
+
+static inline int str2long(const char *p, ulong *num)
{
char *endptr;
*num = simple_strtoul(p, endptr, 16);
- return (*p != '\0' *endptr == '\0') ? 1 : 0;
+ return *p != '\0' *endptr == '\0';
}
-static int
-arg_off_size(int argc, char * const argv[], nand_info_t *nand, ulong *off,
size_t *size)
+static int get_part(const char *partname, int *idx, loff_t *off, loff_t *size)
{
- int idx = nand_curr_device;
-#if defined(CONFIG_CMD_MTDPARTS)
+#ifdef CONFIG_CMD_MTDPARTS
struct mtd_device *dev;
struct part_info *part;
u8 pnum;
+ int ret;
- if (argc = 1 !(str2long(argv[0], off))) {
- if ((mtdparts_init() == 0)
- (find_dev_and_part(argv[0], dev, pnum, part) == 0)) {
- if (dev-id-type != MTD_DEV_TYPE_NAND) {
- puts(not a NAND device\n);
- return -1;
- }
- *off = part-offset;
- if (argc = 2) {
- if (!(str2long(argv[1], (ulong *)size))) {
- printf('%s' is not a number\n,
argv[1]);
- return -1;
- }
- if (*size part-size)
- *size = part-size;
- } else {
- *size = part-size;
- }
- idx = dev-id-num;
- *nand = nand_info[idx];
- goto out;
- }
+ ret = mtdparts_init();
+ if (ret)
+ return ret;
+
+ ret = find_dev_and_part(partname, dev, pnum, part);
+ if (ret)
+ return ret;
+
+ if (dev-id-type != MTD_DEV_TYPE_NAND) {
+ puts(not a NAND device\n);
+ return -1;
}
+
+ *off = part-offset;
+ *size = part-size;
+ *idx = dev-id-num;
+
+ ret = set_dev(*idx);
+ if (ret)
+ return ret;
+
+ return 0;
+#else
+ puts(offset is not a number\n);
+ return -1;
#endif
+}
- if (argc = 1) {
- if (!(str2long(argv[0], off))) {
- printf('%s' is not a number\n, argv[0]);
- return -1;
- }
- } else {
+static int arg_off(const char *arg, int *idx, loff_t *off, loff_t *maxsize)
+{
+ if (!str2off(arg, off))
+ return get_part(arg, idx, off, maxsize);
+
+ if (*off = nand_info[*idx].size)
[U-Boot] [PATCH 4/5] nand commands: make only dump repeatable.
The dump command is made to increment its address on repeat,
as md does. Other commands do not make sense to issue repeatedly,
and can be irritating when it happens accidentally, so don't.
Signed-off-by: Scott Wood scottw...@freescale.com
---
common/cmd_nand.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index d19..8a81237 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -37,10 +37,16 @@ int find_dev_and_part(const char *id, struct mtd_device
**dev,
u8 *part_num, struct part_info **part);
#endif
-static int nand_dump(nand_info_t *nand, ulong off, int only_oob)
+static int nand_dump(nand_info_t *nand, ulong off, int only_oob, int repeat)
{
int i;
u_char *datbuf, *oobbuf, *p;
+ static loff_t last;
+
+ if (repeat)
+ off = last + nand-writesize;
+
+ last = off;
datbuf = malloc(nand-writesize + nand-oobsize);
oobbuf = malloc(nand-oobsize);
@@ -381,6 +387,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
#endif
const char *quiet_str = getenv(quiet);
int dev = nand_curr_device;
+ int repeat = flag CMD_FLAG_REPEAT;
/* at least two arguments please */
if (argc 2)
@@ -391,6 +398,10 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
cmd = argv[1];
+ /* Only dump is repeatable. */
+ if (repeat strcmp(cmd, dump))
+ return 0;
+
if (strcmp(cmd, info) == 0) {
putc('\n');
@@ -532,16 +543,10 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
if (argc 3)
goto usage;
- s = strchr(cmd, '.');
off = (int)simple_strtoul(argv[2], NULL, 16);
-
- if (s != NULL strcmp(s, .oob) == 0)
- ret = nand_dump(nand, off, 1);
- else
- ret = nand_dump(nand, off, 0);
+ ret = nand_dump(nand, off, !strcmp(cmd[4], .oob), repeat);
return ret == 0 ? 1 : 0;
-
}
if (strncmp(cmd, read, 4) == 0 || strncmp(cmd, write, 5) == 0) {
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] nand erase: .spread, .part, .chip subcommands
A while back, in http://lists.denx.de/pipermail/u-boot/2009-June/054428.html,
Michele De Candia posted a patch to not count bad blocks toward the
requested size to be erased. This is desireable when you're passing in
something like $filesize, but not when you're trying to erase a partition.
Thus, a .spread subcommand (named for consistency with
http://lists.denx.de/pipermail/u-boot/2010-August/075163.html) is introduced
to make explicit the user's desire to erase for a given amount of data,
rather than to erase a specific region of the chip.
While passing $filesize to nand erase is useful, accidentally passing
something like $fliesize currently produces quite unpleasant results, as the
variable evaluates to nothing and U-Boot assumes that you want to erase
the entire rest of the chip/partition. To improve the safety of the
erase command, require the user to make explicit their intentions by
using a .part or .chip subcommand. This is an incompatible user interface
change, but keeping compatibility would eliminate the safety gain, and IMHO
it's worth it.
While touching nand_erase_opts(), make it accept 64-bit offsets and sizes,
fix the percentage display when erase length is rounded up, eliminate
an inconsistent warning about rounding up the erase length which only
happened when the length was less than one block (rounding up for $filesize
is normal operation), and add a diagnostic if there's an attempt to erase
beginning at a non-block boundary.
Signed-off-by: Scott Wood scottw...@freescale.com
---
common/cmd_nand.c| 44 -
drivers/mtd/nand/nand_util.c | 31 -
include/nand.h |7 -
3 files changed, 60 insertions(+), 22 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 41aaf7f..d19 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -449,14 +449,40 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
* 01 2 34
* nand erase [clean] [off size]
*/
- if (strcmp(cmd, erase) == 0 || strcmp(cmd, scrub) == 0) {
+ if (strncmp(cmd, erase, 5) == 0 || strncmp(cmd, scrub, 5) == 0) {
nand_erase_options_t opts;
/* clean at index 2 means request to write cleanmarker */
int clean = argc 2 !strcmp(clean, argv[2]);
int o = clean ? 3 : 2;
- int scrub = !strcmp(cmd, scrub);
+ int scrub = !strncmp(cmd, scrub, 5);
+ int part = 0;
+ int chip = 0;
+ int spread = 0;
+ int args = 2;
+
+ if (cmd[5] != 0) {
+ if (!strcmp(cmd[5], .spread)) {
+ spread = 1;
+ } else if (!strcmp(cmd[5], .part)) {
+ part = 1;
+ args = 1;
+ } else if (!strcmp(cmd[5], .chip)) {
+ chip = 1;
+ args = 0;
+ } else {
+ goto usage;
+ }
+ }
+
+ /*
+* Don't allow missing arguments to cause full chip/partition
+* erases -- easy to do accidentally, e.g. with a misspelled
+* variable name.
+*/
+ if (argc != o + args)
+ goto usage;
- printf(\nNAND %s: , scrub ? scrub : erase);
+ printf(\nNAND %s: , cmd);
/* skip first two or three arguments, look for offset and size
*/
if (arg_off_size(argc - o, argv + o, dev, off, size) != 0)
return 1;
@@ -468,6 +494,7 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
opts.length = size;
opts.jffs2 = clean;
opts.quiet = quiet;
+ opts.spread = spread;
if (scrub) {
puts(Warning:
@@ -648,11 +675,16 @@ U_BOOT_CMD(
nand write - addr off|partition size\n
read/write 'size' bytes starting at offset 'off'\n
to/from memory address 'addr', skipping bad blocks.\n
- nand erase [clean] [off size] - erase 'size' bytes from\n
- offset 'off' (entire device if not specified)\n
+ nand erase[.spread] [clean] [off [size]] - erase 'size' bytes
+ from offset 'off'\n
+ With '.spread', erase enough for given file size, otherwise,\n
+ 'size' includes skipped bad blocks.\n
+ nand erase.part [clean] partition - erase entire mtd partition'\n
+ nand erase.chip [clean] - erase entire chip'\n
nand bad - show bad blocks\n
nand dump[.oob] off - dump page\n
- nand scrub - really clean NAND erasing bad blocks (UNSAFE)\n
+ nand scrub off size |
[U-Boot] [PATCH 5/5] nand: remove dead code and suspend/resume
Get rid of the several #if 0 sections that were keeping around Linux
code that isn't relevant to U-Boot. Besides cluttering the code, these
sections make tracking upstream changes harder, rather than easier.
It's easy to discard obviously irrelevant diff hunks that patch rejects,
but it's not as easy to notice hunks that apply cleanly to the #if 0
section, but *are* relevant to U-Boot and require modification elsewhere.
Also remove suspend/resume, as this is not applicable to U-Boot. Removal
saves 232 bytes on powerpc.
Signed-off-by: Scott Wood scottw...@freescale.com
---
drivers/mtd/mtdpart.c| 16 ---
drivers/mtd/nand/nand_base.c | 238 +-
drivers/mtd/nand/nand_bbt.c | 19
drivers/mtd/nand/nand_ecc.c | 17 ---
drivers/mtd/nand/nand_util.c | 35 --
include/linux/mtd/mtd.h |4 -
6 files changed, 1 insertions(+), 328 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index e2e43ea..f647e43 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -230,18 +230,6 @@ static void part_sync(struct mtd_info *mtd)
part-master-sync(part-master);
}
-static int part_suspend(struct mtd_info *mtd)
-{
- struct mtd_part *part = PART(mtd);
- return part-master-suspend(part-master);
-}
-
-static void part_resume(struct mtd_info *mtd)
-{
- struct mtd_part *part = PART(mtd);
- part-master-resume(part-master);
-}
-
static int part_block_isbad(struct mtd_info *mtd, loff_t ofs)
{
struct mtd_part *part = PART(mtd);
@@ -339,10 +327,6 @@ static struct mtd_part *add_one_partition(struct mtd_info
*master,
slave-mtd.get_fact_prot_info = part_get_fact_prot_info;
if (master-sync)
slave-mtd.sync = part_sync;
- if (!partno master-suspend master-resume) {
- slave-mtd.suspend = part_suspend;
- slave-mtd.resume = part_resume;
- }
if (master-lock)
slave-mtd.lock = part_lock;
if (master-unlock)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 48ba892..d6a570d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -32,30 +32,6 @@
*
*/
-/* XXX U-BOOT XXX */
-#if 0
-#include linux/module.h
-#include linux/delay.h
-#include linux/errno.h
-#include linux/err.h
-#include linux/sched.h
-#include linux/slab.h
-#include linux/types.h
-#include linux/mtd/mtd.h
-#include linux/mtd/nand.h
-#include linux/mtd/nand_ecc.h
-#include linux/mtd/compatmac.h
-#include linux/interrupt.h
-#include linux/bitops.h
-#include linux/leds.h
-#include asm/io.h
-
-#ifdef CONFIG_MTD_PARTITIONS
-#include linux/mtd/partitions.h
-#endif
-
-#endif
-
#include common.h
#define ENOTSUPP 524 /* Operation is not supported */
@@ -75,10 +51,6 @@
#include asm/io.h
#include asm/errno.h
-#ifdef CONFIG_JFFS2_NAND
-#include jffs2/jffs2.h
-#endif
-
/*
* CONFIG_SYS_NAND_RESET_CNT is used as a timeout mechanism when resetting
* a flash. NAND flash is initialized prior to interrupts so standard timers
@@ -143,44 +115,17 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t
to,
static int nand_wait(struct mtd_info *mtd, struct nand_chip *this);
-/*
- * For devices which display every fart in the system on a separate LED. Is
- * compiled away when LED support is disabled.
- */
-/* XXX U-BOOT XXX */
-#if 0
-DEFINE_LED_TRIGGER(nand_led_trigger);
-#endif
-
/**
* nand_release_device - [GENERIC] release chip
* @mtd: MTD device structure
*
* Deselect, release chip lock and wake up anyone waiting on the device
*/
-/* XXX U-BOOT XXX */
-#if 0
-static void nand_release_device(struct mtd_info *mtd)
-{
- struct nand_chip *chip = mtd-priv;
-
- /* De-select the NAND device */
- chip-select_chip(mtd, -1);
-
- /* Release the controller and the chip */
- spin_lock(chip-controller-lock);
- chip-controller-active = NULL;
- chip-state = FL_READY;
- wake_up(chip-controller-wq);
- spin_unlock(chip-controller-lock);
-}
-#else
static void nand_release_device (struct mtd_info *mtd)
{
struct nand_chip *this = mtd-priv;
this-select_chip(mtd, -1); /* De-select the NAND device */
}
-#endif
/**
* nand_read_byte - [DEFAULT] read one byte from the chip
@@ -490,24 +435,6 @@ static int nand_block_checkbad(struct mtd_info *mtd,
loff_t ofs, int getchip,
* Wait for the ready pin, after a command
* The timeout is catched later.
*/
-/* XXX U-BOOT XXX */
-#if 0
-void nand_wait_ready(struct mtd_info *mtd)
-{
- struct nand_chip *chip = mtd-priv;
- unsigned long timeo = jiffies + 2;
-
- led_trigger_event(nand_led_trigger, LED_FULL);
- /* wait until command is processed or timeout occures */
- do {
- if (chip-dev_ready(mtd))
- break;
- touch_softlockup_watchdog();
- }
[U-Boot] [PATCH] mpc831xerdb: enable mtdparts for NAND
The default partition table matches the .dts files for these boards in Linux. This allows these partitions to be used by name with U-Boot's nand command. Signed-off-by: Scott Wood scottw...@freescale.com --- include/configs/MPC8313ERDB.h |9 - include/configs/MPC8315ERDB.h |9 - 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index 524afa5..adf05ee 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -1,5 +1,5 @@ /* - * Copyright (C) Freescale Semiconductor, Inc. 2006. + * Copyright (C) Freescale Semiconductor, Inc. 2006, 2010. * * See file CREDITS for list of people who contributed to this * project. @@ -232,6 +232,13 @@ #define CONFIG_SYS_NAND_BASE 0xE280 #endif +#define CONFIG_MTD_DEVICE +#define CONFIG_MTD_PARTITION +#define CONFIG_CMD_MTDPARTS +#define MTDIDS_DEFAULT nand0=e280.flash +#define MTDPARTS_DEFAULT \ + mtdparts=e060.flash:512k(uboot),128k(env),3...@1m(kernel),-(fs) + #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_MTD_NAND_VERIFY_WRITE #define CONFIG_CMD_NAND 1 diff --git a/include/configs/MPC8315ERDB.h b/include/configs/MPC8315ERDB.h index f1b110b..321ae9d 100644 --- a/include/configs/MPC8315ERDB.h +++ b/include/configs/MPC8315ERDB.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. + * Copyright (C) 2007-2010 Freescale Semiconductor, Inc. * * Dave Liu dave...@freescale.com * @@ -243,6 +243,13 @@ #define CONFIG_SYS_NAND_BASE 0xE060 #endif +#define CONFIG_MTD_DEVICE +#define CONFIG_MTD_PARTITION +#define CONFIG_CMD_MTDPARTS +#define MTDIDS_DEFAULT nand0=e060.flash +#define MTDPARTS_DEFAULT \ + mtdparts=e060.flash:512k(uboot),128k(env),3...@1m(kernel),-(fs) + #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define CONFIG_MTD_NAND_VERIFY_WRITE 1 #define CONFIG_CMD_NAND1 -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [U-BOOT] Zoom2 Zoom3: introduced a macro to use a different buffer size when compiling for Zoom2 or Zoom3.
From: Aldo Brett Cedillo Martinez aldo.cedi...@ti.com
Zoom2 and Zoom2 used to hang with md command. It was due to a problem
with a buffer size in print_buffer() function. A macro was introduced
to use a different buffer size in case of compiling for Zoom2 and Zoom3.
Jeff could you please test it on your board with the Zoom3 initial support
patch.
Sandeep I also saw this behaving in Zoom2, so maybe I could send a patch
that introduces only Zoom2 change, which could be introduced in TI tree
without waiting for Zoom3 initial support for going mainline.
Signed-off-by: Aldo Brett Cedillo Martinez aldo.cedi...@ti.com
---
lib/display_options.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/display_options.c b/lib/display_options.c
index 20319e6..99e43f7 100644
--- a/lib/display_options.c
+++ b/lib/display_options.c
@@ -101,7 +101,12 @@ void print_size(unsigned long long size, const char *s)
#define DEFAULT_LINE_LENGTH_BYTES (16)
int print_buffer (ulong addr, void* data, uint width, uint count, uint linelen)
{
+#if defined(CONFIG_OMAP3_ZOOM2) || defined(CONFIG_OMAP3_ZOOM3)
+ uint8_t linebuf[DEFAULT_LINE_LENGTH_BYTES];
+#else
uint8_t linebuf[MAX_LINE_LENGTH_BYTES + 1];
+#endif /* CONFIG_OMAP3 */
+
uint32_t *uip = (void*)linebuf;
uint16_t *usp = (void*)linebuf;
uint8_t *ucp = (void*)linebuf;
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] fix little endian build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/30/2010 11:12 PM, Shinya Kuribayashi wrote: What about the endianness of generated u-boot ELF image then? $ CROSS_COMPILE=mips_4KCle- ./MAKEALL dbau1550_el_config $ file u-boot Hi Shinya here is the info: xian...@openmobilefree:~/u-boot/u-boot.git$ CROSS_COMPILE=~/u-boot/mips/usr/bin/mips_4KCle- ./MAKEALL dbau1550_el Configuring for dbau1x00 board... board.c: In function 'board_init_r': board.c:331: warning: assignment from incompatible pointer type textdata bss dec hex filename 1218634976 18924 145763 23963 ./u-boot - - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( dbau1550_el ) - -- xian...@openmobilefree:~/u-boot/u-boot.git$ file u-boot u-boot: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, not stripped And could you also provide the version info, please? $ mips_4KCle-gcc --version xian...@openmobilefree:~/u-boot/u-boot.git$ ~/u-boot/mips/usr/bin/mips_4KCle-gcc --version mips_4KCle-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx8VDUACgkQRRAEFRxkgLSj/QCeJNvYDAaGBdqjstJYFWr97GoY 3xoAn1rDYCJaBEsG3uDw8zfjORGqCm84 =92rb -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] fix little endian build
On 8/31/2010 10:00 AM, Xiangfu Liu wrote: xian...@openmobilefree:~/u-boot/u-boot.git$ file u-boot u-boot: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, not stripped Ah, it's LSB, got it. As said in the previous mail the patch is tentative and won't work with ELDK, and as fas as I could see nothing has been changed since my version. So I'm overlooking something, will have to think about it. -- Shinya Kuribayashi Renesas Electronics ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] fix little endian build
On 8/31/2010 10:00 AM, Xiangfu Liu wrote: xian...@openmobilefree:~/u-boot/u-boot.git$ file u-boot u-boot: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, not stripped My bad sorry. Could you provide output from readelf? $ readelf u-boot -- Shinya Kuribayashi Renesas Electronics ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] APM82xxx: Add bluestone board support
Hi Marri,
(please reply to the mailing list as well)
On Monday 30 August 2010 19:31:32 Tirumala Marri wrote:
+int board_early_init_r(void)
+{
+ u32 bootdevice;
+
+ /*
+ * Clear potential errors resulting from auto-calibration.
+ * If not done, then we could get an interrupt later on when
+ * exceptions are enabled.
+ */
+ set_mcsr(get_mcsr());
+
+ /* Reconfigure EBC here */
+ bootdevice = bootdevice_selected();
+ reconfigure_EBC(bootdevice);
Please explain why the EBC needs to be reconfigured at this stage.
[Marri]Once we are running out of ram, we are trying to change from what
Initial bootstraps set up the EBC banks. Let me review if it is
significantly
Changing anything. Otherwise I will get rid of the function.
Why don't you do it as usually done. Just define the EBC register settings in
your board header and they will get automatically written to the EBC registers
in arch/powerpc/cpu/ppc4xx/cpu.c, cpu_init_f():
Defines in bluestone.h like this:
/* Memory Bank 0 (NOR-flash) */
#define CONFIG_SYS_EBC_PB0AP(EBC_BXAP_BME_DISABLED | \
EBC_BXAP_TWT_ENCODE(16)| \
EBC_BXAP_BCE_DISABLE | \
EBC_BXAP_BCT_2TRANS| \
EBC_BXAP_CSN_ENCODE(1) | \
EBC_BXAP_OEN_ENCODE(1) | \
EBC_BXAP_WBN_ENCODE(1) | \
EBC_BXAP_WBF_ENCODE(1) | \
EBC_BXAP_TH_ENCODE(7) | \
EBC_BXAP_RE_DISABLED | \
EBC_BXAP_SOR_DELAYED | \
EBC_BXAP_BEM_WRITEONLY | \
EBC_BXAP_PEN_DISABLED)
#define CONFIG_SYS_EBC_PB0CR
(EBC_BXCR_BAS_ENCODE(CONFIG_SYS_BOOT_BASE_ADDR) | \
EBC_BXCR_BS_16MB | \
EBC_BXCR_BU_RW | \
EBC_BXCR_BW_16BIT)
snip
+#define CONFIG_SDRAM_INFO_EEPROM_ADDR0x54/* Board specific
*/
+#define CONFIG_SDRAM16BIT_OFFSET 0x20/* Board specific */
Those two defines are not used in your patches. Please remove.
[Marri] The variable CONFIG_SDRAM_INFO_EEPROM_ADDR is used.
Where CONFIG_SDRAM16BIT_OFFSET is not used any where.
I can't find CONFIG_SDRAM_INFO_EEPROM_ADDR either. Where is it used?
snip
Please fix and resubmit. Thanks.
Cheers,
Stefan
I will do the fixes and send it again.
Thanks.
Cheers,
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 0/2] fix little endian build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/31/2010 09:29 AM, Shinya Kuribayashi wrote: On 8/31/2010 10:00 AM, Xiangfu Liu wrote: xian...@openmobilefree:~/u-boot/u-boot.git$ file u-boot u-boot: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, not stripped My bad sorry. Could you provide output from readelf? $ readelf u-boot xian...@openmobilefree:~/u-boot/u-boot.git$ readelf -h u-boot ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: MIPS R3000 Version: 0x1 Entry point address: 0xbfc0 Start of program headers: 52 (bytes into file) Start of section headers: 374000 (bytes into file) Flags: 0x50001007, noreorder, pic, cpic, o32, mips32 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 26 Section header string table index: 23 - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx8iNkACgkQRRAEFRxkgLS+8wCeKKPIJuwAVWb4QTF2wrsCfr27 T1IAniAZT18XFab/ZZ7nLDxshZplL+KD =rRQF -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] TI: netdev: add driver for cpsw ethernet device
Hi Cyril,
Sorry for taking so long to look at this.
On 8/3/2010 6:33 PM, Cyril Chemparathy wrote:
CPSW is an on-chip ethernet switch that is found on various SoCs from Texas
Instruments. This patch adds a simple driver (based on the Linux driver) for
this hardware module.
Signed-off-by: Cyril Chemparathycy...@ti.com
---
drivers/net/Makefile |1 +
drivers/net/cpsw.c | 861
++
include/netdev.h | 29 ++
3 files changed, 891 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/cpsw.c
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 218eeff..f4f1ed2 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -73,6 +73,7 @@ COBJS-$(CONFIG_SMC9) += smc9.o
COBJS-$(CONFIG_SMC911X) += smc911x.o
COBJS-$(CONFIG_TIGON3) += tigon3.o bcm570x_autoneg.o 5701rls.o
COBJS-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
+COBJS-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o
Please don't use the word DRIVER here. If possible, use something more
verbose than CPSW too.
COBJS-$(CONFIG_TSEC_ENET) += tsec.o
COBJS-$(CONFIG_TSI108_ETH) += tsi108_eth.o
COBJS-$(CONFIG_ULI526X) += uli526x.o
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
new file mode 100644
index 000..c84ec78
--- /dev/null
+++ b/drivers/net/cpsw.c
Please rename this ti_cpsw.c
@@ -0,0 +1,861 @@
+/*
+ * CPSW Ethernet Switch Driver
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#includecommon.h
+#includecommand.h
+#includenet.h
+#includemiiphy.h
+#includemalloc.h
+#includenet.h
+#includenetdev.h
+#includeasm/errno.h
+#includeasm/io.h
+
+#define BIT(x) (1 (x))
+#define BITMASK(bits)(BIT(bits) - 1)
+#define PHY_REG_MASK 0x1f
+#define PHY_ID_MASK 0x1f
+#define NUM_DESCS(PKTBUFSRX * 2)
+#define PKT_MIN 60
+#define PKT_MAX (1500 + 14 + 4 + 4)
+
+/* DMA Registers */
+#define CPDMA_TXCONTROL 0x004
+#define CPDMA_RXCONTROL 0x014
+#define CPDMA_SOFTRESET 0x01c
+#define CPDMA_RXFREE 0x0e0
+#define CPDMA_TXHDP 0x100
+#define CPDMA_RXHDP 0x120
+#define CPDMA_TXCP 0x140
+#define CPDMA_RXCP 0x160
+
+/* Descriptor mode bits */
+#define CPDMA_DESC_SOP BIT(31)
+#define CPDMA_DESC_EOP BIT(30)
+#define CPDMA_DESC_OWNER BIT(29)
+#define CPDMA_DESC_EOQ BIT(28)
+
+struct cpsw_mdio_regs {
+ u32 version;
+ u32 control;
+#define CONTROL_IDLE (1 31)
+#define CONTROL_ENABLE (1 30)
+
+ u32 alive;
+ u32 link;
+ u32 linkintraw;
+ u32 linkintmasked;
+ u32 __reserved_0[2];
+ u32 userintraw;
+ u32 userintmasked;
+ u32 userintmaskset;
+ u32 userintmaskclr;
+ u32 __reserved_1[20];
+
+ struct {
+ u32 access;
+ u32 physel;
+#define USERACCESS_GO(1 31)
+#define USERACCESS_WRITE (1 30)
+#define USERACCESS_ACK (1 29)
+#define USERACCESS_READ (0)
+#define USERACCESS_DATA (0x)
+ } user[0];
+};
+
+struct cpsw_regs {
+ u32 id_ver;
+ u32 control;
+ u32 soft_reset;
+ u32 stat_port_en;
+ u32 ptype;
+};
+
+struct cpsw_slave_regs {
+ u32 max_blks;
+ u32 blk_cnt;
+ u32 flow_thresh;
+ u32 port_vlan;
+ u32 tx_pri_map;
+ u32 gap_thresh;
+ u32 sa_lo;
+ u32 sa_hi;
+};
+
+struct cpsw_host_regs {
+ u32 max_blks;
+ u32 blk_cnt;
+ u32 flow_thresh;
+ u32 port_vlan;
+ u32 tx_pri_map;
+ u32 cpdma_tx_pri_map;
+ u32 cpdma_rx_chan_map;
+};
+
+struct cpsw_sliver_regs {
+ u32 id_ver;
+ u32 mac_control;
+ u32 mac_status;
+ u32 soft_reset;
+ u32 rx_maxlen;
+ u32 __reserved_0;
+ u32 rx_pause;
+ u32 tx_pause;
+ u32 __reserved_1;
+
Re: [U-Boot] [PATCH] display_buffer: fix misaligned buffer
Le 31/08/2010 00:29, Detlev Zundel a écrit : Hi Albert, Le 30/08/2010 18:47, Detlev Zundel a écrit : Hi Reinhard, Detlev Zundel schrieb: Detlev, regarding the discussion I would only point out that we have to be sure that such kind of patch will be merged in the current release. It would be a real pity if a new official realease is published and then even a simple md command does not work on ARM. I don't see a problem here. All proposed patches (with/without attribute and union) surely fix a bug, so they will go into mainline when consent is reached on which one to use. This should well happen before the pending release on September 12th[1]. Am I misunderstanding anything here? No... but I would require that the union approach would be wanted, BEFORE I put effort into doing it. I'd very much appreciate your effort as I want the solution now that you did whet my appetite. Besides, re: 'fixing with the side-effect of a different thing': I think the alignment caused by using an union is not actually a side effect of it but an intended effect of it, as the compiler must ensure correct alignment of each union member -- on architectures where alignment of 32-bit ints is unnecessary, the union will not cause undue alignment, whereas the __aligned__ attribute would. Absolutely and that's why I like the solution. It clearly states the intentions of the code. The 'side effect of another thing' that I was talking about was the proposed local change of using an uint32_t array for something which originally was an uint8_t array in order to gain the alignment. I apologize, then. I did not understand your post this way because I was considering the uint32_t in the union, which is 'legitimate' as it is used for 'md.l'. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
