Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Hi Aneesh,
On Thu, Jun 16, 2011 at 3:39 PM, Aneesh V ane...@ti.com wrote:
Hi Grame,
On Wednesday 15 June 2011 06:12 PM, Graeme Russ wrote:
On 15/06/11 22:04, Wolfgang Denk wrote:
Dear Aneesh V,
In message4df89102.9040...@ti.com you wrote:
Will you accept something like this?
a_val = (reg a_mask) a_shift;
Yes, of course (that's what seems most natural to me).
Me too - The code is obvious - the desired value is being masked out of a
larger composite value and then shifted right to bit 0
And to set the value then you have:
reg= ~a_mask; /* Clear a_val */
reg |= (a_val a_shift) a_mask; /* Set new a_val */
AND'ing with a_mask is required to prevent accidental clobbering when
a_val
is out-of-range. May give undesirable results by setting an illegal a_val,
but at least you don't clobber unrelated bit fields
These are exactly what my helper functions were doing. Are you
suggesting that doing these directly is better than doing them
using helper functions?
I (personally) think that the two lines of memberwise bit mask/shift is
more obvious in its intent that even clrsetbits. I understand there is
defensive programming issues that can be applied with macros or helper
functions, but then the you loose 'obviousness' and sometimes this can
make figuring out the problem even harder (one assumes the macro or
helper function works properly).
When push comes to shove, the compiler will probably produce identical
code anyway.
Sometimes I like seeing the raw elegance of what is going on under the
hood :)
Now, that being said, I see no reason not to do the following if I had,
for example, multiple serial port configuration registers which are all
identical:
/* num data bits is stored in bits 2-4 of the serial config register */
#define DATA_BITS_MASK 0x001c
#define DATA_BITS_OFFSET2
u32 set_serial_data_bits(u32 ser_cfg, u8 data_bits)
{
ser_cfg = ~DATA_BITS_MASK;
ser_cfg |= ((u32)ser_cfg DATA_BITS_OFFSET) DATA_BITS_MASK;
return ser_cfg;
}
void serial_init(void)
{
u32 ser_cfg;
for (i=0; iNUM_SERIAL_PORTS; i++) {
ser_cfg = read_serial_cfg(i);
ser_cfg = set_serial_data_bits(ser_cfg, 7);
write_serial_cfg(i, ser_cfg);
}
}
But that's just me - I tend to avoid #define macros
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Simon, On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ graeme.r...@gmail.com wrote: [snip] BTW should the deltas return a signed value? No - times are unsigned utilising the entire range of the u32 so (to - from) will always returned the unsigned delta, even if there is a wrap between them. I cannot imagine we would ever need to measure time backward anyway. Can you please explain this again in different words as I don't follow. The difference between two unsigned times may be +ve or -ve, surely. For example, say: now = 100 event_time = 200 then the delta is currently -100. Some people might loop until the delta is = 0. This is like setting a future time and waiting for it to happen. If the delta is unsigned then this won't work. start = 0xff00 now = 0x0010 So there was a timer wrap between 'start' and 'now' delta = now - start = 0x110 Remember that the new timer API does not rely on the tick counter (and therefore the ms/us timers) to start at zero - It must be allowed to wrap without causing timer glitches at any arbitray time Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL framework re-design
Dear Wolfgang, This is in continuation of our discussion in the following threads: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99795 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/99785 I think this discussion now needs a dedicated thread. To make sure I understand your new proposals, let me consolidate them here. Please correct me if I am wrong. Also, in the end I have some questions about your new proposal. Some of the questions are getting into the details. But I need the details to re-work my patches according to the new proposal. Current Design: * Currently a single board level Makefile determines what gets built into SPL. * This Makefile chooses all the files to be built. Makes symbolic links to them in the board level SPL directory and builds and links them to create the SPL image. * This structure is duplicated for different types of SPLs, nand_spl, onenand_ipl, mmc_spl etc. * Directory structure is something like: nand_spl/board/vendor/board/ New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' * nand_spl/Makefile builds a generic library with the generic source files at this level. * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image. Open questions about the new proposal: 1. We may need more layers than just generic, SoC and board. For instance all SPLs typically use start.S from the CPU directory. Also, a lot of SoC code is typically SoC family generic. How about something like this for the directory structure: nand_spl/cpu/ soc-family/ soc1/board/ soc2/board/ Maybe, arch needs to be added too. 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? 4. How do we handle the case where a given SoC doesn't need any board level code for the SPL(This is the case with OMAP4). Is this handled by just not have any board directories? 5. If so, how does the top-level SPL Makefile handle this? By checking for the existence of board directory before descending into it? How does it handle the link step where the board level library is not available? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Graeme Russ,
In message banlktik3cxemzu0qpxdlsqmtk-abeod...@mail.gmail.com you wrote:
Now, that being said, I see no reason not to do the following if I had,
for example, multiple serial port configuration registers which are all
identical:
/* num data bits is stored in bits 2-4 of the serial config register */
#define DATA_BITS_MASK0x001c
#define DATA_BITS_OFFSET 2
u32 set_serial_data_bits(u32 ser_cfg, u8 data_bits)
{
ser_cfg = ~DATA_BITS_MASK;
ser_cfg |= ((u32)ser_cfg DATA_BITS_OFFSET) DATA_BITS_MASK;
return ser_cfg;
}
void serial_init(void)
{
u32 ser_cfg;
for (i=0; iNUM_SERIAL_PORTS; i++) {
ser_cfg = read_serial_cfg(i);
ser_cfg = set_serial_data_bits(ser_cfg, 7);
write_serial_cfg(i, ser_cfg);
}
}
One reason for not doing this is that we should not reinvent the wheel
again and again, and instead use standard APIs.
I cannot find any such code in U-Boot, so I cannot check, but to me it
smells a lot as if this code should rather use clrsetbits_*() and
other proper I/O accessors.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Steal five dollars and you were a petty thief. Steal thousands of
dollars and you are either a government or a hero.
- Terry Pratchett, _Going_Postal_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: add marvell specific cache operation
For Marvell sheeva 88SV331xV5 core, it has one special cache asm code to do the clean and valid in one line. Signed-off-by: Lei Wen lei...@marvell.com --- arch/arm/lib/cache.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c index 30686fe..ae8f7e0 100644 --- a/arch/arm/lib/cache.c +++ b/arch/arm/lib/cache.c @@ -33,11 +33,15 @@ void flush_cache (unsigned long dummy1, unsigned long dummy2) arm1136_cache_flush(); #endif #ifdef CONFIG_ARM926EJS +#if defined(CONFIG_SHEEVA_88SV331xV5) + asm(mcr p15, 0, %0, c7, c14, 0 : : r (0)); +#else /* test and clean, page 2-23 of arm926ejs manual */ asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory); /* disable write buffer as well (page 2-22) */ asm(mcr p15, 0, %0, c7, c10, 4 : : r (0)); #endif +#endif #ifdef CONFIG_OMAP34XX void v7_flush_cache_all(void); -- 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] ARM: add marvell specific cache operation
-Original Message- From: Lei Wen [mailto:lei...@marvell.com] Sent: Thursday, June 16, 2011 2:34 PM To: u-boot@lists.denx.de; Prafulla Wadaskar; wadas...@marvell.com; Prafulla Wadaskar; adrian.w...@gmail.com Subject: [PATCH] ARM: add marvell specific cache operation For Marvell sheeva 88SV331xV5 core, it has one special cache asm code to do the clean and valid in one line. Signed-off-by: Lei Wen lei...@marvell.com --- arch/arm/lib/cache.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c index 30686fe..ae8f7e0 100644 --- a/arch/arm/lib/cache.c +++ b/arch/arm/lib/cache.c @@ -33,11 +33,15 @@ void flush_cache (unsigned long dummy1, unsigned long dummy2) arm1136_cache_flush(); #endif #ifdef CONFIG_ARM926EJS +#if defined(CONFIG_SHEEVA_88SV331xV5) + asm(mcr p15, 0, %0, c7, c14, 0 : : r (0)); +#else Hi Lei I had pushed similar code long back but it was not accepted at that time. You may push this with proper explanation- 1. What this code exactly does and how this change is important for SHEEVA SoCs and boards mainlined so far. Regards.. Prafulla . . /* test and clean, page 2-23 of arm926ejs manual */ asm(0: mrc p15, 0, r15, c7, c10, 3\n\t bne 0b\n : : : memory); /* disable write buffer as well (page 2-22) */ asm(mcr p15, 0, %0, c7, c10, 4 : : r (0)); #endif +#endif #ifdef CONFIG_OMAP34XX void v7_flush_cache_all(void); -- 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] ARM: add marvell specific cache operation
Hi Prafulla, On Thu, Jun 16, 2011 at 5:31 PM, Prafulla Wadaskar prafu...@marvell.com wrote: -Original Message- From: Lei Wen [mailto:lei...@marvell.com] Sent: Thursday, June 16, 2011 2:34 PM To: u-boot@lists.denx.de; Prafulla Wadaskar; wadas...@marvell.com; Prafulla Wadaskar; adrian.w...@gmail.com Subject: [PATCH] ARM: add marvell specific cache operation For Marvell sheeva 88SV331xV5 core, it has one special cache asm code to do the clean and valid in one line. Signed-off-by: Lei Wen lei...@marvell.com --- arch/arm/lib/cache.c | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c index 30686fe..ae8f7e0 100644 --- a/arch/arm/lib/cache.c +++ b/arch/arm/lib/cache.c @@ -33,11 +33,15 @@ void flush_cache (unsigned long dummy1, unsigned long dummy2) arm1136_cache_flush(); #endif #ifdef CONFIG_ARM926EJS +#if defined(CONFIG_SHEEVA_88SV331xV5) + asm(mcr p15, 0, %0, c7, c14, 0 : : r (0)); +#else Hi Lei I had pushed similar code long back but it was not accepted at that time. You may push this with proper explanation- 1. What this code exactly does and how this change is important for SHEEVA SoCs and boards mainlined so far. Thanks for your suggestion. The original implementation only drain write buffer. It cannot assure that when using dma from device to memory, the device cannot read the obsolete content of that range. Only invalidate cache would do that way. This new adding assemble code for flushing has this meaning as: DCache Clean All and Invalidate. Cleans all lines in the DCache, then invalidates the cache. It is slightly different from common arm core, as when we want invalidate the cache, we need to invalidate each cache entry. That is the reason why I add this specific implementation for Marvell core only. Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh, In message 4df9b9e0.8020...@ti.com you wrote: To make sure I understand your new proposals, let me consolidate them here. Please correct me if I am wrong. Also, in the end I have some questions about your new proposal. Some of the questions are getting into the details. But I need the details to re-work my patches according to the new proposal. Thanks for going into this! Current Design: * Currently a single board level Makefile determines what gets built into SPL. And as we have learned so far, these board level Makefiles contain a large lot of duplicated code, especially when dealing with several boards based on the same or similar Soc(s). * This Makefile chooses all the files to be built. Makes symbolic links to them in the board level SPL directory and builds and links them to create the SPL image. * This structure is duplicated for different types of SPLs, nand_spl, onenand_ipl, mmc_spl etc. * Directory structure is something like: nand_spl/board/vendor/board/ All correct so far. New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' The longer I think about this the more I feel we should even take this one step further. Looking at what we have so far: mmc_spl/ nand_spl/ onenand_ipl/ we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ This can probably done in an initial step which is more or less plain renaming and without any functional changes. We would then have spl/Makefile ... spl/common/Makefile ... spl/nand/Makefile ... * nand_spl/Makefile builds a generic library with the generic source files at this level. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. ...again with the addition that these may or may not exist - depending if any board specific code is needed or not. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image. ...together by spl/Makefile ... Open questions about the new proposal: 1. We may need more layers than just generic, SoC and board. For instance all SPLs typically use start.S from the CPU directory. Also, a lot of SoC code is typically SoC family generic. How about something like this for the directory structure: nand_spl/cpu/ soc-family/ soc1/board/ soc2/board/ Maybe, arch needs to be added too. If this seems necessary, we may do this. But I would like to avoid to copying basicly the whole source tree (either as verbatim copies or as symlinks). We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? As far as building is concerned, the files to be built should always (unless truly common) be selected based on CONFIG_ settings in the Makefiles. As far as linking is concerned, we can do the same for most cases (keep in mind that all linker scripts are run through the C preprocessor, so we can do a lot of things). For those cases where even more flexibility is needed, we can use custom linker scripts in the board directories. 4. How do we handle the case where a given SoC doesn't need any board level code for the SPL(This is the case with OMAP4). Is this handled by just not have any board directories? Right. Or, if a board directory exists for other reasons, by just building an empty board library. 5. If so, how does the top-level SPL Makefile handle this? By checking for the existence of board directory before descending into it? How Yes. does it handle the link step
Re: [U-Boot] OpenRD Ultimate SATA SD
On Wed, 15 Jun 2011 22:10:30 -0700, Prafulla Wadaskar prafu...@marvell.com wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Philip Hands Sent: Wednesday, June 15, 2011 3:24 PM To: u-boot@lists.denx.de Subject: [U-Boot] OpenRD Ultimate SATA SD Hi, Hi Phil Thanks for the feedback. I've been trying to get a version of u-boot for OpenRD Ultimate that is willing to boot from all of NAND, USB, SD and SATA, and find that SD SATA is still not possible with -rc1 as packaged for Debian (and it seems that nothing in the subsequent work in the master git would help, but if people tell me that it does, I'll give that a try). I don't know which u-boot version you are referring? Once packed with board or one from u-boot.git. What I'm using is very close to this: http://anonscm.debian.org/gitweb/?p=collab-maint/u-boot.git;a=summary which is, as mentioned, the upstream (i.e. as available from denx.de) with debian patches added, the main effect of the patches being that one can then build them as a package -- this used to make more of a difference when we had a diff aimed at the OpenRD, but as you can see that was dropped by Clint on 2011-05-21 when it was merged into the upstream tree: Drop openrd-client-and-ultimate.diff (merged). I've since pulled from git://git.denx.de/u-boot.git, and rebased the Debian stuff, with my tiny patch added, as seen here: http://git.hands.com/u-boot the Debian build system applies the quilt patches (that are in ./debian/patches) so to see what actually gets built, see: http://git.hands.com/?p=u-boot.git;a=shortlog;h=refs/heads/patch-queue/master which has a commit for each of those patches, as applied, tacked on after the master branch. Just to make sure it's not been fixed somehow, I've just recompiled that without the last fil-sata-kludge.diff patch applied (my IRC nick is 'fil' BTW) and now it has now reverted to telling me this: =-=-=-=- Marvell ide reset Reset IDE: ide_preinit failed =-=-=-=- so that diff is required to make SATA work in the setup I have on the OpenRD Ultimate (internal SATA, no eSATA). For other one, u-boot.git (mainlined) SATA is functional, SD not yet supported. OK, so as I said, SATA only works for me if I disable the probing of the second SATA port in ide_preinit, as described here: http://git.hands.com/?p=u-boot.git;a=commit;h=142f614593c4738fdd9c466d33eb41ef16b6a6b1 As for SD, well, it claims to initialise: Marvell mmc init SDHC found. Card desciption is: Manufacturer: 0x1e, OEM AB Product name: USD , revision 1.0 Serial number: 93331321 Manufacturing date: 8/2010 CRC:0x00, b0 = 0 mmc1 is available and then in the past, doing any reading would make it lock up, but I notice that the version I just built actually lets me boot from SD, so it might be unsupported, but it works some of the time, at least. I'll see if I can narrow down when it works for me, or not. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpcmcz3HwzOb.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
On 15/06/11 22:51, Wolfgang Denk wrote: Dear Graeme Russ, In message 4df8a8cf.5000...@gmail.com you wrote: And to set the value then you have: reg = ~a_mask; /* Clear a_val */ reg |= (a_val a_shift) a_mask; /* Set new a_val */ This could be done using clrsetbits_le32(reg, a_mask, a_val a_shift); Not quite: clrsetbits_le32(reg, a_mask, (a_val a_shift) a_mask); is equivalent except that, as already pointed out, clrsetbits and friends: a) Are not portable because only ARM and PPC define them which makes them, by definition, non-standard b) Each invocation results in a read barrier plus a write barrier c) If the hardware register is sensitive to partial updates (i.e. requires all bit-fields to be updated in on operation) this requires a read into a local variable, calls to clrsetbits against that variable and finally a write-back - Lots of memory barriers I know I'm going over old ground, and it's not that I am against clrsetbits, it's just good to know the limitations up-front. So remember, clrsetbits is not platform independent, prevents the compiler from optimising and will most likely impose a performance hit Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
On 16/06/11 18:15, Wolfgang Denk wrote:
Dear Graeme Russ,
In message banlktik3cxemzu0qpxdlsqmtk-abeod...@mail.gmail.com you wrote:
Now, that being said, I see no reason not to do the following if I had,
for example, multiple serial port configuration registers which are all
identical:
/* num data bits is stored in bits 2-4 of the serial config register */
#define DATA_BITS_MASK 0x001c
#define DATA_BITS_OFFSET 2
u32 set_serial_data_bits(u32 ser_cfg, u8 data_bits)
{
ser_cfg = ~DATA_BITS_MASK;
ser_cfg |= ((u32)ser_cfg DATA_BITS_OFFSET) DATA_BITS_MASK;
return ser_cfg;
}
void serial_init(void)
{
u32 ser_cfg;
for (i=0; iNUM_SERIAL_PORTS; i++) {
ser_cfg = read_serial_cfg(i);
ser_cfg = set_serial_data_bits(ser_cfg, 7);
write_serial_cfg(i, ser_cfg);
}
}
One reason for not doing this is that we should not reinvent the wheel
again and again, and instead use standard APIs.
I cannot find any such code in U-Boot, so I cannot check, but to me it
smells a lot as if this code should rather use clrsetbits_*() and
other proper I/O accessors.
Except nobody outside ARM and PPC knows about clrsetbits and friends, so I
would not call them a standard API
I will, however, keep them in mind and implement them for x86 when I have a
need for bit-field operations
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI
-Original Message- From: Holger Brunck [mailto:holger.bru...@keymile.com] Sent: Wednesday, June 15, 2011 1:42 PM To: u-boot@lists.denx.de Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schocher Subject: [PATCH v2 1/2] arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI Some boards e.g. keymile arm boards have CONFIG_CMD_I2C switched on but they use soft i2c on kirkwood. So don't switch CONFIG_I2C_MVTWSI on in this case. Signed-off-by: Holger Brunck holger.bru...@keymile.com cc: Valentin Longchamp valentin.longch...@keymile.com cc: Prafulla Wadaskar prafu...@marvell.com cc: Heiko Schocher h...@denx.de --- changes for v2: - nothing arch/arm/include/asm/arch-kirkwood/config.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-kirkwood/config.h b/arch/arm/include/asm/arch-kirkwood/config.h index 71ba464..b7dae1e 100644 --- a/arch/arm/include/asm/arch-kirkwood/config.h +++ b/arch/arm/include/asm/arch-kirkwood/config.h @@ -137,7 +137,9 @@ * I2C related stuff */ #ifdef CONFIG_CMD_I2C +#ifndef CONFIG_SOFT_I2C #define CONFIG_I2C_MVTWSI +#endif #define CONFIG_SYS_I2C_SLAVE 0x0 #define CONFIG_SYS_I2C_SPEED 10 #endif Applied to u-boot-marvell.git next brach Regards.. Prafulla . . -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] arm/km: fix u-boot.kwb build breakage
-Original Message- From: Holger Brunck [mailto:holger.bru...@keymile.com] Sent: Wednesday, June 15, 2011 1:42 PM To: u-boot@lists.denx.de Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schocher Subject: [PATCH v2 2/2] arm/km: fix u-boot.kwb build breakage commit 010a958b (arm/km: remove CONFIG_SYS_KWD_CONFIG from keymile-common.h) breaks building keymile arm targets, when u-boot.kwb tries to generate the binary with mkimage. A simple make board or MAKEALL succeeded because it don't try to build the kirwood binary at the end. Due this commit we use the CONFIG_SYS_KWD_CONFIG from the arch-kirkwood/config.h and it was removed from the board config. But it was forgotten to include the header. Now the header is included in km_arm.h. Some other defines were obsolete due to this include, these are also removed in this commit. Signed-off-by: Holger Brunck holger.bru...@keymile.com cc: Valentin Longchamp valentin.longch...@keymile.com cc: Prafulla Wadaskar prafu...@marvell.com cc: Heiko Schocher h...@denx.de --- changes for v2: - move CONFIG_KW88F6281 to original place, it was unneeded to touch this for the initial patch include/configs/km/km_arm.h | 28 ++-- include/configs/mgcoge3un.h |1 + 2 files changed, 7 insertions(+), 22 deletions(-) diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h index 20ee6ea..4741278 100644 --- a/include/configs/km/km_arm.h +++ b/include/configs/km/km_arm.h @@ -40,7 +40,6 @@ * High Level Configuration Options (easy to change) */ #define CONFIG_MARVELL -#define CONFIG_ARM926EJS /* Basic Architecture */ #define CONFIG_FEROCEON_88FR131 /* CPU Core subversion */ #define CONFIG_KIRKWOOD /* SOC Family Name */ #define CONFIG_KW88F6281 /* SOC Name */ @@ -49,6 +48,12 @@ /* include common defines/options for all Keymile boards */ #include keymile-common.h +#define CONFIG_CMD_NAND +#define CONFIG_CMD_SF +#define CONFIG_SOFT_I2C /* I2C bit-banged */ + +#include asm/arch/config.h + #define CONFIG_SYS_TEXT_BASE 0x0400 /* code address after reloc */ #define CONFIG_ENV_SIZE (128 10) /* NAND chip block size */ #define CONFIG_SYS_MEMTEST_START 0x0040 /* 4M */ @@ -75,12 +80,7 @@ #define CONFIG_KM_ARCH_DBG_FILE scripts/debug-arm-env.txt -#define CONFIG_MD5 /* get_random_hex on krikwood needs MD5 support */ #define CONFIG_SKIP_LOWLEVEL_INIT/* disable board lowlevel_init */ -#define CONFIG_KIRKWOOD_EGIGA_INIT /* Enable GbePort0/1 for kernel */ -#undef CONFIG_KIRKWOOD_PCIE_INIT/* Disable PCIE Port0 for kernel */ -#define CONFIG_KIRKWOOD_RGMII_PAD_1V8/* Set RGMII Pad voltage to 1.8V */ - #define CONFIG_MISC_INIT_R /* @@ -116,7 +116,6 @@ */ #define CONFIG_CMD_ELF #define CONFIG_CMD_MTDPARTS -#define CONFIG_CMD_NAND #define CONFIG_CMD_NFS /* @@ -131,8 +130,6 @@ */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define NAND_MAX_CHIPS 1 -#define CONFIG_NAND_KIRKWOOD -#define CONFIG_SYS_NAND_BASE 0xd800 #define BOOTFLASH_START 0x0 @@ -175,8 +172,6 @@ /* * I2C related stuff */ -#define CONFIG_SOFT_I2C /* I2C bit-banged */ - #define CONFIG_KIRKWOOD_GPIO/* Enable GPIO Support */ #if defined(CONFIG_SOFT_I2C) #ifndef __ASSEMBLY__ @@ -200,8 +195,6 @@ int get_scl(void); #define I2C_DELAYudelay(3) /* 1/4 I2C clock duration */ #define I2C_SOFT_DECLARATIONS -#define CONFIG_SYS_I2C_SLAVE0x0 -#define CONFIG_SYS_I2C_SPEED10 #endif #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50 @@ -224,15 +217,8 @@ int get_scl(void); #define CONFIG_ENV_OFFSET_REDUND 0x2000 /* no bracets! */ #define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE) -#define CONFIG_CMD_SF - #define CONFIG_SPI_FLASH -#define CONFIG_HARD_SPI -#define CONFIG_KIRKWOOD_SPI #define CONFIG_SPI_FLASH_STMICRO -#define CONFIG_ENV_SPI_BUS 0 -#define CONFIG_ENV_SPI_CS0 -#define CONFIG_ENV_SPI_MAX_HZ5000/* 50Mhz */ #define FLASH_GPIO_PIN 0x0001 @@ -272,8 +258,6 @@ int get_scl(void); /* additions for new relocation code, must be added to all boards */ #define CONFIG_SYS_SDRAM_BASE0x -/* Kirkwood has 2k of Security SRAM, use it for SP */ -#define CONFIG_SYS_INIT_SP_ADDR 0xC8012000 /* Do early setups now in board_init_f() */ #define CONFIG_BOARD_EARLY_INIT_F diff --git a/include/configs/mgcoge3un.h b/include/configs/mgcoge3un.h index 6d56d7d..8d1b61f 100644 --- a/include/configs/mgcoge3un.h +++ b/include/configs/mgcoge3un.h @@ -48,6 +48,7 @@ #define KM_ENV_BUS pca9547:70:d /* I2C2 (Mux-Port 5)*/ /* we use a
Re: [U-Boot] [PATCH v3 5/5] arm/km: add support for portl2 board
-Original Message- From: Holger Brunck [mailto:holger.bru...@keymile.com] Sent: Wednesday, June 15, 2011 8:12 PM To: u-boot@lists.denx.de Cc: Valentin Longchamp; Holger Brunck; Prafulla Wadaskar; Heiko Schocher Subject: [PATCH v3 5/5] arm/km: add support for portl2 board From: Valentin Longchamp valentin.longch...@keymile.com This adds support for the keymile Kirkwood BEC portl2 board. This board relies on the km_arm (km_kirkwood) BEC. The egiga driver is configured for a 100M full-duplex, A/N off connnection to the backplane. This board has always ethernet present, because it is connected to the marvell switch similar to mgcoge3un. The reset_phy functionality is also the same to mgcoge3un. Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com Signed-off-by: Holger Brunck holger.bru...@keymile.com cc: Prafulla Wadaskar prafu...@marvell.com cc: Heiko Schocher h...@denx.de --- Changes for v3: - rebase Changes for v2: - add this board support patch to the end of the serie MAINTAINERS |1 + MAKEALL |1 + board/keymile/km_arm/km_arm.c |8 +++-- boards.cfg|1 + include/configs/portl2.h | 81 + 5 files changed, 89 insertions(+), 3 deletions(-) create mode 100644 include/configs/portl2.h Applied this patch series 1/5-to-5/5 to u-boot-marvell.git next branch Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-marvell.git
Hi Albert
Please kindly pull
The following changes since commit 7b2fac7654f7420c2787f74ec3b1540fa3b343e9:
Aneesh V (1):
omap730p2: fix build breaks
are available in the git repository at:
u-boot-marvell.git next branch.
Holger Brunck (4):
arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI
arm/km: fix u-boot.kwb build breakage
arm/km: remove unneeded define
arm/km: replace suenx targets with km_kirkwood
Valentin Longchamp (3):
arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS
arm/km: ethernet support for mgcoge3un
arm/km: add support for portl2 board
MAINTAINERS |7 ++-
MAKEALL |3 +-
arch/arm/include/asm/arch-kirkwood/config.h |2 +
board/keymile/km_arm/km_arm.c | 45 ++-
boards.cfg |5 +-
include/configs/km/km_arm.h | 32 ++
include/configs/{suen3.h = km_kirkwood.h} | 18 --
include/configs/mgcoge3un.h |6 ++
include/configs/portl2.h| 81 +++
include/configs/suen8.h | 50
10 files changed, 161 insertions(+), 88 deletions(-)
rename include/configs/{suen3.h = km_kirkwood.h} (77%)
create mode 100644 include/configs/portl2.h
delete mode 100644 include/configs/suen8.h
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] YOUR EMAIL ACCOUNT VERIFICATION
Attn... We regret to announce to you that we will be making some vital maintainance on your email account/general web upgrade. During this process you might have login problems in signing into your online account, but to prevent this you have to confirm your account immediately after you receive this notification. To confirm and to keep your account active during and after this process, please reply to this message with the below account information. Failure to do this might cause a permanent deactivation of your user account from our database to enable us create more spaces for new users and to prevent junk and spam emails. YOUR EMAIL ACCOUNT VERIFICATION Username: Password: Date of birth: Your account shall remain active after you have completed the verification process as instructed above. Thanks for bearing with us. Web Support Team Message Code: 002671 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Graeme Russ, In message 4df9e409.1060...@gmail.com you wrote: is equivalent except that, as already pointed out, clrsetbits and friends: a) Are not portable because only ARM and PPC define them which makes them, by definition, non-standard They should be added to _any_ arch/arch/include/asm/io.h that doesn't use them yet. b) Each invocation results in a read barrier plus a write barrier ...which is intentionally (actually mandatory) when accessing I/O memory, and negligable overhead on plain memory. c) If the hardware register is sensitive to partial updates (i.e. requires all bit-fields to be updated in on operation) this requires a read into a local variable, calls to clrsetbits against that variable and finally a write-back - Lots of memory barriers Wrong. The macro does this automatically. There is only a single read and a single write per call. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Ernest asks Frank how long he has been working for the company. Ever since they threatened to fire me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang, On Thursday 16 June 2011 04:17 PM, Wolfgang Denk wrote: Dear Aneesh, In message4df9b9e0.8020...@ti.com you wrote: To make sure I understand your new proposals, let me consolidate them here. Please correct me if I am wrong. Also, in the end I have some questions about your new proposal. Some of the questions are getting into the details. But I need the details to re-work my patches according to the new proposal. Thanks for going into this! Current Design: * Currently a single board level Makefile determines what gets built into SPL. And as we have learned so far, these board level Makefiles contain a large lot of duplicated code, especially when dealing with several boards based on the same or similar Soc(s). * This Makefile chooses all the files to be built. Makes symbolic links to them in the board level SPL directory and builds and links them to create the SPL image. * This structure is duplicated for different types of SPLs, nand_spl, onenand_ipl, mmc_spl etc. * Directory structure is something like: nand_spl/board/vendor/board/ All correct so far. New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' The longer I think about this the more I feel we should even take this one step further. Looking at what we have so far: mmc_spl/ nand_spl/ onenand_ipl/ we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. This can probably done in an initial step which is more or less plain renaming and without any functional changes. We would then have spl/Makefile ... spl/common/Makefile ... spl/nand/Makefile ... * nand_spl/Makefile builds a generic library with the generic source files at this level. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). What's the distinction between spl/Makefile and spl/common/Makefile? I guess we won't have any source files at spl/ level? * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. ...again with the addition that these may or may not exist - depending if any board specific code is needed or not. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image. ...together by spl/Makefile ... Open questions about the new proposal: 1. We may need more layers than just generic, SoC and board. For instance all SPLs typically use start.S from the CPU directory. Also, a lot of SoC code is typically SoC family generic. How about something like this for the directory structure: nand_spl/cpu/ soc-family/ soc1/board/ soc2/board/ Maybe,arch needs to be added too. If this seems necessary, we may do this. But I would like to avoid to copying basicly the whole source tree (either as verbatim copies or as symlinks). We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. You mean you will re-use *.o files with normal u-boot? If so, do you want to create symbolic links to them in the SPL directories or use them in-place? Whether you reuse the source code or the object files we still need directories for all the levels for the respective Makefiles, right? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ I meant code that is media specific, such as MMC support, NAND support etc. I think these should still go in spl/mmc, spl/nand etc right? A multi-device SPL will have to use 2 or more such libraries. 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe,
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message 4df9ee03.8010...@ti.com you wrote: we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. Correct, i. e. please add for example: spl/board/freescale/mx31pdk/ spl/board/freescale/mx31pdk/Makefile ... ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). What's the distinction between spl/Makefile and spl/common/Makefile? I guess we won't have any source files at spl/ level? I think we can implement the logic to decide which directories need to be entered and built into spl/Makefile, so we can keep this out of the top level Makefile. spl/common/Makefile is responsible for building the common code in the spl/common/ directory. Correct, I do not see need for any sources in spl/ We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. You mean you will re-use *.o files with normal u-boot? If so, do you want to create symbolic links to them in the SPL directories or use them in-place? We should use them in-place. Using --gc-sections and -ffunction-sections we have enough granularity to select only what we really need. Whether you reuse the source code or the object files we still need directories for all the levels for the respective Makefiles, right? Can we not use the objects that get normally built, with the existing Makefiles? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. Please let's check where this is needed, and how we can handle this. I'd really like to get rid of this symlinking. I meant code that is media specific, such as MMC support, NAND support etc. I think these should still go in spl/mmc, spl/nand etc right? A multi-device SPL will have to use 2 or more such libraries. Right. So, is the logic like this: If there is a linker script in the board directory use it, else look for a linker script in SoC directory? We should use the same logic as in config.mk, i. e. CONFIG_SYS_LDSCRIPT has hioghest priority, then search in the standard locations. BTW, my question was more about the contents of final image than the memory map. But, I think this can be handled with appropriate use of --gc-sections, -ffunction-sections, and -fdata-sections. The two main entry points board_init_f() and board_init_r() are typically implemented in the SoC layer or board layer of an SPL. This along with the use of above compiler switches will help SoCs/boards to link in only what they need, right? This is my understanding, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 2000 pounds of chinese soup = 1 Won Ton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD Ultimate SATA SD
2011/6/16 Philip Hands p...@hands.com: On Wed, 15 Jun 2011 22:10:30 -0700, Prafulla Wadaskar prafu...@marvell.com wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Philip Hands Sent: Wednesday, June 15, 2011 3:24 PM To: u-boot@lists.denx.de Subject: [U-Boot] OpenRD Ultimate SATA SD Hi, Hi Phil Thanks for the feedback. I've been trying to get a version of u-boot for OpenRD Ultimate that is willing to boot from all of NAND, USB, SD and SATA, and find that SD SATA is still not possible with -rc1 as packaged for Debian (and it seems that nothing in the subsequent work in the master git would help, but if people tell me that it does, I'll give that a try). I don't know which u-boot version you are referring? Once packed with board or one from u-boot.git. What I'm using is very close to this: http://anonscm.debian.org/gitweb/?p=collab-maint/u-boot.git;a=summary which is, as mentioned, the upstream (i.e. as available from denx.de) with debian patches added, the main effect of the patches being that one can then build them as a package -- this used to make more of a difference when we had a diff aimed at the OpenRD, but as you can see that was dropped by Clint on 2011-05-21 when it was merged into the upstream tree: Drop openrd-client-and-ultimate.diff (merged). I've since pulled from git://git.denx.de/u-boot.git, and rebased the Debian stuff, with my tiny patch added, as seen here: http://git.hands.com/u-boot the Debian build system applies the quilt patches (that are in ./debian/patches) so to see what actually gets built, see: http://git.hands.com/?p=u-boot.git;a=shortlog;h=refs/heads/patch-queue/master which has a commit for each of those patches, as applied, tacked on after the master branch. Just to make sure it's not been fixed somehow, I've just recompiled that without the last fil-sata-kludge.diff patch applied (my IRC nick is 'fil' BTW) and now it has now reverted to telling me this: =-=-=-=- Marvell ide reset Reset IDE: ide_preinit failed =-=-=-=- so that diff is required to make SATA work in the setup I have on the OpenRD Ultimate (internal SATA, no eSATA). For other one, u-boot.git (mainlined) SATA is functional, SD not yet supported. OK, so as I said, SATA only works for me if I disable the probing of the second SATA port in ide_preinit, as described here: http://git.hands.com/?p=u-boot.git;a=commit;h=142f614593c4738fdd9c466d33eb41ef16b6a6b1 As for SD, well, it claims to initialise: Marvell mmc init SDHC found. Card desciption is: Manufacturer: 0x1e, OEM AB Product name: USD , revision 1.0 Serial number: 93331321 Manufacturing date: 8/2010 CRC: 0x00, b0 = 0 mmc1 is available and then in the past, doing any reading would make it lock up, but I notice that the version I just built actually lets me boot from SD, so it might be unsupported, but it works some of the time, at least. I'll see if I can narrow down when it works for me, or not. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot I am experiencing the same problem with SATA right now with v2011.06-rc2 (tried also the latest master). If MVSATA_STATUS_TIMEOUT in mvsata_ide_initialize_port is ignored, SATA drive is found on the second port and I am able to read the drive's content. Best regards Alexey Ozhigov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi all, for my MIPS based boards I tested a approach similar to Wolfgang's one in the last weeks. My goal was to create a SPL image, that is able to boot from a SPI flash. The basic idea is to have a spl directory that is used as remote build directory for all object files needed for the SPL image. It contains only the Makefile and nothing else. This Makefile is a strongly simplified version of the TOPDIR/Makefile, uses TOPDIR/config.mk and creates a u-boot-spl.bin. The SPL build can be enabled by defining CONFIG_UBOOT_SPL in the board config file. If the spl/Makefiles becomes active, an additional variable name CONFIG_UBOOT_SPL_BUILD wiil be exported in the make environment. Additionally -DCONFIG_UBOOT_SPL_BUILD will be added to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse almost of the arch, SoC and board code. The board_init_f function could be implemented in arch/ARCH/lib/board_spl.c to allow arch-specific code. The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. With this approach I can create a SPL image, that reuses all of the minimal needed MIPS CPU code, mySoC code, my board lowlevel_init, my SPI driver and some parts of the generic SPI flash driver. Some further comments below On Thu, Jun 16, 2011 at 12:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Aneesh, [snip] The longer I think about this the more I feel we should even take this one step further. Looking at what we have so far: mmc_spl/ nand_spl/ onenand_ipl/ we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ This can probably done in an initial step which is more or less plain renaming and without any functional changes. We would then have spl/Makefile ... spl/common/Makefile ... spl/nand/Makefile ... * nand_spl/Makefile builds a generic library with the generic source files at this level. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). * It then descends into sub-directories(SoC, board etc) to make the respective libraries at those levels. ...again with the addition that these may or may not exist - depending if any board specific code is needed or not. * These libraries are finally linked together by nand_spl/Makefile to build the SPL image. ...together by spl/Makefile ... Open questions about the new proposal: 1. We may need more layers than just generic, SoC and board. For instance all SPLs typically use start.S from the CPU directory. Also, a lot of SoC code is typically SoC family generic. How about something like this for the directory structure: nand_spl/cpu/ soc-family/ soc1/board/ soc2/board/ Maybe, arch needs to be added too. If this seems necessary, we may do this. But I would like to avoid to copying basicly the whole source tree (either as verbatim copies or as symlinks). We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. By using something like CONFIG_UBOOT_SPL_BUILD in the make environment and as CFLAG all code can be reused without symlinking or copying. You need only a separate directory for putting the object files in. 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? As far as building is concerned, the files to be built should always (unless truly
Re: [U-Boot] SPL framework re-design
Dear all, Am 16.06.2011 14:55, schrieb Daniel Schwierzeck: snip On Thu, Jun 16, 2011 at 12:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Aneesh, snip We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. By using something like CONFIG_UBOOT_SPL_BUILD in the make environment and as CFLAG all code can be reused without symlinking or copying. You need only a separate directory for putting the object files in. +1 for reusing existing stuff but changing it a little bit to be able to work as spl(driver) where this is necessary 2. How do we handle the type of SPLs that handle different media. For instance omap3 spl will support mmc and NAND. Can we have a directory tree starting with 'spl/'? If so, how does this tree share generic code Yes, this makes a lot of sense to me - see above. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. sounds better to me than having a complete new tree under /spl regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Thursday 16 June 2011 05:45 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4df9ee03.8010...@ti.com you wrote: we are also duplicating the structure across different boot media. I think we should re-organize this as follows: spl/ spl/common/ spl/mmc/ spl/nand/ spl/onenand/ Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. Correct, i. e. please add for example: spl/board/freescale/mx31pdk/ spl/board/freescale/mx31pdk/Makefile ... I thought we were going to have cpu directory SoC directory etc in this directory structure. ...this changes to: spl/Makefile, spl/common/Makefile and spl/bootdevice/Makefile build libraries with the generic object files at their respective level (assuming these exist). What's the distinction between spl/Makefile and spl/common/Makefile? I guess we won't have any source files at spl/ level? I think we can implement the logic to decide which directories need to be entered and built into spl/Makefile, so we can keep this out of the top level Makefile. spl/common/Makefile is responsible for building the common code in the spl/common/ directory. Correct, I do not see need for any sources in spl/ We should try to get rid of the need to create symbolic links. If we use the same source files as for the normal, then we should also use the normal object files. You mean you will re-use *.o files with normal u-boot? If so, do you want to create symbolic links to them in the SPL directories or use them in-place? We should use them in-place. Using --gc-sections and -ffunction-sections we have enough granularity to select only what we really need. Whether you reuse the source code or the object files we still need directories for all the levels for the respective Makefiles, right? Can we not use the objects that get normally built, with the existing Makefiles? But where do you add the reference to SoC level and CPU level object files? Which library do you make them part of? I thought the board level Makefile was meant only to build the board specific library. For example, let's say we have board 'a' and 'b' of same SoC(soc). Unless we have a SoC directory we may have to do something like this. spl/board/vendor/a/Makefile: OBJS := soc_1.o OBJS += soc_2.o OBJS += a.o spl/board/vendor/b/Makefile: OBJS := soc_1.o OBJS += soc_2.o OBJS += b.o Please note that soc_1.o and soc_2.o are duplicated in the two Makefiles. We are back to square one, right? Or did you have something else in mind? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. Please let's check where this is needed, and how we can handle this. I'd really like to get rid of this symlinking. One case is start.S. We need a simplified start.S for SPL(no relocation, no interrupt handling etc). There are places where CONFIG_PRELOADER is used today. But maybe, these could be avoided it we try. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MMC: add erase function to both mmc and sd
Erase is a very basic function since the begin of sd specification is
announced. Although we could write a bulk of full 0xff memory to the
range to take place of erase, it is more convenient and safe to
implement the erase function itself.
Signed-off-by: Lei Wen lei...@marvell.com
---
common/cmd_mmc.c | 23
drivers/mmc/mmc.c | 102 +
include/mmc.h |8
include/part.h|3 ++
4 files changed, 136 insertions(+), 0 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 176646d..a6483ba 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -287,6 +287,28 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
printf(%d blocks written: %s\n,
n, (n == cnt) ? OK : ERROR);
return (n == cnt) ? 0 : 1;
+ } else if (strcmp(argv[1], erase) == 0) {
+ u32 cnt = simple_strtoul(argv[3], NULL, 16);
+ u32 n;
+ struct mmc *mmc = find_mmc_device(dev);
+
+ int blk = simple_strtoul(argv[2], NULL, 16);
+
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, curr_device);
+ return 1;
+ }
+
+ printf(\nMMC erase: dev # %d, block # %d, count %d ... ,
+ curr_device, blk, cnt);
+
+ mmc_init(mmc);
+
+ n = mmc-block_dev.block_erase(curr_device, blk, cnt);
+
+ printf(%d blocks erased: %s\n,
+ n, (n == cnt) ? OK : ERROR);
+ return (n == cnt) ? 0 : 1;
}
return cmd_usage(cmdtp);
@@ -297,6 +319,7 @@ U_BOOT_CMD(
MMC sub system,
read addr blk# cnt\n
mmc write addr blk# cnt\n
+ mmc erase addr blk# cnt\n
mmc rescan\n
mmc part - lists available partition on current mmc device\n
mmc dev [dev] [part] - show or set current mmc device [partition]\n
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 21aedba..64bb2a8 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -174,6 +174,88 @@ struct mmc *find_mmc_device(int dev_num)
return NULL;
}
+static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
+{
+ struct mmc_cmd cmd;
+ ulong end;
+ int err, start_cmd, end_cmd;
+
+ if (mmc-high_capacity)
+ end = start + blkcnt - 1;
+ else {
+ end = (start + blkcnt - 1) * mmc-write_bl_len;
+ start *= mmc-write_bl_len;
+ }
+
+ if (IS_SD(mmc)) {
+ start_cmd = SD_CMD_ERASE_WR_BLK_START;
+ end_cmd = SD_CMD_ERASE_WR_BLK_END;
+ } else {
+ start_cmd = MMC_CMD_ERASE_GROUP_START;
+ end_cmd = MMC_CMD_ERASE_GROUP_END;
+ }
+
+ cmd.cmdidx = start_cmd;
+ cmd.cmdarg = start;
+ cmd.resp_type = MMC_RSP_R1;
+ cmd.flags = 0;
+
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err)
+ goto err_out;
+
+ cmd.cmdidx = end_cmd;
+ cmd.cmdarg = end;
+
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err)
+ goto err_out;
+
+ cmd.cmdidx = MMC_CMD_ERASE;
+ cmd.cmdarg = SECURE_ERASE;
+ cmd.resp_type = MMC_RSP_R1b;
+
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err)
+ goto err_out;
+
+ return 0;
+
+err_out:
+ printf(mmc erase failed\n\r);
+ return err;
+}
+
+static unsigned long
+mmc_berase(int dev_num, unsigned long start, lbaint_t blkcnt)
+{
+ int err = 0;
+ struct mmc *mmc = find_mmc_device(dev_num);
+ lbaint_t blk = 0, blk_r = 0;
+
+ if (!mmc)
+ return -1;
+
+ if ((start % mmc-erase_grp_size) || (blkcnt % mmc-erase_grp_size))
+ printf(\n\nCaution! Your devices Erase group is 0x%x\n
+ The erase range would be change to 0x%x~0x%x\n\n,
+ mmc-erase_grp_size, start ~(mmc-erase_grp_size - 1),
+ ((start + blkcnt + mmc-erase_grp_size)
+ ~(mmc-erase_grp_size - 1)) - 1);
+
+ while (blk blkcnt) {
+ blk_r = ((blkcnt - blk) mmc-erase_grp_size) ?
+ mmc-erase_grp_size : (blkcnt - blk);
+ err = mmc_erase_t(mmc, start + blk, blk_r);
+ if (err)
+ break;
+
+ blk += blk_r;
+ }
+
+ return blk;
+}
+
static ulong
mmc_write_blocks(struct mmc *mmc, ulong start, lbaint_t blkcnt, const void*src)
{
@@ -911,6 +993,10 @@ int mmc_startup(struct mmc *mmc)
return err;
}
+ /*
+* For SD, its erase group is always one sector
+*/
+ mmc-erase_grp_size = 1;
mmc-part_config = MMCPART_NOAVAILABLE;
if (!IS_SD(mmc) (mmc-version = MMC_VERSION_4)) {
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Wed, Jun 15, 2011 at 11:27 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ graeme.r...@gmail.com wrote: [snip] BTW should the deltas return a signed value? No - times are unsigned utilising the entire range of the u32 so (to - from) will always returned the unsigned delta, even if there is a wrap between them. I cannot imagine we would ever need to measure time backward anyway. Can you please explain this again in different words as I don't follow. The difference between two unsigned times may be +ve or -ve, surely. For example, say: now = 100 event_time = 200 then the delta is currently -100. Some people might loop until the delta is = 0. This is like setting a future time and waiting for it to happen. If the delta is unsigned then this won't work. start = 0xff00 now = 0x0010 So there was a timer wrap between 'start' and 'now' delta = now - start = 0x110 Remember that the new timer API does not rely on the tick counter (and therefore the ms/us timers) to start at zero - It must be allowed to wrap without causing timer glitches at any arbitray time Hi Graeme, Yes I'm fine with that last bit. Taking your example, say now is 0xff00. Then: unsigned stop_at = time_now_ms() + 0x110; // stop_at = 0x10 int diff = time_since_ms(stop_at) I think this will set diff to -0x110, right? You can then wait until diff goes +ve, at which point you know your timeout has passed. I think it is useful for the time delta to be negative or positive, for this reason. I suppose what I am saying is that there are two ways of doing timeouts: 1. Record the start time, then wait until the delta gets big enough 2. Record the finish time, then wait until it arrives. The latter can be useful if you have multiple timeouts in progress at once, something I am thinking we may want to do with USB scanning. Regards, Simon Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hi Daniel, This looks like an interesting alternative. On Thursday 16 June 2011 06:25 PM, Daniel Schwierzeck wrote: Hi all, for my MIPS based boards I tested a approach similar to Wolfgang's one in the last weeks. My goal was to create a SPL image, that is able to boot from a SPI flash. The basic idea is to have a spl directory that is used as remote build directory for all object files needed for the SPL image. It contains only the Makefile and nothing else. This Makefile is a strongly simplified version of the TOPDIR/Makefile, uses TOPDIR/config.mk and creates a u-boot-spl.bin. The SPL build can be enabled by defining CONFIG_UBOOT_SPL in the board config file. In the last few mails Wolfgang was suggesting re-use of object files themselves, not the source files. In this respect his approach may be different from yours. But I think his objective was to avoid the symbolic link business, which this approach achieves. If the spl/Makefiles becomes active, an additional variable name CONFIG_UBOOT_SPL_BUILD wiil be exported in the make environment. Additionally -DCONFIG_UBOOT_SPL_BUILD will be added to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse almost of the arch, SoC and board code. So, you are essentially re-using the make infrastructure of normal U-Boot with a different top-level Makefile and the additional flags, right? With this scheme can you build two different SPLs for a given board, let's say a NAND spl and another MMC spl. I don't know if this is a valid case, but just wondering. I guess you have a unique u-boot- spl.bin much like you have single u-boot.bin, right? Will you be sending your patches to the list? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/10] armv7: cache maintenance operations for armv7
Hi, I am picking up on this old thread. My main point is that I think the armv7 cache implementation is a good start and should go into U-Boot. Aneesh are you planning another patch set? Also see below: On Tue, May 17, 2011 at 2:58 AM, Aneesh V ane...@ti.com wrote: Hi Wolfgang, On Tuesday 17 May 2011 03:01 PM, Wolfgang Denk wrote: Dear Aneesh V, In message4dd23d3a.4010...@ti.com you wrote: How much of this is actually needed in the context of U-Boot? Please see above. As far as I know OMAP doesn't do DMA in U-Boot. Devices like USB oth Ethernet don't use DMA for data transfers? Ethernet support is not upstreamed yet. USB doesn't seem to be using DMA on a quick check. There is DMA in the USB EHCI side and this also does d cache range invalidate / flush. Regards, Simon best regards, Aneesh ___ 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] SPL framework re-design
On Thu, Jun 16, 2011 at 3:57 PM, Aneesh V ane...@ti.com wrote: Hi Daniel, This looks like an interesting alternative. On Thursday 16 June 2011 06:25 PM, Daniel Schwierzeck wrote: Hi all, for my MIPS based boards I tested a approach similar to Wolfgang's one in the last weeks. My goal was to create a SPL image, that is able to boot from a SPI flash. The basic idea is to have a spl directory that is used as remote build directory for all object files needed for the SPL image. It contains only the Makefile and nothing else. This Makefile is a strongly simplified version of the TOPDIR/Makefile, uses TOPDIR/config.mk and creates a u-boot-spl.bin. The SPL build can be enabled by defining CONFIG_UBOOT_SPL in the board config file. In the last few mails Wolfgang was suggesting re-use of object files themselves, not the source files. In this respect his approach may be different from yours. But I think his objective was to avoid the symbolic link business, which this approach achieves. I guess this requires more changes in the build system. But I wanted to keep the diff as minimal as possible. And some files like start.S must be recompiled with different flags. If running from SRAM you need another monitor base address, stack pointer offset and you must disable the relocate_code stuff. To reduce the SPL footprint you have to disable the whole printf and console stuff, so maybe you must recompile some drivers too. If the spl/Makefiles becomes active, an additional variable name CONFIG_UBOOT_SPL_BUILD wiil be exported in the make environment. Additionally -DCONFIG_UBOOT_SPL_BUILD will be added to the CFLAGS (similar to -DCONFIG_PRELOADER). This allows us to reuse almost of the arch, SoC and board code. So, you are essentially re-using the make infrastructure of normal U-Boot with a different top-level Makefile and the additional flags, right? yes, but mainly the config.mk With this scheme can you build two different SPLs for a given board, let's say a NAND spl and another MMC spl. I don't know if this is a valid case, but just wondering. I guess you have a unique u-boot- spl.bin much like you have single u-boot.bin, right? I have a single u-boot.bin and a single u-boot-spl.bin. To create images for different boot media, I use different board configs. For example BOARDNAME_nor or BOARDNAME_sf to boot from NOR flash or SPI flash. The NOR image currently builds without SPL. But there is a use case to combine a SPL image and a compressed U-Boot image to reduce the overall flash footprint. Will you be sending your patches to the list? I've pushed some sample code to https://github.com/danielschwierzeck/u-boot-spl/commits/spl Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Nested Makefiles
Hi, Is it possible for U-Boot to use a system similar to Linux from 2.6 where it prints out the full pathname of each file it is building, and doesn't change in and out of directories as it builds. Perhaps including the subdirectory Makefiles instead using make -C? I haven't looked at how Linux does it. Is there some reason U-Boot cannot / should not do the same? So for example: $ make all CC drivers/spi/tegra2_spi.c Warning: blah blah blah CC board/fred/board.c CC arch/arm/lib/board.c LD u-boot $ Unfortunately I don't even know the name for this feature so wasn't able to find a reference to it in the mailing list archives. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] MMC: add sdhci generic framework
Nowdays, there are plenty of mmc driver in uboot adopt the sd standard
host design, aka as sdhci. It is better to centralize the common logic
together to better maintenance.
Signed-off-by: Lei Wen lei...@marvell.com
---
drivers/mmc/Makefile |1 +
drivers/mmc/sdhci.c | 433 ++
include/sdhci.h | 325 +
3 files changed, 759 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/sdhci.c
create mode 100644 include/sdhci.h
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index a8fe17a..50b5117 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -38,6 +38,7 @@ COBJS-$(CONFIG_OMAP3_MMC) += omap3_mmc.o
COBJS-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o
COBJS-$(CONFIG_PXA_MMC) += pxa_mmc.o
COBJS-$(CONFIG_S5P_MMC) += s5p_mmc.o
+COBJS-$(CONFIG_SDHCI) += sdhci.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
new file mode 100644
index 000..9ebd33d
--- /dev/null
+++ b/drivers/mmc/sdhci.c
@@ -0,0 +1,433 @@
+/*
+ * Copyright 2011, Marvell Semiconductor Inc.
+ * Lei Wen lei...@marvell.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * Back ported to the 8xx platform (from the 8260 platform) by
+ * murray.jen...@cmst.csiro.au, 27-Jan-01.
+ */
+
+#include common.h
+#include malloc.h
+#include mmc.h
+#include sdhci.h
+
+void *aligned_buffer;
+
+static void sdhci_reset(struct sdhci_host *host, u8 mask)
+{
+ unsigned long timeout;
+
+ /* Wait max 100 ms */
+ timeout = 100;
+ sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
+ while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) mask) {
+ if (timeout == 0) {
+ printf(Reset 0x%x never completed.\n, (int)mask);
+ return;
+ }
+ timeout--;
+ udelay(1000);
+ }
+}
+
+static void sdhci_cmd_done(struct sdhci_host *host, struct mmc_cmd *cmd)
+{
+ int i;
+ if (cmd-resp_type MMC_RSP_136) {
+ /* CRC is stripped so we need to do some shifting. */
+ for (i = 0; i 4; i++) {
+ cmd-response[i] = sdhci_readl(host,
+ SDHCI_RESPONSE + (3-i)*4) 8;
+ if (i != 3)
+ cmd-response[i] |= sdhci_readb(host,
+ SDHCI_RESPONSE + (3-i)*4-1);
+ }
+ } else {
+ cmd-response[0] = sdhci_readl(host, SDHCI_RESPONSE);
+ }
+}
+
+static void sdhci_transfer_pio(struct sdhci_host *host, struct mmc_data *data)
+{
+ int i;
+ char *offs;
+ for (i = 0; i data-blocksize; i += 4) {
+ offs = data-dest + i;
+ if (data-flags == MMC_DATA_READ)
+ *(u32 *)offs = sdhci_readl(host, SDHCI_BUFFER);
+ else
+ sdhci_writel(host, *(u32 *)offs, SDHCI_BUFFER);
+ }
+}
+
+static int sdhci_transfer_data(struct sdhci_host *host, struct mmc_data *data,
+ unsigned int start_addr)
+{
+ unsigned int stat, rdy, mask, block = 0;
+
+ rdy = SDHCI_INT_SPACE_AVAIL | SDHCI_INT_DATA_AVAIL;
+ mask = SDHCI_DATA_AVAILABLE | SDHCI_SPACE_AVAILABLE;
+ do {
+ stat = sdhci_readl(host, SDHCI_INT_STATUS);
+ if (stat SDHCI_INT_ERROR) {
+ printf(Error detected in status(0x%X)!\n, stat);
+ return -1;
+ }
+ if (stat rdy) {
+ if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) mask))
+ continue;
+ sdhci_writel(host, rdy, SDHCI_INT_STATUS);
+ sdhci_transfer_pio(host, data);
+ data-dest += data-blocksize;
+ if (++block = data-blocks)
+ break;
+ }
+#ifdef CONFIG_MMC_SDMA
+ if (stat SDHCI_INT_DMA_END) {
+ sdhci_writel(host, SDHCI_INT_DMA_END, SDHCI_INT_STATUS);
+ start_addr =
[U-Boot] [PATCH 2/2] MMC: add marvell sdhci driver
This could support both armada100 and pantheon serial in the mainline,
while this driver also be tested to support upcoming mg, mmp2 and mmp3
hardware.
Signed-off-by: Lei Wen lei...@marvell.com
---
drivers/mmc/Makefile |1 +
drivers/mmc/sdhci-mv.c | 21 +
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/sdhci-mv.c
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 50b5117..fd84389 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o
COBJS-$(CONFIG_PXA_MMC) += pxa_mmc.o
COBJS-$(CONFIG_S5P_MMC) += s5p_mmc.o
COBJS-$(CONFIG_SDHCI) += sdhci.o
+COBJS-$(CONFIG_SDHCI_MV) += sdhci-mv.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mmc/sdhci-mv.c b/drivers/mmc/sdhci-mv.c
new file mode 100644
index 000..97d79ee
--- /dev/null
+++ b/drivers/mmc/sdhci-mv.c
@@ -0,0 +1,21 @@
+#include common.h
+#include malloc.h
+#include sdhci.h
+
+static char *MVSDH_NAME = sdh-mv;
+int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
+{
+ struct sdhci_host *host = NULL;
+ host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
+ if (!host) {
+ printf(sdh_host malloc fail!\n);
+ return 1;
+ }
+
+ host-name = MVSDH_NAME;
+ host-ioaddr = (void *)regbase;
+ host-quirks = quirks;
+ host-version = sdhci_readw(host, SDHCI_HOST_VERSION);
+ add_sdhci(host, max_clk, min_clk);
+ return 0;
+}
--
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 V2] memcpy/memmove: Do not copy to same address
Am 14.06.2011 08:18, schrieb Matthias Weißer: Hello Wolfgang Am 23.05.2011 11:03, schrieb Matthias Weisser: In some cases (e.g. bootm with a elf payload which is already at the right position) there is a in place copy of data to the same address. Catching this saves some ms while booting. What about this patch? As the initial submission of the patch was inside the merge window (see http://patchwork.ozlabs.org/patch/90725/) I would like to see the current version of this patch (see http://patchwork.ozlabs.org/patch/96841/) in the upcoming release. Sorry for the broken reference in patchwork. I try my best next time. If the community decides to NACK the patch I would be happy if you could accept http://patchwork.ozlabs.org/patch/79325/ Ping? Thanks Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
On 05/17/11 00:52, r...@efn.org wrote: Signed-off-by: Rick Bronson r...@efn.org --- arch/arm/cpu/armv7/omap-common/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/timer.c b/arch/arm/cpu/armv7/omap-common/timer.c index 9beebb1..3c9d488 100644 --- a/arch/arm/cpu/armv7/omap-common/timer.c +++ b/arch/arm/cpu/armv7/omap-common/timer.c @@ -44,7 +44,7 @@ static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE; */ #define TIMER_CLOCK (V_SCLK / (2 CONFIG_SYS_PTV)) -#define TIMER_LOAD_VAL 0x +#define TIMER_LOAD_VAL 0 /* counter starts from 0 on reload */ Has this been tested? If yes, then on what hardware (board)? Is it only AM SoCs or DM too? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Thu, 16 Jun 2011 13:38:00 +0530 Aneesh V ane...@ti.com wrote: New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' * nand_spl/Makefile builds a generic library with the generic source files at this level. What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. And no, I don't think we can get rid of building the objects separately, and I don't want a situation where #ifdef NAND_SPL is honored in some files but not others. We could perhaps get rid of the symlinking and have the SPL makefile build directly from the source into a different object location, though whether we should depends on whether it actually makes things simpler. 3. Customizability - In the existing scheme what gets built into the SPL for a given board was completely customizable by the board level Makefile. This is a critical feature for a situation where we need to fit in a tiny space and target a variety of different hardware. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? What about when code depends on #defines that are not present for a given target, because that target isn't going to select that file? What about when alternative files have the same function names? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] NAND: Add 16bit NAND support for the NDFC
On Wed, Jun 08, 2011 at 01:29:12PM -0400, Alex Waterman wrote:
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index 9545a9a..1d847ef 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -122,10 +122,15 @@ static int nand_is_bad_block(struct mtd_info *mtd, int
block)
nand_command(mtd, block, 0, CONFIG_SYS_NAND_BAD_BLOCK_POS,
NAND_CMD_READOOB);
/*
- * Read one byte
+ * Read one byte (or two if it's a 16 bit chip).
*/
- if (readb(this-IO_ADDR_R) != 0xff)
- return 1;
+ if (this-chip_options NAND_BUSWIDTH_16){
+ if (readw(this-IO_ADDR_R) != 0x)
+ return 1;
+ } else {
+ if (readb(this-IO_ADDR_R) != 0xff)
+ return 1;
+ }
Configuring for canyonlands_nand - Board: canyonlands, Options:
CANYONLANDS,NAND_U_BOOT,SYS_TEXT_BASE=0x0100
/tmp/u-boot/nand_spl/board/amcc/canyonlands/nand_boot.c: In function
'nand_is_bad_block':
/tmp/u-boot/nand_spl/board/amcc/canyonlands/nand_boot.c:127:10: error: 'struct
nand_chip' has no member named 'chip_options'
Also, space before {
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] misc patches and cleanup
I recently dabbled in u-boot and kept track of a few points I found confusing. I fixed them up to the best of my ability and created some patches for consideration. From 9802439149594948e3862b9609ca0e68ab793ecc Mon Sep 17 00:00:00 2001 From: Christopher Harvey char...@matrox.com Date: Wed, 15 Jun 2011 16:27:07 -0400 Subject: [PATCH 1/3] Added documentation for CONFIG_SYS_TEXT_BASE for ARM. --- README |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/README b/README index 8bb9c8d..f5c59e1 100644 --- a/README +++ b/README @@ -2356,6 +2356,15 @@ Configuration Settings: - CONFIG_SYS_SDRAM_BASE: Physical start address of SDRAM. _Must_ be 0 here. +- CONFIG_SYS_TEXT_BASE: + - ARM: + Is the address of the u-boot code that is loaded in memory. + This value can be in ROM space since u-boot can run from + within ROM. CONFIG_SYS_TEXT_BASE is simply called _TEXT_BASE + in some files, like arch/arm/lib/board.c. + This value has nothing to do with the relocation destination + in RAM. See doc/README.arm-relocation for more info. + - CONFIG_SYS_MBIO_BASE: Physical start address of Motherboard I/O (if using a Cogent motherboard) -- 1.7.0.4 From 538859500db132eea21ace170bfea291501aba09 Mon Sep 17 00:00:00 2001 From: Christopher Harvey char...@matrox.com Date: Wed, 15 Jun 2011 16:28:08 -0400 Subject: [PATCH 2/3] Added extra documentation about how the relocation address to RAM is picked for ARM. --- doc/README.arm-relocation |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/doc/README.arm-relocation b/doc/README.arm-relocation index 5a9a2fb..954627d 100644 --- a/doc/README.arm-relocation +++ b/doc/README.arm-relocation @@ -22,7 +22,7 @@ At cpu level: modify linker file and add a relocation and fixup loop At board level: dram_init(): bd pointer is now at this point not accessible, so only - detect the real dramsize, and store it in gd-ram_size. Bst detected + detect the real dramsize, and store it in gd-ram_size. Best detected with get_ram_size(). TODO: move also dram initialization there on boards where it is possible. @@ -38,6 +38,13 @@ At lib level: Boards which are not fixed to support relocation will be REMOVED! +The code that picks the location in RAM for ARM can be found in the +arch/arm/lib/board.c file under the board_init_f function. +The postfix _f means executed from flash, and _r means from RAM. +The new location is picked with respect to the highest RAM address, and the +exact final value depends heavily on compile time options. The source is the +best documentation here. + - For boards which boot from nand_spl, it is possible to save one copy -- 1.7.0.4 From b6d2012af7730a57272be223eaa2ccc3eeec011c Mon Sep 17 00:00:00 2001 From: Christopher Harvey char...@matrox.com Date: Wed, 15 Jun 2011 16:47:05 -0400 Subject: [PATCH 3/3] Removed unused define, CONFIG_ARMV7. --- include/configs/am3517_crane.h |2 +- include/configs/am3517_evm.h|2 +- include/configs/ca9x4_ct_vxp.h |2 +- include/configs/cm_t35.h|2 +- include/configs/devkit8000.h|2 +- include/configs/dig297.h|2 +- include/configs/igep0020.h |2 +- include/configs/igep0030.h |2 +- include/configs/omap3_beagle.h |2 +- include/configs/omap3_evm.h |2 +- include/configs/omap3_overo.h |2 +- include/configs/omap3_pandora.h |2 +- include/configs/omap3_sdp3430.h |2 +- include/configs/omap3_zoom1.h |2 +- include/configs/omap3_zoom2.h |2 +- include/configs/omap4_panda.h |2 +- include/configs/omap4_sdp4430.h |2 +- include/configs/s5p_goni.h |2 +- include/configs/s5pc210_universal.h |2 +- include/configs/smdkc100.h |2 +- include/configs/smdkv310.h |2 +- 21 files changed, 21 insertions(+), 21 deletions(-) diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 09cb951..b809053 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */ diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 80ad342..db026c4 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -28,7 +28,7 @@ /* * High Level Configuration Options */ -#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */ + #define CONFIG_OMAP 1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX 1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */ diff --git
Re: [U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
Hi Igor, Yes, I have tested this on the AM3715 but not on any other parts. Cheers, Rick On 05/17/11 00:52, r...@efn.org wrote: Signed-off-by: Rick Bronson r...@efn.org --- arch/arm/cpu/armv7/omap-common/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/timer.c b/arch/arm/cpu/armv7/omap-common/timer.c index 9beebb1..3c9d488 100644 --- a/arch/arm/cpu/armv7/omap-common/timer.c +++ b/arch/arm/cpu/armv7/omap-common/timer.c @@ -44,7 +44,7 @@ static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE; */ #define TIMER_CLOCK(V_SCLK / (2 CONFIG_SYS_PTV)) -#define TIMER_LOAD_VAL 0x +#define TIMER_LOAD_VAL 0 /* counter starts from 0 on reload */ Has this been tested? If yes, then on what hardware (board)? Is it only AM SoCs or DM too? -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD Ultimate SATA SD
On Thu, 16 Jun 2011 16:18:46 +0400, Alexei Ozhigov alexei.ozhi...@gmail.com wrote: ... I am experiencing the same problem with SATA right now with v2011.06-rc2 (tried also the latest master). If MVSATA_STATUS_TIMEOUT in mvsata_ide_initialize_port is ignored, SATA drive is found on the second port and I am able to read the drive's content. Inspired by what you say about timeouts, I thought perhaps increasing the timeout from 10ms to 1s might make a difference -- that worked! ... except that now, it's working regardless :-( So, I've no idea if that's really related to what's going on, because I've now gone as far as reducing the timeout to 5ms and it's _still_ working fine, so perhaps some part of the SATA subsystem was in a state that was somehow reset by waiting a bit longer for the startup once, and that's somehow fixed it. It is still working despite powering down the machine for a while, so I'm guessing whatever changed is something to do with the state of the hard drive. Sadly that means that I've now lost the ability to test this, since trying any of the versions that were previously failing now work. Anyway, Alexei, try increasing the timeout (i.e. the value being assigned to timeleft) --- if that works for you too, it seems pretty harmless, so might be appropriate for wider adoption. =-=-=-=- Meanwhile, the SD has reverted to being broken, so that ext2ls just hangs in the read, by the looks of it :-/ Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp61yUPpfCFX.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] NAND: Add 16bit NAND support for the NDFC
From 99efc91f7a3d55bcf0e839ae30c286fd08166010 Mon Sep 17 00:00:00 2001
From: Alex Waterman awater...@dawning.com
Date: Thu, 19 May 2011 15:08:36 -0400
Subject: [PATCH] NAND: Add 16bit NAND support for the NDFC
This patch adds support for 16 bit NAND devices attached to the
NDFC on ppc4xx processors. Two config entries were added:
CONFIG_SYS_NDFC_16- Setting this tells the NDFC that a
16 bit device is attached.
CONFIG_SYS_NDFC_EBC0_CFG - This is for the External Bus
Controller configuration register.
Also, a new ndfc_read_byte() function was added which does not
first convert the data to little endian.
The NAND SPL was also modified to do 16bit bad block testing
when a 16 bit chip is being used.
Signed-off-by: Alex Waterman awater...@dawning.com
---
README |8
drivers/mtd/nand/ndfc.c | 33 +
nand_spl/nand_boot.c| 11 ---
3 files changed, 45 insertions(+), 7 deletions(-)
Changes for v2:
- Changes dynamic checking of chip options field to a compile time
check.
Changes for v3:
- Revert back to dynamic checking of chip-options in the nand_spl
code.
Note:
For now I just went back to dynamic checking in the nand_spl code since
that is easeir. I think its worth using a preprocessor directive to do
this instead but that would require some more thought. Maybe when the next
release is out I can look into that but for now I don't have as much time
as I would
like :(.
Sorry about that, silly typo I missed because I compiled a RAM boot version
of my code not a NAND version. Whoops. This new patch now passes
$ MAKEALL -v amcc
diff --git a/README b/README
index 8bb9c8d..9d33a2e 100644
--- a/README
+++ b/README
@@ -2918,6 +2918,14 @@ Low Level (hardware related) configuration options:
- CONFIG_SYS_SRIOn_MEM_SIZE:
Size of SRIO port 'n' memory region
+- CONFIG_SYS_NDFC_16
+ Defined to tell the NDFC that the NAND chip is using a
+ 16 bit bus.
+
+- CONFIG_SYS_NDFC_EBC0_CFG
+ Sets the EBC0_CFG register for the NDFC. If not defined
+ a default value will be used.
+
- CONFIG_SPD_EEPROM
Get DDR timing information from an I2C EEPROM. Common
with pluggable memory modules such as SODIMMs
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 0729e0c..6ebbb5e 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -37,6 +37,13 @@
#include asm/io.h
#include asm/ppc4xx.h
+#ifndef CONFIG_SYS_NAND_BCR
+#define CONFIG_SYS_NAND_BCR 0x8000
+#endif
+#ifndef CONFIG_SYS_NDFC_EBC0_CFG
+#define CONFIG_SYS_NDFC_EBC0_CFG 0xb840
+#endif
+
/*
* We need to store the info, which chip-select (CS) is used for the
* chip number. For example on Sequoia NAND chip #0 uses
@@ -140,12 +147,25 @@ static int ndfc_verify_buf(struct mtd_info *mtdinfo,
const uint8_t *buf, int len
return 0;
}
-#endif /* #ifndef CONFIG_NAND_SPL */
-#ifndef CONFIG_SYS_NAND_BCR
-#define CONFIG_SYS_NAND_BCR 0x8000
+/*
+ * Read a byte from the NDFC.
+ */
+static uint8_t ndfc_read_byte(struct mtd_info *mtd)
+{
+
+ struct nand_chip *chip = mtd-priv;
+
+#ifdef CONFIG_SYS_NDFC_16BIT
+ return (uint8_t) readw(chip-IO_ADDR_R);
+#else
+ return readb(chip-IO_ADDR_R);
#endif
+}
+
+#endif /* #ifndef CONFIG_NAND_SPL */
+
void board_nand_select_device(struct nand_chip *nand, int chip)
{
/*
@@ -198,16 +218,21 @@ int board_nand_init(struct nand_chip *nand)
nand-ecc.bytes = 3;
nand-select_chip = ndfc_select_chip;
+#ifdef CONFIG_SYS_NDFC_16BIT
+ nand-options |= NAND_BUSWIDTH_16;
+#endif
+
#ifndef CONFIG_NAND_SPL
nand-write_buf = ndfc_write_buf;
nand-verify_buf = ndfc_verify_buf;
+ nand-read_byte = ndfc_read_byte;
chip++;
#else
/*
* Setup EBC (CS0 only right now)
*/
- mtebc(EBC0_CFG, 0xb840);
+ mtebc(EBC0_CFG, CONFIG_SYS_NDFC_EBC0_CFG);
mtebc(PB0CR, CONFIG_SYS_EBC_PB0CR);
mtebc(PB0AP, CONFIG_SYS_EBC_PB0AP);
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index 9545a9a..4683c7c 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -122,10 +122,15 @@ static int nand_is_bad_block(struct mtd_info *mtd, int
block)
nand_command(mtd, block, 0, CONFIG_SYS_NAND_BAD_BLOCK_POS,
NAND_CMD_READOOB);
/*
-* Read one byte
+* Read one byte (or two if it's a 16 bit chip).
*/
- if (readb(this-IO_ADDR_R) != 0xff)
- return 1;
+ if (this-options NAND_BUSWIDTH_16) {
+ if (readw(this-IO_ADDR_R) != 0x)
+ return 1;
+ } else {
+ if (readb(this-IO_ADDR_R) != 0xff)
+ return 1;
+ }
return 0;
}
--
1.7.4.4
--
Alex Waterman
Computer Engineer
Phone:
Re: [U-Boot] SPL framework re-design
Dear Daniel Schwierzeck, In message banlktim9ae2aszklidh53vd+hjpz7gv...@mail.gmail.com you wrote: The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. This is very much wrong. In the general case, you still need relocation (because the final start address of the U-Boot code canonly be determined at runtime), and you definitely need the code in board_init_r(). available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. No. All SPL related stuff should go into spl/ Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is nothing in this world constant but inconstancy. - Swift ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message 4dfa0759.2060...@ti.com you wrote: Can you please extend this to show the SoC/board directories etc. I guess they will go under spl/ and not under each media. Correct, i. e. please add for example: spl/board/freescale/mx31pdk/ spl/board/freescale/mx31pdk/Makefile ... I thought we were going to have cpu directory SoC directory etc in this directory structure. If needed, yes. This example showed a board directory. Can we not use the objects that get normally built, with the existing Makefiles? But where do you add the reference to SoC level and CPU level object files? Which library do you make them part of? I thought the board level Makefile was meant only to build the board specific library. Sorry, I don;t understand your questions (because I don't understand which problem you see). Yes, the board directories will contain only board specific stuff. For example, let's say we have board 'a' and 'b' of same SoC(soc). Unless we have a SoC directory we may have to do something like this. Why should we not have a SoC dir? Also, at least some files will have to be built separately for SPL because they have conditional compilation with CONFIG_PRELOADER kind of flags. Please let's check where this is needed, and how we can handle this. I'd really like to get rid of this symlinking. One case is start.S. We need a simplified start.S for SPL(no relocation, no interrupt handling etc). OK. There are places where CONFIG_PRELOADER is used today. But maybe, these could be avoided it we try. We should carefully check these. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To live is always desirable. -- Eleen the Capellan, Friday's Child, stardate 3498.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Aneesh V, In message 4dfa0be1.4060...@ti.com you wrote: In the last few mails Wolfgang was suggesting re-use of object files themselves, not the source files. In this respect his approach may be different from yours. But I think his objective was to avoid the symbolic link business, which this approach achieves. We may do both. Such files that will compile the same (i. e. where no specific code changes are done depending on CONFIG_PRELOADER or other settings) should re-use the existing object files. Allothers need to be rebuild, obviously. But this is optimization already, which should be done in a second stage. I will not complain when we start with rebuilding all needed objects. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Never underestimate the bandwidth of a station wagon full of tapes. -- Dr. Warren Jackson, Director, UTCS ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
Dear Simon Glass, In message BANLkTinE=tpvzfdbdje5m79wedznfyv...@mail.gmail.com you wrote: Is it possible for U-Boot to use a system similar to Linux from 2.6 where it prints out the full pathname of each file it is building, and doesn't change in and out of directories as it builds. Perhaps including the subdirectory Makefiles instead using make -C? I haven't looked at how Linux does it. Is there some reason U-Boot cannot / should not do the same? Of course we can have that - if somebody submits patches for it. But please note that I think that the Linux implementation sucks, and ditto for all other projects that copied this method. I think it is fundamentally wrong to implement such a feature (let's call it terse make output) in the Makefiles of many projects, using a lot of trickery and magic. If a specific verbosity of make output is needed, this should most naturally be implemented as a feature in make itself - we already have make options like -d (for very verbose output) or -s (for silent mode), so why not add a new verbosity level which produces exactly the short output format you want? So yes, patches are welcome, but these should go directly to the make mailing lists / patch system, see http://savannah.gnu.org/mail/?group=make Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Anything that is worth doing at all is worth doing well. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Scott Wood, In message 20110616114556.7d3c2...@schlenkerla.am.freescale.net you wrote: What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. I think there is tons of duplicated code that could and should be extraced into common directories. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. Or put this from the head on it's feet and use a board specific config.mk which gets included by the SPL makefile? We could perhaps get rid of the symlinking and have the SPL makefile build directly from the source into a different object location, though whether we should depends on whether it actually makes things simpler. Agreed. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? What about when code depends on #defines that are not present for a given target, because that target isn't going to select that file? What about when alternative files have the same function names? What do you mean? When a target does not select (and thus build) a file, then it does not matter which #defines are in there or not - they don't get build anyway. If files which export the same funcktion names get linked together we have an error somewhere that needs to be fixed - but this is not a new issue, this situation is the same now already. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I dislike companies that have a we-are-the-high-priests-of-hardware- so-you'll-like-what-we-give-you attitude. I like commodity markets in which iron-and-silicon hawkers know that they exist to provide fast toys for software types like me to play with...- Eric S. Raymond ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] misc patches and cleanup
Dear Christopher Harvey, In message 4dfa4764.9040...@matrox.com you wrote: I recently dabbled in u-boot and kept track of a few points I found confusing. I fixed them up to the best of my ability and created some patches for consideration. Please read http://www.denx.de/wiki/U-Boot/Patches These patches must be submitted one by one, each in a separate message. Make sure to provide useful commit messages that explain what you are doing and why, and make sure to include your signed-off-by lines. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A wise person makes his own decisions, a weak one obeys public opinion. -- Chinese proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Fri, 17 Jun 2011 00:09:00 +0200 Wolfgang Denk w...@denx.de wrote: Dear Scott Wood, In message 20110616114556.7d3c2...@schlenkerla.am.freescale.net you wrote: What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. I think there is tons of duplicated code that could and should be extraced into common directories. There's some, but really not that much that I can see. A handful of lines for putc/puts. Some similar but not identical board init code within a board family. Extracting duplicated code into files in the common directories, which can be picked up by the targets that want them, can be done without significant changes to the makefile structure. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. Or put this from the head on it's feet and use a board specific config.mk which gets included by the SPL makefile? That's a little less flexible, but probably OK. That's no longer the case with the proposed scheme. Source files and Makefiles in the generic and CPU directory are shared by many boards. How do we allow customizability for individual boards. using CONFIG_ flags? This may be needed for the boards to make the right trade-offs based SRAM budget/requirements etc. Maybe, --gc-sections and -ffunction-sections help in dealing with this? What about when code depends on #defines that are not present for a given target, because that target isn't going to select that file? What about when alternative files have the same function names? What do you mean? When a target does not select (and thus build) a file, then it does not matter which #defines are in there or not - they don't get build anyway. That's currently how it works, but it appeared that a suggestion was being made to build certain code as a library before getting to what the target wants. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
Wolfgang Denk w...@denx.de writes: Dear Simon Glass, In message BANLkTinE=tpvzfdbdje5m79wedznfyv...@mail.gmail.com you wrote: Is it possible for U-Boot to use a system similar to Linux from 2.6 where it prints out the full pathname of each file it is building, and doesn't change in and out of directories as it builds. Perhaps including the subdirectory Makefiles instead using make -C? I haven't looked at how Linux does it. Is there some reason U-Boot cannot / should not do the same? Of course we can have that - if somebody submits patches for it. But please note that I think that the Linux implementation sucks, and ditto for all other projects that copied this method. I think it is fundamentally wrong to implement such a feature (let's call it terse make output) in the Makefiles of many projects, using a lot of trickery and magic. Aside from the pros and cons of the terse output, getting rid of the recursive makefiles should speed up the u-boot build dramatically. In a typical build, it spends a huge amount of time going in and out of directories only to determine there was nothing to do. No, I'm not volunteering to rewrite the makefiles. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 0/2] GPIO: Tegra2: add GPIO driver for Tegra2
This patchset adds a GPIO driver for Tegra2 SoC, and enables it for all boards Changes in V2: - use 'gpio_pin' enum in gpio.h (Simon Glass review request) - change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request) - change 'offset' to 'pin' globally - enable GPIO for all boards (tegra2-common.h) Changes in V3: - use common cmd_gpio; remove redundant cmd processing code - add gpio_request, gpio_free and gpio_toggle - alias 'gpio_status' to 'gpio_info' for use in cmd_gpio Changes in V4: - update code as per Mike Frysinger's review comments - rewrite gpio_info, aka gpio_status Tom Warren (2): GPIO: Tegra2: add GPIO driver for Tegra2 arm: Tegra2: GPIO: enable GPIO for Tegra2 boards arch/arm/include/asm/arch-tegra2/gpio.h | 250 +-- arch/arm/include/asm/gpio.h | 38 + drivers/gpio/Makefile |1 + drivers/gpio/tegra2_gpio.c | 254 +++ include/configs/tegra2-common.h |2 + 5 files changed, 535 insertions(+), 10 deletions(-) create mode 100644 arch/arm/include/asm/gpio.h create mode 100644 drivers/gpio/tegra2_gpio.c -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 2/2] arm: Tegra2: GPIO: enable GPIO for Tegra2 boards
Signed-off-by: Tom Warren twar...@nvidia.com --- Changes in V2: - enable GPIO for all boards (tegra2-common.h) Changes in V3: - enable use of common cmd_gpio include/configs/tegra2-common.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h index febce35..295ee11 100644 --- a/include/configs/tegra2-common.h +++ b/include/configs/tegra2-common.h @@ -160,4 +160,6 @@ CONFIG_SYS_INIT_RAM_SIZE - \ GENERATED_GBL_DATA_SIZE) +#define CONFIG_TEGRA2_GPIO +#define CONFIG_CMD_GPIO #endif /* __TEGRA2_COMMON_H */ -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Signed-off-by: Tom Warren twar...@nvidia.com
---
Changes in V2:
- use 'gpio_pin' enum in gpio.h (Simon Glass review request)
- change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request)
- change 'offset' to 'pin' globally
Changes in V3:
- use common cmd_gpio; remove redundant cmd processing code
- add gpio_request, gpio_free and gpio_toggle
- alias 'gpio_status' to 'gpio_info' for use in cmd_gpio
Changes in V4:
- update code as per Mike Frysinger's review comments
- rewrite gpio_info, aka gpio_status
arch/arm/include/asm/arch-tegra2/gpio.h | 250 +--
arch/arm/include/asm/gpio.h | 38 +
drivers/gpio/Makefile |1 +
drivers/gpio/tegra2_gpio.c | 254 +++
4 files changed, 533 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/gpio.h
create mode 100644 drivers/gpio/tegra2_gpio.c
diff --git a/arch/arm/include/asm/arch-tegra2/gpio.h
b/arch/arm/include/asm/arch-tegra2/gpio.h
index 0fb8f0d..41e66fe 100644
--- a/arch/arm/include/asm/arch-tegra2/gpio.h
+++ b/arch/arm/include/asm/arch-tegra2/gpio.h
@@ -23,11 +23,13 @@
#define _TEGRA2_GPIO_H_
/*
- * The Tegra 2x GPIO controller has 222 GPIOs arranged in 8 banks of 4 ports,
+ * The Tegra 2x GPIO controller has 224 GPIOs arranged in 7 banks of 4 ports,
* each with 8 GPIOs.
*/
-#define TEGRA_GPIO_PORTS 4 /* The number of ports per bank */
-#define TEGRA_GPIO_BANKS 8 /* The number of banks */
+#define TEGRA_GPIO_PORTS 4 /* number of ports per bank */
+#define TEGRA_GPIO_BANKS 7 /* number of banks */
+#define MAX_NUM_GPIOS (TEGRA_GPIO_PORTS * TEGRA_GPIO_BANKS * 8)
+#define GPIO_NAME_SIZE 20 /* gpio_request max label len */
/* GPIO Controller registers for a single bank */
struct gpio_ctlr_bank {
@@ -45,15 +47,243 @@ struct gpio_ctlr {
struct gpio_ctlr_bank gpio_bank[TEGRA_GPIO_BANKS];
};
-#define GPIO_BANK(x) ((x) 5)
-#define GPIO_PORT(x) (((x) 3) 0x3)
-#define GPIO_BIT(x)((x) 0x7)
+#define GPIO_BANK(x) ((x) 5)
+#define GPIO_PORT(x) (((x) 3) 0x3)
+#define GPIO_FULLPORT(x) ((x) 3)
+#define GPIO_BIT(x)((x) 0x7)
+
+enum gpio_pin {
+ GPIO_PA0 = 0, /* pin 0 */
+ GPIO_PA1,
+ GPIO_PA2,
+ GPIO_PA3,
+ GPIO_PA4,
+ GPIO_PA5,
+ GPIO_PA6,
+ GPIO_PA7,
+ GPIO_PB0, /* pin 8 */
+ GPIO_PB1,
+ GPIO_PB2,
+ GPIO_PB3,
+ GPIO_PB4,
+ GPIO_PB5,
+ GPIO_PB6,
+ GPIO_PB7,
+ GPIO_PC0, /* pin 16 */
+ GPIO_PC1,
+ GPIO_PC2,
+ GPIO_PC3,
+ GPIO_PC4,
+ GPIO_PC5,
+ GPIO_PC6,
+ GPIO_PC7,
+ GPIO_PD0, /* pin 24 */
+ GPIO_PD1,
+ GPIO_PD2,
+ GPIO_PD3,
+ GPIO_PD4,
+ GPIO_PD5,
+ GPIO_PD6,
+ GPIO_PD7,
+ GPIO_PE0, /* pin 32 */
+ GPIO_PE1,
+ GPIO_PE2,
+ GPIO_PE3,
+ GPIO_PE4,
+ GPIO_PE5,
+ GPIO_PE6,
+ GPIO_PE7,
+ GPIO_PF0, /* pin 40 */
+ GPIO_PF1,
+ GPIO_PF2,
+ GPIO_PF3,
+ GPIO_PF4,
+ GPIO_PF5,
+ GPIO_PF6,
+ GPIO_PF7,
+ GPIO_PG0, /* pin 48 */
+ GPIO_PG1,
+ GPIO_PG2,
+ GPIO_PG3,
+ GPIO_PG4,
+ GPIO_PG5,
+ GPIO_PG6,
+ GPIO_PG7,
+ GPIO_PH0, /* pin 56 */
+ GPIO_PH1,
+ GPIO_PH2,
+ GPIO_PH3,
+ GPIO_PH4,
+ GPIO_PH5,
+ GPIO_PH6,
+ GPIO_PH7,
+ GPIO_PI0, /* pin 64 */
+ GPIO_PI1,
+ GPIO_PI2,
+ GPIO_PI3,
+ GPIO_PI4,
+ GPIO_PI5,
+ GPIO_PI6,
+ GPIO_PI7,
+ GPIO_PJ0, /* pin 72 */
+ GPIO_PJ1,
+ GPIO_PJ2,
+ GPIO_PJ3,
+ GPIO_PJ4,
+ GPIO_PJ5,
+ GPIO_PJ6,
+ GPIO_PJ7,
+ GPIO_PK0, /* pin 80 */
+ GPIO_PK1,
+ GPIO_PK2,
+ GPIO_PK3,
+ GPIO_PK4,
+ GPIO_PK5,
+ GPIO_PK6,
+ GPIO_PK7,
+ GPIO_PL0, /* pin 88 */
+ GPIO_PL1,
+ GPIO_PL2,
+ GPIO_PL3,
+ GPIO_PL4,
+ GPIO_PL5,
+ GPIO_PL6,
+ GPIO_PL7,
+ GPIO_PM0, /* pin 96 */
+ GPIO_PM1,
+ GPIO_PM2,
+ GPIO_PM3,
+ GPIO_PM4,
+ GPIO_PM5,
+ GPIO_PM6,
+ GPIO_PM7,
+ GPIO_PN0, /* pin 104 */
+ GPIO_PN1,
+ GPIO_PN2,
+ GPIO_PN3,
+ GPIO_PN4,
+ GPIO_PN5,
+ GPIO_PN6,
+ GPIO_PN7,
+ GPIO_PO0, /* pin 112 */
+ GPIO_PO1,
+ GPIO_PO2,
+ GPIO_PO3,
+ GPIO_PO4,
+ GPIO_PO5,
+ GPIO_PO6,
+ GPIO_PO7,
+ GPIO_PP0, /* pin 120 */
+ GPIO_PP1,
+ GPIO_PP2,
+ GPIO_PP3,
+ GPIO_PP4,
+ GPIO_PP5,
+ GPIO_PP6,
+ GPIO_PP7,
+ GPIO_PQ0, /* pin 128 */
+ GPIO_PQ1,
+
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Hi Wolfgang, On Thu, Jun 16, 2011 at 9:46 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message 4df9e409.1060...@gmail.com you wrote: is equivalent except that, as already pointed out, clrsetbits and friends: a) Are not portable because only ARM and PPC define them which makes them, by definition, non-standard Agreed - As mentioned in another post, I will look to implement clrsetbits and friends in x86 at some point They should be added to _any_ arch/arch/include/asm/io.h that doesn't use them yet. b) Each invocation results in a read barrier plus a write barrier ...which is intentionally (actually mandatory) when accessing I/O memory, and negligable overhead on plain memory. Agreed - The raw performance overhead of the barriers is most likely negligible, although is there possibly a cache flush/sync operation or flush of the predictive branch cache that could have a more significant impact? I don't see this as such a huge problem since clrsetbits is (usually) used to update hardware registers, any flush will happen anyway c) If the hardware register is sensitive to partial updates (i.e. requires all bit-fields to be updated in on operation) this requires a read into a local variable, calls to clrsetbits against that variable and finally a write-back - Lots of memory barriers Wrong. The macro does this automatically. There is only a single read and a single write per call. I mean: clrsetbits(foo_reg, foo_val_1, foo_val_1_mask); clrsetbits(foo_reg, foo_val_2, foo_val_2_mask); clrsetbits(foo_reg, foo_val_3, foo_val_3_mask); This could cause side-effects if foo_reg is sensitive to the three foo_val's being set independently. To ensure all three values are updated in a single write to foo_reg you would need to do: foo_tmp = readl(foo_reg); clrsetbits(foo_tmp, foo_val_1, foo_val_1_mask); clrsetbits(foo_tmp, foo_val_2, foo_val_2_mask); clrsetbits(foo_tmp, foo_val_3, foo_val_3_mask); foo_tmp = writel(foo_tmp, foo_reg); Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
On Thursday, June 16, 2011 19:51:33 Tom Warren wrote:
+int gpio_request(int gp, const char *label)
+{
+ if (gp = MAX_NUM_GPIOS)
+ return -1;
+
+ strncpy(gpio_names[gp].name, label, GPIO_NAME_SIZE);
if the label is =GPIO_NAME_SIZE, the result will not be NUL terminated. i'd
suggest you add something like this to after the strncpy call:
gpio_names[gp].name[GPIO_NAME_SIZE - 1] = '\0';
+ return (val GPIO_BIT(gp)) 1;
could be written as !!(val GPIO_BIT(gp)), but up to you, or see how the
code size works out
otherwise, looks fine. not that i looked too closely as i dont know anything
about Tegra2 parts.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
On Thursday, June 16, 2011 18:03:07 Wolfgang Denk wrote: Simon Glass wrote: Is it possible for U-Boot to use a system similar to Linux from 2.6 where it prints out the full pathname of each file it is building, and doesn't change in and out of directories as it builds. Perhaps including the subdirectory Makefiles instead using make -C? I haven't looked at how Linux does it. Is there some reason U-Boot cannot / should not do the same? Of course we can have that - if somebody submits patches for it. this sounds ambiguous ... i think you mean no, this isnt going into u-boot, but people can submit patches to other projects like GNU make. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Mike,
On Thu, Jun 16, 2011 at 5:06 PM, Mike Frysinger vap...@gentoo.org wrote:
On Thursday, June 16, 2011 19:51:33 Tom Warren wrote:
+int gpio_request(int gp, const char *label)
+{
+ if (gp = MAX_NUM_GPIOS)
+ return -1;
+
+ strncpy(gpio_names[gp].name, label, GPIO_NAME_SIZE);
if the label is =GPIO_NAME_SIZE, the result will not be NUL terminated. i'd
suggest you add something like this to after the strncpy call:
gpio_names[gp].name[GPIO_NAME_SIZE - 1] = '\0';
Will do. Thanks for the quick response!
+ return (val GPIO_BIT(gp)) 1;
could be written as !!(val GPIO_BIT(gp)), but up to you, or see how the
code size works out
I'll check it and update if your way is smaller. Thanks.
otherwise, looks fine. not that i looked too closely as i dont know anything
about Tegra2 parts.
-mike
Thanks,
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nested Makefiles
On Thursday, June 16, 2011 19:03:21 Måns Rullgård wrote: Aside from the pros and cons of the terse output, getting rid of the recursive makefiles should speed up the u-boot build dramatically. In a typical build, it spends a huge amount of time going in and out of directories only to determine there was nothing to do. indeed. it shouldnt be that bad now that more stuff has converted to FOO-$(CONFIG) syntax. it could probably even be done piece by piece rather than the whole tree to make transition easier. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Possible bug in UBIFS function ubifs_finddir
All, Hello again it has been a while since I was here. I am working on u-boot once again and think I may have found a bug in the UBIFS sub-system. The function is ubifs_finddir and the issue is that there seems to be a free of a pointer in a structure that has already been freed. This is causing the free function to rightly crash. The code is in the error path of the ubifs_finddir at the end of the function line 363: if (file) free(file); if (dentry) free(dentry); if (dir) free(dir); if (file-private_data) kfree(file-private_data); file-private_data = NULL; file-f_pos = 2; The issue is that we are free'ing the file pointer at the top of this block and then trying to free the private_data element after the base pointer. I will fix and send a patch but before I do I just wanted to make sure I was not missing the obvious. Has this been discussed before and is there already a patch? Regards, Rod Boyce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uncompressed uImages
On Wednesday, June 15, 2011 13:00:32 David Peverley wrote: I've got an interesting issue with a MIPS board I'm working on. The uncompressed uImage has been created with a Load Address of 0x8050 and an Entry Point of 0x80504590. This gets TFTP's into RAM at 0x8055b728. if it's uncompressed, why not simply load it to the final address in the first place ? then bootm wont have to do any memcpy, it can simply jump to the entry point. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10] Add support for Network Space v2 and parents
On Wednesday, June 15, 2011 10:39:53 Simon Guinot wrote: Hi Prafulla, please dont top post It appears that this v10 patch is also wrong. The specified email encoding is UTF-8. It should be ISO-8859-1 which is the MAINTAINERS file encoding. It is the reason why the patch is discarded by patchwork. Please note that the patch diff is correct. The patch applies correctly using git-am. Let me know if a v11 is needed ? if it isnt making it to the mailing list, then yes. i didnt actually see any v10 patch hit the mailing list, and i dont think that has anything to do with encoding or patchwork. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] About the CRC of u-boot.bin
On Monday, June 13, 2011 04:11:57 Andreas Bießmann wrote: The build-timestamp is an quite usable parameter, if it is configurable it should be opt-out. goes without saying When I looked for the char *version_string I found out this is defined in respective architecture board.c. Shouldn't this be defined somewhere else to have always the same string? feel free to submit a patch. there is a lot of logic in arch/*/lib/board.c that should be unified. also, please fix your e-mail client to properly wrap long lines -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: add erase function to both mmc and sd
On Thursday, June 16, 2011 09:47:56 Lei Wen wrote:
+ } else if (strcmp(argv[1], erase) == 0) {
+ u32 cnt = simple_strtoul(argv[3], NULL, 16);
+ u32 n;
+ struct mmc *mmc = find_mmc_device(dev);
+
+ int blk = simple_strtoul(argv[2], NULL, 16);
+
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, curr_device);
+ return 1;
+ }
+
+ printf(\nMMC erase: dev # %d, block # %d, count %d ... ,
+ curr_device, blk, cnt);
+
+ mmc_init(mmc);
this logic really needs to get cleaned up rather than every sub-mmc command
doing the same thing over and over ...
+ printf(mmc erase failed\n\r);
no output strings should include \r in them
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: add erase function to both mmc and sd
Hi Mike,
On Fri, Jun 17, 2011 at 8:57 AM, Mike Frysinger vap...@gentoo.org wrote:
On Thursday, June 16, 2011 09:47:56 Lei Wen wrote:
+ } else if (strcmp(argv[1], erase) == 0) {
+ u32 cnt = simple_strtoul(argv[3], NULL, 16);
+ u32 n;
+ struct mmc *mmc = find_mmc_device(dev);
+
+ int blk = simple_strtoul(argv[2], NULL, 16);
+
+ if (!mmc) {
+ printf(no mmc device at slot %x\n, curr_device);
+ return 1;
+ }
+
+ printf(\nMMC erase: dev # %d, block # %d, count %d ... ,
+ curr_device, blk, cnt);
+
+ mmc_init(mmc);
this logic really needs to get cleaned up rather than every sub-mmc command
doing the same thing over and over ...
Agree, I would sort it out as a seperate patch.
+ printf(mmc erase failed\n\r);
no output strings should include \r in them
Opps... I would correct that.
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MMC: add erase function to both mmc and sd
On Thursday, June 16, 2011 23:09:40 Lei Wen wrote: On Fri, Jun 17, 2011 at 8:57 AM, Mike Frysinger wrote: this logic really needs to get cleaned up rather than every sub-mmc command doing the same thing over and over ... Agree, I would sort it out as a seperate patch. thanks. this further will implicitly force consistency across the sub- commands. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
