Re: [U-Boot] [PATCH 5/9] apf9328: add default board configuration file
Dear Wolfgang, Dear Stefano, On 23 août 2011, at 13:26, Wolfgang Denk wrote: Dear Eric Jarrige, can you please mind your line length? It is strongly recommended that text lines should not exceed 70 characters or so. Thanks. I will take care of that. I do apologize for the inconvenient. In message 1fad4112-2a57-415d-9cdf-8fc7a9edb...@armadeus.org you wrote: +#define CONFIG_EXTRA_ENV_SETTINGS \ + env_version= CONFIG_ENV_VERSION \0\ + fileaddr= MK_STR(CONFIG_SYS_LOAD_ADDR)\0\ + filesize= MK_STR(CONFIG_SYS_MONITOR_LEN) \0\ filesize is dynamically computed, you should not add it We need this variable already initialized at boot time to support the specific imx boot mode from serial port when the user lost the full content of the flash. Stefano is right. filesize and fileaddr are dynamic variables, thet get created and updated on the fly. It makes no sense to pre-define them to any specific value. [Actually I have some changes in mind that avoid to save such variables with the environment at all.] I understand - It make sense for me to wait for the new interface. In such case (that is a stressing situation for the user) he can push U-Boot through the serial port and use directly the script flash_uboot to recover the original content of the flash. In such a use case this variable is not dynamically computed. What do you mean by push U-Boot through the serial port? Any of the respective commands in U-Boot (loads, loadb, loady) will automatically update the respective variables. I meant to boot using the iMX internal bootstrap loader as U-Boot is not yet running. Alternatively I can download U-Boot a second time to have the environment variables initialized. It is just a longer process than the original one. +#define CONFIG_NETMASK255.255.255.0 +#define CONFIG_IPADDR 192.168.000.10 Please drop fix ip address. They should not be part of mainline, Here, I have a problem as our documentation on the wiki armadeus.org is based on this default IP addresses. Then fix the documentation? That is something we will do in any case. It is a somewhat bad idea to publish documentation to end users before the code has passed even the inital code review... Thanks for the recommendation. We really need a set of default IP addresses for private network to simplify as much as possible the life of the armadeus project developers. And what makes you think that 192.168.0.10 might be a free IP address in my network? Or assume that 255.255.255.0 is the right netmask in this network? http://tools.ietf.org/html/rfc1918#page-4 These addresses may work for you, but they will not work for others, and thus it makes no sense to use them as defaults. The armadeus BSP provide a user interface to customize the network parameters according to end user network environment. If you need a reasonable default, then configure the board to use DHCP. I never seen such a restriction in U-Boot doc and moreover there is a set CONFIG_XXIP documented in U-BOOT that confusing me, There are situations where this cannot be avoided - like when U-Boot is installed in a ROM, where the environment cannot be changed at all, and where for some reason DHCP or similar is not possible. But that does not mean that this makes sense for the generic case. Is there another solution for a complete usable default configuration? Use DHCP? Sure, DHCP is the best *technical* solution. I meant for static IP address? Why do we need such a stuff when your configuration is fixed at compile time with CONFIG_SYS_SDRAM_MBYTE_SYZE 16 ? 16MiB is the regular configuration but there are many configurations of boards with different size of memory. This set of parameters enables to support every boards at compilation by just changing the value of CONFIG_SYS_SDRAM_MBYTE_SYZE. So that the binary generated is fully optimized for each board. That's a maintenance nightmage for everybody and not needed at all. Please use get_ram_size() to have U-Boot auto-adjust to the actual RAM size of your board and forget about all such static optimizations. Thanks for the update. +#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE \ + + CONFIG_SYS_SDRAM_1_SIZE - 0x010) You do not use U_Boot macro here (GENERATED_GBL_DATA_SIZE), as it is usual. Stack pointer is already in RAM before relocation. Is it correct ? Correct. I do have to optimize the location of the initial Stack pointer for my board so I put the init SP at any safe place in RAM. I find your answers not really helpful and constructive. You write you have to optimize the location, but you fail to explain why you think so. I consider it likely that you are wrong about the optimize part. And you are definitely wrong about the rest, as you obviously did not understand Stefano's
Re: [U-Boot] [PATCH 5/9] apf9328: add default board configuration file
On 08/24/2011 06:56 AM, Eric Jarrige wrote: Dear Wolfgang, Dear Stefano, Hi Eric, We really need a set of default IP addresses for private network to simplify as much as possible the life of the armadeus project developers. And what makes you think that 192.168.0.10 might be a free IP address in my network? Or assume that 255.255.255.0 is the right netmask in this network? http://tools.ietf.org/html/rfc1918#page-4 Really RFC1918 reservs only IP addresses for private use, but there is nothing regarding a default IP address. And nothing different as usual how to assign the addresses to the hosts. To set a static IP address when DHCP is not available (a sort of autoconfiguration without DHCP server), the link-local address range should be used (169.254.0.0/16), described in http://tools.ietf.org/html/rfc3927. It sets a random IP in the range and checks with ARP that the address is not already used in the network. However, it is outside the goals of a bootloader ;-) 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
Re: [U-Boot] [PATCH 5/9] apf9328: add default board configuration file
Dear Eric, In message 20110824054915.0860711f9...@gemini.denx.de I wrote: Sure, DHCP is the best *technical* solution. I meant for static IP address? Why does anybody need static IP addresses for the default case, i. e. for system bring up? And if you need one, what is the issue with using setenv ipaddr at the serial console? 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 Don't put off for tomorrow what you can do today, because if you enjoy it today you can do it again tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] New init sequence processing without init_sequence array
Dear Graeme Russ,
In message CALButCLX42Q=u33gcoka+lozz+rzo1y-sxnhe8mk66dfru9...@mail.gmail.com
you wrote:
But frankly: do you consider this list above _readable_?
...
grep is your friend - All you need to to is grep for GLOBAL (actually I
think COMMON is a better name) and the ARCH, SOC, and BOARD keywords in
the namespace for your board and voila - You have a sorted list of the
init sequence for you board
Yes, this is exactly what I mean. I will need additional tools to
be able to read the code. I cannot - for example - print a few pages
of source code and check the lines that worked, or similar.
It would be trivial to enable printing the names from the loop; we
can't do it because we don't have the needed prerequisites yet in most
cases.
How so? I cannot see how you could create a macro which when used in the
static array initialiser would send the function pointers to one array and
the string names (or pointers to) to another array.
See the example in the CPP info pages: cpp.info, Node: Concatenation:
#define COMMAND(NAME) { #NAME, NAME ## _command }
How does debugging in that case work now? There is no difference between
the two implementations - the only thing I am changing is:
Right. So we cannot say that the initcall code is any improvment here.
The difference is that I have a source file for reference.
Huh? You still do in the initcall case
Agreed. I should have written: I have a _readable_ source file that
can be parsed without additional tools.
With the init.h as above I have no such reference.
No reference to what? - the static array of function pointers? This is of
little use anyway as all your debug stepping will do is pick up the next
value from the array
But I can _see_ what the next entry will be.
No, it becomes a clean linear list of the init sequence from which you
can easily grep out the noise. This list will never have an init step
defined out-of-order. If INIT_YOUR_BOARD_ETHERNET occurs after
INIT_YOUR_ARCH_PCI in the list then you know your board initialises its
Ehternet after the arch has initialised PCI
If I see some INIT_YOUR_ARCH_FOO in this list - how can I see if this
is actually being executed on my specific board? This might depend on
a number of feature selections, so it is run on one board but not on
another.
Yes, you remove the #ifdef's - but here in this case this is exactly
the information that would be needed one way or another.
I bet that rather sooner than later you will end up with some toold
that parses either the ELF file or the linker map or the symbol table
to generate a readable list for the current build. I bet a case of
beer that you will need such a tool. We don't need it now.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If there are self-made purgatories, then we all have to live in them.
-- Spock, This Side of Paradise, stardate 3417.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31: make HSP clock for mx3fb driver available
On 08/22/2011 06:02 PM, Marek Vasut wrote: ... _COSMETIC_, while this new mx3fb driver really works nicely ;-) Oh my sense for metrosexuality of code really kicks in here ;-) Arousal was not my first objective, but deliberately endorsed :-P I'll do what can be done easily concerning the bit accesses. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] New init sequence processing without init_sequence array
Hi Wolfgang,
On Wed, Aug 24, 2011 at 4:48 PM, Wolfgang Denk w...@denx.de wrote:
Dear Graeme Russ,
In message
CALButCLX42Q=u33gcoka+lozz+rzo1y-sxnhe8mk66dfru9...@mail.gmail.com you
wrote:
But frankly: do you consider this list above _readable_?
...
grep is your friend - All you need to to is grep for GLOBAL (actually I
think COMMON is a better name) and the ARCH, SOC, and BOARD keywords in
the namespace for your board and voila - You have a sorted list of the
init sequence for you board
Yes, this is exactly what I mean. I will need additional tools to
be able to read the code. I cannot - for example - print a few pages
of source code and check the lines that worked, or similar.
Well if the use of grep irks you so, I dare you to rm grep ;)
It would be trivial to enable printing the names from the loop; we
can't do it because we don't have the needed prerequisites yet in most
cases.
How so? I cannot see how you could create a macro which when used in the
static array initialiser would send the function pointers to one array and
the string names (or pointers to) to another array.
See the example in the CPP info pages: cpp.info, Node: Concatenation:
#define COMMAND(NAME) { #NAME, NAME ## _command }
Ah, so turn the current array into a two element array containing a
function pointer and string pointer. I guess that would work, but that will
totally change the symantics of the static variable between debug and non
debug builds - Not an optimal scenario in my mind
How does debugging in that case work now? There is no difference between
the two implementations - the only thing I am changing is:
Right. So we cannot say that the initcall code is any improvment here.
The difference is that I have a source file for reference.
Huh? You still do in the initcall case
Agreed. I should have written: I have a _readable_ source file that
can be parsed without additional tools.
I would hardly call 'grep' an extra tool - How many programmers do you
know that have never used grep?
With the init.h as above I have no such reference.
No reference to what? - the static array of function pointers? This is of
little use anyway as all your debug stepping will do is pick up the next
value from the array
But I can _see_ what the next entry will be.
And by defining #DEBUG I can have a parallel list of function names so when
the loop picks up the next funtion pointer, it picks up the name as well
ready to examine before stepping in - OK, not ideal, but still, I think
the flexibility to seamlessly inject init functions at the board level
outweighs this
No, it becomes a clean linear list of the init sequence from which you
can easily grep out the noise. This list will never have an init step
defined out-of-order. If INIT_YOUR_BOARD_ETHERNET occurs after
INIT_YOUR_ARCH_PCI in the list then you know your board initialises its
Ehternet after the arch has initialised PCI
If I see some INIT_YOUR_ARCH_FOO in this list - how can I see if this
is actually being executed on my specific board? This might depend on
a number of feature selections, so it is run on one board but not on
another.
Technically we have the same issue with weak functions - Just because you
have code that overrides them, does not mean that code gets compiled in.
The initcall solution introduces no additional 'issues' that we are not
already dealing with on a day-to-day basis.
Yes, you remove the #ifdef's - but here in this case this is exactly
the information that would be needed one way or another.
I bet that rather sooner than later you will end up with some toold
that parses either the ELF file or the linker map or the symbol table
to generate a readable list for the current build. I bet a case of
beer that you will need such a tool. We don't need it now.
Sorry, I don't have a crystal ball
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] DM9000:Add a byte swap macro for dm9000 io operation.
Subject: Re: [U-Boot] [PATCH 7/9] DM9000:Add a byte swap macro for dm9000 io operation. On Tuesday, August 23, 2011 01:47:54 Jason Jin wrote: +#ifndef DM9000_BYTE_SWAPPED should be CONFIG_XXX -mike [Jin Zhengxiong-R64188] Thanks Mike, I'll updated this in next version. -Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] ARM: Add Calxeda Highbank platform
Le 23/08/2011 16:32, Rob Herring a écrit : Albert, On 08/21/2011 02:28 PM, Rob Herring wrote: On 08/21/2011 09:40 AM, Albert ARIBAUD wrote: Hi Rob, Le 21/08/2011 15:16, Rob Herring a écrit : From: Rob Herringrob.herr...@calxeda.com Add basic support for Calxeda Highbank platform. Only minimal support with serial and SATA are included. Signed-off-by: Jason Hobbsjason.ho...@calxeda.com Signed-off-by: Rob Herringrob.herr...@calxeda.com Cc: Albert ARIBAUDalbert.u.b...@aribaud.net --- This applies to u-boot-arm/master, with three empty lines at end of new files removed, but the compilation with ELDK 4.2 fails with: uboot@lilith:~/src/u-boot-arm$ ./MAKEALL highbank Configuring for highbank board... include/common.h:0: error: bad value (armv7-a) for -march= switch include/common.h:0: error: bad value (armv7-a) for -march= switch lib/asm-offsets.c:1: error: bad value (armv7-a) for -march= switch make: *** [lib/asm-offsets.s] Erreur 1 arm-linux-size: './u-boot': No such file - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( highbank ) -- Seems like ELDK 4.2 does not know armv7-a. Is it a requirement that this board build with this march flag? With device tree, there are lots of endian conversions. With v7, those conversions are a single inline rev instruction vs. 10-20 assembly instructions. Since there is no state maintained in the fdt code, the conversions are done over and over. So there's not a hard requirement, but it is something I will always set and I imagine others with v7 platforms will want to also. I think Tegra prevents doing this change globally. What do you want to do here? arch/arm/cpu/armv7/highbank/config.mk can simply be deleted if you don't want to compile with armv7-a. Well, it is more a question of which toolchain(s) we want supported in U-Boot. Denx ELDK is one of them I guess :) but now that ELDK 5.0 is out, I don't know if ELDK 4.2 support is still required. (I am assuming that ELDK5.0 has armv7-a support here. Please correct me if not) If ELDK4.2 must be supported, then I would suggest creating a configuration option to allow the use of armv7-a ISA, then the arch/arm/cpu/armv7/highbank/config.mk file would select armv7-a ISA based on this option, and then any ARMv7 compatible board that needs or wants to use this ISA can set this config option in its config header file. If ELDK4.2 support is dropped (at least partially) then no change would be needed. Wolfgang:, I think that toolchain support for ARM is more your choice than mine. Rob Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] ARM: Add Calxeda Highbank platform
Le 24/08/2011 10:37, Albert ARIBAUD a écrit : Le 23/08/2011 16:32, Rob Herring a écrit : Albert, On 08/21/2011 02:28 PM, Rob Herring wrote: On 08/21/2011 09:40 AM, Albert ARIBAUD wrote: Hi Rob, Le 21/08/2011 15:16, Rob Herring a écrit : From: Rob Herringrob.herr...@calxeda.com Add basic support for Calxeda Highbank platform. Only minimal support with serial and SATA are included. Signed-off-by: Jason Hobbsjason.ho...@calxeda.com Signed-off-by: Rob Herringrob.herr...@calxeda.com Cc: Albert ARIBAUDalbert.u.b...@aribaud.net --- This applies to u-boot-arm/master, with three empty lines at end of new files removed, but the compilation with ELDK 4.2 fails with: uboot@lilith:~/src/u-boot-arm$ ./MAKEALL highbank Configuring for highbank board... include/common.h:0: error: bad value (armv7-a) for -march= switch include/common.h:0: error: bad value (armv7-a) for -march= switch lib/asm-offsets.c:1: error: bad value (armv7-a) for -march= switch make: *** [lib/asm-offsets.s] Erreur 1 arm-linux-size: './u-boot': No such file - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( highbank ) -- Seems like ELDK 4.2 does not know armv7-a. Is it a requirement that this board build with this march flag? With device tree, there are lots of endian conversions. With v7, those conversions are a single inline rev instruction vs. 10-20 assembly instructions. Since there is no state maintained in the fdt code, the conversions are done over and over. So there's not a hard requirement, but it is something I will always set and I imagine others with v7 platforms will want to also. I think Tegra prevents doing this change globally. What do you want to do here? arch/arm/cpu/armv7/highbank/config.mk can simply be deleted if you don't want to compile with armv7-a. Well, it is more a question of which toolchain(s) we want supported in U-Boot. Denx ELDK is one of them I guess :) but now that ELDK 5.0 is out, I don't know if ELDK 4.2 support is still required. (I am assuming that ELDK5.0 has armv7-a support here. Please correct me if not) If ELDK4.2 must be supported, then I would suggest creating a configuration option to allow the use of armv7-a ISA, then the arch/arm/cpu/armv7/highbank/config.mk file would select armv7-a ISA based on this option, and then any ARMv7 compatible board that needs or wants to use this ISA can set this config option in its config header file. If ELDK4.2 support is dropped (at least partially) then no change would be needed. ... adding Wolfgang, this time... Wolfgang:, I think that toolchain support for ARM is more your choice than mine. Rob Amicalement, Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FDT without FIT?
Dear Wolfgang Denk, On 08/23/2011 07:45 PM, Wolfgang Denk wrote: Dear Simon Schwarz, In message4e53c9f6.4010...@gmail.com you wrote: How can FDT be used without a FIT image? I don't understand this question - using the FDT and the image format are orthogonal to each other. I can't really get this from the code - if someone can point me in the right direction this would be great! Try: help bootm This prints: # help bootm bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image cmdline - OS specific command line processing/setup bdt - OS specific bd_t processing prep- OS specific prep before relocation or go go - start OS (Yes, #define CONFIG_OF_LIBFDT 1 is in my board config) For example: tftp 60 uImage tftp 90 board.dtb bootm 60 - 90 What exactly is your problem? Thanks - john already pointed me to this. This works. It was/is just a problem with the help text - duno why.. Best regards, Wolfgang Denk Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
Hi, On Tue, 23 Aug 2011 23:00:59 -0400 Mike Frysinger vap...@gentoo.org wrote: On Tuesday, August 23, 2011 18:42:46 Wolfgang Denk wrote: Mike Frysinger wrote: Why cannot we define a macro that declares a (sufficiently sized) buffer on the stack and provides and a pointer to a (correctly aligned) address in this buffer? isnt that what i already posted and you NAK-ed ? :) DMA_DECLARE_BUFFER(...) I just NAKed this specific implementation. well, it's hard to come up with a good one without knowing the parameters to work within ;). i'm not stuck on any particular implementation, i just want the helper to be simple to use and hard to screw up. the trouble with doing something like: char foo[func_to_do_round(size)]; is that size is not in # of bytes but is number of elements. so the point of my (i dont deny) complicated cpp logic was so that the internal implementation took on more of the work leaving the user (which we all know can easily mess things up) with a very simple macro: DMA_DECLARE_BUFFER(buffer type, variable name, num elements); -mike After reading dcache related threads I'd like to sum them up: 1. alloca() - not acceptable to u-boot mainline by Wolfgang. I agree that alloca is NOT the way to go. 2. malloc/memalign - avoidable to use 3. Mike's DMA_DECLARE_BUFFER(buffer type, variable name, size in bytes) solution looks OK for me, at least for the stack allocated data (e.g. ext_csd). However this proposed implementation has been NAK'ed by Wolfgang. I'm curious how this macro should look like? Is it only matter of code reordering or other approach shall be found? 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. However, I think, that proposed get_dcache_line_size() implementation ( http://patchwork.ozlabs.org/patch/111048/ ) is more programmer friendly (one don't need to exactly know the dcache line size on a particular SoC). -- Best regards, Lukasz Majewski Samsung Poland RD Center Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/8] SPL Linux boot
Adds direct Linux boot to SPL. It implements a savebp command to save ATAGS or FDT to NAND flash. The kernel image has to be in place for this! checkpatch whines about not using strict_strtoull - since this is not available - I can't change this. V2 changes: FIX FDT creation ADD Readme based on: - The new SPL layout - OMAP3 new SPL layout (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105260) Related to: - http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102669 Simon Schwarz (8): arm: Add Prep subcommand support to bootm Add savebp command arm: Add savebp implementation for arm omap-common/spl: Add linux boot to SPL devkit8000/spl: init GPMC for dm9000 in SPL omap-common: Add NAND SPL linux booting omap-common: fixes BSS overwriting problem savebp: added Readme arch/arm/cpu/armv7/omap-common/spl.c | 49 +- arch/arm/cpu/armv7/omap-common/spl_nand.c | 63 +--- arch/arm/include/asm/omap_common.h|2 + arch/arm/include/asm/savebp.h | 27 + arch/arm/lib/Makefile |1 + arch/arm/lib/bootm.c | 116 -- arch/arm/lib/savebp.c | 91 ++ board/timll/devkit8000/devkit8000.c | 33 +-- common/Makefile |1 + common/cmd_bootm.c|2 +- common/cmd_savebp.c | 149 + doc/README.commands.savebp| 28 ++ include/command.h |5 + include/configs/devkit8000.h | 14 +++- 14 files changed, 499 insertions(+), 82 deletions(-) create mode 100644 arch/arm/include/asm/savebp.h create mode 100644 arch/arm/lib/savebp.c create mode 100644 common/cmd_savebp.c create mode 100644 doc/README.commands.savebp -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/8] arm: Add Prep subcommand support to bootm
Adds prep subcommand to bootm implementation of ARM. When bootm is called with
the subcommand prep the function stops right after ATAGS creation and before
announce_and_cleanup.
This is used in savebp command
Signed-off-by: Simon Schwarz simonschwarz...@gmail.com
V2 changes:
nothing
---
arch/arm/lib/bootm.c | 116 +++--
common/cmd_bootm.c |2 +-
2 files changed, 65 insertions(+), 53 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..d3152ae 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -1,4 +1,7 @@
-/*
+/* Copyright (C) 2011
+ * Corscience GmbH Co. KG - Simon Schwarz schw...@corscience.de
+ * - Added prep subcommand support
+ *
* (C) Copyright 2002
* Sysgo Real-Time Solutions, GmbH www.elinos.com
* Marius Groeger mgroe...@sysgo.de
@@ -55,7 +58,7 @@ static struct tag *params;
static ulong get_sp(void);
#if defined(CONFIG_OF_LIBFDT)
-static int bootm_linux_fdt(int machid, bootm_headers_t *images);
+static int bootm_linux_fdt(int machid, bootm_headers_t *images, int flag);
#endif
void arch_lmb_reserve(struct lmb *lmb)
@@ -98,63 +101,67 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
bd_t*bd = gd-bd;
char*s;
int machid = bd-bi_arch_number;
- void(*kernel_entry)(int zero, int arch, uint params);
+ void(*kernel_entry)(int zero, int arch, uint params) = NULL;
#ifdef CONFIG_CMDLINE_TAG
char *commandline = getenv (bootargs);
#endif
-
- if ((flag != 0) (flag != BOOTM_STATE_OS_GO))
- return 1;
-
- s = getenv (machid);
- if (s) {
- machid = simple_strtoul (s, NULL, 16);
- printf (Using machid 0x%x from environment\n, machid);
- }
-
- show_boot_progress (15);
+ if ((flag != 0) (!(flag BOOTM_STATE_OS_GO ||
+flag BOOTM_STATE_OS_PREP)))
+ return 1; /* subcommand not implemented */
+ else if ((flag == 0) || flag BOOTM_STATE_OS_PREP) {
+ s = getenv(machid);
+ if (s) {
+ strict_strtoul(s, 16, (long unsigned int *) machid);
+ printf(Using machid 0x%x from environment\n, machid);
+ }
+
+ show_boot_progress(15);
#ifdef CONFIG_OF_LIBFDT
- if (images-ft_len)
- return bootm_linux_fdt(machid, images);
+ if (images-ft_len)
+ return bootm_linux_fdt(machid, images, flag);
#endif
- kernel_entry = (void (*)(int, int, uint))images-ep;
+ kernel_entry = (void (*)(int, int, uint))images-ep;
- debug (## Transferring control to Linux (at address %08lx) ...\n,
- (ulong) kernel_entry);
+ debug(## Transferring control to Linux (at address %08lx) \
+ ...\n, (ulong) kernel_entry);
#if defined (CONFIG_SETUP_MEMORY_TAGS) || \
defined (CONFIG_CMDLINE_TAG) || \
defined (CONFIG_INITRD_TAG) || \
defined (CONFIG_SERIAL_TAG) || \
defined (CONFIG_REVISION_TAG)
- setup_start_tag (bd);
+ setup_start_tag(bd);
#ifdef CONFIG_SERIAL_TAG
- setup_serial_tag (params);
+ setup_serial_tag(params);
#endif
#ifdef CONFIG_REVISION_TAG
- setup_revision_tag (params);
+ setup_revision_tag(params);
#endif
#ifdef CONFIG_SETUP_MEMORY_TAGS
- setup_memory_tags (bd);
+ setup_memory_tags(bd);
#endif
#ifdef CONFIG_CMDLINE_TAG
- setup_commandline_tag (bd, commandline);
+ setup_commandline_tag(bd, commandline);
#endif
#ifdef CONFIG_INITRD_TAG
- if (images-rd_start images-rd_end)
- setup_initrd_tag (bd, images-rd_start, images-rd_end);
+ if (images-rd_start images-rd_end)
+ setup_initrd_tag(bd, images-rd_start, images-rd_end);
#endif
- setup_end_tag(bd);
+ setup_end_tag(bd);
#endif
+ if (flag BOOTM_STATE_OS_PREP)
+ return 0;
+ }
- announce_and_cleanup();
-
- kernel_entry(0, machid, bd-bi_boot_params);
- /* does not return */
+ if (flag == 0 || flag BOOTM_STATE_OS_GO) {
+ announce_and_cleanup();
+ kernel_entry(0, machid, bd-bi_boot_params);
+ /* does not return */
+ }
return 1;
}
@@ -174,10 +181,10 @@ static int fixup_memory_node(void *blob)
return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
}
-static int bootm_linux_fdt(int machid, bootm_headers_t *images)
+static int bootm_linux_fdt(int machid, bootm_headers_t *images, int flag)
{
ulong rd_len;
- void (*kernel_entry)(int zero, int dt_machid, void *dtblob);
+ void (*kernel_entry)(int zero, int dt_machid, void *dtblob) = NULL;
ulong of_size = images-ft_len;
[U-Boot] [PATCH V2 2/8] Add savebp command
This adds a savebp command to the u-boot.
Related config:
CONFIG_CMD_SAVEBP
activate/deactivate the command
CONFIG_CMD_SAVEBP_NAND_OFS
Offset in NAND to use
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
---
V2 changes:
CHG corrected bootm call. Now bootm is called with five parameters including
Address of FDT in RAM. This fixes the hang on savebp fdt call.
ADD debug output of the actual bootm parameter call
CHG help message
---
common/Makefile |1 +
common/cmd_savebp.c | 149 ++
include/configs/devkit8000.h |6 ++
3 files changed, 156 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_savebp.c
diff --git a/common/Makefile b/common/Makefile
index 124a427..0b42968 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -158,6 +158,7 @@ COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
+COBJS-$(CONFIG_CMD_SAVEBP) += cmd_savebp.o
# others
COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o
diff --git a/common/cmd_savebp.c b/common/cmd_savebp.c
new file mode 100644
index 000..a8801ca
--- /dev/null
+++ b/common/cmd_savebp.c
@@ -0,0 +1,149 @@
+/* Copyright (C) 2011
+ * Corscience GmbH Co. KG - Simon Schwarz schw...@corscience.de
+ *
+ * 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
+ */
+
+#include common.h
+#include command.h
+
+#define TYPE_FDT 0
+#define TYPE_ATAGS 1
+
+static inline int str2off(const char *p, loff_t *num)
+{
+ char *endptr;
+
+ *num = simple_strtoull(p, endptr, 16);
+ return *p != '\0' *endptr == '\0';
+}
+
+int do_savebp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ loff_t offset;
+ int img_type = TYPE_ATAGS;
+ int ret = 0;
+ int bootm_argc = 5;
+ char *bootm_argsv[] = {do_bootm, xxx, 0x8200, -,
+ 0x8100};
+
+ offset = (loff_t)CONFIG_CMD_SAVEBP_NAND_OFS;
+ bootm_argsv[2] = getenv(loadaddr);
+ /* - Validate args - */
+ switch (argc) {
+ case 6: /* 4. fdt addr */
+ if (strcmp(argv[5], -))
+ strcpy(bootm_argsv[4], argv[5]);
+ case 5: /* 5. initrd addr */
+ if (strcmp(argv[4], -))
+ strcpy(bootm_argsv[3], argv[4]);
+ case 4: /* 3. arg kernel addr */
+ if (strcmp(argv[3], -))
+ strcpy(bootm_argsv[2], argv[3]);
+ case 3: /* 2. arg offset */
+ if (strcmp(argv[2], -)) {
+ if (!str2off(argv[2], offset)) {
+ printf('%s' is not a number\n, argv[2]);
+ return cmd_usage(cmdtp);
+ }
+ }
+ case 2: /* 1. arg atags or fdt */
+ if (!strcmp(argv[1], fdt))
+ img_type = TYPE_FDT;
+ bootm_argc = 5;
+ else if (!strcmp(argv[1], atags)) {
+ img_type = TYPE_ATAGS;
+ bootm_argc = 4;
+ } else {
+ return cmd_usage(cmdtp);
+ }
+ /* using standard offset */
+ printf(using standard destination at: 0x%x\n,
+ (uint32_t)offset);
+ break;
+ default:
+ return cmd_usage(cmdtp);
+ }
+ debug(using as bootm arsgs: %s / %s / %s / %s / %s\n
+ , bootm_argsv[0], bootm_argsv[1], bootm_argsv[2],
+ bootm_argsv[3], bootm_argsv[4]);
+
+ /* - do the work - */
+ /* exec bootm_start as subcommand of do_bootm to init the images
+* data structure */
+ debug(exec bootm subcommand start\n);
+ bootm_argsv[1] = start;
+ ret = do_bootm(find_cmd(do_bootm), 0, bootm_argc, bootm_argsv);
+ debug(Subcommand start bootm retcode: %d\n, ret);
+
+ debug(exec bootm subcommand
[U-Boot] [PATCH V2 3/8] arm: Add savebp implementation for arm
This adds the savebp implementation to the arm platform.
Related CONFIGs:
CONFIG_CMD_SAVEBP_WRITE_SIZE defines the size of the image to write
Signed-off-by: Simon Schwarz simonschwarz...@gmail.com
---
V2 changes:
DEL _cosmetic_ old comment
---
arch/arm/include/asm/savebp.h | 27
arch/arm/lib/Makefile |1 +
arch/arm/lib/savebp.c | 91 +
include/command.h |5 ++
include/configs/devkit8000.h |1 +
5 files changed, 125 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/savebp.h
create mode 100644 arch/arm/lib/savebp.c
diff --git a/arch/arm/include/asm/savebp.h b/arch/arm/include/asm/savebp.h
new file mode 100644
index 000..3774e45
--- /dev/null
+++ b/arch/arm/include/asm/savebp.h
@@ -0,0 +1,27 @@
+/* Copyright (C) 2011
+ * Corscience GmbH Co. KG - Simon Schwarz schw...@corscience.de
+ *
+ * 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
+ */
+#ifndef _SAVEBP_H_
+#define _SAVEBP_H_
+
+extern bootm_headers_t images;
+
+#endif /* _SAVEBP_H_ */
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 300c8fa..abf7a6a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -44,6 +44,7 @@ COBJS-y += cache-cp15.o
COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
COBJS-y+= interrupts.o
COBJS-y+= reset.o
+COBJS-$(CONFIG_CMD_SAVEBP) += savebp.o
SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
SOBJS-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
endif
diff --git a/arch/arm/lib/savebp.c b/arch/arm/lib/savebp.c
new file mode 100644
index 000..e0cfd83
--- /dev/null
+++ b/arch/arm/lib/savebp.c
@@ -0,0 +1,91 @@
+/* Copyright (C) 2011
+ * Corscience GmbH Co. KG - Simon Schwarz schw...@corscience.de
+ *
+ * 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
+ */
+
+#include common.h
+#include command.h
+#include image.h
+
+#include nand.h
+#include asm/savebp.h
+
+#ifdef CONFIG_OMAP34XX
+#include asm/arch/sys_proto.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* This function writes given bootparams to NAND flash
+ * adr: Start adress of Kernel parameter image (ATAGS, FDT)
+ * length: length of the image in byte
+ * off: offset in NAND flash
+ *
+ * borrowd heavily from common/cmd_nand.c
+ */
+static void boot_params_to_nand(u_char *adr, size_t length, loff_t off)
+{
+ nand_info_t *nand = nand_info[0]; /* use 0 as in SPL */
+ nand_erase_options_t opts;
+#ifdef CONFIG_OMAP34XX
+ omap_nand_switch_ecc(1); /* use hw ecc on omap for SPL compat */
+#endif
+ /* erase */
+ memset(opts, 0, sizeof(opts));
+ opts.offset = off;
+ opts.length = length;
+ opts.quiet = 1;
+ opts.spread = 1;
+ nand_erase_opts(nand, opts);
+
+ /* write */
+ if (nand_write_skip_bad(nand, off, length, adr, 0)) {
+ printf(FAILED!\n);
+ return;
+ }
+
+ printf(Written to offset 0x%llX, size: %d bytes\n,
+ off, length);
+}
+
+/* Saves FDT to NAND */
+int do_savebp_fdt(loff_t offset)
+{
+ boot_params_to_nand((u_char *)images.ft_addr,
+ CONFIG_CMD_SAVEBP_WRITE_SIZE, offset);
+ return 0;
+}
+
+
+/* Saves ATAGS to NAND */
+int do_savebp_atags(loff_t offset)
+{
+ /* Vars */
+ bd_t *bd = gd-bd;
+
+ printf(write ATAGS to NAND...\n);
+
+ /* save em */
+ /* used fixed size - easier to read later just ignore garbage */
+ boot_params_to_nand((u_char
[U-Boot] [PATCH V2 4/8] omap-common/spl: Add linux boot to SPL
This adds Linux booting to the SPL
Related CONFIGs:
CONFIG_SPL_OS_BOOT
Activates/Deactivates the OS booting feature
CONFIG_SPL_OS_BOOT_KEY
defines the IO-pin number u-boot switch - if pressed u-boot is booted
CONFIG_SYS_SPL_MACHID
Machine ID of the used board
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 normaly
RAM-begin + 0x100
Signed-off-by: Simon Schwarz simonschwarz...@gmail.com
---
V2 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl.c | 48 -
include/configs/devkit8000.h |7 +++-
2 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index c76fea6..9c22c7a 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -35,6 +35,7 @@
#include asm/arch/mmc_host_def.h
#include i2c.h
#include image.h
+#include asm/omap_gpio.h
DECLARE_GLOBAL_DATA_PTR;
@@ -63,6 +64,25 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, gdata, CONFIG_SPL_TEXT_BASE);
}
+#ifdef CONFIG_SPL_OS_BOOT
+/* Return the value of the U-boot key
+ *
+ * RETURN
+ * 0 if not pressed
+ * positiv if pressed
+ */
+int spl_uboot_key(void)
+{
+ int val = 0;
+ if (!omap_request_gpio(CONFIG_SPL_OS_BOOT_KEY)) {
+ omap_set_gpio_direction(CONFIG_SPL_OS_BOOT_KEY, 1);
+ val = omap_get_gpio_datain(CONFIG_SPL_OS_BOOT_KEY);
+ omap_free_gpio(CONFIG_SPL_OS_BOOT_KEY);
+ }
+ return !val;
+}
+#endif /* CONFIG_SPL_OS_BOOT */
+
void spl_parse_image_header(const struct image_header *header)
{
u32 header_size = sizeof(struct image_header);
@@ -90,7 +110,25 @@ void spl_parse_image_header(const struct image_header
*header)
}
}
-static void jump_to_image_no_args(void)
+#ifdef CONFIG_SPL_OS_BOOT
+/* This function jumps to an image with argument. Normally an FDT or ATAGS
+ * image.
+ * arg: Pointer to paramter image in RAM
+ */
+void jump_to_image_linux(void *arg)
+{
+ debug(Entering kernel arg pointer: 0x%X\n, arg);
+ typedef void (*image_entry_arg_t)(int, int, void *)
+ __attribute__ ((noreturn));
+ image_entry_arg_t image_entry =
+ (image_entry_arg_t) spl_image.entry_point;
+ /* cleanup_before_linux(); */ /*write SPL function for that*/
+ image_entry(0, CONFIG_SYS_SPL_MACHID, arg);
+}
+void jump_to_image_linux(void *) __attribute__ ((noreturn));
+#endif
+
+void jump_to_image_no_args(void)
{
typedef void (*image_entry_noargs_t)(void)__attribute__ ((noreturn));
image_entry_noargs_t image_entry =
@@ -99,8 +137,8 @@ static void jump_to_image_no_args(void)
debug(image entry point: 0x%X\n, spl_image.entry_point);
image_entry();
}
-
void jump_to_image_no_args(void) __attribute__ ((noreturn));
+
void board_init_r(gd_t *id, ulong dummy)
{
u32 boot_device;
@@ -134,6 +172,12 @@ void board_init_r(gd_t *id, ulong dummy)
debug(Jumping to U-Boot\n);
jump_to_image_no_args();
break;
+#ifdef CONFIG_SPL_OS_BOOT
+ case IH_OS_LINUX:
+ debug(Jumping to Linux\n);
+ jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
+ break;
+#endif
default:
puts(Unsupported OS image.. Jumping nevertheless..\n);
jump_to_image_no_args();
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 4d0573c..3897ab4 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -38,7 +38,7 @@
#define CONFIG_OMAP34301 /* which is in a 3430 */
#define CONFIG_OMAP3_DEVKIT80001 /* working with DevKit8000 */
-#defineCONFIG_SYS_TEXT_BASE0x80008000
+#defineCONFIG_SYS_TEXT_BASE0x8010
#define CONFIG_SDRC/* The chip has SDRC controller */
@@ -328,7 +328,7 @@
#define CONFIG_SPL_MAX_SIZE0xB400 /* 45 K */
#define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
-#define CONFIG_SPL_BSS_START_ADDR 0x8000 /*CONFIG_SYS_SDRAM_BASE*/
+#define CONFIG_SPL_BSS_START_ADDR 0x8500 /* leave space for bootargs*/
#define CONFIG_SPL_BSS_MAX_SIZE0x8
/* NAND boot config */
@@ -358,6 +358,9 @@
#define CONFIG_CMD_SAVEBP_WRITE_SIZE 0x400 /* 1024 byte */
#define CONFIG_CMD_SAVEBP_NAND_OFS (CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x40)
+#define CONFIG_SPL_OS_BOOT
+#define CONFIG_SPL_OS_BOOT_KEY 26
+#define CONFIG_SYS_SPL_MACHID MACH_TYPE_DEVKIT8000
#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS0x28
#define CONFIG_SYS_SPL_ARGS_ADDR (PHYS_SDRAM_1 + 0x100)
#endif /* __CONFIG_H */
--
1.7.4.1
[U-Boot] [PATCH V2 5/8] devkit8000/spl: init GPMC for dm9000 in SPL
Linux crashes if the GPMC isn't configured for the dm9000.
Signed-off-by: Simon Schwarz simonschwarz...@gmail.com
---
V2 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl.c |1 +
arch/arm/include/asm/omap_common.h |2 ++
board/timll/devkit8000/devkit8000.c | 33 -
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index 9c22c7a..0c38bbb 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -175,6 +175,7 @@ void board_init_r(gd_t *id, ulong dummy)
#ifdef CONFIG_SPL_OS_BOOT
case IH_OS_LINUX:
debug(Jumping to Linux\n);
+ spl_board_prepare_for_linux();
jump_to_image_linux((void *)CONFIG_SYS_SPL_ARGS_ADDR);
break;
#endif
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 015cede..0906f49 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -77,6 +77,8 @@ u32 omap_boot_mode(void);
/* SPL common function s*/
void spl_parse_image_header(const struct image_header *header);
+int spl_uboot_key(void);
+void spl_board_prepare_for_linux(void);
/* NAND SPL functions */
void spl_nand_load_image(void);
diff --git a/board/timll/devkit8000/devkit8000.c
b/board/timll/devkit8000/devkit8000.c
index 9b53742..3dd0eeb 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -62,6 +62,18 @@ int board_init(void)
return 0;
}
+/* Configure GPMC registers for DM9000 */
+static void gpmc_dm9000_config(void)
+{
+ writel(NET_GPMC_CONFIG1, gpmc_cfg-cs[6].config1);
+ writel(NET_GPMC_CONFIG2, gpmc_cfg-cs[6].config2);
+ writel(NET_GPMC_CONFIG3, gpmc_cfg-cs[6].config3);
+ writel(NET_GPMC_CONFIG4, gpmc_cfg-cs[6].config4);
+ writel(NET_GPMC_CONFIG5, gpmc_cfg-cs[6].config5);
+ writel(NET_GPMC_CONFIG6, gpmc_cfg-cs[6].config6);
+ writel(NET_GPMC_CONFIG7, gpmc_cfg-cs[6].config7);
+}
+
/*
* Routine: misc_init_r
* Description: Configure board specific parts
@@ -80,14 +92,7 @@ int misc_init_r(void)
#endif
#ifdef CONFIG_DRIVER_DM9000
- /* Configure GPMC registers for DM9000 */
- writel(NET_GPMC_CONFIG1, gpmc_cfg-cs[6].config1);
- writel(NET_GPMC_CONFIG2, gpmc_cfg-cs[6].config2);
- writel(NET_GPMC_CONFIG3, gpmc_cfg-cs[6].config3);
- writel(NET_GPMC_CONFIG4, gpmc_cfg-cs[6].config4);
- writel(NET_GPMC_CONFIG5, gpmc_cfg-cs[6].config5);
- writel(NET_GPMC_CONFIG6, gpmc_cfg-cs[6].config6);
- writel(NET_GPMC_CONFIG7, gpmc_cfg-cs[6].config7);
+ gpmc_dm9000_config();
/* Use OMAP DIE_ID as MAC address */
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
@@ -119,7 +124,7 @@ void set_muxconf_regs(void)
MUX_DEVKIT8000();
}
-#if defined(CONFIG_DRIVER_DM9000) !defined(CONFIG_SPL_BUILD)
+#ifdef CONFIG_DRIVER_DM9000
/*
* Routine: board_eth_init
* Description: Setting up the Ethernet hardware.
@@ -129,3 +134,13 @@ int board_eth_init(bd_t *bis)
return dm9000_initialize(bis);
}
#endif
+
+#ifdef CONFIG_SPL_OS_BOOT
+/* do board specific preperation before SPL
+ * Linux boot */
+void spl_board_prepare_for_linux(void)
+{
+ gpmc_dm9000_config();
+}
+
+#endif
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 6/8] omap-common: Add NAND SPL linux booting
This implements booting of Linux from NAND in SPL
Signed-off-by: Simon Schwarz simonschwarz...@gmail.com
---
V2 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl_nand.c | 48 +++-
1 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index af02a59..06254b2 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -46,26 +46,42 @@ 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()) {
+ /* load parameter image */
+ nand_spl_load_image(CONFIG_CMD_SAVEBP_NAND_OFS ,
+ CONFIG_CMD_SAVEBP_WRITE_SIZE,
+ (void *)CONFIG_SYS_SPL_ARGS_ADDR);
+ /* load linux */
+ nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+ spl_image.size, (void *)spl_image.load_addr);
+ } else
+#endif
+ {
#ifdef CONFIG_NAND_ENV_DST
- nand_spl_load_image(CONFIG_ENV_OFFSET,
- CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
- spl_parse_image_header(header);
- nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
- (void *)image_load_addr);
+ nand_spl_load_image(CONFIG_ENV_OFFSET,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_ENV_OFFSET, spl_image.size,
+ (void *)spl_image.load_addr);
#ifdef CONFIG_ENV_OFFSET_REDUND
- nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
- CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
- spl_parse_image_header(header);
- nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
- (void *)image_load_addr);
+ nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_ENV_OFFSET_REDUND, spl_image.size,
+ (void *)spl_image.load_addr);
#endif
#endif
- /* Load u-boot */
- nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
- CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
- spl_parse_image_header(header);
- nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
- spl_image.size, (void *)spl_image.load_addr);
+ /* Load u-boot */
+ nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
+ spl_image.size, (void *)spl_image.load_addr);
+ }
nand_deselect();
}
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 7/8] omap-common: fixes BSS overwriting problem
spl_nand overwrote BSS section because it reads a whole block everytime. Now
loads the block to spare area and just copy the needed junk to destination.
Whole block read is necessary for ecc check!
Signed-off-by: Simon Schwarz simonschwarz...@gmail.com
---
V2 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl_nand.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 06254b2..408892f 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 timestamp_autogenerated.h
#include version_autogenerated.h
@@ -33,6 +34,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);
@@ -49,16 +51,29 @@ void spl_nand_load_image(void)
#ifdef CONFIG_SPL_OS_BOOT
if (!spl_uboot_key()) {
/* load parameter image */
- nand_spl_load_image(CONFIG_CMD_SAVEBP_NAND_OFS ,
+ /* 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_SAVEBP_NAND_OFS,
CONFIG_CMD_SAVEBP_WRITE_SIZE,
- (void *)CONFIG_SYS_SPL_ARGS_ADDR);
+ (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_SAVEBP_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);
nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
- spl_image.size, (void *)spl_image.load_addr);
+ spl_image.size,
+ (void *)spl_image.load_addr - sizeof(header));
} else
#endif
{
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 8/8] savebp: added Readme
Adds a Readme for the savebp command Signed-off-by: Simon Schwarz simonschwarz...@gmail.com --- V2 changes: ADDED in V2 --- doc/README.commands.savebp | 28 1 files changed, 28 insertions(+), 0 deletions(-) create mode 100644 doc/README.commands.savebp diff --git a/doc/README.commands.savebp b/doc/README.commands.savebp new file mode 100644 index 000..dc05ee0 --- /dev/null +++ b/doc/README.commands.savebp @@ -0,0 +1,28 @@ +The savebp (=save boot parameters) is used to save a boot parameter image to +non-volatile memory. + +To execute the command everything has to be in place as if bootm should be +used. +(kernel image, initrd-image, fdt-image etc.) + +Call is: +savebp [ftd|atags] [nand_offset] [kernel_addr] [initrd_addr] [fdt_addr] + +Only the first parameter [ftd|atags] is mandatory if the others are left blank +standard values are used. + +e.g: +savebp fdt 0x68 0x8200 0x8100 - +savebo atags + +typical call on OMAP3: +nandecc hw +nand read 0x8200 0x28 0x40 /* Read kernel image from NAND */ +tftpboot 0x8100 devkit8000.dtb /* Read fdt */ +savebp fdt 0x68 0x8200 0x8100 - /* Save the image */ + +Behind the scene--- +Atm the implementation is that we have /common/cmd_savebp.c which implements +the command tself and the subcommand calls to bootm. +Then the arch specific implementation of do_save_atags or do_savebp_fdt +in /arch/arm/lib is called. -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx3fb: move to CONFIG_VIDEO to support videomodes
On 08/22/2011 07:13 PM, Stefano Babic wrote:
I see you updated the code synchronizing it with the linux driver. Add
to the commit message the kernel version (better: the commit id) of the
kernel you used as base for your changes, so that everybody in future
can know where it comes from.
Ok.
+static struct ctfb_res_modes *mode;
+static struct ctfb_res_modes var_mode;
+
+
One newline should be enough.
Sure.
- * @pixel_fmt: pixel format of buffer as FOURCC ASCII code.
pixel_fmt is still in the parameter list, and di_panel should be added
to the description.
I'll update it.
+reg = width + mode-left_margin + mode-right_margin - 1;
+if (reg 1023) {
+debug(display width too large, coerced to 1023!);
+reg = 1023;
I do not if it is better to try to adapt the values if the caller pass
to the function wrong parameters. Probably it does not work. I think in
these case it is better to output an error (print instead of debug) and
return without with an error. What do you think ?
I put that code in as I tried to adjust the porches (left and right
margin) for our display.
If it is coerced the way I did, you'll never overwrite other bits in the
same register field, so
you can still see the effect it has. I preferred it during display
configuration, so I left it in.
We could output an error (not only during debug builds) but write the
registers anyway.
-switch (PANEL_TYPE) {
+switch (di_panel) {
case IPU_PANEL_SHARP_TFT:
reg_write(0x00FD0102L, SDC_SHARP_CONF_1);
reg_write(0x00F500F4L, SDC_SHARP_CONF_2);
reg_write(SDC_COM_SHARP | SDC_COM_TFT_COLOR, SDC_COM_CONF);
+/* TODO: probably IF_CONF must be adapted (see below)! */
I do not understand this comment.
Each display specific define found an equivalent in the ctfb_res_modes
struct.
IF_CONF however is currently always 0, but might need adaption for SHARP
TFT panels, which
I could not test.
/* Init clocking */
-/*
- * Calculate divider: fractional part is 4 bits so simply multiple by
- * 2^4 to get fractional part, as long as we stay under ~250MHz and on
- * i.MX31 it (HSP_CLK) is= 178MHz. Currently 128.267MHz
+/* Calculate divider: the IPU receives its clock from the hsp divder */
+/* fractional part is 4 bits so simply multiple by 2^4 to get it
Multiline comments, you should use the same style as in the removed lines.
Ok.
+div = ((mxc_get_clock(MXC_IPU_CLK)/1024)*(mode-pixclock/128))/476837;
I try to understand this line. pixclock is in ps, as in kernel. I am
missing something. I am expecting to have the same formula as in kernel,
where I can read:
div = clk_get_rate(ipu_clk) * 16 / pixel_clk;
Where does 476837 come from ?
Well I already thought that might need another line of comment. In the
kernel the pixel_clk really
is a clock value, while it is a time (in pico seconds) in this driver. I
could have calculated the
pixel clock from the pixel time value first:
pixel_clk = 1e12 / mode-pixclock;
div = ipu_clk * 16 / pixel_clk;
I simply put that into one calculation:
div = ipu_clk * 16 / (1e12 / mode-pixclock)
or
div = ipu_clk * mode-pixclock / ~60e6;
but this would provoke an overflow problem during the multiplication, so
I split the division to
1024, 128 and 476837 which exactly gives 1e12 / 16 (~60e6). So I have 2
shifts a multiplication and a division.
Probably I simply put the 2 code lines above into a comment. The name
'pixel_clk' is actually misleading, but it sat there already. We could
use 'pixel_ps' in ctfb_res_modes instead?
+/*
+ * The current implementation is only tested for GDF_16BIT_565RGB!
+ * It was switched from the original CONFIG_LCD setup to CONFIG_VIDEO,
+ * because the lcd code seemed loaded with color table stuff, that
+ * does not relate to most modern TFTs. cfb_console.c looks more
+ * straight forward.
+ * This is the environment setting for the original setup
+ unknown=video=ctfb:x:240,y:320,depth:16,mode:0,pclk:185925,le:9,ri:17,
+up:7,lo:10,hs:1,vs:1,sync:100663296,vmode:0
+ videomode=unknown
Multiline comment. As original setup you mean the setup if not
CONFIG_DISPLAY_* was set, right ?
I'll fix the comment and yes you're right.
+void *video_hw_init(void)
{
-return ((panel_info.vl_col * panel_info.vl_row *
-NBITS(panel_info.vl_bpix)) / 8) + PAGE_SIZE;
+char *penv;
+u32 memsize;
+unsigned long t1, hsynch, vsynch;
+int bits_per_pixel, i, tmp, vesa_idx = 0, videomode;
+
+tmp = 0;
+
+videomode = CONFIG_SYS_DEFAULT_VIDEO_MODE;
Ok. This is a way to fix qong/phycore after merging these patches, and
avoid that they do not work anymore if the videomode variable is not
set. I write it down...
Perfect. I could have done that already, but lacking hardware to test
with ...
Anatolij, should be this code not general ? It is not strictly related
to the
Re: [U-Boot] [PATCH 2/2] mx3fb: move to CONFIG_VIDEO to support videomodes
Please ignore the 2 messages sent at 8:30, obviously the save and send buttons changed position. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] top of tree build fails for beagleboard
Hi guys, I cloned top of tree and tried to build beagleboard. Fails right at the end with: make[1]: Entering directory `/home/beaglexm/clean_code_for_bootstuff/u-boot/board/ti/beagle' beagle.c:41:27: error: asm/arch/gpio.h: No such file or directory led.c:25:27: error: asm/arch/gpio.h: No such file or directory make[1]: *** No rule to make target `.depend', needed by `libbeagle.o'. Stop. make[1]: Leaving directory `/home/beaglexm/clean_code_for_bootstuff/u-boot/board/ti/beagle' make: *** [board/ti/beagle/libbeagle.o] Error 2 It used to work fine so I think something broke recently. I also see that someone has posted a patch for this, http://lists.denx.de/pipermail/u-boot/2011-August/098594.html Is that the right fix? Thanks, jaya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] top of tree build fails for beagleboard
Hi Jaya Kumar, On Wednesday 24 August 2011 05:39 PM, Jaya Kumar wrote: Hi guys, I cloned top of tree and tried to build beagleboard. Fails right at the end with: make[1]: Entering directory `/home/beaglexm/clean_code_for_bootstuff/u-boot/board/ti/beagle' beagle.c:41:27: error: asm/arch/gpio.h: No such file or directory led.c:25:27: error: asm/arch/gpio.h: No such file or directory make[1]: *** No rule to make target `.depend', needed by `libbeagle.o'. Stop. make[1]: Leaving directory `/home/beaglexm/clean_code_for_bootstuff/u-boot/board/ti/beagle' make: *** [board/ti/beagle/libbeagle.o] Error 2 It used to work fine so I think something broke recently. I also see that someone has posted a patch for this, http://lists.denx.de/pipermail/u-boot/2011-August/098594.html Is that the right fix? There is already a fix in u-boot-arm for this. http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=9ec6b678e7c17684cbe5cc0e521cad9ce7a2c281 best regards, Aneesh Thanks, jaya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] OMAP3: CM-T35: Use generic MMC driver
On 08/23/11 01:13, Tom Rini wrote:
Switch from the legacy omap3 mmc driver to the new generic omap hsmmc
driver. This patch is based on the work done for Beagle, etc.
Signed-off-by: Tom Rini tr...@ti.com
It is a good practice to CC the board maintainer. Thanks.
Tested-by: Igor Grinberg grinb...@compulab.co.il
---
board/cm_t35/cm_t35.c|8
include/configs/cm_t35.h |3 ++-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/board/cm_t35/cm_t35.c b/board/cm_t35/cm_t35.c
index f82111b..420cd70 100644
--- a/board/cm_t35/cm_t35.c
+++ b/board/cm_t35/cm_t35.c
@@ -313,6 +313,14 @@ void set_muxconf_regs(void)
cm_t3730_set_muxconf();
}
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ omap_mmc_init(0);
+ return 0;
+}
+#endif
+
/*
* Routine: setup_net_chip_gmpc
* Description: Setting up the configuration GPMC registers specific to the
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 16a5f5b..496a904 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -108,8 +108,9 @@
#define CONFIG_BAUDRATE 115200
#define CONFIG_SYS_BAUDRATE_TABLE{4800, 9600, 19200, 38400, 57600,\
115200}
+#define CONFIG_GENERIC_MMC 1
#define CONFIG_MMC 1
-#define CONFIG_OMAP3_MMC 1
+#define CONFIG_OMAP_HSMMC1
#define CONFIG_DOS_PARTITION 1
/* DDR - I use Micron DDR */
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx31: make HSP clock for mx3fb driver available
On Wednesday, August 24, 2011 08:55:03 AM Helmut Raiger wrote: On 08/22/2011 06:02 PM, Marek Vasut wrote: ... _COSMETIC_, while this new mx3fb driver really works nicely ;-) Oh my sense for metrosexuality of code really kicks in here ;-) Arousal was not my first objective, but deliberately endorsed :-P Hehe :-D I'll do what can be done easily concerning the bit accesses. Helmut Thanks! -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] New init sequence processing without init_sequence array
Dear Graeme Russ, In message CALButCK=hn8vbmu+8ezvq7uhffasrj_zjn_yz8wqt0qnxjl...@mail.gmail.com you wrote: Agreed. I should have written: I have a _readable_ source file that can be parsed without additional tools. I would hardly call 'grep' an extra tool - How many programmers do you know that have never used grep? That's not the point. There is a significant difference between seeng the source code in your favorite editor or in the source code window of your debugger's GUI or even some IDE, versus having to run additional commands in a separate window. And by defining #DEBUG I can have a parallel list of function names so when the loop picks up the next funtion pointer, it picks up the name as well ready to examine before stepping in - OK, not ideal, but still, I think the flexibility to seamlessly inject init functions at the board level outweighs this Sorry, but when reading the source code or when revioewing patches I cannot paick up any next funtion pointers, I'm stuck with reading the source code only. 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 use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- 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 v5] ARM: Add Calxeda Highbank platform
Dear Albert ARIBAUD, In message 4e54b862.2070...@aribaud.net you wrote: Well, it is more a question of which toolchain(s) we want supported in U-Boot. Denx ELDK is one of them I guess :) but now that ELDK 5.0 is out, I don't know if ELDK 4.2 support is still required. It seems reasonable to support any gcc 4.x configuration. If ELDK4.2 must be supported, then I would suggest creating a configuration option to allow the use of armv7-a ISA, then the arch/arm/cpu/armv7/highbank/config.mk file would select armv7-a ISA I don't tink I want to accept a board specific config.mk for such apurpose. We want to get rid of thse config.mk files. Either ARMv7 based boards all need this option, or they all don;t need it. Thisis NOT a board specific feature. If ELDK4.2 support is dropped (at least partially) then no change would be needed. Wolfgang:, I think that toolchain support for ARM is more your choice than mine. See above - I see no reason why we should abandon ELDK 4.2 when adding a new board - when all other boards with similar CPUs work just fine. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de They say a little knowledge is a dangerous thing, but it is not one half so bad as a lot of ignorance. - Terry Pratchett, _Equal Rites_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] New init sequence processing without init_sequence array
Hi Wolfgang, On 24/08/11 22:49, Wolfgang Denk wrote: Dear Graeme Russ, In message CALButCK=hn8vbmu+8ezvq7uhffasrj_zjn_yz8wqt0qnxjl...@mail.gmail.com you wrote: Agreed. I should have written: I have a _readable_ source file that can be parsed without additional tools. I would hardly call 'grep' an extra tool - How many programmers do you know that have never used grep? That's not the point. There is a significant difference between seeng the source code in your favorite editor or in the source code window of your debugger's GUI or even some IDE, versus having to run additional commands in a separate window. And by defining #DEBUG I can have a parallel list of function names so when the loop picks up the next funtion pointer, it picks up the name as well ready to examine before stepping in - OK, not ideal, but still, I think the flexibility to seamlessly inject init functions at the board level outweighs this Sorry, but when reading the source code or when revioewing patches I cannot paick up any next funtion pointers, I'm stuck with reading the source code only. Well, I guess I had a good shot at creating a 'better' init sequence - one where any board, SoC, or arch can seamlessly inject a custom init step without treading on any toes. I must say, it was rather fun learning how to build the macros and get the linker to do the right thing and have it all work so quickly. I'll stick it in my bag of tricks for another day :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FDT without FIT?
Dear Simon Schwarz, In message 4e54c961.70...@gmail.com you wrote: This prints: # help bootm bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image You must either have a very old version of U-Bot, or one without FDT support built in. What exactly is your problem? Thanks - john already pointed me to this. This works. It was/is just a problem with the help text - duno why.. Hm... I get this: = help bootm bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image ===When booting a Linux kernel which requires a flat device-tree ===a third argument is required which is the address of the ===device-tree blob. To boot that kernel without an initrd image, ===use a '-' for the second argument. If you do not pass a third ===a bd_info struct will be passed instead Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image ramdisk - relocate initrd, set env initrd_start/initrd_end ===fdt - relocate flat device tree cmdline - OS specific command line processing/setup bdt - OS specific bd_t processing prep- OS specific prep before relocation or go go - start OS 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 ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, The Omega Glory, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] Armada100: Enable Ethernet support for GplugD
This patch enables ethernet support for Marvell GplugD board. Network
related commands works.
Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com
---
Changes for v2:
- armada100_fec_initialize changed to armada100_fec_register
arch/arm/include/asm/arch-armada100/armada100.h | 57 +++
arch/arm/include/asm/arch-armada100/mfp.h | 19
board/Marvell/gplugd/gplugd.c | 39 +++
include/configs/gplugd.h| 19 +++-
4 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-armada100/armada100.h
b/arch/arm/include/asm/arch-armada100/armada100.h
index 3d567eb..849638d 100644
--- a/arch/arm/include/asm/arch-armada100/armada100.h
+++ b/arch/arm/include/asm/arch-armada100/armada100.h
@@ -41,6 +41,10 @@
/* Functional Clock Selection Mask */
#define APBC_FNCLKSEL(x)(((x) 0xf) 4)
+/* Fast Ethernet Controller Clock register definition */
+#define FE_CLK_RST 0x1
+#define FE_CLK_ENA 0x8
+
/* Register Base Addresses */
#define ARMD1_DRAM_BASE0xB000
#define ARMD1_TIMER_BASE 0xD4014000
@@ -85,6 +89,59 @@ struct armd1mpmu_registers {
};
/*
+ * Application Subsystem Power Management
+ * Refer Datasheet Appendix A.9
+ */
+struct armd1apmu_registers {
+ u32 pcr;/* 0x000 */
+ u32 ccr;/* 0x004 */
+ u32 pad1;
+ u32 ccsr; /* 0x00C */
+ u32 fc_timer; /* 0x010 */
+ u32 pad2;
+ u32 ideal_cfg; /* 0x018 */
+ u8 pad3[0x04C - 0x018 - 4];
+ u32 lcdcrc; /* 0x04C */
+ u32 cciccrc;/* 0x050 */
+ u32 sd1crc; /* 0x054 */
+ u32 sd2crc; /* 0x058 */
+ u32 usbcrc; /* 0x05C */
+ u32 nfccrc; /* 0x060 */
+ u32 dmacrc; /* 0x064 */
+ u32 pad4;
+ u32 buscrc; /* 0x06C */
+ u8 pad5[0x07C - 0x06C - 4];
+ u32 wake_clr; /* 0x07C */
+ u8 pad6[0x090 - 0x07C - 4];
+ u32 core_status;/* 0x090 */
+ u32 rfsc; /* 0x094 */
+ u32 imr;/* 0x098 */
+ u32 irwc; /* 0x09C */
+ u32 isr;/* 0x0A0 */
+ u8 pad7[0x0B0 - 0x0A0 - 4];
+ u32 mhst; /* 0x0B0 */
+ u32 msr;/* 0x0B4 */
+ u8 pad8[0x0C0 - 0x0B4 - 4];
+ u32 msst; /* 0x0C0 */
+ u32 pllss; /* 0x0C4 */
+ u32 smb;/* 0x0C8 */
+ u32 gccrc; /* 0x0CC */
+ u8 pad9[0x0D4 - 0x0CC - 4];
+ u32 smccrc; /* 0x0D4 */
+ u32 pad10;
+ u32 xdcrc; /* 0x0DC */
+ u32 sd3crc; /* 0x0E0 */
+ u32 sd4crc; /* 0x0E4 */
+ u8 pad11[0x0F0 - 0x0E4 - 4];
+ u32 cfcrc; /* 0x0F0 */
+ u32 mspcrc; /* 0x0F4 */
+ u32 cmucrc; /* 0x0F8 */
+ u32 fecrc; /* 0x0FC */
+ u32 pciecrc;/* 0x100 */
+ u32 epdcrc; /* 0x104 */
+};
+
+/*
* APB1 Clock Reset/Control Registers
* Refer Datasheet Appendix A.10
*/
diff --git a/arch/arm/include/asm/arch-armada100/mfp.h
b/arch/arm/include/asm/arch-armada100/mfp.h
index d6e0494..da76b58 100644
--- a/arch/arm/include/asm/arch-armada100/mfp.h
+++ b/arch/arm/include/asm/arch-armada100/mfp.h
@@ -64,6 +64,25 @@
#define MFP105_CI2C_SDA(MFP_REG(0x1a4) | MFP_AF1 |
MFP_DRIVE_MEDIUM)
#define MFP106_CI2C_SCL(MFP_REG(0x1a8) | MFP_AF1 |
MFP_DRIVE_MEDIUM)
+/* Fast Ethernet */
+#define MFP086_ETH_TXCLK (MFP_REG(0x158) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP087_ETH_TXEN(MFP_REG(0x15C) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
+#define MFP088_ETH_TXDQ3 (MFP_REG(0x160) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP089_ETH_TXDQ2 (MFP_REG(0x164) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP090_ETH_TXDQ1 (MFP_REG(0x168) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP091_ETH_TXDQ0 (MFP_REG(0x16C) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP092_ETH_CRS (MFP_REG(0x170) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP093_ETH_COL (MFP_REG(0x174) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP094_ETH_RXCLK (MFP_REG(0x178) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP095_ETH_RXER(MFP_REG(0x17C) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
+#define MFP096_ETH_RXDQ3 (MFP_REG(0x180) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP097_ETH_RXDQ2 (MFP_REG(0x184) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP098_ETH_RXDQ1 (MFP_REG(0x188) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP099_ETH_RXDQ0 (MFP_REG(0x18C) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP100_ETH_MDC (MFP_REG(0x190) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP101_ETH_MDIO
[U-Boot] [PATCH v2 3/3] Armada100: Enable 88E3015 PHY support for GplugD
This patch adds support for 88E3015 PHY for Marvell GplugD board.
This patch depends on series of patch which adds support for Marvell
GuruPlug-Display.
Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com
---
Changes for v2:
- Not changed
board/Marvell/gplugd/gplugd.c | 33 -
include/configs/gplugd.h | 14 ++
2 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/board/Marvell/gplugd/gplugd.c b/board/Marvell/gplugd/gplugd.c
index 4cd4086..bf3cdb4 100644
--- a/board/Marvell/gplugd/gplugd.c
+++ b/board/Marvell/gplugd/gplugd.c
@@ -32,6 +32,8 @@
#include mvmfp.h
#include asm/arch/mfp.h
#include asm/arch/armada100.h
+#include asm/gpio.h
+#include miiphy.h
#ifdef CONFIG_ARMADA100_FEC
#include net.h
@@ -83,6 +85,11 @@ int board_init(void)
gd-bd-bi_arch_number = MACH_TYPE_SHEEVAD;
/* adress of boot parameters */
gd-bd-bi_boot_params = armd1_sdram_base(0) + 0x100;
+ /* Assert PHY_RST# */
+ gpio_direction_output(CONFIG_SYS_GPIO_PHY_RST, GPIO_LOW);
+ udelay(10);
+ /* Deassert PHY_RST# */
+ gpio_set_value(CONFIG_SYS_GPIO_PHY_RST, GPIO_HIGH);
return 0;
}
@@ -97,5 +104,29 @@ int board_eth_init(bd_t *bis)
return armada100_fec_register();
}
-#endif /* CONFIG_ARMADA100_FEC */
+#ifdef CONFIG_RESET_PHY_R
+/* Configure and initialize PHY chip 88E3015 */
+void reset_phy(void)
+{
+ u16 phy_adr;
+ const char *name = armd-fec0;
+
+ if (miiphy_set_current_dev(name))
+ return;
+
+ /* command to read PHY dev address */
+ if (miiphy_read(name, 0xff, 0xff, (u16 *) phy_adr)) {
+ printf(Err..%s could not read PHY dev address\n, __func__);
+ return;
+ }
+ /* Set Ethernet LED in TX blink mode */
+ miiphy_write(name, phy_adr, PHY_LED_MAN_REG, 0x00);
+ miiphy_write(name, phy_adr, PHY_LED_PAR_SEL_REG, PHY_LED_VAL);
+
+ /* reset the phy */
+ miiphy_reset(name, phy_adr);
+ printf(88E3015 Initialized on %s\n, name);
+}
+#endif /* CONFIG_RESET_PHY_R */
+#endif /* CONFIG_ARMADA100_FEC */
diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h
index f3b94d8..b63ffd5 100644
--- a/include/configs/gplugd.h
+++ b/include/configs/gplugd.h
@@ -80,6 +80,20 @@
#define CONFIG_ROOTPATH/tftpboot
#define CONFIG_SYS_IMG_NAMEuImage
+/* GPIO Support */
+#define CONFIG_MARVELL_GPIO
+
+/* PHY configuration */
+#define CONFIG_MII
+#define CONFIG_CMD_MII
+#define CONFIG_RESET_PHY_R
+/* 88E3015 register definition */
+#define PHY_LED_PAR_SEL_REG22
+#define PHY_LED_MAN_REG25
+#define PHY_LED_VAL0x5b/* LINK LED1, ACT LED2 */
+/* GPIO Configuration for PHY */
+#define CONFIG_SYS_GPIO_PHY_RST104 /* GPIO104 */
+
/*
* mv-common.h should be defined after CMD configs since it used them
* to enable certain macros
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100
This patch adds support for Fast Ethernet Controller driver for
Armada100 series.
Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com
---
Changes for v2:
- removed random MAC generation
- driver init function changed to register as per new naming convention
- code cleanup (Thanks to Wolfgang, Marek Mike for tips)
arch/arm/include/asm/arch-armada100/armada100.h |1 +
drivers/net/Makefile|1 +
drivers/net/armada100_fec.c | 761 +++
drivers/net/armada100_fec.h | 232 +++
include/netdev.h|1 +
5 files changed, 996 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/armada100_fec.c
create mode 100644 drivers/net/armada100_fec.h
diff --git a/arch/arm/include/asm/arch-armada100/armada100.h
b/arch/arm/include/asm/arch-armada100/armada100.h
index d5d125a..3d567eb 100644
--- a/arch/arm/include/asm/arch-armada100/armada100.h
+++ b/arch/arm/include/asm/arch-armada100/armada100.h
@@ -59,6 +59,7 @@
#define ARMD1_MPMU_BASE0xD405
#define ARMD1_APMU_BASE0xD4282800
#define ARMD1_CPU_BASE 0xD4282C00
+#define ARMD1_FEC_BASE 0xC080
/*
* Main Power Management (MPMU) Registers
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 819b197..34b4322 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -28,6 +28,7 @@ LIB := $(obj)libnet.o
COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o
COBJS-$(CONFIG_PPC4xx_EMAC) += 4xx_enet.o
COBJS-$(CONFIG_ALTERA_TSE) += altera_tse.o
+COBJS-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
COBJS-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o
COBJS-$(CONFIG_BCM570x) += bcm570x.o
diff --git a/drivers/net/armada100_fec.c b/drivers/net/armada100_fec.c
new file mode 100644
index 000..e36dca6
--- /dev/null
+++ b/drivers/net/armada100_fec.c
@@ -0,0 +1,761 @@
+/*
+ * (C) Copyright 2011
+ * eInfochips Ltd. www.einfochips.com
+ * Written-by: Ajay Bhargav ajay.bhar...@einfochips.com
+ *
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Contributor: Mahavir Jain mj...@marvell.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include net.h
+#include malloc.h
+#include miiphy.h
+#include netdev.h
+#include asm/types.h
+#include asm/byteorder.h
+#include linux/err.h
+#include linux/mii.h
+#include asm/io.h
+#include asm/arch/armada100.h
+#include armada100_fec.h
+
+#define PHY_ADR_REQ 0xFF /* Magic number to read/write PHY address */
+
+#ifdef DEBUG
+static int eth_dump_regs(struct eth_device *dev)
+{
+ struct armdfec_device *darmdfec = to_darmdfec(dev);
+ struct armdfec_reg *regs = darmdfec-regs;
+ unsigned int i = 0;
+
+ printf(\noffset: phy_adr, value: 0x%x\n, readl(regs-phyadr));
+ printf(offset: smi, value: 0x%x\n, readl(regs-smi));
+ for (i = 0x400; i = 0x4e4; i += 4)
+ printf(offset: 0x%x, value: 0x%x\n,
+ i, readl(ARMD1_FEC_BASE + i));
+ return 0;
+}
+#endif
+
+static int armdfec_phy_timeout(u32 reg, u32 flag, int cond)
+{
+ u32 timeout = PHY_WAIT_ITERATIONS;
+ while (--timeout) {
+ if (cond (readl(reg) flag))
+ break;
+ else if (!cond !(readl(reg) flag))
+ break;
+ udelay(PHY_WAIT_MICRO_SECONDS);
+ }
+ return !timeout;
+}
+
+static int smi_reg_read(const char *devname, u8 phy_addr, u8 phy_reg,
+ u16 *value)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ struct armdfec_device *darmdfec = to_darmdfec(dev);
+ struct armdfec_reg *regs = darmdfec-regs;
+ u32 val, reg_data;
+
+ if (phy_addr == PHY_ADR_REQ phy_reg == PHY_ADR_REQ) {
+ reg_data = readl(regs-phyadr);
+ *value = (u16) (reg_data 0x1f);
+ return 0;
+ }
+
+ /* check parameters */
+ if (phy_addr PHY_MASK) {
+ printf(Err..(%s) Invalid phy address: 0x%X\n,
+ __func__, phy_addr);
+
Re: [U-Boot] [RFC] New init sequence processing without init_sequence array
Dear Graeme Russ, In message 4e54f501.6050...@gmail.com you wrote: Sorry, but when reading the source code or when revioewing patches I cannot paick up any next funtion pointers, I'm stuck with reading the source code only. Well, I guess I had a good shot at creating a 'better' init sequence - one where any board, SoC, or arch can seamlessly inject a custom init step without treading on any toes. I must say, it was rather fun learning how to build the macros and get the linker to do the right thing and have it all work so quickly. I'll stick it in my bag of tricks for another day :) Hey, you give up early. Are you suffering from hot weather, too? :-) Seriously, I do not think we should stop this discussion yet. I agree that a better approach to the init code would be a good thing, but at the same time I want to make sure the result will be really better, and we not by means of Beelzebub expel the demons... I already tried to lend a helping hand by suggesting to create a list of init functions as part of the build process - OK, we still have to build the code to get this, but at last we can then see the complete and precise order for this specific configuration. Also, Detlev made some interesting remarks - he noted that basicly what we are trying to solve is a dependency issue: each init function has a list of dependencies (other init steps) that need to be run before. Instead of manually assigning initcall numbers, we could try and write down these dependencies, for example in a format that can be digested by a tool like tsort. We could then use this to auto-generate the list of init calls. This is a completely new approach, but it has the charme of making the dependencies clear. 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 Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
Dear Lukasz Majewski, In message 20110824120744.097ba2c5@lmajewski.digital.local you wrote: After reading dcache related threads I'd like to sum them up: 1. alloca() - not acceptable to u-boot mainline by Wolfgang. I agree that alloca is NOT the way to go. 2. malloc/memalign - avoidable to use 3. Mike's DMA_DECLARE_BUFFER(buffer type, variable name, size in bytes) solution looks OK for me, at least for the stack allocated data (e.g. ext_csd). However this proposed implementation has been NAK'ed by Wolfgang. I'm curious how this macro should look like? Is it only matter of code reordering or other approach shall be found? I think I'd like to see a macro that can be used like this: void *dma_buffer_pointer = DMA_BUFFER(size_in_bytes); 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. Actually I fail to understand why we would ever need get_dcache_line_size() in a boot loader. 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 know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] New init sequence processing without init_sequence array
Hi Wolfgang, [...] I bet that rather sooner than later you will end up with some toold that parses either the ELF file or the linker map or the symbol table to generate a readable list for the current build. I bet a case of beer that you will need such a tool. We don't need it now. objdump -t --section=... will probably do the trick. Cheers Detlev -- I'm not one of those who think Bill Gates is the devil. I simply suspect that if Microsoft ever met up with the devil, it wouldn't need an interpreter. --NICHOLAS PETRELEY, Sr. Editor, InfoWorld -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: Add Calxeda Highbank platform
From: Rob Herring rob.herr...@calxeda.com Add basic support for Calxeda Highbank platform. Only minimal support with serial and SATA are included. Signed-off-by: Jason Hobbs jason.ho...@calxeda.com Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- changes in v6: - Remove arch/arm/cpu/armv7/highbank/config.mk - Fix some whitespace errors (blank lines at EOF) changes in v5: - Rebase to current u-boot-arm/master (5557e86bb0793012057d5462976c2a902bc629ac) changes in v4: - Rebase to current mainline (d50a8f45c9a640b3bcbd0ede91f83c8646cca018) - Add back SATA support to inital patch as dependencies are all in mainline changes in v3: - Add hignbank to MAINTAINERS changes in v2: - Set DRAM size to correct value - split SATA and SD enabling to separate patches MAINTAINERS |4 + arch/arm/cpu/armv7/highbank/Makefile | 46 + arch/arm/cpu/armv7/highbank/timer.c | 123 ++ board/highbank/Makefile | 49 + board/highbank/highbank.c| 57 boards.cfg |1 + include/configs/highbank.h | 113 +++ 7 files changed, 393 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/armv7/highbank/Makefile create mode 100644 arch/arm/cpu/armv7/highbank/timer.c create mode 100644 board/highbank/Makefile create mode 100644 board/highbank/highbank.c create mode 100644 include/configs/highbank.h diff --git a/MAINTAINERS b/MAINTAINERS index f895e9a..c383f6d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -219,6 +219,10 @@ Wolfgang Grandegger w...@denx.de IPHASE4539 MPC8260 SCM MPC8260 +Rob Herring rob.herr...@calxeda.com + + highbankhighbank + Klaus Heydeck heyd...@kieback-peter.de KUP4K MPC855 diff --git a/arch/arm/cpu/armv7/highbank/Makefile b/arch/arm/cpu/armv7/highbank/Makefile new file mode 100644 index 000..76faeb0 --- /dev/null +++ b/arch/arm/cpu/armv7/highbank/Makefile @@ -0,0 +1,46 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# 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 +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(SOC).o + +COBJS := timer.o +SOBJS := + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) + +all: $(obj).depend $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv7/highbank/timer.c b/arch/arm/cpu/armv7/highbank/timer.c new file mode 100644 index 000..d8a0288 --- /dev/null +++ b/arch/arm/cpu/armv7/highbank/timer.c @@ -0,0 +1,123 @@ +/* + * Copyright 2010-2011 Calxeda, Inc. + * + * Based on arm926ejs/mx27/timer.c + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the 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 div64.h +#include linux/types.h/* for size_t */ +#include linux/stddef.h /* for NULL */ +#include asm/io.h +#include asm/arch-armv7/systimer.h + +#undef SYSTIMER_BASE +#define SYSTIMER_BASE 0xFFF34000 /* Timer 0 and 1 base */ +#define SYSTIMER_RATE 15000 + +static ulong timestamp; +static ulong lastinc; +static struct systimer *systimer_base = (struct systimer *)SYSTIMER_BASE; + +/* + * Start the timer + */ +int
Re: [U-Boot] [RFC] New init sequence processing without init_sequence array
Hi Wolfgang, On 24/08/11 23:24, Wolfgang Denk wrote: Dear Graeme Russ, In message 4e54f501.6050...@gmail.com you wrote: Sorry, but when reading the source code or when revioewing patches I cannot paick up any next funtion pointers, I'm stuck with reading the source code only. Well, I guess I had a good shot at creating a 'better' init sequence - one where any board, SoC, or arch can seamlessly inject a custom init step without treading on any toes. I must say, it was rather fun learning how to build the macros and get the linker to do the right thing and have it all work so quickly. I'll stick it in my bag of tricks for another day :) Hey, you give up early. Are you suffering from hot weather, too? :-) No, just young kids, new job and pregnant wife :) Seriously, I do not think we should stop this discussion yet. I agree that a better approach to the init code would be a good thing, but at the same time I want to make sure the result will be really better, and we not by means of Beelzebub expel the demons... I already tried to lend a helping hand by suggesting to create a list of init functions as part of the build process - OK, we still have to build the code to get this, but at last we can then see the complete and precise order for this specific configuration. Something like how we auto generate asm-offsets.h? Also, Detlev made some interesting remarks - he noted that basicly what we are trying to solve is a dependency issue: each init function has a list of dependencies (other init steps) that need to be run before. Instead of manually assigning initcall numbers, we could try and write down these dependencies, for example in a format that can be digested by a tool like tsort. We could then use this to auto-generate the list of init calls. This is a completely new approach, but it has the charme of making the dependencies clear. Hmmm, now we're talking ;) Let me ramble aimlessly for a second... I can see this heading towards an auto-generated init-sequence.c file with an init array specifically crafted for the build target. That would have less linker functionality dependencies than initcall... So if we define a file, say 'init.txt' which lists the init dependencies and we drill-down and pre-process this to generate /common/init-sequence.c which has the array of function pointers (and optionally the function name strings for debug output...) Hmmm, it _sounds_ messy on the surface, but it is a pre-compile step so what you get code-wise for the final build is exactly what you want - A clean array that is 'right there' So we might have in init.txt for a board: INIT_STEP_TIMER(board_foo_timer_init) DEPENDS_ON(INIT_STEP_ARM_TIMER) and in arch/arm/Soc/init.txt INIT_STEP_ARM_TIMER(arm_timer_init) DEPENDS(INIT_STEP_SDRAM) DEPENDS(INIT_STEP_GPIO) Can't say I like it much...could be xml, but still very clunky Maybe there is something to be gleaned... Dunno - thoughts? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] OMAP3: DIG297: Use generic MMC driver
Tom Rini wrote:
Switch from the legacy omap3 mmc driver to the new generic omap hsmmc
driver. This patch is based on the work done for Beagle, etc.
Signed-off-by: Tom Rinitr...@ti.com
Again, please Cc: the board maintainers in the future, thanks.
---
board/comelit/dig297/dig297.c |9 +
include/configs/dig297.h |5 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/board/comelit/dig297/dig297.c b/board/comelit/dig297/dig297.c
index 0062f12..a7071cd 100644
--- a/board/comelit/dig297/dig297.c
+++ b/board/comelit/dig297/dig297.c
@@ -37,6 +37,7 @@
#includenetdev.h
#includetwl4030.h
#includeasm/io.h
+#includeasm/arch/mmc_host_def.h
#includeasm/arch/omap3-regs.h
#includeasm/arch/mux.h
#includeasm/arch/mem.h
@@ -145,6 +146,14 @@ void set_muxconf_regs(void)
MUX_DIG297();
}
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ omap_mmc_init(0);
+ return 0;
+}
+#endif
+
#ifdef CONFIG_CMD_NET
/*
* Routine: setup_net_chip
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index b68f073..0e05df3 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -97,8 +97,9 @@
#define CONFIG_BAUDRATE 115200
#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
115200}
-#define CONFIG_MMC
-#define CONFIG_OMAP3_MMC
+#define CONFIG_GENERIC_MMC 1
+#define CONFIG_MMC 1
+#define CONFIG_OMAP_HSMMC1
IIRC the coding style says you should define the y/n constants without
a value, e.g.:
#define CONFIG_GENERIC_MMC
not:
#define CONFIG_GENERIC_MMC 1
Apart for this:
Tested-by: Luca Ceresoli luca.ceres...@comelit.it
Luca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] fastboot gadget support
On 08/13/2011 12:22 PM, Remy Bohmer wrote: Hi Sebastian, Hi Remy, 2011/8/10 Sebastian Andrzej Siewiorbige...@linutronix.de: This is the faastboot gadget code based on git://git.omapzoom.org/repo/u-boot.git as of commit 601ff71c8 including a few changes. Some of them are: - generic mmc framework - new gadget framework - different / easier command parsing - booti command is missing It was tested before it has been re-written. It is possible that it is broken. It is posted for reference only not for merging. Signed-off-by: Sebastian Andrzej Siewiorbige...@linutronix.de I am going to look at it in detail in a couple of days. I will come back to this soon. any news so far? :) Kind regards, Remy Sebastian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] ARM: board removal
Hi all, Quick status on the 52-part ARM board removal patch. After applying various patches and pulling some repositories, the following boards are still scheduled for removal: [U-Boot,37/52] ARM: remove broken voiceblue board 2011-07-17 Wolfgang Denk aaribaudNew [U-Boot,36/52] ARM: remove broken versatile boards. 2011-07-17 Wolfgang Denk aaribaudNew [U-Boot,34/52] ARM: remove broken smdk2400 board 2011-07-17 Wolfgang DenkaaribaudNew [U-Boot,32/52] ARM: remove broken sbc2410x board 2011-07-17 Wolfgang DenkaaribaudNew [U-Boot,31/52] ARM: remove broken netstar board 2011-07-17 Wolfgang DenkaaribaudNew [U-Boot,30/52] ARM: remove broken mx1fs2 board2011-07-17 Wolfgang DenkaaribaudNew [U-Boot,29/52] ARM: remove broken lpd7a40x boards 2011-07-17 Wolfgang Denk aaribaudNew [U-Boot,28/52] ARM: remove broken edb93xx boards 2011-07-17 Wolfgang DenkaaribaudNew [U-Boot,10/52] ARM: remove broken B2 board2011-07-17 Wolfgang DenkaaribaudNew [U-Boot,09/52] ARM: remove broken armadillo board 2011-07-17 Wolfgang Denk aaribaudNew [U-Boot,01/52] ARM: remove broken assabet board 2011-07-17 Wolfgang DenkaaribaudNew For which I am delegate. These board, for which no bugfix patch was provided, will be removed from u-boot-arm/master. Also, the following boards, for which Reinhard is a delegate, are still undecided: [U-Boot,46/52] ARM: remove broken at91rm9200dk board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,45/52] ARM: remove broken m501sk board2011-07-17 Wolfgang Denkreinhardm New [U-Boot,44/52] ARM: remove broken kb9202 board2011-07-17 Wolfgang Denkreinhardm New [U-Boot,43/52] ARM: remove broken csb637 board2011-07-17 Wolfgang Denkreinhardm New [U-Boot,42/52] ARM: remove broken cmc_pu2 board 2011-07-17 Wolfgang Denkreinhardm New [U-Boot,40/52] ARM: remove broken at91cap9adk board 2011-07-17 Wolfgang Denk reinhardm New Reinhard, can you either let me know if these should be removed or kept (or if you're going to process them through your repo and send out a pull req)? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Cleanup how SVR_MAJ() is defined on MPC8536
The MPC8536 seems to use only 3 bits for the major revision field in the
SVR rather than the 4 bits used by all other processors. The most
significant bit is used as a mfg code on MPC8536.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/cpu/mpc85xx/cpu.c |3 ---
arch/powerpc/include/asm/processor.h |4
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 52a34f7..2417a6a 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -69,9 +69,6 @@ int checkcpu (void)
svr = get_svr();
major = SVR_MAJ(svr);
-#ifdef CONFIG_MPC8536
- major = 0x7; /* the msb of this nibble is a mfg code */
-#endif
minor = SVR_MIN(svr);
if (cpu_numcores() 1) {
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index f5bf4dd..cf06dfa 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -987,7 +987,11 @@
#define SVR_FAM(svr) (((svr) 20) 0xFFF) /* Family field */
#define SVR_MEM(svr) (((svr) 16) 0xF) /* Member field */
+#ifdef CONFIG_MPC8536
+#define SVR_MAJ(svr) (((svr) 4) 0x7) /* Major revision field*/
+#else
#define SVR_MAJ(svr) (((svr) 4) 0xF) /* Major revision field*/
+#endif
#define SVR_MIN(svr) (((svr) 0) 0xF) /* Minor revision field*/
/* Some parts define SVR[0:23] as the SOC version */
--
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 V4 3/4] ARM: Warn when the machine ID isn't set.
Le 04/08/2011 08:30, Albert ARIBAUD a écrit :
Hi Christopher,
Le 18/07/2011 19:33, Christopher Harvey a écrit :
Linux cannot boot without it.
Signed-off-by: Christopher Harveychar...@matrox.com
---
V2:
Used a #define instead of a constant.
Used a printf instead of a debug.
---
V3:
Moved gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID; before the
init_sequence loop, so it doesn't overwrite existing values.
Removed unneeded braces.
Reminder, in V2 of this series there are 3 uncommited patches that
have no comments.
---
V3:
Fixed mixed tabs and spaces.
Message prints in both debug and release mode.
arch/arm/include/asm/u-boot.h |2 ++
arch/arm/lib/board.c |2 ++
arch/arm/lib/bootm.c |3 +++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index ed33327..81735de 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -48,4 +48,6 @@ typedef struct bd_info {
} bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#define BI_ARCH_NUMBER_INVALID 0x
+
#endif/* _U_BOOT_H_ */
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index fc52a26..1635aa1 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -281,6 +281,8 @@ void board_init_f (ulong bootflag)
gd-mon_len = _bss_end_ofs;
+gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID;
+
for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..d5fd26b 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,9 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+if (machid == BI_ARCH_NUMBER_INVALID)
+printf(Warning: machid not set.\n);
+
show_boot_progress (15);
#ifdef CONFIG_OF_LIBFDT
This patch does not apply cleanly any more. Can you post a rebased V5
please?
Ping?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
Hi Wolfgang,
I think I'd like to see a macro that can be used like this:
void *dma_buffer_pointer = DMA_BUFFER(size_in_bytes);
Frankly speaking I don't know any easy way to define buffer this way
in a macro (at least without digging deep enough to C preprocessor
programming tricks). Maybe Mike or Anton knows.
The void *dma_buffer_pointer = DMA_BUFFER(size_in_bytes); approach
needs to do following things in macro:
#define DMA_BUFFER(100) \
char buf[100 + get_dcache_line_size]; \
unsigned long tmp = (unsigned long) buf; \
void* buf_out = (void*) ((tmp + (get_dcache_line_size() - 1))
~(get_dcache_line_size() - 1))
The problem here is to assign the buf_out pointer to the void
*dma_buffer_pointer. How can we return the void *buf_out?
For comparison please look to this solution:
#define ALIGN_ADDR(addr) ((void *)(((unsigned long) addr +
get_dcache_line_size() - 1)\ ~(get_dcache_line_size() - 1)))
#define DMA_DECLARE_BUFFER(type, name, size) \
char *__##name[size + get_dcache_line_size()]; \
type *name = ALIGN_ADDR(__##name);
int mmc_startup(struct mmc *mmc)
{
/* Some declarations */
/* char ext_csd[512]; */
DMA_DECLARE_BUFFER(char, ext_csd, 512);
printf(%s: ptr:%p\n, __func__, ext_csd);
/* rest of the code */
}
Here the DMA_DECLARE_BUFFER really defines the buffer as an automatic
variable with this function scope. This is tested and works :-)
4. get_dcache_line_size() can be simply defined as
#define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we
_really_ want to save a few bytes.
Actually I fail to understand why we would ever need
get_dcache_line_size() in a boot loader.
If I can ask for clarification here.
Shall not u-boot read on fly the cache line size (as it is now done) or
you don't like the get_cache_line_size defined as function?
Going further shall the get_cache_line_size be removed completely and
replaced with CONFIG_SYS_CACHE_LINE_SIZE?
Best regards,
Wolfgang Denk
--
Best regards,
Lukasz Majewski
Samsung Poland RD Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: Add Calxeda Highbank platform
Dear Rob Herring, In message 1314193751-6097-1-git-send-email-robherri...@gmail.com you wrote: From: Rob Herring rob.herr...@calxeda.com Add basic support for Calxeda Highbank platform. Only minimal support with serial and SATA are included. Signed-off-by: Jason Hobbs jason.ho...@calxeda.com Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- changes in v6: - Remove arch/arm/cpu/armv7/highbank/config.mk - Fix some whitespace errors (blank lines at EOF) changes in v5: - Rebase to current u-boot-arm/master (5557e86bb0793012057d5462976c2a902bc629ac) changes in v4: - Rebase to current mainline (d50a8f45c9a640b3bcbd0ede91f83c8646cca018) - Add back SATA support to inital patch as dependencies are all in mainline changes in v3: - Add hignbank to MAINTAINERS changes in v2: - Set DRAM size to correct value - split SATA and SD enabling to separate patches Which patch version is this, then? The Subject does not mention anything... 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 News is what a chap who doesn't care much about anything wants to read. And it's only news until he's read it. After that it's dead. - Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx3fb: move to CONFIG_VIDEO to support videomodes
I just found that the mx3fb driver uses:
static inline u32 reg_read(unsigned long reg)
{
return __REG(reg);
}
static inline void reg_write(u32 value, unsigned long reg)
{
__REG(reg) = value;
}
I am about to change this to readl() and writel(), should I do it in a
separate 'cosmetic only' patch before the really thing?
As it is more or less a re-write anyway (350 of 900 lines changed), it
think its probably ok to do it in one shot.
Helmut
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 04/13] Add isblank
On Tue, Aug 23, 2011 at 05:40:35PM -0400, Mike Frysinger wrote: On Tuesday, August 23, 2011 17:06:52 Jason Hobbs wrote: Existing ctype checks are implemented using a 256 byte lookup table, allowing each character to be in any of 8 character classes. Since there are 8 existing character classes without the blank class, I implemented isblank without using the lookup table. Since there are only two blank characters - tab and space - this is a more reasonable approach than doubling the size of the lookup table to accommodate one more class. and isspace() doesnt work because ... ? Because isspace matches characters other than tab and space, like end of line, which isn't always desired. Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100
On Wednesday, August 24, 2011 09:07:18 Ajay Bhargav wrote:
+ darmdfec-p_rxdesc = (struct rx_desc *) memalign(PKTALIGN,
+ ARMDFEC_RXQ_DESC_ALIGNED_SIZE * RINGSZ + 1);
memalign() returns a void*, so you shouldnt need to cast its return value (you
do this a couple of times)
+ /* Read mac from env if available */
+ eth_getenv_enetaddr(ethaddr, dev-enetaddr);
you shouldnt need to do this. the higher layers will take care of this for
you when you set write_hwaddr
also, it seems like some of my previous feedback wasnt addressed ?
+ while (cmd_sts BUF_OWNED_BY_DMA) {
...
+ };
no semi-colon needed
+int armada100_fec_initialize()
+{
...
+ darmdfec-regs = (void *) ARMD1_FEC_BASE;
make the reg base a parameter to armada100_fec_initialize()
+#if defined(CONFIG_PHY_BASE_ADR)
+ miiphy_write(dev-name, PHY_ADR_REQ, PHY_ADR_REQ,
+ (u16) CONFIG_PHY_BASE_ADR);
+#else
+ /* Search phy address from range 0-31 */
+ phy_adr = ethernet_phy_detect(dev);
+ if (phy_adr 0) {
+ printf(Error: PHY not detected at address range 0-31\n);
+ return -1;
+ } else {
+ debug(PHY detected at addr %d\n, phy_adr);
+ miiphy_write(dev-name, PHY_ADR_REQ, PHY_ADR_REQ,
+ (u16) phy_adr);
+ }
+#endif
this should be done in the armdfec_init() func, not the initialize func
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] OMAP3: DIG297: Use generic MMC driver
On Wed, Aug 24, 2011 at 6:43 AM, Luca Ceresoli luca.ceres...@comelit.it wrote:
Tom Rini wrote:
Switch from the legacy omap3 mmc driver to the new generic omap hsmmc
driver. This patch is based on the work done for Beagle, etc.
Signed-off-by: Tom Rinitr...@ti.com
Again, please Cc: the board maintainers in the future, thanks.
Oh, sorry, used to other lists where people complain about too many CCs.
[snip]
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index b68f073..0e05df3 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -97,8 +97,9 @@
#define CONFIG_BAUDRATE 115200
#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
115200}
-#define CONFIG_MMC
-#define CONFIG_OMAP3_MMC
+#define CONFIG_GENERIC_MMC 1
+#define CONFIG_MMC 1
+#define CONFIG_OMAP_HSMMC 1
IIRC the coding style says you should define the y/n constants without
a value, e.g.:
#define CONFIG_GENERIC_MMC
not:
#define CONFIG_GENERIC_MMC 1
Apart for this:
Tested-by: Luca Ceresoli luca.ceres...@comelit.it
OK, thanks, I'll respin this patch (all of the other boards were doing
the define CONFIG_FOO 1 everywhere) shortly.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx3fb: move to CONFIG_VIDEO to support videomodes
On 08/24/2011 05:34 PM, Helmut Raiger wrote:
I just found that the mx3fb driver uses:
static inline u32 reg_read(unsigned long reg)
{
return __REG(reg);
}
static inline void reg_write(u32 value, unsigned long reg)
{
__REG(reg) = value;
}
i.MX31 is quite old, and it was pushed before general ARM accessors were
introduced in u-boot. This is the reason. I appreciate you will fix this
point.
I am about to change this to readl() and writel(), should I do it in a
separate 'cosmetic only' patch before the really thing?
As it is more or less a re-write anyway (350 of 900 lines changed), it
think its probably ok to do it in one shot.
IMHO you can do in one shot - you can mention this change in the commit
message.
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
Re: [U-Boot] [PATCH] ARM: Add Calxeda Highbank platform
On 08/24/2011 10:06 AM, Wolfgang Denk wrote: Dear Rob Herring, In message 1314193751-6097-1-git-send-email-robherri...@gmail.com you wrote: From: Rob Herring rob.herr...@calxeda.com Add basic support for Calxeda Highbank platform. Only minimal support with serial and SATA are included. Signed-off-by: Jason Hobbs jason.ho...@calxeda.com Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Albert ARIBAUD albert.u.b...@aribaud.net --- changes in v6: - Remove arch/arm/cpu/armv7/highbank/config.mk - Fix some whitespace errors (blank lines at EOF) changes in v5: - Rebase to current u-boot-arm/master (5557e86bb0793012057d5462976c2a902bc629ac) changes in v4: - Rebase to current mainline (d50a8f45c9a640b3bcbd0ede91f83c8646cca018) - Add back SATA support to inital patch as dependencies are all in mainline changes in v3: - Add hignbank to MAINTAINERS changes in v2: - Set DRAM size to correct value - split SATA and SD enabling to separate patches Which patch version is this, then? The Subject does not mention anything... Sorry, it's v6 as the change log says. I forgot to fix the subject. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] OMAP3: CM-T35: Use generic MMC driver
On Wed, Aug 24, 2011 at 5:31 AM, Igor Grinberg grinb...@compulab.co.il wrote: On 08/23/11 01:13, Tom Rini wrote: Switch from the legacy omap3 mmc driver to the new generic omap hsmmc driver. This patch is based on the work done for Beagle, etc. Signed-off-by: Tom Rini tr...@ti.com It is a good practice to CC the board maintainer. Thanks. Tested-by: Igor Grinberg grinb...@compulab.co.il Apologies, thanks! -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/13] Replace space and tab checks with isblank
On Tue, Aug 23, 2011 at 05:42:59PM -0400, Mike Frysinger wrote: On Tuesday, August 23, 2011 17:06:54 Jason Hobbs wrote: - while (*nn == ' ' || *nn == '\t') + while (isblank(*nn)) nn++; at least for these walking forward ones, they could be replaced with: nn += strspn(nn, \t); -mike Sure, and we'd pick up the use of a currently unused function which might otherwise get optimized away with linker garbage collection. Even without taking garbage collection of strspn into account, switching one of the walkahead while isblank lines in my tree to the strspn pattern inceases my binary size by 11 bytes - two of them inceases it by 31 bytes. There's also the extra overhead for the function call and strspn's local variables. I'd consider it if strspn was more readable (I don't think it is), or there was some cost to adding the isblank macro (there isn't, as it's replacing existing code that was doing the same thing). Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] ARM: board removal
Dear Albert, [snip] Also, the following boards, for which Reinhard is a delegate, are still undecided: [U-Boot,46/52] ARM: remove broken at91rm9200dk board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,45/52] ARM: remove broken m501sk board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,44/52] ARM: remove broken kb9202 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,43/52] ARM: remove broken csb637 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,42/52] ARM: remove broken cmc_pu2 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,40/52] ARM: remove broken at91cap9adk board 2011-07-17 Wolfgang Denk reinhardm New Reinhard, can you either let me know if these should be removed or kept (or if you're going to process them through your repo and send out a pull req)? If you are in the routine of applying removal patches, remove them as well. I have not heard anything about those boards. Thank you! Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Tuesday, August 23, 2011 17:48:50 Anton Staaf wrote:
I wasn't going to say it. :) How about something like this, which is
very similar to what you had Mike, but doesn't define the array in the
macro. It's a bit clearer what is going on, but also requires a bit
more work at each use.
#define DCACHE_RESIZE(size) ((size) + get_dcache_line_size() - 1)
#define DCACHE_ALIGN(buffer) ((buffer) + get_dcache_line_size() - 1)
~(get_dcache_line_size() - 1)
char buffer[DCACHE_RESIZE(100)];
as long as people always use a byte-sized type (i.e. char), this should work.
obviously using u32 buffer[...] will be bad.
It would be awesome if the idea below worked, but it can't because the
array is popped when the ({...}) scope is exited I believe.
yes, i believe you are correct.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Wednesday, August 24, 2011 09:25:53 Wolfgang Denk wrote:
Lukasz Majewski wrote:
3. Mike's DMA_DECLARE_BUFFER(buffer type, variable name,
size in bytes)
solution looks OK for me, at least for the stack allocated data (e.g.
ext_csd).
However this proposed implementation has been NAK'ed by Wolfgang.
I'm curious how this macro should look like? Is it only matter of code
reordering or other approach shall be found?
I think I'd like to see a macro that can be used like this:
void *dma_buffer_pointer = DMA_BUFFER(size_in_bytes);
as Anton highlighted, i'm not sure this is possible. DMA_BUFFER() would have
to be defined with ({...}), and any storage declared in there is in new scope,
so as soon as you exit that scope, any storage declared is invalid for use
outside of it. the only thing that is good for is producing a single value
(i.e. an int or char or a pointer etc..., but not storage).
if a person who knows more about gcc internals in this regard could comment,
that'd be great :).
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] Armada100: Enable 88E3015 PHY support for GplugD
On Wednesday, August 24, 2011 03:07:20 PM Ajay Bhargav wrote:
This patch adds support for 88E3015 PHY for Marvell GplugD board.
This patch depends on series of patch which adds support for Marvell
GuruPlug-Display.
Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com
---
Changes for v2:
- Not changed
board/Marvell/gplugd/gplugd.c | 33 -
include/configs/gplugd.h | 14 ++
2 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/board/Marvell/gplugd/gplugd.c b/board/Marvell/gplugd/gplugd.c
index 4cd4086..bf3cdb4 100644
--- a/board/Marvell/gplugd/gplugd.c
+++ b/board/Marvell/gplugd/gplugd.c
@@ -32,6 +32,8 @@
#include mvmfp.h
#include asm/arch/mfp.h
#include asm/arch/armada100.h
+#include asm/gpio.h
+#include miiphy.h
#ifdef CONFIG_ARMADA100_FEC
#include net.h
@@ -83,6 +85,11 @@ int board_init(void)
gd-bd-bi_arch_number = MACH_TYPE_SHEEVAD;
/* adress of boot parameters */
gd-bd-bi_boot_params = armd1_sdram_base(0) + 0x100;
+ /* Assert PHY_RST# */
+ gpio_direction_output(CONFIG_SYS_GPIO_PHY_RST, GPIO_LOW);
+ udelay(10);
+ /* Deassert PHY_RST# */
+ gpio_set_value(CONFIG_SYS_GPIO_PHY_RST, GPIO_HIGH);
return 0;
}
@@ -97,5 +104,29 @@ int board_eth_init(bd_t *bis)
return armada100_fec_register();
}
-#endif /* CONFIG_ARMADA100_FEC */
+#ifdef CONFIG_RESET_PHY_R
+/* Configure and initialize PHY chip 88E3015 */
+void reset_phy(void)
+{
+ u16 phy_adr;
+ const char *name = armd-fec0;
+
+ if (miiphy_set_current_dev(name))
+ return;
+
+ /* command to read PHY dev address */
+ if (miiphy_read(name, 0xff, 0xff, (u16 *) phy_adr)) {
Do you need the cast there ?
+ printf(Err..%s could not read PHY dev address\n, __func__);
+ return;
+ }
+ /* Set Ethernet LED in TX blink mode */
+ miiphy_write(name, phy_adr, PHY_LED_MAN_REG, 0x00);
+ miiphy_write(name, phy_adr, PHY_LED_PAR_SEL_REG, PHY_LED_VAL);
+
+ /* reset the phy */
+ miiphy_reset(name, phy_adr);
+ printf(88E3015 Initialized on %s\n, name);
Maybe debug() ?
+}
+#endif /* CONFIG_RESET_PHY_R */
+#endif /* CONFIG_ARMADA100_FEC */
diff --git a/include/configs/gplugd.h b/include/configs/gplugd.h
index f3b94d8..b63ffd5 100644
--- a/include/configs/gplugd.h
+++ b/include/configs/gplugd.h
@@ -80,6 +80,20 @@
#define CONFIG_ROOTPATH /tftpboot
#define CONFIG_SYS_IMG_NAME uImage
+/* GPIO Support */
+#define CONFIG_MARVELL_GPIO
+
+/* PHY configuration */
+#define CONFIG_MII
+#define CONFIG_CMD_MII
+#define CONFIG_RESET_PHY_R
+/* 88E3015 register definition */
+#define PHY_LED_PAR_SEL_REG 22
+#define PHY_LED_MAN_REG 25
+#define PHY_LED_VAL 0x5b/* LINK LED1, ACT LED2 */
+/* GPIO Configuration for PHY */
+#define CONFIG_SYS_GPIO_PHY_RST 104 /* GPIO104 */
+
/*
* mv-common.h should be defined after CMD configs since it used them
* to enable certain macros
Cheers
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] Armada100: Enable Ethernet support for GplugD
On Wednesday, August 24, 2011 03:07:19 PM Ajay Bhargav wrote:
This patch enables ethernet support for Marvell GplugD board. Network
related commands works.
Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com
---
Changes for v2:
- armada100_fec_initialize changed to armada100_fec_register
arch/arm/include/asm/arch-armada100/armada100.h | 57
+++ arch/arm/include/asm/arch-armada100/mfp.h |
19
board/Marvell/gplugd/gplugd.c | 39 +++
include/configs/gplugd.h| 19 +++-
4 files changed, 132 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-armada100/armada100.h
b/arch/arm/include/asm/arch-armada100/armada100.h index 3d567eb..849638d
100644
--- a/arch/arm/include/asm/arch-armada100/armada100.h
+++ b/arch/arm/include/asm/arch-armada100/armada100.h
@@ -41,6 +41,10 @@
/* Functional Clock Selection Mask */
#define APBC_FNCLKSEL(x)(((x) 0xf) 4)
+/* Fast Ethernet Controller Clock register definition */
+#define FE_CLK_RST 0x1
+#define FE_CLK_ENA 0x8
+
/* Register Base Addresses */
#define ARMD1_DRAM_BASE 0xB000
#define ARMD1_TIMER_BASE 0xD4014000
@@ -85,6 +89,59 @@ struct armd1mpmu_registers {
};
/*
+ * Application Subsystem Power Management
+ * Refer Datasheet Appendix A.9
+ */
+struct armd1apmu_registers {
+ u32 pcr;/* 0x000 */
+ u32 ccr;/* 0x004 */
+ u32 pad1;
+ u32 ccsr; /* 0x00C */
+ u32 fc_timer; /* 0x010 */
+ u32 pad2;
+ u32 ideal_cfg; /* 0x018 */
+ u8 pad3[0x04C - 0x018 - 4];
+ u32 lcdcrc; /* 0x04C */
+ u32 cciccrc;/* 0x050 */
+ u32 sd1crc; /* 0x054 */
+ u32 sd2crc; /* 0x058 */
+ u32 usbcrc; /* 0x05C */
+ u32 nfccrc; /* 0x060 */
+ u32 dmacrc; /* 0x064 */
+ u32 pad4;
+ u32 buscrc; /* 0x06C */
+ u8 pad5[0x07C - 0x06C - 4];
+ u32 wake_clr; /* 0x07C */
+ u8 pad6[0x090 - 0x07C - 4];
+ u32 core_status;/* 0x090 */
+ u32 rfsc; /* 0x094 */
+ u32 imr;/* 0x098 */
+ u32 irwc; /* 0x09C */
+ u32 isr;/* 0x0A0 */
+ u8 pad7[0x0B0 - 0x0A0 - 4];
+ u32 mhst; /* 0x0B0 */
+ u32 msr;/* 0x0B4 */
+ u8 pad8[0x0C0 - 0x0B4 - 4];
+ u32 msst; /* 0x0C0 */
+ u32 pllss; /* 0x0C4 */
+ u32 smb;/* 0x0C8 */
+ u32 gccrc; /* 0x0CC */
+ u8 pad9[0x0D4 - 0x0CC - 4];
+ u32 smccrc; /* 0x0D4 */
+ u32 pad10;
+ u32 xdcrc; /* 0x0DC */
+ u32 sd3crc; /* 0x0E0 */
+ u32 sd4crc; /* 0x0E4 */
+ u8 pad11[0x0F0 - 0x0E4 - 4];
+ u32 cfcrc; /* 0x0F0 */
+ u32 mspcrc; /* 0x0F4 */
+ u32 cmucrc; /* 0x0F8 */
+ u32 fecrc; /* 0x0FC */
+ u32 pciecrc;/* 0x100 */
+ u32 epdcrc; /* 0x104 */
+};
+
+/*
* APB1 Clock Reset/Control Registers
* Refer Datasheet Appendix A.10
*/
diff --git a/arch/arm/include/asm/arch-armada100/mfp.h
b/arch/arm/include/asm/arch-armada100/mfp.h index d6e0494..da76b58 100644
--- a/arch/arm/include/asm/arch-armada100/mfp.h
+++ b/arch/arm/include/asm/arch-armada100/mfp.h
@@ -64,6 +64,25 @@
#define MFP105_CI2C_SDA (MFP_REG(0x1a4) | MFP_AF1 |
MFP_DRIVE_MEDIUM)
#define MFP106_CI2C_SCL (MFP_REG(0x1a8) | MFP_AF1 |
MFP_DRIVE_MEDIUM)
+/* Fast Ethernet */
+#define MFP086_ETH_TXCLK (MFP_REG(0x158) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP087_ETH_TXEN (MFP_REG(0x15C) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
+#define MFP088_ETH_TXDQ3 (MFP_REG(0x160) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP089_ETH_TXDQ2 (MFP_REG(0x164) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP090_ETH_TXDQ1 (MFP_REG(0x168) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP091_ETH_TXDQ0 (MFP_REG(0x16C) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP092_ETH_CRS (MFP_REG(0x170) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
+#define MFP093_ETH_COL (MFP_REG(0x174) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
+#define MFP094_ETH_RXCLK (MFP_REG(0x178) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP095_ETH_RXER (MFP_REG(0x17C) | MFP_AF5 |
MFP_DRIVE_MEDIUM)
+#define MFP096_ETH_RXDQ3 (MFP_REG(0x180) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP097_ETH_RXDQ2 (MFP_REG(0x184) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP098_ETH_RXDQ1 (MFP_REG(0x188) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP099_ETH_RXDQ0 (MFP_REG(0x18C) | MFP_AF5 | MFP_DRIVE_MEDIUM)
+#define MFP100_ETH_MDC (MFP_REG(0x190) | MFP_AF5 |
Re: [U-Boot] [PATCH v4 07/13] Add standard environment variables README
On Tue, Aug 23, 2011 at 05:45:07PM -0400, Mike Frysinger wrote: this somewhat duplicates the Environment Variables section in the top level README. can't we have just one location for this stuff ? Ah, you're right. When I searched for existing doc before adding this file, I didn't think to look outside of the doc dir. I will move this doc into README. Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100
On Wednesday, August 24, 2011 03:07:18 PM Ajay Bhargav wrote:
This patch adds support for Fast Ethernet Controller driver for
Armada100 series.
Signed-off-by: Ajay Bhargav ajay.bhar...@einfochips.com
---
[...]
diff --git a/drivers/net/armada100_fec.c b/drivers/net/armada100_fec.c
new file mode 100644
index 000..e36dca6
--- /dev/null
+++ b/drivers/net/armada100_fec.c
@@ -0,0 +1,761 @@
+/*
+ * (C) Copyright 2011
+ * eInfochips Ltd. www.einfochips.com
+ * Written-by: Ajay Bhargav ajay.bhar...@einfochips.com
+ *
+ * (C) Copyright 2010
+ * Marvell Semiconductor www.marvell.com
+ * Contributor: Mahavir Jain mj...@marvell.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include net.h
+#include malloc.h
+#include miiphy.h
+#include netdev.h
+#include asm/types.h
+#include asm/byteorder.h
+#include linux/err.h
+#include linux/mii.h
+#include asm/io.h
+#include asm/arch/armada100.h
+#include armada100_fec.h
+
+#define PHY_ADR_REQ 0xFF/* Magic number to read/write PHY
address */
+
+#ifdef DEBUG
+static int eth_dump_regs(struct eth_device *dev)
+{
+ struct armdfec_device *darmdfec = to_darmdfec(dev);
+ struct armdfec_reg *regs = darmdfec-regs;
+ unsigned int i = 0;
+
+ printf(\noffset: phy_adr, value: 0x%x\n, readl(regs-phyadr));
+ printf(offset: smi, value: 0x%x\n, readl(regs-smi));
+ for (i = 0x400; i = 0x4e4; i += 4)
+ printf(offset: 0x%x, value: 0x%x\n,
+ i, readl(ARMD1_FEC_BASE + i));
+ return 0;
+}
+#endif
+
+static int armdfec_phy_timeout(u32 reg, u32 flag, int cond)
+{
+ u32 timeout = PHY_WAIT_ITERATIONS;
+ while (--timeout) {
+ if (cond (readl(reg) flag))
+ break;
+ else if (!cond !(readl(reg) flag))
You can read the register into some temporary variable so you don't need the
readl() at two places.
+ break;
+ udelay(PHY_WAIT_MICRO_SECONDS);
+ }
+ return !timeout;
+}
+
+static int smi_reg_read(const char *devname, u8 phy_addr, u8 phy_reg,
+ u16 *value)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ struct armdfec_device *darmdfec = to_darmdfec(dev);
+ struct armdfec_reg *regs = darmdfec-regs;
+ u32 val, reg_data;
+
+ if (phy_addr == PHY_ADR_REQ phy_reg == PHY_ADR_REQ) {
+ reg_data = readl(regs-phyadr);
+ *value = (u16) (reg_data 0x1f);
+ return 0;
+ }
+
+ /* check parameters */
+ if (phy_addr PHY_MASK) {
+ printf(Err..(%s) Invalid phy address: 0x%X\n,
+ __func__, phy_addr);
+ return -EINVAL;
+ }
+ if (phy_reg PHY_MASK) {
+ printf(Err..(%s) Invalid register offset: 0x%X\n,
+ __func__, phy_reg);
+ return -EINVAL;
+ }
+
+ /* wait for the SMI register to become available */
+ if (armdfec_phy_timeout((u32)regs-smi, SMI_BUSY, FALSE)) {
Adjust the function so you don't need the cast.
+ printf(Error (%s) PHY busy timeout\n, __func__);
+ return -1;
+ }
+
+ writel(phy_addr 16 | phy_reg 21 | SMI_OP_R, regs-smi);
Parentheses missing maybe ?
+
+ /* now wait for the data to be valid */
+ if (armdfec_phy_timeout((u32)regs-smi, SMI_R_VALID, TRUE)) {
+ val = readl(regs-smi);
+ printf(Err (%s) PHY Read timeout, val=0x%x\n, __func__, val);
+ return -1;
+ }
+ val = readl(regs-smi);
+ *value = val 0x;
+
+ return 0;
+}
+
+static int smi_reg_write(const char *devname,
+ u8 phy_addr, u8 phy_reg, u16 value)
+{
+ struct eth_device *dev = eth_get_dev_by_name(devname);
+ struct armdfec_device *darmdfec = to_darmdfec(dev);
+ struct armdfec_reg *regs = darmdfec-regs;
+
+ if (phy_addr == PHY_ADR_REQ phy_reg == PHY_ADR_REQ) {
+ clrsetbits_le32(regs-phyadr, 0x1f, value 0x1f);
+ return 0;
+ }
+
+ /* check parameters */
+ if (phy_addr PHY_MASK) {
+
Re: [U-Boot] [PATCH v2 1/3] net: Adds Fast Ethernet Controller driver for Armada100
On Wednesday, August 24, 2011 05:42:06 PM Mike Frysinger wrote: On Wednesday, August 24, 2011 09:07:18 Ajay Bhargav wrote: + darmdfec-p_rxdesc = (struct rx_desc *) memalign(PKTALIGN, + ARMDFEC_RXQ_DESC_ALIGNED_SIZE * RINGSZ + 1); memalign() returns a void*, so you shouldnt need to cast its return value (you do this a couple of times) + /* Read mac from env if available */ + eth_getenv_enetaddr(ethaddr, dev-enetaddr); you shouldnt need to do this. the higher layers will take care of this for you when you set write_hwaddr also, it seems like some of my previous feedback wasnt addressed ? I have exactly the same feeling :-( Ajay, please go through the feedback, if you don't understand something, just ask instead of hoping we won't notice ... we will, we see everything ;-) Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] powerpc/mpc8xxx: Extend CWL table
Extend CAS write Latency (CWL) table to comply with DDR3 spec
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
index 391eb25..15cd375 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -96,6 +96,10 @@ static inline int fsl_ddr_get_rtt(void)
* 6 if 2.5ns tCK = 1.875ns
* 7 if 1.875ns tCK = 1.5ns
* 8 if 1.5ns tCK = 1.25ns
+ * 9 if 1.25ns tCK = 1.07ns
+ * 10 if 1.07ns tCK = 0.935ns
+ * 11 if 0.935ns tCK = 0.833ns
+ * 12 if 0.833ns tCK = 0.75ns
*/
static inline unsigned int compute_cas_write_latency(void)
{
@@ -110,8 +114,18 @@ static inline unsigned int compute_cas_write_latency(void)
cwl = 7;
else if (mclk_ps = 1250)
cwl = 8;
- else
- cwl = 8;
+ else if (mclk_ps = 1070)
+ cwl = 9;
+ else if (mclk_ps = 935)
+ cwl = 10;
+ else if (mclk_ps = 833)
+ cwl = 11;
+ else if (mclk_ps = 750)
+ cwl = 12;
+ else {
+ cwl = 12;
+ printf(Warning: CWL is out of range\n);
+ }
return cwl;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] powerpc/corenet_ds: Use separated speed tables for UDIMM and RDIMM
RDIMM has different timing parameters from UDIMM. Create new tables for
RDIMMs. Single-, dual- and quad-rank RDIMMs have been verified with speeds
from 800 to 1333MT/s. Speed table expands to include 1600MT/s for future
use. Single- and quad-rank RDIMM entries are copied into UDIMM tables for
future use.
Signed-off-by: York Sun york...@freescale.com
---
board/freescale/corenet_ds/ddr.c | 103 +++---
1 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index e3b3855..10ff4e7 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -118,53 +118,111 @@ typedef struct {
u32 force_2T;
} board_specific_parameters_t;
-/* ranges for parameters:
- * wr_data_delay = 0-6
- * clk adjust = 0-8
- * cpo 2-0x1E (30)
- */
-
-
-/* XXX: these values need to be checked for all interleaving modes. */
-/* XXX: No reliable dual-rank 800 MHz setting has been found. It may
- * seem reliable, but errors will appear when memory intensive
- * program is run. */
-/* XXX: Single rank at 800 MHz is OK. */
-const board_specific_parameters_t board_specific_parameters[][30] = {
+const board_specific_parameters_t board_specific_parameters_udimm[][30] = {
{
/*
* memory controller 0
* lo| hi| num| clk| wrlvl | cpo |wrdata|2T
-* mhz| mhz|ranks|adjst| start | delay|
+* mhz| mhz|ranks|adjst| start | |delay |
*/
{ 0, 850,4,4, 6, 0xff,2, 0},
{851, 950,4,5, 7, 0xff,2, 0},
{951, 1050, 4,5, 8, 0xff,2, 0},
{1051, 1250, 4,5,10, 0xff,2, 0},
{1251, 1350, 4,5,11, 0xff,2, 0},
+ {1351, 1666, 4,5,12, 0xff,2, 0},
{ 0, 850,2,5, 6, 0xff,2, 0},
{851, 950,2,5, 7, 0xff,2, 0},
{951, 1050, 2,5, 7, 0xff,2, 0},
{1051, 1250, 2,4, 6, 0xff,2, 0},
{1251, 1350, 2,5, 7, 0xff,2, 0},
+ {1351, 1666, 2,5, 8, 0xff,2, 0},
+ { 0, 850,1,4, 5, 0xff,2, 0},
+ {851, 950,1,4, 7, 0xff,2, 0},
+ {951, 1050, 1,4, 8, 0xff,2, 0},
+ {1051, 1250, 1,4, 8, 0xff,2, 0},
+ {1251, 1350, 1,4, 8, 0xff,2, 0},
+ {1351, 1666, 1,4, 8, 0xff,2, 0},
},
{
/*
* memory controller 1
* lo| hi| num| clk| wrlvl | cpo |wrdata|2T
-* mhz| mhz|ranks|adjst| start | delay|
+* mhz| mhz|ranks|adjst| start | |delay |
*/
{ 0, 850,4,4, 6, 0xff,2, 0},
{851, 950,4,5, 7, 0xff,2, 0},
{951, 1050, 4,5, 8, 0xff,2, 0},
{1051, 1250, 4,5,10, 0xff,2, 0},
{1251, 1350, 4,5,11, 0xff,2, 0},
+ {1351, 1666, 4,5,12, 0xff,2, 0},
{ 0, 850,2,5, 6, 0xff,2, 0},
{851, 950,2,5, 7, 0xff,2, 0},
{951, 1050, 2,5, 7, 0xff,2, 0},
{1051, 1250, 2,4, 6, 0xff,2, 0},
{1251, 1350, 2,5, 7, 0xff,2, 0},
+ {1351, 1666, 2,5, 8, 0xff,2, 0},
+ { 0, 850,1,4, 5, 0xff,2, 0},
+ {851, 950,1,4, 7, 0xff,2, 0},
+ {951, 1050, 1,4, 8, 0xff,2, 0},
+ {1051, 1250, 1,4, 8, 0xff,2, 0},
+ {1251, 1350, 1,4, 8, 0xff,2, 0},
+ {1351, 1666, 1,4, 8, 0xff,2, 0},
+ }
+};
+
+const board_specific_parameters_t board_specific_parameters_rdimm[][30] = {
+ {
+ /*
+* memory controller 0
+* lo| hi| num| clk| wrlvl | cpo |wrdata|2T
+* mhz| mhz|ranks|adjst| start | |delay |
+*/
+ { 0, 850,4,4, 6, 0xff,2, 0},
+ {851, 950,4,5, 7, 0xff,2, 0},
+ {951, 1050, 4,5, 8, 0xff,2, 0},
+ {1051, 1250, 4,5,10, 0xff,2, 0},
+ {1251, 1350, 4,5,11, 0xff,2, 0},
+ {1351, 1666, 4,5,12, 0xff,2, 0},
+ { 0, 850,2,4, 6, 0xff,2, 0},
+ {851, 950,2,4, 7, 0xff,2, 0},
+ {951, 1050, 2,4, 7, 0xff,2, 0},
+ {1051, 1250, 2,
[U-Boot] [PATCH 2/3] powerpc/mpc8xxx: Move DDR RCW overriding to common code
DDR RCW varies at different speeds. It is common for all platform. Move it
out from corenet_ds.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/options.c | 15 +++
board/freescale/corenet_ds/ddr.c | 14 --
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
index 7fc5494..7165635 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
@@ -484,6 +484,7 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
char buffer[HWCONFIG_BUFFER_SIZE];
char *buf = NULL;
const dynamic_odt_t *pdodt = odt_unknown;
+ ulong ddr_freq;
/*
* Extract hwconfig from environment since we have not properly setup
@@ -928,6 +929,20 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
if (pdimm[0].n_ranks == 4)
popts-quad_rank_present = 1;
+ ddr_freq = get_ddr_freq(0) / 100;
+ if (popts-registered_dimm_en) {
+ popts-rcw_override = 1;
+ popts-rcw_1 = 0x000a5a00;
+ if (ddr_freq = 800)
+ popts-rcw_2 = 0x;
+ else if (ddr_freq = 1066)
+ popts-rcw_2 = 0x0010;
+ else if (ddr_freq = 1333)
+ popts-rcw_2 = 0x0020;
+ else
+ popts-rcw_2 = 0x0030;
+ }
+
fsl_ddr_board_options(popts, pdimm, ctrl_num);
return 0;
diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index a184592..e3b3855 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -223,20 +223,6 @@ void fsl_ddr_board_options(memctl_options_t *popts,
/* DHC_EN =1, ODT = 60 Ohm */
popts-ddr_cdr1 = DDR_CDR1_DHC_EN;
-
- /* override SPD values. rcw_2 should vary at differnt speed */
- if (pdimm[0].registered_dimm == 1) {
- popts-rcw_override = 1;
- popts-rcw_1 = 0x000a5a00;
- if (ddr_freq = 800)
- popts-rcw_2 = 0x;
- else if (ddr_freq = 1066)
- popts-rcw_2 = 0x0010;
- else if (ddr_freq = 1333)
- popts-rcw_2 = 0x0020;
- else
- popts-rcw_2 = 0x0030;
- }
}
phys_size_t initdram(int board_type)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] ARM: board removal
Le 24/08/2011 18:09, Reinhard Meyer a écrit : Dear Albert, [snip] Also, the following boards, for which Reinhard is a delegate, are still undecided: [U-Boot,46/52] ARM: remove broken at91rm9200dk board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,45/52] ARM: remove broken m501sk board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,44/52] ARM: remove broken kb9202 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,43/52] ARM: remove broken csb637 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,42/52] ARM: remove broken cmc_pu2 board 2011-07-17 Wolfgang Denk reinhardm New [U-Boot,40/52] ARM: remove broken at91cap9adk board 2011-07-17 Wolfgang Denk reinhardm New Reinhard, can you either let me know if these should be removed or kept (or if you're going to process them through your repo and send out a pull req)? If you are in the routine of applying removal patches, remove them as well. I have not heard anything about those boards. Thank you! Understood. Update: Aaaargh! With many patches removed from the series, plus some unrelated patches which have altered source files from to-be-removed boards, already the second of the remaining patches in Wolfgang's series doesn't apply cleanly any more. Wolfgang, did you by any chance use some kind of script to produce your patchset, and if so, could you regenerate the set of patches for the remaining boards, those that currently have an 'action required' status in patchwork? Best Regards, Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Wed, Aug 24, 2011 at 6:25 AM, Wolfgang Denk w...@denx.de wrote: Dear Lukasz Majewski, In message 20110824120744.097ba2c5@lmajewski.digital.local you wrote: After reading dcache related threads I'd like to sum them up: 1. alloca() - not acceptable to u-boot mainline by Wolfgang. I agree that alloca is NOT the way to go. 2. malloc/memalign - avoidable to use 3. Mike's DMA_DECLARE_BUFFER(buffer type, variable name, size in bytes) solution looks OK for me, at least for the stack allocated data (e.g. ext_csd). However this proposed implementation has been NAK'ed by Wolfgang. I'm curious how this macro should look like? Is it only matter of code reordering or other approach shall be found? I think I'd like to see a macro that can be used like this: void *dma_buffer_pointer = DMA_BUFFER(size_in_bytes); 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. Actually I fail to understand why we would ever need get_dcache_line_size() in a boot loader. It is required so that we can correctly allocate buffers that will be used by DMA engines to read or write data. The reason that these buffers need to be cache line size aligned is because unaligned cache invalidates are not possible to do in a safe way. The problem is that invalidating a partial cache line requires invalidating the entire line. And the other part of the line can contain nearby variables (especially if the buffer is stack allocated), so we have to first flush the cache line to be safe. However, that flush will clobber the values that the DMA engine wrote to main memory that are not reflected in the cache. Thanks, Anton 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 know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: tegra2: fix out-of-tree build
On Tue, Aug 23, 2011 at 8:03 PM, Che-liang Chiou clch...@chromium.org wrote: Hi Anton, Thanks for comments. Replied below. Regards, Che-Liang On Wed, Aug 24, 2011 at 1:01 AM, Anton Staaf robot...@google.com wrote: On Tue, Aug 23, 2011 at 3:03 AM, Che-Liang Chiou clch...@chromium.org wrote: The out-of-tree build fails because the Makefiles in question depend on source files of another directory but do not explicitly mkdir that directory. As a matter of fact, other Makefiles under board/*/ directory that refer to source files under another directory explicitly call mkdir. This patch adds explicit mkdir's to the Makefiles in question, and verifies that out-of-tree build is working. Signed-off-by: Che-Liang Chiou clch...@chromium.org Cc: Albert Aribaud albert.u.b...@aribaud.net --- board/nvidia/harmony/Makefile | 4 board/nvidia/seaboard/Makefile | 4 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/board/nvidia/harmony/Makefile b/board/nvidia/harmony/Makefile index 9fb6b57..ebd8e02 100644 --- a/board/nvidia/harmony/Makefile +++ b/board/nvidia/harmony/Makefile @@ -24,6 +24,10 @@ include $(TOPDIR)/config.mk +ifneq ($(OBJTREE),$(SRCTREE)) +$(shell mkdir -p $(obj)../common) +endif + We should actually fix this by making the other directory build a library and then include the library in this Makefile. I had a reminder to get back to this but haven't yet. Thanks, Anton I find that Makefiles that call mkdir are those depend on a board/*/common/ directory which is shared among board variants (with a couple of exceptions). I guess the reason why none of boards implemented your proposal is because it involves changes to the top-level Makefile. The top-level Makefile cherry-picks the libraries, and the (only?) board-dependent library is LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o. And I guess implementing your proposal means we have to add a LIBBOARD_COMMON to the top-level Makefile. I am not sure whether adding a board-common library to the top-level Makefile is possible. If it is possible, maybe we could start from this patch. What do you think? I'm not sure what the accepted path is to add new libraries. Albert had indicated in a previous thread for this patch that it should be done using the library approach. I haven't had time to look into the actual implementation of that approach however. -Anton LIB = $(obj)lib$(BOARD).o COBJS := $(BOARD).o diff --git a/board/nvidia/seaboard/Makefile b/board/nvidia/seaboard/Makefile index 9fb6b57..ebd8e02 100644 --- a/board/nvidia/seaboard/Makefile +++ b/board/nvidia/seaboard/Makefile @@ -24,6 +24,10 @@ include $(TOPDIR)/config.mk +ifneq ($(OBJTREE),$(SRCTREE)) +$(shell mkdir -p $(obj)../common) +endif + LIB = $(obj)lib$(BOARD).o COBJS := $(BOARD).o -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 3/4] ARM: Warn when the machine ID isn't set.
On Wed, Aug 24, 2011 at 04:31:20PM +0200, Albert ARIBAUD wrote:
Le 04/08/2011 08:30, Albert ARIBAUD a ?crit :
Hi Christopher,
Le 18/07/2011 19:33, Christopher Harvey a ?crit :
Linux cannot boot without it.
Signed-off-by: Christopher Harveychar...@matrox.com
---
V2:
Used a #define instead of a constant.
Used a printf instead of a debug.
---
V3:
Moved gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID; before the
init_sequence loop, so it doesn't overwrite existing values.
Removed unneeded braces.
Reminder, in V2 of this series there are 3 uncommited patches that
have no comments.
---
V3:
Fixed mixed tabs and spaces.
Message prints in both debug and release mode.
arch/arm/include/asm/u-boot.h |2 ++
arch/arm/lib/board.c |2 ++
arch/arm/lib/bootm.c |3 +++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index ed33327..81735de 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -48,4 +48,6 @@ typedef struct bd_info {
} bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;
+#define BI_ARCH_NUMBER_INVALID 0x
+
#endif /* _U_BOOT_H_ */
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index fc52a26..1635aa1 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -281,6 +281,8 @@ void board_init_f (ulong bootflag)
gd-mon_len = _bss_end_ofs;
+ gd-bd-bi_arch_number = BI_ARCH_NUMBER_INVALID;
+
for (init_fnc_ptr = init_sequence; *init_fnc_ptr;
++init_fnc_ptr) {
if ((*init_fnc_ptr)() != 0) {
hang ();
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..d5fd26b 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -113,6 +113,9 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
printf (Using machid 0x%x from environment\n, machid);
}
+ if (machid == BI_ARCH_NUMBER_INVALID)
+ printf(Warning: machid not set.\n);
+
show_boot_progress (15);
#ifdef CONFIG_OF_LIBFDT
This patch does not apply cleanly any more. Can you post a rebased V5
please?
Ping?
Amicalement,
--
Albert.
I lost confidence in blindly rebasing because I haven't had time to go
through u-boot to make sure no boards are able to set their machine id
before I can. When I get a moment I will get back into this code and
rebase it when I feel comfortable with the changes. Probably this
week.
-Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Wednesday, August 24, 2011 13:27:05 Anton Staaf wrote: On Wed, Aug 24, 2011 at 6:25 AM, Wolfgang Denk wrote: Lukasz Majewski wrote: 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. Actually I fail to understand why we would ever need get_dcache_line_size() in a boot loader. It is required so that we can correctly allocate buffers that will be used by DMA engines to read or write data. The reason that these buffers need to be cache line size aligned is because unaligned cache invalidates are not possible to do in a safe way. The problem is that invalidating a partial cache line requires invalidating the entire line. And the other part of the line can contain nearby variables (especially if the buffer is stack allocated), so we have to first flush the cache line to be safe. However, that flush will clobber the values that the DMA engine wrote to main memory that are not reflected in the cache. right, and that's why i want to hide it be hind a dma buffer allocate API so that people can just say i want a dma safe buffer rather than having to delve into these details. they'll inevitable get confused and screw it up. ;) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] ARM: board removal
Dear Albert ARIBAUD, In message 4e553288.9000...@aribaud.net you wrote: Wolfgang, did you by any chance use some kind of script to produce your patchset, and if so, could you regenerate the set of patches for the remaining boards, those that currently have an 'action required' status in patchwork? No, this was done manually. Do you have a list of the boards that shall eb removed? And which exact tree shall the patches be based on? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A 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] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
Dear Anton Staaf, In message CAF6FioWBsjFa+QdFNHEQGO50eLoqZMc--Yt3-iYX6DWr=hc...@mail.gmail.com you wrote: 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. Actually I fail to understand why we would ever need get_dcache_line_size() in a boot loader. It is required so that we can correctly allocate buffers that will be used by DMA engines to read or write data. The reason that these No, it is definitely NOT needed for this purpose - we have been using CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so I don't really understand why we now would need a new function for this? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Brain: an apparatus with which we think we think.- Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message CAF6FioWBsjFa+QdFNHEQGO50eLoqZMc--Yt3-iYX6DWr=hc...@mail.gmail.com you wrote: 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. Actually I fail to understand why we would ever need get_dcache_line_size() in a boot loader. It is required so that we can correctly allocate buffers that will be used by DMA engines to read or write data. The reason that these No, it is definitely NOT needed for this purpose - we have been using CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so I don't really understand why we now would need a new function for this? Ahh, I misunderstood your question. I thought you were asking about the need to know the cache line size. Not it's specific implementation as a function call. In which case, I agree, and am happy to use CONFIG_SYS_CACHE_LINE_SIZE, though I don't see any definitions of CONFIG_SYS_CACHE_LINE_SIZE in the entire U-Boot tree. What have I missed? Thanks, Anton Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Brain: an apparatus with which we think we think. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] gcc-4.6 warnings
We get a bunch of warnings like this with gcc-4.6.x: e1000.c:4334:3: warning: variable 'x' set but not used [-Wunused-but-set-variable] Are we get with adding -Wunused-but-set-variable so they don't show up? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] Added documentation for CONFIG_SYS_TEXT_BASE.
On Thu, Aug 04, 2011 at 08:20:33AM +0200, Albert ARIBAUD wrote: Hi Christopher, Le 07/07/2011 16:26, Christopher Harvey a ?crit : Signed-off-by: Christopher Harveychar...@matrox.com --- V2: Make it clear that this is the start address of u-boot. README |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/README b/README index 2da0f96..8345746 100644 --- a/README +++ b/README @@ -2366,6 +2366,12 @@ Configuration Settings: - CONFIG_SYS_SDRAM_BASE: Physical start address of SDRAM. _Must_ be 0 here. +- CONFIG_SYS_TEXT_BASE: + Is the start address of the u-boot code. + This value can be in ROM space since u-boot can startup from + within ROM. This value has nothing to do with the relocation + destination in RAM. + - CONFIG_SYS_MBIO_BASE: Physical start address of Motherboard I/O (if using a Cogent motherboard) Applied to u-boot-arm/master (with 3 trailing whitespaces fixed), thanks! Amicalement, -- Albert. I'm curious, this one never went in. I'd like to know if I'm not understanding CONFIG_SYS_TEXT_BASE completely. thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gcc-4.6 warnings
On Wednesday, August 24, 2011 14:29:43 Kumar Gala wrote: We get a bunch of warnings like this with gcc-4.6.x: e1000.c:4334:3: warning: variable 'x' set but not used [-Wunused-but-set-variable] Are we get with adding -Wunused-but-set-variable so they don't show up? in general, i like this new warning as it tends to catch variables that are dead. i wonder why the e1000 driver has this indirection in the first place. simply calling readl() without using the return value shouldnt cause warnings or DCE ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
Dear Anton Staaf, In message caf6fiowm6mezmmdr6+i8tgolg-en4tihtocaupbh0o7vqha...@mail.gmail.com you wrote: No, it is definitely NOT needed for this purpose - we have been using CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so I don't really understand why we now would need a new function for this? Ahh, I misunderstood your question. I thought you were asking about the need to know the cache line size. Not it's specific implementation as a function call. In which case, I agree, and am happy to use CONFIG_SYS_CACHE_LINE_SIZE, though I don't see any definitions of CONFIG_SYS_CACHE_LINE_SIZE in the entire U-Boot tree. What have I missed? I copy pasted the name, incorrectly. It's CONFIG_SYS_CACHELINE_SIZE You will find this being used: - grep -R CONFIG_SYS_CACHELINE_SIZE * | wc -l 276 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 certain things men must do to remain men. -- Kirk, The Ultimate Computer, stardate 4929.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gcc-4.6 warnings
Dear Kumar Gala, In message 3aa0e5b6-7e38-4cb0-94e2-f7bba9a10...@kernel.crashing.org you wrote: We get a bunch of warnings like this with gcc-4.6.x: e1000.c:4334:3: warning: variable 'x' set but not used [-Wunused-but-set-variable] Are we get with adding -Wunused-but-set-variable so they don't show up? If the variable is not used, why don't we remove it, then? 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 C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] Added documentation for CONFIG_SYS_TEXT_BASE.
Dear Christopher Harvey, In message 20110824183457.gb3...@harvey-pc.matrox.com you wrote: +- CONFIG_SYS_TEXT_BASE: + Is the start address of the u-boot code. + This value can be in ROM space since u-boot can startup from + within ROM. This value has nothing to do with the relocation + destination in RAM. + - CONFIG_SYS_MBIO_BASE: Physical start address of Motherboard I/O (if using a Cogent motherboard) Applied to u-boot-arm/master (with 3 trailing whitespaces fixed), thanks! ... I'm curious, this one never went in. I'd like to know if I'm not understanding CONFIG_SYS_TEXT_BASE completely. I can't see it in Albert's u-boot-arm/master branch, either. ...and the text is actually wrong. What is the start address? I would say that _start defines the start address, i. e. the entry point into the U-Boot code where the CPU starts execution after a reset. But this is on most systems NOT CONFIG_SYS_TEXT_BASE. CONFIG_SYS_TEXT_BASE is the start address of the text segment. - as the name suggests. Guess that should be fixed... 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 only time the world beats a path to your door is when you are in the bathroom. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Wed, 24 Aug 2011 11:25:42 -0700 Anton Staaf robot...@google.com wrote: On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message CAF6FioWBsjFa+QdFNHEQGO50eLoqZMc--Yt3-iYX6DWr=hc...@mail.gmail.com you wrote: 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. Actually I fail to understand why we would ever need get_dcache_line_size() in a boot loader. It is required so that we can correctly allocate buffers that will be used by DMA engines to read or write data. The reason that these No, it is definitely NOT needed for this purpose - we have been using CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so I don't really understand why we now would need a new function for this? Ok, so one problem solved :-). Ahh, I misunderstood your question. I thought you were asking about the need to know the cache line size. Not it's specific implementation as a function call. In which case, I agree, and am happy to use CONFIG_SYS_CACHE_LINE_SIZE, though I don't see any definitions of CONFIG_SYS_CACHE_LINE_SIZE in the entire U-Boot tree. What have I missed? There are some similar definitions: ./include/configs/atstk1006.h:#define CONFIG_SYS_DCACHE_LINESZ 32 ./include/configs/atngw100.h:#define CONFIG_SYS_DCACHE_LINESZ 32 ./include/configs/favr-32-ezkit.h:#define CONFIG_SYS_DCACHE_LINESZ 32 Thanks, Anton Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Brain: an apparatus with which we think we think. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, Lukasz Majewski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] fastboot gadget support
Hi, 2011/8/10 Sebastian Andrzej Siewior bige...@linutronix.de: It was tested before it has been re-written. It is possible that it is broken. It is posted for reference only not for merging. Looking at this code, I can already say that the way it is written is not suitable for mainline acceptance at all. If you at least would run the Linux checkpatch over it, it would result in an almost endless list of style warnings and errors ;-) But, since it RFC only, let's look into the design parts and not be too picky about the style (yet) I may be missing something, but it appears to me that this particular patch for the fastboot framework makes several assumptions about: * if MMC is available (max 2 controllers, namely 0 or 1). Let' s say my hardware doe not support it, and I do not want to enable it due to codesize reasons... * if NAND is available and it is either YAFFS or raw, what if I have UBI? * Or let's drop the MMC and NAND, and assume we only have a harddrive or USB storage on our board ;-) * Hardcoded NAND block sizes which are evil. * storage_medium is hardcoded set to NAND, never to EMMC, so what is the EMMC code doing here? Furthermore: * Board code is mixed up with generic code. * drivers/usb/dwc3/fastboot_oem.c, drivers/usb/dwc3/misc.c, drivers/usb/dwc3/sparse.c contain code that has _nothing_ to do with USB. * generic files (for example like include/linux/usb/ch9.h) are adapted with changes not even used by the code. * Mix up of different licenses: U-boot is still GPLv2, while this patch contains Apache based licenses (Not sure if it conflicts with GPL, but it seems strange) * it makes a lot of assumptions how the hardware looks like. * It is not properly separated across different subsystems. There need to be a proper separation between drivers, library code, U-boot core code and board files. Everything that is board specific should go in board files. NAND-availability or partitioning is board specific, MMC as well, the only assumption you can make about hardware that should always be available is RAM, you can only not assume how much there is, and which address area is free. NAND and MMC usage should be completely configurable per board. * There need to be proper Documentation in the doc directory. * It would be great to have at least a demo tool in /tools or a commonly used OSS package that provides the tools, such that the mechanism can be tested as well. This is the faastboot gadget code based on git://git.omapzoom.org/repo/u-boot.git as of commit 601ff71c8 including a few changes. Some of them are: - generic mmc framework I have not found a ' generic' mmc framework, only a 'fastboot' dedicated mmc framework. So, I have no objections to the protocol or the mechanism itself, as long as it is properly implemented. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Wed, Aug 24, 2011 at 12:04 PM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message caf6fiowm6mezmmdr6+i8tgolg-en4tihtocaupbh0o7vqha...@mail.gmail.com you wrote: No, it is definitely NOT needed for this purpose - we have been using CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so I don't really understand why we now would need a new function for this? Ahh, I misunderstood your question. I thought you were asking about the need to know the cache line size. Not it's specific implementation as a function call. In which case, I agree, and am happy to use CONFIG_SYS_CACHE_LINE_SIZE, though I don't see any definitions of CONFIG_SYS_CACHE_LINE_SIZE in the entire U-Boot tree. What have I missed? I copy pasted the name, incorrectly. It's CONFIG_SYS_CACHELINE_SIZE You will find this being used: - grep -R CONFIG_SYS_CACHELINE_SIZE * | wc -l 276 :) Hah, thanks. I tried a number of permutations, but never the right one. -Anton 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 certain things men must do to remain men. -- Kirk, The Ultimate Computer, stardate 4929.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
On Wed, Aug 24, 2011 at 12:18 PM, Lukasz Majewski majess1...@gmail.com wrote: On Wed, 24 Aug 2011 11:25:42 -0700 Anton Staaf robot...@google.com wrote: On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message CAF6FioWBsjFa+QdFNHEQGO50eLoqZMc--Yt3-iYX6DWr=hc...@mail.gmail.com you wrote: 4. get_dcache_line_size() can be simply defined as #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we _really_ want to save a few bytes. Actually I fail to understand why we would ever need get_dcache_line_size() in a boot loader. It is required so that we can correctly allocate buffers that will be used by DMA engines to read or write data. The reason that these No, it is definitely NOT needed for this purpose - we have been using CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so I don't really understand why we now would need a new function for this? Ok, so one problem solved :-). Ahh, I misunderstood your question. I thought you were asking about the need to know the cache line size. Not it's specific implementation as a function call. In which case, I agree, and am happy to use CONFIG_SYS_CACHE_LINE_SIZE, though I don't see any definitions of CONFIG_SYS_CACHE_LINE_SIZE in the entire U-Boot tree. What have I missed? There are some similar definitions: ./include/configs/atstk1006.h:#define CONFIG_SYS_DCACHE_LINESZ 32 ./include/configs/atngw100.h:#define CONFIG_SYS_DCACHE_LINESZ 32 ./include/configs/favr-32-ezkit.h:#define CONFIG_SYS_DCACHE_LINESZ 32 I would assume that these should be changed to the one mentioned by Wolfgang. But this still leaves us with a question of how to make a simple, easy to use macro for allocating cache line size aligned stack buffers. I'll work on that some more and see if I can come up with something. Thanks, Anton Thanks, Anton Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Brain: an apparatus with which we think we think. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, Lukasz Majewski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] DM9000: change some printf to use debug instead
Dear Eric Jarrige, In message 2b613989-addb-43d6-a8c3-a30d52452...@armadeus.org you wrote: I'am just wondering: I see that DM9000_DBG is used all over dm9000 code - do you know the reason why not just use debug()? dm9000 does not use debug() at all. That's the reason to fix the printf issues as a first priority by using the DM9000_DBG. NAK. If you touch that, then please do it right: us debug() instead, and remove DM9000_DBG. 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 When you say I wrote a program that crashed Windows, people just stare at you blankly and say Hey, I got those with the system, *for free*.- Linus Torvalds in 3itc77$9...@ninurta.fer.uni-lj.si ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot][PATCH] tftp: Remove command repetition.
Dear Marek Belisko, In message 1313348911-10817-1-git-send-email-marek.beli...@open-nandra.com you wrote: Lot of commands in u-boot have repeat command flag but not all are very usefull. Remove this flag for tftp to avoid repeated file download when user press enter. Why don't you consider this useful? It makes an excellent test for the network drivers to repeatedly download a file. NAK. 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 Totally illogical, there was no chance. -- Spock, The Galileo Seven, stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0)
Dear Kumar Gala,
In message 17e34909-a735-4920-9980-059d95535...@kernel.crashing.org you wrote:
If so, I wonder what has changed, because this used to be working in
older versions of the kernel? I did not attampt a full git bisect,
but from some old images I still found it appears it must have been
broken between 2.6.16 (reboot in Linux works fine) and 2.6.27
(reboot does not work any more) - so probably this was part of the
arch/ppc = arch/powerpc rework.
Possible, its a pretty fragile reset solution so one (or a thousand) of
a million things could be the issue.
Is there any specific reason we don't use the good old approach of
triggering an unhandled machine check exception?
Hmm, when did we do that? I've got no issues with it if it causes
HRESET_REQ to be signaled on the older devices. On MPC8548 and greater
we provided a means for software to causes HRESET_REQ to be asserted.
So if an unhandled mcheck will do this sounds good to me.
For example for PQ2 Linux does this (in arch/powerpc/platforms/82xx/pq2.c):
26 void pq2_restart(char *cmd)
27 {
28 local_irq_disable();
29 setbits32(cpm2_immr-im_clkrst.car_rmr, RMR_CSRE);
30
31 /* Clear the ME,EE,IR DR bits in MSR to cause checkstop */
32 mtmsr(mfmsr() ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
33 in_8(cpm2_immr-im_clkrst.res[0]);
34
35 panic(Restart failed\n);
36 }
So we set the Checkstop Reset enable, and then reference a known bad
address.
Should we try and do the same here, too?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A person with one watch knows what time it is; a person with two
watches is never sure. Proverb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] checkpatch.pl: Add ability to ignore various messages
Dear Joe Perches, In message 1311804639.21169.22.camel@Joe-Laptop you wrote: Did you receive any feedback for your proposal, especially from Andrew Morton? This feature would be really useful for us, but I'd rather see this in mainline than starting a fork. A better version is in Linus' current 3.0+ as of a couple of days ago. It's not in 3.0. Great. Are you planning to submit a patch to add this into U-Boot? 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 Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension! - Buckaroo Banzai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README: clean up and document the Freescale QE/FMAN firmware macros
On Mon, Aug 22, 2011 at 4:45 PM, Timur Tabi ti...@freescale.com wrote: The Freescale QE and FMAN devices support uploading of firmware, and U-Boot can locate that firmware on different types of storage media. However, the current macros used for this code are inconsistent and poorly documented. Note that some of the code managed by these macros have not yet been posted externally. Such code will be posted, but properly documenting the macros is the first step. Wolfgang, if you're okay with the text in this patch, I will go ahead and make the corresponding changes to the code. I just want to make sure that there are no objections to these definitions before I work on the code itself. -- 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] [PATCH] post: fix up I/O helper usage
Dear Mike Frysinger,
In message 201108141645.40439.vap...@gentoo.org you wrote:
Sorry, but I will not accept inl() here.
so not even to fix build failures for most non-ppc arches ? i wont be
able to post an updated patch for a while.
so i can post a patch to use io{read,write}32, but then it'll only build for
Blackfin targets whereas the patch i posted originally works for all arches.
what exactly do you want done ?
Best would be to add io{read,write}*() support for those architectures
that don't have it yet.
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
I can type faster than I can move a mouse, so I find menu-driven
drawing packages time consuming and frustrating. - W. R. Stevens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: Defer Dataflash access to env_relocate_spec
Dear Hong Xu, In message 1312354896-24951-1-git-send-email-hong...@atmel.com you wrote: When env_init is called, the SPI is not actually initialized in U-Boot. So that we can not read Dataflash for its content. We simply mark it OK for now, and defer the real work to `env_relocate_spec'. (Idealy from env_nand.c) Signed-off-by: Hong Xu hong...@atmel.com How do you then get access for example to the baudrate environment variable, which is needed for initializing the console interface, which happens long before relocation? 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 All my life I wanted to be someone; I guess I should have been more specific. - Jane Wagner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] new tool mkenvimage: generates an env image from an arbitrary config file
Dear David Wagner,
In message 1312885889-20222-1-git-send-email-david.wag...@free-electrons.com
you wrote:
This tool takes a key=value configuration file (same as would a `printenv'
show)
and generates the corresponding environnment image, ready to be flashed.
s/nnm/nm/
Signed-off-by: David Wagner david.wag...@free-electrons.com
---
Hi Mike,
This 3rd version should address what you pointed out.
If this is v3, then why don't you say so in the Subject: ???
Could you please explain which usage scenarios you have in mind for
this tool? I would probably rather just load the text file you use as
input, and run env import -t on it.
Checkpatch says:
total: 4 errors, 5 warnings, 228 lines checked
Please fix these.
In addition:
...
+ default:
+ fprintf(stderr, Wrong option -%c\n, option);
+ usage(argv[0]);
+ return EXIT_FAILURE;
+ }
+ }
+
+
+ /* Check datasize and allocate the data */
Please only one blank line in cases like this.
+ /* envptr points to the beginning of the actual environment (after the
+ * crc and possible `redundant' bit */
inforrect multiline comment style.
+ /* Open the configuration file ... */
+ txt_filename = argv[optind];
+ if (!txt_filename) {
+ fprintf(stderr, Can't strdup() the configuration filename\n);
+ return EXIT_FAILURE;
Where is there any strdup() involved ?
+ txt_file = fopen(txt_filename, rb);
+ if (!txt_file) {
+ fprintf(stderr, Can't open configuration file: %s\n,
strerror(errno));
It would probably be very useful to also print the file name.
+ /* ... and check it */
+ ret = fstat(fileno(txt_file), txt_file_stat);
Why don't you simply use mmap() ?
+ for (i = 0 ; i txt_file_stat.st_size ; i++)
+ if (envptr[i] == '\n')
+ envptr[i] = '\0';
This is actually wrong. Envrionment variables can have embedded
newlines.
+ /*
+ * Make sure there is a final '\0' (necessary if the padding byte isn't
+ * 0x00 or if there wasn't a newline at the end of the configuration
You did not take this into account in your file size check above, it
seems.
+ * file) Also, don't add it if the configuration file size is exactly
+ * the size of the environnment.
The double '\0' termination is _always_ needed.
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 can observe a lot just by watchin'. - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc460: read get_sys_info from CPR registers instead of STRP registers
Dear Tirumala Marri, In message c7e65d5ac78ea9dea60d6533795da...@mail.gmail.com you wrote: As mentioned before, we might otherwise remove the dead code. [marri] Sorry I was on vacation last month. We do still need this code as PPC460 is still used by many companies. We are working in submitting the New patch set to fix most of the issues. Stefan asked before, but you did not reply yet, so here I ask again: What exactly are your plans? You did not respond to the Eiger patches for the last 9 months, so I somewhat doubt you are going to submit usable patches within the next couple of days, or are you? 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 biblical analogy I'd like to draw here. Casts are to C++ Programmers what the apple was to Eve. - Scott Douglas Meyers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] powerpc/8xxx: Add support for interactive DDR programming interface
Dear York Sun,
In message 1312923045-2612-7-git-send-email-york...@freescale.com you wrote:
Interactive DDR debugging provides a user interface to view and modify SPD,
DIMM parameters, board options and DDR controller registers before DDR is
initialized. With this feature, developers can fine-tune DDR for board
bringup and other debugging without frequently having to reprogram the flash.
To enable this feature, define CONFIG_FSL_DDR_INTERACTIVE in board header
file and set an environment variable to activate it. Syntax:
...
Checkpatch says:
WARNING: do not add new typedefs
WARNING: plain inline is preferred over __inline__
WARNING: do not add new typedefs
Please fix!
...
+/* Option parameter Structures */
+typedef struct {
+ const char *option_name;
+ size_t offset;
+ unsigned int size;
+ const char printHex;
We don't allow CamelCase identifiers. Please fix globally.
...
+ /*
+ * FIXME: For some reason printing this whole
+ * thing causes the machine to freeze.
+ * Splitting it into two printfs seems to make
+ * it work. Does printf() have limits on the
+ * length of the string?
+ */
Please fix this before submitting.
+ printf(
+ commands:\n
+ print print SPD and intermediate computed data\n
+ reset reboot machine\n
+ recompute reload SPD and options to default and recompute regs\n);
+ printf(
+ edit modify spd, parameter, or option\n);
+ printf(
+ computerecompute registers from current next_step to end\n
+ next_step shows current next_step\n
+ help this message\n
+ go program the memory controller and continue with u-boot\n);
+ continue;
+ }
Incorrect indentation.
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
Don't tell me how hard you work. Tell me how much you get done.
- James J. Ling
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] checkpatch.pl: Add ability to ignore various messages
On Wed, 2011-08-24 at 23:25 +0200, Wolfgang Denk wrote: This feature would be really useful for us, but I'd rather see this in mainline than starting a fork. A better version is in Linus' current 3.0+ as of a couple of days ago. It's not in 3.0. Great. Are you planning to submit a patch to add this into U-Boot? No I am not. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] powerpc/mpc83xx: Migrate from spd_sdram to unified DDR driver
Dear York Sun,
In message 1312923045-2612-5-git-send-email-york...@freescale.com you wrote:
Unified DDR driver is maintained for better performance, robustness and bug
fixes. Upgrading to use unified DDR driver for MPC83xx takes advantage of
overall improvement. It requires changes for board files to customize
platform-dependent parameters.
To utilize the unified DDR driver, a board needs to define CONFIG_FSL_DDRx
in the header file. No more boards will be accepted without such definition.
Note: the workaround for erratum DDR6 for the very old MPC834x Rev 1.0/1.1
and MPC8360 Rev 1.1/1.2 parts is not migrated to unified driver.
Signed-off-by: Kim Phillips kim.phill...@freescale.com
Signed-off-by: York Sun york...@freescale.com
Checkpatch says:
WARNING: do not add new typedefs
#408: FILE: arch/powerpc/include/asm/immap_83xx.h:289:
+typedef struct ccsr_ddr {
Please fix.
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
Every revolutionary idea - in science, politics, art, or whatever -
evokes three stages of reaction in a hearer:
1. It is completely impossible - don't waste my time.
2. It is possible, but it is not worth doing.
3. I said it was a good idea all along.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] apf9328: add default board configuration file
Dear Wolfgang, On 24 août 2011, at 07:49, Wolfgang Denk wrote: Dear Eric Jarrige, In message d25738a8-8a7a-475a-95f5-8408c6463...@armadeus.org you wrote: Stefano is right. filesize and fileaddr are dynamic variables, thet get created and updated on the fly. It makes no sense to pre-define them to any specific value. [Actually I have some changes in mind that avoid to save such variables with the environment at all.] I understand - It make sense for me to wait for the new interface. Which new interface do you mean? And why would waiting for it help you? By interface I mean the changes you mentioned to avoid to have filesize and fileaddr with the environment variables. What do you mean by push U-Boot through the serial port? Any of the respective commands in U-Boot (loads, loadb, loady) will automatically update the respective variables. I meant to boot using the iMX internal bootstrap loader as U-Boot is not yet running. Alternatively I can download U-Boot a second time to have the environment variables initialized. It is just a longer process than the original one. Are you aware of things like env import etc.? That could be the solution. I have to check it. Thanks for the update. And what makes you think that 192.168.0.10 might be a free IP address in my network? Or assume that 255.255.255.0 is the right netmask in this network? http://tools.ietf.org/html/rfc1918#page-4 This page lists 192.168/16 prefix, i. e. a 255.255.0.0 netmask. I know many development environments, and 192.168.x.x is used very, very often there. often with a /24 netmask, sometimes differently (at DENX we're using it with a /16 netmast, for example). 192.168/16 prefix is only the prefix of the class C private networks. IMHO that means there are 256 class C networks (255.255.255.0) reserved for private networks as mentioned on the same RFC page by ..and third block is a set of 256 contiguous class C network numbers In the same way, there is another address range 172.16 - 172.31 dedicated class B private networks for the organization who need /16 netmask. And there is absolutely NO guarantee that 192.168.0.10 is free, or that multiple users of your boards will boot simultaneously, or ... The _concept_ of such a default address is broken. These addresses may work for you, but they will not work for others, and thus it makes no sense to use them as defaults. The armadeus BSP provide a user interface to customize the network parameters according to end user network environment. Do you know the amount of efforts needed in any bigger organization to set up additional or to change existing network configurations? I meant our BSP enable to change U-Boot default configuration of the board to fit the existing networks of the end users/developpers - not to change the network configuration of any organization. Use DHCP? Sure, DHCP is the best *technical* solution. I meant for static IP address? Why does anybody need static IP addresses for the default case, i. e. for system bring up? Well, may be things can be easier to explain with static IP than explaining how to setup a DHCP server, DNS server Anyway we will work more on the DHCP solution if this solution is acceptable. Best regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] powerpc/mpc8349emds: Migrate from spd_sdram to unified DDR driver
Dear York Sun,
In message 1312923045-2612-6-git-send-email-york...@freescale.com you 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
Checkpatch says:
WARNING: do not add new typedefs
#149: FILE: board/freescale/mpc8349emds/ddr.c:14:
+typedef struct {
Please fix.
+++ b/board/freescale/mpc8349emds/ddr.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2011 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
+ * Version 2 as published by the Free Software Foundation.
U-Boot requires GPLv2+ in all new files. Please fix globally.
+typedef struct {
+ u32 datarate_mhz_low;
+ u32 datarate_mhz_high;
+ u32 n_ranks;
+ u32 clk_adjust;
+ u32 cpo;
+ u32 write_data_delay;
+ u32 force_2T;
We don't allow CamelCaps identifiers. Please fix globally.
+ /* Get clk_adjust, cpo, write_data_delay,2T, according to the board ddr
+ * freqency and n_banks specified in board_specific_parameters table.
+ */
Incorrect multiline comment style. Please fix 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
One thing they don't tell you about doing experimental physics is
that sometimes you must work under adverse conditions... like a state
of sheer terror.- W. K. Hartmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tsec: Configure the buffer descriptor bases to always include all of the descriptors
Dear Joe Hershberger, In message CANr=Z=anqtw_yv-xcqse8f2rpdpyymhkl7wwsrcpa_pqzkj...@mail.gmail.com you wrote: It fixes something that was wrong before you committed 063c12633d5ad74d52152d9c358e715475e17629, but at this point, it's just cosmetic. I don't think this is worth to change the code. Can you accept that we drop this patch? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I have seen further it is by standing on the shoulders of giants. - Isaac Newton, Letter to Robert Hooke, 5 February 1676 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] beagleboard: enable HUB power on all variants of the BeagleBoard
From: Christian Spielberger c.spielber...@bct-electronic.com
Signed-off-by: Joel A Fernandes joelag...@ti.com
Cc: Eric Bénard e...@eukrea.com
Cc: Christian Spielberger c.spielber...@bct-electronic.com
---
Pushing this patch myself as no one else did.
Previous discussions:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105663/
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101540/
board/ti/beagle/beagle.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 13fe39b..9d65e9e 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -332,7 +332,15 @@ int misc_init_r(void)
setenv(expansion_config.env_var, expansion_config.env_setting);
twl4030_power_init();
- twl4030_led_init(TWL4030_LED_LEDEN_LEDAON | TWL4030_LED_LEDEN_LEDBON);
+ switch (get_board_revision()) {
+ case REVISION_XM_C:
+ case REVISION_C4:
+ twl4030_led_init(TWL4030_LED_LEDEN_LEDAON |
TWL4030_LED_LEDEN_LEDBON);
+ break;
+ default:
+ twl4030_led_init(TWL4030_LED_LEDEN_LEDBON);
+ break;
+ }
/* Set GPIO states before they are made outputs */
writel(GPIO23 | GPIO10 | GPIO8 | GPIO2 | GPIO1,
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tsec: Configure the buffer descriptor bases to always include all of the descriptors
On Wed, Aug 24, 2011 at 5:46 PM, Wolfgang Denk w...@denx.de wrote: Dear Joe Hershberger, In message CANr=Z=anqtw_yv-xcqse8f2rpdpyymhkl7wwsrcpa_pqzkj...@mail.gmail.com you wrote: It fixes something that was wrong before you committed 063c12633d5ad74d52152d9c358e715475e17629, but at this point, it's just cosmetic. I don't think this is worth to change the code. Can you accept that we drop this patch? Yes, it is fine to drop this patch. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] apf9328: add default board configuration file
Dear Eric Jarrige, In message 8f000deb-1afc-403b-9b00-fa2bff2e1...@armadeus.org you wrote: Which new interface do you mean? And why would waiting for it help you? By interface I mean the changes you mentioned to avoid to have filesize and fileaddr with the environment variables. Don't expect this any time soon. Also, I don't see how this would have any influence on your situation. All I want to tell you is that it's not a good idea to rely on pre-initialization of such dynamically set variables. 192.168/16 prefix is only the prefix of the class C private networks. IMHO that means there are 256 class C networks (255.255.255.0) reserved for private networks as mentioned on the same RFC page by ..and third block is a set of 256 contiguous class C network numbers I can split the 192.168/16 range in any way I like. We use it as a single 255.255.0.0 masked network. I could as well define it as for 192.168/18 nets, or whatever comes to my mind. 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 Mirrors should reflect a little before throwing back images. - Jean Cocteau ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
