[U-Boot] [PATCH] integrator: stop calling pci_init() twice
The U-Boot startup infrastructure already makes sure pci_init() is
called at a proper time, calling it again from within the board
setup code will not make things better.
Signed-off-by: Linus Walleij
---
board/armltd/integrator/integrator.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/board/armltd/integrator/integrator.c
b/board/armltd/integrator/integrator.c
index a507c09..4658ac1 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -115,9 +115,6 @@ extern void cm_remap(void);
int misc_init_r (void)
{
-#ifdef CONFIG_PCI
- pci_init();
-#endif
setenv("verify", "n");
return (0);
}
--
1.7.7.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] microblaze: Wire up LL_TEMAC driver initialization
Initialize ll_temac driver. Reported-by: Michal Simek Signed-off-by: Stephan Linz --- .../xilinx/microblaze-generic/microblaze-generic.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/board/xilinx/microblaze-generic/microblaze-generic.c b/board/xilinx/microblaze-generic/microblaze-generic.c index c4c13a6..517b2f1 100644 --- a/board/xilinx/microblaze-generic/microblaze-generic.c +++ b/board/xilinx/microblaze-generic/microblaze-generic.c @@ -90,5 +90,10 @@ int board_eth_init(bd_t *bis) ret |= xilinx_emaclite_initialize(bis, XILINX_EMACLITE_BASEADDR, txpp, rxpp); #endif + +#ifdef CONFIG_XILINX_LL_TEMAC + ret |= xilinx_ll_temac_standard_init(bis); +#endif + return ret; } -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] microblaze: Enable TFTP put command
Signed-off-by: Stephan Linz --- include/configs/microblaze-generic.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index ec2e49e..a4cdcd8 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -256,6 +256,7 @@ #else # define CONFIG_CMD_PING # define CONFIG_CMD_DHCP +# define CONFIG_CMD_TFTPPUT #endif #if defined(CONFIG_SYSTEMACE) -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] microblaze: Enable several ethernet driver compilation
NET_MULTI enables to use several ethernet drivers but microblaze-generic platform config file select only one driver. Reported-by: Michal Simek Signed-off-by: Stephan Linz --- include/configs/microblaze-generic.h | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index 03a6f5a..29a86d1 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -65,11 +65,12 @@ /* ethernet */ #undef CONFIG_SYS_ENET -#ifdef XILINX_EMACLITE_BASEADDR -# define CONFIG_XILINX_EMACLITE1 +#if defined(XILINX_EMACLITE_BASEADDR) +# define CONFIG_XILINX_EMACLITE1 # define CONFIG_SYS_ENET -#elif XILINX_LLTEMAC_BASEADDR -# define CONFIG_XILINX_LL_TEMAC1 +#endif +#if defined(XILINX_LLTEMAC_BASEADDR) || defined(XILINX_LLTEMAC_BASEADDR1) +# define CONFIG_XILINX_LL_TEMAC1 # define CONFIG_SYS_ENET #endif #if defined(XILINX_AXIEMAC_BASEADDR) @@ -312,6 +313,7 @@ #defineCONFIG_SERVERIP 192.168.0.5 #defineCONFIG_GATEWAYIP192.168.0.1 #defineCONFIG_ETHADDR 00:E0:0C:00:00:FD +#defineCONFIG_ETH1ADDR 00:E0:0C:00:00:FC /* architecture dependent code */ #defineCONFIG_SYS_USR_EXCEP/* user exception */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] microblaze: Enable phylib and mii support
From: Michal Simek Enable phylib and mii support for LLTEMAC or AXI EMAC ethernet drivers on Microblaze systems. Signed-off-by: Michal Simek Acked-by: Stephan Linz --- include/configs/microblaze-generic.h | 21 + 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/include/configs/microblaze-generic.h b/include/configs/microblaze-generic.h index 29a86d1..ec2e49e 100644 --- a/include/configs/microblaze-generic.h +++ b/include/configs/microblaze-generic.h @@ -340,4 +340,25 @@ #define CONFIG_FIT 1 #define CONFIG_OF_LIBFDT 1 +#if defined(CONFIG_XILINX_LL_TEMAC) || defined(CONFIG_XILINX_AXIEMAC) +# define CONFIG_MII1 +# define CONFIG_CMD_MII1 +# define CONFIG_PHY_GIGE 1 +# define CONFIG_SYS_FAULT_ECHO_LINK_DOWN 1 +# define CONFIG_PHYLIB 1 +# define CONFIG_PHY_ATHEROS1 +# define CONFIG_PHY_BROADCOM 1 +# define CONFIG_PHY_DAVICOM1 +# define CONFIG_PHY_LXT1 +# define CONFIG_PHY_MARVELL1 +# define CONFIG_PHY_MICREL 1 +# define CONFIG_PHY_NATSEMI1 +# define CONFIG_PHY_REALTEK1 +# define CONFIG_PHY_VITESSE1 +#else +# undef CONFIG_MII +# undef CONFIG_CMD_MII +# undef CONFIG_PHYLIB +#endif + #endif /* __CONFIG_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] microblaze: Add faked LL_TEMAC driver configuration
Expand the specific configuration for the microblaze-generic board in xparameters.h with a faked setup to enable the LL_TEMAC driver. Note: From now the microblaze-generic board is no longer a valid board configuration for a real piece of hardware. Rather than, we use the file config.mk and xparameters.h as a faked board configuration to force the compilation of all potential driver code for Microblaze systems. Signed-off-by: Stephan Linz --- board/xilinx/microblaze-generic/config.mk |6 -- board/xilinx/microblaze-generic/xparameters.h | 12 ++-- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/board/xilinx/microblaze-generic/config.mk b/board/xilinx/microblaze-generic/config.mk index f8d7e26..9fd1015 100644 --- a/board/xilinx/microblaze-generic/config.mk +++ b/board/xilinx/microblaze-generic/config.mk @@ -21,8 +21,10 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # -# CAUTION: This file is automatically generated by libgen. -# Version: Xilinx EDK 6.3 EDK_Gmm.12.3 +# CAUTION: This file is a faked configuration !!! +# There is no real target for the microblaze-generic +# configuration. You have to replace this file with +# the generated file from your Xilinx design flow. # CONFIG_SYS_TEXT_BASE = 0x2900 diff --git a/board/xilinx/microblaze-generic/xparameters.h b/board/xilinx/microblaze-generic/xparameters.h index fae03bf..fcbd55e 100644 --- a/board/xilinx/microblaze-generic/xparameters.h +++ b/board/xilinx/microblaze-generic/xparameters.h @@ -21,8 +21,10 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, * MA 02111-1307 USA * - * CAUTION: This file is automatically generated by libgen. - * Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4 + * CAUTION: This file is a faked configuration !!! + * There is no real target for the microblaze-generic + * configuration. You have to replace this file with + * the generated file from your Xilinx design flow. */ #define XILINX_BOARD_NAME microblaze-generic @@ -69,3 +71,9 @@ /* Ethernet controller is Ethernet_MAC */ #define XILINX_EMACLITE_BASEADDR 0x40C0 + +/* Ethernet controller is Ethernet_MAC */ +#define XILINX_LLTEMAC_BASEADDR0x4400 +#define XILINX_LLTEMAC_SDMA_CTRL_BASEADDR 0x42000180 +#define XILINX_LLTEMAC_BASEADDR1 0x4440 +#define XILINX_LLTEMAC_SDMA_CTRL_BASEADDR1 0x42000200 -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] LL TEMAC v9 refactored
Back to the discussion from the last three months I have refactored the LL TEMAC driver again. The version v9 is ready to next review and testing (I hope the last one). I myself have tested it successfully on an ML605 (TEMAC hard core) and on a SP3ADSP1800 (TEMAC soft core). Thanks to Marek, Wolfgang, Andy, Mike and Michal to review v4..8. Special thanks to Ricardo. He has tested the driver v6 on a Xilinx Virtex5 FX (PPC440) platform. To use the driver on Microblaze, you will need all additional platform patches by Michal Simek and me. All related patches are bundled on patchwork: - http://patchwork.ozlabs.org/bundle/rexut/net-ll_temac/ @Michal: Please merge the patches into the custodian git tree for final testing. @Ricardo: Please could you test again the new v9 patch on your PPC440 platform. -- Best regards, Stephan Linz __ MB-Ref: http://www.li-pro.de/xilinx_mb:mbref:start OpenDCC: http://www.li-pro.net/opendcc.phtml PC/M: http://www.li-pro.net/pcm.phtml Sourceforge: http://sourceforge.net/users/slz Gitorious: https://gitorious.org/~slz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/20] tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel
Hi Stephen, On Wed, Jan 18, 2012 at 2:28 PM, Stephen Warren wrote: > On 01/11/2012 09:32 PM, Simon Glass wrote: >> This was taken from commit b48c54e2 at: >> git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git >> >> Signed-off-by: Simon Glass > >> diff --git a/board/nvidia/dts/tegra2-seaboard.dts >> b/board/nvidia/dts/tegra2-seaboard.dts > > This is also somewhat out-of-date w.r.t. the latest in kernel tag > next-20120118. It's probably not too much of an issue, so this is > probably fine to apply as-is. U-Boot may benefit from the addition of > many status="disable" properties, and clock-frequency properties for the > I2C nodes. It'd be good to keep U-Boot up-to-date with the kernel as > much as possible. Of course, there are ongoing changes being queued for > the kernel as work is done too... > OK once everything is in we can do any updates that then exist based on what is finalised in the kernel. Regards, Simon > -- > nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions
Hi Stephen,
On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren wrote:
> On 01/11/2012 09:32 PM, Simon Glass wrote:
>> This adds some support into fdtdec for reading GPIO definitions from
>> the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
>> is of the form:
>>
>> gpio-function-name = ;
>
> That's not true in general.
>
> The binding definition for the GPIO controller that provides the GPIO in
> question defines the number and meaning of all cells after the phandle
> cell. In practice, this usually does mean two cells with the meanings
> above, but there's no need for this to be true in general.
>
> For reference, the correct way to parse such a property is:
>
> * Read the first cell.
> * Find the node referenced by the phandle.
> * Ensure property gpio-controller is present in the controller node.
> * Read property #gpio-cells from the controller node.
> * Extract #gpio-cells from the original property.
> * Keep processing more cells from the original property; there may be
> multiple GPIOs listed.
>
> Still, I'll review this patch under the assumption that it's understood
> that its applicability is limited to the subset of controllers that use
> the same GPIO specifier as Tegra, i.e. that which you documented.
>
>> where:
>>
>> phandle is a pointer to the GPIO node
>> gpio_num is the number of the GPIO (0 to 223)
>> flags is a flag, as follows:
>>
>> bit meaning
>> 0 0=polarity normal, 1=active low (inverted)
>
> For reference, according to the binding documentation in the Linux
> kernel, Samsung Exynos4 doesn't use this format, and while all other
> chips do have a flags cell, about 50% of the controllers indicate the
> cell is unused.
>
>> An example is:
>>
>> gpio-enable-propounder = <&gpio 43 0>;
>
> It appears to be idiomatic to name GPIO-related properties as plural
> even when only one GPIO is expected, so e.g. "wp-gpios" for an SDHCI
> controller's write-proptect GPIO, rather than simply "wp-gpio.
OK, for both of those I will update the commit message. I have so far
been avoiding having the fdtdec library keep any state around. Looking
up a phandle and properties every time we need to decode a GPIO might
push me towards adding some sort of structure to speed decoding of the
device tree. For now we don't need it, and these functions only do
what they say they do, but it looks like at some point in the future
we might need more complexity here.
Regarding multiple GPIOs - there is a static function
fdtdec_decode_gpios() for decoding such a list which we can export as
needed later. But not everything is required to be a list. For many
GPIOs it makes no sense to have more than one, so a single GPIO is
convenient and conceptually simple for people, and easy to code.
>
> ...
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
> ...
>> +/* GPIOs are numbered from 0 */
>> +enum {
>> + FDT_GPIO_NONE = -1U, /* an invalid GPIO used to end our list */
>
> Is this due to the way U-Boot works right now, or something defined by
> this patch? It's been pointed out that the kernel's choice to use -1 as
> "invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
> fields being easily added to platform data structures, since you then
> have to go and initialize every new instance to -1, rather than relying
> on BSS initializing it to 0. I assume this is just the way U-Boot works,
> so solving this is outside the scope of this patch.
It is nothing to do with U-Boot itself - we can choose any number.
What is Linux using now / planning to use?
The number -1U is convenient because it allows us to number GPIOs from
0, which is natural for people and easier to see what is going on when
debugging. Off-by-one situations can be very confusing for people.
At present you must call fdtdec_decode_gpio() to decode a gpio
property in the node. If you don't then you can't know if anything was
there. U-Boot doesn't really have a device model yet, but if it did,
and if you wanted to add a GPIO to a core structure that the driver
used, then indeed the driver (or the code that owns the structure)
would need to call fdtdec_decode_gpio() to set it up. If it did not
then the GPIO number would be 0, which is valid.
A few things do come to mind though. First ->name is set to the
property name - if that is NULL then fdtdec_decode_gpio() has not been
called. Also we could add a 'valid' flag to the flags byte perhaps.
Perhaps in Linux a GPIO is represented just with a number, but here we
are using a structure and can fairly easily add something else to
indicate validity.
Should we try to do something about this now, or later? I am
especially interested in what Linux plans to do here.
>
> Ignoring all the above, the code looks correct to perform as documented.
Thanks for looking at it.
Regards,
Simon
>
> --
> nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/9] Stop using builtin_run_command()
Hi Simon,
Am Samstag 14 Januar 2012, 07:45:52 schrieb Simon Glass:
> diff --git a/common/cmd_source.c b/common/cmd_source.c
> index 481241c..32fff5c 100644
> --- a/common/cmd_source.c
> +++ b/common/cmd_source.c
> @@ -179,7 +179,7 @@ source (ulong addr, const char *fit_uname)
> if (*line) {
> debug ("** exec: \"%s\"\n",
> line);
> - if (builtin_run_command(line, 0) < 0)
{
> + if (run_command(line, 0) < 0) {
> rcode = 1;
> break;
> }
> @@ -189,7 +189,7 @@ source (ulong addr, const char *fit_uname)
> ++next;
> }
> if (rcode == 0 && *line)
> - rcode = (builtin_run_command(line, 0) >= 0);
> + rcode = (run_command(line, 0) >= 0);
> }
> #endif
> free (cmd);
Please have a look at this file. There is already a conditional on
CONFIG_SYS_HUSH_PARSER, which can be removed, since it is now handled in
run_command(). Do not forget to remove the hush.h include, too.
Could you move this script handling into an own function into common/main.c?
This way others can easily execute whole scripts without duplicating this
code. I'm planning to submit support for a board which needs exactly that, so
there will be at least one board which make use of this.
Mike proposed source_commands() as a function name. My original patch named it
run_script(). Dunno whats a better name.
Feel free to reuse/incorporate my patch at
http://patchwork.ozlabs.org/patch/137122/
into your patchset ;)
--
michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On 1/20/2012 9:32 PM, Olof Johansson wrote:
Hi,
On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren wrote:
Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+ the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",
+ and "osc".
Hmm. I'd prefer to just ditch the notion of "clock-names" in the cases
where it isn't strictly necessary. Just because some vendors don't want
to define an order between their clocks doesn't mean it's a good idea
for everybody to use that model. In this case, just declaring that the
two clocks refs have to be to those two clocks in that order should
be sufficient.
OK, that seems reasonable. I'm happy using of_clk_get() rather than
of_clk_get_by_name(). I guess that means we should just avoid any
discussion of clock-output-names too.
Sounds good to me. Let's make sure Grant is OK with it too though.
+- #clock-cells : Should be 1.
+ In clock consumers, this cell represents the clock ID exposed by the CAR.
+ For a list of valid values, see the clock-output-names property.
+
+Optional properties :
+- clock-output-names : Should contain a list of strings defining the clocks
+ that the CAR provides. The list of names and clock IDs is below. The IDs
+ may be used in clock specifiers. The names should be listed in this clock-
+ output-names property, sorted in ID order, if this property is present.
+
+ The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+ registers. Later, subsequent IDs will be assigned to all other clocks the
+ CAR controls.
Aren't these names hardcoded per SoC? If so, they can be derived from the
compatible field + output number without having a table in the device tree.
If anything, you might want to enumerate the allowed/expected values, but
actually putting them in a property seems overkill.
Yes, the set of clocks is hard-coded per SoC, and the clock is uniquely
identified by compatible+id.
clock-output-names doesn't actually serve any functional purpose in
Grant's common clock bindings patches; it's more of a documentation
thing. As such, yes, I can remove the suggestion to actually put the
table into the device tree, and rework the binding to simply define
what the mapping is independently.
Again, sounds good to me.
+Example:
+
+clocks {
+ clk_32k: oscillator@0 {
If it has a unit addres (@) it needs a reg property with the same base
address.
I thought everything needed a unit address period? Is the rule more like
the unit address is optional, but if present must match reg, so I can
simply remove @0 and @1 here? I guess that makes a lot more sense.
Nope, you only need a unit address to make a node unique, i.e. if you
have more than one with the same name. It's not something that's been
followed very well on ARM dts files, I have even seen review comments
asking for explicit unit IDs when none are needed.
So you can't remove @0 and @1 here, since there are two oscillator subnodes.
I'm not 100% sure if you have to have the unit address represented as
"reg" or not, but it should probably be represented by _something_ in
the properties of the node. Mitch? Segher? :)
unit-address is, by definition, the first address component of reg
+ compatible = "fixed-clock";
+ #clock-cells =<0>;
+ clock-frequency =<32768>;
+ };
+
+ osc: oscillator@1 {
+ compatible = "fixed-clock";
+ #clock-cells =<0>;
+ clock-frequency =<1200>;
+ };
+};
-Olof
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request: u-boot-tegra/master
Hi Tom, Le 19/01/2012 01:01, Tom Warren a écrit : Albert, Please pull u-boot-tegra/master into arm master. Thanks. The following changes since commit 137703b811502dfea364650fb3e17f20b4c21333: overo: add SPL support (2012-01-16 08:40:13 +0100) are available in the git repository at: git://git.denx.de/u-boot-tegra master Simon Glass (9): tegra: Adjust funcmux config test to permit expansion tegra: Add enum to select from available funcmux configs tegra: Add I2C support to funcmux tegra: Add SDMMC support to funcmux tegra: Use funcmux for MMC on tamonten tegra: Use funcmux for MMC on harmony tegra: Use funcmux for MMC on seaboard tegra: mmc: Support operation with dcache enabled tegra2: Enable data cache Stephen Warren (3): tegra2: Fix conflicting pinmux for UARTA tegra2: Fix default RAM size selection in odmdata tegra2: Add support for Compal Paz00 (Toshiba AC100) MAINTAINERS|1 + arch/arm/cpu/armv7/tegra2/board.c | 12 ++- arch/arm/cpu/armv7/tegra2/funcmux.c| 152 +--- arch/arm/include/asm/arch-tegra2/funcmux.h | 30 ++- board/avionic-design/common/tamonten.c | 10 +-- board/compal/paz00/Makefile| 41 board/compal/paz00/paz00.c | 81 +++ board/nvidia/harmony/harmony.c | 19 +--- board/nvidia/seaboard/seaboard.c | 21 +--- boards.cfg |1 + drivers/mmc/tegra2_mmc.c | 16 +++ include/configs/paz00.h| 51 + 12 files changed, 379 insertions(+), 56 deletions(-) create mode 100644 board/compal/paz00/Makefile create mode 100644 board/compal/paz00/paz00.c create mode 100644 include/configs/paz00.h Applied to u-boot-arm/master, thanks! Would it be possible, though, not to have this in your mails to the list? --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
