Re: [U-Boot] [PATCH] Correct call to eth_write_hwaddr()
Hello Simon, Simon Glass wrote: > This fixes "Warning: failed to set MAC address" on platforms which rely on > an 'ethaddr' environment variable to set the MAC address. > > This bug was introduced by this commit: > > 7616e785 Add Ethernet hardware MAC address framework to usbnet > > Signed-off-by: Simon Glass > --- > net/eth.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > Tested on a davinci am1808 based board, so Tested-by: Heiko Schocher Thanks for fixing this! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fix warning not initializing MAC address
Hello Kumar,
Kumar Gala wrote:
> On Sep 2, 2011, at 12:55 AM, Heiko Schocher wrote:
>
>> following warning message blobs up, when initializing for example
>> DaVinci EMAC:
>>
>> Net: Ethernet PHY: KSZ8873 @ 0x02
>> DaVinci-EMACWarning: failed to set MAC address
>>
>> Introduced from commit
>>
>> commit 7616e7850804c7c69e0a22c179dfcba9e8f3f587
>> Author: Simon Glass
>> Date: Mon Jun 13 16:13:10 2011 -0700
>>
>>Add Ethernet hardware MAC address framework to usbnet
>>
>>Built-in Ethernet adapters support setting the mac address by means of a
>>ethaddr environment variable for each interface (ethaddr, eth1addr,
>> eth2addr).
>>
>>This adds similar support to the USB network side, using the names
>>usbethaddr, usbeth1addr, etc. They are kept separate since we don't want
>>a USB device taking the MAC address of a built-in device or vice versa.
>>
>>Signed-off-by: Simon Glass
>>Tested-by: Eric Bénard
>>
>> Fix this!
>>
>> Signed-off-by: Heiko Schocher
>> cc: Simon Glass
>> ---
>> net/eth.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/eth.c b/net/eth.c
>> index a34fe59..2caaf60 100644
>> --- a/net/eth.c
>> +++ b/net/eth.c
>> @@ -296,7 +296,7 @@ int eth_initialize(bd_t *bis)
>> if (strchr(dev->name, ' '))
>> puts("\nWarning: eth device name has a
>> space!\n");
>>
>> -if (eth_write_hwaddr(dev, NULL, eth_number))
>> +if (eth_write_hwaddr(dev, "eth", eth_number))
>> puts("Warning: failed to set MAC address\n");
>>
>> eth_number++;
>> --
>> 1.7.6
>
> We keep fixing this one ;)
>
> http://patchwork.ozlabs.org/patch/112361/
Good!
(Sorry for posting another fix, but just back from vacation, and
didn;t found time for looking in the u-boot ml ... :-(
Thanks for the hint!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] MX25: tx25: Avoid the usage of extern in C file
On 08/30/2011 02:20 PM, Fabio Estevam wrote: > Avoid the usage of extern in C file as pointed out by checkpatch. > > Signed-off-by: Fabio Estevam > --- Applied to u-boot-imx, as a fix, thanks. 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] MX25: tx25: Cleanup tx25.h config
On 08/30/2011 05:44 PM, Fabio Estevam wrote: > Cleanup tx25.h by removing unnecessary defines and by removing unneeded "1"'s. > > Signed-off-by: Fabio Estevam > --- > include/configs/tx25.h | 14 ++ > 1 files changed, 6 insertions(+), 8 deletions(-) > Applied to u-boot-imx (fix), thanks. 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 v2 1/2] MX25: tx25: Avoid the usage of extern in C file
On 09/02/2011 09:14 AM, Stefano Babic wrote: > On 08/30/2011 02:20 PM, Fabio Estevam wrote: >> Avoid the usage of extern in C file as pointed out by checkpatch. >> >> Signed-off-by: Fabio Estevam >> --- > Hi Fabio, > Applied to u-boot-imx, as a fix, thanks. Sorry, it is not. Your patch introduces warnings for the tx25 board: Configuring for tx25 board... tx25.c: In function 'board_init': tx25.c:145: warning: implicit declaration of function 'mx25_uart1_init_pins' 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 1/2] ARM: mx25: Print the silicon revison
On 08/30/2011 03:54 PM, Fabio Estevam wrote:
> Print the silicon revison during boot.
>
> Signed-off-by: Fabio Estevam
> ---
Hi Fabio,
>
> +
> +u32 get_cpu_rev(void)
> +{
> + u32 srev;
> + u32 system_rev = 0x25000;
> +
> + /* read SREV register from IIM module */
> + struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
> + srev = readl(&iim->iim_srev);
> +
> + switch (srev) {
> + case 0x00:
> + system_rev |= CHIP_REV_1_0;
> + break;
> + case 0x01:
> + system_rev |= CHIP_REV_1_1;
> + break;
> + default:
> + system_rev |= CHIP_REV_UNKNOWN;
> + break;
> + }
> +
> + return system_rev;
> +}
> +
> #if defined(CONFIG_DISPLAY_CPUINFO)
> int print_cpuinfo (void)
> {
> char buf[32];
> + u32 cpurev;
> +
> + cpurev = get_cpu_rev();
>
> - printf ("CPU: Freescale i.MX25 at %s MHz\n\n",
> + printf("CPU: Freescale i.MX25 rev%d.%d at %s MHz\n\n",
> + (cpurev & 0x000F0) >> 4,
> + (cpurev & 0xF) >> 0,
I see that we did different for other i.MX processor - if you check in
the MX31 processor, we print the "unknown" string if the revision number
does not match a known value instead of printing an arbitrary value as
here. Can we stick with the same behavior ?
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 2/2] ARM: mx25: Print the source of reset
On 08/30/2011 03:54 PM, Fabio Estevam wrote:
> Print the source of reset during boot.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/cpu/arm926ejs/mx25/generic.c | 25 -
> 1 files changed, 24 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
> b/arch/arm/cpu/arm926ejs/mx25/generic.c
> index a4e8c14..047e49d 100644
> --- a/arch/arm/cpu/arm926ejs/mx25/generic.c
> +++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
> @@ -130,6 +130,28 @@ u32 get_cpu_rev(void)
> return system_rev;
> }
>
> +static char *get_reset_cause(void)
> +{
> + /* read RCSR register from CCM module */
> + struct ccm_regs *ccm =
> + (struct ccm_regs *)IMX_CCM_BASE;
> +
> + u32 cause = readl(&ccm->rcsr) & 0x0f;
> +
> + switch (cause) {
> + case 0x:
> + return "POR";
> + case 0x0001:
> + return "RST";
> + case 0x0002:
> + return "WDOG";
> + case 0x0006:
> + return "JTAG";
> + default:
> + return "unknown reset";
> + }
> +}
Can you help me interpreting the manual ? I see in MX25 RM:
REST
Reset status bits. Shows what caused the most recent reset to the
system.Otherwise, the last signal that
is released is honored.
POR reset
0001 Reset In reset.
xx10 WDOG reset
x1x0 SOFT RESET
1xx0 JTAG SW RESET
The code for JTAG seems wrong, should be at 0x08. It sounds me odd that
some bits are not fixed. According to the manual, we should check the
single bits, becase for example a WDOG reset can be identified not only
by 0x02, but also by 0x06, 0x0a, 0x0E..
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 1/5] coldfire: Change timer_init return type from void to int
Dear Mike Frysinger, In message <20110830.00896.vap...@gentoo.org> you wrote: > ... > you should have gotten a build error as the prototype is in common.h. so=20 > please add an include for common.h to this file. ... > drop the extern and include common.h ... When requesting changes to a patch, can you (and everybody else!) *** P L E A S E *** update the patch state in Patchworks to "Changes requested" ? 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 The only person who always got his work done by Friday was Robinson Crusoe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-samsung/master
Dear Albert ARIBAUD, The following changes since commit 5a70b8d8cc8481f7b25e2fcab98c4b9fb24907cf: Tegra2: Use clock and pinmux functions to simplify code (2011-08-30 18:45:54 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master Chander Kashyap (2): ARMV7: Add support for Samsung ORIGEN board ORIGEN: Add MMC SPL support Łukasz Majewski (2): i2c:gpio:s5p: I2C GPIO Software implementation (via soft_i2c) i2c:gpio:s5p: Enable I2C GPIO on the GONI target MAINTAINERS |1 + arch/arm/include/asm/arch-s5pc1xx/gpio.h | 13 + arch/arm/include/asm/arch-s5pc2xx/gpio.h | 29 ++ board/samsung/origen/Makefile | 64 board/samsung/origen/lowlevel_init.S | 357 +++ board/samsung/origen/mem_setup.S | 421 ++ board/samsung/origen/mmc_boot.c | 58 +++ board/samsung/origen/origen.c | 109 ++ board/samsung/origen/origen_setup.h | 546 + board/samsung/origen/tools/mkv310_image.c | 126 +++ boards.cfg|1 + drivers/gpio/s5p_gpio.c | 44 +++ include/configs/origen.h | 168 + include/configs/s5p_goni.h| 12 + spl/Makefile | 10 + 15 files changed, 1959 insertions(+), 0 deletions(-) create mode 100644 board/samsung/origen/Makefile create mode 100644 board/samsung/origen/lowlevel_init.S create mode 100644 board/samsung/origen/mem_setup.S create mode 100644 board/samsung/origen/mmc_boot.c create mode 100644 board/samsung/origen/origen.c create mode 100644 board/samsung/origen/origen_setup.h create mode 100644 board/samsung/origen/tools/mkv310_image.c create mode 100644 include/configs/origen.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] s5p-mmc: Fix ambiguous setting of data transfer width
Dear Wolfgang Denk, On 1 September 2011 14:51, Wolfgang Denk wrote: > Dear Minkyu Kang, > > In message > you > wrote: >> >> > I know these were like this before, but those numbers are awfully >> > magical. You should really define constants for them. >> >> We decided to use comments instead of defines. > > And now we ask you to fix this, because we don;t want such magic > constants. So please go on and change this. > OK. Thanks. Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Michal Simek,
In message <4e607a0b.3040...@monstr.eu> you wrote:
>
> +static void sdma_out_be32(struct ll_priv *priv, u32 offset, u32 val)
> +{
> +if (priv->mode & DCR_BIT)
> +mtdcr_local(priv->ctrl + offset, val);
> +else
> +out_be32((u32 *)(priv->ctrl + offset * 4), val);
> +}
...
> On PPC system with DCR is special connection between memory controller
> through DCR bus. Handling is done
> with mfdcr_local and mtdcr_local functions.
>
> DMA : Sdma address ranges
> (www.xilinx.com/support/documentation/user_guides/ug200.pdf page 261 and 299)
> 0 : 0x80-0x90
> 1 : 0x98-0xA8
> 2 : 0xB0-0xC0
> 3 : 0xC8-0xD8
>
> The first reg for DMA2 accessed trough DCR is at 0xB0, the second at 0xB1,
> etc..
This is indeed a good example, as it shows how terribly broken your
code is.
See function sdma_out_be32() above. It is suppose to write a 32 bit
value ("u32 val") as a 32 bit entity in big endian mode ("_be32") to
some device register - but the register addresses are (1) not aligned
to 32 bit boundaries and (2) not even 32 bits apart.
Oh! You are NOT writing 32 bit data? You are writing only 8 bit?
But the function claims to be writing 32 bit!!!
And your function mtdcr_local() is actually a NOOP for anything but
PPC? Without even a warning?
This code is obfuscated in multiple levels.
I will not accept that.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What is tolerance? -- it is the consequence of humanity. We are all
formed of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature. - Voltaire
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: ll_temac: Add LL TEMAC driver to u-boot
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <4e607a0b.3040...@monstr.eu> you wrote:
>> +static void sdma_out_be32(struct ll_priv *priv, u32 offset, u32 val)
>> +{
>> +if (priv->mode & DCR_BIT)
>> +mtdcr_local(priv->ctrl + offset, val);
>> +else
>> +out_be32((u32 *)(priv->ctrl + offset * 4), val);
>> +}
> ...
>> On PPC system with DCR is special connection between memory controller
>> through DCR bus. Handling is done
>> with mfdcr_local and mtdcr_local functions.
>>
>> DMA : Sdma address ranges
>> (www.xilinx.com/support/documentation/user_guides/ug200.pdf page 261 and 299)
>> 0 : 0x80-0x90
>> 1 : 0x98-0xA8
>> 2 : 0xB0-0xC0
>> 3 : 0xC8-0xD8
>>
>> The first reg for DMA2 accessed trough DCR is at 0xB0, the second at 0xB1,
>> etc..
>
> This is indeed a good example, as it shows how terribly broken your
> code is.
>
> See function sdma_out_be32() above. It is suppose to write a 32 bit
> value ("u32 val") as a 32 bit entity in big endian mode ("_be32") to
> some device register - but the register addresses are (1) not aligned
> to 32 bit boundaries and (2) not even 32 bits apart.
I think you misunderstand what there is written.
For DCR is register address with offset + 0x1 but still you are writing there
32bit values. It is not direct access.
and it is not any unaligned access at all. But bus access it will be unaligned
access but not for DCR.
DCR is defined just for PPC right now because none wanted to do it for
Microblaze.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] new tool mkenvimage: generates an env image from an arbitrary config file
This tool takes a key=value configuration file (same as would a `printenv' show)
and generates the corresponding environment image, ready to be flashed.
use case: flash the environment with an external tool
Signed-off-by: David Wagner
---
changes since v5
- fix reading from stdin
- remove an obsolete TODO
tools/Makefile |5 +
tools/mkenvimage.c | 270
2 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 tools/mkenvimage.c
diff --git a/tools/Makefile b/tools/Makefile
index fc741d3..da7caf0 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -66,6 +66,7 @@ BIN_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc$(SFX)
BIN_FILES-$(CONFIG_CMD_NET) += gen_eth_addr$(SFX)
BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX)
BIN_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes$(SFX)
+BIN_FILES-y += mkenvimage$(SFX)
BIN_FILES-y += mkimage$(SFX)
BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
@@ -89,6 +90,7 @@ OBJ_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes.o
NOPED_OBJ_FILES-y += kwbimage.o
NOPED_OBJ_FILES-y += imximage.o
NOPED_OBJ_FILES-y += omapimage.o
+NOPED_OBJ_FILES-y += mkenvimage.o
NOPED_OBJ_FILES-y += mkimage.o
OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
NOPED_OBJ_FILES-y += os_support.o
@@ -184,6 +186,9 @@ $(obj)xway-swap-bytes$(SFX):$(obj)xway-swap-bytes.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
+$(obj)mkenvimage$(SFX):$(obj)crc32.o $(obj)mkenvimage.o
+ $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
+
$(obj)mkimage$(SFX): $(obj)crc32.o \
$(obj)default_image.o \
$(obj)fit_image.o \
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
new file mode 100644
index 000..c2636fd
--- /dev/null
+++ b/tools/mkenvimage.c
@@ -0,0 +1,270 @@
+/*
+ * (C) Copyright 2011 Free Electrons
+ * David Wagner
+ *
+ * Inspired from envcrc.c:
+ * (C) Copyright 2001
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define CRC_SIZE sizeof(uint32_t)
+
+static void usage(const char *exec_name)
+{
+ fprintf(stderr, "%s [-h] [-r] [-b] [-p ] "
+ "-s -o \n"
+ "\n"
+ "This tool takes a key=value input file (same as would a "
+ "`printenv' show) and generates the corresponding environment "
+ "image, ready to be flashed.\n"
+ "\n"
+ "\tThe input file is in format:\n"
+ "\t\tkey1=value1\n"
+ "\t\tkey2=value2\n"
+ "\t\t...\n"
+ "\t-r : the environment has multiple copies in flash\n"
+ "\t-b : the target is big endian (default is little endian)\n"
+ "\t-p : fill the image with bytes instead of "
+ "0xff bytes\n"
+ "\n"
+ "If the input file is \"-\", data is read from standard input\n",
+ exec_name);
+}
+
+int main(int argc, char **argv)
+{
+ uint32_t crc, targetendian_crc;
+ const char *txt_filename = NULL, *bin_filename = NULL;
+ int txt_fd, bin_fd;
+ unsigned char *dataptr, *envptr;
+ unsigned char *filebuf = NULL;
+ unsigned int filesize = 0, envsize = 0, datasize = 0;
+ int bigendian = 0;
+ int redundant = 0;
+ unsigned char padbyte = 0xff;
+
+ int option;
+ int ret = EXIT_SUCCESS;
+
+ struct stat txt_file_stat;
+
+ int fp, ep;
+
+ /* Parse the cmdline */
+ while ((option = getopt(argc, argv, "s:o:rbp:h")) != -1) {
+ switch (option) {
+ case 's':
+ datasize = strtol(optarg, NULL, 0);
+ break;
+ case 'o':
+ bin_filename = strdup(optarg);
+ if (!bin_filename) {
+ fprintf(stderr, "Can't strdup() the output "
+
[U-Boot] [PATCHv6] new tool mkenvimage: generates an env image from an arbitrary config file
This tool takes a key=value configuration file (same as would a `printenv' show)
and generates the corresponding environment image, ready to be flashed.
use case: flash the environment with an external tool
Signed-off-by: David Wagner
---
changes since v5
- fix reading from stdin
- remove an obsolete TODO
tools/Makefile |5 +
tools/mkenvimage.c | 270
2 files changed, 275 insertions(+), 0 deletions(-)
create mode 100644 tools/mkenvimage.c
diff --git a/tools/Makefile b/tools/Makefile
index fc741d3..da7caf0 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -66,6 +66,7 @@ BIN_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc$(SFX)
BIN_FILES-$(CONFIG_CMD_NET) += gen_eth_addr$(SFX)
BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX)
BIN_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes$(SFX)
+BIN_FILES-y += mkenvimage$(SFX)
BIN_FILES-y += mkimage$(SFX)
BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
@@ -89,6 +90,7 @@ OBJ_FILES-$(CONFIG_XWAY_SWAP_BYTES) += xway-swap-bytes.o
NOPED_OBJ_FILES-y += kwbimage.o
NOPED_OBJ_FILES-y += imximage.o
NOPED_OBJ_FILES-y += omapimage.o
+NOPED_OBJ_FILES-y += mkenvimage.o
NOPED_OBJ_FILES-y += mkimage.o
OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
NOPED_OBJ_FILES-y += os_support.o
@@ -184,6 +186,9 @@ $(obj)xway-swap-bytes$(SFX):$(obj)xway-swap-bytes.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
+$(obj)mkenvimage$(SFX):$(obj)crc32.o $(obj)mkenvimage.o
+ $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
+
$(obj)mkimage$(SFX): $(obj)crc32.o \
$(obj)default_image.o \
$(obj)fit_image.o \
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
new file mode 100644
index 000..c2636fd
--- /dev/null
+++ b/tools/mkenvimage.c
@@ -0,0 +1,270 @@
+/*
+ * (C) Copyright 2011 Free Electrons
+ * David Wagner
+ *
+ * Inspired from envcrc.c:
+ * (C) Copyright 2001
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define CRC_SIZE sizeof(uint32_t)
+
+static void usage(const char *exec_name)
+{
+ fprintf(stderr, "%s [-h] [-r] [-b] [-p ] "
+ "-s -o \n"
+ "\n"
+ "This tool takes a key=value input file (same as would a "
+ "`printenv' show) and generates the corresponding environment "
+ "image, ready to be flashed.\n"
+ "\n"
+ "\tThe input file is in format:\n"
+ "\t\tkey1=value1\n"
+ "\t\tkey2=value2\n"
+ "\t\t...\n"
+ "\t-r : the environment has multiple copies in flash\n"
+ "\t-b : the target is big endian (default is little endian)\n"
+ "\t-p : fill the image with bytes instead of "
+ "0xff bytes\n"
+ "\n"
+ "If the input file is \"-\", data is read from standard input\n",
+ exec_name);
+}
+
+int main(int argc, char **argv)
+{
+ uint32_t crc, targetendian_crc;
+ const char *txt_filename = NULL, *bin_filename = NULL;
+ int txt_fd, bin_fd;
+ unsigned char *dataptr, *envptr;
+ unsigned char *filebuf = NULL;
+ unsigned int filesize = 0, envsize = 0, datasize = 0;
+ int bigendian = 0;
+ int redundant = 0;
+ unsigned char padbyte = 0xff;
+
+ int option;
+ int ret = EXIT_SUCCESS;
+
+ struct stat txt_file_stat;
+
+ int fp, ep;
+
+ /* Parse the cmdline */
+ while ((option = getopt(argc, argv, "s:o:rbp:h")) != -1) {
+ switch (option) {
+ case 's':
+ datasize = strtol(optarg, NULL, 0);
+ break;
+ case 'o':
+ bin_filename = strdup(optarg);
+ if (!bin_filename) {
+ fprintf(stderr, "Can't strdup() the output "
+
Re: [U-Boot] [PATCH] new tool mkenvimage: generates an env image from an arbitrary config file
oops, subject is missing "v6". I just resent a correct version. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] ns16550: change to allow 32 bit access to registers
If CONFIG_SYS_NS16550_MEM32 is defined then 32 bit memory mapped access will be used to read/write the uart registers. This is especially useful for SoC devices that implement 16550 compatible uarts but that have peripheral access width constraints. Signed-off-by: Dave Aldridge --- Changes for v2: - Add endian support Changes for v3: - Use in_be32()/out_be32() and in_le32/out_le32() functions to provide endian support Changes for v4: - use u32 instead of unsigned int in include/ns16550.h to remove any ambiguity about the register size drivers/serial/ns16550.c |6 ++ include/ns16550.h|4 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 8eeb48f..0174744 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -19,6 +19,12 @@ #ifdef CONFIG_SYS_NS16550_PORT_MAPPED #define serial_out(x,y)outb(x,(ulong)y) #define serial_in(y) inb((ulong)y) +#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE > 0) +#define serial_out(x,y) out_be32(y,x) +#define serial_in(y) in_be32(y) +#elif defined(CONFIG_SYS_NS16550_MEM32) && (CONFIG_SYS_NS16550_REG_SIZE < 0) +#define serial_out(x,y) out_le32(y,x) +#define serial_in(y) in_le32(y) #else #define serial_out(x,y) writeb(x,y) #define serial_in(y) readb(y) diff --git a/include/ns16550.h b/include/ns16550.h index 9ea81e9..51f1c17 100644 --- a/include/ns16550.h +++ b/include/ns16550.h @@ -21,8 +21,12 @@ * will not allocate storage for arrays of size 0 */ +#include + #if !defined(CONFIG_SYS_NS16550_REG_SIZE) || (CONFIG_SYS_NS16550_REG_SIZE == 0) #error "Please define NS16550 registers size." +#elif defined(CONFIG_SYS_NS16550_MEM32) +#define UART_REG(x) u32 x #elif (CONFIG_SYS_NS16550_REG_SIZE > 0) #define UART_REG(x) \ unsigned char prepad_##x[CONFIG_SYS_NS16550_REG_SIZE - 1]; \ -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot with gcov / gprof?
Hi, I've not used that - but have used -finstrument-functions which works fairly well. The difficulty is figuring out what to do during the extra calls it generates. Thanks, Andrew Murray On 2 September 2011 05:06, Simon Glass wrote: > Hi, > > Has anyone got a profiling tool running with U-Boot? I can't see a > mention of it in the lists but thought I should ask. > > I would like to get something running. > > Regards, > Simon > ___ > 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 v2] net: axi_ethernet: Add driver to u-boot
Dear Wolfgang Denk,
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <1314877154-14536-2-git-send-email-mon...@monstr.eu> you wrote:
>> Add axi_ethernet driver for little-endian Microblaze.
>>
>> RX/TX BDs and rxframe buffer are shared among all axi_ethernet MACs.
>> Only one MAC can work in one time.
>>
>> Signed-off-by: Michal Simek
>
>> +/* Mask used to verify certain PHY features (or register contents)
>> + * in the register above:
>> + * 0x1000: 10Mbps full duplex support
>> + * 0x0800: 10Mbps half duplex support
>> + * 0x0008: Auto-negotiation support
>> + */
>
> Incorrect multiline comment style. Please fix globally.
Fixed.
>
>
>> +u32 timeout = 200;
>> +/* Wait till MDIO interface is ready to accept a new transaction. */
>> +while (timeout && (!(in_be32(®s->mdio_mcr)
>> +& XAE_MDIO_MCR_READY_MASK)))
>> +timeout--;
>
> Multiline statement - braches needed.
>
> Also, add some udelay() or similar to have a defined length of the
> timeout. Please fix globally.
Fixed.
>
>
>> +/* STOP DMA transfers */
>> +static void axiemac_halt(struct eth_device *dev)
>> +{
>> +struct axidma_priv *priv = dev->priv;
>> +
>> +/* Stop the hardware */
>> +priv->dmatx->control &= ~XAXIDMA_CR_RUNSTOP_MASK;
>> +priv->dmarx->control &= ~XAXIDMA_CR_RUNSTOP_MASK;
>
> Please ALWAYS use I/O accessors to access device registers. Please
> fix globally.
Done
>
>> +static int IsRxReady(struct eth_device *dev)
>
> As requested before: Please get rid of these CamelCaps identifiers!!!
Fixed this.
>
>
>> +static int axiemac_miiphy_read(const char *devname, uchar addr,
>> +uchar reg, ushort *val)
>> +{
>> +struct eth_device *dev = eth_get_dev();
>> +*val = phyread(dev, addr, reg);
>> +debug("axiemac: Read MII 0x%x, 0x%x, 0x%x\n", addr, reg, *val);
>> +return 0;
>
> Please separate declarations and code by a single blank line. Please
> fix globally.
Done
>
>
> Why does this function return int when you uncondsitionally always
> return 0 only?
I have fixed phywrite/phyread functions.
>
>> +}
>> +
>> +static int axiemac_miiphy_write(const char *devname, uchar addr,
>> +uchar reg, ushort val)
>> +{
>> +struct eth_device *dev = eth_get_dev();
>> +debug("axiemac: Write MII 0x%x, 0x%x, 0x%x\n", addr, reg, val);
>> +phywrite(dev, addr, reg, val);
>> +return 0;
>> +}
>
> Ditto.
>
>> +static int axiemac_bus_reset(struct mii_dev *bus)
>> +{
>> +debug("axiemac: Bus reset\n");
>> +return 0;
>> +}
>
> Ditto.
Because of miiphyutil code requires to return 0 and I am not aware about
doing anything useful for bus_reset.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Michal Simek,
In message <4e609682.8030...@monstr.eu> you wrote:
>
> >> +static void sdma_out_be32(struct ll_priv *priv, u32 offset, u32 val)
> >> +{
> >> + if (priv->mode & DCR_BIT)
> >> + mtdcr_local(priv->ctrl + offset, val);
> >> + else
> >> + out_be32((u32 *)(priv->ctrl + offset * 4), val);
> >> +}
> > ...
...
> >> The first reg for DMA2 accessed trough DCR is at 0xB0, the second at 0xB1,
> >> etc..
> >
> > This is indeed a good example, as it shows how terribly broken your
> > code is.
> >
> > See function sdma_out_be32() above. It is suppose to write a 32 bit
> > value ("u32 val") as a 32 bit entity in big endian mode ("_be32") to
> > some device register - but the register addresses are (1) not aligned
> > to 32 bit boundaries and (2) not even 32 bits apart.
>
> I think you misunderstand what there is written.
Maybe. Maybe even I want to misunderstand it. The problem is that
the code does not prevent such misunderstanding.
There are many shortcomings of that code.
> DCR is defined just for PPC right now because none wanted to do it for
> Microblaze.
Actually even this is incorrect - AFAIK Device Control Registers (DCR)
exist not on all PPC systems, but only on 4xx (and even there only on
some models). So your code works on a few systems, silently does not
do anything on others, and crashes on yet others with an illegal
instruction.
How do you call code that exposes such behaviour?
I don't want to have this in mainline.
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 hit a man when he's down - kick him; it's easier.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net: Check network device driver name
Mike Frysinger wrote:
> On Tuesday, August 30, 2011 05:30:13 Michal Simek wrote:
>> --- a/net/eth.c
>> +++ b/net/eth.c
>> @@ -224,6 +224,14 @@ int eth_write_hwaddr(struct eth_device *dev, const
>> char *base_name, int eth_register(struct eth_device *dev)
>> {
>> struct eth_device *d;
>> +
>> +size_t len = strlen(dev->name);
>> +if (len >= NAMESIZE) {
>> +printf("Network driver name is too long (%zu >= %zu): %s\n",
>> +len, NAMESIZE, dev->name);
>> +return -1;
>> +}
>
> thinking a little more, i wonder if this wouldnt be better as an assert() or
> BUG_ON(). this isnt a normal issue and generally gets caught once -- during
> development of a new board.
Just during development. Not sure if possible to do configuration run-time
through
custom command. If yes then it can be useful too.
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v3] ARM: ARM926EJS - Add cache operations
Hi Hong, On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote: > Hi Marek, > > On 08/11/2011 12:47 PM, Marek Vasut wrote: > > On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: > >> Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations > >> into this file. > >> > >> Signed-off-by: Hong Xu > >> --- > >> V2: > >>Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined > >> V3: > >>Undo changes in include/configs/at91sam9260ek.h > >>It's for testing purpose > >> > >> arch/arm/cpu/arm926ejs/Makefile |2 +- > >> arch/arm/cpu/arm926ejs/cache.c | 142 > >> +++ 2 files changed, 143 > >> insertions(+), 1 deletions(-) > >> create mode 100644 arch/arm/cpu/arm926ejs/cache.c What is the status for this patch ? I have failed to find any trace for this patch in patchwork or in the arm git repository... Regards, Simon signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v3] ARM: ARM926EJS - Add cache operations
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote: > Hi Hong, > > On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote: > > Hi Marek, > > > > On 08/11/2011 12:47 PM, Marek Vasut wrote: > > > On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: > > >> Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations > > >> into this file. > > >> > > >> Signed-off-by: Hong Xu > > >> --- > > >> > > >> V2: > > >> Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined > > >> > > >> V3: > > >> Undo changes in include/configs/at91sam9260ek.h > > >> It's for testing purpose > > >> > > >> arch/arm/cpu/arm926ejs/Makefile |2 +- > > >> arch/arm/cpu/arm926ejs/cache.c | 142 > > >> > > >> +++ 2 files changed, 143 > > >> insertions(+), 1 deletions(-) > > >> > > >> create mode 100644 arch/arm/cpu/arm926ejs/cache.c > > What is the status for this patch ? > > I have failed to find any trace for this patch in patchwork or in the > arm git repository... We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline! Cheers > > Regards, > > Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Good news?! China Daily Europe advertising - Two-for-One expiring 15th Sept
Hi there We thought you might be interested to know that the TWO-FOR-ONE advertising offer for China Daily Europe Edition (weekly) has been reinstated briefly and is finishing on 15th Sept 2011 (original details below). This £2500.00 offer gives you exposure to the entire AB1 distribution in two weekly hard copy editions of your choice, and exposure at the heavily trafficked China Daily Online for the duration of your entries, with clickthroughs/tracking. Usual list price for this package is £5500.00 fyi, and it will enable you to receive enquiries for your products and services from the Chinese and Euro-Chinese marketplaces with excellent ROI. In addition, the first five to accept are receiving a free web banner without charge! Can this fit into budget? Simply reply with the word 'BOOK!' and we will get back to you before the offer deadline cutoff. We think you'll be glad you did! Best wishes, Chris Brown @ SKS for China Daily Europe / +44 (0) 203 286 9737 W: http://europe.chinadaily.com.cn/ **original email Hi there How are you doing? Getting into summertime now? :)) Good news, I think?! As you might recall, your organisation has been invited to advertise in China Daily Europe Edition (weekly). We now have ten two-for-one offers to send out on a first-come-first-served basis, and we thought we would send you one of them! For China Daily European Edition (weekly, in English), it's usually £2500.00 for the full tabloid size ad page, full colour, BUT you can have two of these included when you book before 7th July (although the editions in which you appear can be later in the year at any time). This offer also includes the online edition in the European area at the site which gets 2.5 million unique business users per week, thus perfect for you to reach the C-level subscribers and senior executives interested in China, and vice-versa, for your business development, direct sales and branding! To take advantage of this limited time Two-for-One offer, please simply reply to this email with the word "BOOK!", and we'll be delighted to welcome you aboard by return before 7th July! Interested?! Best wishes, Chris Brown @ SKS for China Daily Europe T: +44 (0) 203 286 8737 ddi / or via accts team +44 (0) 207 607 0717 ddi W: http://europe.chinadaily.com.cn/ Downloads: for CDEW: China Daily Europe Flyer (weekly) - http://www.sksassociates.co.uk/cd/ChinaDailyEuropeanWeeklyMediaFlyerJune2011.pdf China Daily Europe - airline distribution - http://www.sksassociates.co.uk/cd/ChinaDailyEuropeanWeekly-airlines.xls China Daily Europe - hotel distribution - http://www.sksassociates.co.uk/cd/ChinaDailyEuropeanWeekly-hotels.xls China Daily Europe - corporate receptions distribution - http://www.sksassociates.co.uk/cd/ChinaDailyEuropeanWeekly-corporates.xls and for China: China Daily China Edition (daily) - http://www.sksassociates.co.uk/cd/2011ChinaDailyChinaADRATE.pdf China Daily website - http://www.sksassociates.co.uk/cd/2011ChinaDailyWebsiteMediaKit.pdf Contracted by: SKS/Enhanced Media & Communications Ltd 1 Farnham Road, Guildford, Surrey GU2 4RG UK "Bringing the top drawer to you!" <>___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Wolfgang Denk,
Wolfgang Denk wrote:
> Dear Michal Simek,
>
> In message <4e609682.8030...@monstr.eu> you wrote:
+static void sdma_out_be32(struct ll_priv *priv, u32 offset, u32 val)
+{
+ if (priv->mode & DCR_BIT)
+ mtdcr_local(priv->ctrl + offset, val);
+ else
+ out_be32((u32 *)(priv->ctrl + offset * 4), val);
+}
>>> ...
> ...
The first reg for DMA2 accessed trough DCR is at 0xB0, the second at 0xB1,
etc..
>>> This is indeed a good example, as it shows how terribly broken your
>>> code is.
>>>
>>> See function sdma_out_be32() above. It is suppose to write a 32 bit
>>> value ("u32 val") as a 32 bit entity in big endian mode ("_be32") to
>>> some device register - but the register addresses are (1) not aligned
>>> to 32 bit boundaries and (2) not even 32 bits apart.
>> I think you misunderstand what there is written.
>
> Maybe. Maybe even I want to misunderstand it. The problem is that
> the code does not prevent such misunderstanding.
>
> There are many shortcomings of that code.
I think that this is the reason why we have review process, don't we?
Especially this driver is 2-3 years old and it is used by many our customers.
It is only my effort to clear xilinx drivers/platforms.
As I see there is still ugly board/xilinx/common folder and ancient enet driver
and i2c
driver.
>
>> DCR is defined just for PPC right now because none wanted to do it for
>> Microblaze.
>
> Actually even this is incorrect - AFAIK Device Control Registers (DCR)
> exist not on all PPC systems, but only on 4xx (and even there only on
> some models). So your code works on a few systems, silently does not
> do anything on others, and crashes on yet others with an illegal
> instruction.
That driver is not definitely for all ppc systems. That IP is available just for
Xilinx FPGA where can be possible to use it with Microblaze and xilinx ppc440
(maybe ppc405).
That DCR handling, which is implemented in this driver, fits to xilinx ppc440
implementation.
Which means that none can add this IP to any other PPC system out of Xilinx
FPGA.
>
> How do you call code that exposes such behaviour?
If I look at drivers/net folder there are a lot of examples like that.
None expect that altera_tse/bfin_mac/tsec will be possible to use with all
systems.
Maybe you expect that they can be use on the same architecture but this is
Xilinx FPGA.
It is up to you how you want to compose your system.
IRC tsec is used just for Freescale PPC and this ll_temac driver is just used
for xilinx microblaze
and xilinx ppc.
Sorry I can't see any problem to have driver for specific platform or even to
have one driver
which supports two completely different platform.
I saw that there are some drivers in arch// folders but this is not that
case because
can be possible to use it for microblaze and xilinx ppc.
This ll_temac driver is just another net IP like emaclite is. Emaclite driver
is possible to use
on Microblaze and xilinx ppc systems and in near future with arm on Xilinx zynq
platform.
> I don't want to have this in mainline.
If this is your decision, I won't send any updated version.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 0/6] SPL Linux boot
Adds direct Linux boot to SPL. It implements a spl export command to save ATAGS or FDT to NAND flash. The kernel image has to be in place for this! based on: - The new SPL layout - OMAP3 new SPL layout (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105260) - CONFIG_MACH_TYPE fix (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105809) - Prep subcommand patch for arm (http://article.gmane.org/gmane.comp.boot-loaders.u-boot/106725) Related to: - http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102669 Simon Schwarz (6): removed static from images in cmd_bootm.c Add cmd_spl command devkit8000/spl: init GPMC for dm9000 in SPL omap-common/spl: Add linux boot to SPL omap-common: Add NAND SPL linux booting omap-common: fixes BSS overwriting problem arch/arm/cpu/armv7/omap-common/spl.c | 45 ++- arch/arm/cpu/armv7/omap-common/spl_nand.c | 63 +++-- arch/arm/include/asm/omap_common.h|2 + board/timll/devkit8000/devkit8000.c | 33 -- common/Makefile |1 + common/cmd_bootm.c|2 +- common/cmd_spl.c | 214 + doc/README.commands.spl | 31 include/cmd_spl.h | 30 include/configs/devkit8000.h | 16 ++- 10 files changed, 407 insertions(+), 30 deletions(-) create mode 100644 common/cmd_spl.c create mode 100644 doc/README.commands.spl create mode 100644 include/cmd_spl.h -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 2/6] Add cmd_spl command
This adds a spl command to the u-boot.
Related config:
CONFIG_CMD_CPL
activate/deactivate the command
CONFIG_CMD_SPL_NAND_OFS
Offset in NAND to use
Signed-off-by: Simon Schwarz
---
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
V3 changes:
FIX added missing brackets
V4 changes:
CHG Corrected argument number in comments
CHG added check for CONFIG_OF_LIBFDT
CHG squashed the README to this commit
DEL define description from commit message - unused in this patch
CHG renamed to spl now with subcommand export, very different now
ADD New call style with subcommands.
CHG added printf where the image is located
CHG Patched README to reflect changes
CHG parameter count
CHG usage message
---
common/Makefile |1 +
common/cmd_spl.c | 214 ++
doc/README.commands.spl | 31 ++
include/cmd_spl.h| 30 ++
include/configs/devkit8000.h |7 ++
5 files changed, 283 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_spl.c
create mode 100644 doc/README.commands.spl
create mode 100644 include/cmd_spl.h
diff --git a/common/Makefile b/common/Makefile
index 124a427..6945175 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_SPL) += cmd_spl.o
# others
COBJS-$(CONFIG_DDR_SPD) += ddr_spd.o
diff --git a/common/cmd_spl.c b/common/cmd_spl.c
new file mode 100644
index 000..51fc680
--- /dev/null
+++ b/common/cmd_spl.c
@@ -0,0 +1,214 @@
+/* Copyright (C) 2011
+ * Corscience GmbH & Co. KG - Simon Schwarz
+ *
+ * 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
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Calls bootm with the parameters given */
+int call_bootm(int argc, char * const argv[], char *subcommand[])
+{
+ char *bootm_argv[5];
+ char command[] = "do_bootm";
+
+ int i = 0;
+ int ret = 0;
+
+ /* create paramter array */
+ bootm_argv[0] = command;
+ switch (argc) {
+ case 3:
+ bootm_argv[4] = argv[2]; /* fdt addr */
+ case 2:
+ bootm_argv[3] = argv[1]; /* initrd addr */
+ case 1:
+ bootm_argv[2] = argv[0]; /* kernel addr */
+ }
+
+
+ /* - do the work - */
+ /* exec subcommands of do_bootm to init the images
+* data structure */
+ while (subcommand[i] != '\0') {
+ bootm_argv[1] = subcommand[i];
+ debug("args: %s, %s, %s, %s, %s, %d\n", bootm_argv[0],
+ bootm_argv[1], bootm_argv[2], bootm_argv[3],
+ bootm_argv[4], argc);
+ ret = do_bootm(find_cmd("do_bootm"), 0, argc+2,
+ bootm_argv);
+ debug("Subcommand retcode: %d\n", ret);
+ i++;
+ }
+
+ if (ret) {
+ printf("ERROR prep subcommand failed!\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+/* assemble the bootm paramteres for fdt creation */
+int spl_export_fdt(int argc, char * const argv[])
+{
+#ifdef CONFIG_OF_LIBFDT
+ /* Create subcommand string */
+ char *subcommand[] = {"start", "loados",
+#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
+ "ramdisk",
+#endif
+ "fdt", "cmdline", "bdt", "prep", '\0'};
+
+ /* inspect paramters and execute bootm */
+ argc--;
+ argv++;
+ if (call_bootm(argc, argv, subcommand))
+ return -1;
+
+ printf("Argument image is now in RAM: 0x%p\n",
+ (void *)images.ft_addr);
+ return 0;
+#else
+ printf("Das U-Boot was build without fdt support - aborting\n");
+ return -1;
+#endif
+}
+
+/* assemble the bootm patameters for atags creation */
+int spl_export_atags(int argc, char * const argv[])
+{
+#if defined(CONFIG_SETUP_MEMORY_TAGS) || \
+ defined(CONFIG_CMDLINE_TAG) || \
+ defined(CONFIG_INITRD_TAG
[U-Boot] [PATCH V4 3/6] devkit8000/spl: init GPMC for dm9000 in SPL
Linux crashes if the GPMC isn't configured for the dm9000.
Signed-off-by: Simon Schwarz
---
V2 changes:
nothing
V3 changes:
nothing
---
arch/arm/include/asm/omap_common.h |2 ++
board/timll/devkit8000/devkit8000.c | 33 -
2 files changed, 26 insertions(+), 9 deletions(-)
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 V4 4/6] omap-common/spl: Add linux boot to SPL
This adds Linux booting to the SPL
This depends on CONFIG_MACH_TYPE patch by Igor Grinberg
(http://article.gmane.org/gmane.comp.boot-loaders.u-boot/105809)
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_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
---
V2 changes:
nothing
V3 changes:
nothing
V4 changes:
CHG Using CONFIG_MACH_TYPE now.
DEL CONFIG_SYS_SPL_MACHID
CHG Use CONFIG_MACH_TYPE for machine id config - This makes the patch
depending on the patch linked above
---
arch/arm/cpu/armv7/omap-common/spl.c | 45 -
include/configs/devkit8000.h |9 +-
2 files changed, 50 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..4fe3837 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -63,6 +64,23 @@ void board_init_f(ulong dummy)
relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
}
+/* 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;
+}
+
void spl_parse_image_header(const struct image_header *header)
{
u32 header_size = sizeof(struct image_header);
@@ -90,7 +108,23 @@ void spl_parse_image_header(const struct image_header
*header)
}
}
-static void jump_to_image_no_args(void)
+/* 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_MACH_TYPE, arg);
+}
+void jump_to_image_linux(void *) __attribute__ ((noreturn));
+
+void jump_to_image_no_args(void)
{
typedef void (*image_entry_noargs_t)(void)__attribute__ ((noreturn));
image_entry_noargs_t image_entry =
@@ -99,8 +133,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 +168,13 @@ 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");
+ spl_board_prepare_for_linux();
+ 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 09a2505..72a4f40 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -38,7 +38,9 @@
#define CONFIG_OMAP34301 /* which is in a 3430 */
#define CONFIG_OMAP3_DEVKIT80001 /* working with DevKit8000 */
-#defineCONFIG_SYS_TEXT_BASE0x80008000
+#define CONFIG_MACH_TYPE MACH_TYPE_DEVKIT8000
+
+#defineCONFIG_SYS_TEXT_BASE0x8010
#define CONFIG_SDRC/* The chip has SDRC controller */
@@ -328,7 +330,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 +360,9 @@
#define CONFIG_CMD_SPL_WRITE_SIZE 0x400 /* 1024 byte */
#define CONFIG_CMD_SPL_NAND_OFS(CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x40)
+#define CONFIG_SPL_OS_BOOT
+#define CONFIG_SPL_OS_BOOT_KEY 26
+
[U-Boot] [PATCH V4 5/6] omap-common: Add NAND SPL linux booting
This implements booting of Linux from NAND in SPL
Related config parameters:
CONFIG_SYS_NAND_SPL_KERNEL_OFFS
Offset in NAND of direct boot kernel image to use in SPL
CONFIG_SYS_SPL_ARGS_ADDR
Address where the kernel boot arguments are expected - this is
normally RAM-start + 0x100 (on ARM)
Signed-off-by: Simon Schwarz
---
V2 changes:
nothing
V3 changes:
nothing
V4 changes:
ADD define description to commit message
CHG renaming some defines - renaming SAVEBP SPL
---
arch/arm/cpu/armv7/omap-common/spl_nand.c | 62 +---
1 files changed, 46 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..93f5183 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
#include
#include
+#include
#include
#include
#include
@@ -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");
@@ -46,26 +48,54 @@ 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 */
+ /* load to temp position since nand_spl_load_image reads
+* a whole block which is typically larger than
+* CONFIG_CMD_SAVEBP_WRITE_SIZE therefore may overwrite
+* following sections like BSS */
+ nand_spl_load_image(CONFIG_CMD_SPL_NAND_OFS,
+ CONFIG_CMD_SPL_WRITE_SIZE,
+ (void *)CONFIG_SYS_TEXT_BASE);
+ /* copy to destintion */
+ for (dst = (int *)CONFIG_SYS_SPL_ARGS_ADDR,
+ src = (int *)CONFIG_SYS_TEXT_BASE;
+ src < (int *)(CONFIG_SYS_TEXT_BASE +
+ CONFIG_CMD_SPL_WRITE_SIZE);
+ src++, dst++) {
+ writel(readl(src), dst);
+ }
+ /* load linux */
+ nand_spl_load_image(CONFIG_SYS_NAND_SPL_KERNEL_OFFS,
+ CONFIG_SYS_NAND_PAGE_SIZE, (void *)header);
+ spl_parse_image_header(header);
+ 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 V4 6/6] 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
---
V2 changes:
nothing
V3 changes:
nothing
---
arch/arm/cpu/armv7/omap-common/spl_nand.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/spl_nand.c
b/arch/arm/cpu/armv7/omap-common/spl_nand.c
index 93f5183..ec56565 100644
--- a/arch/arm/cpu/armv7/omap-common/spl_nand.c
+++ b/arch/arm/cpu/armv7/omap-common/spl_nand.c
@@ -72,7 +72,8 @@ void spl_nand_load_image(void)
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 V4 1/6] removed static from images in cmd_bootm.c
This removes static modifier from cmd_bootm.c to make it public and usable
by savebp
Signed-off-by: Simon Schwarz
---
common/cmd_bootm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 1966da4..c642299 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -156,7 +156,7 @@ static boot_os_fn *boot_os[] = {
#endif
};
-static bootm_headers_t images; /* pointers to os/initrd/fdt images */
+bootm_headers_t images;/* pointers to os/initrd/fdt images */
/* Allow for arch specific config before we boot */
void __arch_preboot_os(void)
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] powerpc/p4080: Add support for secure boot flow
Pre u-boot Flow: 1. User loads the u-boot image in flash 2. PBL/Configuration word is used to create LAW for Flash at 0xc000 (Please note that ISBC expects all these addresses, images to be validated, entry point etc within 0 - 3.5G range) 3. ISBC validates the u-boot image, and passes control to u-boot at 0xcffc. Changes in u-boot: 1. Temporarily map CONFIG_SYS_MONITOR_BASE to the 1M CONFIG_SYS_PBI_FLASH_WINDOW in AS=1. (The CONFIG_SYS_PBI_FLASH_WINDOW is the address map for the flash created by PBL/configuration word within 0 - 3.5G memory range. The u-boot image at this address has been validated by ISBC code) 2. Remove TLB entries for 0 - 3.5G created by ISBC code 3. Remove the LAW entry for the CONFIG_SYS_PBI_FLASH_WINDOW created by PBL/configuration word after switch to AS = 1 Signed-off-by: Ruchika Gupta Signed-off-by: Kuldip Giroh Acked-by: Wood Scott-B07421 Signed-off-by: Kumar Gala --- arch/powerpc/cpu/mpc85xx/cpu_init.c| 11 +- arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 10 +- arch/powerpc/cpu/mpc85xx/start.S | 55 +++- arch/powerpc/include/asm/fsl_secure_boot.h | 43 ++ arch/powerpc/include/asm/immap_85xx.h |2 + boards.cfg |1 + include/configs/corenet_ds.h |4 ++ 7 files changed, 123 insertions(+), 3 deletions(-) create mode 100644 arch/powerpc/include/asm/fsl_secure_boot.h diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 27f836c..e2c5b6f 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -226,7 +226,9 @@ void cpu_init_f (void) #ifdef CONFIG_SYS_DCSRBAR_PHYS ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); #endif - +#if defined(CONFIG_SECURE_BOOT) + struct law_entry law; +#endif #ifdef CONFIG_MPC8548 ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR); uint svr = get_svr(); @@ -244,6 +246,13 @@ void cpu_init_f (void) disable_tlb(14); disable_tlb(15); +#if defined(CONFIG_SECURE_BOOT) + /* Disable the LAW created for NOR flash by the PBI commands */ + law = find_law(CONFIG_SYS_PBI_FLASH_BASE); + if (law.index != -1) + disable_law(law.index); +#endif + #ifdef CONFIG_CPM2 config_8560_ioports((ccsr_cpm_t *)CONFIG_SYS_MPC85xx_CPM_ADDR); #endif diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c index a04f5c1..4ef3c9a 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c @@ -1,5 +1,5 @@ /* - * Copyright 2009 Freescale Semiconductor, Inc + * Copyright 2009-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 as @@ -149,5 +149,13 @@ void cpu_init_early_f(void) #endif invalidate_tlb(1); + +#if defined(CONFIG_SECURE_BOOT) + /* Disable the TLBs created by ISBC */ + for (i = CONFIG_SYS_ISBC_START_TLB; +i < CONFIG_SYS_ISBC_START_TLB + CONFIG_SYS_ISBC_NUM_TLBS; i++) + disable_tlb(i); +#endif + init_tlbs(); } diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index d89d18c..5e0d78d 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -83,6 +83,45 @@ _start_e500: +#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500MC) + /* ISBC uses L2 as stack. +* Disable L2 cache here so that u-boot can enable it later +* as part of it's normal flow + */ + + /* Check if L2 is enabled */ + mfspr r3, SPRN_L2CSR0 + lis r2, L2CSR0_L2E@h + ori r2, r2, L2CSR0_L2E@l + and.r4, r3, r2 + beq l2_disabled + + mfspr r3, SPRN_L2CSR0 + /* Flush L2 cache */ + lis r2,(L2CSR0_L2FL)@h + ori r2, r2, (L2CSR0_L2FL)@l + or r3, r2, r3 + sync + isync + mtspr SPRN_L2CSR0,r3 + isync +1: + mfspr r3, SPRN_L2CSR0 + and. r1, r3, r2 + bne 1b + + mfspr r3, SPRN_L2CSR0 + lis r2, L2CSR0_L2E@h + ori r2, r2, L2CSR0_L2E@l + andc r4, r3, r2 + sync + isync + mtspr SPRN_L2CSR0,r4 + isync + +l2_disabled: +#endif + /* clear registers/arrays not reset by hardware */ /* L1 */ @@ -516,7 +555,7 @@ create_init_ram_area: lis r6,FSL_BOOKE_MAS0(1, 15, 0)@h ori r6,r6,FSL_BOOKE_MAS0(1, 15, 0)@l -#ifndef CONFIG_SYS_RAMBOOT +#if !defined(CONFIG_SYS_RAMBOOT) && !defined(CONFIG_SECURE_BOOT) /* create a temp mapping in AS=1 to the 4M boot window */ lis r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@h ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@l @@ -527,6 +566,20 @@
[U-Boot] [PATCH 0/3] Add secure boot support on P4080/P3041/P5020 & P1010 boards.
Boot Flow in secure systems: 1. User loads the u-boot image in flash 2. PBL/Configuration word is used to create LAW for Flash at 0xc000 (Please note that ISBC expects all these addresses, images to be validated, entry point etc within 0 - 3.5G range) 3. On system reset, BOOt ROM code executes first. It validates the u-boot image, and then passes control to u-boot The patch set adds the changes for u-boot to execute after BOOT ROM code in secure systems. Kumar Gala (2): powerpc/85xx: Add PBL & SECUREBOOT support on P3041/P5020DS boards P1010RDB :Secure Boot support added for NOR , NAND and SPIFLASH Ruchika Gupta (1): powerpc/p4080: Add support for secure boot flow arch/powerpc/cpu/mpc85xx/cpu_init.c| 11 +- arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 10 +- arch/powerpc/cpu/mpc85xx/start.S | 55 +++- arch/powerpc/include/asm/fsl_secure_boot.h | 43 ++ arch/powerpc/include/asm/immap_85xx.h |2 + boards.cfg |9 + include/configs/P1010RDB.h | 15 +++- include/configs/corenet_ds.h |4 ++ 8 files changed, 144 insertions(+), 5 deletions(-) create mode 100644 arch/powerpc/include/asm/fsl_secure_boot.h -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] P1010RDB :Secure Boot support added for NOR , NAND and SPIFLASH
From: Kumar Gala Signed-off-by: Ruchika Gupta Signed-off-by: Kuldip Giroh --- boards.cfg |6 ++ include/configs/P1010RDB.h | 15 +-- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/boards.cfg b/boards.cfg index 6fd6e55..25ca5f5 100644 --- a/boards.cfg +++ b/boards.cfg @@ -580,13 +580,19 @@ MPC8572DSpowerpc mpc85xx mpc8572ds freesca MPC8572DS_36BIT powerpc mpc85xx mpc8572ds freescale - MPC8572DS:36BIT MPC8572DS_NAND powerpc mpc85xx mpc8572ds freescale - MPC8572DS:NAND P1010RDB_NOR powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB +P1010RDB_NOR_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SECURE_BOOT P1010RDB_36BIT_NOR powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT +P1010RDB_36BIT_NOR_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SECURE_BOOT P1010RDB_NANDpowerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,NAND +P1010RDB_NAND_SECBOOTpowerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,NAND_SECBOOT,SECURE_BOOT P1010RDB_36BIT_NAND powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,NAND +P1010RDB_36BIT_NAND_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,NAND_SECBOOT,SECURE_BOOT P1010RDB_SDCARD powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SDCARD P1010RDB_SPIFLASHpowerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SPIFLASH +P1010RDB_SPIFLASH_SECBOOTpowerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,SPIFLASH,SECURE_BOOT P1010RDB_36BIT_SDCARDpowerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SDCARD P1010RDB_36BIT_SPIFLASH powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SPIFLASH +P1010RDB_36BIT_SPIFLASH_SECBOOT powerpc mpc85xx p1010rdb freescale - P1010RDB:P1010RDB,36BIT,SPIFLASH,SECURE_BOOT P1011RDB powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB P1011RDB_36BIT powerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,36BIT P1011RDB_36BIT_SDCARDpowerpc mpc85xx p1_p2_rdb freescale - P1_P2_RDB:P1011RDB,36BIT,SDCARD diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h index ff35fb1..ca6178a 100644 --- a/include/configs/P1010RDB.h +++ b/include/configs/P1010RDB.h @@ -59,6 +59,13 @@ #endif /* CONFIG_NAND_SPL */ #endif + +#ifdef CONFIG_NAND_SECBOOT /* NAND Boot */ +#define CONFIG_RAMBOOT_NAND +#define CONFIG_SYS_TEXT_BASE 0x1100 +#define CONFIG_RESET_VECTOR_ADDRESS0x1107fffc +#endif + #ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0xeff8 #endif @@ -345,7 +352,7 @@ extern unsigned long get_sdram_size(void); #define CONFIG_SYS_NAND_DDR_LAW11 /* Set up IFC registers for boot location NOR/NAND */ -#ifdef CONFIG_NAND_U_BOOT +#if defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SECBOOT) #define CONFIG_SYS_CSPR0 CONFIG_SYS_NAND_CSPR #define CONFIG_SYS_AMASK0 CONFIG_SYS_NAND_AMASK #define CONFIG_SYS_CSOR0 CONFIG_SYS_NAND_CSOR @@ -501,7 +508,7 @@ extern unsigned long get_sdram_size(void); * SPI interface will not be available in case of NAND boot SPI CS0 will be * used for SLIC */ -#ifndef CONFIG_NAND_U_BOOT +#if !defined(CONFIG_NAND_U_BOOT) || !defined(CONFIG_NAND_SECBOOT) /* eSPI - Enhanced SPI */ #define CONFIG_FSL_ESPI #define CONFIG_SPI_FLASH @@ -762,4 +769,8 @@ extern unsigned long get_sdram_size(void); #define CONFIG_BOOTCOMMAND CONFIG_RAMBOOTCOMMAND +#ifdef CONFIG_SECURE_BOOT +#include +#endif + #endif /* __CONFIG_H */ -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] powerpc/85xx: Add PBL & SECUREBOOT support on P3041/P5020DS boards
From: Kumar Gala Signed-off-by: Kumar Gala --- boards.cfg |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/boards.cfg b/boards.cfg index dae858c..6fd6e55 100644 --- a/boards.cfg +++ b/boards.cfg @@ -672,6 +672,7 @@ P2041RDB_SPIFLASHpowerpc mpc85xx p2041rdbfreesca P3041DS powerpc mpc85xx corenet_ds freescale P3041DS_NANDpowerpc mpc85xx corenet_ds freescale - P3041DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8 P3041DS_SDCARD powerpc mpc85xx corenet_ds freescale - P3041DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8 +P3041DS_SECURE_BOOT powerpc mpc85xx corenet_ds freescale - P3041DS:SECURE_BOOT P3041DS_SPIFLASHpowerpc mpc85xx corenet_ds freescale - P3041DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 P4080DS powerpc mpc85xx corenet_ds freescale P4080DS_SDCARD powerpc mpc85xx corenet_ds freescale - P4080DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8 @@ -680,6 +681,7 @@ P4080DS_SPIFLASH powerpc mpc85xx corenet_ds freescale P5020DS powerpc mpc85xx corenet_ds freescale P5020DS_NANDpowerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8 P5020DS_SDCARD powerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8 +P5020DS_SECURE_BOOT powerpc mpc85xx corenet_ds freescale - P5020DS:SECURE_BOOT P5020DS_SPIFLASHpowerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 mpq101 powerpc mpc85xx mpq101 mercury- mpq101 stxgp3 powerpc mpc85xx stxgp3 stx -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: standardize display of address map size (32-bit vs. 36-bit)
Kumar Gala wrote: > 1. We reduce the amount printed in the "default" case > 2. First choice should always be to have a command the print status info > 3. Allow a board port to makes its own decision if it wants to do something > like enable CONFIG_PCI_SCAN_SHOW > > Any concerns w/that proposal? Are you talking about my patch, or about CONFIG_PCI_SCAN_SHOW? The reason I like my patch as-is is because it completely eliminates the board from the decision. It's only one line, and it's CONSISTENT. That's the key part. We have not been consistent about this, and it seems silly for each board to implement the same feature. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1 V2] add support for mcf5307 cpu
Hi Jason and all, i am really interested to bring mcf5307 inside u-boot. But still waiting for your feedback/help on my comments below. Let me know your comments. Many thanks, Regards, angelo > Hello Jason and all, > i started to work to rewrite the patch. > > Starting from mcf532x/cpu.c, i am not sure this is the right place to add > MCF5307. > > 1) On "checkcpu", mcf5307 don't have ccm->cir where to read mask/ver. > 2) About "do_reset", here also mcf5307 don't have MMAP_RCM, memory map and > reset \ > procedure are different. 3) In general, as memory map, mcf5307 is much more > similar \ > to some mcf52x2 cpu. This is the reason why i thought to treat it as a > separate \ > family. Looking here: > http://www.freescale.com/webapp/sps/site/taxonomy.jsp?code=68KCFV3 > seems Freescale also treat it as the only cpu of the MCF530X family. > > I can still go ahead, but cpu.c should have a great #ifdef CONFIG_MCF5307 to > handle \ > separately this cpu. How do you think i should proceed ? > > regards > angelo On 22/08/2011 05:49, Jin Zhengxiong-R64188 wrote: > > -Original Message- > > From: Angelo Dureghello [mailto:angel...@gmail.com] > > Sent: Friday, August 12, 2011 5:20 AM > > To: U-Boot@lists.denx.de > > Cc: Jin Zhengxiong-R64188 > > Subject: [PATCH 1/1 V2] add support for mcf5307 cpu > > > > Add cpu related files and memory map includes. Apply the related > > minor changes to general coldfire architecture include files. > > > > Signed-off-by: Angelo Dureghello > > --- > > arch/m68k/cpu/mcf530x/Makefile | 48 +++ > > arch/m68k/cpu/mcf530x/config.mk| 25 > > arch/m68k/cpu/mcf530x/cpu.c| 48 +++ > > arch/m68k/cpu/mcf530x/cpu.h| 33 + > > arch/m68k/cpu/mcf530x/cpu_init.c | 164 +++ > > arch/m68k/cpu/mcf530x/interrupts.c | 42 ++ > > arch/m68k/cpu/mcf530x/speed.c | 36 + > > arch/m68k/cpu/mcf530x/start.S | 253 > > > arch/m68k/include/asm/immap_5307.h | 78 +++ > > arch/m68k/include/asm/m5307.h | 119 + > > 10 files changed, 846 insertions(+), 0 deletions(-) > > create mode 100644 arch/m68k/cpu/mcf530x/Makefile > > create mode 100644 arch/m68k/cpu/mcf530x/config.mk > > create mode 100644 arch/m68k/cpu/mcf530x/cpu.c > > create mode 100644 arch/m68k/cpu/mcf530x/cpu.h > > create mode 100644 arch/m68k/cpu/mcf530x/cpu_init.c > > create mode 100644 arch/m68k/cpu/mcf530x/interrupts.c > > create mode 100644 arch/m68k/cpu/mcf530x/speed.c > > create mode 100644 arch/m68k/cpu/mcf530x/start.S > > create mode 100644 arch/m68k/include/asm/immap_5307.h > > create mode 100644 arch/m68k/include/asm/m5307.h > > [Jin Zhengxiong-R64188] Could you please try to merge the 5307 cpu to > mcf532x as we > already have two ColdFire V3 boards here(We can try to rename the mcf532x to > such \ > as mcf53xx later for less confuse). You can keep the immap_5307.h and > m5307.h > for the 5307 cpu. All the other files are similar with the files for the two > V3 \ > boards except the cpu_init.c file. > > Thanks. > > Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/4] Run-time configuration of U-Boot via a flat device tree (fdt)
Hi Simon, On 09/01/2011 04:49 PM, Simon Glass wrote: > At present in U-Boot configuration is mostly done using CONFIG options in the > board file. This patch set aims to make it possible for a single U-Boot > binary to support multiple boards, with the exact configuration of each board > controlled by a flat device tree (fdt). This is the approach recently taken > by the ARM Linux kernel and has been used by PowerPC for some time. Very exciting. I've thought about doing this for years, but never had the ambition (or time). [snip] > and add some defines to your board (only ARM is currently supported): > > #define CONFIG_OF_CONTROL (to enable run-time config control via fdt) > #define CONFIG_OF_EMBED or CONFIG_OF_SEPARATE > (either build the fdt blob into U-Boot, or create a separate u-boot.dtb) > #define CONFIG_DEFAULT_DEVICE_TREE "" > (to specify the name of the device tree file is >board///.dts) > > This patch set does not include any drivers which actually use the fdt. I have > some concerns about spreading fdt code around the U-Boot code base so am > thinking of having a support file which makes this easier. I can provide a > UART driver modified to use fdt if there is interest. Please. A concrete reference is very useful, especially for discussion. > It is important to understand that the fdt only selects options available in > the platform / drivers. It cannot add new drivers (yet). So you must still > have the CONFIG option to enable the driver. For example, you need to define > CONFIG_SYS_NS16550 to bring in the NS16550 driver, but can use the fdt to > specific the UART clock, peripheral address, etc. In very broad terms, the > CONFIG options in general control *what* driver files are pulled in, and the > fdt controls *how* those files work. Sounds reasonable and practical. One of the things u-boot struggles with is staying small (but it is nice to be able to make it all inclusive and big if you have the flash). > While only ARM is supported in this patch series, it should be easy enough to > add support for other architectures. Exercise left for the students. :-) [snip] Thanks! gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v3] ARM: ARM926EJS - Add cache operations
On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote: > On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote: > > Hi Hong, > > > > On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote: > > > Hi Marek, > > > > > > On 08/11/2011 12:47 PM, Marek Vasut wrote: > > > > On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: > > > >> Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations > > > >> into this file. > > > >> > > > >> Signed-off-by: Hong Xu > > > >> --- > > > >> > > > >> V2: > > > >>Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined > > > >> > > > >> V3: > > > >>Undo changes in include/configs/at91sam9260ek.h > > > >>It's for testing purpose > > > >> > > > >> arch/arm/cpu/arm926ejs/Makefile |2 +- > > > >> arch/arm/cpu/arm926ejs/cache.c | 142 > > > >> > > > >> +++ 2 files changed, 143 > > > >> insertions(+), 1 deletions(-) > > > >> > > > >> create mode 100644 arch/arm/cpu/arm926ejs/cache.c > > > > What is the status for this patch ? > > > > I have failed to find any trace for this patch in patchwork or in the > > arm git repository... > > We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... > I > dunno what's this guys' full name ;-D). I tested this patch on certain type > of > CPU and it works really good. I'd be really glad if we got this mainline! Yes. Moreover some drivers (as mvgbe) really needs such functions to fix the DMA operations when D-cache is enabled. Simon signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v3] ARM: ARM926EJS - Add cache operations
On Friday, September 02, 2011 01:43:39 PM Simon Guinot wrote: > On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote: > > On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote: > > > Hi Hong, > > > > > > On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote: > > > > Hi Marek, > > > > > > > > On 08/11/2011 12:47 PM, Marek Vasut wrote: > > > > > On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: > > > > >> Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache > > > > >> operations into this file. > > > > >> > > > > >> Signed-off-by: Hong Xu > > > > >> --- > > > > >> > > > > >> V2: > > > > >> Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined > > > > >> > > > > >> V3: > > > > >> Undo changes in include/configs/at91sam9260ek.h > > > > >> It's for testing purpose > > > > >> > > > > >> arch/arm/cpu/arm926ejs/Makefile |2 +- > > > > >> arch/arm/cpu/arm926ejs/cache.c | 142 > > > > >> > > > > >> +++ 2 files changed, 143 > > > > >> insertions(+), 1 deletions(-) > > > > >> > > > > >> create mode 100644 arch/arm/cpu/arm926ejs/cache.c > > > > > > What is the status for this patch ? > > > > > > I have failed to find any trace for this patch in patchwork or in the > > > arm git repository... > > > > We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea > > ... I dunno what's this guys' full name ;-D). I tested this patch on > > certain type of CPU and it works really good. I'd be really glad if we > > got this mainline! > > Yes. Moreover some drivers (as mvgbe) really needs such functions to fix > the DMA operations when D-cache is enabled. I have some fixes already queued, yes. > > Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/8] POST/arm: adaptations needed for POST on ARM to work
On 09/02/2011 12:11 AM, Mike Frysinger wrote: > On Thursday, September 01, 2011 11:39:20 Valentin Longchamp wrote: >> arch/arm/include/asm/global_data.h |4 >> arch/arm/lib/board.c |2 ++ > > these two are fine for arm > >> include/post.h |8 > > but this looks like a board-specific issue and not really arm. could you > split it into its own patch please ? OK, fine for me. -- Valentin Longchamp Embedded Software Engineer Hardware and Chip Integration __ KEYMILE AG Schwarzenburgstr. 73 CH-3097 Liebefeld Phone +41 31 377 1318 Fax +41 31 377 1212 valentin.longch...@keymile.com www.keymile.com __ KEYMILE: A Specialist as a Partner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/8] POST/km_arm: add POST memory tests infrastructure
On 09/02/2011 12:10 AM, Mike Frysinger wrote: > On Thursday, September 01, 2011 11:39:25 Valentin Longchamp wrote: >> post/board/km_arm/Makefile | 29 + >> post/board/km_arm/memory.c | 35 +++ > > cant these live in board// ? i'd like to kill off post/board/*. > -mike They sure can. I had not done it since there was a remark from Marek Vasut in the previous thread, but if post/board/* is going to disappear, the discussion is not valid any more. -- Valentin Longchamp Embedded Software Engineer Hardware and Chip Integration __ KEYMILE AG Schwarzenburgstr. 73 CH-3097 Liebefeld Phone +41 31 377 1318 Fax +41 31 377 1212 valentin.longch...@keymile.com www.keymile.com __ KEYMILE: A Specialist as a Partner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap3evm: Set environment variable 'ethaddr'
It is now responsibility of the board specific init
code to set the environment variable corresponding
to the MAC address.
Signed-off-by: Sanjeev Premi
---
Tested on omap3evm at against latest master at:
bd061a5 : Merge branch 'master' of git://git.denx.de/u-boot-sh
board/ti/evm/evm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 30c1c57..07db40c 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -216,7 +216,17 @@ int board_eth_init(bd_t *bis)
{
int rc = 0;
#ifdef CONFIG_SMC911X
+ struct eth_device *dev;
+
rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+
+ dev = eth_get_dev_by_index(0);
+ if (dev) {
+ eth_setenv_enetaddr("ethaddr", dev->enetaddr);
+ } else {
+ printf("omap3evm: Couldn't get eth device\n");
+ rc = -1;
+ }
#endif
return rc;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Michal Simek,
In message <4e60b220.6010...@monstr.eu> you wrote:
>
> As I see there is still ugly board/xilinx/common folder and ancient enet
> driver and i2c
> driver.
Indeed, and improvementrs are more than welcome.
> > Actually even this is incorrect - AFAIK Device Control Registers (DCR)
> > exist not on all PPC systems, but only on 4xx (and even there only on
> > some models). So your code works on a few systems, silently does not
> > do anything on others, and crashes on yet others with an illegal
> > instruction.
>
> That driver is not definitely for all ppc systems. That IP is available just
> for
> Xilinx FPGA where can be possible to use it with Microblaze and xilinx ppc440
> (maybe ppc405).
> That DCR handling, which is implemented in this driver, fits to xilinx ppc440
> implementation.
> Which means that none can add this IP to any other PPC system out of Xilinx
> FPGA.
So why not use something like CONFIG_440 in this test, and add an
#error for anything else?
Do we actually need this m{f,t}dcr_local() then?
> Sorry I can't see any problem to have driver for specific platform or even to
> have one driver
> which supports two completely different platform.
My issue is that this code silently breaks or crashes when certain
(undocumented) conditions are not met. Preventing this seems not to
bee too difficult: add a comment, make it depend on the right CONFIG_
settings, and bail out with a clear error message when conditions are
not met.
As for the other part of the problem - you try to mix two different
cases: one where you refer to an index, and one where you refer to an
address. This obviously doesn't mix well. If there is no better way
of doing this, I'd still prefer deriving the index from the offset in
a struct than deriving the address from an offset - the intention is
to enable the compiler to perform type checking, which is impossible
with a typeless base+offset address.
> > I don't want to have this in mainline.
>
> If this is your decision, I won't send any updated version.
Attempted extortion?
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
"Wagner's music is better than it sounds." - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: standardize display of address map size (32-bit vs. 36-bit)
On Sep 2, 2011, at 6:36 AM, Tabi Timur-B04825 wrote: > Kumar Gala wrote: >> 1. We reduce the amount printed in the "default" case >> 2. First choice should always be to have a command the print status info >> 3. Allow a board port to makes its own decision if it wants to do something >> like enable CONFIG_PCI_SCAN_SHOW >> >> Any concerns w/that proposal? > > Are you talking about my patch, or about CONFIG_PCI_SCAN_SHOW? > > The reason I like my patch as-is is because it completely eliminates the > board from the decision. It's only one line, and it's CONSISTENT. That's > the key part. We have not been consistent about this, and it seems silly > for each board to implement the same feature. Both. I'm think for your patch we'd add some general config option for extra print info. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap: gpio: User generic (instead of custom) API
> -Original Message- > From: Luca Ceresoli [mailto:luca.ceres...@comelit.it] > Sent: Thursday, September 01, 2011 10:19 PM > To: Premi, Sanjeev > Cc: u-boot@lists.denx.de; Paulraj, Sandeep; Igor Grinberg; > Enric Balletbo i Serra; Sunil Kumar; Shashi Ranjan; Menon, > Nishanth; Steve Sakoman > Subject: Re: [RFC 0/3] omap: gpio: User generic (instead of > custom) API > > Hi Sanjeev, > > Sanjeev Premi wrote: > > The OMAP boards use a custom api for GPIO operations. While > > it works, it doesn't help when when we don't know existence > > of the customization. > > > > I earlier encountered the problem when looking for GPIO > > related changes when submitting prev set of patches. Since > > the search for gpio_request() in omap sources returned empty, > > I had assumed that it isn't supported. > > > > This patchset attempts to adapt the current implementation > > to use generic API. > > > > Since, the changes impact all OMAP boards, and I wouldn't be > > able to test on all, I decided to submit changes as RFC. > > Unless any major issue is found, I will be able to submit > > as formal patch by end of this week. > > Tested and working on the dig297 board, on top of the master > branch in the u-boot-ti repository. > > I also tried to merge your work on the u-boot-arm repo, but it > conflicts with the GPIO work recently committed there. You might > want to rebase and resubmit when the -ti repo will be in line with > the -arm one. Thanks. I didn't check the -arm repo; had based all patches on the master @ git.denx.de/u-boot.git - assuming there won't been too many changes since recent pull requests. ~sanjeev (PS: Had to trim the cc: list to ensure message gets through...) > Anyway, for the current version: > Tested-by: Luca Ceresoli > > Luca > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Cleanup how SVR_MAJ() is defined on MPC8536
On Aug 24, 2011, at 9:16 AM, Kumar Gala wrote: > 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 > --- > arch/powerpc/cpu/mpc85xx/cpu.c |3 --- > arch/powerpc/include/asm/processor.h |4 > 2 files changed, 4 insertions(+), 3 deletions(-) applied to next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/mpc8xxx: Extend CWL table
On Aug 24, 2011, at 11:40 AM, York Sun wrote: > Extend CAS write Latency (CWL) table to comply with DDR3 spec > > Signed-off-by: York Sun > --- > arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 18 -- > 1 files changed, 16 insertions(+), 2 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] powerpc/mpc8xxx: Move DDR RCW overriding to common code
On Aug 24, 2011, at 11:40 AM, York Sun wrote: > DDR RCW varies at different speeds. It is common for all platform. Move it > out from corenet_ds. > > Signed-off-by: York Sun > --- > arch/powerpc/cpu/mpc8xxx/ddr/options.c | 15 +++ > board/freescale/corenet_ds/ddr.c | 14 -- > 2 files changed, 15 insertions(+), 14 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] powerpc/corenet_ds: Use separated speed tables for UDIMM and RDIMM
On Aug 24, 2011, at 11:40 AM, York Sun wrote: > 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 > --- > board/freescale/corenet_ds/ddr.c | 103 +++--- > 1 files changed, 84 insertions(+), 19 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Wolfgang Denk,
> In message <4e60b220.6010...@monstr.eu> you wrote:
>> As I see there is still ugly board/xilinx/common folder and ancient enet
>> driver and i2c
>> driver.
>
> Indeed, and improvementrs are more than welcome.
>
>>> Actually even this is incorrect - AFAIK Device Control Registers (DCR)
>>> exist not on all PPC systems, but only on 4xx (and even there only on
>>> some models). So your code works on a few systems, silently does not
>>> do anything on others, and crashes on yet others with an illegal
>>> instruction.
>> That driver is not definitely for all ppc systems. That IP is available just
>> for
>> Xilinx FPGA where can be possible to use it with Microblaze and xilinx
>> ppc440 (maybe ppc405).
>> That DCR handling, which is implemented in this driver, fits to xilinx
>> ppc440 implementation.
>> Which means that none can add this IP to any other PPC system out of Xilinx
>> FPGA.
>
> So why not use something like CONFIG_440 in this test, and add an
> #error for anything else?
>
> Do we actually need this m{f,t}dcr_local() then?
DCR handling is specific for Xilinx ppc440 which means that not all PPC440 can
use it.
As you see m{f,t}dcr_local setup handling for it that's why it is neeeded.
>
>> Sorry I can't see any problem to have driver for specific platform or even
>> to have one driver
>> which supports two completely different platform.
>
> My issue is that this code silently breaks or crashes when certain
> (undocumented) conditions are not met. Preventing this seems not to
> bee too difficult: add a comment, make it depend on the right CONFIG_
> settings, and bail out with a clear error message when conditions are
> not met.
Driver is protected by CONFIG_XILINX_LL_TEMAC option which means that
any platform is not silently breaks. You can use it with Microblaze and PPC
and configuration is done (xparameters.h and config.mk files) by u-boot BSP
in connection to Xilinx EDK which check if DCR can be used or not.
>
> As for the other part of the problem - you try to mix two different
> cases: one where you refer to an index, and one where you refer to an
> address.
In technical sense it is still address not index. It is different addressing
mode.
I have done it because it is much better than a lot of ifdefs. It is more than
that
because ppc has dcr up to 4 DMAs but memory controller supports up to 8 DMAs
that's why I think that it is better to support both modes and decide by
configuration.
This obviously doesn't mix well. If there is no better way
> of doing this, I'd still prefer deriving the index from the offset in
> a struct than deriving the address from an offset - the intention is
> to enable the compiler to perform type checking, which is impossible
> with a typeless base+offset address.
I understand the reasons for that but I can't see any elegant way how to do so.
>>> I don't want to have this in mainline.
>> If this is your decision, I won't send any updated version.
>
> Attempted extortion?
My god why do you think that it is extortion?
If you don't want to add it to mainline because you think that this driver
is bad/broken/anything, I can do nothing with it and make no sense for me to
invest my time to it.
And I am not going to disturb others with it.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] UBI problems on current u-bo
Hi Stefan, I address this question to you because one of your commits is connected to this problem, but other hints from other readers are also welcome ;-) . We have a kirkwood based board with a micron NAND flash. We have one ubi device created on the NAND flash and inside the device we have one ubi volume were we store our linux kernel. At startup we attach to the ubi device, to be able to readout the kernel image. On our old u-boot branch which based on v2009.08 we hadn't any problems. Now after upgrading to the newest u-boot version we saw in some rarely cases our u-boot get stuck when we try to attach: => ubi part ubi0 Creating 1 MTD partitions on "nand0": 0x-0x0800 : "mtd=0" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 UBI: fixable bit-flip detected at PEB 71 And after this u-boot gets stuck until the end of days and we have to force a reboot, but the u-boot gets stuck again. If I revert your commit: commit 1b1f9a9d00447d9eab32ae5633f60a106196b75f Author: Stefan Roese Date: Mon May 17 10:00:51 2010 +0200 UBI: Ensure that "background thread" operations are really executed the u-boot don't get stuck: => ubi part ubi0 Creating 1 MTD partitions on "nand0": 0x-0x0800 : "mtd=0" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 UBI: fixable bit-flip detected at PEB 71 UBI: attached mtd1 to ubi0 UBI: MTD device name:"mtd=0" UBI: MTD device size:128 MiB UBI: number of good PEBs:1024 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 9 UBI: available PEBs: 623 UBI: total number of reserved PEBs: 401 UBI: number of PEBs reserved for bad PEB handling: 10 UBI: max/mean erase counter: 8193/3082 => This is the reason why our old u-boot works, because the background thread seems to be not or not completely executed... If I boot a recent linux kernel the kernel also reports an "fixable bit-flip detected at PEB 71" but linux is able to really fix this bit flip and is able to work as expceted, even u-boot is afterwards bootable because the bitflip is corrected and gone. Now I could revert your commit in my local branch and then it seems to work, but I think this is not a good solution because I expect that the real error is somewhere in the UBI layer in u-boot and already fixed in current linux. AFAIK the ubi layer was initially copied from linux, but it seems that the bugfixes are not backported in the last years. Any thoughts or ideas? Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: standardize display of address map size (32-bit vs. 36-bit)
Kumar Gala wrote:
> Both. I'm think for your patch we'd add some general config option for extra
> print info.
So you want to see this instead:
/*
* Display whether this is a 32-bit build or a 36-bit build.
*/
#ifdef CONFIG_DISPLAY_ADDR_SIZE
#ifdef CONFIG_PHYS_64BIT
puts("ADDR: 36-bit address map\n");
#else
puts("ADDR: 32-bit address map\n");
#endif
#endif
I still like my way better. It eliminates the need to think about another
CONFIG option. I think adding another CONFIG option is worse than adding
another line of text.
It think it's silly to complain about adding one line of text that is only
displayed on e500 systems that support 36-bit addressing, especially since we
display this information on most of our boards anyway. Surely we can find some
other line of text that we can shorten or eliminate to make up for it.
For instance, we can combine these two lines into one:
CPU0: P1022E, Version: 1.0, (0x80ee0010)
Core: E500, Version: 5.0, (0x80211050)
or these two lines:
L1:D-cache 32 kB enabled
I-cache 32 kB enabled
--
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] omap3evm: Set environment variable 'ethaddr'
Dear Sanjeev Premi, In message <1314967433-14199-1-git-send-email-pr...@ti.com> you wrote: > It is now responsibility of the board specific init > code to set the environment variable corresponding > to the MAC address. > > Signed-off-by: Sanjeev Premi This looks all wrong to me. In U-Boot, the "ethaddr" environment variable is normally the primary storage for the MAC address. Only when this variable is not set, other potential storage locations may be referenced to initialize this value. Your patch always and unconditionally overwrites any existing "ethaddr" settings. This is not acceptable. 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 Build a system that even a fool can use and only a fool will want to use it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Set environment variable 'ethaddr'
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Friday, September 02, 2011 7:14 PM > To: Premi, Sanjeev > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH] omap3evm: Set environment > variable 'ethaddr' > > Dear Sanjeev Premi, > > In message <1314967433-14199-1-git-send-email-pr...@ti.com> you wrote: > > It is now responsibility of the board specific init > > code to set the environment variable corresponding > > to the MAC address. > > > > Signed-off-by: Sanjeev Premi > > This looks all wrong to me. In U-Boot, the "ethaddr" environment > variable is normally the primary storage for the MAC address. Only > when this variable is not set, other potential storage locations may > be referenced to initialize this value. > > Your patch always and unconditionally overwrites any existing > "ethaddr" settings. This is not acceptable. For the EVM, MAC address is always probed from the chip. Hence, I assumed it safe to set the ethaddr - without checking for env var. It was unlikely that someone would be setting it - to different value. But, I see your point that I should be checking for existence of a valid ethaddr before setting/overwriting it. ~sanjeev > > 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 > Build a system that even a fool can use and only a fool will want to > use it. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] MX25: tx25: Avoid the usage of extern in C file
Avoid the usage of extern in C file as pointed out by checkpatch.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Place the extern in the MX25 imx-regs.h instead of inside the MX27 imx-regs.h
Changes since v1:
- No changes
arch/arm/include/asm/arch-mx25/imx-regs.h |1 +
board/karo/tx25/tx25.c|1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 9e30f7c..7e34050 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -37,6 +37,7 @@
#ifdef CONFIG_FEC_MXC
extern void mx25_fec_init_pins(void);
extern void imx_get_mac_from_fuse(unsigned char *mac);
+extern void mx25_uart1_init_pins(void);
#endif
/* Clock Control Module (CCM) registers */
diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c
index 25b99e8..2787715 100644
--- a/board/karo/tx25/tx25.c
+++ b/board/karo/tx25/tx25.c
@@ -141,7 +141,6 @@ void tx25_fec_init(void)
int board_init()
{
#ifdef CONFIG_MXC_UART
- extern void mx25_uart1_init_pins(void);
mx25_uart1_init_pins();
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] MX25: Add initial support for MX25PDK
Add the initial support for MX25PDK booting from SD card via internal boot. Signed-off-by: Fabio Estevam --- Changes since v2: - No changes Changes since v1: - Keep mx25pdk entry to boards.cfg sorted - Removed unused defines in mx25pdk.h - Do not use the whole RAM space for memory test MAINTAINERS |1 + board/freescale/mx25pdk/Makefile| 49 ++ board/freescale/mx25pdk/imximage.cfg| 73 + board/freescale/mx25pdk/lowlevel_init.S | 21 ++ board/freescale/mx25pdk/mx25pdk.c | 62 ++ boards.cfg |1 + include/configs/mx25pdk.h | 106 +++ 7 files changed, 313 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mx25pdk/Makefile create mode 100644 board/freescale/mx25pdk/imximage.cfg create mode 100644 board/freescale/mx25pdk/lowlevel_init.S create mode 100644 board/freescale/mx25pdk/mx25pdk.c create mode 100644 include/configs/mx25pdk.h diff --git a/MAINTAINERS b/MAINTAINERS index f895e9a..7f07b60 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -645,6 +645,7 @@ Kristoffer Ericson Fabio Estevam + mx25pdk i.MX25 mx31pdk i.MX31 mx53ard i.MX53 mx53smd i.MX53 diff --git a/board/freescale/mx25pdk/Makefile b/board/freescale/mx25pdk/Makefile new file mode 100644 index 000..4d45ae3 --- /dev/null +++ b/board/freescale/mx25pdk/Makefile @@ -0,0 +1,49 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) 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 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$(BOARD).o + +COBJS := mx25pdk.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(call cmd_link_o_target, $(OBJS) $(SOBJS)) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mx25pdk/imximage.cfg b/board/freescale/mx25pdk/imximage.cfg new file mode 100644 index 000..f7af7ff --- /dev/null +++ b/board/freescale/mx25pdk/imximage.cfg @@ -0,0 +1,73 @@ +# +# (C) Copyright 2009 +# Stefano Babic DENX Software Engineering sba...@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. +# +# Refer docs/README.imxmage for more details about how-to configure +# and create imximage boot image +# +# The syntax is taken as close as possible with the kwbimage + +# Boot Device : one of +# spi, sd (the board has no nand neither onenand) + +BOOT_FROM sd + +# Device Configuration Data (DCD) +# +# Each entry must have the format: +# Addr-type AddressValue +# +# where: +# Addr-type register length (1,2 or 4 bytes) +# Address absolute address of the register +# value value to be stored in the register + +# EIM config-CS5 init -- CPLD +DATA 4 0xB8002050 0xD843 +DATA 4 0xB8002054 0x22252521 +DATA 4 0xB8002058 0x0A00 + +# DDR2 init +DATA 4 0xB8001004 0x0076E83A +DATA 4 0xB8001010 0x0204 +DATA 4 0xB8001000 0x9221 +DATA 4 0x8f00 0x12344321 +DATA 4 0xB8001000 0xB221 +DATA 1 0x8200 0xda +DATA 1 0x8300 0xda +DATA 1 0x81000400 0xda +DATA 1 0x8333 0xda + +DATA 4 0xB8001000 0x9221 +DATA 1 0x8400 0x12345678 + +DATA 4 0xB8001000 0xA221 +DATA 4 0x8000 0x87654321 +DATA 4 0x8000 0x8
Re: [U-Boot] [PATCH v3] net: ll_temac: Add LL TEMAC driver to u-boot
Dear Michal Simek,
In message <4e60da47.4070...@monstr.eu> you wrote:
>
> >> That driver is not definitely for all ppc systems. That IP is available
> >> just for
> >> Xilinx FPGA where can be possible to use it with Microblaze and xilinx
> >> ppc440 (maybe ppc405).
> >> That DCR handling, which is implemented in this driver, fits to xilinx
> >> ppc440 implementation.
> >> Which means that none can add this IP to any other PPC system out of
> >> Xilinx FPGA.
> >
> > So why not use something like CONFIG_440 in this test, and add an
> > #error for anything else?
You did not answer this - why not using CONFIG_440 instead of
CONFIG_PPC ?
> > Do we actually need this m{f,t}dcr_local() then?
>
> DCR handling is specific for Xilinx ppc440 which means that not all PPC440
> can use it.
> As you see m{f,t}dcr_local setup handling for it that's why it is neeeded.
Then maybe you should chose a better name for it, say m?dcr_xilinx()
or so.
> > My issue is that this code silently breaks or crashes when certain
> > (undocumented) conditions are not met. Preventing this seems not to
> > bee too difficult: add a comment, make it depend on the right CONFIG_
> > settings, and bail out with a clear error message when conditions are
> > not met.
>
> Driver is protected by CONFIG_XILINX_LL_TEMAC option which means that
> any platform is not silently breaks. You can use it with Microblaze and PPC
> and configuration is done (xparameters.h and config.mk files) by u-boot BSP
> in connection to Xilinx EDK which check if DCR can be used or not.
I can only offer you a solution that seems acceptable to me.
> > As for the other part of the problem - you try to mix two different
> > cases: one where you refer to an index, and one where you refer to an
> > address.
>
> In technical sense it is still address not index. It is different addressing
> mode.
The Processor Core User's Manual says for example:
The DCR number (DCRN) is specified by the Device Control
Register Immediate Prefix Register (DCRIPR)
and the DCRF field of the mfdcr instruction.
To me, "number" translates much better into index than into address.
Also, the DCR number are incremented by 1 - if these were addresses in
the common sense, they could only point to 8 bit entities - but the
registers are actually 32 bit wide.
But again, I can only show you what I think could be an acceptable
approach. If you don't like it, please feel free to develop a better
one.
In any case, I will not accept the current (V3) code.
> This obviously doesn't mix well. If there is no better way
> > of doing this, I'd still prefer deriving the index from the offset in
> > a struct than deriving the address from an offset - the intention is
> > to enable the compiler to perform type checking, which is impossible
> > with a typeless base+offset address.
>
> I understand the reasons for that but I can't see any elegant way how to do
> so.
Well, I just proposed one way - not elegant indeed, but I'd be willing
to swallow that.
> If you don't want to add it to mainline because you think that this driver
> is bad/broken/anything, I can do nothing with it and make no sense for me to
> invest my time to it.
I only complain about a few details of the implementation, and I even
lend you a helping hand by offering specific solutions. Feel free to
take or to refuse it. I got better things to do myself, either.
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 ultimate barrier is one's viewpoint.
- Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv6] new tool mkenvimage: generates an env image from an arbitrary config file
On Friday, September 02, 2011 04:48:03 David Wagner wrote: > This tool takes a key=value configuration file (same as would a `printenv' > show) and generates the corresponding environment image, ready to be > flashed. > > use case: flash the environment with an external tool Acked-by: Mike Frysinger -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 v5 1/3] net: Adds Fast Ethernet Controller driver for Armada100
On Friday, September 02, 2011 01:18:39 Ajay Bhargav wrote: > This patch adds support for Fast Ethernet Controller driver for > Armada100 series. Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 7/8] km_arm: change CONFIG_SYS_TEXT_BASE to end of RAM
This allows to test a larger part of the RAM in the memory tests. Signed-off-by: Valentin Longchamp Signed-off-by: Holger Brunck Cc: Prafulla Wadaskar --- include/configs/km/km_arm.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h index b1243ad..54c13ce 100644 --- a/include/configs/km/km_arm.h +++ b/include/configs/km/km_arm.h @@ -54,7 +54,7 @@ #include "asm/arch/config.h" -#define CONFIG_SYS_TEXT_BASE 0x0400 /* code address after reloc */ +#define CONFIG_SYS_TEXT_BASE 0x07d0 /* code address after reloc */ #define CONFIG_SYS_MEMTEST_START 0x0040/* 4M */ #define CONFIG_SYS_MEMTEST_END 0x007f /*(_8M -1) */ #define CONFIG_SYS_LOAD_ADDR 0x0080 /* default load adr- 8M */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/8] POST: support for km_arm and mem_regions test definition
This series adds support for POST on the km_arm boards. These boards use a jumper to run some self-tests at the board power-up. There are some adaptations for POST to run on the ARM architecture. This series defines a new mem_regions POST test. This test also takes place before relocation, but it only tests some regions of the RAM so that it is quicker. Changes for v2: - added CONFIG_POST_EXTERNAL_WORD_FUNCS to allow to redefine post_word_load/store in the board support file when the proposed functions are not suitable. Changes for v3: - moved COFNIG_POST_EXTERNAL_WORD_FUNCS to an individual patch - moved memory test configuration for km_arm from post to board code Valentin Longchamp (8): POST/arm: adaptations needed for POST on ARM to work POST: allow redefinition of post_word_load/store POST: add post_log_res field for post results in global data POST: make env test flags fetching optional POST: drivers/memory.c coding style cleanup POST: add new memory regions test km_arm: change CONFIG_SYS_TEXT_BASE to end of RAM km_arm: enable POST for these boards arch/arm/include/asm/global_data.h |5 + arch/arm/lib/board.c|2 + arch/blackfin/include/asm/global_data.h |1 + arch/nios2/include/asm/global_data.h|1 + arch/powerpc/include/asm/global_data.h |1 + arch/sparc/include/asm/global_data.h|1 + board/keymile/km_arm/km_arm.c | 32 ++ include/configs/km/km_arm.h |8 ++- include/post.h | 10 ++ post/drivers/memory.c | 173 +++--- post/post.c | 29 -- post/tests.c| 15 +++- 12 files changed, 203 insertions(+), 75 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/8] POST/arm: adaptations needed for POST on ARM to work
For post to run on ARM, 3 things are needed:
- post_log_word to be defined in gd
- a post.h include in arch/arm/lib/board.c
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
Cc: Mike Frysinger
---
Changes for v2:
- introduced CONFIG_POST_EXTERNAL_WORD_FUNCS
Changes for v3:
- removed CONFIG_POST_EXTERNAL_WORD_FUNCS. This is now in a separate
patch
---
arch/arm/include/asm/global_data.h |4
arch/arm/lib/board.c |2 ++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index ef9959e..4ab17ae 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -75,6 +75,10 @@ typedef struct global_data {
#endif
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
+ unsigned long post_log_word; /* Record POST activities */
+ unsigned long post_init_f_time; /* When post_init_f started */
+#endif
} gd_t;
/*
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 41ef492..f929acd 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -49,6 +49,8 @@
#include
#include
#include
+#include
+#include
#ifdef CONFIG_BITBANGMII
#include
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/8] POST: drivers/memory.c coding style cleanup
This is needed for a further patch adding a new memory test.
Signed-off-by: Valentin Longchamp
Acked-by: Mike Frysinger
---
post/drivers/memory.c | 118 +
1 files changed, 60 insertions(+), 58 deletions(-)
diff --git a/post/drivers/memory.c b/post/drivers/memory.c
index 2edb745..66039e5 100644
--- a/post/drivers/memory.c
+++ b/post/drivers/memory.c
@@ -250,7 +250,7 @@ static int memory_post_dataline(unsigned long long * pmem)
hi = (temp64>>32) & 0x;
lo = temp64 & 0x;
- post_log ("Memory (date line) error at %08x, "
+ post_log("Memory (date line) error at %08x, "
"wrote %08x%08x, read %08x%08x !\n",
pmem, pathi, patlo, hi, lo);
ret = -1;
@@ -281,7 +281,7 @@ static int memory_post_addrline(ulong *testaddr, ulong
*base, ulong size)
}
#endif
if(readback == *testaddr) {
- post_log ("Memory (address line) error at
%08x<->%08x, "
+ post_log("Memory (address line) error at
%08x<->%08x, "
"XOR value %08x !\n",
testaddr, target, xor);
ret = -1;
@@ -291,7 +291,7 @@ static int memory_post_addrline(ulong *testaddr, ulong
*base, ulong size)
return ret;
}
-static int memory_post_test1 (unsigned long start,
+static int memory_post_test1(unsigned long start,
unsigned long size,
unsigned long val)
{
@@ -303,13 +303,13 @@ static int memory_post_test1 (unsigned long start,
for (i = 0; i < size / sizeof (ulong); i++) {
mem[i] = val;
if (i % 1024 == 0)
- WATCHDOG_RESET ();
+ WATCHDOG_RESET();
}
- for (i = 0; i < size / sizeof (ulong) && ret == 0; i++) {
+ for (i = 0; i < size / sizeof (ulong) && !ret; i++) {
readback = mem[i];
if (readback != val) {
- post_log ("Memory error at %08x, "
+ post_log("Memory error at %08x, "
"wrote %08x, read %08x !\n",
mem + i, val, readback);
@@ -317,13 +317,13 @@ static int memory_post_test1 (unsigned long start,
break;
}
if (i % 1024 == 0)
- WATCHDOG_RESET ();
+ WATCHDOG_RESET();
}
return ret;
}
-static int memory_post_test2 (unsigned long start, unsigned long size)
+static int memory_post_test2(unsigned long start, unsigned long size)
{
unsigned long i;
ulong *mem = (ulong *) start;
@@ -333,13 +333,13 @@ static int memory_post_test2 (unsigned long start,
unsigned long size)
for (i = 0; i < size / sizeof (ulong); i++) {
mem[i] = 1 << (i % 32);
if (i % 1024 == 0)
- WATCHDOG_RESET ();
+ WATCHDOG_RESET();
}
- for (i = 0; i < size / sizeof (ulong) && ret == 0; i++) {
+ for (i = 0; i < size / sizeof (ulong) && !ret; i++) {
readback = mem[i];
if (readback != (1 << (i % 32))) {
- post_log ("Memory error at %08x, "
+ post_log("Memory error at %08x, "
"wrote %08x, read %08x !\n",
mem + i, 1 << (i % 32), readback);
@@ -347,13 +347,13 @@ static int memory_post_test2 (unsigned long start,
unsigned long size)
break;
}
if (i % 1024 == 0)
- WATCHDOG_RESET ();
+ WATCHDOG_RESET();
}
return ret;
}
-static int memory_post_test3 (unsigned long start, unsigned long size)
+static int memory_post_test3(unsigned long start, unsigned long size)
{
unsigned long i;
ulong *mem = (ulong *) start;
@@ -363,13 +363,13 @@ static int memory_post_test3 (unsigned long start,
unsigned long size)
for (i = 0; i < size / sizeof (ulong); i++) {
mem[i] = i;
if (i % 1024 == 0)
- WATCHDOG_RESET ();
+ WATCHDOG_RESET();
}
- for (i = 0; i < size / sizeof (ulong) && ret == 0; i++) {
+ for (i = 0; i < size / sizeof (ulong) && !ret; i++) {
readback = mem[i];
if (readback != i) {
- post_log ("Memory error at %08x, "
+ post_log("Memory error at %08x, "
"wrote %08x, read %08x !\n",
[U-Boot] [PATCH v3 2/8] POST: allow redefinition of post_word_load/store
The predefinde post_word_load/store functions do not fit all boards,
so we introduce a way to define post_word_load/store as externs in
post.h that then can be defined in board specific files. This is done
with the CONFIG_POST_EXTERNAL_WORD_FUNCS #define
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
---
include/post.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/post.h b/include/post.h
index bb3138d..d859f9f 100644
--- a/include/post.h
+++ b/include/post.h
@@ -33,6 +33,7 @@
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
+#ifndef CONFIG_POST_EXTERNAL_WORD_FUNCS
#ifdef CONFIG_SYS_POST_WORD_ADDR
#define _POST_WORD_ADDRCONFIG_SYS_POST_WORD_ADDR
#else
@@ -85,6 +86,13 @@ static inline void post_word_store (ulong value)
{
out_le32((volatile void *)(_POST_WORD_ADDR), value);
}
+
+#else
+
+extern ulong post_word_load(void);
+extern void post_word_store(ulong value);
+
+#endif /* CONFIG_POST_EXTERNAL_WORD_FUNCS */
#endif /* defined (CONFIG_POST) || defined(CONFIG_LOGBUFFER) */
#endif /* __ASSEMBLY__ */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/8] POST: add post_log_res field for post results in global data
The current post_log_word in global data is currently split into 2x
16 bits: half for the test start, half for the test success.
Since we alredy have more than 16 POST tests defined and more could
be defined, this may result in an overflow and the post_output_backlog
would not work for the tests defined further of these 16 positions.
An additional field is added to global data so that we can now support up
to 32 (depending of architecture) tests. The post_log_word is only used
to record the start of the test and the new field post_log_res for the
test success (or failure). The post_output_backlog is for this change
also adapted.
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
Acked-by: Mike Frysinger
---
arch/arm/include/asm/global_data.h |1 +
arch/blackfin/include/asm/global_data.h |1 +
arch/nios2/include/asm/global_data.h|1 +
arch/powerpc/include/asm/global_data.h |1 +
arch/sparc/include/asm/global_data.h|1 +
post/post.c |9 +
6 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 4ab17ae..efcf652 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -77,6 +77,7 @@ typedef struct global_data {
charenv_buf[32];/* buffer for getenv() before reloc. */
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
unsigned long post_log_word; /* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
} gd_t;
diff --git a/arch/blackfin/include/asm/global_data.h
b/arch/blackfin/include/asm/global_data.h
index eba5e93..62cd631 100644
--- a/arch/blackfin/include/asm/global_data.h
+++ b/arch/blackfin/include/asm/global_data.h
@@ -50,6 +50,7 @@ typedef struct global_data {
unsigned long env_valid;/* Checksum of Environment valid? */
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
unsigned long post_log_word;/* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
diff --git a/arch/nios2/include/asm/global_data.h
b/arch/nios2/include/asm/global_data.h
index 2c4a719..1f0bbe8 100644
--- a/arch/nios2/include/asm/global_data.h
+++ b/arch/nios2/include/asm/global_data.h
@@ -34,6 +34,7 @@ typedef struct global_data {
unsigned long env_valid; /* Checksum of Environment valid */
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
unsigned long post_log_word; /* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
void**jt; /* Standalone app jump table */
diff --git a/arch/powerpc/include/asm/global_data.h
b/arch/powerpc/include/asm/global_data.h
index a33ca2f..fbfe8c0 100644
--- a/arch/powerpc/include/asm/global_data.h
+++ b/arch/powerpc/include/asm/global_data.h
@@ -160,6 +160,7 @@ typedef struct global_data {
#endif
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
unsigned long post_log_word; /* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
#ifdef CONFIG_BOARD_TYPES
diff --git a/arch/sparc/include/asm/global_data.h
b/arch/sparc/include/asm/global_data.h
index 9b14674..4b62250 100644
--- a/arch/sparc/include/asm/global_data.h
+++ b/arch/sparc/include/asm/global_data.h
@@ -58,6 +58,7 @@ typedef struct global_data {
#endif
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
unsigned long post_log_word;/* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
#ifdef CONFIG_BOARD_TYPES
diff --git a/post/post.c b/post/post.c
index 1b7f2aa..03c521f 100644
--- a/post/post.c
+++ b/post/post.c
@@ -100,6 +100,7 @@ void post_bootmode_init (void)
/* Reset activity record */
gd->post_log_word = 0;
+ gd->post_log_res = 0;
}
int post_bootmode_get (unsigned int *last_test)
@@ -123,12 +124,12 @@ int post_bootmode_get (unsigned int *last_test)
/* POST tests run before relocation only mark status bits */
static void post_log_mark_start ( unsigned long testid )
{
- gd->post_log_word |= (testid)<<16;
+ gd->post_log_word |= testid;
}
static void post_log_mark_succ ( unsigned long testid )
{
- gd->post_log_word |= testid;
+ gd->post_log_res |= testid;
}
/* ... and the messages are output once we are relocated */
@@ -137,9 +138,9 @@ void post_output_backlog ( void )
int j;
f
[U-Boot] [PATCH v3 8/8] km_arm: enable POST for these boards
The current km_arm boards have a Power-On test jumper. When this
jumper is set, this triggers some Power-On tests on the board.
This patch enables the support of this jumper for starting the
memory_regions test when the jumper is set.
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
Cc: Prafulla Wadaskar
---
Changes for v2:
- adapted to CONFIG_POST_EXTERNAL_WORD_FUNCS
- implemented suggestion from Sergei
Changes for v3:
- moved arch_memory_test_prepare from post/board/km_arm to
board/keymile/km_arm/km_arm.c
---
board/keymile/km_arm/km_arm.c | 32
include/configs/km/km_arm.h |6 ++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index 69f86f5..83e6736 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -483,6 +483,38 @@ int get_scl(void)
}
#endif
+#if defined(CONFIG_POST)
+
+#define KM_POST_EN_L 44
+
+int post_hotkeys_pressed(void)
+{
+ return !kw_gpio_get_value(KM_POST_EN_L);
+}
+
+ulong post_word_load(void)
+{
+ volatile void* addr = (void *) (gd->ram_size - BOOTCOUNT_ADDR + 4);
+ return in_le32(addr);
+
+}
+void post_word_store(ulong value)
+{
+ volatile void* addr = (void *) (gd->ram_size - BOOTCOUNT_ADDR + 4);
+ out_le32(addr, value);
+}
+
+int arch_memory_test_prepare(u32 *vstart, u32 *size, phys_addr_t *phys_offset)
+{
+ *vstart = CONFIG_SYS_SDRAM_BASE;
+
+ /* we go up to relocation plus a 1 MB margin */
+ *size = CONFIG_SYS_TEXT_BASE - (1<<20);
+
+ return 0;
+}
+#endif
+
#if defined(CONFIG_SYS_EEPROM_WREN)
int eeprom_write_enable(unsigned dev_addr, int state)
{
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 54c13ce..82275a6 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -271,4 +271,10 @@ int get_scl(void);
/* address for the bootcount (taken from end of RAM) */
#define BOOTCOUNT_ADDR (CONFIG_KM_RESERVED_PRAM)
+/* enable POST tests with log */
+#define CONFIG_POST(CONFIG_SYS_POST_MEM_REGIONS)
+#define CONFIG_POST_SKIP_ENV_FLAGS
+#define CONFIG_POST_EXTERNAL_WORD_FUNCS
+#define CONFIG_CMD_DIAG
+
#endif /* _CONFIG_KM_ARM_H */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/8] POST: make env test flags fetching optional
Some boards have the environment variables defined in a slow EEPROM. post_run
accesses these environment variables to define which tests have to be run (in
post_get_flags). This is very slow before the code relocation on some boards
with a slow I2C EEPROM for environement variables.
This patch adds a config option to skip the fetching of the test flags in the
environment variables. The test flags assigned to the tests then only are the
ones statically defined for the test in post/tests.c.
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
Acked-by: Mike Frysinger
---
post/post.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/post/post.c b/post/post.c
index 03c521f..8b2cb3c 100644
--- a/post/post.c
+++ b/post/post.c
@@ -170,7 +170,8 @@ static void post_bootmode_test_off (void)
post_word_store (word);
}
-static void post_get_flags (int *test_flags)
+#ifndef CONFIG_POST_SKIP_ENV_FLAGS
+static void post_get_env_flags(int *test_flags)
{
int flag[] = { POST_POWERON, POST_NORMAL, POST_SLOWTEST,
POST_CRITICAL };
@@ -183,10 +184,6 @@ static void post_get_flags (int *test_flags)
int last;
int i, j;
- for (j = 0; j < post_list_size; j++) {
- test_flags[j] = post_list[j].flags;
- }
-
for (i = 0; i < varnum; i++) {
if (getenv_f(var[i], list, sizeof (list)) <= 0)
continue;
@@ -224,6 +221,19 @@ static void post_get_flags (int *test_flags)
name = s + 1;
}
}
+}
+#endif
+
+static void post_get_flags(int *test_flags)
+{
+ int j;
+
+ for (j = 0; j < post_list_size; j++)
+ test_flags[j] = post_list[j].flags;
+
+#ifndef CONFIG_POST_SKIP_ENV_FLAGS
+ post_get_env_flags(test_flags);
+#endif
for (j = 0; j < post_list_size; j++) {
if (test_flags[j] & POST_POWERON) {
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/8] POST: add new memory regions test
This test is similar to the actual POST memory test but quicker and
far less complete. It checks the address and data lines and then only
tests some regularly placed sub regions of the RAM.
This can be useful when we want to test the RAM but we do not have enough
time to run the full memory test.
The POST memory test code was rearranged in order to avoid code duplication
between the two tests but the memory test functionnality remains the same.
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
Cc: Mike Frysinger
---
Changes for v3:
- cosmetic changes in the test list
---
include/post.h|2 +
post/drivers/memory.c | 81 +---
post/tests.c | 15 -
3 files changed, 78 insertions(+), 20 deletions(-)
diff --git a/include/post.h b/include/post.h
index d859f9f..35c86f7 100644
--- a/include/post.h
+++ b/include/post.h
@@ -194,6 +194,8 @@ extern int post_hotkeys_pressed(void);
#define CONFIG_SYS_POST_BSPEC5 0x0010
#define CONFIG_SYS_POST_CODEC 0x0020
#define CONFIG_SYS_POST_COPROC 0x0040
+#define CONFIG_SYS_POST_FLASH 0x0080
+#define CONFIG_SYS_POST_MEM_REGIONS0x0100
int memory_post_test(int flags);
#endif /* CONFIG_POST */
diff --git a/post/drivers/memory.c b/post/drivers/memory.c
index 66039e5..90af549 100644
--- a/post/drivers/memory.c
+++ b/post/drivers/memory.c
@@ -153,7 +153,7 @@
#include
#include
-#if CONFIG_POST & CONFIG_SYS_POST_MEMORY
+#if CONFIG_POST & (CONFIG_SYS_POST_MEMORY | CONFIG_SYS_POST_MEM_REGIONS)
DECLARE_GLOBAL_DATA_PTR;
@@ -413,23 +413,29 @@ static int memory_post_test4(unsigned long start,
unsigned long size)
return ret;
}
-static int memory_post_tests(unsigned long start, unsigned long size)
+static int memory_post_test_lines(unsigned long start, unsigned long size)
{
int ret = 0;
- if (!ret)
- ret = memory_post_dataline((unsigned long long *)start);
+ ret = memory_post_dataline((unsigned long long *)start);
WATCHDOG_RESET();
if (!ret)
ret = memory_post_addrline((ulong *)start, (ulong *)start,
- size);
+ size);
WATCHDOG_RESET();
if (!ret)
- ret = memory_post_addrline((ulong *)(start + size - 8),
- (ulong *)start, size);
+ ret = memory_post_addrline((ulong *)(start+size-8),
+ (ulong *)start, size);
WATCHDOG_RESET();
- if (!ret)
- ret = memory_post_test1(start, size, 0x);
+
+ return ret;
+}
+
+static int memory_post_test_patterns(unsigned long start, unsigned long size)
+{
+ int ret = 0;
+
+ ret = memory_post_test1(start, size, 0x);
WATCHDOG_RESET();
if (!ret)
ret = memory_post_test1(start, size, 0x);
@@ -453,6 +459,36 @@ static int memory_post_tests(unsigned long start, unsigned
long size)
return ret;
}
+static int memory_post_test_regions(unsigned long start, unsigned long size)
+{
+ unsigned long i;
+ int ret = 0;
+
+ for (i = 0; i < (size >> 20) && (!ret); i++) {
+ if (!ret)
+ ret = memory_post_test_patterns(i << 20, 0x800);
+ if (!ret)
+ ret = memory_post_test_patterns((i << 20) + 0xff800,
+ 0x800);
+ }
+
+ return ret;
+}
+
+static int memory_post_tests(unsigned long start, unsigned long size)
+{
+ int ret = 0;
+
+ ret = memory_post_test_lines(start, size);
+ if (!ret)
+ ret = memory_post_test_patterns(start, size);
+
+ return ret;
+}
+
+/*
+ * !! this is only valid, if you have contiguous memory banks !!
+ */
__attribute__((weak))
int arch_memory_test_prepare(u32 *vstart, u32 *size, phys_addr_t *phys_offset)
{
@@ -487,6 +523,21 @@ void arch_memory_failure_handle(void)
return;
}
+int memory_regions_post_test(int flags)
+{
+ int ret = 0;
+ phys_addr_t phys_offset = 0;
+ u32 memsize, vstart;
+
+ arch_memory_test_prepare(&vstart, &memsize, &phys_offset);
+
+ ret = memory_post_test_lines(vstart, memsize);
+ if (!ret)
+ ret = memory_post_test_regions(vstart, memsize);
+
+ return ret;
+}
+
int memory_post_test(int flags)
{
int ret = 0;
@@ -499,15 +550,7 @@ int memory_post_test(int flags)
if (flags & POST_SLOWTEST) {
ret = memory_post_tests(vstart, memsize);
} else {/* POST_NORMAL */
- unsigned long i;
- for (i = 0; i < (memsize >> 20) && !ret; i++) {
- if (!ret)
- ret = memory_post_tests(vstart +
-
[U-Boot] [MPC8379E-rdb] Question about master bus busy after enabling I2C.
Hi, here is a question about I2C initialization. I2C driver of our own references i2c driver implemented in fsl_i2c.c The init flow is almost the same. After writing enable-bit MEN into i2c control register to enable I2C controler, sometimes, Bit 2 in i2c status, MBB bit, will be set, indicating i2c master bus busy. And this will cause wait4bus return with failing. Is there anyone around who used to face this question? Or is there any suggestion or advice anyway? Thanks in advance. Best Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] POST/km_arm: add POST memory tests infrastructure
On Thursday, August 18, 2011 06:44:34 Marek Vasut wrote: > On Sunday, August 14, 2011 09:49:27 PM Mike Frysinger wrote: > > On Wednesday, August 03, 2011 08:37:05 Valentin Longchamp wrote: > > > This patch adds a board support for km_arm in the POST framework. > > > It consists of a memory test configuration with the redefinition of > > > the arch_memory_test_prepare function. > > > > > > Signed-off-by: Valentin Longchamp > > > Signed-off-by: Holger Brunck > > > --- > > > > > > post/board/km_arm/Makefile | 29 + > > > post/board/km_arm/memory.c | 37 > > > + > > > > i'm not sure post/board// is something we want to continue. > > putting the post logic into your normal board// dir works fine. > > might i suggest board/km_arm/post.c ... > > post/board/... seems fine to me actually ... there might be more post tests > for the board so poluting usual board directory would be stupid. no it wouldnt. post tests that are board specific belong in the board specific location: board//. creating a mirror of that existing hierarchy is stupid, and most board dirs have very few files, so there really isn't all that much to clutter up in the first place. -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 6/8] POST/km_arm: add POST memory tests infrastructure
On Friday, September 02, 2011 08:39:15 Valentin Longchamp wrote: > On 09/02/2011 12:10 AM, Mike Frysinger wrote: > > On Thursday, September 01, 2011 11:39:25 Valentin Longchamp wrote: > >> post/board/km_arm/Makefile | 29 + > >> post/board/km_arm/memory.c | 35 +++ > > > > cant these live in board// ? i'd like to kill off > > post/board/*. > > They sure can. I had not done it since there was a remark from Marek Vasut > in the previous thread, but if post/board/* is going to disappear, the > discussion is not valid any more. thanks ... i missed his post, so i responded. but it doesnt change my response here :). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] ARM: mx25: Print the silicon revison
Print the silicon revison during boot.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Handle the unkown silicon revision in the same way as for mx31.
arch/arm/cpu/arm926ejs/mx25/generic.c | 32 +++-
arch/arm/include/asm/arch-mx25/imx-regs.h |3 ++
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index 76e4b5c..dca8d98 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -105,12 +105,40 @@ ulong imx_get_perclk (int clk)
return lldiv (fref, div);
}
+
+u32 get_cpu_rev(void)
+{
+ u32 srev;
+ u32 system_rev = 0x25000;
+
+ /* read SREV register from IIM module */
+ struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+ srev = readl(&iim->iim_srev);
+
+ switch (srev) {
+ case 0x00:
+ system_rev |= CHIP_REV_1_0;
+ break;
+ case 0x01:
+ system_rev |= CHIP_REV_1_1;
+ break;
+ default:
+ system_rev |= 0x8000;
+ break;
+ }
+
+ return system_rev;
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo (void)
{
char buf[32];
-
- printf ("CPU: Freescale i.MX25 at %s MHz\n\n",
+ u32 cpurev = get_cpu_rev();
+
+ printf("CPU: Freescale i.MX25 rev%d.%d%s at %s MHz\n\n",
+ (cpurev & 0xF0) >> 4, (cpurev & 0x0F),
+ ((cpurev & 0x8000) ? " unknown" : ""),
strmhz (buf, imx_get_armclk ()));
return 0;
}
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index 7e34050..d0c6d00 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -352,4 +352,7 @@ struct aips_regs {
#define GPIO3_BASE_ADDRIMX_GPIO3_BASE
#define GPIO4_BASE_ADDRIMX_GPIO4_BASE
+#define CHIP_REV_1_0 0x10
+#define CHIP_REV_1_1 0x11
+
#endif /* _IMX_REGS_H */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] ARM: mx25: Print the source of reset
Print the source of reset during boot.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Fix the logic for detecting the reset cause
arch/arm/cpu/arm926ejs/mx25/generic.c | 25 -
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index dca8d98..ed4b3e0 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -105,6 +105,28 @@ ulong imx_get_perclk (int clk)
return lldiv (fref, div);
}
+static char *get_reset_cause(void)
+{
+ /* read RCSR register from CCM module */
+ struct ccm_regs *ccm =
+ (struct ccm_regs *)IMX_CCM_BASE;
+
+ u32 cause = readl(&ccm->rcsr) & 0x0f;
+
+ if (cause == 0)
+ return "POR";
+ else if (cause == 1)
+ return "RST";
+ else if ((cause & 2) == 2)
+ return "WDOG";
+ else if ((cause & 4) == 4)
+ return "SW RESET";
+ else if ((cause & 8) == 8)
+ return "JTAG";
+ else
+ return "unknown reset";
+
+}
u32 get_cpu_rev(void)
{
@@ -136,10 +158,11 @@ int print_cpuinfo (void)
char buf[32];
u32 cpurev = get_cpu_rev();
- printf("CPU: Freescale i.MX25 rev%d.%d%s at %s MHz\n\n",
+ printf("CPU: Freescale i.MX25 rev%d.%d%s at %s MHz\n",
(cpurev & 0xF0) >> 4, (cpurev & 0x0F),
((cpurev & 0x8000) ? " unknown" : ""),
strmhz (buf, imx_get_armclk ()));
+ printf("Reset cause: %s\n\n", get_reset_cause());
return 0;
}
#endif
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] POST: add new memory regions test
Acked-by: Mike Frysinger -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 v3 1/8] POST/arm: adaptations needed for POST on ARM to work
Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] omap3evm: Set environment variable 'ethaddr'
It is now responsibility of the board specific init
code to set the environment variable corresponding
to the MAC address.
Signed-off-by: Sanjeev Premi
---
Changes in v2:
- Ensure that environment variable is set iff
it wasn't already set earlier.
Tested on omap3evm at against latest master at:
bd061a5 : Merge branch 'master' of git://git.denx.de/u-boot-sh
To build successfully, make this substituion in board/ti/evm/evm.c:
-#include
+#include
This problem was addressed in separate RFC. Patches
will follow shortly. (Substituion is not real fix).
board/ti/evm/evm.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 30c1c57..ae3f713 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -216,7 +216,22 @@ int board_eth_init(bd_t *bis)
{
int rc = 0;
#ifdef CONFIG_SMC911X
+#define STR_ENV_ETHADDR"ethaddr"
+
+ struct eth_device *dev;
+ uchar eth_addr[6];
+
rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+
+ if (!eth_getenv_enetaddr(STR_ENV_ETHADDR, eth_addr)) {
+ dev = eth_get_dev_by_index(0);
+ if (dev) {
+ eth_setenv_enetaddr(STR_ENV_ETHADDR, dev->enetaddr);
+ } else {
+ printf("omap3evm: Couldn't get eth device\n");
+ rc = -1;
+ }
+ }
#endif
return rc;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/4] fdt: ARM: Add device tree control of U-Boot (CONFIG_OF_CONTROL)
On Thursday, September 01, 2011 16:49:06 Simon Glass wrote: > --- a/arch/arm/include/asm/global_data.h > +++ b/arch/arm/include/asm/global_data.h > > + const void *blob; /* Our device tree, NULL if none */ let's call it "fdt_blob" or something less generic than "blob" -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] [RFC PATCH 0/4] Run-time configuration of U-Boot via a flat device tree (fdt)
On Thursday, September 01, 2011 16:49:05 Simon Glass wrote: > At present in U-Boot configuration is mostly done using CONFIG options in > the board file. This patch set aims to make it possible for a single > U-Boot binary to support multiple boards, with the exact configuration of > each board controlled by a flat device tree (fdt). This is the approach > recently taken by the ARM Linux kernel and has been used by PowerPC for > some time. > > The fdt is a convenient vehicle for implementing run-time configuration for > three reasons. Firstly it is easy to use, being a simple text file. It is > extensible since it consists of nodes and properties in a nice hierarchical > format. > > Finally, there is already excellent infrastructure for the fdt: a compiler > checks the text file and converts it to a compact binary format, and a > library is already available in U-Boot (libfdt) for handling this format. i guess the important questions for u-boot: size and speed. have you done any comparisons in this area ? -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] [RFC PATCH 0/4] Run-time configuration of U-Boot via a flat device tree (fdt)
HI Mike,
On Fri, Sep 2, 2011 at 9:33 AM, Mike Frysinger wrote:
> On Thursday, September 01, 2011 16:49:05 Simon Glass wrote:
>> At present in U-Boot configuration is mostly done using CONFIG options in
>> the board file. This patch set aims to make it possible for a single
>> U-Boot binary to support multiple boards, with the exact configuration of
>> each board controlled by a flat device tree (fdt). This is the approach
>> recently taken by the ARM Linux kernel and has been used by PowerPC for
>> some time.
>>
>> The fdt is a convenient vehicle for implementing run-time configuration for
>> three reasons. Firstly it is easy to use, being a simple text file. It is
>> extensible since it consists of nodes and properties in a nice hierarchical
>> format.
>>
>> Finally, there is already excellent infrastructure for the fdt: a compiler
>> checks the text file and converts it to a compact binary format, and a
>> library is already available in U-Boot (libfdt) for handling this format.
>
> i guess the important questions for u-boot: size and speed. have you done any
> comparisons in this area ?
In general the main difference between compile-time and run-time
config is the device init. Rather than spreading CONFIG_ items through
the driiver, we can define a structure which holds the config. Then it
can be set up at driver init, either by assigning from CONFIG items,
or decoding values from the fdt. Using this structure could in some
cases have some small affect on code size and performance within the
driver. For example, if the driver has something like:
for (very tight loop executed 1000 times) {
writel(CONFIG_SOME_VALUE / 9, &periph->reg);
}
then the compiler can work out the value at run time, whereas when the
driver is modified to use a structure:
writel(config.some_value / 9, &periph->reg);
the compiler must actually do the calculation. I don't see much of
this in the code base though. So overall the performance difference is
small, and with a little effort can be close to zero.
In terms of code size, apart from adding the init code to decode from
the fdt, I don't see a difference. I think an fdt_decode library is a
good idea so that drivers have helper functions for doing common tasks
(higher level than the existing fdt_support library, with specific
driver decode support). That means that the fdt decode code size hit
might happen once per driver class, maybe.
Regards,
Simon
> -mike
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/4] Run-time configuration of U-Boot via a flat device tree (fdt)
Hi Jerry, On Fri, Sep 2, 2011 at 4:42 AM, Jerry Van Baren wrote: > Hi Simon, > > On 09/01/2011 04:49 PM, Simon Glass wrote: >> >> At present in U-Boot configuration is mostly done using CONFIG options in >> the >> board file. This patch set aims to make it possible for a single U-Boot >> binary to support multiple boards, with the exact configuration of each >> board >> controlled by a flat device tree (fdt). This is the approach recently >> taken >> by the ARM Linux kernel and has been used by PowerPC for some time. > > Very exciting. I've thought about doing this for years, but never had the > ambition (or time). Thanks for your comments. Yes there was mention of it in the UBML a few years ago: http://lists.denx.de/pipermail/u-boot/2008-August/038052.html where Wolfgang said: > A much more powerful concept is to have U-Boot read and interpret the > DT dynamically - only then can you use the same U-Boot binary image > on different board configurations, which is an important feature for > many board vendors. This is basically what my patch set sets out to do. > > [snip] > >> and add some defines to your board (only ARM is currently supported): >> >> #define CONFIG_OF_CONTROL (to enable run-time config control via >> fdt) >> #define CONFIG_OF_EMBED or CONFIG_OF_SEPARATE >> (either build the fdt blob into U-Boot, or create a separate >> u-boot.dtb) >> #define CONFIG_DEFAULT_DEVICE_TREE "" >> (to specify the name of the device tree file is >> board///.dts) >> >> This patch set does not include any drivers which actually use the fdt. I >> have >> some concerns about spreading fdt code around the U-Boot code base so am >> thinking of having a support file which makes this easier. I can provide a >> UART driver modified to use fdt if there is interest. > > Please. A concrete reference is very useful, especially for discussion. I will try to create a driver for something for which we have a device tree definition in the kernel. Will post to the list as an RFC. > >> It is important to understand that the fdt only selects options available >> in >> the platform / drivers. It cannot add new drivers (yet). So you must still >> have the CONFIG option to enable the driver. For example, you need to >> define >> CONFIG_SYS_NS16550 to bring in the NS16550 driver, but can use the fdt to >> specific the UART clock, peripheral address, etc. In very broad terms, the >> CONFIG options in general control *what* driver files are pulled in, and >> the >> fdt controls *how* those files work. > > Sounds reasonable and practical. One of the things u-boot struggles with is > staying small (but it is nice to be able to make it all inclusive and big if > you have the flash). Yes to some extent this is a halfway house, but it is a way of introducing this feature without changing the way things currently work. I almost feel as if there are two types of configs, and perhaps the naming should recognize that (SELECT_ and CONFIG_?). No, I don't want to modify all the board files... > >> While only ARM is supported in this patch series, it should be easy enough >> to >> add support for other architectures. > > Exercise left for the students. :-) Yes - you can pretty-much just copy the ARM board.c code into your board.c file to try this out. Regards, Simon > > [snip] > > Thanks! > gvb > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/4] fdt: ARM: Add device tree control of U-Boot (CONFIG_OF_CONTROL)
Hi Mike, On Fri, Sep 2, 2011 at 9:32 AM, Mike Frysinger wrote: > On Thursday, September 01, 2011 16:49:06 Simon Glass wrote: >> --- a/arch/arm/include/asm/global_data.h >> +++ b/arch/arm/include/asm/global_data.h >> >> + const void *blob; /* Our device tree, NULL if none */ > > let's call it "fdt_blob" or something less generic than "blob" > -mike > OK, will change to fdt_blob within the global data. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: standardize display of address map size (32-bit vs. 36-bit)
On Sep 2, 2011, at 8:41 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>> Both. I'm think for your patch we'd add some general config option for
>> extra print info.
>
> So you want to see this instead:
>
> /*
> * Display whether this is a 32-bit build or a 36-bit build.
> */
> #ifdef CONFIG_DISPLAY_ADDR_SIZE
> #ifdef CONFIG_PHYS_64BIT
> puts("ADDR: 36-bit address map\n");
> #else
> puts("ADDR: 32-bit address map\n");
> #endif
> #endif
>
> I still like my way better. It eliminates the need to think about another
> CONFIG option. I think adding another CONFIG option is worse than adding
> another line of text.
I think we could introduce kernel style "printk" levels that would allow more
control over something like this.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: standardize display of address map size (32-bit vs. 36-bit)
Kumar Gala wrote: > I think we could introduce kernel style "printk" levels that would allow more > control over something like this. > Or we could implement Kconfig and defconfigs. But neither of these options is going to help me now. -- 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] omap3evm: Set environment variable 'ethaddr'
Dear "Premi, Sanjeev", In message you wrote: > > > Your patch always and unconditionally overwrites any existing > > "ethaddr" settings. This is not acceptable. > > For the EVM, MAC address is always probed from the chip. Hence, I > assumed it safe to set the ethaddr - without checking for env var. This is not what we do in U-Boot, so please fix that. > It was unlikely that someone would be setting it - to different > value. Unlikely? Not so. This is expected standard behaviour. Please don't try to invent a wheel (in a different shape). 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 Save energy: Drive a smaller shell. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: standardize display of address map size (32-bit vs. 36-bit)
Dear Kumar Gala, In message you wrote: > > I think we could introduce kernel style "printk" levels that would allow = > more control over something like this. We can invent many things, or we can keep the code lean and simple. Let's just move this to where it belongs - to some command that prints that information upon explicit request of the user. "bdinfo" comes to mind here. Feel free to run such a command as "preboot" sequence 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 The inappropriate cannot be beautiful. - Frank Lloyd Wright _The Future of Architecture_ (1953) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] dcache: Dcache line size aligned stack buffer allocation
On Thu, Sep 1, 2011 at 3:30 AM, Lukasz Majewski wrote: > > ALLOC_CACHE_ALIGN_BUFFER shall be used in functions, which are using > stack allocated buffers for DMA transfers. > > Signed-off-by: Lukasz Majewski > Signed-off-by: Kyungmin Park > CC: Albert ARIBAUD > --- > Changes for v2: > - ./include/cache.h has been removed and replaced with > simpler macro added to ./include/common.h > Changes for v3: > - change char * to char > - defined table size definition > Changes for v4: > - (type*) added for compiler warning fix > > Signed-off-by: Lukasz Majewski > Signed-off-by: Kyungmin Park > --- > include/common.h | 5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/include/common.h b/include/common.h > index 12a1074..a74c6e8 100644 > --- a/include/common.h > +++ b/include/common.h > @@ -767,6 +767,11 @@ int cpu_release(int nr, int argc, char * const argv[]); > #define ALIGN(x,a) __ALIGN_MASK((x),(typeof(x))(a)-1) > #define __ALIGN_MASK(x,mask) (((x)+(mask))&~(mask)) > > +#define ALLOC_CACHE_ALIGN_BUFFER(type, name, size) \ > + char __##name[size + CONFIG_SYS_CACHELINE_SIZE - 1]; \ It was pointed out to me that we need to make sure that both ends of the resulting buffer are cache line aligned. Or put another way, that the __##name array has enough padding at the beginning and end that an invalidate will be both aligned to the cache line and not effect anything defined after the array on the stack. So the above definition needs to change to something like: char __##name[ROUND(size, CONFIG_SYS_CACHELINE_SIZE) + CONFIG_SYS_CACHELINE_SIZE - 1]; Another thing that concerns me is that the macro takes a type, but the size parameter is specified in bytes, not units of the size of the type. Would it make sense to specify the size in units of the type? It would make almost no sense to specify a size that wasn't a multiple of the size of the type anyway. If we want to do that the the array definition becomes: char __##name[ROUND(size * sizeof(type), CONFIG_SYS_CACHELINE_SIZE) + CONFIG_SYS_CACHELINE_SIZE - 1]; And finally, the ROUND macro is written such that it will always return a value that is larger than it's first parameter. Thus ROUND(CONFIG_SYS_CACHELINE_SIZE, CONFIG_SYS_CACHELINE_SIZE) withh not equal CONFIG_SYS_CACHELINE_SIZE, but actually 2 * CONFIG_SYS_CACHELINE_SIZE. I'm not sure if this is intentional. In fact, the only use of ROUND that is not to round the value of CONFIG_SYS_MALLOC_LEN to a multiple of 4096 is in the common/cmd_sf.c implementation. And there it looks like the author worked around the behavior of ROUND by passing "len_arg - 1", instead of len_arg. So, it looks like a patch to fix ROUND might be in order as well. I'll try and send one today. -Anton > > + type *name = (type *) ALIGN(((typeof(CONFIG_SYS_CACHELINE_SIZE))\ > + (__##name)), > (CONFIG_SYS_CACHELINE_SIZE)); > + > /* Pull in stuff for the build system */ > #ifdef DO_DEPS_ONLY > # include > -- > 1.7.2.3 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common: fix behavior of ROUND macro when input is already rounded
Currently when you call ROUND with a value that is already a multiple of the second parameter it will return a value that is one multiple larger, instead of returning the value passed in. There are only two types of usage of ROUND currently, one in various config files to round CONFIG_SYS_MALLOC_LEN to a multiple of 4096 bytes. The other in cmd_sf.c where the incorrect behavior of ROUND is worked around be subtracting one from the length argument before passing it to ROUND. This patch fixes ROUND and removes the workaround from cmd_sf. It also results in all of the malloc pools that use ROUND to compute their size shrinking by 4KB. Cc: Lukasz Majewski Cc: Mike Frysinger --- I'm not sure if it makes sense to go and add 4KB to each malloc pool effected. What do other people think? I'd be happy to make a v2 that does that. This just seemed like a cleaner v1 to start with. common/cmd_sf.c |2 +- include/common.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/common/cmd_sf.c b/common/cmd_sf.c index 11a491d..27d6e39 100644 --- a/common/cmd_sf.c +++ b/common/cmd_sf.c @@ -53,7 +53,7 @@ static int sf_parse_len_arg(char *arg, ulong *len) return -1; if (round_up_len && flash->sector_size > 0) - *len = ROUND(len_arg - 1, flash->sector_size); + *len = ROUND(len_arg, flash->sector_size); else *len = len_arg; diff --git a/include/common.h b/include/common.h index 12a1074..3f49fef 100644 --- a/include/common.h +++ b/include/common.h @@ -759,7 +759,7 @@ int cpu_release(int nr, int argc, char * const argv[]); #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) -#define ROUND(a,b) (((a) + (b)) & ~((b) - 1)) +#define ROUND(a,b) (((a) + (b) - 1) & ~((b) - 1)) #define DIV_ROUND(n,d) (((n) + ((d)/2)) / (d)) #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) #define roundup(x, y) x) + ((y) - 1)) / (y)) * (y)) -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] MIPS patche
Hi Wolfgang, please pull the following patch from Yao, thanks in advance. The following changes since commit a1118d60423c1fe25afc9df9015f72739f96fd67: MPC8xx: fix build problem for ETX094 board (2011-08-31 22:38:20 +0200) are available in the git repository at: git://git.denx.de/u-boot-mips.git master Yao Cheng (1): MIPS: mips32: fix wrong loop bound in flush_cache() arch/mips/cpu/mips32/cpu.c |4 1 files changed, 4 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: retry the cmd8 to meet 74 clocks requirement in the spec
For some controller it has dynamic clock gating, and only toggle out clk
when the first cmd0 send out, while some card strictly obey the 74
clocks rule, the interval may not be sufficient between the cmd0 and
this cmd8, retry to fulfil the clock requirement.
Signed-off-by: Lei Wen
---
drivers/mmc/mmc.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 7e703c0..f9b2223 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1178,7 +1178,7 @@ block_dev_desc_t *mmc_get_dev(int dev)
int mmc_init(struct mmc *mmc)
{
- int err;
+ int err, retry = 3;
if (mmc->has_init)
return 0;
@@ -1201,7 +1201,19 @@ int mmc_init(struct mmc *mmc)
mmc->part_num = 0;
/* Test for SD version 2 */
- err = mmc_send_if_cond(mmc);
+ /*
+* retry here for 3 times, as for some controller it has dynamic
+* clock gating, and only toggle out clk when the first cmd0 send
+* out, while some card strictly obey the 74 clocks rule, the interval
+* may not be sufficient between the cmd0 and this cmd8, retry to
+* fulfil the clock requirement
+*/
+ do {
+ err = mmc_send_if_cond(mmc);
+ } while (--retry > 0 && err);
+
+ if (err)
+ return err;
/* Now try to get the SD card's operating condition */
err = sd_send_op_cond(mmc);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
