[U-Boot] U-boot's stack space on a Sequoia board
Hello, I recently spent quite a lot of time finding a problem where U-boot was overwriting part of its stack onto my kernel that I had downloaded via tftpboot. The board I am using is a Sequoia, powerpc 440EPx board running U-boot 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12). I found that when I booted my Linux kernel, part of its text space was corrupted upon entry. I traced this back to U-boot writing a command line and board info record into its own stack space (- 2048 bytes). This happens in common/cmd_bootm.c What surprised me was that this board (fairly old now) has 256M of memory, but U-boot's stack pointer was around the 8MB point (the pointer to the board info record passed into my kernel is address 0x007ffe70 -- just under 8M). So I have a couple of questions: 1) Any idea why the stack pointer would be so low in memory? 2) Is there any way to tell, once the board is up and running U-boot, where its stack space is so that I can be sure to avoid running into it? The U-boot that is running on this board wasn't compiled with DEBUG enabled. Thanks for your consideration, - Corey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] arm: exynos4: Fix exynos4_fb structure
Dear Donghwa,
On 13 September 2012 16:45, Piotr Wilczek wrote:
> Signed-off-by: Piotr Wilczek
> Signed-off-by: Kyungmin Park
> CC: Minkyu Kang
> ---
> arch/arm/include/asm/arch-exynos/fb.h |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/fb.h
> b/arch/arm/include/asm/arch-exynos/fb.h
> index b10b0da..f7c6d76 100644
> --- a/arch/arm/include/asm/arch-exynos/fb.h
> +++ b/arch/arm/include/asm/arch-exynos/fb.h
> @@ -103,7 +103,7 @@ struct exynos4_fb {
>
> unsigned int vidintcon0;
> unsigned int vidintcon1;
> - unsigned int res9[1];
> + unsigned int res9[2];
>
> unsigned int w1keycon0;
> unsigned int w1keycon1;
> @@ -120,14 +120,14 @@ struct exynos4_fb {
> unsigned int w4keyalpha;
>
> unsigned int dithmode;
> - unsigned int res10[2];
> + unsigned int res10[3];
>
> unsigned int win0map;
> unsigned int win1map;
> unsigned int win2map;
> unsigned int win3map;
> unsigned int win4map;
> - unsigned int res11[1];
> + unsigned int res11[2];
>
> unsigned int wpalcon_h;
> unsigned int wpalcon_l;
> @@ -141,7 +141,7 @@ struct exynos4_fb {
> unsigned int i80ifconb1;
>
> unsigned int colorgaincon;
> - unsigned int res13[2];
> + unsigned int res13[3];
>
> unsigned int ldi_cmdcon0;
> unsigned int ldi_cmdcon1;
> --
Please check it.
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] U-boot's stack space on a Sequoia board
Dear Corey Ashford, In message <5053ccb5.3070...@linux.vnet.ibm.com> you wrote: > > The board I am using is a Sequoia, powerpc 440EPx board running U-boot > 1.2.0-gc0c292b2 (Jun 5 2007 - 07:16:12). Frankly: we don't really care any longer about 5 years old code. The Sequoia board is well supported in mainline U-Boot, so please update and use current code instead. > So I have a couple of questions: Please update, then try again. 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 "Pull the wool over your own eyes!"- J.R. "Bob" Dobbs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] arm: exynos4: universal_C210: add display support
Dear Piotr,
On 13 September 2012 16:45, Piotr Wilczek wrote:
> This patch add support for display on Universal C210 board.
> Width of displayed logo must be not bigger than 480 pixel and
> is limited by width of the screen.
> Tizen logo size is 520x120 pixels should be reseized to be
> displayed corectly on Universal C210.
>
> Signed-off-by: Piotr Wilczek
> Signed-off-by: Kyungmin Park
> CC: Minkyu Kang
> ---
> board/samsung/universal_c210/universal.c | 225
> +++---
> include/configs/s5pc210_universal.h | 13 ++
> 2 files changed, 220 insertions(+), 18 deletions(-)
>
> diff --git a/board/samsung/universal_c210/universal.c
> b/board/samsung/universal_c210/universal.c
> index 772ade5..da28f7a 100644
> --- a/board/samsung/universal_c210/universal.c
> +++ b/board/samsung/universal_c210/universal.c
>
> +static void init_pmic_lcd(void)
> +{
> + unsigned char val;
> + int ret = 0;
> +
> + struct pmic *p = get_pmic();
> +
> + if (pmic_probe(p))
> + return;
> +
> + /* LDO7 1.8V */
> + val = 0x02; /* (1800 - 1600) / 100; */
> + ret |= pmic_reg_write(p, MAX8998_REG_LDO7, val);
> +
> + /* LDO17 3.0V */
> + val = 0xe; /* (3000 - 1600) / 100; */
> + ret |= pmic_reg_write(p, MAX8998_REG_LDO17, val);
> +
> + /* Disable unneeded regulators */
> + /*
> +* ONOFF1
> +* Buck1 ON, Buck2 OFF, Buck3 ON, Buck4 ON
> +* LDO2 ON, LDO3 OFF, LDO4 OFF, LDO5 ON
> +*/
> + val = 0xB9;
> + ret |= pmic_reg_write(p, MAX8998_REG_ONOFF1, val);
> +
> + /* ONOFF2
> +* LDO6 OFF, LDO7 ON, LDO8 OFF, LDO9 ON,
> +* LDO10 OFF, LDO11 OFF, LDO12 OFF, LDO13 OFF
> +*/
> + val = 0x50;
> + ret |= pmic_reg_write(p, MAX8998_REG_ONOFF2, val);
> +
> + /* ONOFF3
> +* LDO14 OFF, LDO15 OFF, LGO16 OFF, LDO17 OFF
> +* EPWRHOLD OFF, EBATTMON OFF, ELBCNFG2 OFF, ELBCNFG1 OFF
> +*/
> + val = 0x00;
> + ret |= pmic_reg_write(p, MAX8998_REG_ONOFF3, val);
> +
> + if (ret)
> + puts("LCD pmic initialisation error!\n");
> +}
> +
> +static void fimd_clk_set(void)
> +{
> + unsigned int cfg = 0;
> +
> + /* LCD0_BLK FIFO S/W reset */
> + cfg = readl(EXYNOS4_DISPLAY_CONTROL);
> + cfg |= EXYNOS_DISPLAYCONTROL_FIFORST_LBLK0;
> + writel(cfg, EXYNOS4_DISPLAY_CONTROL);
> +
> + cfg = 0;
> +
> + /* FIMD of LBLK0 Bypass Selection */
> + cfg = readl(EXYNOS4_DISPLAY_CONTROL);
> + cfg &= ~EXYNOS_DISPLAYCONTROL_FIFORST_LBLK0;
> + cfg |= EXYNOS_DISPLAYCONTROL_FIMDBYPASS_LBLK0;
> + writel(cfg, EXYNOS4_DISPLAY_CONTROL);
No..
We don't allow direct access.
And this function looks same with exynos4_set_system_display.
> +}
> +
> +static void lcd_cfg_gpio(void)
> +{
> + unsigned int i, f3_end = 4;
> +
> + for (i = 0; i < 8; i++) {
> + /* set GPF0,1,2[0:7] for RGB Interface and Data lines (32bit)
> */
> + s5p_gpio_cfg_pin(&gpio1->f0, i, GPIO_FUNC(2));
> + s5p_gpio_cfg_pin(&gpio1->f1, i, GPIO_FUNC(2));
> + s5p_gpio_cfg_pin(&gpio1->f2, i, GPIO_FUNC(2));
> + /* pull-up/down disable */
> + s5p_gpio_set_pull(&gpio1->f0, i, GPIO_PULL_NONE);
> + s5p_gpio_set_pull(&gpio1->f1, i, GPIO_PULL_NONE);
> + s5p_gpio_set_pull(&gpio1->f2, i, GPIO_PULL_NONE);
> +
> + /* drive strength to max (24bit) */
> + s5p_gpio_set_drv(&gpio1->f0, i, GPIO_DRV_4X);
> + s5p_gpio_set_rate(&gpio1->f0, i, GPIO_DRV_SLOW);
> + s5p_gpio_set_drv(&gpio1->f1, i, GPIO_DRV_4X);
> + s5p_gpio_set_rate(&gpio1->f1, i, GPIO_DRV_SLOW);
> + s5p_gpio_set_drv(&gpio1->f2, i, GPIO_DRV_4X);
> + s5p_gpio_set_rate(&gpio1->f0, i, GPIO_DRV_SLOW);
> + }
> +
> + for (i = 0; i < f3_end; i++) {
> + /* set GPF3[0:3] for RGB Interface and Data lines (32bit) */
> + s5p_gpio_cfg_pin(&gpio1->f3, i, GPIO_FUNC(2));
> + /* pull-up/down disable */
> + s5p_gpio_set_pull(&gpio1->f3, i, GPIO_PULL_NONE);
> + /* drive strength to max (24bit) */
> + s5p_gpio_set_drv(&gpio1->f3, i, GPIO_DRV_4X);
> + s5p_gpio_set_rate(&gpio1->f3, i, GPIO_DRV_SLOW);
> + }
> +
> + /* gpio pad configuration for LCD reset. */
> + s5p_gpio_cfg_pin(&gpio2->y4, 5, GPIO_OUTPUT);
> +
> + spi_init();
> +
> + return;
Please remove this return.
> +}
> +
> +static void reset_lcd(void)
> +{
> + s5p_gpio_set_value(&gpio2->y4, 5, 1);
> + udelay(1);
> + s5p_gpio_set_value(&gpio2->y4, 5, 0);
> + udelay(1);
> + s5p_gpio_set_value(&gpio2->y4, 5, 1);
> + udelay(100);
> +}
> +
> +static void lcd_power_on(void)
> +{
> + struct pmic *p = get_pmic();
> +
> + if (pmic_pr
Re: [U-Boot] [PATCH] arm:exynos4:universal_c210: implement software SPI
Dear Piotr,
On 29 August 2012 17:15, Piotr Wilczek wrote:
> This patch implements software SPI for the universal C210 board.
>
> Signed-off-by: Piotr Wilczek
> Signed-off-by: Kyungmin Park
> CC: Minkyu Kang
> CC: Wolfgang Denk
> CC: Jean-Christophe PLAGNIOL-VILLARD
> ---
> board/samsung/universal_c210/universal.c | 36
> ++
> drivers/spi/soft_spi.c |7 +-
> include/configs/s5pc210_universal.h | 19 +++
> 3 files changed, 61 insertions(+), 1 deletions(-)
>
> diff --git a/board/samsung/universal_c210/universal.c
> b/board/samsung/universal_c210/universal.c
> index 8a114e6..772ade5 100644
> --- a/board/samsung/universal_c210/universal.c
> +++ b/board/samsung/universal_c210/universal.c
> @@ -24,6 +24,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -34,6 +35,10 @@
> #include
> #include
>
> +#if defined(CONFIG_SOFT_SPI)
> +# include
remove space between # and include.
> +#endif
> +
> DECLARE_GLOBAL_DATA_PTR;
>
> struct exynos4_gpio_part1 *gpio1;
> @@ -288,3 +293,34 @@ int board_early_init_f(void)
>
> return 0;
> }
> +
> +void soft_spi_init()
> +{
> + gpio_direction_output(CONFIG_SOFT_SPI_GPIO_SCLK,
> + CONFIG_SOFT_SPI_MODE & SPI_CPOL);
> + gpio_direction_output(CONFIG_SOFT_SPI_GPIO_MOSI, 1);
> + gpio_direction_input(CONFIG_SOFT_SPI_GPIO_MISO);
> + gpio_direction_output(CONFIG_SOFT_SPI_GPIO_CS,
> + !(CONFIG_SOFT_SPI_MODE & SPI_CS_HIGH));
> +}
> +
> +void spi_cs_activate(struct spi_slave *slave)
> +{
> + gpio_set_value(CONFIG_SOFT_SPI_GPIO_CS,
> + !(CONFIG_SOFT_SPI_MODE & SPI_CS_HIGH));
> + SPI_SCL(1);
> + gpio_set_value(CONFIG_SOFT_SPI_GPIO_CS,
> + CONFIG_SOFT_SPI_MODE & SPI_CS_HIGH);
> +}
> +
> +void spi_cs_deactivate(struct spi_slave *slave)
> +{
> + gpio_set_value(CONFIG_SOFT_SPI_GPIO_CS,
> + !(CONFIG_SOFT_SPI_MODE & SPI_CS_HIGH));
> +}
> +
> +int spi_cs_is_valid(unsigned int bus, unsigned int cs)
> +{
> + return 1;
always return 1?
> +}
> +
> diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c
> index 13df8cb..a0a3012 100644
> --- a/drivers/spi/soft_spi.c
> +++ b/drivers/spi/soft_spi.c
> @@ -29,6 +29,10 @@
>
> #include
>
> +#if defined(CONFIG_SOFT_SPI)
> +# include
> +#endif
> +
> /*---
> * Definitions
> */
> @@ -59,8 +63,9 @@ static inline struct soft_spi_slave *to_soft_spi(struct
> spi_slave *slave)
> void spi_init (void)
> {
> #ifdef SPI_INIT
> +#ifdef CONFIG_SYS_IMMR
> volatile immap_t *immr = (immap_t *)CONFIG_SYS_IMMR;
> -
> +#endif
Is it related change with this patch?
> SPI_INIT;
> #endif
> }
> diff --git a/include/configs/s5pc210_universal.h
> b/include/configs/s5pc210_universal.h
> index 7978317..a338840 100644
> --- a/include/configs/s5pc210_universal.h
> +++ b/include/configs/s5pc210_universal.h
> @@ -266,4 +266,23 @@
> #define CONFIG_USB_GADGET_S3C_UDC_OTG
> #define CONFIG_USB_GADGET_DUALSPEED
>
> +/*
> + * SPI Settings
> + */
> +#define CONFIG_SOFT_SPI
> +#define CONFIG_SOFT_SPI_MODE SPI_MODE_3
> +#define CONFIG_SOFT_SPI_GPIO_SCLK exynos4_gpio_part2_get_nr(y3, 1)
> +#define CONFIG_SOFT_SPI_GPIO_MOSI exynos4_gpio_part2_get_nr(y3, 3)
> +#define CONFIG_SOFT_SPI_GPIO_MISO exynos4_gpio_part2_get_nr(y3, 0)
> +#define CONFIG_SOFT_SPI_GPIO_CS exynos4_gpio_part2_get_nr(y4, 3)
> +
> +#define SPI_DELAY udelay(1)
> +#define SPI_INIT soft_spi_init()
> +#define SPI_SCL(bit) gpio_set_value(CONFIG_SOFT_SPI_GPIO_SCLK, bit)
> +#define SPI_SDA(bit) gpio_set_value(CONFIG_SOFT_SPI_GPIO_MOSI, bit)
> +#define SPI_READ gpio_get_value(CONFIG_SOFT_SPI_GPIO_MISO)
> +#ifndef__ASSEMBLY__
> +void soft_spi_init(void);
> +#endif
> +
> #endif /* __CONFIG_H */
> --
> 1.7.5.4
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 2/2] IPL: Remove remains of OneNAND IPL
Dear Marek Vasut, On 6 September 2012 12:09, Marek Vasut wrote: > After removing the Apollon board, remove the OneNAND IPL too. > There are no users for it any more. > > Signed-off-by: Marek Vasut > Cc: Albert Aribaud > Cc: Minkyu Kang > Cc: Tom Rini > --- > .gitignore |5 - > Makefile | 10 -- > board/samsung/goni/lowlevel_init.S | 120 > board/samsung/smdkc100/lowlevel_init.S | 42 - > onenand_ipl/onenand_boot.c | 48 -- > onenand_ipl/onenand_ipl.h | 36 > onenand_ipl/onenand_read.c | 158 > > 7 files changed, 419 deletions(-) > delete mode 100644 onenand_ipl/onenand_boot.c > delete mode 100644 onenand_ipl/onenand_ipl.h > delete mode 100644 onenand_ipl/onenand_read.c > Acked-by: Minkyu Kang Thanks. -- 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] fdt: Check if the FDT address is configured
On 09/05/2012 02:34 AM, Marek Vasut wrote: > In case the "fdt addr" command wasn't ran yet and any other "fdt" > subcommand was issued, the system crashed due to NULL pointer being > used. > > This is caused by "fdt addr" command setting up a pointer to the > FDT memory location. Prior issuing "fdt addr", the pointer is NULL > so calling any other subcommands crashed the u-boot. > > Signed-off-by: Marek Vasut > Cc: Simon Glass Applied and sent a pull request to Tom Rini. Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-fdt
Dear Tom, Please pull u-boot-fdt. This contains the FDT null address bug fix from Marek. Thanks, gvb P.S. Tom - Resent because I sent to the list from the wrong email account. The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 09:17:27 +0200) are available in the git repository at: git://git.denx.de/u-boot-fdt.git master for you to fetch changes up to e02c9458748a59e5d80649deb5e40f96ed992bb5: fdt: Check if the FDT address is configured (2012-09-15 09:16:08 -0400) Marek Vasut (1): fdt: Check if the FDT address is configured common/cmd_fdt.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A little introduction
I just noticed this mail today, sorry for the late reply. Thanks Henrik for introducing this in the u-boot mail list. I am Tom Cubie, a former engineer at Allwinner. Allwinner Tech is a 5-years-old Chinese company making low cost ARM soc. I joined Allwinner last year, and have been working on the Linux BSP, U-boot and some device drivers. To help speed up development and improve resource usage i suggested that we Allwinner should open source and work with the open source community as it is the fastest way for Allwinner engineer to learn and get feedback. At that time the EOMA project announced that they will make computer-on-module using allwinner A10 chip. I have been trying to advocate the benefits of open source within the company since then. The community's work are based on a number of source releases by both Allwinner and their customers. Though there are source code public. i feel that there are not many developers (like Henrik) on Allwinner platform. I think one reason is no good hardware to work on it and also the lack of documents. So my colleagues and i, we made the cubieboard (cubieboard.org), a low cost board based on A10. Hope that we can improve the FOSS on Allwinner platform. Because of family reasons I recently quit my job at Allwinner and decide to run cubieboard project fulltime while still get support from my former colleagues. If there are developers in the mail list interested in hacking the board, welcome. We offer special orders to developers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] libfdt: Add support for appending the values to a existing property
On 08/27/2012 08:38 PM, Kim Phillips wrote: > From: Minghuan Lian > > Some properties may contain multiple values, these values may need > to be added to the property respectively. this patch provides this > functionality. The main purpose of fdt_append_prop() is to append > the values to a existing property, or create a new property if it > dose not exist. > > Signed-off-by: Minghuan Lian > Signed-off-by: David Gibson Queued up 2 of 2 patches to the u-boot-fdt "next" branch. I'll issue a pull request when the merge window opens. Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] libfdt: Add support for appending the values to a existing property
On Sat, Sep 15, 2012 at 9:36 AM, Jerry Van Baren wrote: > Queued up 2 of 2 patches to the u-boot-fdt "next" branch. I'll issue a > pull request when the merge window opens. I thought libfdt patches were suppose to go to dtc.git? -- 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 1/2] libfdt: Add support for appending the values to a existing property
On 09/15/2012 11:00 AM, Tabi Timur-B04825 wrote: > On Sat, Sep 15, 2012 at 9:36 AM, Jerry Van Baren wrote: > >> Queued up 2 of 2 patches to the u-boot-fdt "next" branch. I'll issue a >> pull request when the merge window opens. > > I thought libfdt patches were suppose to go to dtc.git? That is where they came from. Since the u-boot libfdt is a subset of the whole dtc.git repository (just the libfdt part), I've been cherry picking only the libfdt/* patches (with the help of others). I see David has another patch for the libfdt library that I probably should pick up so that we stay in sync (18 lines of code by counting semicolons). commit be6026838e45b67800ac803f4ad8cca3cde57d6d Author: David Gibson Date: Fri Jun 1 14:12:38 2012 +1000 libfdt: Add helper function to create a trivial, empty tree The libfdt read/write functions are now usable enough that it's become a moderately common pattern to use them to build and manipulate a device tree from scratch. For example, we do so ourself in our rw_tree1 testcase, and qemu is starting to use this model when building device trees for some targets such as e500. However, the read/write functions require some sort of valid tree to begin with, so this necessitates either having a trivial canned dtb to begin with or, more commonly, creating an empty tree using the serial-write functions first. This patch adds a helper function which uses the serial-write functions to create a trivial, empty but complete and valid tree in a supplied buffer, ready for manipulation with the read/write functions. Signed-off-by: David Gibson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] IPL: Remove remains of OneNAND IPL
Dear Minkyu Kang, > Dear Marek Vasut, > > On 6 September 2012 12:09, Marek Vasut wrote: > > After removing the Apollon board, remove the OneNAND IPL too. > > There are no users for it any more. > > > > Signed-off-by: Marek Vasut > > Cc: Albert Aribaud > > Cc: Minkyu Kang > > Cc: Tom Rini > > --- > > > > .gitignore |5 - > > Makefile | 10 -- > > board/samsung/goni/lowlevel_init.S | 120 > > board/samsung/smdkc100/lowlevel_init.S | 42 - > > onenand_ipl/onenand_boot.c | 48 -- > > onenand_ipl/onenand_ipl.h | 36 > > onenand_ipl/onenand_read.c | 158 > > 7 files changed, 419 deletions(-) > > delete mode 100644 onenand_ipl/onenand_boot.c > > delete mode 100644 onenand_ipl/onenand_ipl.h > > delete mode 100644 onenand_ipl/onenand_read.c > > Acked-by: Minkyu Kang What about 1/2 please? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] ARM: fix relocation on ARM926EJS
Dear José Miguel Gonçalves, > Jumping to board_init_r is not performed due to a bug on address > computation. Is your CONFIG_SYS_TEXT_BASE configured correctly? I don't detect any misbehavior on my arm926 boards. > Relocation offsets are not needed when building SPL. Do they cause any trouble? > Signed-off-by: José Miguel Gonçalves > --- > Changes for v2: >- None > --- > arch/arm/cpu/arm926ejs/start.S |4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/cpu/arm926ejs/start.S > b/arch/arm/cpu/arm926ejs/start.S index 6f05f1a..2da5342 100644 > --- a/arch/arm/cpu/arm926ejs/start.S > +++ b/arch/arm/cpu/arm926ejs/start.S > @@ -325,7 +325,7 @@ _nand_boot_ofs: > .word nand_boot > #else > ldr r0, _board_init_r_ofs > - ldr r1, _TEXT_BASE > + adr r1, _start > add lr, r0, r1 > add lr, lr, r9 > /* setup parameters for board_init_r */ > @@ -338,12 +338,14 @@ _board_init_r_ofs: > .word board_init_r - _start > #endif > > +#ifndef CONFIG_SPL_BUILD > _rel_dyn_start_ofs: > .word __rel_dyn_start - _start > _rel_dyn_end_ofs: > .word __rel_dyn_end - _start > _dynsym_start_ofs: > .word __dynsym_start - _start > +#endif > > /* > * Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx28evk: extend default environment
The environment has been based on mx53loco and m28evk but keeping the
possibility to easy change the default console device as Freescale and
mainline kernels differ on the device name.
Signed-off-by: Otavio Salvador
---
include/configs/mx28evk.h | 82 -
1 file changed, 74 insertions(+), 8 deletions(-)
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 43b4002..dffb744 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -239,7 +239,6 @@
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_BOOTDELAY 3
#define CONFIG_BOOTFILE"uImage"
-#define CONFIG_BOOTCOMMAND "run bootcmd_net"
#define CONFIG_LOADADDR0x4200
#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
#define CONFIG_OF_LIBFDT
@@ -248,13 +247,80 @@
* Extra Environments
*/
#define CONFIG_EXTRA_ENV_SETTINGS \
- "console_fsl=console=ttyAM0" \
- "console_mainline=console=ttyAMA0" \
- "netargs=setenv bootargs console=${console_mainline}" \
+ "update_nand_full_filename=u-boot.nand\0" \
+ "update_nand_firmware_filename=u-boot.sb\0" \
+ "update_sd_firmware_filename=u-boot.sd\0" \
+ "update_nand_firmware_maxsz=0x10\0" \
+ "update_nand_stride=0x40\0" /* MX28 datasheet ch. 12.12 */ \
+ "update_nand_count=0x4\0" /* MX28 datasheet ch. 12.12 */ \
+ "update_nand_get_fcb_size=" /* Get size of FCB blocks */ \
+ "nand device 0 ; " \
+ "nand info ; " \
+ "setexpr fcb_sz ${update_nand_stride} * ${update_nand_count};" \
+ "setexpr update_nand_fcb ${fcb_sz} * ${nand_writesize}\0" \
+ "update_nand_full=" /* Update FCB, DBBT and FW */ \
+ "if tftp ${update_nand_full_filename} ; then " \
+ "run update_nand_get_fcb_size ; " \
+ "nand scrub -y 0x0 ${filesize} ; " \
+ "nand write.raw ${loadaddr} 0x0 ${update_nand_fcb} ; " \
+ "setexpr update_off ${loadaddr} + ${update_nand_fcb} ; " \
+ "setexpr update_sz ${filesize} - ${update_nand_fcb} ; " \
+ "nand write ${update_off} ${update_nand_fcb} ${update_sz} ; " \
+ "fi\0" \
+ "update_nand_firmware=" /* Update only firmware */ \
+ "if tftp ${update_nand_firmware_filename} ; then " \
+ "run update_nand_get_fcb_size ; " \
+ "setexpr fcb_sz ${update_nand_fcb} * 2 ; " /* FCB + DBBT */ \
+ "setexpr fw_sz ${update_nand_firmware_maxsz} * 2 ; " \
+ "setexpr fw_off ${fcb_sz} + ${update_nand_firmware_maxsz};" \
+ "nand erase ${fcb_sz} ${fw_sz} ; " \
+ "nand write ${loadaddr} ${fcb_sz} ${filesize} ; " \
+ "nand write ${loadaddr} ${fw_off} ${filesize} ; " \
+ "fi\0" \
+ "update_sd_firmware=" /* Update the SD firmware partition */ \
+ "if mmc rescan ; then " \
+ "if tftp ${update_sd_firmware_filename} ; then " \
+ "setexpr fw_sz ${filesize} / 0x200 ; " /* SD block size */ \
+ "setexpr fw_sz ${fw_sz} + 1 ; " \
+ "mmc write ${loadaddr} 0x800 ${fw_sz} ; " \
+ "fi ; " \
+ "fi\0" \
+ "script=boot.scr\0" \
+ "uimage=uImage\0" \
+ "console_fsl=ttyAM0\0" \
+ "console_mainline=ttyAMA0\0" \
+ "mmcdev=0\0" \
+ "mmcpart=2\0" \
+ "mmcroot=/dev/mmcblk0p3 rw\0" \
+ "mmcrootfstype=ext3 rootwait\0" \
+ "mmcargs=setenv bootargs console=${console_mainline},${baudrate} " \
+ "root=${mmcroot} " \
+ "rootfstype=${mmcrootfstype}\0" \
+ "loadbootscript=" \
+ "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+ "bootscript=echo Running bootscript from mmc ...; " \
+ "source\0" \
+ "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
+ "mmcboot=echo Booting from mmc ...; " \
+ "run mmcargs; " \
+ "bootm\0" \
+ "netargs=setenv bootargs console=${console_mainline},${baudrate} " \
"root=/dev/nfs " \
- "ip=dhcp nfsroot=${serverip}:${nfsroot}\0" \
- "bootcmd_net=echo Booting from net ...; " \
- "run netargs; " \
- "dhcp ${uimage}; bootm\0" \
+ "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
+ "netboot=echo Booting from net ...; " \
+ "run netargs; " \
+ "dhcp ${uimage}; bootm\0"
+
+#define CONFIG_BOOTCOMMAND \
+ "if mmc rescan ${mmcdev}; then " \
+ "if run loadbootscript; then " \
+ "run bootscript; " \
+ "else " \
+ "if run loaduimage; then " \
+ "run mmcboot; " \
+ "else run netboot; " \
+
Re: [U-Boot] AR8031 Ethernet on mx6
Hi Dirk, On Sat, Sep 15, 2012 at 2:32 AM, Dirk Behme wrote: > I think a coworker has an ARM2, so I'll try to ask him on Monday. Thanks for your help. > > But while talking about ethernet on MX6: There seems to be a lot of issues > with 1GB ethernet. Or is it just confusion? As I'm no expert on this, I'm > really confused. That means that I don't know if we still really have some > issues with it or not :( > > The initial SabreLite boards (revision from September/Octorber last year?) > had a hardware issue with 1GB ethernet. I was told that this hardware issue > is fixed in the latest SabreLite boards with hardware revision D. But a > coworker reports that it looks like GB ethernet even doesn't work with the > U-Boot the SabreLite revision D ships with (?). Nor a more recent (patched?) > U-Boot. I'm not sure if the recent (unpatched) mainline was tested, though. > So this might be an issue of an U-Boot version which has SW patches for the > old, broken ethernet applied, which now breaks the fixed hardware? Or is > there still an hardware issue? I don't know. I haven't worked with Gigabit Ethernet on mx6qsabrelite, but my understanding is that it has been functional now in U-boot. Ccing Troy and Eric as they probably know all the details. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AR8031 Ethernet on mx6
Dear Fabio Estevam, > Hi Dirk, > > On Sat, Sep 15, 2012 at 2:32 AM, Dirk Behme wrote: > > I think a coworker has an ARM2, so I'll try to ask him on Monday. > > Thanks for your help. > > > But while talking about ethernet on MX6: There seems to be a lot of > > issues with 1GB ethernet. Or is it just confusion? As I'm no expert on > > this, I'm really confused. That means that I don't know if we still > > really have some issues with it or not :( > > > > The initial SabreLite boards (revision from September/Octorber last > > year?) had a hardware issue with 1GB ethernet. I was told that this > > hardware issue is fixed in the latest SabreLite boards with hardware > > revision D. But a coworker reports that it looks like GB ethernet even > > doesn't work with the U-Boot the SabreLite revision D ships with (?). > > Nor a more recent (patched?) U-Boot. I'm not sure if the recent > > (unpatched) mainline was tested, though. So this might be an issue of an > > U-Boot version which has SW patches for the old, broken ethernet > > applied, which now breaks the fixed hardware? Or is there still an > > hardware issue? I don't know. > > I haven't worked with Gigabit Ethernet on mx6qsabrelite, but my > understanding is that it has been functional now in U-boot. > > Ccing Troy and Eric as they probably know all the details. It works for me, but I don't think it runs on "gigabit" speed. > Regards, > > Fabio Estevam Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
Dear Thierry Reding, > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > > Hi, > > > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: > > > Dear Stephen Warren, > > > > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > > >> > Dear Stephen Warren, > > >> > > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > > >> >>> Folks, > > >> >>> > > >> >>> Stephen Warren has posted an internal bug regarding the cache > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing MMC. > > >> >>> Here's the gist: > > >> >>> > > >> >>> Executing "mmc dev 0" still yields cache warnings: > > >> >>> > > >> >>> Tegra20 (Harmony) # mmc dev 0 > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- > > >> >>> 0x3fb69908 mmc0 is current device > > >> >> > > >> >> ... > > >> >> > > >> >>> There have been patches in the past (IIRC) that have tried to > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force their > > >> >>> buffers to the appropriate alignment, but I don't know that we > > >> >>> can ever correct every instance, now or in the future. > > >> >>> > > >> >>> Can we start a discussion about what we can do about this warning? > > >> >>> Adding an appropriate #ifdef > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen put > > >> >>> his #if 0's would be one approach, or changing the printf() to a > > >> >>> debug(), perhaps. As far as I can tell, these alignment 'errors' > > >> >>> don't seem to produce bad data in the transfer. > > >> >> > > >> >> I don't think simply turning off the warning is the correct > > >> >> approach; I believe they represent real problems that can in fact > > >> >> cause data corruption. I don't believe we have any choice other > > >> >> than to fully solve the root-cause. > > > > Yes I agree, and I think it is pretty close - certainly much better > > than it used to be. The good thing about them being annoying is that > > they will likely get fixed :-) > > I think I traced this to the copying of CSD a while back. The problem is > that the transferred buffer is 8 bytes, so there's no way to make it > aligned properly. Unfortunately the entailing discussion did not yield a > solution at the time. And how exactly does the MMC bounce buffer not help here? > Thierry Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > Hi, > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: > > Dear Stephen Warren, > > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > >> > Dear Stephen Warren, > >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > >> >>> Folks, > >> >>> > >> >>> Stephen Warren has posted an internal bug regarding the cache > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing MMC. Here's > >> >>> the gist: > >> >>> > >> >>> Executing "mmc dev 0" still yields cache warnings: > >> >>> > >> >>> Tegra20 (Harmony) # mmc dev 0 > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- 0x3fb69908 > >> >>> mmc0 is current device > >> >> > >> >> ... > >> >> > >> >>> There have been patches in the past (IIRC) that have tried to ensure > >> >>> all callers (FS, MMC driver, USB driver, etc.) force their buffers to > >> >>> the appropriate alignment, but I don't know that we can ever correct > >> >>> every instance, now or in the future. > >> >>> > >> >>> Can we start a discussion about what we can do about this warning? > >> >>> Adding an appropriate #ifdef (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, > >> >>> etc.) where Stephen put his #if 0's would be one approach, or changing > >> >>> the printf() to a debug(), perhaps. As far as I can tell, these > >> >>> alignment 'errors' don't seem to produce bad data in the transfer. > >> >> > >> >> I don't think simply turning off the warning is the correct approach; I > >> >> believe they represent real problems that can in fact cause data > >> >> corruption. I don't believe we have any choice other than to fully solve > >> >> the root-cause. > > Yes I agree, and I think it is pretty close - certainly much better > than it used to be. The good thing about them being annoying is that > they will likely get fixed :-) I think I traced this to the copying of CSD a while back. The problem is that the transferred buffer is 8 bytes, so there's no way to make it aligned properly. Unfortunately the entailing discussion did not yield a solution at the time. Thierry pgpExPdjzINCh.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
On Sat, Sep 15, 2012 at 10:01:47PM +0200, Thierry Reding wrote: > I think I traced this to the copying of CSD a while back. The problem is > that the transferred buffer is 8 bytes, so there's no way to make it > aligned properly. Unfortunately the entailing discussion did not yield a > solution at the time. For reference, below is a link[0] to the patch I proposed at the time but it was obviously wrong. And it wasn't CSD but rather SCR. The reason why allocating a larger buffer is not enough is that the MMC core requests that only 8 bytes be transferred, which is the value that eventually ends up being passed to the cache invalidation routine. Thierry [0]: http://lists.denx.de/pipermail/u-boot/2012-April/123080.html pgpmeEezjAOLh.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AR8031 Ethernet on mx6
Hi all, On 09/15/2012 12:26 PM, Marek Vasut wrote: Dear Fabio Estevam, Hi Dirk, On Sat, Sep 15, 2012 at 2:32 AM, Dirk Behme wrote: I think a coworker has an ARM2, so I'll try to ask him on Monday. Thanks for your help. But while talking about ethernet on MX6: There seems to be a lot of issues with 1GB ethernet. Or is it just confusion? As I'm no expert on this, I'm really confused. That means that I don't know if we still really have some issues with it or not :( The initial SabreLite boards (revision from September/Octorber last year?) had a hardware issue with 1GB ethernet. I was told that this hardware issue is fixed in the latest SabreLite boards with hardware revision D. But a coworker reports that it looks like GB ethernet even doesn't work with the U-Boot the SabreLite revision D ships with (?). Nor a more recent (patched?) U-Boot. I'm not sure if the recent (unpatched) mainline was tested, though. So this might be an issue of an U-Boot version which has SW patches for the old, broken ethernet applied, which now breaks the fixed hardware? Or is there still an hardware issue? I don't know. I haven't worked with Gigabit Ethernet on mx6qsabrelite, but my understanding is that it has been functional now in U-boot. Ccing Troy and Eric as they probably know all the details. It works for me, but I don't think it runs on "gigabit" speed. The first shipments of Rev C (~10% of those shipped) and handful of prototype boards that preceded it) had an issue with pin 9 on the combination ethernet/USB jack. This pin was connected and should have been left floating. This caused some issues properly negotiating Gb speeds, and Gb rarely worked. The only patches circulated for this simply disabled Gb speeds entirely Later (most) Rev C and all Rev D boards have been tested to function at Gb speeds, at least nominally (against the Gb switches we have in house) using u-boot-2009.08. That said, we have seen quite a few reports of instability or inability to negotiate Gb speeds at customer sites. The majority of these have been addressed by replacing cables though there are some reports of packet loss as well. In particular, using the 'tcp' option for NFS is sometimes helpful. I suspect that some additional tweaking of the KSZ9021 PHY is needed. In the 2009-08 Freescale and Boundary are distributing, there appears to be an occasional issue with negotiation. In the normal, successful case, you get a message about the link status like this, with a U-Boot > dhcp 1200 192.168.0.162:uImage-imx6 Found phy at 6 FEC: Link is Up 796d BOOTP broadcast 1 DHCP client bound to address 192.168.0.119 ... goes on to transfer file But on occasion, I see negotiation fail: Found phy at 6 FEC: Link is down 7949 Note that the 7949 corresponds to register 1 (PHY status) and that bits 5 (A/N complete) and 2 (link status) are both clear. Main-line U-Boot master seems to just work and sync up at Gb. MX6QSABRELITE U-Boot > version U-Boot 2012.07-00490-ga6f0c4f (Sep 15 2012 - 13:17:31) arm-none-linux-gnueabi-gcc (4.4.4_09.06.2010) 4.4.4 GNU ld (GNU Binutils) 2.20.1.20100303 MX6QSABRELITE U-Boot > dhcp 1200 192.168.0.162:uImage-imx6 BOOTP broadcast 1 DHCP client bound to address 192.168.0.119 Using FEC device TFTP from server 192.168.0.162; our IP address is 192.168.0.119 Filename 'uImage-imx6'. Load address: 0x1200 Loading: # # # # # # # # # # # # # ### done Bytes transferred = 4379516 (42d37c hex) MX6QSABRELITE U-Boot > mii dump 6 0. (1140) -- PHY control register -- (8000:) 0.15= 0reset (4000:) 0.14= 0loopback (2040:0040) 0. 6,13 = b10speed selection = 1000 Mbps (1000:1000) 0.12= 1A/N enable (0800:) 0.11= 0power-down (0400:) 0.10= 0isolate (0200:) 0. 9= 0restart A/N (0100:0100) 0. 8= 1duplex = full (0080:) 0. 7= 0collision test enable (00
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: > Dear Thierry Reding, > > > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > > > Hi, > > > > > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: > > > > Dear Stephen Warren, > > > > > > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > > > >> > Dear Stephen Warren, > > > >> > > > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > > > >> >>> Folks, > > > >> >>> > > > >> >>> Stephen Warren has posted an internal bug regarding the cache > > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing MMC. > > > >> >>> Here's the gist: > > > >> >>> > > > >> >>> Executing "mmc dev 0" still yields cache warnings: > > > >> >>> > > > >> >>> Tegra20 (Harmony) # mmc dev 0 > > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- > > > >> >>> 0x3fb69908 mmc0 is current device > > > >> >> > > > >> >> ... > > > >> >> > > > >> >>> There have been patches in the past (IIRC) that have tried to > > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force their > > > >> >>> buffers to the appropriate alignment, but I don't know that we > > > >> >>> can ever correct every instance, now or in the future. > > > >> >>> > > > >> >>> Can we start a discussion about what we can do about this warning? > > > >> >>> Adding an appropriate #ifdef > > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen put > > > >> >>> his #if 0's would be one approach, or changing the printf() to a > > > >> >>> debug(), perhaps. As far as I can tell, these alignment 'errors' > > > >> >>> don't seem to produce bad data in the transfer. > > > >> >> > > > >> >> I don't think simply turning off the warning is the correct > > > >> >> approach; I believe they represent real problems that can in fact > > > >> >> cause data corruption. I don't believe we have any choice other > > > >> >> than to fully solve the root-cause. > > > > > > Yes I agree, and I think it is pretty close - certainly much better > > > than it used to be. The good thing about them being annoying is that > > > they will likely get fixed :-) > > > > I think I traced this to the copying of CSD a while back. The problem is > > that the transferred buffer is 8 bytes, so there's no way to make it > > aligned properly. Unfortunately the entailing discussion did not yield a > > solution at the time. > > And how exactly does the MMC bounce buffer not help here? The problem solved by the bounce buffer is that it is properly cache- line aligned. However the issue here is not that the buffer is not properly aligned but rather that the transfer is too small. When the MMC core transfers the SCR, it requests 8 bytes. The buffer used to store these 8 bytes is properly allocated. However, those 8 bytes eventually end up as the size of the range that is to be invalidated. This is the reason for the warning. Address x of the buffer is cache-line aligned, but x + 8 is never properly aligned and therefore the code complains. Thierry pgpRd5Ytqx66H.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
Dear Thierry Reding, > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: > > Dear Thierry Reding, > > > > > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > > > > Hi, > > > > > > > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: > > > > > Dear Stephen Warren, > > > > > > > > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > > > > >> > Dear Stephen Warren, > > > > >> > > > > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > > > > >> >>> Folks, > > > > >> >>> > > > > >> >>> Stephen Warren has posted an internal bug regarding the cache > > > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing > > > > >> >>> MMC. Here's the gist: > > > > >> >>> > > > > >> >>> Executing "mmc dev 0" still yields cache warnings: > > > > >> >>> > > > > >> >>> Tegra20 (Harmony) # mmc dev 0 > > > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- > > > > >> >>> 0x3fb69908 mmc0 is current device > > > > >> >> > > > > >> >> ... > > > > >> >> > > > > >> >>> There have been patches in the past (IIRC) that have tried to > > > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force > > > > >> >>> their buffers to the appropriate alignment, but I don't know > > > > >> >>> that we can ever correct every instance, now or in the > > > > >> >>> future. > > > > >> >>> > > > > >> >>> Can we start a discussion about what we can do about this > > > > >> >>> warning? Adding an appropriate #ifdef > > > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen > > > > >> >>> put his #if 0's would be one approach, or changing the > > > > >> >>> printf() to a debug(), perhaps. As far as I can tell, these > > > > >> >>> alignment 'errors' don't seem to produce bad data in the > > > > >> >>> transfer. > > > > >> >> > > > > >> >> I don't think simply turning off the warning is the correct > > > > >> >> approach; I believe they represent real problems that can in > > > > >> >> fact cause data corruption. I don't believe we have any choice > > > > >> >> other than to fully solve the root-cause. > > > > > > > > Yes I agree, and I think it is pretty close - certainly much better > > > > than it used to be. The good thing about them being annoying is that > > > > they will likely get fixed :-) > > > > > > I think I traced this to the copying of CSD a while back. The problem > > > is that the transferred buffer is 8 bytes, so there's no way to make > > > it aligned properly. Unfortunately the entailing discussion did not > > > yield a solution at the time. > > > > And how exactly does the MMC bounce buffer not help here? > > The problem solved by the bounce buffer is that it is properly cache- > line aligned. However the issue here is not that the buffer is not > properly aligned but rather that the transfer is too small. > > When the MMC core transfers the SCR, it requests 8 bytes. The buffer > used to store these 8 bytes is properly allocated. However, those 8 > bytes eventually end up as the size of the range that is to be > invalidated. This is the reason for the warning. Address x of the buffer > is cache-line aligned, but x + 8 is never properly aligned and therefore > the code complains. The bounce buffer also up-aligns the newly buffer size to ARCH_DMA_MINALIGN, so you can safely up-align you cacheline flush/invalidate sizes. > Thierry Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] ARM: kirkwood/orion5x: Use reset_cpu definition in include/common.h
Hi!
> > From: Dinh Nguyen
> >
> > include/common.h has the reset_cpu defined already. No need to
> > re-define here.
> >
> > Signed-off-by: Dinh Nguyen
> > Signed-off-by: Pavel Machek
> > ---
> > arch/arm/include/asm/arch-kirkwood/cpu.h |1 -
> > arch/arm/include/asm/arch-orion5x/cpu.h |1 -
> > 2 files changed, 2 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-kirkwood/cpu.h
> > b/arch/arm/include/asm/arch-kirkwood/cpu.h
> > index d28c51a..7a53c8f 100644
> > --- a/arch/arm/include/asm/arch-kirkwood/cpu.h
> > +++ b/arch/arm/include/asm/arch-kirkwood/cpu.h
> > @@ -155,7 +155,6 @@ struct kwgpio_registers {
> > /*
> > * functions
> > */
> > -void reset_cpu(unsigned long ignored);
> > unsigned char get_random_hex(void);
> > unsigned int kw_sdram_bar(enum memory_bank bank);
> > unsigned int kw_sdram_bs(enum memory_bank bank);
> > diff --git a/arch/arm/include/asm/arch-orion5x/cpu.h
> > b/arch/arm/include/asm/arch-orion5x/cpu.h
> > index 2f52ca8..17b9b69 100644
> > --- a/arch/arm/include/asm/arch-orion5x/cpu.h
> > +++ b/arch/arm/include/asm/arch-orion5x/cpu.h
> > @@ -251,7 +251,6 @@ struct orion5x_ddr_addr_decode_registers {
> > /*
> > * functions
> > */
> > -void reset_cpu(unsigned long ignored);
> > u32 orion5x_device_id(void);
> > u32 orion5x_device_rev(void);
> > unsigned int orion5x_winctrl_calcsize(unsigned int sizeval);
> > --
>
> Acked-By: Prafulla Wadaskar
>
> BTW: you could have made this patch independent so that it could be pulled
> independently.
It is independend... Feel free to just apply it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Limit of kernel size
Hi, everyone Is there limitation of the kernel size which u-boot loads? My kernel is very big, because I included the ramdisk into the kernel. My kernel size is over 40MB. When I load the kernel through u-boot, the prcedure hangs in the boot step. The step is "Uncompressing Linux done, booting the kernel" Thanks in advance. Best Regards, J.Hwan Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
Hi, On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding wrote: > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: >> Dear Thierry Reding, >> >> > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: >> > > Hi, >> > > >> > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: >> > > > Dear Stephen Warren, >> > > > >> > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: >> > > >> > Dear Stephen Warren, >> > > >> > >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: >> > > >> >>> Folks, >> > > >> >>> >> > > >> >>> Stephen Warren has posted an internal bug regarding the cache >> > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing MMC. >> > > >> >>> Here's the gist: >> > > >> >>> >> > > >> >>> Executing "mmc dev 0" still yields cache warnings: >> > > >> >>> >> > > >> >>> Tegra20 (Harmony) # mmc dev 0 >> > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- >> > > >> >>> 0x3fb69908 mmc0 is current device >> > > >> >> >> > > >> >> ... >> > > >> >> >> > > >> >>> There have been patches in the past (IIRC) that have tried to >> > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force their >> > > >> >>> buffers to the appropriate alignment, but I don't know that we >> > > >> >>> can ever correct every instance, now or in the future. >> > > >> >>> >> > > >> >>> Can we start a discussion about what we can do about this warning? >> > > >> >>> Adding an appropriate #ifdef >> > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen put >> > > >> >>> his #if 0's would be one approach, or changing the printf() to a >> > > >> >>> debug(), perhaps. As far as I can tell, these alignment 'errors' >> > > >> >>> don't seem to produce bad data in the transfer. >> > > >> >> >> > > >> >> I don't think simply turning off the warning is the correct >> > > >> >> approach; I believe they represent real problems that can in fact >> > > >> >> cause data corruption. I don't believe we have any choice other >> > > >> >> than to fully solve the root-cause. >> > > >> > > Yes I agree, and I think it is pretty close - certainly much better >> > > than it used to be. The good thing about them being annoying is that >> > > they will likely get fixed :-) >> > >> > I think I traced this to the copying of CSD a while back. The problem is >> > that the transferred buffer is 8 bytes, so there's no way to make it >> > aligned properly. Unfortunately the entailing discussion did not yield a >> > solution at the time. >> >> And how exactly does the MMC bounce buffer not help here? > > The problem solved by the bounce buffer is that it is properly cache- > line aligned. However the issue here is not that the buffer is not > properly aligned but rather that the transfer is too small. > > When the MMC core transfers the SCR, it requests 8 bytes. The buffer > used to store these 8 bytes is properly allocated. However, those 8 > bytes eventually end up as the size of the range that is to be > invalidated. This is the reason for the warning. Address x of the buffer > is cache-line aligned, but x + 8 is never properly aligned and therefore > the code complains. Would it be too dreadful to define a minimum MMC transfer size, and set that to the cache line size? While the bounce buffers are useful, I thought the intent was that they would be a temporary aeration while we fix the code that calls MMC? Regards, Simon > > Thierry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Limit of kernel size
Hello J.Hwan, On 16.09.2012 01:40, J.Hwan Kim wrote: Hi, everyone Is there limitation of the kernel size which u-boot loads? Only as I know the maximum RAM size (minus the size U-Boot needs) My kernel is very big, because I included the ramdisk into the kernel. My kernel size is over 40MB. When I load the kernel through u-boot, the prcedure hangs in the boot step. The step is "Uncompressing Linux done, booting the kernel" On which board with which RAM size? Please provide more Information including a u-boot log from reset, your environment ... and maybe it is a Linux problem ... 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] common, hush [BUG]: exit not work in hush shell
Hello Wolfgang,
On 14.09.2012 20:31, Wolfgang Denk wrote:
Dear Heiko Schocher,
In message<1347645856-3326-1-git-send-email...@denx.de> you wrote:
running the following script in u-boot:
setenv error 'if true; then
echo ERROR
exit;
fi'
I think I once tried to fix this, too.
See here:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/94660
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/94661
Later, I rejected both these patches (and several other, unpublished
versions I came up with during testing), because none of these worked
I can understand exactly how you feel... I had also several patches...
for all tests really reliable.
Do you still have this test somewhere?
rcode = source (addr, fit_uname);
+ if (rcode == -2) {
+ debug("Hit exit in script\n");
+ rcode = 0;
+ }
Hm... Note that "exit" can take an argment, which should be reflected
in the return code - I mean, would it not be wrong to reurn 0 if the
user has "exit 1" in his script?
Oh, Ok, this is a killing argument for this patch!
Please make sure to test this extensively. When I was trying to fix a
few similar issues with hush, I quickly gave up because I decided it
would be an easier (and more promising) undertaking to update the whole
hush code to a more recent version of hush.
Hmm... Okay, so I have two options:
- fix "exit" with arguments
- update to a recent version of hush (where is the current code from?)
But I have the gut feeling, that the problem is not in the original
code, but in the u-boot adaptions, as the code in hush.c has a lot
of "#ifndef __U_BOOT__" ...
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] Cache alignment warnings on Tegra (ARM)
On Sat, Sep 15, 2012 at 07:45:30PM -0700, Simon Glass wrote: > Hi, > > On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding > wrote: > > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: > >> Dear Thierry Reding, > >> > >> > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > >> > > Hi, > >> > > > >> > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: > >> > > > Dear Stephen Warren, > >> > > > > >> > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > >> > > >> > Dear Stephen Warren, > >> > > >> > > >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > >> > > >> >>> Folks, > >> > > >> >>> > >> > > >> >>> Stephen Warren has posted an internal bug regarding the cache > >> > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing MMC. > >> > > >> >>> Here's the gist: > >> > > >> >>> > >> > > >> >>> Executing "mmc dev 0" still yields cache warnings: > >> > > >> >>> > >> > > >> >>> Tegra20 (Harmony) # mmc dev 0 > >> > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- > >> > > >> >>> 0x3fb69908 mmc0 is current device > >> > > >> >> > >> > > >> >> ... > >> > > >> >> > >> > > >> >>> There have been patches in the past (IIRC) that have tried to > >> > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force > >> > > >> >>> their > >> > > >> >>> buffers to the appropriate alignment, but I don't know that we > >> > > >> >>> can ever correct every instance, now or in the future. > >> > > >> >>> > >> > > >> >>> Can we start a discussion about what we can do about this > >> > > >> >>> warning? > >> > > >> >>> Adding an appropriate #ifdef > >> > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen put > >> > > >> >>> his #if 0's would be one approach, or changing the printf() to a > >> > > >> >>> debug(), perhaps. As far as I can tell, these alignment 'errors' > >> > > >> >>> don't seem to produce bad data in the transfer. > >> > > >> >> > >> > > >> >> I don't think simply turning off the warning is the correct > >> > > >> >> approach; I believe they represent real problems that can in fact > >> > > >> >> cause data corruption. I don't believe we have any choice other > >> > > >> >> than to fully solve the root-cause. > >> > > > >> > > Yes I agree, and I think it is pretty close - certainly much better > >> > > than it used to be. The good thing about them being annoying is that > >> > > they will likely get fixed :-) > >> > > >> > I think I traced this to the copying of CSD a while back. The problem is > >> > that the transferred buffer is 8 bytes, so there's no way to make it > >> > aligned properly. Unfortunately the entailing discussion did not yield a > >> > solution at the time. > >> > >> And how exactly does the MMC bounce buffer not help here? > > > > The problem solved by the bounce buffer is that it is properly cache- > > line aligned. However the issue here is not that the buffer is not > > properly aligned but rather that the transfer is too small. > > > > When the MMC core transfers the SCR, it requests 8 bytes. The buffer > > used to store these 8 bytes is properly allocated. However, those 8 > > bytes eventually end up as the size of the range that is to be > > invalidated. This is the reason for the warning. Address x of the buffer > > is cache-line aligned, but x + 8 is never properly aligned and therefore > > the code complains. > > Would it be too dreadful to define a minimum MMC transfer size, and > set that to the cache line size? I did try setting the data size to the cache line size back then, but that resulted in an error. After that I gave up. I think what we really need to do is separate the invalidation size from the transfer size in order to properly handle these situations. Or alternatively pass an additional buffer size so the code knows how much needs to be invalidated. AFAICT this is the only location where this actually happens. All other transfers are typically block sized so they'll be a multiple of the cache line anyway. Thierry pgpJyioYEDbDY.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
