Re: [U-Boot] [PATCH v2] Add a CBFS driver and commands to u-boot
Dear Gabe Black,
In message CAPPXG1nqDa_UgZsJx_g_RDCQOfJLjM=zak5k7w9pgcsrrc9...@mail.gmail.com
you wrote:
WARNING: do not add new typedefs
#853: FILE: include/cbfs.h:61:
+typedef const struct cbfs_cache_node *cbfs_file;
This typedef is to create an opaque handle for CBFS files. If you look here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle
In chapter 5 in the list of acceptable uses for typedefs, creating an
opaque type is item a. This use of typedef is consistent with the Linux
coding standards as described in that document and functionally important
for this change and should stay.
Sorry, but you have to explain this better to me.
What would be wrong with using struct cbfs_cache_node * ?
And what of this exactly is functionally important here?
While we are quoting the CodingStyle, we should also code the next
lines:
NOTE! Opaqueness and accessor functions are not good in
themselves.
Why do you think it is needed here?
+ if (file_cbfs_result != CBFS_SUCCESS) {
+ printf(%s.\n, file_cbfs_error());
Use
puts(file_cbfs_error());
?
That would leave out the \n. Whatever came next (like the prompt) would
continue on the same line which would be wrong.
It appears your only use of file_cbfs_error() is in such constructs,
so just change file_cbfs_error() to include the newline. There is
only a single call that doesn't really fit:
+ if (file_cbfs_result == CBFS_FILE_NOT_FOUND)
===+ printf(%s: %s\n, file_cbfs_error(), argv[2]);
+ else
+ printf(%s.\n, file_cbfs_error());
but that would be better written with arguments swapped anyway:
printf(%s: %s, argv[2], file_cbfs_error());
While we are at it: for consistent style, please also omit the
trailing '.' in all such output.
Actually you can then even simplify the code:
if (file_cbfs_result == CBFS_FILE_NOT_FOUND)
printf(%s: argv[2]);
puts(file_cbfs_error());
+ if (type_name)
+ printf( %16s, type_name);
+ else
+ printf( %16d, type);
This is probably confusing to the user. How can he know if the file
type has the numerical value of 123 or if the file name is 123 ?
This isn't file name, it's the file type. No file type is named after a
number. There are also labels on the columns indicating which is which.
Please explain the meaning of this numeric versus string value is,
then, and how the user is supposed to understand when he sees a string
and when a numeric value.
+ if (filename[0])
+ printf( %s\n, filename);
+ else
+ printf( %s\n, (empty));
Use puts().
The first one can't be a puts, it would have to be three. That's a lot of
clutter to avoid a slight performance penalty when interacting with a human
that won't notice such a tiny delay anyway. The second one could be a puts,
but that would make the two branches of the if uneven. I'll change the
second one.
Come on. It this really that difficlt? How about:
puts( );
puts(filename[0] ? filename : (empty));
I put newlines there because the FAT commands do, and I have no problem
removing them. You may want to look at the other commands and remove them
there too.
Patches are welcome.
Readability? I don't care that much one way or the other though. I'll
change it.
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
How many hardware guys does it take to change a light bulb? Well the
diagnostics say it's fine buddy, so it's a software problem.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-video/master
Dear Anatolij Gustschin, In message 20111205233532.125ce470@wker you wrote: Hello Wolfgang, The following changes since commit 7708d8b352e9e595f6f08afd3206af6495c7dc09: Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2011-12-02 00:17:49 +0100) are available in the git repository at: git://git.denx.de/u-boot-video.git master Gabe Black (1): video: cfb_console: Make the software cursor non-destructive drivers/video/cfb_console.c | 109 +-- 1 files changed, 53 insertions(+), 56 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de What the gods would destroy they first submit to an IEEE standards committee. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/7] reboard: Introduce generic relocation feature
Hi Simon, Le 22/11/2011 00:57, Simon Glass a écrit : This is the second patch series aiming to unify the various board.c files in each architecture into a single one. This series creates a libboard library and implements relocation in it. It then moves ARM over to use this framework, as an example. On ARM the relocation code is duplicated for each CPU yet it is the same. We can bring this up to the arch level. But since (I believe) Elf relocation is basically the same process for all archs, there is no reason not to bring it up to the generic level. Agreed. This series establishes a new libboard library in the board/ subdir and puts some relocation code in it. Each architecture which uses this framework needs to provide a function called arch_elf_relocate_entry() which processes a single relocation entry. If there is concern about calling a function for all 2000-odd relocations then I can change this. NAK -- a generic relocation function should be not be in board/, it should be in lib/ For ARM, a new arch/arm/lib/proc.S file is created, which holds generic ARM assembler code (things that cannot be written in C and are common functions used by all ARM CPUs). This helps reduce duplication. Interrupt handling code and perhaps even some startup code can move there later. As commented in detail, I am not sure creating a function for three asm instructions is worthwhile. The overhead for calling the code might be bigger than the body of the function. Did you compare with inline functions with asm statements and/or intrinsics? It may be useful for other architectures to have a similar file. This series moves ARM over to use this framework. Overall this means that two new files are required 'early' in boot: board/reloc.c and arch/arm/lib/proc.S. This is tricky mainly due to SPL. Can you develop what the issue is with SPL exactly? I believe that we may need to adjust link scripts to put these two files early in the link scripts also. But I am not sure about this and can't actually find a problem as yet. I would much prefer to solve this with a new section name like .text.early if we can. (I should really cc all arch maintainers but I think in that case I get an error from the list server. Not sure what the limit is.) This would not cause an error, but Wolfgang would have to OK' the post, which is a good thing if many people are involved. :) Comments please... Generic comment is that the patch is not about generic *board*. It is about generic *relocation*, which is not a thing of boards IMO: it is not related to peripheral or HW configuration, and is not actually memory-mapped related. Other than that, as stated in the detailed answers, we need to keep the relocation code as efficient as possible. As happy as I am to see the ELF relocation code rewritten in C for easy understanding and maintenance, I would not want it done at the expense of speed or overall architecture soundness. So: - the C relocation code (both the generic function and the ELF specific code) are neither board-related nor ARM-specific, so it has no reason to reside in board/ or arch/arm. My first reflex was lib/, but indeed common/ might be a better place. - the relocation function should be as efficient as possible. Compared numbers between 'before' and 'after' should also be provided -- I do not necessarily expect the same or better performance, but we need to assess what the performance issue is. - I would prefer each patch to be as self-contained as possible -- 'preparatory' patches I don't like much. For instance, to relace ASM relocation with C relocation, I would want a single patch introducing the C code and removing the ASM code or moving it out of the way. - I am not sure why the code should be early or, more precisely, should be specifically located in the linker file: any code in there is accessible at any time, and the only special case is for _start because we want it to be first in placement, not in time. Can you clarify this 'early' issue? - indeed I would prefer a weak symbol for the relocation function. This would allow a given config to easily override the generic C code if needed. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Add a CBFS driver and commands to u-boot
On Wed, Dec 7, 2011 at 3:03 AM, Wolfgang Denk w...@denx.de wrote: Dear Gabe Black, In message 1323214584-11635-1-git-send-email-gabebl...@chromium.org you wrote: Coreboot uses a very simple file system called CBFS to keep track of and allow access to multiple files in a ROM image. This change adds CBFS support and some commands to use it to u-boot. These commands are: cbfsinit - Initialize CBFS support and pull all metadata into RAM. The end of the ROM is an optional parameter which defaults to the standard 0x and can be used to support multiple CBFSes in a system. The last one set up with cbfsinit is the one that will be used. cbfsinfo - Print information from the CBFS header. cbfsls - Print out the size, type, and name of all the files in the current CBFS. Recognized types are translated into symbolic names. cbfsload - Load a file from CBFS into memory. Like the similar command for fat filesystems, you can optionally provide a maximum size. Also, if u-boot needs something out of CBFS very early before the heap is configured, it won't be able to use the normal CBFS support which caches some information in memory it allocates from the heap. This change adds a new cbfs_file_find_uncached function which searchs a CBFS instance without touching the heap. Support for CBFS is compiled in when the CONFIG_CMD_CBFS option is specified. Signed-off-by: Gabe Black gabebl...@chromium.org See previous message. Could you be more specific? Gabe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
On 28/11/2011 17:37, Ilya Yanok wrote: Currently nand_spl_simple puts it's temp data at 0x1 offset in SDRAM which is likely to contain already loaded data. I can't see any way to determine some safe address automagically so make it up to board porter to provide the safe-to-use address via CONFIG_SPL_NAND_WORKSPACE value. Signed-off-by: Ilya Yanok ya...@emcraft.com --- drivers/mtd/nand/nand_spl_simple.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/nand_spl_simple.c b/drivers/mtd/nand/nand_spl_simple.c index ed821f2..70f3cfe 100644 Hi Ilya, --- a/drivers/mtd/nand/nand_spl_simple.c +++ b/drivers/mtd/nand/nand_spl_simple.c @@ -199,8 +199,13 @@ static int nand_read_page(int block, int page, void *dst) /* No malloc available for now, just use some temporary locations * in SDRAM + * Please provide some safe value for CONFIG_SPL_NAND_WORKSPACE in + * your board configuration, this is just a guess!! */ - ecc_calc = (u_char *)(CONFIG_SYS_SDRAM_BASE + 0x1); +#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE(CONFIG_SYS_SDRAM_BASE + 0x1) +#endif Maybe it is better to not have a default value somewhere in the SDRAM and to get a compile error. If we do not want to fix also the related boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...). Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 0/6] Add an SPL to boot the da850evm from SPI
Hi Tom,
On Tue, Dec 6, 2011 at 11:17 PM, Tom Rini tom.r...@gmail.com wrote:
On Tue, Dec 6, 2011 at 10:34 AM, Tom Rini tom.r...@gmail.com wrote:
[...]
OK, thanks, I'll chalk it up to my toolchain then.
After talking with Wolfgang and Albert, we (OK, Wolfgang) found that
ELDK 4.2 toolchain also shows this issue, so please grab that and
figure out what's going on here. Thanks!
With ELDK 4.2 I got the same error message:
arm-linux-ld: error: no memory region specified for loadable section
`.ARM.exidx'
In my linker script for the SPL (board/davinci/da8xxevm/u-boot-spl.lds) no
such section is defined. But somehow the linker in the Codesourcery
toolchain that I used before manages to place the .ARM.exidx section
between rodata and data automatically (The section is listed in the
corresponding .map file). However, with the ELDK 4.2 toolchain this section
(and the .got section) must be specified explicitly. With the patch below
(applied on top of the patchset) the SPL builds and links nicely with
both ELDK 4.2 and the Codesourcery toolchain.
Tom, could you please try if that works for your toolchain?
I don't know much about linker scripts, so my question is: Is this
the right way to solve this problem?
Thanks, Christian
---
board/davinci/da8xxevm/u-boot-spl.lds |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/board/davinci/da8xxevm/u-boot-spl.lds
b/board/davinci/da8xxevm/u-boot-spl.lds
index 6f6e065..1ba0a59 100644
--- a/board/davinci/da8xxevm/u-boot-spl.lds
+++ b/board/davinci/da8xxevm/u-boot-spl.lds
@@ -44,6 +44,8 @@ SECTIONS
. = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(.rodata*)) } .sram
+ .ARM.exidx : { *(.ARM.exidx*) } .sram
+ .got : { *(.got*) } .sram
. = ALIGN(4);
.data : { *(SORT_BY_ALIGNMENT(.data*)) } .sram
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] 5PC2XX: Rename S5pc2XX to exynos
As per new naming convention for Samsung SoC's, all Cortex-A9 and Cortex-A15
based SoC's will be classified under the name Exynos. Cortex-A9 and Cortex-A15
based SoC's will be sub-classified as Exynos4 and Exynos5 respectively.
In order to better adapt and reuse code across various upcoming Samsung Exynos
based boards, all uses of s5pc210 prefix/suffix/directory-names are renamed in
this patch. s5pc210 is renamed as exynos4210 and S5PC210/s5pc210 suffix/prefix
are renamed as exynos4/EXYNOS4.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes for v2:
- Removed renaming of s5p-common to exynos4-common
- Renamed s5pc210 prefixes to exynos4210
Changes for v3:
- Dropped number 4 in exenos4.
Rebased on following commit.
19cdfd3e84bff108febb127b598ac3f1634c768c
Ethernut 5 board support
MAINTAINERS|6 +-
Makefile |2 +-
arch/arm/cpu/armv7/{s5pc2xx = exynos}/Makefile|0
arch/arm/cpu/armv7/{s5pc2xx = exynos}/clock.c | 50
arch/arm/cpu/armv7/{s5pc2xx = exynos}/soc.c |0
.../asm/{arch-s5pc2xx = arch-exynos}/adc.h|0
.../asm/{arch-s5pc2xx = arch-exynos}/clk.h|0
.../asm/{arch-s5pc2xx = arch-exynos}/clock.h |2 +-
.../asm/{arch-s5pc2xx = arch-exynos}/cpu.h| 64 ++--
.../asm/{arch-s5pc2xx = arch-exynos}/gpio.h | 28
.../asm/{arch-s5pc2xx = arch-exynos}/mmc.h|0
.../asm/{arch-s5pc2xx = arch-exynos}/pwm.h|0
.../asm/{arch-s5pc2xx = arch-exynos}/sromc.h |0
.../asm/{arch-s5pc2xx = arch-exynos}/sys_proto.h |0
.../asm/{arch-s5pc2xx = arch-exynos}/uart.h |0
board/samsung/origen/lowlevel_init.S | 26
board/samsung/origen/mem_setup.S | 12 ++--
board/samsung/origen/origen.c |8 +-
board/samsung/origen/origen_setup.h|8 +-
board/samsung/smdkv310/lowlevel_init.S | 22
board/samsung/smdkv310/mem_setup.S |8 +-
board/samsung/smdkv310/smdkv310.c |8 +-
board/samsung/universal_c210/lowlevel_init.S | 24
board/samsung/universal_c210/universal.c |8 +-
boards.cfg |6 +-
include/configs/origen.h |6 +-
include/configs/s5pc210_universal.h| 10 ++--
include/configs/smdkv310.h |6 +-
28 files changed, 152 insertions(+), 152 deletions(-)
rename arch/arm/cpu/armv7/{s5pc2xx = exynos}/Makefile (100%)
rename arch/arm/cpu/armv7/{s5pc2xx = exynos}/clock.c (81%)
rename arch/arm/cpu/armv7/{s5pc2xx = exynos}/soc.c (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/adc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/clk.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/clock.h (99%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/cpu.h (64%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/gpio.h (84%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/mmc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/pwm.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/sromc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/sys_proto.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx = arch-exynos}/uart.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 37bbb34..d493e4e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -691,12 +691,12 @@ Minkyu Kang mk7.k...@samsung.com
SMDKC100ARM ARMV7 (S5PC100 SoC)
s5p_goniARM ARMV7 (S5PC110 SoC)
- s5pc210_universal ARM ARMV7 (S5PC210 SoC)
+ s5pc210_universal ARM ARMV7 (EXYNOS4210 SoC)
Chander Kashyap k.chan...@samsung.com
- origen ARM ARMV7 (S5PC210 SoC)
- SMDKV310ARM ARMV7 (S5PC210 SoC)
+ origen ARM ARMV7 (EXYNOS4210 SoC)
+ SMDKV310ARM ARMV7 (EXYNOS4210 SoC)
Torsten Koschorrek koschor...@synertronixx.de
scb9328 ARM920T (i.MXL)
diff --git a/Makefile b/Makefile
index fb658f4..3875466 100644
--- a/Makefile
+++ b/Makefile
@@ -296,7 +296,7 @@ endif
ifeq ($(SOC),s5pc1xx)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
-ifeq ($(SOC),s5pc2xx)
+ifeq ($(SOC),exynos)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
diff --git a/arch/arm/cpu/armv7/s5pc2xx/Makefile
b/arch/arm/cpu/armv7/exynos/Makefile
similarity index 100%
rename from arch/arm/cpu/armv7/s5pc2xx/Makefile
rename to arch/arm/cpu/armv7/exynos/Makefile
diff --git a/arch/arm/cpu/armv7/s5pc2xx/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
similarity index 81%
rename from arch/arm/cpu/armv7/s5pc2xx/clock.c
rename to arch/arm/cpu/armv7/exynos/clock.c
Re: [U-Boot] [STATUS] Getting ready for -rc1
Dear Wolfgang, (resent from registered account cause u-boot list seems to be members only now ...) Am 06.12.2011 12:12, schrieb Wolfgang Denk: Hi all, Second, I would like to get ready for the -rc1 pre-release. I'll wait for the next ARM pull request from Albert, and then I will push -rc1 out. If anybody has any unmerged patches pending that are supposed to go in, please speak up now. These are waiting for merge: * http://patchwork.ozlabs.org/patch/117688/ (unbreak avr32 arch) * http://patchwork.ozlabs.org/patch/120993/ (new mmc framework for avr32, brake some board/mmc combinations) * http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) * http://patchwork.ozlabs.org/patch/128931/ best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Dear Andreas, In message 4edf3855.5010...@corscience.de you wrote: These are waiting for merge: * http://patchwork.ozlabs.org/patch/117688/ (unbreak avr32 arch) * http://patchwork.ozlabs.org/patch/120993/ (new mmc framework for avr32, brake some board/mmc combinations) * http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) * http://patchwork.ozlabs.org/patch/128931/ This is MMC stuff, so they go through Andy's tree. Maybe you should put him on Cc: (done now). Instead of adding broken stuff to fix it later you might want to submit a new version of this stuff that sqashes the patches. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The number you have dialed is imaginary. Please divide by 0 and try again. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Dear Andreas, In message 4edf3a70.8000...@gmail.com you wrote: (resent from registered account cause u-boot list seems to be members only now ...) Moderated, yes. 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 Defaults are wonderful, just like fire. - Larry Wall in 1996mar6.004121.27...@netlabs.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Dear Wolfgang, Am 07.12.2011 11:25, schrieb Wolfgang Denk: Dear Andreas, In message 4edf3855.5010...@corscience.de you wrote: These are waiting for merge: * http://patchwork.ozlabs.org/patch/117688/ (unbreak avr32 arch) * http://patchwork.ozlabs.org/patch/120993/ (new mmc framework for avr32, brake some board/mmc combinations) * http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) * http://patchwork.ozlabs.org/patch/128931/ This is MMC stuff, so they go through Andy's tree. Only two of them are MMC related. Maybe you should put him on Cc: (done now). Instead of adding broken stuff to fix it later you might want to submit a new version of this stuff that sqashes the patches. Well, only the http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) is from me. The 'new mmc framework for avr32' is from Sven Schnelle and yes, we could merge these two together .. sven? IMHO the most important patch is http://patchwork.ozlabs.org/patch/117688/ which unbreaks the whole avr32 architecture. best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Dear Wolfgang, Am 07.12.2011 13:11, schrieb Wolfgang Denk: Dear Andreas, In message 4edf4521.6060...@gmail.com you wrote: IMHO the most important patch is http://patchwork.ozlabs.org/patch/117688/ which unbreaks the whole avr32 architecture. Was the AVR32 custodian on Cc: ? AFAIK Haavrad Skinnemoen does not work at atmel any longer and I think he has nothing else to do with avr32 ... Since then Reinhard took over as a 'atmel' custodian and yes, he was in CC. best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Dear Andreas, In message 4edf58c0.8090...@gmail.com you wrote: Was the AVR32 custodian on Cc: ? AFAIK Haavrad Skinnemoen does not work at atmel any longer and I think You are right, I have to update my mail aliases :-( Since then Reinhard took over as a 'atmel' custodian and yes, he was in CC. OK. 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 a multi-legged creature crawling on your shoulder. -- Spock, A Taste of Armageddon, stardate 3193.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] Convert cmd_usage() calls in common to use a return value
Hi Simon, On 12/07/11 07:47, Simon Glass wrote: Change all files in common/ to use CMD_RET_USAGE instead of calling cmd_usage() directly. I'm not completely sure about this patch since the code since impact is small (100 byte or so on ARM) and it might need splitting into smaller patches. But for now here it is. Signed-off-by: Simon Glass s...@chromium.org --- [...] diff --git a/common/cmd_mmc_spi.c b/common/cmd_mmc_spi.c index cfd0fb1..3153610 100644 --- a/common/cmd_mmc_spi.c +++ b/common/cmd_mmc_spi.c @@ -78,7 +78,7 @@ static int do_mmc_spi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return 0; usage: - cmd_usage(cmdtp); + return CMD_RET_USAGE; return 1; You, probably, also want to remove the above line... [...] -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] Add generic ULPI layer
Hi Marek,
On 12/07/11 01:49, Marek Vasut wrote:
Although it is a single patch, I felt that a cover letter will
definetly not hurt here, also the patch version history is so big, so
I decided to move it here.
The ULPI (UTMI Low Pin (count) Interface) PHYs are widely used on
variety of boards. This requires a generic architecture independant
implementation which can be reused and will eliminate the need for
direct write of arbitrary values to the ULPI transciever.
Although, the generic implementation can be reused on any architecture,
the access to ULPI PHY must be done in a platform specific way.
The platform specific way is in majority of case called a viewport.
Also, the ULPI specification defines a hybrid aproach for managing the
ULPI PHY. That is, the PHY must be managed through both the PHY registers
and control lines.
The proposed patch provides a partial implementation of the ULPI
specification, which should be enough for boot loader use cases,
and a viewport implementation for Chipidea/ARC based controllers,
which, AFAIK, are used on imx and tegra SoCs.
It is based on the Wolfgang's master branch (4 Dec 2012),
compile tested and checkpatch clean.
What is still missing, IMO:
- documentation for the CONFIG_* macros (I can add it in a separate
patch)
- a way to make most of the initialization in one ulpi_init() call
- viewport extension to be able to implement resume,
reset and disabling the serial mode
The change log:
Changes for v2:
- make code EHCI-independent
- use udelay() in waiting loop
- mark static functions as static
- naming changes
Changes for v3:
- merge with patch ulpi: add generic ULPI support header file
- rewrite ULPI interface in more functionality-oriented way
Changes for v4:
- add error-checking
- add waiting for completion into ulpi_reset() function
Changes for v5:
- CodingStyle changes
- add comments
- simplify implemenation of the ULPI interface functions
Changes for v6:
- cleanup function ulpi_drive_vbus()
Changes for v7:
- ulpi-viewport.c:
- reorder bit definitions
- split ulpi_request() to two functions
- reuse ulpi_wakeup() from ulpi_request()
to remove duplicated calls from ulpi_{read|write}()
- inline ulpi_*_mask as it is simple and used only once
- ulpi.c:
- move several defines into c file
- rework all the functions to propagate error values
- move function description comments into ulpi.h
along with declarations
- check arguments validity (as suggested by Simon)
- fix cases when using the *_set register,
bits cannot be cleared
- shorten several arguments names (e.g. ulpi_set_vbus())
- add ability to disable VBUS
- clean up ulpi_set_pd()
- add ability to enter the serial mode
- add verbosity in error cases
- remove ulpi_resume() as it were wrong and
must be implemented in a viewport specific way
- rework ulpi_reset() as it must be implemented in a
viewport specific way, but provide kind of generic
implementation which should work in most of the cases
- ulpi.h:
- add default timeout value
- remove unused defines
- move several defines inside c files
- add description for each function
- move the API declaration to the top of the header file
Jana Rapava (1):
USB: Add generic ULPI layer and a viewport
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 118 +++
drivers/usb/ulpi/ulpi.c | 227 +
include/usb/ulpi.h | 298
++ 5 files changed, 688 insertions(+),
0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
create mode 100644 include/usb/ulpi.h
Igor, please add Cc annotations to this patch too.
Well, I indeed forgot this, but I've send a forward of this email
to everybody supposed to be in Cc. Adding Cc once again...
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Getting ready for -rc1
Hi Andreas, On 12/07/2011 02:51 AM, Andreas Bießmann wrote: Dear Wolfgang, Am 07.12.2011 11:25, schrieb Wolfgang Denk: Dear Andreas, In message 4edf3855.5010...@corscience.de you wrote: These are waiting for merge: * http://patchwork.ozlabs.org/patch/117688/ (unbreak avr32 arch) * http://patchwork.ozlabs.org/patch/120993/ (new mmc framework for avr32, brake some board/mmc combinations) * http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) * http://patchwork.ozlabs.org/patch/128931/ This is MMC stuff, so they go through Andy's tree. Only two of them are MMC related. Maybe you should put him on Cc: (done now). Instead of adding broken stuff to fix it later you might want to submit a new version of this stuff that sqashes the patches. Well, only the http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) is from me. The 'new mmc framework for avr32' is from Sven Schnelle and yes, we could merge these two together .. sven? No objections against merging those two patches together. Can you do that for me, as i'm traveling and have no access to all the AVR32 stuff for testing. Thanks, Sven. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] USB: Add generic ULPI layer and a viewport
On 12/07/11 03:42, Simon Glass wrote:
Hi Igor,
Looks good - a few comments from me.
On Mon, Dec 5, 2011 at 1:07 AM, Igor Grinberg grinb...@compulab.co.il wrote:
From: Jana Rapava ferma...@gmail.com
Add partial ULPI specification implementation that should be enough to
interface the ULPI PHYs in the boot loader context.
Add a viewport implementation for Chipidea/ARC based controllers.
Signed-off-by: Jana Rapava ferma...@gmail.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Remy Bohmer li...@bohmer.net
Cc: Stefano Babic sba...@denx.de
Cc: Wolfgang Grandegger w...@denx.de
Cc: Simon Glass s...@chromium.org
---
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 118 +++
drivers/usb/ulpi/ulpi.c | 227 +
include/usb/ulpi.h | 298
++
This would benefit from additions to the README describing the two new
CONFIGs you add.
5 files changed, 688 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
create mode 100644 include/usb/ulpi.h
diff --git a/drivers/usb/ulpi/ulpi.c b/drivers/usb/ulpi/ulpi.c
new file mode 100644
index 000..805e29d
--- /dev/null
+++ b/drivers/usb/ulpi/ulpi.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright (C) 2011 Jana Rapava ferma...@gmail.com
+ * Copyright (C) 2011 CompuLab, Ltd. www.compulab.co.il
+ *
+ * Authors: Jana Rapava ferma...@gmail.com
+ * Igor Grinberg grinb...@compulab.co.il
+ *
+ * Based on:
+ * linux/drivers/usb/otg/ulpi.c
+ * Generic ULPI USB transceiver support
+ *
+ * Original Copyright follow:
+ * Copyright (C) 2009 Daniel Mack dan...@caiaq.de
+ *
+ * Based on sources from
+ *
+ * Sascha Hauer s.ha...@pengutronix.de
+ * Freescale Semiconductors
+ *
+ * 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.
+ */
+
+#include common.h
+#include exports.h
+#include usb/ulpi.h
+
+#define ULPI_ID_REGS_COUNT 4
+#define ULPI_TEST_VALUE0x55/* 0x55 == 0b01010101 */
+
+static struct ulpi_regs *ulpi = (struct ulpi_regs *)0;
+
+static int ulpi_integrity_check(u32 ulpi_viewport)
+{
+ u32 err, val, tval = ULPI_TEST_VALUE;
+ int i;
+
+ /* Use the 'special' test value to check all bits */
+ for (i = 0; i 2; i++, tval = 1) {
+ err = ulpi_write(ulpi_viewport, ulpi-scratch, tval);
+ if (err)
+ return err;
+
+ val = ulpi_read(ulpi_viewport, ulpi-scratch);
+ if (val != tval) {
+ printf(ULPI integrity check failed\n);
+ return val;
+ }
+ }
+
+ return 0;
+}
+
+int ulpi_init(u32 ulpi_viewport)
+{
+ u32 val, id = 0;
+ u8 *reg = ulpi-product_id_high;
+ int i;
+
+ /* Assemble ID from four ULPI ID registers (8 bits each). */
+ for (i = 0; i ULPI_ID_REGS_COUNT; i++) {
+ val = ulpi_read(ulpi_viewport, reg - i);
+ if (val == ULPI_ERROR)
+ return val;
+
+ id = (id 8) | val;
+ }
+
+ /* Split ID into vendor and product ID. */
+ debug(ULPI transceiver ID 0x%04x:0x%04x\n, id 16, id 0x);
+
+ return ulpi_integrity_check(ulpi_viewport);
+}
+
+int ulpi_select_transceiver(u32 ulpi_viewport, u8 speed)
Is there any point in making the argument u8?
Not really...
How about just unsigned?
Sounds sane
I think this adds a mask to the call = larger code size. You check the
arg with the switch() below anyway.
Haven't thought about that...
I don't know how is this exactly works, but I don't see
any reason why shouldn't I use unsigned here.
+{
+ u8 tspeed = ULPI_FC_FULL_SPEED;
+ u32 val;
+
+ switch (speed) {
+ case ULPI_FC_HIGH_SPEED:
+ case ULPI_FC_FULL_SPEED:
+ case ULPI_FC_LOW_SPEED:
+ case ULPI_FC_FS4LS:
+ tspeed = speed;
+ break;
+ default:
+ printf(ULPI: %s: wrong transceiver speed specified,
+ falling back to full speed\n, __func__);
+ }
+
+ val = ulpi_read(ulpi_viewport, ulpi-function_ctrl);
+ if (val == ULPI_ERROR)
+ return val;
+
+ /* clear
[U-Boot] [PATCH v2] MIPS: fix endianess handling
Make endianess of target CPU configurable. Use the new config option for dbau1550_el and pb1000 boards. Adapt linking of standalone applications to pass through endianess options to LD. Build tested with: - ELDK 4 mips_4KC- and mips4KCle - Sourcery CodeBench Lite 2011.03-93 With this patch all 26 MIPS boards can be compiled now in one step by running MAKEALL -a mips. Signed-off-by: Daniel Schwierzeck daniel.schwierz...@googlemail.com --- Changes for v2: - moved CONFIG_SYS_LITTLE_ENDIAN from boards.cfg to configs/pb1x00.h - fixed typo in comment - updated patch summary Note: qemu_mips and tb0229 boards are still broken. Build result with Sourcery CodeBench Lite 2011.03-93: ~/devel/u-boot$ CROSS_COMPILE=/opt/codesourcery/mips-2011.03/bin/mips-linux-gnu- BUILD_NCPUS=2 ./MAKEALL -a mips Configuring for dbau1000 - Board: dbau1x00, Options: DBAU1000 textdata bss dec hex filename 1206044390 16068 141062 22706 ./u-boot Configuring for dbau1100 - Board: dbau1x00, Options: DBAU1100 textdata bss dec hex filename 1206044390 16068 141062 22706 ./u-boot Configuring for dbau1500 - Board: dbau1x00, Options: DBAU1500 textdata bss dec hex filename 1206044390 16068 141062 22706 ./u-boot Configuring for dbau1550 - Board: dbau1x00, Options: DBAU1550 textdata bss dec hex filename 1191484454 18732 142334 22bfe ./u-boot Configuring for dbau1550_el - Board: dbau1x00, Options: DBAU1550,SYS_LITTLE_ENDIAN textdata bss dec hex filename 1203164454 18732 143502 2308e ./u-boot Configuring for gth2 board... textdata bss dec hex filename 1136684390 13752 131810 202e2 ./u-boot Configuring for incaip board... textdata bss dec hex filename 1475005066 15676 168242 29132 ./u-boot Configuring for incaip_100MHz - Board: incaip, Options: CPU_CLOCK_RATE=1 textdata bss dec hex filename 1475005066 15676 168242 29132 ./u-boot Configuring for incaip_133MHz - Board: incaip, Options: CPU_CLOCK_RATE=13300 textdata bss dec hex filename 1475005066 15676 168242 29132 ./u-boot Configuring for incaip_150MHz - Board: incaip, Options: CPU_CLOCK_RATE=15000 textdata bss dec hex filename 1475005066 15676 168242 29132 ./u-boot Configuring for pb1000 - Board: pb1x00, Options: PB1000 textdata bss dec hex filename 1100845090 15896 131070 1fffe ./u-boot Configuring for qemu_mips board... net/libnet.o: In function `eth_halt': (.text.eth_halt+0x0): multiple definition of `eth_halt' drivers/net/libnet.o:/home/schwierd/devel/u-boot/drivers/net/ne2000_base.c:721: first defined here net/libnet.o: In function `eth_rx': (.text.eth_rx+0x0): multiple definition of `eth_rx' drivers/net/libnet.o:/home/schwierd/devel/u-boot/drivers/net/ne2000_base.c:729: first defined here net/libnet.o: In function `eth_init': (.text.eth_init+0x0): multiple definition of `eth_init' drivers/net/libnet.o:/home/schwierd/devel/u-boot/drivers/net/ne2000_base.c:668: first defined here net/libnet.o: In function `eth_send': (.text.eth_send+0x0): multiple definition of `eth_send' drivers/net/libnet.o:/home/schwierd/devel/u-boot/drivers/net/ne2000_base.c:734: first defined here make: *** [u-boot] Error 1 /opt/codesourcery/mips-2011.03/bin/mips-linux-gnu-size: './u-boot': No such file Configuring for tb0229 board... flash.c:27:24: fatal error: asm/ppc4xx.h: No such file or directory compilation terminated. make[1]: *** No rule to make target `.depend', needed by `_depend'. Stop. make: *** [depend] Error 2 /opt/codesourcery/mips-2011.03/bin/mips-linux-gnu-size: './u-boot': No such file Configuring for vct_premium - Board: vct, Options: VCT_PREMIUM textdata bss dec hex filename 197880 12100 272852 482832 75e10 ./u-boot Configuring for vct_premium_small - Board: vct, Options: VCT_PREMIUM,VCT_SMALL_IMAGE board.c: In function 'board_init_r': board.c:266:8: warning: unused variable 's' textdata bss dec hex filename 881043640 14372 106116 19e84 ./u-boot Configuring for vct_premium_onenand - Board: vct, Options: VCT_PREMIUM,VCT_ONENAND textdata bss dec hex filename 292552 14564 274068 581184 8de40 ./u-boot Configuring for vct_premium_onenand_small - Board: vct, Options: VCT_PREMIUM,VCT_ONENAND,VCT_SMALL_IMAGE board.c: In function 'board_init_r': board.c:266:8: warning: unused variable 's' textdata bss dec hex filename 1818846056 15604 203544 31b18 ./u-boot Configuring for vct_platinum - Board: vct, Options: VCT_PLATINUM textdata bss dec hex filename 197880 12100 272852 482832 75e10 ./u-boot Configuring for vct_platinum_small - Board: vct, Options: VCT_PLATINUM,VCT_SMALL_IMAGE board.c: In function 'board_init_r': board.c:266:8:
[U-Boot] [PATCH v2 0/3] env: handle special variables and selective env default
This patchset modifies the handling of all the operations on the environment
(set/import/default) so to unify handling of special variables.
On top of that we implement a selective env default.
A selective env import would imply a user API change and should therefore
be discussed separately.
Changes in the syntax (user API):
- env default -f: override write-once variables, -a means all
Changes from v1:
- removed cosmetic patches (now mainstream)
- rebased to latest trunk
- removed subtle error in env_check_apply
(comparing {loadaddr, bootfile} to values instead
of variable names)
- changed env_check_apply so not to display warnings
in case of H_FORCE flag being set
Changes from v0
- checkpatch cleanup
- removed himport_ex()
- removed warning for serial_assign()
- env import NOT implemented here
Gerlando Falauto (3):
env: unify logic to check and apply changes
env: check and apply changes on delete/destroy
env: make env default selective, check and apply
README |2 +
common/cmd_nvedit.c | 219 +++---
common/env_common.c | 35 +++-
include/config_cmd_all.h |1 +
include/environment.h| 12 +++
include/search.h | 23 -
lib/hashtable.c | 61 +++--
7 files changed, 270 insertions(+), 83 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] env: unify logic to check and apply changes
The logic of checking special parameters (e.g. baudrate, stdin, stdout,
for a valid value and/or whether can be overwritten) and applying the
new value to the running system is now all within a single function
env_check_apply() which can be called whenever changes are made
to the environment, no matter if by set, default or import.
With this patch env_check_apply() is only called by env set,
retaining previous behavior.
Also allow for selectively importing/resetting variables.
So add 3 new arguments to himport_r():
o nvars, vars:, number and list of variables to take into account
(0 means ALL)
o apply callback function to check whether a variable can be
overwritten, and possibly immediately apply the changes;
when NULL, no check is performed.
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
common/cmd_nvedit.c | 174 +++--
common/env_common.c |6 +-
include/environment.h |7 ++
include/search.h | 17 +-
lib/hashtable.c | 43 -
5 files changed, 180 insertions(+), 67 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 5995354..a31d413 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -197,32 +197,23 @@ static int do_env_grep(cmd_tbl_t *cmdtp, int flag,
#endif
/*
- * Set a new environment variable,
- * or replace or delete an existing one.
+ * Performs consistency checking before setting, replacing,
+ * or deleting an environment variable, then (if successful)
+ * apply the changes to internals so to make them effective.
+ * Code for this function was taken out of _do_env_set(),
+ * which now calls it.
+ * Also called as a callback function by himport_r().
+ * Returns 0 in case of success, 1 in case of failure.
+ * When (flag H_FORCE) is set, force overwriting of
+ * write-once variables.
*/
-int _do_env_set(int flag, int argc, char * const argv[])
+
+int env_check_apply(const char *name, const char *oldval,
+ const char *newval, int flag)
{
bd_t *bd = gd-bd;
- int i, len;
+ int i;
int console = -1;
- char *name, *value, *s;
- ENTRY e, *ep;
-
- name = argv[1];
-
- if (strchr(name, '=')) {
- printf(## Error: illegal character '=' in variable name
- \%s\\n, name);
- return 1;
- }
-
- env_id++;
- /*
-* search if variable with this name already exists
-*/
- e.key = name;
- e.data = NULL;
- hsearch_r(e, FIND, ep, env_htab);
/* Check for console redirection */
if (strcmp(name, stdin) == 0)
@@ -233,22 +224,24 @@ int _do_env_set(int flag, int argc, char * const argv[])
console = stderr;
if (console != -1) {
- if (argc 3) { /* Cannot delete it! */
- printf(Can't delete \%s\\n, name);
+ if ((newval == NULL) || (*newval == '\0')) {
+ /* We cannot delete stdin/stdout/stderr */
+ if ((flag H_FORCE) == 0)
+ printf(Can't delete \%s\\n, name);
return 1;
}
#ifdef CONFIG_CONSOLE_MUX
- i = iomux_doenv(console, argv[2]);
+ i = iomux_doenv(console, newval);
if (i)
return i;
#else
/* Try assigning specified device */
- if (console_assign(console, argv[2]) 0)
+ if (console_assign(console, newval) 0)
return 1;
#ifdef CONFIG_SERIAL_MULTI
- if (serial_assign(argv[2]) 0)
+ if (serial_assign(newval) 0)
return 1;
#endif
#endif /* CONFIG_CONSOLE_MUX */
@@ -256,37 +249,52 @@ int _do_env_set(int flag, int argc, char * const argv[])
/*
* Some variables like ethaddr and serial# can be set only
-* once and cannot be deleted; also, ver is readonly.
+* once and cannot be deleted, unless CONFIG_ENV_OVERWRITE
+* is defined.
*/
- if (ep) { /* variable exists */
#ifndef CONFIG_ENV_OVERWRITE
+ if (oldval != NULL/* variable exists */
+ (flag H_FORCE) == 0) {/* and we are not forced */
if (strcmp(name, serial#) == 0 ||
(strcmp(name, ethaddr) == 0
#if defined(CONFIG_OVERWRITE_ETHADDR_ONCE) defined(CONFIG_ETHADDR)
- strcmp(ep-data, MK_STR(CONFIG_ETHADDR)) != 0
+ strcmp(oldval, MK_STR(CONFIG_ETHADDR)) != 0
#endif /* CONFIG_OVERWRITE_ETHADDR_ONCE CONFIG_ETHADDR */
)) {
printf(Can't overwrite \%s\\n, name);
return 1;
}
+ }
#endif
+ /*
+* When we change baudrate, or we are doing an env default -a
+
[U-Boot] [PATCH v2 2/3] env: check and apply changes on delete/destroy
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
common/cmd_nvedit.c |2 +-
include/search.h|6 --
lib/hashtable.c | 18 --
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index a31d413..871b3b1 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -377,7 +377,7 @@ int _do_env_set(int flag, int argc, char * const argv[])
/* Delete only ? */
if (argc 3 || argv[2] == NULL) {
- int rc = hdelete_r(name, env_htab);
+ int rc = hdelete_r(name, env_htab, NULL);
return !rc;
}
diff --git a/include/search.h b/include/search.h
index 2a59e03..7ad4261 100644
--- a/include/search.h
+++ b/include/search.h
@@ -70,7 +70,8 @@ struct hsearch_data {
extern int hcreate_r(size_t __nel, struct hsearch_data *__htab);
/* Destroy current internal hashing table. */
-extern void hdestroy_r(struct hsearch_data *__htab);
+extern void hdestroy_r(struct hsearch_data *__htab,
+ apply_cb apply);
/*
* Search for entry matching ITEM.key in internal hash table. If
@@ -95,7 +96,8 @@ extern int hstrstr_r(const char *__match, int __last_idx,
ENTRY ** __retval,
struct hsearch_data *__htab);
/* Search and delete entry matching ITEM.key in internal hash table. */
-extern int hdelete_r(const char *__key, struct hsearch_data *__htab);
+extern int hdelete_r(const char *__key, struct hsearch_data *__htab,
+ apply_cb apply);
extern ssize_t hexport_r(struct hsearch_data *__htab,
const char __sep, char **__resp, size_t __size,
diff --git a/lib/hashtable.c b/lib/hashtable.c
index 75b9b07..87adc01 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -142,7 +142,8 @@ int hcreate_r(size_t nel, struct hsearch_data *htab)
* be freed and the local static variable can be marked as not used.
*/
-void hdestroy_r(struct hsearch_data *htab)
+void hdestroy_r(struct hsearch_data *htab,
+ int(*apply)(const char *, const char *, const char *, int))
{
int i;
@@ -156,7 +157,10 @@ void hdestroy_r(struct hsearch_data *htab)
for (i = 1; i = htab-size; ++i) {
if (htab-table[i].used 0) {
ENTRY *ep = htab-table[i].entry;
-
+ if (apply != NULL) {
+ /* deletion is always forced */
+ apply(ep-key, ep-data, NULL, H_FORCE);
+ }
free((void *)ep-key);
free(ep-data);
}
@@ -401,7 +405,8 @@ int hsearch_r(ENTRY item, ACTION action, ENTRY ** retval,
* do that.
*/
-int hdelete_r(const char *key, struct hsearch_data *htab)
+int hdelete_r(const char *key, struct hsearch_data *htab,
+ int(*apply)(const char *, const char *, const char *, int))
{
ENTRY e, *ep;
int idx;
@@ -417,7 +422,8 @@ int hdelete_r(const char *key, struct hsearch_data *htab)
/* free used ENTRY */
debug(hdelete: DELETING key \%s\\n, key);
-
+ if (apply != NULL)
+ apply(ep-key, ep-data, NULL, H_FORCE);
free((void *)ep-key);
free(ep-data);
htab-table[idx].used = -1;
@@ -681,7 +687,7 @@ int himport_r(struct hsearch_data *htab,
debug(Destroy Hash Table: %p table = %p\n, htab,
htab-table);
if (htab-table)
- hdestroy_r(htab);
+ hdestroy_r(htab, apply);
}
/*
@@ -747,7 +753,7 @@ int himport_r(struct hsearch_data *htab,
if (!process_var(name, nvars, vars))
continue;
- if (hdelete_r(name, htab) == 0)
+ if (hdelete_r(name, htab, apply) == 0)
debug(DELETE ERROR
##\n);
continue;
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] env: make env default selective, check and apply
Changes in the syntax (user API) for env default:
-f: override write-once variables
-a: all (resetting the whole env is NOT the default behavior)
Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
---
README |2 ++
common/cmd_nvedit.c | 43 ---
common/env_common.c | 31 ++-
include/config_cmd_all.h |1 +
include/environment.h|5 +
5 files changed, 74 insertions(+), 8 deletions(-)
diff --git a/README b/README
index fda0190..e924575 100644
--- a/README
+++ b/README
@@ -724,6 +724,8 @@ The following options need to be configured:
CONFIG_CMD_CONSOLEconinfo
CONFIG_CMD_CRC32* crc32
CONFIG_CMD_DATE * support for RTC, date/time...
+ CONFIG_CMD_DEFAULTENV_VARS
+ * Reset individual variables to default
CONFIG_CMD_DHCP * DHCP support
CONFIG_CMD_DIAG * Diagnostics
CONFIG_CMD_DS4510 * ds4510 I2C gpio commands
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 871b3b1..317bd1c 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -674,14 +674,40 @@ int envmatch(uchar *s1, int i2)
return -1;
}
-static int do_env_default(cmd_tbl_t *cmdtp, int flag,
+static int do_env_default(cmd_tbl_t *cmdtp, int __flag,
int argc, char * const argv[])
{
- if (argc != 2 || strcmp(argv[1], -f) != 0)
- return cmd_usage(cmdtp);
-
- set_default_env(## Resetting to default environment\n);
- return 0;
+ int all = 0, flag = 0;
+ debug(Initial value for argc=%d\n, argc);
+ while (--argc 0 **++argv == '-') {
+ char *arg = *argv;
+ while (*++arg) {
+ switch (*arg) {
+ case 'a': /* default all */
+ all = 1;
+ break;
+ case 'f': /* force */
+ flag |= H_FORCE;
+ break;
+ default:
+ return cmd_usage(cmdtp);
+ }
+ }
+ }
+ debug(Final value for argc=%d\n, argc);
+ if (all (argc == 0)) {
+ /* Reset the whole environment */
+ set_default_env(## Resetting to default environment\n);
+ return 0;
+ }
+#ifdef CONFIG_CMD_DEFAULTENV_VARS
+ if (!all (argc 0)) {
+ /* Reset individual variables */
+ env_default_vars(argc, argv);
+ return 0;
+ }
+#endif
+ return cmd_usage(cmdtp);
}
static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
@@ -1012,7 +1038,10 @@ U_BOOT_CMD(
#if defined(CONFIG_CMD_ASKENV)
ask name [message] [size] - ask for environment variable\nenv
#endif
- default -f - reset default environment\n
+ default [-f] -a - [forcibly] reset default environment\n
+#if defined(CONFIG_CMD_DEFAULTENV_VARS)
+ env default [-f] var [...] - [forcibly] reset variable(s) to their
default values\n
+#endif
#if defined(CONFIG_CMD_EDITENV)
env edit name - edit environment variable\n
#endif
diff --git a/common/env_common.c b/common/env_common.c
index 7e2bb2f..56719a6 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -157,6 +157,11 @@ const uchar *env_get_addr(int index)
void set_default_env(const char *s)
{
+ /*
+* By default, do not apply changes as they will eventually
+* be applied by someone else
+*/
+ apply_cb apply_function = NULL;
if (sizeof(default_environment) ENV_SIZE) {
puts(*** Error - default environment is too large\n\n);
return;
@@ -168,6 +173,14 @@ void set_default_env(const char *s)
using default environment\n\n,
s + 1);
} else {
+ /*
+* This set_to_default was explicitly asked for
+* by the user, as opposed to being a recovery
+* mechanism. Therefore we chack every single
+* variable and apply changes to the system
+* right away (e.g. baudrate, console).
+*/
+ apply_function = env_check_apply;
puts(s);
}
} else {
@@ -176,12 +189,28 @@ void set_default_env(const char *s)
if (himport_r(env_htab, (char *)default_environment,
sizeof(default_environment), '\0', 0,
- 0, NULL, NULL) == 0)
+ 0, NULL, apply_function) == 0)
error(Environment import
Re: [U-Boot] [STATUS] Getting ready for -rc1
Dear Sven, Am 07.12.2011 14:20, schrieb Sven Schnelle: Hi Andreas, On 12/07/2011 02:51 AM, Andreas Bießmann wrote: Dear Wolfgang, Am 07.12.2011 11:25, schrieb Wolfgang Denk: Dear Andreas, In message 4edf3855.5010...@corscience.de you wrote: These are waiting for merge: * http://patchwork.ozlabs.org/patch/117688/ (unbreak avr32 arch) * http://patchwork.ozlabs.org/patch/120993/ (new mmc framework for avr32, brake some board/mmc combinations) * http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) * http://patchwork.ozlabs.org/patch/128931/ This is MMC stuff, so they go through Andy's tree. Only two of them are MMC related. Maybe you should put him on Cc: (done now). Instead of adding broken stuff to fix it later you might want to submit a new version of this stuff that sqashes the patches. Well, only the http://patchwork.ozlabs.org/patch/119780/ (unbreak new mmc framework) is from me. The 'new mmc framework for avr32' is from Sven Schnelle and yes, we could merge these two together .. sven? No objections against merging those two patches together. Can you do that for me, as i'm traveling and have no access to all the AVR32 stuff for testing. I can do so, but not before Friday ... Andy should comment on http://patchwork.ozlabs.org/patch/119780/ before doing the merge cause this patch was an RFC ... will forward the patch to him and ask. IMHO those two patches (120993 and 119780) are not a _must_ have for rc1 (or this release at all), but they where posted before merge window closed (and on my wish list). best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] Add generic ULPI layer
On 12/07/11 14:59, Igor Grinberg wrote:
Hi Marek,
On 12/07/11 01:49, Marek Vasut wrote:
Although it is a single patch, I felt that a cover letter will
definetly not hurt here, also the patch version history is so big, so
I decided to move it here.
The ULPI (UTMI Low Pin (count) Interface) PHYs are widely used on
variety of boards. This requires a generic architecture independant
implementation which can be reused and will eliminate the need for
direct write of arbitrary values to the ULPI transciever.
Although, the generic implementation can be reused on any architecture,
the access to ULPI PHY must be done in a platform specific way.
The platform specific way is in majority of case called a viewport.
Also, the ULPI specification defines a hybrid aproach for managing the
ULPI PHY. That is, the PHY must be managed through both the PHY registers
and control lines.
The proposed patch provides a partial implementation of the ULPI
specification, which should be enough for boot loader use cases,
and a viewport implementation for Chipidea/ARC based controllers,
which, AFAIK, are used on imx and tegra SoCs.
It is based on the Wolfgang's master branch (4 Dec 2012),
compile tested and checkpatch clean.
What is still missing, IMO:
- documentation for the CONFIG_* macros (I can add it in a separate
patch)
- a way to make most of the initialization in one ulpi_init() call
- viewport extension to be able to implement resume,
reset and disabling the serial mode
The change log:
Changes for v2:
- make code EHCI-independent
- use udelay() in waiting loop
- mark static functions as static
- naming changes
Changes for v3:
- merge with patch ulpi: add generic ULPI support header file
- rewrite ULPI interface in more functionality-oriented way
Changes for v4:
- add error-checking
- add waiting for completion into ulpi_reset() function
Changes for v5:
- CodingStyle changes
- add comments
- simplify implemenation of the ULPI interface functions
Changes for v6:
- cleanup function ulpi_drive_vbus()
Changes for v7:
- ulpi-viewport.c:
- reorder bit definitions
- split ulpi_request() to two functions
- reuse ulpi_wakeup() from ulpi_request()
to remove duplicated calls from ulpi_{read|write}()
- inline ulpi_*_mask as it is simple and used only once
- ulpi.c:
- move several defines into c file
- rework all the functions to propagate error values
- move function description comments into ulpi.h
along with declarations
- check arguments validity (as suggested by Simon)
- fix cases when using the *_set register,
bits cannot be cleared
- shorten several arguments names (e.g. ulpi_set_vbus())
- add ability to disable VBUS
- clean up ulpi_set_pd()
- add ability to enter the serial mode
- add verbosity in error cases
- remove ulpi_resume() as it were wrong and
must be implemented in a viewport specific way
- rework ulpi_reset() as it must be implemented in a
viewport specific way, but provide kind of generic
implementation which should work in most of the cases
- ulpi.h:
- add default timeout value
- remove unused defines
- move several defines inside c files
- add description for each function
- move the API declaration to the top of the header file
Jana Rapava (1):
USB: Add generic ULPI layer and a viewport
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 118 +++
drivers/usb/ulpi/ulpi.c | 227 +
include/usb/ulpi.h | 298
++ 5 files changed, 688 insertions(+),
0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
create mode 100644 include/usb/ulpi.h
Igor, please add Cc annotations to this patch too.
Well, I indeed forgot this, but I've send a forward of this email
to everybody supposed to be in Cc. Adding Cc once again...
That's interesting...
I've added much more people to Cc, than those listed currently...
It looks like the bounce from the list eats the Cc partially...
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] gen_atmel_mci: add mci_set_data_timeout()
Dear Andy Fleming, Am 14.10.2011 14:36, schrieb Andreas Bießmann: Before the DTOR register is set to a fixed value and resulted in some cards not working. Setting the fixed value to a hihger value is not appropriate cause we could wait way to long for slow clock rates. This patch moves the mci_set_data_timeout() from old atmel_mci driver to gen_atmel_mci driver and adopts to the parameters. In contrast to the origin this version of mci_set_data_timeout() relies on some fixed input values for timeout_ns and timeout_clks. Before these values where taken from the card's CSD. Signed-off-by: Andreas Bießmann biessm...@corscience.de CC: Sven Schnelle sv...@stackframe.org CC: Reinhard Meyer u-b...@emk-elektronik.de CC: Andy Fleming aflem...@gmail.com --- RESENT TO LIST ... This is an RFC. The most questionary thing is whether we use fixed values for timeout_ns/timeout_clks or take the values from CSD as before. I wonder if we should add the taac and nsac values to the mmc struct or if we should handle the mmc-csd[] inside the driver if we requiore the card data as input for the timeout equtation. Please read also http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/112056/focus=112057 This is the patch in question (see discussion @ http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/119611/focus=119626) Is it OK for you to use the fixed values for timeout_ns/timeout_clks here or should we a) use the mmc-csd[] values in the respective driver? or b) introduce some generic handling for mmc-csd[]? best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: cfb_console: fix build warnings
Fix:
cfb_console.c:371: warning: 'cursor_state' defined but not used
cfb_console.c:372: warning: 'old_col' defined but not used
cfb_console.c:373: warning: 'old_row' defined but not used
cfb_console.c:435: warning: 'video_invertchar' defined but not used
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
I forgot to run MAKEALL for both, arm and powerpc for last CFB
patch, sorry.
drivers/video/cfb_console.c | 38 +-
1 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 9be6166..904caf7 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -368,9 +368,9 @@ static void *video_console_address; /* console buffer start
address */
static int video_logo_height = VIDEO_LOGO_HEIGHT;
-static int cursor_state;
-static int old_col;
-static int old_row;
+static int __maybe_unused cursor_state;
+static int __maybe_unused old_col;
+static int __maybe_unused old_row;
static int console_col;/* cursor col */
static int console_row;/* cursor row */
@@ -430,23 +430,6 @@ static const int video_font_draw_table32[16][4] = {
{0x00ff, 0x00ff, 0x00ff, 0x00ff}
};
-
-static void video_invertchar(int xx, int yy)
-{
- int firstx = xx * VIDEO_PIXEL_SIZE;
- int lastx = (xx + VIDEO_FONT_WIDTH) * VIDEO_PIXEL_SIZE;
- int firsty = yy * VIDEO_LINE_LEN;
- int lasty = (yy + VIDEO_FONT_HEIGHT) * VIDEO_LINE_LEN;
- int x, y;
- for (y = firsty; y lasty; y += VIDEO_LINE_LEN) {
- for (x = firstx; x lastx; x++) {
- u8 *dest = (u8 *)(video_fb_address) + x + y;
- *dest = ~*dest;
- }
- }
-}
-
-
static void video_drawchars(int xx, int yy, unsigned char *s, int count)
{
u8 *cdat, *dest, *dest0;
@@ -627,7 +610,20 @@ static void video_set_cursor(void)
console_cursor(1);
}
-
+static void video_invertchar(int xx, int yy)
+{
+ int firstx = xx * VIDEO_PIXEL_SIZE;
+ int lastx = (xx + VIDEO_FONT_WIDTH) * VIDEO_PIXEL_SIZE;
+ int firsty = yy * VIDEO_LINE_LEN;
+ int lasty = (yy + VIDEO_FONT_HEIGHT) * VIDEO_LINE_LEN;
+ int x, y;
+ for (y = firsty; y lasty; y += VIDEO_LINE_LEN) {
+ for (x = firstx; x lastx; x++) {
+ u8 *dest = (u8 *)(video_fb_address) + x + y;
+ *dest = ~*dest;
+ }
+ }
+}
void console_cursor(int state)
{
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p2041rdb: fix serdes clock map
On Dec 1, 2011, at 7:38 PM, Shaohui Xie wrote: Description of SerDes clock Bank2 setting in p2041 hardware specification is wrong, the clock map which based on it is wrong either, so fix the serdes clock map. wrong setting of SERDES Reference Clocks Bank2: SW2[5:6] = ON OFF =100MHz for PCI mode SW2[5:6] = OFF ON =125MHz for SGMII mode right setting of SERDES Reference Clocks Bank2: SW2[5:6] = OFF OFF=100MHz for PCI mode SW2[5:6] = OFF ON =125MHz for SGMII mode SW2[5:6] = ON OFF =156.25MHZ Signed-off-by: Shaohui Xie shaohui@freescale.com --- board/freescale/p2041rdb/p2041rdb.c | 25 +++-- 1 files changed, 15 insertions(+), 10 deletions(-) applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] Allow for parallel builds and saved output
On Nov 21, 2011, at 5:40 PM, Andy Fleming wrote:
The MAKEALL script cleverly runs make with the appropriate options
to use all of the cores on the system, but your average U-Boot build
can't make much use of more than a few cores. If you happen to have
a many-core server, your builds will leave most of the system idle.
In order to make full use of such a system, we need to build multiple
targets in parallel, and this requires directing make output into
multiple directories. We add a BUILD_NBUILDS variable, which allows
users to specify how many builds to run in parallel.
When BUILD_NBUILDS is set greater than 1, we redefine BUILD_DIR for
each build to be ${BUILD_DIR}/${target}. Also, we make ./build the
default BUILD_DIR when BUILD_NBUILDS is greater than 1.
MAKEALL now tracks which builds are still running, and when one
finishes, it starts a new build.
Once each build finishes, we run make tidy on its directory, to reduce
the footprint.
As a result, we are left with a build directory with all of the built
targets still there for use, which means anyone who wanted to use
MAKEALL as part of a test harness can now do so.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
v2: - Update to keep BUILD_NBUILDS builds in flight, rather than batching
- Clean up style things
- Defer error output until build completion to make output *slightly*
more readable
Can you re-fresh patch against top of tree.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] AM3517: Add NOR Flash boot mode Support
Hi Tom,
On 12/06/11 17:49, Tom Rini wrote:
From: Vaibhav Hiremath hvaib...@ti.com
Please note that NOR Flash is located on Application board and requires
hardware modification to get NOR boot mode working.
NOR Flash boot mode configuration -
- From baseboard remove R235 resistor.
- Set switch S11.3 position to ON
- Set S7 switch position to
1 2 3 4 5
-
on off off off off
Please note that, once you remove R235 resistor from the baseboard, you
will not be able to boot from NAND without Application board.
The GPMC_nCS0 is now routed through Application board.
Please note that, Rev4 revision of Application board doesn't
work with NOR Flash due to HW issue.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap3/mem.c| 61 +++-
arch/arm/include/asm/arch-omap3/mem.h | 15 +---
board/logicpd/am3517evm/am3517evm.h |2 +-
3 files changed, 61 insertions(+), 17 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/mem.c b/arch/arm/cpu/armv7/omap3/mem.c
index 4a8c025..4ad3d12 100644
--- a/arch/arm/cpu/armv7/omap3/mem.c
+++ b/arch/arm/cpu/armv7/omap3/mem.c
@@ -51,6 +51,17 @@ static const u32 gpmc_m_nand[GPMC_MAX_REG] = {
#endif
+#if defined (CONFIG_CMD_FLASH)
+static const u32 gpmc_nor[GPMC_MAX_REG] = {
+ STNOR_GPMC_CONFIG1,
+ STNOR_GPMC_CONFIG2,
+ STNOR_GPMC_CONFIG3,
+ STNOR_GPMC_CONFIG4,
+ STNOR_GPMC_CONFIG5,
+ STNOR_GPMC_CONFIG6, 0
+};
+#endif
This does not seem to be the right place for these settings...
I think those must be board specific.
+
#if defined(CONFIG_CMD_ONENAND)
static const u32 gpmc_onenand[GPMC_MAX_REG] = {
ONENAND_GPMC_CONFIG1,
@@ -118,21 +129,34 @@ void enable_gpmc_cs_config(const u32 *gpmc_config,
struct gpmc_cs *cs, u32 base,
sdelay(2000);
}
-/*
+/*
* gpmc_init(): init gpmc bus
- * Init GPMC for x16, MuxMode (SDRAM in x32).
- * This code can only be executed from SRAM or SDRAM.
- */
+ * Init GPMC for x16, MuxMode (SDRAM in x32). This code can only be
+ * executed from SRAM or SDRAM. In the common case, we will disable
+ * and then configure chip select 0 for our needs (NAND or OneNAND).
+ * However, on the AM3517 EVM the way that NOR can be exposed requires us
+ * to rethink this. When NOR is enabled, it will be chip select 0 if
+ * we are booting from NOR or chip select 2 otherwise. This requires us
+ * to check the value we get from the SYSBOOT pins.
All the above looks like board specific...
+ */
void gpmc_init(void)
{
/* putting a blanket check on GPMC based on ZeBu for now */
gpmc_cfg = (struct gpmc *)GPMC_BASE;
-#if defined(CONFIG_CMD_NAND) || defined(CONFIG_CMD_ONENAND)
+#if defined(CONFIG_CMD_NAND) || defined(CONFIG_CMD_ONENAND) || \
+ (defined(CONFIG_OMAP3_AM3517EVM) defined(CONFIG_SYS_HAS_NORFLASH))
const u32 *gpmc_config = NULL;
u32 base = 0;
- u32 size = 0;
+ u32 sz = 0;
#endif
u32 config = 0;
+ u32 nor_boot = 0;
+
+#if defined(CONFIG_OMAP3_AM3517EVM) defined(CONFIG_SYS_HAS_NORFLASH)
+ /* 0xD means NOR boot on AM35x */
+ if (get_boot_type() == 0xD)
+ nor_boot = 1;
+#endif
/* global settings */
writel(0, gpmc_cfg-irqenable); /* isr's sources masked */
@@ -146,14 +170,31 @@ void gpmc_init(void)
gpmc_config = gpmc_m_nand;
base = PISMO1_NAND_BASE;
- size = PISMO1_NAND_SIZE;
- enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, size);
+ sz = PISMO1_NAND_SIZE;
+ if (!nor_boot)
+ enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, sz);
+ else
+ enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[2], base, sz);
+
#endif
#if defined(CONFIG_CMD_ONENAND)
gpmc_config = gpmc_onenand;
base = PISMO1_ONEN_BASE;
- size = PISMO1_ONEN_SIZE;
- enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, size);
+ sz = PISMO1_ONEN_SIZE;
+ if (!nor_boot)
+ enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, sz);
+ else
+ enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[2], base, sz);
+
+#endif
+
+#if defined(CONFIG_OMAP3_AM3517EVM) defined(CONFIG_SYS_HAS_NORFLASH)
+ /* NOR - CS2 */
+ gpmc_config = gpmc_nor;
+ base = DEBUG_BASE;
+ sz = GPMC_SIZE_64M;
+ if (!nor_boot)
+ enable_gpmc_cs_config(gpmc_nor, gpmc_cfg-cs[2], base, sz);
#endif
}
All the above look very hackish...
You just bring board specific code into a common location.
I don't think we should be doing it this way.
Instead, change the gpmc_init() function signature to get a parameter(s),
so it will be a generic function, that
[U-Boot] [PATCH] powerpc/bootm: Flush ramdisk and device tree image when booting on MP
We already flush the kernel image after we've loaded it to ensure
visiblity to the other cores. We need to do the same thing for the
ramdisk and device tree images. In AMP boot scenarios we might not be
HW cache coherent with the secondary core that we are loading and
setting the ramdisk and device tree up for. Thus we need to ensure
we've flushed the regions of memory utilized by ramdisk and device tree
so the loadding and any modifications (from decompression or fdt updates)
are made visible to the secondary cores.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/lib/bootm.c | 22 --
common/image.c |8
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 8233f1f..efcfe84 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -174,6 +174,18 @@ void arch_lmb_reserve(struct lmb *lmb)
return ;
}
+static void boot_prep_linux(bootm_headers_t *images)
+{
+#ifdef CONFIG_MP
+ /*
+* if we are MP make sure to flush the device tree so any changes are
+* made visibile to all other cores. In AMP boot scenarios the cores
+* might not be HW cache coherent with each other.
+*/
+ flush_cache((unsigned long)images-ft_addr, images-ft_len);
+#endif
+}
+
static int boot_cmdline_linux(bootm_headers_t *images)
{
ulong of_size = images-ft_len;
@@ -329,19 +341,17 @@ int do_bootm_linux(int flag, int argc, char * const
argv[], bootm_headers_t *ima
return 0;
}
- /*
-* We do nothing report success to retain compatiablity with older
-* versions of u-boot in which this use to flush the dcache on MP
-* systems
-*/
- if (flag BOOTM_STATE_OS_PREP)
+ if (flag BOOTM_STATE_OS_PREP) {
+ boot_prep_linux(images);
return 0;
+ }
if (flag BOOTM_STATE_OS_GO) {
boot_jump_linux(images);
return 0;
}
+ boot_prep_linux(images);
ret = boot_body_linux(images);
if (ret)
return ret;
diff --git a/common/image.c b/common/image.c
index aacae5a..77ca6e4 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1104,6 +1104,14 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data,
ulong rd_len,
memmove_wd((void *)*initrd_start,
(void *)rd_data, rd_len, CHUNKSZ);
+#ifdef CONFIG_MP
+ /*
+* Ensure the image is flushed to memory to handle
+* AMP boot scenarios in which we might not be
+* HW cache coherent
+*/
+ flush_cache((unsigned long)*initrd_start, rd_len);
+#endif
puts(OK\n);
}
} else {
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] AM35xx: Read and set ethaddr for EMAC
Hi Steve, Tom,
On 12/06/11 17:49, Tom Rini wrote:
From: Steve Kipisz s-kipi...@ti.com
Signed-off-by: Steve Kipisz s-kipi...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap3/emac.c | 20 +++-
arch/arm/include/asm/arch-omap3/emac_defs.h |3 +++
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/emac.c b/arch/arm/cpu/armv7/omap3/emac.c
index 14667f1..d400bef 100644
--- a/arch/arm/cpu/armv7/omap3/emac.c
+++ b/arch/arm/cpu/armv7/omap3/emac.c
@@ -26,6 +26,7 @@
#include netdev.h
#include asm/io.h
#include asm/arch/am35x_def.h
+#include asm/arch/emac_defs.h
/*
* Initializes on-chip ethernet controllers.
@@ -33,12 +34,29 @@
*/
int cpu_eth_init(bd_t *bis)
{
- u32 reset;
+ u32 reset, msb, lsb;
+ u_int8_t macaddr[6];
+ int i;
/* ensure that the module is out of reset */
reset = readl(am35x_scm_general_regs-ip_sw_reset);
reset = ~CPGMACSS_SW_RST;
writel(reset, am35x_scm_general_regs-ip_sw_reset);
+ /* Read MAC address */
+ msb = readl(EMAC_MACADDR_MSB);
+ lsb = readl(EMAC_MACADDR_LSB);
+
+ for (i = 0; i 3; i++) {
+ macaddr[5 - i] = lsb 0xFF;
+ lsb = 8;
+ }
+
+ for (i = 0; i 3; i++) {
+ macaddr[2 - i] = msb 0xFF;
+ msb = 8;
+ }
+ eth_setenv_enetaddr(ethaddr, macaddr);
+
This is a wrong place for this code...
You force every board to use the EFUSE'd MAC address - this is wrong.
The board must have a freedom to choose what MAC address it wants to use.
You don't even check if ethaddr variable is already set...
What you can do is put this implementation into a separate function
and let board to make a decision if it wants to call it or use another
MAC address.
Something like:
int am3517_get_efuse_enetaddr(u8 *enetaddr)
{
/* read the address and shift or whatever */
...
return is_valid_ether_addr(enetaddr);
}
return davinci_emac_initialize();
}
diff --git a/arch/arm/include/asm/arch-omap3/emac_defs.h
b/arch/arm/include/asm/arch-omap3/emac_defs.h
index 8506c55..c3c96c0 100644
--- a/arch/arm/include/asm/arch-omap3/emac_defs.h
+++ b/arch/arm/include/asm/arch-omap3/emac_defs.h
@@ -42,6 +42,9 @@
#define EMAC_MDIO_BASE_ADDR0x5C03
#define EMAC_HW_RAM_ADDR 0x01E2
+#define EMAC_MACADDR_LSB0x48002380
+#define EMAC_MACADDR_MSB0x48002384
+
#define EMAC_MDIO_BUS_FREQ 16600 /* 166 MHZ check */
#define EMAC_MDIO_CLOCK_FREQ 100 /* 2.0 MHz */
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] AM35xx: Read and set ethaddr for EMAC
On 12/07/2011 07:48 AM, Igor Grinberg wrote:
Hi Steve, Tom,
On 12/06/11 17:49, Tom Rini wrote:
From: Steve Kipisz s-kipi...@ti.com
Signed-off-by: Steve Kipisz s-kipi...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap3/emac.c | 20 +++-
arch/arm/include/asm/arch-omap3/emac_defs.h |3 +++
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/emac.c
b/arch/arm/cpu/armv7/omap3/emac.c
index 14667f1..d400bef 100644
--- a/arch/arm/cpu/armv7/omap3/emac.c
+++ b/arch/arm/cpu/armv7/omap3/emac.c
@@ -26,6 +26,7 @@
#include netdev.h
#include asm/io.h
#include asm/arch/am35x_def.h
+#include asm/arch/emac_defs.h
/*
* Initializes on-chip ethernet controllers.
@@ -33,12 +34,29 @@
*/
int cpu_eth_init(bd_t *bis)
{
-u32 reset;
+u32 reset, msb, lsb;
+u_int8_t macaddr[6];
+int i;
/* ensure that the module is out of reset */
reset = readl(am35x_scm_general_regs-ip_sw_reset);
reset = ~CPGMACSS_SW_RST;
writel(reset, am35x_scm_general_regs-ip_sw_reset);
+/* Read MAC address */
+msb = readl(EMAC_MACADDR_MSB);
+lsb = readl(EMAC_MACADDR_LSB);
+
+for (i = 0; i 3; i++) {
+macaddr[5 - i] = lsb 0xFF;
+lsb = 8;
+}
+
+for (i = 0; i 3; i++) {
+macaddr[2 - i] = msb 0xFF;
+msb = 8;
+}
+eth_setenv_enetaddr(ethaddr, macaddr);
+
This is a wrong place for this code...
You force every board to use the EFUSE'd MAC address - this is wrong.
The board must have a freedom to choose what MAC address it wants to use.
You don't even check if ethaddr variable is already set...
What you can do is put this implementation into a separate function
and let board to make a decision if it wants to call it or use another
MAC address.
Something like:
int am3517_get_efuse_enetaddr(u8 *enetaddr)
{
/* read the address and shift or whatever */
...
return is_valid_ether_addr(enetaddr);
}
That's reasonable enough. I wasn't sure where the custom boards were
getting their MAC as the EVM and Crane both need this change.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 0/4] SPL Linux boot
On 06/12/2011 23:41, Tom Rini wrote: On Tue, Dec 6, 2011 at 11:34 AM, Simon Schwarz simonschwarz...@googlemail.com wrote: Adds direct Linux boot to SPL. It implements a spl export command to save ATAGS or FDT to NAND flash. The kernel image has to be in place for this! After talking with Albert on IRC about this, there's concern about the general impact (esp since the pre-req is a generic change) so it'd be best if people can try and Tested-by this series now and get this in early in the merge window to check for unexpected fallout. Agree with you - I am testing the patches and I am finding some issues - better to be ready when the merge window will open again. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 2/4] omap-common: Add NAND SPL linux booting
On 06/12/2011 19:34, Simon Schwarz wrote:
From: Simon Schwarz simonschwarz...@googlemail.com
This implements booting of Linux from NAND in SPL
Related config parameters:
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is
normally RAM-start + 0x100 (on ARM)
Signed-off-by: Simon Schwarz simonschwarz...@gmail.com
---
Hi Simon,
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 38d06b1..db52879 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -24,6 +24,7 @@
#include asm/u-boot.h
#include asm/utils.h
#include asm/arch/sys_proto.h
+#include asm/io.h
#include nand.h
#include version.h
#include asm/omap_common.h
@@ -32,6 +33,7 @@
void spl_nand_load_image(void)
{
struct image_header *header;
+ int *src, *dst;
switch (omap_boot_mode()) {
case NAND_MODE_HW_ECC:
debug(spl: nand - using hw ecc\n);
@@ -45,26 +47,56 @@ void spl_nand_load_image(void)
/*use CONFIG_SYS_TEXT_BASE as temporary storage area */
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+#ifdef CONFIG_SPL_OS_BOOT
+ if (!spl_uboot_key()) {
Using a gpio or whatever mechanis is baord specific. What about to set a
weak function and let that the board decides itself what to do ?
Not always a GPIO can be used for this purpose.
I have noted another issue. If the kernel image is not found, the
fallback is to load u-boot. However, u-boot is searched at the address
in NAND of the kernel, not at CONFIG_SYS_NAND_U_BOOT_OFFS.
This means that if the kernel is not loaded at all, the SPL starts to
start a u-boot.bin instead of u-boot.img loaded at
CONFIG_CMD_SPL_NAND_OFS, and this fails.
+ /*
+ * load parameter image
+ * load to temp position since nand_spl_load_image reads
+ * a whole block which is typically larger than
+ * CONFIG_CMD_SAVEBP_WRITE_SIZE therefore may overwrite
+ * following sections like BSS
+ */
+ nand_spl_load_image(CONFIG_CMD_SPL_NAND_OFS,
+ CONFIG_CMD_SPL_WRITE_SIZE,
+ (void *)CONFIG_SYS_TEXT_BASE);
+ /* copy to destintion */
+ for (dst = (int *)CONFIG_SYS_SPL_ARGS_ADDR,
+ src = (int *)CONFIG_SYS_TEXT_BASE;
+ src (int *)(CONFIG_SYS_TEXT_BASE +
+ CONFIG_CMD_SPL_WRITE_SIZE);
+ src++, dst++) {
+ writel(readl(src), dst);
+ }
+ /* load linux */
+ nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
So if the parse function fails, we should have the fallback to u-boot,
exactly as we have now the fallback from u-boot.img to u-boot.bin.
The function you write are in omap-common/spl_nand.c, but they are not
specific for OMAP, and any architecture can profit from your work. What
about to move common functions away from TI related directory ? I do not
know which is the best place, maybe a new directory under the root as
spllib ?
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 0/4] SPL Linux boot
On 06/12/2011 19:34, Simon Schwarz wrote: Adds direct Linux boot to SPL. It implements a spl export command to save ATAGS or FDT to NAND flash. The kernel image has to be in place for this! Changes in V5: - Rebased on u-boot-ti - fixed MAKEALL warnings and errors - adapted to general gpio interface Changes in V6: - Change old commit message Changes in V7: - Correct style and format errors Changes in V8: - rebased on u-boot Changes in V9: - Deleted a left-over patch from the series this also fixed the first problem mentioned here: - http://article.gmane.org/gmane.comp.boot-loaders.u-boot/119452 based on: - Prep subcommand patch for arm (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/106725) Hi Simon, I am testing your patches (V9) - the kernel image is not corrupted anynmore due to the ECC, but I am not able to boot successfully the kernel. I am testing now with a second hardware (twister, I have recently posted the patches for this board, also OMAP3) to have a comparison with the beagleboard. The kernel starts but it stops very soon, I think after the machine-id check and it seems it cannot poarse correctly the tags. However, the parameters exported by spl export are correct and I have not found any difference with the bootm command under U-boot. I am starting to debug the kernel to get some more infos, but do you have some hints ? How do you test it ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Non-OMAP/DaVinci ARM SPL? (Was: Re: [PATCH V9 2/4] omap-common: Add NAND SPL linux booting)
On Wed, Dec 7, 2011 at 8:39 AM, Stefano Babic sba...@denx.de wrote: [snip] The function you write are in omap-common/spl_nand.c, but they are not specific for OMAP, and any architecture can profit from your work. What about to move common functions away from TI related directory ? I do not know which is the best place, maybe a new directory under the root as spllib ? There's a lot of thinking and reworking we should do for the SPL code we have today under arch/arm, both in terms of sharing between davinci and OMAP(ish) and non-TI parts. My question is, for non-TI stuff, is anyone using or about to start using this framework? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc5200: digsy_mtc: Fix extension board detection
Switch to extension board detection using pci_find_device()
instead of detecting by i2c access to EEPROM device on
extension board.
This is a cleaner detection method since EEPROM addresses
can be different on different board revisions. This also
avoids i2c_read: failed to address chip error messages
in the boot log on boards without extension board which
may confuse users.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
board/intercontrol/digsy_mtc/digsy_mtc.c | 15 ---
include/configs/digsy_mtc.h |7 ---
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/board/intercontrol/digsy_mtc/digsy_mtc.c
b/board/intercontrol/digsy_mtc/digsy_mtc.c
index 4d6b33d..4aa56b2 100644
--- a/board/intercontrol/digsy_mtc/digsy_mtc.c
+++ b/board/intercontrol/digsy_mtc/digsy_mtc.c
@@ -49,6 +49,7 @@
#include libfdt.h
#include fdt_support.h
#include i2c.h
+#include mb862xx.h
DECLARE_GLOBAL_DATA_PTR;
@@ -226,11 +227,6 @@ static void exbo_hw_init(void)
struct mpc5xxx_gpio *gpio = (struct mpc5xxx_gpio *)MPC5XXX_GPIO;
struct mpc5xxx_wu_gpio *wu_gpio =
(struct mpc5xxx_wu_gpio *)MPC5XXX_WU_GPIO;
- unsigned char val;
-
- /* 1st, check if extension board is present */
- if (i2c_read(CONFIG_SYS_EXBO_EE_I2C_ADDRESS, 0, 1, val, 1))
- return;
/* configure IrDA pins (PSC6 port) as gpios */
gpio-port_config = 0xFF8F;
@@ -285,8 +281,6 @@ int board_early_init_r(void)
/* enable CS0 */
setbits_be32((void *)MPC5XXX_ADDECR, (1 16));
- exbo_hw_init();
-
#if defined(CONFIG_USB_OHCI_NEW) defined(CONFIG_SYS_USB_OHCI_CPU_INIT)
/* Low level USB init, required for proper kernel operation */
usb_cpu_init();
@@ -326,8 +320,15 @@ void board_get_enetaddr (uchar * enet)
int misc_init_r(void)
{
+ pci_dev_t devbusfn;
uchar enetaddr[6];
+ /* check if graphic extension board is present */
+ devbusfn = pci_find_device(PCI_VENDOR_ID_FUJITSU,
+ PCI_DEVICE_ID_CORAL_PA, 0);
+ if (devbusfn != -1)
+ exbo_hw_init();
+
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(enetaddr);
eth_setenv_enetaddr(ethaddr, enetaddr);
diff --git a/include/configs/digsy_mtc.h b/include/configs/digsy_mtc.h
index 1e52299..40ab631 100644
--- a/include/configs/digsy_mtc.h
+++ b/include/configs/digsy_mtc.h
@@ -293,13 +293,6 @@
#define CONFIG_SYS_DS1339_TCR_VAL 0xAB/* diode + 4k resistor */
#endif
-/* ExBo I2C Addresses */
-#if defined(CONFIG_DIGSY_REV5)
-#define CONFIG_SYS_EXBO_EE_I2C_ADDRESS 0x54
-#else
-#define CONFIG_SYS_EXBO_EE_I2C_ADDRESS 0x56
-#endif
-
/*
* Flash configuration
*/
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-OMAP/DaVinci ARM SPL? (Was: Re: [PATCH V9 2/4] omap-common: Add NAND SPL linux booting)
On 12/07/11 18:00, Tom Rini wrote: On Wed, Dec 7, 2011 at 8:39 AM, Stefano Babic sba...@denx.de wrote: [snip] The function you write are in omap-common/spl_nand.c, but they are not specific for OMAP, and any architecture can profit from your work. What about to move common functions away from TI related directory ? I do not know which is the best place, maybe a new directory under the root as spllib ? There's a lot of thinking and reworking we should do for the SPL code we have today under arch/arm, both in terms of sharing between davinci and OMAP(ish) and non-TI parts. My question is, for non-TI stuff, is anyone using or about to start using this framework? I think NVIDIA Tegra can benefit from this. Added Simon Glass to Cc. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10] Use CMD_RET_usage in i2c
Hi Heiko,
On Tue, Dec 6, 2011 at 11:16 PM, Heiko Schocher h...@denx.de wrote:
Hello Simon,
Simon Glass wrote:
This small patch converts the I2C command over to using the
CMD_RET_USAGE return value instead of calling cmd_usage()
directly.
Signed-off-by: Simon Glass s...@chromium.org
---
common/cmd_i2c.c | 36 +++-
1 files changed, 19 insertions(+), 17 deletions(-)
First, why did you seperate the changes in cmd_i2c.c from
the other same changes in your Convert cmd_usage() calls in
common to use a return value patch? Is there a special reason
for this?
[Well, since you asked, there are quite a few changes in this file,
and initially I was planning to split the changes into a number of
small commits for each file in common/. But there are a lot of files,
and I was unsure of the utility of the patch anyway, so I put the rest
in a single patch. But on the other hand, there would be no reason to
merge this and not the others I suppose]
I will squash this patch.
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index e795139..165f1f2 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
[...]
@@ -1208,7 +1208,9 @@ static int do_i2c_add_bus(cmd_tbl_t * cmdtp, int flag,
int argc, char * const ar
device = device-next;
}
} else {
- (void)i2c_mux_ident_muxstring ((uchar *)argv[1]);
+ I2C_MUX_DEVICE *dev;
+
+ dev = i2c_mux_ident_muxstring((uchar *)argv[1]);
No, this will result in this warning:
cmd_i2c.c: In function 'do_i2c_add_bus':
cmd_i2c.c:1212:19: warning: variable 'dev' set but not used
[-Wunused-but-set-variable]
Thanks, will fix in next pass.
Regards,
Simon
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Pending patches for december release?
On 12/06/2011 06:18 PM, Simon Glass wrote: Hi Albert, On Mon, Dec 5, 2011 at 10:05 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi all, As I don't have much time and the december release is coming soon, I would appreciate that anyone with a patch that they think should go to ARM master now please send me an e-mail with the link to the patchwork patch page so that I delegate the patch to myself. If the patch is already delegated to me, then nothing need be done. Of course, if you can directly delegate a patchwork patch to me, just do so. I have a series here which is still pending: http://patchwork.ozlabs.org/patch/128187/ http://patchwork.ozlabs.org/patch/128183/ http://patchwork.ozlabs.org/patch/128185/ http://patchwork.ozlabs.org/patch/128188/ http://patchwork.ozlabs.org/patch/128192/ http://patchwork.ozlabs.org/patch/128186/ http://patchwork.ozlabs.org/patch/128189/ I have delegated it to you in patchwork (except for 2/7 which Marek already has). Won't these go through u-boot-tegra.git now that it exists and is ramping up? Taking Tegra patches both though u-boot-tegra and u-boot-arm seems like it'll cause problems. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Change to miiphy_register() creates warnings
Hi Wolfgang, On Tue, Dec 6, 2011 at 11:39 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message CAPnjgZ0tGPnZOQ7eBRwt5noHHVw_z3KY=qcyh_gsxkfxs2k...@mail.gmail.com you wrote: In this commit: 5c45a22 mii: miiphy register address width change the required prototypes for the read and write functions passed to miiphy_register() were changed. However, from what I can tell the callers to miiphy_register() did not all get their functions changes. So there are now a lot of warnings. I doubt they will affect actual operation. Chandan, do you have time to do a patch for this? Files that use this are listed below, but not all will require changes - just changing the other use in miiphy.h would help a lot. ./arch/arm/cpu/ixp/npe/npe.c ./arch/mips/cpu/mips32/au1x00/au1x00_eth.c ./arch/powerpc/cpu/mpc85xx/ether_fcc.c ./arch/powerpc/cpu/mpc8220/fec.c ./arch/powerpc/cpu/mpc8xx/fec.c ./arch/powerpc/cpu/mpc8260/ether_fcc.c ./board/evb64260/eth.c ./board/prodrive/p3mx/mv_eth.c ./board/gdsys/405ex/io64.c ./board/gdsys/405ep/io.c ./common/miiphyutil.c ./drivers/qe/uec.c ./drivers/net/fsl_mcdmafec.c ./drivers/net/macb.c ./drivers/net/mpc5xxx_fec.c ./drivers/net/davinci_emac.c ./drivers/net/mcffec.c ./drivers/net/enc28j60.c ./drivers/net/smc911x.c ./drivers/net/altera_tse.c ./drivers/net/ep93xx_eth.c ./drivers/net/at91_emac.c ./drivers/net/sh_eth.c ./drivers/net/bfin_mac.c ./drivers/net/mpc512x_fec.c ./drivers/net/xilinx_axi_emac.c ./drivers/net/mvgbe.c ./drivers/net/armada100_fec.c ./drivers/net/designware.c ./drivers/net/4xx_enet.c ./drivers/net/fec_mxc.c ./drivers/net/eepro100.c It makes no sense fixing all these drivers just to keep the old API longer alive. I reverted the commit. Well that will fix the problem, thank you. Regards, Simon 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 Wait! You have not been prepared! -- Mr. Atoz, Tomorrow is Yesterday, stardate 3113.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/bootm: Flush ramdisk and device tree image when booting on MP
On Wed, Dec 7, 2011 at 8:42 AM, Kumar Gala ga...@kernel.crashing.org wrote:
+ if (flag BOOTM_STATE_OS_PREP) {
+ boot_prep_linux(images);
return 0;
+ }
if (flag BOOTM_STATE_OS_GO) {
boot_jump_linux(images);
return 0;
}
+ boot_prep_linux(images);
Why are we calling boot_prep_linux(images) when flag
BOOTM_STATE_OS_PREP is zero? If we don't want the OS to be PREPped,
then why call a function named boot_prep_linux()?
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 5/7] reboard: arm: Add processor function library
Hi Albert, On Tue, Dec 6, 2011 at 11:44 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Simon, Le 22/11/2011 00:57, Simon Glass a écrit : Add a library to hold ARM assembler code which is generic across all ARM CPUs. Signed-off-by: Simon Glasss...@chromium.org --- arch/arm/lib/Makefile | 1 + arch/arm/lib/proc.S | 35 +++ 2 files changed, 36 insertions(+), 0 deletions(-) create mode 100644 arch/arm/lib/proc.S diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index ca2802a..27749dc 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -50,6 +50,7 @@ endif ifndef CONFIG_SYS_LEGACY_BOARD COBJS-y += arch_reloc.o +SOBJS-y += proc.o endif SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \ diff --git a/arch/arm/lib/proc.S b/arch/arm/lib/proc.S new file mode 100644 index 000..99a2944 --- /dev/null +++ b/arch/arm/lib/proc.S @@ -0,0 +1,35 @@ +/* + * Copyright (c) 2011 The Chromium OS Authors. + * 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 + */ + + +/** + * Jump to board_init_r with a new stack pointer + * + * @param gd Pointer to global data + * @param dest_addr Destination address from global data + * @param func Address of board_init_r function (relocated) + * @param sp New stack pointer + */ +.globl proc_call_board_init_r +proc_call_board_init_r: + mov sp, r3 + /* jump to it ... */ + mov pc, r2 What do we gain from this patch exactly? The idea is to create a library to hold ARM assembler code which is generic across all (or even most) ARM CPUs. So far it is just relocation, but I feel that exception handling could move here too eventually. IMO start.S is a bad place for this sort of thing - it is private to each cpu type so people tend to copy and paste large tracts of code and it doesn't feel right to call back into your startup code later to do things. So I suggest a proc.S (or some other name) with processor-level functions which are generic across ARM. We can then move this code from all the little start.S files into one place, and maintain it more easily. Yes this is a trivial wee patch, but it's good to start the discussion with something. Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] reboard: define CONFIG_SYS_LEGACY_BOARD everywhere
Hi Albert, On Wed, Dec 7, 2011 at 12:15 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Le 30/11/2011 00:40, Simon Glass a écrit : Hi Mike, On Tue, Nov 29, 2011 at 3:19 PM, Mike Frysingervap...@gentoo.org wrote: On Tuesday 29 November 2011 17:09:19 Simon Glass wrote: On Tue, Nov 29, 2011 at 1:40 PM, Mike Frysinger wrote: On Tuesday 29 November 2011 15:08:09 Simon Glass wrote: On Mon, Nov 28, 2011 at 7:11 PM, Mike Frysinger wrote: On Monday 21 November 2011 18:57:54 Simon Glass wrote: We are introducing a new unified board setup and we want this to be the default. So we need to opt all architectures out first. the define says BOARD, so shouldn't it be in board configs ? we can do that easily: add it to include/config_defaults.h. then boards that opt into it will #undef it in their own configs. Thanks for looking at this. I see this as an architecture feature - perhaps a rename to something like CONFIG_LEGACY_ARCH would help? I quite badly want to avoid moving boards over one at a time, or having boards for a particular architecture that still do things the old way - it just increases maintenance and means that my eventual patch to remove arch/xxx/lib/board.c cannot be applied. My idea for this CONFIG is purely as a temporary measure before boards more over to the generic approach. how about we have the reloc code live in lib/reloc/ and be controlled by CONFIG_LEGACY_ARCH_RELOC ? My only concern is that if something like SPL needs to keep all the early code at the start of the image. I personally don't like the current method for doing that (would prefer a distinctive .text.early section name) and I don't believe that any SPL implementation actually relocates itself. not sure why this matters ? -mike Because if they require linking with reloc.o then we will get link failures some boards. There is some ugly stuff in SPL which pulls in particular files from around U-Boot. Any time I split something out of start.S I may break something. IIRC, SPL never relocates itself -- the goal of SPL is to get some code in memory that will just enable RAM, move the rest of U-Boot in, and jump to it. What SPL pulls in is drivers/ functions for console output and access to the RAM and main U-Boot image. Besides, sometimes making boards all fail until they are fixed is a good way to manage a change. :) OK it sounds like SPL won't cause problems with this series, good. Regards, Simon Regards, Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] Convert cmd_usage() calls in common to use a return value
Hi Igor, On Wed, Dec 7, 2011 at 4:47 AM, Igor Grinberg grinb...@compulab.co.il wrote: Hi Simon, On 12/07/11 07:47, Simon Glass wrote: Change all files in common/ to use CMD_RET_USAGE instead of calling cmd_usage() directly. I'm not completely sure about this patch since the code since impact is small (100 byte or so on ARM) and it might need splitting into smaller patches. But for now here it is. Signed-off-by: Simon Glass s...@chromium.org --- [...] diff --git a/common/cmd_mmc_spi.c b/common/cmd_mmc_spi.c index cfd0fb1..3153610 100644 --- a/common/cmd_mmc_spi.c +++ b/common/cmd_mmc_spi.c @@ -78,7 +78,7 @@ static int do_mmc_spi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) return 0; usage: - cmd_usage(cmdtp); + return CMD_RET_USAGE; return 1; You, probably, also want to remove the above line... Will do, thanks. Regards, Simon [...] -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-OMAP/DaVinci ARM SPL? (Was: Re: [PATCH V9 2/4] omap-common: Add NAND SPL linux booting)
On 07/12/2011 17:00, Tom Rini wrote: On Wed, Dec 7, 2011 at 8:39 AM, Stefano Babic sba...@denx.de wrote: [snip] The function you write are in omap-common/spl_nand.c, but they are not specific for OMAP, and any architecture can profit from your work. What about to move common functions away from TI related directory ? I do not know which is the best place, maybe a new directory under the root as spllib ? There's a lot of thinking and reworking we should do for the SPL code we have today under arch/arm, both in terms of sharing between davinci and OMAP(ish) and non-TI parts. My question is, for non-TI stuff, is anyone using or about to start using this framework? I am still using with TI, but my goal is to have it available for the IMX SOCs, too. Some of them boot with old spl code (MX3x), and some of them (MX5 and in future MX6) need it and it would be nice to reuse the code. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-OMAP/DaVinci ARM SPL? (Was: Re: [PATCH V9 2/4] omap-common: Add NAND SPL linux booting)
Hi, On Wed, Dec 7, 2011 at 8:17 AM, Igor Grinberg grinb...@compulab.co.il wrote: On 12/07/11 18:00, Tom Rini wrote: On Wed, Dec 7, 2011 at 8:39 AM, Stefano Babic sba...@denx.de wrote: [snip] The function you write are in omap-common/spl_nand.c, but they are not specific for OMAP, and any architecture can profit from your work. What about to move common functions away from TI related directory ? I do not know which is the best place, maybe a new directory under the root as spllib ? There's a lot of thinking and reworking we should do for the SPL code we have today under arch/arm, both in terms of sharing between davinci and OMAP(ish) and non-TI parts. My question is, for non-TI stuff, is anyone using or about to start using this framework? I think NVIDIA Tegra can benefit from this. Added Simon Glass to Cc. The Tegra boot rom can load the whole U-Boot in from various media types so we haven't had to use SPL to date. I have been trying out a way of moving a good chunk of the code (that is useful to devs but not used in a normal boot) into the back end of the image to load later. But this is just a link trick and not really related to SPL (although I think it might have application if we want to generalise SPL). Samsung and Freescale use it I think. I agree that SPL code should be as generic as possible. Regards, Simon -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Append board name to version identifier
so it is printed as part of the version command and visible when
displaying the image in the various flash banks.
This allows strings u-boot.bin | head -1 to identify target:
VU-Boot 2011.09-01427-g6ee5cf2 (Dec 07 2011 - 11:11:55) P4080DS
Signed-off-by: Ed Swarthout ed.swarth...@freescale.com
---
include/version.h |2 +-
mkconfig |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/version.h b/include/version.h
index c908bd3..58f42e1 100644
--- a/include/version.h
+++ b/include/version.h
@@ -35,7 +35,7 @@
#endif
#define U_BOOT_VERSION_STRING U_BOOT_VERSION ( U_BOOT_DATE - \
- U_BOOT_TIME ) CONFIG_IDENT_STRING
+ U_BOOT_TIME ) BOARD_NAME CONFIG_IDENT_STRING
#ifndef __ASSEMBLY__
extern const char version_string[];
diff --git a/mkconfig b/mkconfig
index 438530b..50bd731 100755
--- a/mkconfig
+++ b/mkconfig
@@ -155,6 +155,7 @@ else
config.h # Create new config file
fi
echo /* Automatically generated - do not edit */ config.h
+echo #define BOARD_NAME \${BOARD_NAME}\ config.h
for i in ${TARGETS} ; do
i=`echo ${i} | sed '/=/ {s/=/ /;q; } ; { s/$/ 1/; }'`
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [PCI] Update pci_ids.h from current Linux sources
On Wed, 7 Dec 2011 18:10:55 +0100 Anatolij Gustschin ag...@denx.de wrote: ... include/pci_ids.h | 2072 - 1 files changed, 1420 insertions(+), 652 deletions(-) Applied to u-boot-staging/ag...@denx.de. Thanks! Dropped applied patch, it causes many build issues. The patch in my staging branch is replaced by v2 patch. Ah, it will take a while till the v2 patch appears on the ML. The patch is too big and thus moderated. Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fwd: [PATCH v6 1/2] Introduce generic TPM support in u-boot
Dear Wolfgang Denk, On Tue, Dec 6, 2011 at 11:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Vadim Bendebury, [..] Applied, thanks. Thank you! But _please_ get used to providing full change logs to your patches. This is patch v6, so I would like to see a history for v2, v3, v4, v5 and v6 - but all you have is a totally useless (as incomprehensible) comment for v5. Do you mean all newer patch versions are supposed to include logs of all previous patch versions? I can do that, somehow nobody mentioned this omission while reviewing previous patches (up to version 5). Cheers, /vb 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 Anyone who doesn't believe in miracles is not a realist. - David Ben Gurion ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] USB: Add generic ULPI layer and a viewport
On 12/07/11 03:42, Simon Glass wrote:
Hi Igor,
Looks good - a few comments from me.
On Mon, Dec 5, 2011 at 1:07 AM, Igor Grinberg grinb...@compulab.co.il
wrote:
From: Jana Rapava ferma...@gmail.com
Add partial ULPI specification implementation that should be enough to
interface the ULPI PHYs in the boot loader context.
Add a viewport implementation for Chipidea/ARC based controllers.
Signed-off-by: Jana Rapava ferma...@gmail.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Remy Bohmer li...@bohmer.net
Cc: Stefano Babic sba...@denx.de
Cc: Wolfgang Grandegger w...@denx.de
Cc: Simon Glass s...@chromium.org
---
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 118 +++
drivers/usb/ulpi/ulpi.c | 227 +
include/usb/ulpi.h | 298
++
This would benefit from additions to the README describing the two new
CONFIGs you add.
5 files changed, 688 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
create mode 100644 include/usb/ulpi.h
diff --git a/drivers/usb/ulpi/ulpi.c b/drivers/usb/ulpi/ulpi.c
new file mode 100644
index 000..805e29d
--- /dev/null
+++ b/drivers/usb/ulpi/ulpi.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright (C) 2011 Jana Rapava ferma...@gmail.com
+ * Copyright (C) 2011 CompuLab, Ltd. www.compulab.co.il
+ *
+ * Authors: Jana Rapava ferma...@gmail.com
+ * Igor Grinberg grinb...@compulab.co.il
+ *
+ * Based on:
+ * linux/drivers/usb/otg/ulpi.c
+ * Generic ULPI USB transceiver support
+ *
+ * Original Copyright follow:
+ * Copyright (C) 2009 Daniel Mack dan...@caiaq.de
+ *
+ * Based on sources from
+ *
+ * Sascha Hauer s.ha...@pengutronix.de
+ * Freescale Semiconductors
+ *
+ * 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.
+ */
+
+#include common.h
+#include exports.h
+#include usb/ulpi.h
+
+#define ULPI_ID_REGS_COUNT 4
+#define ULPI_TEST_VALUE0x55/* 0x55 == 0b01010101 */
+
+static struct ulpi_regs *ulpi = (struct ulpi_regs *)0;
+
+static int ulpi_integrity_check(u32 ulpi_viewport)
+{
+ u32 err, val, tval = ULPI_TEST_VALUE;
+ int i;
+
+ /* Use the 'special' test value to check all bits */
+ for (i = 0; i 2; i++, tval = 1) {
+ err = ulpi_write(ulpi_viewport, ulpi-scratch, tval);
+ if (err)
+ return err;
+
+ val = ulpi_read(ulpi_viewport, ulpi-scratch);
+ if (val != tval) {
+ printf(ULPI integrity check failed\n);
+ return val;
+ }
+ }
+
+ return 0;
+}
+
+int ulpi_init(u32 ulpi_viewport)
+{
+ u32 val, id = 0;
+ u8 *reg = ulpi-product_id_high;
+ int i;
+
+ /* Assemble ID from four ULPI ID registers (8 bits each). */
+ for (i = 0; i ULPI_ID_REGS_COUNT; i++) {
+ val = ulpi_read(ulpi_viewport, reg - i);
+ if (val == ULPI_ERROR)
+ return val;
+
+ id = (id 8) | val;
+ }
+
+ /* Split ID into vendor and product ID. */
+ debug(ULPI transceiver ID 0x%04x:0x%04x\n, id 16, id
0x); +
+ return ulpi_integrity_check(ulpi_viewport);
+}
+
+int ulpi_select_transceiver(u32 ulpi_viewport, u8 speed)
Is there any point in making the argument u8?
Not really...
How about just unsigned?
Sounds sane
I think this adds a mask to the call = larger code size. You check the
arg with the switch() below anyway.
Haven't thought about that...
I don't know how is this exactly works, but I don't see
any reason why shouldn't I use unsigned here.
+{
+ u8 tspeed = ULPI_FC_FULL_SPEED;
+ u32 val;
+
+ switch (speed) {
+ case ULPI_FC_HIGH_SPEED:
+ case ULPI_FC_FULL_SPEED:
+ case ULPI_FC_LOW_SPEED:
+ case ULPI_FC_FS4LS:
+ tspeed = speed;
+ break;
+ default:
+ printf(ULPI: %s: wrong transceiver speed specified,
+ falling back to full speed\n, __func__);
Re: [U-Boot] [PATCH v7] Add generic ULPI layer
On 12/07/11 14:59, Igor Grinberg wrote:
Hi Marek,
On 12/07/11 01:49, Marek Vasut wrote:
Although it is a single patch, I felt that a cover letter will
definetly not hurt here, also the patch version history is so big, so
I decided to move it here.
The ULPI (UTMI Low Pin (count) Interface) PHYs are widely used on
variety of boards. This requires a generic architecture independant
implementation which can be reused and will eliminate the need for
direct write of arbitrary values to the ULPI transciever.
Although, the generic implementation can be reused on any architecture,
the access to ULPI PHY must be done in a platform specific way.
The platform specific way is in majority of case called a viewport.
Also, the ULPI specification defines a hybrid aproach for managing the
ULPI PHY. That is, the PHY must be managed through both the PHY
registers and control lines.
The proposed patch provides a partial implementation of the ULPI
specification, which should be enough for boot loader use cases,
and a viewport implementation for Chipidea/ARC based controllers,
which, AFAIK, are used on imx and tegra SoCs.
It is based on the Wolfgang's master branch (4 Dec 2012),
compile tested and checkpatch clean.
What is still missing, IMO:
- documentation for the CONFIG_* macros (I can add it in a separate
patch)
- a way to make most of the initialization in one ulpi_init() call
- viewport extension to be able to implement resume,
reset and disabling the serial mode
The change log:
Changes for v2:
- make code EHCI-independent
- use udelay() in waiting loop
- mark static functions as static
- naming changes
Changes for v3:
- merge with patch ulpi: add generic ULPI support header file
- rewrite ULPI interface in more functionality-oriented way
Changes for v4:
- add error-checking
- add waiting for completion into ulpi_reset() function
Changes for v5:
- CodingStyle changes
- add comments
- simplify implemenation of the ULPI interface functions
Changes for v6:
- cleanup function ulpi_drive_vbus()
Changes for v7:
- ulpi-viewport.c:
- reorder bit definitions
- split ulpi_request() to two functions
- reuse ulpi_wakeup() from ulpi_request()
to remove duplicated calls from ulpi_{read|write}()
- inline ulpi_*_mask as it is simple and used only once
- ulpi.c:
- move several defines into c file
- rework all the functions to propagate error values
- move function description comments into ulpi.h
along with declarations
- check arguments validity (as suggested by Simon)
- fix cases when using the *_set register,
bits cannot be cleared
- shorten several arguments names (e.g. ulpi_set_vbus())
- add ability to disable VBUS
- clean up ulpi_set_pd()
- add ability to enter the serial mode
- add verbosity in error cases
- remove ulpi_resume() as it were wrong and
must be implemented in a viewport specific way
- rework ulpi_reset() as it must be implemented in a
viewport specific way, but provide kind of generic
implementation which should work in most of the cases
- ulpi.h:
- add default timeout value
- remove unused defines
- move several defines inside c files
- add description for each function
- move the API declaration to the top of the header file
Jana Rapava (1):
USB: Add generic ULPI layer and a viewport
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 118 +++
drivers/usb/ulpi/ulpi.c | 227 +
include/usb/ulpi.h | 298
++ 5 files changed, 688
insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
create mode 100644 include/usb/ulpi.h
Igor, please add Cc annotations to this patch too.
Well, I indeed forgot this, but I've send a forward of this email
to everybody supposed to be in Cc. Adding Cc once again...
That's interesting...
I've added much more people to Cc, than those listed currently...
It looks like the bounce from the list eats the Cc partially...
Exactly, I noticed this earlier in some other emails too. Detlev, can you
please
verify?
M
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH V9 0/4] SPL Linux boot
On 12/07/2011 04:52 PM, Stefano Babic wrote: On 06/12/2011 19:34, Simon Schwarz wrote: Adds direct Linux boot to SPL. It implements a spl export command to save ATAGS or FDT to NAND flash. The kernel image has to be in place for this! Changes in V5: - Rebased on u-boot-ti - fixed MAKEALL warnings and errors - adapted to general gpio interface Changes in V6: - Change old commit message Changes in V7: - Correct style and format errors Changes in V8: - rebased on u-boot Changes in V9: - Deleted a left-over patch from the series this also fixed the first problem mentioned here: - http://article.gmane.org/gmane.comp.boot-loaders.u-boot/119452 based on: - Prep subcommand patch for arm (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/106725) Hi Simon, I am testing your patches (V9) - the kernel image is not corrupted anynmore due to the ECC, but I am not able to boot successfully the kernel. I am testing now with a second hardware (twister, I have recently posted the patches for this board, also OMAP3) to have a comparison with the beagleboard. The kernel starts but it stops very soon, I think after the machine-id check and it seems it cannot poarse correctly the tags. However, the parameters exported by spl export are correct and I have not found any difference with the bootm command under U-boot. I am starting to debug the kernel to get some more infos, but do you have some hints ? How do you test it ? Best regards, Stefano Babic Hi Stefano, great that someone has a closer look on this! The only problem i had was a wrong machine id (The one to use is defined in the board config file). So I didn't do any debugging in the kernel besides from activating early printk. Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] AM35xx: Read and set ethaddr for EMAC
Dear Tom Rini,
In message 4edf7e34.1070...@ti.com you wrote:
This is a wrong place for this code...
You force every board to use the EFUSE'd MAC address - this is wrong.
The board must have a freedom to choose what MAC address it wants to use.
You don't even check if ethaddr variable is already set...
What you can do is put this implementation into a separate function
and let board to make a decision if it wants to call it or use another
MAC address.
Something like:
int am3517_get_efuse_enetaddr(u8 *enetaddr)
{
/* read the address and shift or whatever */
...
return is_valid_ether_addr(enetaddr);
}
That's reasonable enough. I wasn't sure where the custom boards were
getting their MAC as the EVM and Crane both need this change.
The rule is that the settings in the environment always have
precedence, and you must never overwrite an existing eth*addr in
the environment.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
They that can give up essential liberty to obtain a little temporary
saftey deserve neither liberty not saftey. - Benjamin Franklin, 1759
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
Hi Stefano, On 07.12.2011 13:06, Stefano Babic wrote: +#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x1) +#endif Maybe it is better to not have a default value somewhere in the SDRAM and to get a compile error. If we do not want to fix also the related My intention was not to break something as I can't fix every board using this driver. That's why I preserved the existing address for the case where CONFIG_SPL_NAND_WORKSPACE is not defined. boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...). Probably. Wolfgang, Scott, do you think we should add a warning here? Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] net: add Calxeda xgmac driver
From: Rob Herring rob.herr...@calxeda.com This adds ethernet driver for Calxeda xgmac found on Highbank SOC. Signed-off-by: Rob Herring rob.herr...@calxeda.com --- v2: -Convert register base plus offset to a struct -drop ethaddr env setting -drop valid mac address check -fix return values README |3 + drivers/net/Makefile |1 + drivers/net/calxedaxgmac.c | 554 include/netdev.h |1 + 4 files changed, 559 insertions(+), 0 deletions(-) create mode 100644 drivers/net/calxedaxgmac.c diff --git a/README b/README index fda0190..c7b6264 100644 --- a/README +++ b/README @@ -1003,6 +1003,9 @@ The following options need to be configured: If this defined, the driver is quiet. The driver doen't show link status messages. + CONFIG_CALXEDA_XGMAC + Support for the Calxeda XGMAC device + CONFIG_DRIVER_LAN91C96 Support for SMSC's LAN91C96 chips. diff --git a/drivers/net/Makefile b/drivers/net/Makefile index d3df82e..f4f7ea3 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -31,6 +31,7 @@ COBJS-$(CONFIG_ARMADA100_FEC) += armada100_fec.o COBJS-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o COBJS-$(CONFIG_BFIN_MAC) += bfin_mac.o +COBJS-$(CONFIG_CALXEDA_XGMAC) += calxedaxgmac.o COBJS-$(CONFIG_CS8900) += cs8900.o COBJS-$(CONFIG_TULIP) += dc2114x.o COBJS-$(CONFIG_DESIGNWARE_ETH) += designware.o diff --git a/drivers/net/calxedaxgmac.c b/drivers/net/calxedaxgmac.c new file mode 100644 index 000..ca08049 --- /dev/null +++ b/drivers/net/calxedaxgmac.c @@ -0,0 +1,554 @@ +/* + * Copyright 2010-2011 Calxeda, Inc. + * + * 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 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, see http://www.gnu.org/licenses/. + */ +#include common.h +#include malloc.h +#include linux/err.h +#include asm/io.h + +#define TX_NUM_DESC1 +#define RX_NUM_DESC32 + +#define MAC_TIMEOUT(5*CONFIG_SYS_HZ) + +#define ETH_BUF_SZ 2048 +#define TX_BUF_SZ (ETH_BUF_SZ * TX_NUM_DESC) +#define RX_BUF_SZ (ETH_BUF_SZ * RX_NUM_DESC) + +#define RXSTART0x0002 +#define TXSTART0x2000 + +#define RXENABLE 0x0004 +#define TXENABLE 0x0008 + +#define XGMAC_CONTROL_SPD 0x4000 +#define XGMAC_CONTROL_SPD_MASK 0x6000 +#define XGMAC_CONTROL_SARC 0x1000 +#define XGMAC_CONTROL_SARK_MASK0x1800 +#define XGMAC_CONTROL_CAR 0x0400 +#define XGMAC_CONTROL_CAR_MASK 0x0600 +#define XGMAC_CONTROL_CAR_SHIFT25 +#define XGMAC_CONTROL_DP 0x0100 +#define XGMAC_CONTROL_WD 0x0080 +#define XGMAC_CONTROL_JD 0x0040 +#define XGMAC_CONTROL_JE 0x0010 +#define XGMAC_CONTROL_LM 0x1000 +#define XGMAC_CONTROL_IPC 0x0400 +#define XGMAC_CONTROL_ACS 0x0080 +#define XGMAC_CONTROL_DDIC 0x0010 +#define XGMAC_CONTROL_TE 0x0008 +#define XGMAC_CONTROL_RE 0x0004 + +#define XGMAC_DMA_BUSMODE_RESET0x0001 +#define XGMAC_DMA_BUSMODE_DSL 0x0004 +#define XGMAC_DMA_BUSMODE_DSL_MASK 0x007c +#define XGMAC_DMA_BUSMODE_DSL_SHIFT2 +#define XGMAC_DMA_BUSMODE_ATDS 0x0080 +#define XGMAC_DMA_BUSMODE_PBL_MASK 0x3f00 +#define XGMAC_DMA_BUSMODE_PBL_SHIFT8 +#define XGMAC_DMA_BUSMODE_FB 0x0001 +#define XGMAC_DMA_BUSMODE_USP 0x0080 +#define XGMAC_DMA_BUSMODE_8PBL 0x0100 +#define XGMAC_DMA_BUSMODE_AAL 0x0200 + +#define XGMAC_DMA_AXIMODE_ENLPI0x8000 +#define XGMAC_DMA_AXIMODE_MGK 0x4000 +#define XGMAC_DMA_AXIMODE_WROSR0x0010 +#define XGMAC_DMA_AXIMODE_WROSR_MASK 0x00F0 +#define XGMAC_DMA_AXIMODE_WROSR_SHIFT 20 +#define XGMAC_DMA_AXIMODE_RDOSR0x0001 +#define XGMAC_DMA_AXIMODE_RDOSR_MASK 0x000F +#define XGMAC_DMA_AXIMODE_RDOSR_SHIFT 16 +#define XGMAC_DMA_AXIMODE_AAL 0x1000 +#define
[U-Boot] [PATCH v2 2/2] ARM: highbank: enable networking and pxe
From: Rob Herring rob.herr...@calxeda.com
This enables the XGMAC ethernet driver and networking related config
options.
Signed-off-by: Jason Hobbs jason.ho...@calxeda.com
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
v2:
-drop CONFIG_NET_MULTI
-drop leftover 'verify' env setting
board/highbank/highbank.c | 12
include/configs/highbank.h | 18 --
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/board/highbank/highbank.c b/board/highbank/highbank.c
index 8db8a2b..0fa363d 100644
--- a/board/highbank/highbank.c
+++ b/board/highbank/highbank.c
@@ -33,6 +33,18 @@ int board_init(void)
return 0;
}
+/* We know all the init functions have been run now */
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+
+#ifdef CONFIG_CALXEDA_XGMAC
+ rc = calxedaxgmac_initialize(0, 0xfff5);
+ rc |= calxedaxgmac_initialize(1, 0xfff51000);
+#endif
+ return rc;
+}
+
int misc_init_r(void)
{
ahci_init(0xffe08000);
diff --git a/include/configs/highbank.h b/include/configs/highbank.h
index 9c85788..5604733 100644
--- a/include/configs/highbank.h
+++ b/include/configs/highbank.h
@@ -51,19 +51,27 @@
#define CONFIG_DOS_PARTITION
+#define CONFIG_CALXEDA_XGMAC
+
+/* PXE support */
+#define CONFIG_BOOTP_PXE
+#define CONFIG_BOOTP_PXE_CLIENTARCH0x100
+#define CONFIG_BOOTP_VCI_STRINGU-boot.armv7.highbank
+
/*
* Command line configuration.
*/
#include config_cmd_default.h
-#undef CONFIG_CMD_NET
-#undef CONFIG_CMD_NFS
#define CONFIG_CMD_BDI
+#define CONFIG_CMD_DHCP
#define CONFIG_CMD_ELF
#define CONFIG_CMD_MEMORY
#define CONFIG_CMD_LOADS
#define CONFIG_CMD_SCSI
#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_PXE
+#define CONFIG_MENU
#define CONFIG_BOOTDELAY 2
/*
@@ -82,6 +90,12 @@
#define CONFIG_SYS_LOAD_ADDR 0x80
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ fdtaddr_r=0x60\0 \
+ pxefile_addr_r=0x70\0 \
+ kernel_addr_r=0x80\0 \
+ ramdisk_addr_r=0x0100\0 \
+
/*---
* Stack sizes
*
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 2/4] omap-common: Add NAND SPL linux booting
On 12/07/2011 04:39 PM, Stefano Babic wrote:
On 06/12/2011 19:34, Simon Schwarz wrote:
From: Simon Schwarzsimonschwarz...@googlemail.com
This implements booting of Linux from NAND in SPL
Related config parameters:
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is
normally RAM-start + 0x100 (on ARM)
Signed-off-by: Simon Schwarzsimonschwarz...@gmail.com
---
Hi Simon,
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 38d06b1..db52879 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -24,6 +24,7 @@
#includeasm/u-boot.h
#includeasm/utils.h
#includeasm/arch/sys_proto.h
+#includeasm/io.h
#includenand.h
#includeversion.h
#includeasm/omap_common.h
@@ -32,6 +33,7 @@
void spl_nand_load_image(void)
{
struct image_header *header;
+ int *src, *dst;
switch (omap_boot_mode()) {
case NAND_MODE_HW_ECC:
debug(spl: nand - using hw ecc\n);
@@ -45,26 +47,56 @@ void spl_nand_load_image(void)
/*use CONFIG_SYS_TEXT_BASE as temporary storage area */
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+#ifdef CONFIG_SPL_OS_BOOT
+ if (!spl_uboot_key()) {
Using a gpio or whatever mechanis is baord specific. What about to set a
weak function and let that the board decides itself what to do ?
Sounds reasonable to me. So I'am ok with this.
Not always a GPIO can be used for this purpose.
I have noted another issue. If the kernel image is not found, the
fallback is to load u-boot. However, u-boot is searched at the address
in NAND of the kernel, not at CONFIG_SYS_NAND_U_BOOT_OFFS.
This means that if the kernel is not loaded at all, the SPL starts to
start a u-boot.bin instead of u-boot.img loaded at
CONFIG_CMD_SPL_NAND_OFS, and this fails.
+ /*
+* load parameter image
+* load to temp position since nand_spl_load_image reads
+* a whole block which is typically larger than
+* CONFIG_CMD_SAVEBP_WRITE_SIZE therefore may overwrite
+* following sections like BSS
+*/
+ nand_spl_load_image(CONFIG_CMD_SPL_NAND_OFS,
+ CONFIG_CMD_SPL_WRITE_SIZE,
+ (void *)CONFIG_SYS_TEXT_BASE);
+ /* copy to destintion */
+ for (dst = (int *)CONFIG_SYS_SPL_ARGS_ADDR,
+ src = (int *)CONFIG_SYS_TEXT_BASE;
+ src (int *)(CONFIG_SYS_TEXT_BASE +
+ CONFIG_CMD_SPL_WRITE_SIZE);
+ src++, dst++) {
+ writel(readl(src), dst);
+ }
+ /* load linux */
+ nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
So if the parse function fails, we should have the fallback to u-boot,
exactly as we have now the fallback from u-boot.img to u-boot.bin.
Hm, I don't think that we want any fallback here. I would prefere an
error message and hang. The direct boot is designed to be used in the
field - so IMHO we don't want to start the bootloader automatically if a
normal startup fails.
The function you write are in omap-common/spl_nand.c, but they are not
specific for OMAP, and any architecture can profit from your work. What
about to move common functions away from TI related directory ? I do not
know which is the best place, maybe a new directory under the root as
spllib ?
Hm thats generally right. I would prefer lib_spl. Somehow it feels like
going back to nand_spl times. Duno if there are better places?
The first two points I will fix/rework hopfully on monday (I'am not in
the next two days)
Regards
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 2/4] omap-common: Add NAND SPL linux booting
On 07/12/2011 18:57, Simon Schwarz wrote: So if the parse function fails, we should have the fallback to u-boot, exactly as we have now the fallback from u-boot.img to u-boot.bin. Hm, I don't think that we want any fallback here. I would prefere an error message and hang. The direct boot is designed to be used in the field - so IMHO we don't want to start the bootloader automatically if a normal startup fails. this is also reasonable - we should drop the current behavior: if Linux is not found, SPL tries to start the loaded code as u-boot.bin. Better to hang with a message. The function you write are in omap-common/spl_nand.c, but they are not specific for OMAP, and any architecture can profit from your work. What about to move common functions away from TI related directory ? I do not know which is the best place, maybe a new directory under the root as spllib ? Hm thats generally right. I would prefer lib_spl. Somehow it feels like going back to nand_spl times. Duno if there are better places? Tom probably can suggest us something.. BR, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] USB: Add generic ULPI layer and a viewport
Hi Marek,
On 12/07/11 19:27, Marek Vasut wrote:
On 12/07/11 03:42, Simon Glass wrote:
Hi Igor,
Looks good - a few comments from me.
On Mon, Dec 5, 2011 at 1:07 AM, Igor Grinberg grinb...@compulab.co.il
wrote:
From: Jana Rapava ferma...@gmail.com
Add partial ULPI specification implementation that should be enough to
interface the ULPI PHYs in the boot loader context.
Add a viewport implementation for Chipidea/ARC based controllers.
Signed-off-by: Jana Rapava ferma...@gmail.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Remy Bohmer li...@bohmer.net
Cc: Stefano Babic sba...@denx.de
Cc: Wolfgang Grandegger w...@denx.de
Cc: Simon Glass s...@chromium.org
---
[...]
Just out of interest, is it possible to test this? How would I plumb it
in?
Well, from my experience with ULPI hardware,
I think the controller specific glue looks like the right place
for putting the ULPI layer calls in.
In general, the controller code knows which PHYs it supports
and board code knows which PHY is assembled on the board,
so it is not that straight simple to find the right place.
I think, Marek has patches that supposed to use this framework on efikamx
board.
I tried using the interface, but the design seems completely wrong :-( Jana
was
supposed to design it mainly for the efikamx board, but this interface is
unusable there.
May I ask you why?
Isn't it because of that nasty VBUS bug efikamx has?
You can't say the design is wrong if it is more generic then you want...
I had to fall back to basic ulpi_read()/ulpi_write() calls :-(
That's too bad.
Because ulpi_{read|write}() is only a viewport implementation and
it is not following the ULPI spec.
I'm afraid we won't make it for .12 release window with this patches ... very
bad :-( I'll try talking to WD if he can push the release window to allow
this
Good.
(or redesigned version) in, but I don't know if that's a good idea.
I don't think it should be redesigned.
Currently, it is generic and abstracts the ULPI specification nicely.
It can be used on any architecture.
I have already stated in the cover letter,
what IMO is missing to improve usability, but that will not be a problem.
Do you have the efikamx patches somewhere I can look at?
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
On 12/07/2011 11:46 AM, Ilya Yanok wrote: Hi Stefano, On 07.12.2011 13:06, Stefano Babic wrote: +#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x1) +#endif Maybe it is better to not have a default value somewhere in the SDRAM and to get a compile error. If we do not want to fix also the related My intention was not to break something as I can't fix every board using this driver. That's why I preserved the existing address for the case where CONFIG_SPL_NAND_WORKSPACE is not defined. How many boards are using the new SPL for NAND so far? It shouldn't be that bad to just fix them. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Add board_pre_console_putc to deal with early console output
Hi Graeme, On Sun, Dec 4, 2011 at 8:35 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Mon, Dec 5, 2011 at 3:31 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Sun, Dec 4, 2011 at 7:40 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Mon, Dec 5, 2011 at 2:34 PM, Simon Glass s...@chromium.org wrote: Hi Stefan, On Sun, Dec 4, 2011 at 10:56 AM, Stefano Babic sba...@denx.de wrote: On 02/12/2011 19:16, Simon Glass wrote: It actually started as a last-ditch panic message printer. It morphed into the general pre-console putc after discussions on the list (with Graeme). It can happen that your early board code does not know what clocks to use, or can't find a console, or some other critical error. It then calls panic() which silently dies or maybe reboots if you are lucky. This problem mostly comes about with device trees, where we must have certain info in the device tree before we can even get to relocation. The idea is that boards provide a way of outputting characters which tries to work on all types of boards with that SOC. For example, they output the characters on all UARTs with various clock options, etc. We use it on Tegra to print a friendly panic message when something is horribly wrong. In this case we will never make it to relocation so the pre-console buffer will not be displayed. So we can't rely on that. I do not know if this mechanism can be used on other SOCs, but IMHO it does not hurt and it helps at least on Tegra, as you explained me. Applied to u-boot-staging, sba...@denx.de branch Thanks. I think it can be used on any SOC with internal UARTs and a reasonably small list of permitted clock speeds. I suspect I will be trying it out on a few before long. Can it be used in conjuction with PRE_CONSOLE_BUFFER? i.e. panic() prints the contents of the PRE_CONSOLE_BUFFER before the panic message? I think that would be invaluable in determining what was happening leading up to the panic It could have been when it was still a pre-console panic. But now that it has morphed into a general putc(), I suppose the only option is to somehow detect the first call and send the pre-console text first? Couldn't the panic() function detect that the pre console buffer is not empty and dump it before the panic message? Maybe even a generic panic_dump_pre_console_buffer() which checks if console has been initialised (in which case the buffer has already been dumped) and if the buffer is not empty, use pre_console_putc() to dump the buffer. This would be the first call in panic() followed by printing the panic message Yes it could - sounds like a great idea. Patches welcome :-) Regards, Simon Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] MX5x USB support
This patchset adds the USB support for MX5x. Most of the code is based on work of Wolfgang Grandegger with modifications done by various other authors. I also included version of ULPI support code cleaned up by Igor Grinberg. NOTE: I'd really love to get this code into .12 release. Remy, Wolfgang, do you think it'd be possible? I'd really help adoption of the MX5x USB code greatly as well as cleanup of the ULPI code (which is sadly in a bad shape). Jana Rapava (1): USB: Add generic ULPI layer and a viewport Marek Vasut (4): USB: MX5: Abstract out mx51 USB pixmux configuration USB: MX5: Add MX5 usb post-init callback USB: EHCI: Allow EHCI post-powerup configuration in board files USB: efikamx: Enable USB on EfikaMX and EfikaSB Wolfgang Grandegger (4): USB: MX5: add helper functions to enable USB clocks USB: MX5: add generic USB EHCI support for mx51 and mx53 USB: mx53loco: add end enable USB host support on port 1 USB: mx51evk: add end enable USB host support on port 1 Makefile |1 + arch/arm/cpu/armv7/mx5/clock.c | 72 +++ arch/arm/include/asm/arch-mx5/clock.h|5 + arch/arm/include/asm/arch-mx5/crm_regs.h |3 + board/efikamx/Makefile |4 + board/efikamx/efikamx-usb.c | 210 + board/efikamx/efikamx.c | 15 ++ board/freescale/mx51evk/mx51evk.c| 62 ++ board/freescale/mx53loco/mx53loco.c | 10 + drivers/usb/host/Makefile|1 + drivers/usb/host/ehci-hcd.c | 12 +- drivers/usb/host/ehci-mx5.c | 255 + drivers/usb/ulpi/Makefile| 44 + drivers/usb/ulpi/ulpi-viewport.c | 118 drivers/usb/ulpi/ulpi.c | 227 +++ include/configs/efikamx.h| 47 - include/configs/mx51evk.h| 13 ++ include/configs/mx53loco.h | 13 ++ include/usb/ehci-fsl.h | 16 ++ include/usb/ulpi.h | 298 ++ 20 files changed, 1418 insertions(+), 8 deletions(-) create mode 100644 board/efikamx/efikamx-usb.c create mode 100644 drivers/usb/host/ehci-mx5.c create mode 100644 drivers/usb/ulpi/Makefile create mode 100644 drivers/usb/ulpi/ulpi-viewport.c create mode 100644 drivers/usb/ulpi/ulpi.c create mode 100644 include/usb/ulpi.h Cc: Igor Grinberg grinb...@compulab.co.il Cc: Jana Rapava ferma...@gmail.com Cc: Remy Bohmer li...@bohmer.net Cc: Simon Glass s...@chromium.org Cc: Stefano Babic sba...@denx.de Cc: Wolfgang Grandegger w...@denx.de -- 1.7.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] USB: MX5: Abstract out mx51 USB pixmux configuration
Signed-off-by: Marek Vasut marek.va...@gmail.com
Cc: Stefano Babic sba...@denx.de
Cc: Remy Bohmer li...@bohmer.net
Cc: Wolfgang Grandegger w...@denx.de
Cc: Jason Liu r64...@freescale.com
---
drivers/usb/host/ehci-mx5.c | 71 +++
include/usb/ehci-fsl.h |6
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-mx5.c b/drivers/usb/host/ehci-mx5.c
index 4c961d3..7b88137 100644
--- a/drivers/usb/host/ehci-mx5.c
+++ b/drivers/usb/host/ehci-mx5.c
@@ -58,6 +58,77 @@
/* USB_CTRL_1 */
#define MXC_USB_CTRL_UH1_EXT_CLK_EN(1 25)
+/* USB pin configuration */
+#define USB_PAD_CONFIG (PAD_CTL_PKE_ENABLE | PAD_CTL_SRE_FAST | \
+ PAD_CTL_DRV_HIGH | PAD_CTL_100K_PU | \
+ PAD_CTL_HYS_ENABLE | PAD_CTL_PUE_PULL)
+
+#ifdef CONFIG_MX51
+/*
+ * Configure the MX51 USB H1 IOMUX
+ */
+void setup_iomux_usb_h1(void)
+{
+ mxc_request_iomux(MX51_PIN_USBH1_STP, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_STP, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_CLK, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_CLK, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DIR, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DIR, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_NXT, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_NXT, USB_PAD_CONFIG);
+
+ mxc_request_iomux(MX51_PIN_USBH1_DATA0, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA0, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DATA1, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA1, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DATA2, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA2, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DATA3, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA3, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DATA4, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA4, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DATA5, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA5, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DATA6, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA6, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_USBH1_DATA7, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_DATA7, USB_PAD_CONFIG);
+}
+
+/*
+ * Configure the MX51 USB H2 IOMUX
+ */
+void setup_iomux_usb_h2(void)
+{
+ mxc_request_iomux(MX51_PIN_EIM_A24, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_A24, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_A25, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_A25, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_A26, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_A26, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_A27, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_A27, USB_PAD_CONFIG);
+
+ mxc_request_iomux(MX51_PIN_EIM_D16, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D16, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_D17, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D17, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_D18, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D18, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_D19, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D19, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_D20, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D20, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_D21, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D21, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_D22, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D22, USB_PAD_CONFIG);
+ mxc_request_iomux(MX51_PIN_EIM_D23, IOMUX_CONFIG_ALT2);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D23, USB_PAD_CONFIG);
+}
+#endif
+
int mxc_set_usbcontrol(int port, unsigned int flags)
{
unsigned int v;
diff --git a/include/usb/ehci-fsl.h b/include/usb/ehci-fsl.h
index 4ce0ab3..2869302 100644
--- a/include/usb/ehci-fsl.h
+++ b/include/usb/ehci-fsl.h
@@ -253,4 +253,10 @@ struct usb_ehci {
/* Board-specific initialization */
int board_ehci_hcd_init(int port);
+/* CPU-specific abstracted-out IOMUX init */
+#ifdef CONFIG_MX51
+void setup_iomux_usb_h1(void);
+void setup_iomux_usb_h2(void);
+#endif
+
#endif /* _EHCI_FSL_H */
--
1.7.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] USB: MX5: add helper functions to enable USB clocks
From: Wolfgang Grandegger w...@denx.de
Signed-off-by: Wolfgang Grandegger w...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Remy Bohmer li...@bohmer.net
Cc: Wolfgang Grandegger w...@denx.de
Cc: Jason Liu r64...@freescale.com
V2: Fix spacing in crm_regs.h
---
arch/arm/cpu/armv7/mx5/clock.c | 72 ++
arch/arm/include/asm/arch-mx5/clock.h|5 ++
arch/arm/include/asm/arch-mx5/crm_regs.h |3 +
3 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index 0769a64..c8dad17 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -50,6 +50,78 @@ struct mxc_pll_reg *mxc_plls[PLL_CLOCKS] = {
struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)MXC_CCM_BASE;
+void set_usboh3_clk(void)
+{
+ unsigned int reg;
+
+ reg = readl(mxc_ccm-cscmr1)
+~MXC_CCM_CSCMR1_USBOH3_CLK_SEL_MASK;
+ reg |= 1 MXC_CCM_CSCMR1_USBOH3_CLK_SEL_OFFSET;
+ writel(reg, mxc_ccm-cscmr1);
+
+ reg = readl(mxc_ccm-cscdr1);
+ reg = ~MXC_CCM_CSCDR1_USBOH3_CLK_PODF_MASK;
+ reg = ~MXC_CCM_CSCDR1_USBOH3_CLK_PRED_MASK;
+ reg |= 4 MXC_CCM_CSCDR1_USBOH3_CLK_PRED_OFFSET;
+ reg |= 1 MXC_CCM_CSCDR1_USBOH3_CLK_PODF_OFFSET;
+
+ writel(reg, mxc_ccm-cscdr1);
+}
+
+void enable_usboh3_clk(unsigned char enable)
+{
+ unsigned int reg;
+
+ reg = readl(mxc_ccm-CCGR2);
+ if (enable)
+ reg |= 1 MXC_CCM_CCGR2_CG14_OFFSET;
+ else
+ reg = ~(1 MXC_CCM_CCGR2_CG14_OFFSET);
+ writel(reg, mxc_ccm-CCGR2);
+}
+
+void set_usb_phy1_clk(void)
+{
+ unsigned int reg;
+
+ reg = readl(mxc_ccm-cscmr1);
+ reg = ~MXC_CCM_CSCMR1_USB_PHY_CLK_SEL;
+ writel(reg, mxc_ccm-cscmr1);
+}
+
+void enable_usb_phy1_clk(unsigned char enable)
+{
+ unsigned int reg;
+
+ reg = readl(mxc_ccm-CCGR4);
+ if (enable)
+ reg |= 1 MXC_CCM_CCGR4_CG5_OFFSET;
+ else
+ reg = ~(1 MXC_CCM_CCGR4_CG5_OFFSET);
+ writel(reg, mxc_ccm-CCGR4);
+}
+
+void set_usb_phy2_clk(void)
+{
+ unsigned int reg;
+
+ reg = readl(mxc_ccm-cscmr1);
+ reg = ~MXC_CCM_CSCMR1_USB_PHY_CLK_SEL;
+ writel(reg, mxc_ccm-cscmr1);
+}
+
+void enable_usb_phy2_clk(unsigned char enable)
+{
+ unsigned int reg;
+
+ reg = readl(mxc_ccm-CCGR4);
+ if (enable)
+ reg |= 1 MXC_CCM_CCGR4_CG6_OFFSET;
+ else
+ reg = ~(1 MXC_CCM_CCGR4_CG6_OFFSET);
+ writel(reg, mxc_ccm-CCGR4);
+}
+
/*
* Calculate the frequency of PLLn.
*/
diff --git a/arch/arm/include/asm/arch-mx5/clock.h
b/arch/arm/include/asm/arch-mx5/clock.h
index 1f8a537..ea972a3 100644
--- a/arch/arm/include/asm/arch-mx5/clock.h
+++ b/arch/arm/include/asm/arch-mx5/clock.h
@@ -40,4 +40,9 @@ u32 imx_get_uartclk(void);
u32 imx_get_fecclk(void);
unsigned int mxc_get_clock(enum mxc_clock clk);
+void set_usb_phy2_clk(void);
+void enable_usb_phy2_clk(unsigned char enable);
+void set_usboh3_clk(void);
+void enable_usboh3_clk(unsigned char enable);
+
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/asm/arch-mx5/crm_regs.h
b/arch/arm/include/asm/arch-mx5/crm_regs.h
index fcc0e36..bdeafbc 100644
--- a/arch/arm/include/asm/arch-mx5/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx5/crm_regs.h
@@ -195,7 +195,10 @@ struct mxc_ccm_reg {
/* Define the bits in register CCGRx */
#define MXC_CCM_CCGR_CG_MASK 0x3
+#define MXC_CCM_CCGR4_CG5_OFFSET 10
+#define MXC_CCM_CCGR4_CG6_OFFSET 12
#define MXC_CCM_CCGR5_CG5_OFFSET 10
+#define MXC_CCM_CCGR2_CG14_OFFSET 28
/* Define the bits in register CLPCR */
#define MXC_CCM_CLPCR_BYPASS_IPU_LPM_HS (0x1 18)
--
1.7.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/9] USB: MX5: add generic USB EHCI support for mx51 and mx53
From: Wolfgang Grandegger w...@denx.de
It's derived from ehci-mxc and uses the header files of the
ehci-fsl interface. The callback board_ehci_hcd_init() has
been introduced to allow for board-specific setup when USB
is started.
Signed-off-by: Wolfgang Grandegger w...@denx.de
CC: Stefano Babic sba...@denx.de
CC: Remy Bohmer li...@bohmer.net
---
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-mx5.c | 174 +++
include/usb/ehci-fsl.h | 10 +++
3 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/host/ehci-mx5.c
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 09abb75..77e217f 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-fsl.o
endif
COBJS-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o
COBJS-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o
+COBJS-$(CONFIG_USB_EHCI_MX5) += ehci-mx5.o
COBJS-$(CONFIG_USB_EHCI_PPC4XX) += ehci-ppc4xx.o
COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o
COBJS-$(CONFIG_USB_EHCI_KIRKWOOD) += ehci-kirkwood.o
diff --git a/drivers/usb/host/ehci-mx5.c b/drivers/usb/host/ehci-mx5.c
new file mode 100644
index 000..4c961d3
--- /dev/null
+++ b/drivers/usb/host/ehci-mx5.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright (c) 2009 Daniel Mack dan...@caiaq.de
+ * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+#include common.h
+#include usb.h
+#include errno.h
+#include linux/compiler.h
+#include usb/ehci-fsl.h
+#include asm/io.h
+#include asm/arch/imx-regs.h
+#include asm/arch/clock.h
+#include asm/arch/mx5x_pins.h
+
+#include ehci.h
+#include ehci-core.h
+
+#define MX5_USBOTHER_REGS_OFFSET 0x800
+
+
+#define MXC_OTG_OFFSET 0
+#define MXC_H1_OFFSET 0x200
+#define MXC_H2_OFFSET 0x400
+
+#define MXC_USBCTRL_OFFSET 0
+#define MXC_USB_PHY_CTR_FUNC_OFFSET0x8
+#define MXC_USB_PHY_CTR_FUNC2_OFFSET 0xc
+#define MXC_USB_CTRL_1_OFFSET 0x10
+#define MXC_USBH2CTRL_OFFSET 0x14
+
+/* USB_CTRL */
+#define MXC_OTG_UCTRL_OWIE_BIT (1 27) /* OTG wakeup intr enable */
+#define MXC_OTG_UCTRL_OPM_BIT (1 24) /* OTG power mask */
+#define MXC_H1_UCTRL_H1UIE_BIT (1 12) /* Host1 ULPI interrupt enable */
+#define MXC_H1_UCTRL_H1WIE_BIT (1 11) /* HOST1 wakeup intr enable */
+#define MXC_H1_UCTRL_H1PM_BIT (1 8) /* HOST1 power mask */
+
+/* USB_PHY_CTRL_FUNC */
+#define MXC_OTG_PHYCTRL_OC_DIS_BIT (1 8) /* OTG Disable Overcurrent Event */
+#define MXC_H1_OC_DIS_BIT (1 5) /* UH1 Disable Overcurrent Event */
+
+/* USBH2CTRL */
+#define MXC_H2_UCTRL_H2UIE_BIT (1 8)
+#define MXC_H2_UCTRL_H2WIE_BIT (1 7)
+#define MXC_H2_UCTRL_H2PM_BIT (1 4)
+
+/* USB_CTRL_1 */
+#define MXC_USB_CTRL_UH1_EXT_CLK_EN(1 25)
+
+int mxc_set_usbcontrol(int port, unsigned int flags)
+{
+ unsigned int v;
+ void __iomem *usb_base = (void __iomem *)OTG_BASE_ADDR;
+ void __iomem *usbother_base;
+ int ret = 0;
+
+ usbother_base = usb_base + MX5_USBOTHER_REGS_OFFSET;
+
+ switch (port) {
+ case 0: /* OTG port */
+ if (flags MXC_EHCI_INTERNAL_PHY) {
+ v = __raw_readl(usbother_base +
+ MXC_USB_PHY_CTR_FUNC_OFFSET);
+ if (flags MXC_EHCI_POWER_PINS_ENABLED)
+ /* OC/USBPWR is not used */
+ v |= MXC_OTG_PHYCTRL_OC_DIS_BIT;
+ else
+ /* OC/USBPWR is used */
+ v = ~MXC_OTG_PHYCTRL_OC_DIS_BIT;
+ __raw_writel(v, usbother_base +
+ MXC_USB_PHY_CTR_FUNC_OFFSET);
+
+ v = __raw_readl(usbother_base + MXC_USBCTRL_OFFSET);
+ if (flags MXC_EHCI_POWER_PINS_ENABLED)
+ v |= MXC_OTG_UCTRL_OPM_BIT;
+ else
+ v = ~MXC_OTG_UCTRL_OPM_BIT;
+ __raw_writel(v, usbother_base + MXC_USBCTRL_OFFSET);
+ }
+ break;
+ case 1: /* Host 1 Host ULPI */
+#ifdef CONFIG_MX51
+ /* The clock for the USBH1 ULPI port will come externally
+ from the PHY. */
+ v = __raw_readl(usbother_base + MXC_USB_CTRL_1_OFFSET);
+ __raw_writel(v | MXC_USB_CTRL_UH1_EXT_CLK_EN,
[U-Boot] [PATCH 5/9] USB: mx53loco: add end enable USB host support on port 1
From: Wolfgang Grandegger w...@denx.de
Signed-off-by: Wolfgang Grandegger w...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Remy Bohmer li...@bohmer.net
Cc: Wolfgang Grandegger w...@denx.de
Cc: Jason Liu r64...@freescale.com
---
board/freescale/mx53loco/mx53loco.c | 10 ++
include/configs/mx53loco.h | 13 +
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx53loco/mx53loco.c
b/board/freescale/mx53loco/mx53loco.c
index b4c7f33..a4cd14e 100644
--- a/board/freescale/mx53loco/mx53loco.c
+++ b/board/freescale/mx53loco/mx53loco.c
@@ -78,6 +78,16 @@ static void setup_iomux_uart(void)
PAD_CTL_ODE_OPENDRAIN_ENABLE);
}
+#ifdef CONFIG_USB_EHCI_MX5
+void board_ehci_hcd_init(int port)
+{
+ /* request VBUS power enable pin, GPIO[8}, gpio7 */
+ mxc_request_iomux(MX53_PIN_ATA_DA_2, IOMUX_CONFIG_ALT1);
+ gpio_direction_output(IOMUX_TO_GPIO(MX53_PIN_ATA_DA_2), 0);
+ gpio_set_value(IOMUX_TO_GPIO(MX53_PIN_ATA_DA_2), 1);
+}
+#endif
+
static void setup_iomux_fec(void)
{
/*FEC_MDIO*/
diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
index d699010..9ce43d7 100644
--- a/include/configs/mx53loco.h
+++ b/include/configs/mx53loco.h
@@ -72,6 +72,19 @@
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+/* USB Configs */
+#define CONFIG_CMD_USB
+#define CONFIG_CMD_FAT
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX5
+#define CONFIG_USB_STORAGE
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_MXC_USB_PORT1
+#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
+#define CONFIG_MXC_USB_FLAGS 0
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
--
1.7.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] USB: MX5: Add MX5 usb post-init callback
This is useful for USB Transceivers init etc.
Signed-off-by: Marek Vasut marek.va...@gmail.com
Cc: Stefano Babic sba...@denx.de
Cc: Remy Bohmer li...@bohmer.net
Cc: Wolfgang Grandegger w...@denx.de
Cc: Jason Liu r64...@freescale.com
---
drivers/usb/host/ehci-mx5.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-mx5.c b/drivers/usb/host/ehci-mx5.c
index 7b88137..68a673e 100644
--- a/drivers/usb/host/ehci-mx5.c
+++ b/drivers/usb/host/ehci-mx5.c
@@ -22,6 +22,7 @@
#include asm/arch/imx-regs.h
#include asm/arch/clock.h
#include asm/arch/mx5x_pins.h
+#include asm/arch/iomux.h
#include ehci.h
#include ehci-core.h
@@ -198,6 +199,13 @@ int mxc_set_usbcontrol(int port, unsigned int flags)
return ret;
}
+void __board_ehci_hcd_postinit(struct usb_ehci *ehci, int port)
+{
+}
+
+void board_ehci_hcd_postinit(struct usb_ehci *ehci, int port)
+ __attribute((weak, alias(__board_ehci_hcd_postinit)));
+
int ehci_hcd_init(void)
{
struct usb_ehci *ehci;
@@ -217,7 +225,7 @@ int ehci_hcd_init(void)
enable_usb_phy2_clk(1);
mdelay(1);
- /* do board specific initialization */
+ /* Do board specific initialization */
board_ehci_hcd_init(CONFIG_MXC_USB_PORT);
ehci = (struct usb_ehci *)(OTG_BASE_ADDR +
@@ -231,9 +239,11 @@ int ehci_hcd_init(void)
setbits_le32(ehci-portsc, USB_EN);
mxc_set_usbcontrol(CONFIG_MXC_USB_PORT, CONFIG_MXC_USB_FLAGS);
-
mdelay(10);
+ /* Do board specific post-initialization */
+ board_ehci_hcd_postinit(ehci, CONFIG_MXC_USB_PORT);
+
return 0;
}
--
1.7.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/9] USB: EHCI: Allow EHCI post-powerup configuration in board files
This patch allows USB to work on some hosts, which need additional frobing after
the host was powered up via regular USB powerup sequence.
Signed-off-by: Marek Vasut marek.va...@gmail.com
Cc: Stefano Babic sba...@denx.de
Cc: Remy Bohmer li...@bohmer.net
Cc: Wolfgang Grandegger w...@denx.de
Cc: Jason Liu r64...@freescale.com
---
drivers/usb/host/ehci-hcd.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index b4c9db8..8bb3ff1 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -205,6 +205,14 @@ static inline void ehci_invalidate_dcache(struct QH *qh)
}
#endif /* CONFIG_EHCI_DCACHE */
+void __ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg)
+{
+ mdelay(50);
+}
+
+void ehci_powerup_fixup(uint32_t *status_reg, uint32_t *reg)
+ __attribute__((weak, alias(__ehci_powerup_fixup)));
+
static int handshake(uint32_t *ptr, uint32_t mask, uint32_t done, int usec)
{
uint32_t result;
@@ -713,8 +721,8 @@ ehci_submit_root(struct usb_device *dev, unsigned long
pipe, void *buffer,
* usb 2.0 specification say 50 ms resets on
* root
*/
- wait_ms(50);
- /* terminate the reset */
+ ehci_powerup_fixup(status_reg, reg);
+
ehci_writel(status_reg, reg ~EHCI_PS_PR);
/*
* A host controller must terminate the reset
--
1.7.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/9] USB: mx51evk: add end enable USB host support on port 1
From: Wolfgang Grandegger w...@denx.de
Signed-off-by: Wolfgang Grandegger w...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Remy Bohmer li...@bohmer.net
Cc: Wolfgang Grandegger w...@denx.de
Cc: Jason Liu r64...@freescale.com
---
board/freescale/mx51evk/mx51evk.c | 62 +
include/configs/mx51evk.h | 13
2 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 37e6e4d..991bae2 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -35,6 +35,7 @@
#include pmic.h
#include fsl_pmic.h
#include mc13892.h
+#include usb/ehci-fsl.h
DECLARE_GLOBAL_DATA_PTR;
@@ -172,6 +173,64 @@ static void setup_iomux_spi(void)
}
#endif
+#ifdef CONFIG_USB_EHCI_MX5
+#define MX51EVK_USBH1_HUB_RST IOMUX_TO_GPIO(MX51_PIN_GPIO1_7) /* GPIO1_7 */
+#define MX51EVK_USBH1_STP IOMUX_TO_GPIO(MX51_PIN_USBH1_STP) /* GPIO1_27 */
+#define MX51EVK_USB_CLK_EN_B IOMUX_TO_GPIO(MX51_PIN_EIM_D18) /* GPIO2_1 */
+#define MX51EVK_USB_PHY_RESET IOMUX_TO_GPIO(MX51_PIN_EIM_D21) /* GPIO2_5 */
+
+#define USBH1_PAD (PAD_CTL_SRE_FAST | PAD_CTL_DRV_HIGH | \
+PAD_CTL_100K_PU | PAD_CTL_PUE_PULL | \
+PAD_CTL_PKE_ENABLE | PAD_CTL_HYS_ENABLE)
+#define GPIO_PAD (PAD_CTL_DRV_HIGH | PAD_CTL_PKE_ENABLE |\
+PAD_CTL_SRE_FAST)
+#define NO_PAD (1 16)
+
+static void setup_usb_h1(void)
+{
+ setup_iomux_usb_h1();
+
+ /* GPIO_1_7 for USBH1 hub reset */
+ mxc_request_iomux(MX51_PIN_GPIO1_7, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_GPIO1_7, NO_PAD);
+
+ /* GPIO_2_1 */
+ mxc_request_iomux(MX51_PIN_EIM_D17, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D17, GPIO_PAD);
+
+ /* GPIO_2_5 for USB PHY reset */
+ mxc_request_iomux(MX51_PIN_EIM_D21, IOMUX_CONFIG_ALT1);
+ mxc_iomux_set_pad(MX51_PIN_EIM_D21, GPIO_PAD);
+}
+
+void board_ehci_hcd_init(int port)
+{
+ /* Set USBH1_STP to GPIO and toggle it */
+ mxc_request_iomux(MX51_PIN_USBH1_STP, IOMUX_CONFIG_GPIO);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_STP, USBH1_PAD);
+
+ gpio_direction_output(MX51EVK_USBH1_STP, 0);
+ gpio_direction_output(MX51EVK_USB_PHY_RESET, 0);
+ mdelay(10);
+ gpio_set_value(MX51EVK_USBH1_STP, 1);
+
+ /* Set back USBH1_STP to be function */
+ mxc_request_iomux(MX51_PIN_USBH1_STP, IOMUX_CONFIG_ALT0);
+ mxc_iomux_set_pad(MX51_PIN_USBH1_STP, USBH1_PAD);
+
+ /* De-assert USB PHY RESETB */
+ gpio_set_value(MX51EVK_USB_PHY_RESET, 1);
+
+ /* Drive USB_CLK_EN_B line low */
+ gpio_direction_output(MX51EVK_USB_CLK_EN_B, 0);
+
+ /* Reset USB hub */
+ gpio_direction_output(MX51EVK_USBH1_HUB_RST, 0);
+ mdelay(2);
+ gpio_set_value(MX51EVK_USBH1_HUB_RST, 1);
+}
+#endif
+
static void power_init(void)
{
unsigned int val;
@@ -391,6 +450,9 @@ int board_early_init_f(void)
{
setup_iomux_uart();
setup_iomux_fec();
+#ifdef CONFIG_USB_EHCI_MX5
+ setup_usb_h1();
+#endif
return 0;
}
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 7c7544f..18f1ebd 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -110,6 +110,19 @@
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+/* USB Configs */
+#define CONFIG_CMD_USB
+#define CONFIG_CMD_FAT
+#define CONFIG_USB_EHCI
+#define CONFIG_USB_EHCI_MX5
+#define CONFIG_USB_STORAGE
+#define CONFIG_USB_HOST_ETHER
+#define CONFIG_USB_ETHER_ASIX
+#define CONFIG_USB_ETHER_SMSC95XX
+#define CONFIG_MXC_USB_PORT1
+#define CONFIG_MXC_USB_PORTSC PORT_PTS_ULPI
+#define CONFIG_MXC_USB_FLAGS MXC_EHCI_POWER_PINS_ENABLED
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
--
1.7.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Pending patches for december release?
Dear Simon Glass, In message capnjgz0bwjrt+m8qdev7d2chp-nzpgvpvbzvgmfy4phre_d...@mail.gmail.com you wrote: Albert, the correct series is the I delegated to you, not the one in my email. It tidies up the ARM link scripts: http://patchwork.ozlabs.org/patch/126933/ http://patchwork.ozlabs.org/patch/126930/ http://patchwork.ozlabs.org/patch/126927/ http://patchwork.ozlabs.org/patch/126931/ http://patchwork.ozlabs.org/patch/126926/ http://patchwork.ozlabs.org/patch/126928/ http://patchwork.ozlabs.org/patch/126932/ This is all post-mergewindow stuff. Does it qualify as bug fixes? 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 Wait! You have not been prepared! -- Mr. Atoz, Tomorrow is Yesterday, stardate 3113.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/9] MX5x USB support
This patchset adds the USB support for MX5x. Most of the code is based on work of Wolfgang Grandegger with modifications done by various other authors. I also included version of ULPI support code cleaned up by Igor Grinberg. NOTE: I'd really love to get this code into .12 release. Remy, Wolfgang, do you think it'd be possible? I'd really help adoption of the MX5x USB code greatly as well as cleanup of the ULPI code (which is sadly in a bad shape). Jana Rapava (1): USB: Add generic ULPI layer and a viewport Marek Vasut (4): USB: MX5: Abstract out mx51 USB pixmux configuration USB: MX5: Add MX5 usb post-init callback USB: EHCI: Allow EHCI post-powerup configuration in board files USB: efikamx: Enable USB on EfikaMX and EfikaSB Wolfgang Grandegger (4): USB: MX5: add helper functions to enable USB clocks USB: MX5: add generic USB EHCI support for mx51 and mx53 USB: mx53loco: add end enable USB host support on port 1 USB: mx51evk: add end enable USB host support on port 1 Makefile |1 + arch/arm/cpu/armv7/mx5/clock.c | 72 +++ arch/arm/include/asm/arch-mx5/clock.h|5 + arch/arm/include/asm/arch-mx5/crm_regs.h |3 + board/efikamx/Makefile |4 + board/efikamx/efikamx-usb.c | 210 + board/efikamx/efikamx.c | 15 ++ board/freescale/mx51evk/mx51evk.c| 62 ++ board/freescale/mx53loco/mx53loco.c | 10 + drivers/usb/host/Makefile|1 + drivers/usb/host/ehci-hcd.c | 12 +- drivers/usb/host/ehci-mx5.c | 255 + drivers/usb/ulpi/Makefile| 44 + drivers/usb/ulpi/ulpi-viewport.c | 118 drivers/usb/ulpi/ulpi.c | 227 +++ include/configs/efikamx.h| 47 - include/configs/mx51evk.h| 13 ++ include/configs/mx53loco.h | 13 ++ include/usb/ehci-fsl.h | 16 ++ include/usb/ulpi.h | 298 ++ 20 files changed, 1418 insertions(+), 8 deletions(-) create mode 100644 board/efikamx/efikamx-usb.c create mode 100644 drivers/usb/host/ehci-mx5.c create mode 100644 drivers/usb/ulpi/Makefile create mode 100644 drivers/usb/ulpi/ulpi-viewport.c create mode 100644 drivers/usb/ulpi/ulpi.c create mode 100644 include/usb/ulpi.h Cc: Igor Grinberg grinb...@compulab.co.il Cc: Jana Rapava ferma...@gmail.com Cc: Remy Bohmer li...@bohmer.net Cc: Simon Glass s...@chromium.org Cc: Stefano Babic sba...@denx.de Cc: Wolfgang Grandegger w...@denx.de If some of the patches didn't make it through gmail because of the different From:, please check git://git.denx.de/u-boot-marex.git, usb branch. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Append board name to version identifier
Dear Ed Swarthout, In message 1323278284-19643-1-git-send-email-ed.swarth...@freescale.com you wrote: so it is printed as part of the version command and visible when displaying the image in the various flash banks. This allows strings u-boot.bin | head -1 to identify target: VU-Boot 2011.09-01427-g6ee5cf2 (Dec 07 2011 - 11:11:55) P4080DS Signed-off-by: Ed Swarthout ed.swarth...@freescale.com --- include/version.h |2 +- mkconfig |1 + 2 files changed, 2 insertions(+), 1 deletions(-) I don't think this is a good idea, especially as it afects the user interface for all boards. Please feel free to define local settings for boards that are maintained by you (oops... there aren't any...), but I don't want to change this globally. 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 Maintain an awareness for contribution -- to your schedule, your project, our company. - A Group of Employees ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
Dear Ilya Yanok, In message 4edfa65e.8080...@emcraft.com you wrote: boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...). Probably. Wolfgang, Scott, do you think we should add a warning here? How much space are we talking about? Can it be put on the stack? 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 Lead me not into temptation... I can find it myself. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 2/4] omap-common: Add NAND SPL linux booting
Dear Simon Schwarz, In message 4edfa8fd.9000...@gmail.com you wrote: So if the parse function fails, we should have the fallback to u-boot, exactly as we have now the fallback from u-boot.img to u-boot.bin. Hm, I don't think that we want any fallback here. I would prefere an error message and hang. The direct boot is designed to be used in the field - so IMHO we don't want to start the bootloader automatically if a normal startup fails. I feel it is better to start U-Boot and enable the user to analyze the situation instead of just hanging hard. Just my 0.02# 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 Very ugly or very beautiful women should be flattered on their understanding, and mediocre ones on their beauty. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Append board name to version identifier
Hi Ed, On 12/07/11 20:39, Wolfgang Denk wrote: Dear Ed Swarthout, In message 1323278284-19643-1-git-send-email-ed.swarth...@freescale.com you wrote: so it is printed as part of the version command and visible when displaying the image in the various flash banks. This allows strings u-boot.bin | head -1 to identify target: VU-Boot 2011.09-01427-g6ee5cf2 (Dec 07 2011 - 11:11:55) P4080DS Signed-off-by: Ed Swarthout ed.swarth...@freescale.com --- include/version.h |2 +- mkconfig |1 + 2 files changed, 2 insertions(+), 1 deletions(-) I don't think this is a good idea, especially as it afects the user interface for all boards. Please feel free to define local settings for boards that are maintained by you (oops... there aren't any...), but I don't want to change this globally. Instead, you can create the localversion-something file and the build system will take care of the rest, for example: cut-- ~/git-repo/u-boot $ cat localversion-cm-t3730 -cm-t3730-1 cut-- and it gives me: U-Boot 2011.09-cm-t3730-1 (Oct 11 2011 - 11:52:34) -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to test a new u-boot image over network?
I apologize if this is a duplicate message. I tried to send it earlier but it went Waiting for approval as the system thought I was not a subscriber :-( I have built a new u-boot for a board which is very similar to canyonlands. But I am having problem in running it. Afterwards, I ran mkimage on it. uboot-sources-EMC/u-boot-2009.01 ls u-boot* u-boot u-boot.bin u-boot.bin.load u-boot.map u-boot.srec uboot-sources-EMC/u-boot-2009.01 ls -l u-boot -rwxr-xr-x 1 sontav ucode 1174024 2011-12-06 16:30 u-boot uboot-sources-EMC/u-boot-2009.01 file u-boot u-boot: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped uboot-sources-EMC/u-boot-2009.01 ls -l u-boot.bin -rwxr-xr-x 1 sontav ucode 393216 2011-12-06 16:30 u-boot.bin uboot-sources-EMC/u-boot-2009.01 file u-boot.bin u-boot.bin: u-boot/PPCBoot image uboot-sources-EMC/u-boot-2009.01 mkimage -d u-boot.bin u-boot.bin.load Image Name: Created: Wed Dec 7 12:08:45 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:393216 Bytes = 384.00 kB = 0.38 MB Load Address: 0x Entry Point: 0x uboot-sources-EMC/u-boot-2009.01 I then tftp the image u-boot.bin.load and bootm it but I am getting following error. Error: Bad gzipped data GUNZIP: uncompress or overwrite error - must RESET board to recover I have tried many different load addresses such as 0x40., 0x400., 0x800., 0x1000.. with exactly the same behaviour. What am I missing? The board has full 2Gig of RAM and since the new u-boot image is only about 1.2MB after compression, why is it getting overwrite error? Or is my image not really gzipped but has been marked as gzipped by mkimage utility? Here is the information about the board:- U-Boot 2009.01 SX_PPC_M460EX SX_3.1.0738 ppc (Aug 04 2011 - 00:21:27) CPU: AMCC PowerPC 460EX Rev. B at 1000 MHz (PLB=200, OPB=100, EBC=100 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) Internal PCI arbiter disabled 32 kB I-Cache 32 kB D-Cache Board: Mellanox PPC460EX Board FDEF: No I2C: ready DRAM: 2 GB (ECC enabled, 400 MHz, CL3) FLASH: 16 MB NAND: 1024 MiB ... ... = tftp 0x1000 u-boot.bin.load Waiting for PHY auto negotiation to complete. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 192.168.100.253; our IP address is 192.168.100.22 Filename 'u-boot.bin.load'. Load address: 0x1000 Loading: T ### done Bytes transferred = 393280 (60040 hex) = bootm Error: Bad gzipped data GUNZIP: uncompress or overwrite error - must RESET board to recover Thanks, Vikas Sontakke, EMC vikas.sonta...@emc.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
Dear Wolfgang, On 07.12.2011 22:45, Wolfgang Denk wrote: boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...). Probably. Wolfgang, Scott, do you think we should add a warning here? How much space are we talking about? Can it be put on the stack? Well, currently the code uses 0x200 + CONFIG_SYS_NAND_OOBSIZE bytes but I think a lot of this space is unused. What we really need is CONFIG_SYS_NAND_ECCTOTAL + CONFIG_SYS_NAND_OOBSIZE. This is probably acceptable to put on the stack. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
On 07/12/2011 19:45, Wolfgang Denk wrote: Dear Ilya Yanok, In message 4edfa65e.8080...@emcraft.com you wrote: boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...). Probably. Wolfgang, Scott, do you think we should add a warning here? How much space are we talking about? Can it be put on the stack? I think we are talking about 24 bytes, getting the value for CONFIG_SYS_NAND_ECCTOTAL in the configuration file. Reading the code it is not clear to me why the computed ecc is stored in this way at a fixed offset in RAM - anybody knows why cannot we set a static char ecc_calc[] at the beginning of the nand_spl_simple.c file ? Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] USB: Add generic ULPI layer and a viewport
On 12/07/11 20:36, Marek Vasut wrote:
Hi Marek,
On 12/07/11 19:27, Marek Vasut wrote:
On 12/07/11 03:42, Simon Glass wrote:
Hi Igor,
Looks good - a few comments from me.
On Mon, Dec 5, 2011 at 1:07 AM, Igor Grinberg grinb...@compulab.co.il
wrote:
From: Jana Rapava ferma...@gmail.com
Add partial ULPI specification implementation that should be enough to
interface the ULPI PHYs in the boot loader context.
Add a viewport implementation for Chipidea/ARC based controllers.
Signed-off-by: Jana Rapava ferma...@gmail.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Cc: Remy Bohmer li...@bohmer.net
Cc: Stefano Babic sba...@denx.de
Cc: Wolfgang Grandegger w...@denx.de
Cc: Simon Glass s...@chromium.org
---
[...]
Just out of interest, is it possible to test this? How would I plumb it
in?
Well, from my experience with ULPI hardware,
I think the controller specific glue looks like the right place
for putting the ULPI layer calls in.
In general, the controller code knows which PHYs it supports
and board code knows which PHY is assembled on the board,
so it is not that straight simple to find the right place.
I think, Marek has patches that supposed to use this framework on
efikamx board.
I tried using the interface, but the design seems completely wrong :-(
Jana was supposed to design it mainly for the efikamx board, but this
interface is unusable there.
May I ask you why?
Isn't it because of that nasty VBUS bug efikamx has?
You can't say the design is wrong if it is more generic then you want...
I think it's overengineered. Basically, to achieve what I needed, I either
didn't find the right function or I had to use multiple functions. Therefore
I
had to fall back to plain simple ulpi_read/write().
So now it is plain simple multiple ulpi_read/write() calls?
This is no more as simple as ulpi_layer function() calls...
Instead of forging masks and writing arbitrary values, use
the functional API.
I don't think is is over engineered, because it is simple
and in the same time helps prevent mistakes and most of the cases,
you don't need to be familiar with all the ULPI bits.
I had to fall back to basic ulpi_read()/ulpi_write() calls :-(
That's too bad.
Because ulpi_{read|write}() is only a viewport implementation and
it is not following the ULPI spec.
Well ... we'll need to rethink this.
I'm afraid we won't make it for .12 release window with this patches ...
very bad :-( I'll try talking to WD if he can push the release window to
allow this
Good.
(or redesigned version) in, but I don't know if that's a good idea.
I don't think it should be redesigned.
Currently, it is generic and abstracts the ULPI specification nicely.
Nicely maybe, but try using it on top of some hardware that has ULPI chip.
What's the problem? It is better then just using ulpi_read/write() calls...
May be you are just lazy to read the documentation...
It can be used on any architecture.
I have already stated in the cover letter,
what IMO is missing to improve usability, but that will not be a problem.
Do you have the efikamx patches somewhere I can look at?
Submitted to ML just a while ago.
M
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/bootm: Flush ramdisk and device tree image when booting on MP
On Dec 7, 2011, at 10:17 AM, Tabi Timur-B04825 wrote:
On Wed, Dec 7, 2011 at 8:42 AM, Kumar Gala ga...@kernel.crashing.org wrote:
+ if (flag BOOTM_STATE_OS_PREP) {
+ boot_prep_linux(images);
return 0;
+ }
if (flag BOOTM_STATE_OS_GO) {
boot_jump_linux(images);
return 0;
}
+ boot_prep_linux(images);
Why are we calling boot_prep_linux(images) when flag
BOOTM_STATE_OS_PREP is zero? If we don't want the OS to be PREPped,
then why call a function named boot_prep_linux()?
We call it in both cases, one is for 'normal' bootm command the other is for
'bootm subcommand'.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 2/4] omap-common: Add NAND SPL linux booting
On Wed, Dec 7, 2011 at 11:10 AM, Stefano Babic sba...@denx.de wrote: On 07/12/2011 18:57, Simon Schwarz wrote: [snip] The function you write are in omap-common/spl_nand.c, but they are not specific for OMAP, and any architecture can profit from your work. What about to move common functions away from TI related directory ? I do not know which is the best place, maybe a new directory under the root as spllib ? Hm thats generally right. I would prefer lib_spl. Somehow it feels like going back to nand_spl times. Duno if there are better places? Tom probably can suggest us something.. common/spl_a few files.c ? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to test a new u-boot image over network?
Hi, On Wed, 7 Dec 2011 12:41:38 -0500 vikas.sonta...@emc.com wrote: ... uboot-sources-EMC/u-boot-2009.01 file u-boot.bin u-boot.bin: u-boot/PPCBoot image uboot-sources-EMC/u-boot-2009.01 mkimage -d u-boot.bin u-boot.bin.load Image Name: Created: Wed Dec 7 12:08:45 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:393216 Bytes = 384.00 kB = 0.38 MB Load Address: 0x Entry Point: 0x uboot-sources-EMC/u-boot-2009.01 I then tftp the image u-boot.bin.load and bootm it but I am getting following error. Error: Bad gzipped data GUNZIP: uncompress or overwrite error - must RESET board to recover Did you read the documentation? Why are you trying to boot U-Boot image using 'bootm' command? 'bootm' command is used for booting operating system images. If you want to update U-Boot on the board, you need to write it into the flash memory used for booting. Do you have a JTAG debugger for the case updating U-Boot image goes wrong for some reason? I have tried many different load addresses such as 0x40., 0x400., 0x800., 0x1000.. with exactly the same behaviour. What am I missing? Please read U-Boot documentation [1] to understand which command is used for which purpose. Updating U-Boot is also described in the U-Boot documentation. HTH, Anatolij [1] http://www.denx.de/wiki/view/DULG/UBoot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Remove usbdev.c
Dear Stefan Roese, In message 1321619897-25657-1-git-send-email...@denx.de you wrote: As this driver doesn't seem to be really used, let's remove it completely. Signed-off-by: Stefan Roese s...@denx.de --- arch/powerpc/cpu/ppc4xx/Makefile |1 - arch/powerpc/cpu/ppc4xx/usb.c |5 - arch/powerpc/cpu/ppc4xx/usb_ohci.c |7 - arch/powerpc/cpu/ppc4xx/usbdev.c | 230 arch/powerpc/cpu/ppc4xx/usbdev.h | 31 - 5 files changed, 0 insertions(+), 274 deletions(-) delete mode 100644 arch/powerpc/cpu/ppc4xx/usbdev.c delete mode 100644 arch/powerpc/cpu/ppc4xx/usbdev.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Some programming languages manage to absorb change, but withstand progress. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PPC4xx: usbdev.c used at all?
Dear Stefan Roese, In message 201112010915.34487...@denx.de you wrote: On Wednesday 23 November 2011 07:10:37 Rupjyoti Sarmah wrote: This driver is used by PPC440EP for usb 1.1. Please explain this in more detail. I fail to see, how this driver could be of any used. I definitely never used it. So please explain how exactly you make use of this driver, or why it is needed? Ping! This removal patch is still on my list. So please explain, or I will remove this driver. I'm not willing to wait any longer. I want to see these warnigns fixed. I'll pull your patch directly. Rup, if you can explain that this driver is needed,, then please feel free to submit a patch to re-add it - after cleaningup the warnings it cuases, that is. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I mean, I . . . think to understand you, I just don't know what you are saying ...- Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to test a new u-boot image over network?
Dear vikas.sonta...@emc.com, In message 629d989c137dd040a0a994bd21888f1e75e81...@mx29a.corp.emc.com you wrote: I have built a new u-boot for a board which is very similar to canyonlands. But I am having problem in running it. Afterwards, I ran mkimage on it. Why did you do that? I then tftp the image u-boot.bin.load and bootm it but I am getting following error. Error: Bad gzipped data GUNZIP: uncompress or overwrite error - must RESET board to recover What makes you think this could work? There is no documentation anywhere that desribes such an approach, so why do you think this could work? Why don't you simply read the DULG for the canyonlands board an follow the steps described there to install a new U-Bootimage? Board: Mellanox PPC460EX Board Be careful. Even if boards are similar the code for one board (canyonlands) will most certainly NOT run on different hardware (even if you consider the differences to be small). Make sure you have a JTAG debugger at hand in case you brick your board (alternatively, make sure you have a working boot image in NAND for recovery). 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 Experience is what causes a person to make new mistakes instead of old ones. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to test a new u-boot image over network?
Hi Anatolij, Before I attempt to burn the new image in the flash, I want to test it first. There are instruction on burning this image in to flash but The documentation that I am looking says following:- == If U-Boot is already installed and running on your board, you can use these instructions to download another U-Boot image to replace the current one. ALERT! Warning: Before you can install the new image, you have to erase the current one. If anything goes wrong your board will be dead. It is strongly recommended that: you have a backup of the old, working U-Boot image you know how to install an image on a virgin system ALERT! Proceed as follows: The rest of the instructions are for burning it in the flash. === I am complete newbie at this. I also tried go load_address but that caused immediate crash. I am hoping that this is trivial for somebody who has updated u-boot code. If I am using wrong command, please tell me correct command to test the u-boot from RAM before burning it to the flash. Thanks, - Vikas -Original Message- From: Anatolij Gustschin [mailto:ag...@denx.de] Sent: Wednesday, December 07, 2011 2:59 PM To: Sontakke, Vikas Cc: U-Boot@lists.denx.de Subject: Re: [U-Boot] How to test a new u-boot image over network? Hi, On Wed, 7 Dec 2011 12:41:38 -0500 vikas.sonta...@emc.com wrote: ... uboot-sources-EMC/u-boot-2009.01 file u-boot.bin u-boot.bin: u-boot/PPCBoot image uboot-sources-EMC/u-boot-2009.01 mkimage -d u-boot.bin u-boot.bin.load Image Name: Created: Wed Dec 7 12:08:45 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:393216 Bytes = 384.00 kB = 0.38 MB Load Address: 0x Entry Point: 0x uboot-sources-EMC/u-boot-2009.01 I then tftp the image u-boot.bin.load and bootm it but I am getting following error. Error: Bad gzipped data GUNZIP: uncompress or overwrite error - must RESET board to recover Did you read the documentation? Why are you trying to boot U-Boot image using 'bootm' command? 'bootm' command is used for booting operating system images. If you want to update U-Boot on the board, you need to write it into the flash memory used for booting. Do you have a JTAG debugger for the case updating U-Boot image goes wrong for some reason? I have tried many different load addresses such as 0x40., 0x400., 0x800., 0x1000.. with exactly the same behaviour. What am I missing? Please read U-Boot documentation [1] to understand which command is used for which purpose. Updating U-Boot is also described in the U-Boot documentation. HTH, Anatolij [1] http://www.denx.de/wiki/view/DULG/UBoot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/esd/cpci405/cpci405.c: Fix GCC 4.6 warning
Dear Matthias Fuchs, In message 4ece6529.8050...@esd.eu you wrote: Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- board/esd/cpci405/cpci405.c |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) Applied, thanks. Stefan, hope this is OK with you, but I want to get rid of these warnings. 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 You said you didn't want to use CGI.pm, but methinks you are needlessly reinventing the wheel, one spoke at a time. Either you are masochistic, or you just haven't seen enough of what CGI.pm can do for you. -- Randal L. Schwartz in 8cyb81rg81@gadget.cscaper.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to test a new u-boot image over network?
Hi Wolfgang, I received the sources from the vendor for the u-boot. I built it using ELDK. I want to do sanity check by verifying that my u-boot binary image can work *before* burning it to the flash. I am presuming that this is possible i.e. test u-boot from RAM before burning to flash. I have built the image which is specifically built for this board. The reason I did mkimage on it because I got the following error message when I attempted to boot the u-boot.bin image as it was produced by the make all. Here is snippet from the console:- = tftp 0x40 u-boot.bin Waiting for PHY auto negotiation to complete. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 192.168.100.253; our IP address is 192.168.100.22 Filename 'u-boot.bin'. Load address: 0x40 Loading: T ### done Bytes transferred = 393216 (6 hex) = bootm Bad Header Checksum ERROR: can't get kernel image! That is why I thought I needed to put a header on it. I also tried to use go command instead of boot and I had followuing error:- = tftpboot 0x100 u-boot.bin Waiting for PHY auto negotiation to complete. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 192.168.100.253; our IP address is 192.168.100.22 Filename 'u-boot.bin'. Load address: 0x100 Loading: T ### done Bytes transferred = 393216 (6 hex) = go 0x100 ## Starting application at 0x0100 ... NIP: 0100 XER: LR: 7FF6A564 REGS: 7fe52c88 TRAP: 0700 DEAR: 87E003E 7 MSR: 00029000 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 7FF6A5E8 7FE52D78 7FE52F24 0001 7FE5873C 7FE5873C 000B F71BD70D GPR08: 7FF5B40C 0020 05F5E101 3B9ACA0C 0001 FFBEBFF7 7FFAFB00 GPR16: 7FFA40F4 7FFAC388 GPR24: 7FE58688 7FE5873C 0100 7FFB03C8 0002 ** Illegal Instruction ** Call backtrace: 0100 7FF6A5E8 7FF7C3C4 7FF7BAC8 7FF7BC38 7FF7E7F0 7FF5AF68 7FF59710 Program Check Exception = I am using following DULG documentation (5.4.3 Installation using U-Boot) http://www.denx.de/wiki/view/DULG/UBootInstallUsingUBoot which tells how to burn the new u-boot but does not tell me how to run *without* burning. Please help! I hope I am not asking something impossible. Thanks, - Vikas -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, December 07, 2011 3:13 PM To: Sontakke, Vikas Cc: U-Boot@lists.denx.de Subject: Re: [U-Boot] How to test a new u-boot image over network? Dear vikas.sonta...@emc.com, In message 629d989c137dd040a0a994bd21888f1e75e81...@mx29a.corp.emc.com you wrote: I have built a new u-boot for a board which is very similar to canyonlands. But I am having problem in running it. Afterwards, I ran mkimage on it. Why did you do that? I then tftp the image u-boot.bin.load and bootm it but I am getting following error. Error: Bad gzipped data GUNZIP: uncompress or overwrite error - must RESET board to recover What makes you think this could work? There is no documentation anywhere that desribes such an approach, so why do you think this could work? Why don't you simply read the DULG for the canyonlands board an follow the steps described there to install a new U-Bootimage? Board: Mellanox PPC460EX Board Be careful. Even if boards are similar the code for one board (canyonlands) will most certainly NOT run on different hardware (even if you consider the differences to be small). Make sure you have a JTAG debugger at hand in case you brick your board (alternatively, make sure you have a working boot image in NAND for recovery). 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 Experience is what causes a person to make new mistakes instead of old ones. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: cfb_console: fix build warnings
Dear Anatolij Gustschin, In message 1323266290-31142-1-git-send-email-ag...@denx.de you wrote: Fix: cfb_console.c:371: warning: 'cursor_state' defined but not used cfb_console.c:372: warning: 'old_col' defined but not used cfb_console.c:373: warning: 'old_row' defined but not used cfb_console.c:435: warning: 'video_invertchar' defined but not used Signed-off-by: Anatolij Gustschin ag...@denx.de --- I forgot to run MAKEALL for both, arm and powerpc for last CFB patch, sorry. drivers/video/cfb_console.c | 38 +- 1 files changed, 17 insertions(+), 21 deletions(-) Indeed, this fixes the build warnings. Thanks. Tested-by: Wolfgang Denk w...@denx.de [If it's OK with you, I will pull this direcxtly.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can't understand it. I can't even understand the people who can understand it.- Queen Juliana of the Netherlands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: cfb_console: fix build warnings
Hello Wolfgang, On Wed, 07 Dec 2011 21:32:33 +0100 Wolfgang Denk w...@denx.de wrote: ... drivers/video/cfb_console.c | 38 +- 1 files changed, 17 insertions(+), 21 deletions(-) Indeed, this fixes the build warnings. Thanks. Tested-by: Wolfgang Denk w...@denx.de [If it's OK with you, I will pull this direcxtly.] Yes, it is OK. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: cfb_console: fix build warnings
Dear Anatolij Gustschin, In message 1323266290-31142-1-git-send-email-ag...@denx.de you wrote: Fix: cfb_console.c:371: warning: 'cursor_state' defined but not used cfb_console.c:372: warning: 'old_col' defined but not used cfb_console.c:373: warning: 'old_row' defined but not used cfb_console.c:435: warning: 'video_invertchar' defined but not used Signed-off-by: Anatolij Gustschin ag...@denx.de --- I forgot to run MAKEALL for both, arm and powerpc for last CFB patch, sorry. drivers/video/cfb_console.c | 38 +- 1 files changed, 17 insertions(+), 21 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Many companies that have made themselves dependent on [the equipment of a certain major manufacturer] (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the un- mastered complexity of their data processing systems. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 6/7] powerpc/mpc8349emds: Migrate from spd_sdram to unified DDR driver
On Wed, 2011-12-07 at 21:40 +0100, Wolfgang Denk wrote: Dear Kim Kumar, many weeks ago in message 20111023095323.2087511f9...@gemini.denx.de I wrote: Dear Kumar Gala, In message 2a6300e8-a874-49ac-84cb-be681af1b...@freescale.com you wrote: On Aug 26, 2011, at 1:32 PM, York Sun wrote: Update MPC8349EMDS to use unified DDR driver instead of spd_sdram.c. The unified driver can initialize data using DDR controller. No need to use DMA if just to initialze for ECC. Signed-off-by: York Sun york...@freescale.com Signed-off-by: Kim Phillips kim.phill...@freescale.com --- board/freescale/mpc8349emds/Makefile |1 + board/freescale/mpc8349emds/ddr.c | 107 + board/freescale/mpc8349emds/mpc8349emds.c | 26 --- include/configs/MPC8349EMDS.h | 16 4 files changed, 139 insertions(+), 11 deletions(-) create mode 100644 board/freescale/mpc8349emds/ddr.c applied to 85xx 'next' Did you test it??? This patch breaks out-of-tree building of the MPC8349EMDS board: + MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG + BUILD_DIR=/work/wd/tmp-ppc + ./MAKEALL MPC8349EMDS Configuring for MPC8349EMDS board... make[1]: *** No rule to make target `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend.ddr-gen2', needed by `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend'. Stop. make[1]: *** No rule to make target `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend.ddr-gen2', needed by `/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/.depend'. Stop. make: *** [depend] Error 2 [Local building works.] Note also that make distclean still leaves a file arch/powerpc/cpu/mpc83xx/ddr-gen2.c Please fix this, too. Is anybody going to fix this? Or can I assume the board is dead and we can remove it? A patch was sent on Oct 25 to fix this http://patchwork.ozlabs.org/patch/121746/ York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] PIP405: build warnings
Dear Denis, the PIP405 board throws some build warnings: Configuring for PIP405 board... ../common/isa.c: In function 'handle_isa_int': ../common/isa.c:385:21: warning: variable 'isr2' set but not used [-Wunused-but-set-variable] ../common/isa.c:385:16: warning: variable 'isr1' set but not used [-Wunused-but-set-variable] Are you going to fix these, or can we assume this board is dead and can be removed? Thanks. 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 witty saying proves nothing, but saying something pointless gets people's attention. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to test a new u-boot image over network?
Dear vikas.sonta...@emc.com, In message 629d989c137dd040a0a994bd21888f1e75e81...@mx29a.corp.emc.com you wrote: I am using following DULG documentation (5.4.3 Installation using U-Boot) h= ttp://www.denx.de/wiki/view/DULG/UBootInstallUsingUBoot which tells how to= burn the new u-boot but does not tell me how to run *without* burning. You cannot run the image without buring it to flash. Did you bother to read the FAQ? The very first U-Boot FAQ handles your situation: http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM You may be able to istall a NAND booting version of U-Boot to NAND flash (assuming your out-of-tree port supports NAND booting). Once you got this working, you have a recovery system, and you can erase and re-program the NOR flash without risk. 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 are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious defi- ciencies. - Charles Anthony Richard Hoare ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2 6/7] powerpc/mpc8349emds: Migrate from spd_sdram to unified DDR driver
Dear York Sun, In message 1323290774.27412.25.camel@oslab-l1 you wrote: Is anybody going to fix this? Or can I assume the board is dead and we can remove it? A patch was sent on Oct 25 to fix this http://patchwork.ozlabs.org/patch/121746/ Yes, and Kim wrote on Fri, 11 Nov 2011: this somehow got lost from my inbox, but I grabbed it from patchwork and applied it to 83xx. But I haven't seen any pull request since. So I have to assume this is dead code and nobody cares about it any more ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The so-called desktop metaphor of today's workstations is instead an airplane-seat metaphor. Anyone who has shuffled a lap full of papers while seated between two portly passengers will recognize the difference -- one can see only a very few things at once. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ARM] Pending patches for december release?
Hi Wolfgang, On Wed, Dec 7, 2011 at 10:36 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message capnjgz0bwjrt+m8qdev7d2chp-nzpgvpvbzvgmfy4phre_d...@mail.gmail.com you wrote: Albert, the correct series is the I delegated to you, not the one in my email. It tidies up the ARM link scripts: http://patchwork.ozlabs.org/patch/126933/ http://patchwork.ozlabs.org/patch/126930/ http://patchwork.ozlabs.org/patch/126927/ http://patchwork.ozlabs.org/patch/126931/ http://patchwork.ozlabs.org/patch/126926/ http://patchwork.ozlabs.org/patch/126928/ http://patchwork.ozlabs.org/patch/126932/ This is all post-mergewindow stuff. Does it qualify as bug fixes? Oh ok, no this is just a clean-up, it doesn't fix any bugs. We can worry about it later. Regards, Simon 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 Wait! You have not been prepared! -- Mr. Atoz, Tomorrow is Yesterday, stardate 3113.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] please pull u-boot-mpc83xx fixes
Wolfgang, Please pull: The following changes since commit 5721385b187b3154c7768e6c182501022f4e2e45: Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx (2011-11-08 07:44:52 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Andreas Huber (1): powerpc/83xx: fix sdram initialization for keymile boards York Sun (1): powerpc/mpc83xx: cleanup makefile for mpc83xx Makefile |1 + arch/powerpc/cpu/mpc83xx/Makefile |9 +++-- board/keymile/km83xx/km83xx.c |2 +- 3 files changed, 5 insertions(+), 7 deletions(-) Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ne2000: Convert to new net-multi model, fixes build of three boards
This fixes the build of the two sh boards shmin and r7780mp and qemu-mips which currently fail to build due to dropped pre-CONFIG_NET_MULTI code. This v2 patch minimizes the number of lines in the diff for easy review and to eliminate any possible accidential changes resulting from moving lines of code in the file. This also makes the register function very easy. Any cleanups and improvements are intentionally deferred to follow-up patches to keep this patch as simple and as easy to review as possible. A new driver register function, ne2k_register() calls the existing one-time setup part of the old init function and calls eth_register(). Changes to shmin, r7780mp and qemu-mips: - Call the new ne2k_register() from board_eth_init() of the boards. - Tested using qemu-mips board, - Tested the two renesas / sh boards r7780mp and shmin to compile again, and should work. checkpatch-clean when --ignore VOLATILE is added to .checkpatch.conf, and no warnings introduced in none of the three boards using this driver. Signed-off-by: Bernhard Kaindl bernhard.kai...@gmx.net --- board/qemu-mips/qemu-mips.c |6 ++ board/renesas/r7780mp/r7780mp.c |3 +- board/shmin/shmin.c |6 ++ drivers/net/ne2000_base.c | 99 --- include/netdev.h| 1 + 5 files changed, 86 insertions(+), 29 deletions(-) I think this patch is absolutelly essential to have in .12 release. I'll test it now and ev. rebase and resubmit. Bernhard, you're ok with me doing minor fixes? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/gpio/da8xx_gpio.c: Fix build warning
Fix:
da8xx_gpio.c: In function 'gpio_toggle_value':
da8xx_gpio.c:208:23: warning: variable 'bank' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/gpio/da8xx_gpio.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/da8xx_gpio.c b/drivers/gpio/da8xx_gpio.c
index 7a15614..74b58e8 100644
--- a/drivers/gpio/da8xx_gpio.c
+++ b/drivers/gpio/da8xx_gpio.c
@@ -205,9 +205,6 @@ void gpio_free(int gp)
void gpio_toggle_value(int gp)
{
- struct davinci_gpio *bank;
-
- bank = GPIO_BANK(gp);
gpio_set_value(gp, !gpio_get_value(gp));
}
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
