Re: [U-Boot] [PATCH] BOOT: Add RAW ramdisk support to bootz
Dear Wolfgang Denk, Dear Marek Vasut, In message 201203221745.16226.marek.va...@gmail.com you wrote: Dear Wolfgang Denk, are we OK with applying this and bootz patch please? Can we get it into .04 release please? this - which patch version exactly are you referring to? Revision V6. Could you please be a bit more specific? Like posting a link to the respective message on gmane, or in patchwork? http://patchwork.ozlabs.org/patch/146848/ http://patchwork.ozlabs.org/patch/147440/ The Subject: of this message is BOOT: Add RAW ramdisk support to bootz, but I have not seen any V6 for this patch. Ican only guess that you might be referring to [PATCH V6] BOOT: Add bootz command to boot Linux zImage on ARM - but I'd rather be sure. Yes, see above two links please. I believe this patch is quite important to the linux-arm people and early adoption of this stuff would be very beneficial. Also, there are other patches that were applied after the MW was closed. Finally, this patch started long before .04 release cycle. Where/when? If you mean the patch, here: http://patchwork.ozlabs.org/patch/125318/ If you talk about accepting patches way past MW, almost all the time, at least in the ARM stuffs. And this works OK so far I believe, I see no breakage. Also, we didn't reach the RC phase yet either. Lastly, this change is not intrusive in any way. Best regards, Wolfgang Denk 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 1/2] mx28evk: Provide default values for SPI bus and chip select
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com Provide default values for SPI bus and chip select. This allows the command sf probe to work without passing SPI bus and chip select numbers as arguments. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Marek Vasut ma...@denx.de --- include/configs/mx28evk.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 04967d7..112fda4 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -186,6 +186,8 @@ /* SPI Flash */ #ifdef CONFIG_CMD_SF #define CONFIG_SPI_FLASH +#define CONFIG_SF_DEFAULT_BUS2 +#define CONFIG_SF_DEFAULT_CS 0 /* this may vary and depends on the installed chip */ #define CONFIG_SPI_FLASH_SST #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 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 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
Dear Fabio Estevam, CONFIG_SPI_FLASH_CS is not used anywhere. Use CONFIG_SF_DEFAULT_CS instead. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/efikamx.h |2 +- include/configs/m28evk.h |2 +- include/configs/vision2.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h index af542fa..120055f 100644 --- a/include/configs/efikamx.h +++ b/include/configs/efikamx.h @@ -113,7 +113,7 @@ #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_SST -#define CONFIG_SPI_FLASH_CS (1 | 121 8) +#define CONFIG_SF_DEFAULT_CS (1 | 121 8) #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0) #define CONFIG_SF_DEFAULT_SPEED 2500 diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index 4d59153..4b97c71 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -252,7 +252,7 @@ #ifdef CONFIG_CMD_SF #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_STMICRO -#define CONFIG_SPI_FLASH_CS 2 +#define CONFIG_SF_DEFAULT_CS2 are you sure about this? Are you sure this does the same thing? #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 #define CONFIG_SF_DEFAULT_SPEED 2400 diff --git a/include/configs/vision2.h b/include/configs/vision2.h index 35b71f7..f6904f3 100644 --- a/include/configs/vision2.h +++ b/include/configs/vision2.h @@ -72,7 +72,7 @@ * Use gpio 4 pin 25 as chip select for SPI flash * This corresponds to gpio 121 */ -#define CONFIG_SPI_FLASH_CS (1 | (121 8)) +#define CONFIG_SF_DEFAULT_CS (1 | (121 8)) #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 #define CONFIG_SF_DEFAULT_SPEED 2500 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 05/14] cfb_console: Fix function console_scrollup
Hi, On Thu, 22 Mar 2012 01:58:02 -0700 (PDT) Pali Rohár pali.ro...@gmail.com wrote: ... Do you think that mapped address of framebuffer is only problem? I wrote that it could be a problem. I do not know much about your system and U-Boot port and do not know exactly what you meant by damaged screen output and when exactly it happens, so I can only speculate. Why then framebuffer output on n900 screen working without problem if I do NOT read framebuffer memory? Problem with garbaged display output seems happends only for read operations (console_scrollup, negation of pixels for cursor,...) but not for write-only operations (clear console, clear line, set black/white cursror, render fonsts...). I think if there is problem with address space, then garbaged screen should be also for framebuffer write operations... This is another issue then. Can you test read/write access to the frame buffer area by available memory commands cp, md, mm, cmp? Can you also verify that reading from frame buffer area by using these memory commands is not working? Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
On 23/03/2012 09:39, Marek Vasut wrote: Dear Fabio Estevam, CONFIG_SPI_FLASH_CS is not used anywhere. Use CONFIG_SF_DEFAULT_CS instead. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/efikamx.h |2 +- include/configs/m28evk.h |2 +- include/configs/vision2.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h index af542fa..120055f 100644 --- a/include/configs/efikamx.h +++ b/include/configs/efikamx.h @@ -113,7 +113,7 @@ #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_SST -#define CONFIG_SPI_FLASH_CS (1 | 121 8) +#define CONFIG_SF_DEFAULT_CS(1 | 121 8) #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0) #define CONFIG_SF_DEFAULT_SPEED 2500 diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index 4d59153..4b97c71 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -252,7 +252,7 @@ #ifdef CONFIG_CMD_SF #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_STMICRO -#define CONFIG_SPI_FLASH_CS 2 +#define CONFIG_SF_DEFAULT_CS2 are you sure about this? Are you sure this does the same thing? Are we sure that CONFIG_SPI_FLASH_CS has still a meaning ? It seems to me that SPI flash uses now CONFIG_SF_DEFAULT_CS, and we should exchange other boards exactly as Fabio does for mx28evk. Is there still code using CONFIG_SPI_FLASH_CS ? 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-53 Fax: +49-8142-66989-80 Email: sba...@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] configs: imx: Use CONFIG_SF_DEFAULT_CS
Dear Stefano Babic, On 23/03/2012 09:39, Marek Vasut wrote: Dear Fabio Estevam, CONFIG_SPI_FLASH_CS is not used anywhere. Use CONFIG_SF_DEFAULT_CS instead. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/efikamx.h |2 +- include/configs/m28evk.h |2 +- include/configs/vision2.h |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h index af542fa..120055f 100644 --- a/include/configs/efikamx.h +++ b/include/configs/efikamx.h @@ -113,7 +113,7 @@ #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_SST -#define CONFIG_SPI_FLASH_CS (1 | 121 8) +#define CONFIG_SF_DEFAULT_CS (1 | 121 8) #define CONFIG_SF_DEFAULT_MODE(SPI_MODE_0) #define CONFIG_SF_DEFAULT_SPEED 2500 diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h index 4d59153..4b97c71 100644 --- a/include/configs/m28evk.h +++ b/include/configs/m28evk.h @@ -252,7 +252,7 @@ #ifdefCONFIG_CMD_SF #define CONFIG_SPI_FLASH #define CONFIG_SPI_FLASH_STMICRO -#define CONFIG_SPI_FLASH_CS 2 +#define CONFIG_SF_DEFAULT_CS2 are you sure about this? Are you sure this does the same thing? Are we sure that CONFIG_SPI_FLASH_CS has still a meaning ? It seems to me that SPI flash uses now CONFIG_SF_DEFAULT_CS, and we should exchange other boards exactly as Fabio does for mx28evk. Is there still code using CONFIG_SPI_FLASH_CS ? No, that's why I'm asking. And I see no use of CONFIG_SPI_FLASH_CS. All right then: Acked-by: Marek Vasut ma...@denx.de Best regards, Stefano Babic 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 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
On 23/03/2012 10:18, Marek Vasut wrote: No, that's why I'm asking. And I see no use of CONFIG_SPI_FLASH_CS. All right then: Acked-by: Marek Vasut ma...@denx.de Ok, then everything is clear. Acked-by: Stefano Babic sba...@denx.de 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-53 Fax: +49-8142-66989-80 Email: sba...@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] mx28evk: Provide default values for SPI bus and chip select
On 23/03/2012 01:29, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Provide default values for SPI bus and chip select. This allows the command sf probe to work without passing SPI bus and chip select numbers as arguments. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX53: DDR: Fix ZQHWCTRL field TZQ_CS
On 23/03/2012 04:25, Troy Kisky wrote: On 3/22/2012 6:47 PM, Troy Kisky wrote: On 3/22/2012 3:00 PM, Troy Kisky wrote: Currently, board files are setting this field to 0x01 which the manual says is a reserved value. Change to use the default of 0x04 - 128 cycles. Typo, should say default of 0x02 - 128 cycles Possibly the manual is wrong, and the value of 0x01 corresponds to 64 cycles? My testing was on a DDR2 device where this field is not relevant. Is there someone who can answer to this question ? This patch fixes the value according to the manual, without doubts. But if the manual is wrong... 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53: Make PLL2 to be the parent of UART clock
On 21/03/2012 16:42, Fabio Estevam wrote: Change the parent UART clock to be PLL2, so that U-boot can also boot a Freescale 2.6.35 kernel for mx53. FSL kernel and U-boot changed the UART parent from PLL3 to PLL2 to avoid conflicts with IPU clocks, so that the video resolution can be changed without affecting the UART clock. On a 2.6.35 kernel the serial console is messed up after IPU driver is loaded and this patch fixes this problem. Tested on a mx53loco board booting a FSL kernel and also a mainline kernel. Reported-by: Otavio Salvador ota...@ossystems.com.br Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53ard: Initialize return code with error
On 20/03/2012 00:41, Fabio Estevam wrote: The variable rc is the return of board_eth_init() function. Initialize it with an error code, so that this function can return an error when CONFIG_SMC911X is not set. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
Hi Scott, On Friday 23 March 2012 01:13 AM, Scott Wood wrote: On 03/22/2012 12:52 AM, Prabhakar Kushwaha wrote: Hi Scott, Please find my reply in-lined On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR + IVOR15) to have valid and fetchable OP code. While executing in translated space (AS=1), whenever a debug exception is generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to fetch an instruction from the debug exception vector (IVPR + IVOR15); since now we are in AS=0, the application needs to ensure the proper TLB configuration to have (IVOR + IVOR15) accessible from AS=0 also. Create a temporary TLB in AS0 to make sure debug exception verctor is accessible on debug exception. Signed-off-by: Radu Lazarescuradu.lazare...@freescale.com Signed-off-by: Marius Grigorasmarius.grigo...@freescale.com Signed-off-by: Prabhakar Kushwahaprabha...@freescale.com Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). Sure. May be separate patch will be send. Let's start with just an e-mail thoroughly describing your understanding of this. It will provide necessary context for review. We can clean it up for permanent documentation once it's clear to everyone what's going on. Sure. I will start this activity from now. But i will suggest not to combine both patches. let debugger patch to go ahead , if required i will send required patch later-on. In the ramboot case is this really supposed to be I+G? I am not sure. But same is done under label create_init_ram_area for TLB entry 15. what you suggest. I suggest as part of the request to document all of this, you figure out what should actually be mapped in each configuration. The existing code might be wrong for some of them, but we shouldn't proceed ahead blindly and make an even bigger mess. After internal discussion we can have following settings for non-RAMBOOT(NOR boot) == I + G for RAMBOOT == I, cache inhibited is required as L1 cache is used as stack. I=0 it means the memory range is cacheable, so an access to an address from that range could get the line in cache. If you are using the cache as a memory zone(L1 as stack), it may overwrite some data in cache and replace it with the last access. Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. i think NAND_SPL does not require temporary TLB as NAND SPL even does not have any interrupt vector. So there's no plan to support using breakpoints or single step during the SPL? That's fine with me, but should be documented, and we should make sure this code does not run in that case. Breakpoints will work as it is. No impact will be on debugging for NAND SPL. Generally any debugger use some initial configuration file. Only problem occurs when application modifies those configuration. +lis r10,0xffc0@h +ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. Please refer above response. May be this piece of code is not required for NAND SPL Still, I'd like to know why you're writing 0xffc0 to MAS7. Only the low 4 bits of MAS7 are valid on current e500. The reason for using 0xffc0 to support e6500 - since it supports 40-bit physical addresses, the last 8 bits of MAS7 are defined. But i am not sure whether e6500 will be part of mpc85xx or not. So, I will use as #ifdef CONFIG_ENABLE_36BIT_PHYS lis r10,0x #endif +mtspr MAS0,r6 +mtspr MAS1,r7 +mtspr MAS2,r8 +mtspr MAS3,r9 +mtspr MAS7,r10 Why are you writing 0xffc0 into MAS7? Access to MAS7 needs to be conditional on CONFIG_ENABLE_36BIT_PHYS (misnamed, should be something like CONFIG_SYS_PPC_HAS_MAS7). i will put this code under #define CONFIG_ENABLE_36BIT_PHYS For your kind information : in start.S, label label create_ccsr_new_tlb, create_ccsr_old_tlb uses MAS7 without CONFIG_ENABLE_36BIT_PHYS #define. It should be fixed ?? Yes, it should be fixed. That was a fairly recent change and perhaps e500v1 has not been tested since then -- Timur, could you look at this? i will use CONFIG_ENABLE_36BIT_PHYS defines. diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 8654625..268c56e 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -1,5 +1,5 @@ /* - * Copyright 2011 Freescale Semiconductor, Inc. + * Copyright 2011-2012 Freescale Semiconductor, Inc. * * This
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Graeme,
On Thu, Mar 22, 2012 at 4:41 PM, Graeme Russ graeme.r...@gmail.com wrote:
Hi Simon,
On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass s...@google.com wrote:
I am going to have a similar problem in the SPL soon - how to deal
with panic(). Advice gratefully accepted.
Take a leaf out of the Linux x86 source
arch/x86/boot/main.c - This is the start of the 16-bit 'real-mode' code
which is entered by the boot loader (so it's like SPL - IPL being the
BIOS/Bootloader combo)
void main(void)
{
/* First, copy the boot header into the zeropage */
copy_boot_params();
/* Initialize the early-boot console */
console_init();
...
arch/x86/boot/early_serial_console.c
void console_init(void)
{
parse_earlyprintk();
if (!early_serial_base)
parse_console_uart8250();
}
early_serial_base is a global defined in boot.h:
extern int early_serial_base;
You can do the same in SPL, but you are not going to have the luxury of
having it configurable unless you can do so in some non-volatile memory
or hardware configuration (dedicated GPIO pins etc)
It's a chicken and egg scenario - If you want your default console port to
be configurable, you need code to determine the configuration. But you
cannot spew out debug messages for the code which determines the console
configuration. Linux x86 has the same problem, there is no way to ouput
debug messages in copy_boot_params() or console_init()
In U-Boot we kind of 'cheat' - We define a board specific default console
in the board config (hard coded in the U-Boot binary) which we use unitl
environment variables are available. Linux x86 could do the same - have
compile time options which allow the serial console to be enabled before
copy_boot_params(), but the amount of code which is 'dark' is so small
it's not worth it.
U-Boot is different, the amount of code that is 'dark' before the
environment variables are available is rather large. And pre console
buffer covers the 'dark' code just prior to the hard-coded console being
available (but of course pre console buffer does not help if there is a
hang or crash before the hard-coded console is available)
Thanks very much for your comments.
Yes it is this dark period that bothers me. I think for now the
solution is to ignore it and hope that nothing goes wrong,
particularly with the revert of even the pre-console putc(). I think
for now I will provide an option to check the device tree later in the
boot, and later look at having some sort of fallback config for the
console.
I should check - Is it possible to not have a default console, and
therefor pre console buffer is used all the way up to the console defined
in the environment being intialised?
I actually created a patch to delay console init until after
relocation, just to see how this might work. It works fine, and does
speed things up a little, but is of course not in keeping with the
U-Boot design.
Anyway all I am really concerned about is that we might not make it
through the dark period. For now I am going to forget about that
problem; there are plenty of others.
Regards,
Simon
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC v0 01/11] omap3+: Introduce configs/omap3_common.h
On Thu, Mar 22, 2012 at 09:48:27PM -0400, Jason Kridner wrote: I'm reading/replying to these one-by-one for sanity/clarity with regards to BeagleBoard... [snip] diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 80b9a5a..21e4b01 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -29,16 +29,21 @@ #define __CONFIG_H /* - * High Level Configuration Options + * Values that differ from platform defaults or are unspecified. */ -#define CONFIG_OMAP 1 /* in a TI OMAP core */ -#define CONFIG_OMAP34XX 1 /* which is a 34XX */ -#define CONFIG_OMAP3_BEAGLE 1 /* working with BEAGLE */ +#define CONFIG_SDRC /* The chip has SDRC controller */ -#define CONFIG_SDRC /* The chip has SDRC controller */ I can see it can make sense to have an OMAP/DM/AM3x target without SDRC enabled. Er, right. That's why SDRC or EMIF is done per-board for us (omap4/5 are EMIF only and if we can honestly keep am335x at one config for all boards it'll just be opting in to later parts of these kind of series). -- Tom 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 1/1] MX53: DDR: Fix ZQHWCTRL field TZQ_CS
Hi Stefano, On Fri, Mar 23, 2012 at 6:34 AM, Stefano Babic sba...@denx.de wrote: Is there someone who can answer to this question ? This patch fixes the value according to the manual, without doubts. But if the manual is wrong... We are checking this internally at Freescale and will keep the list updated. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
On 03/23/2012 06:44 AM, Prabhakar Kushwaha wrote: Hi Scott, On Friday 23 March 2012 01:13 AM, Scott Wood wrote: On 03/22/2012 12:52 AM, Prabhakar Kushwaha wrote: Hi Scott, Please find my reply in-lined On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR + IVOR15) to have valid and fetchable OP code. While executing in translated space (AS=1), whenever a debug exception is generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to fetch an instruction from the debug exception vector (IVPR + IVOR15); since now we are in AS=0, the application needs to ensure the proper TLB configuration to have (IVOR + IVOR15) accessible from AS=0 also. Create a temporary TLB in AS0 to make sure debug exception verctor is accessible on debug exception. Signed-off-by: Radu Lazarescuradu.lazare...@freescale.com Signed-off-by: Marius Grigorasmarius.grigo...@freescale.com Signed-off-by: Prabhakar Kushwahaprabha...@freescale.com Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). Sure. May be separate patch will be send. Let's start with just an e-mail thoroughly describing your understanding of this. It will provide necessary context for review. We can clean it up for permanent documentation once it's clear to everyone what's going on. Sure. I will start this activity from now. But i will suggest not to combine both patches. let debugger patch to go ahead , if required i will send required patch later-on. My point is that I cannot fully follow what's going on here without spending a bunch of time looking at it, and I don't see anyone else stepping up to review this, so I'd like to see a write-up of what's going on so that I can properly review these patches. In the ramboot case is this really supposed to be I+G? I am not sure. But same is done under label create_init_ram_area for TLB entry 15. what you suggest. I suggest as part of the request to document all of this, you figure out what should actually be mapped in each configuration. The existing code might be wrong for some of them, but we shouldn't proceed ahead blindly and make an even bigger mess. After internal discussion we can have following settings for non-RAMBOOT(NOR boot) == I + G for RAMBOOT == I, cache inhibited is required as L1 cache is used as stack. Why does using L1 for a stack mean that the mapping must be cache inhibited? Why do we even need to use L1 for a stack with ramboot? I=0 it means the memory range is cacheable, so an access to an address from that range could get the line in cache. If you are using the cache as a memory zone(L1 as stack), it may overwrite some data in cache and replace it with the last access. It will not do that -- when we use L1 (or part of it) for an early stack, we lock the cache lines. Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. i think NAND_SPL does not require temporary TLB as NAND SPL even does not have any interrupt vector. So there's no plan to support using breakpoints or single step during the SPL? That's fine with me, but should be documented, and we should make sure this code does not run in that case. Breakpoints will work as it is. No impact will be on debugging for NAND SPL. Generally any debugger use some initial configuration file. Only problem occurs when application modifies those configuration. Then why do we need to set MSR[DE] on entry, if the debugger can take care of it? +lis r10,0xffc0@h +ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. Please refer above response. May be this piece of code is not required for NAND SPL Still, I'd like to know why you're writing 0xffc0 to MAS7. Only the low 4 bits of MAS7 are valid on current e500. The reason for using 0xffc0 to support e6500 - since it supports 40-bit physical addresses, the last 8 bits of MAS7 are defined. Regardless, you're setting the wrong end of MAS7. It's the *lower* bits, not the upper bits, that are used. And we should not be doing anything special for e6500 here. e6500 does not need this, and e6500 platforms should not set CONFIG_SYS_PPC_E500_DEBUG_TLB. But i am not sure whether e6500 will be part of mpc85xx or not. It will. So, I will use as #ifdef CONFIG_ENABLE_36BIT_PHYS lis r10,0x #endif Why? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de
[U-Boot] NetConsole TFTP
Hi all, I am trying to use the NetConsole to configure the U-Boot and to send command to it. Everything works fine, but I also need to transfer files via TFTP. It looks like that is a problem and I hope the members of this mailing list can give me some answers and maybe solutions. Is it possible to use NetConsole and TFTP parallel at one Ethernet interface? My fist thoughts were that this could be possible, because TFTP and NetConsole use different ports. But out of the box the behavior is different. In my tests TFTP tries to use another Ethernet interface (eTSEC1) as the NetConsole (eTSEC0), but the final Hardware has only one Ethernet and no serial interface. By the way, I tried the functionality with a second Ethernet interface and it also does not work. I see only less character at the NetConsole and it seems that the communication is going wrong and after a short time the communication is dead. Therefore I need a possibility to communicate with a target (via NetConsole) and transfer the flash images (via TFTP). Has anybody experiences with this? Is this possible with U-Boot? Maybe I am doing something wrong? Thank you for helping. Regards, Thomas SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB OTG host mode support in u-boot (Ethernet Over USB)
I am trying to get usb-ethernet dongle to work in u-boot but in order to get this to work I need to have the device in host mode. My current platform doesn't have USB host EHCI port but it has the micro OTG port and I have verified that keyboard/mouse/usb-ethernet all work on this port in Linux. But I have not been able to get ethernet over USB to work in u-boot (using Micro-A cable). Ethernet over USB is already supported in u-boot for the USB host but it seems that USB OTG support is missing from u-boot. Can someone advise or suggest a solution to get ethernet over USB to work in u-boot using USB OTG host? Thanks, Behnam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NetConsole TFTP
Dear Thomas, In message of0b4b1e6c.b54b0c2d-onc12579ca.0038e059-c12579ca.0038f...@sick.de you wrote: Is it possible to use NetConsole and TFTP parallel at one Ethernet interface? My fist thoughts were that this could be possible, because TFTP Yes, this is supposed to work. We've even seen running TFTP and Netconsole over Ethernet over USB... and NetConsole use different ports. But out of the box the behavior is different. In my tests TFTP tries to use another Ethernet interface (eTSEC1) as the NetConsole (eTSEC0), but the final Hardware has only one Hm... you are not running mainline code, right? Because we always have a single network interface active at any time. Therefore I need a possibility to communicate with a target (via NetConsole) and transfer the flash images (via TFTP). Has anybody experiences with this? Is this possible with U-Boot? Maybe I am doing something wrong? I recommend you undo any modifications made to the network stack, and/or try plain mainline code instead. 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 Premature optimization is the root of all evil. -- D.E. Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] net/eth: set status to active before calling init
If we set the status after successful init call then we get in trouble
if stdout (or setderr) is set to netconsole. If we are going to use one
of those (lets say printf) during -init() the following happens:
- network is of (state passive)
- we switch on netconsole
- nc_getc() gets called
- in NetLoop() we switch on ethernet via eth_init()
- we end up in tsec_init() (inc case we use the tsec driver). Here we
call a printf()
- That printf() ends up in nc_puts() because netconsole is our default
output.
- The state is not active yet, so we call eth_init() once again.
- and we are again in tsec_init(). Another printf() is waiting. However,
due to the recursion check nc_puts() returns early before doing
anything.
- we return from each function. Sine nc_puts() thinks that it was in
charge of enabling the ethernet, it disables it before leaving.
- We return now to the top-most eth_init() function. Since everything
went fine, it sets the status to active. In reality the network is
switched off.
- nc_getc() gets called over and over to receive new packets. Sadly the
nic is disabled and new network packets won't be noticed.
This patch sets the network status early so nc_puts() does not get
confused and disables the network interface in case of a printf() on its
way.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
net/eth.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/eth.c b/net/eth.c
index 4280d6d..bca405a 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -380,14 +380,17 @@ int eth_init(bd_t *bis)
old_current = eth_current;
do {
+ int old_state;
+
debug(Trying %s\n, eth_current-name);
- if (eth_current-init(eth_current,bis) = 0) {
- eth_current-state = ETH_STATE_ACTIVE;
-
+ old_state = eth_current-state;
+ eth_current-state = ETH_STATE_ACTIVE;
+ if (eth_current-init(eth_current,bis) = 0)
return 0;
- }
+
debug(FAIL\n);
+ eth_current-state = old_state;
eth_try_another(0);
} while (old_current != eth_current);
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] net/tsec: Don't tell the link status if used with netconsole
Since we start/stop the network after each character we see that line printed a lot. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/net/tsec.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c index 78badfa..9af3c7e 100644 --- a/drivers/net/tsec.c +++ b/drivers/net/tsec.c @@ -235,9 +235,11 @@ static void adjust_link(struct tsec_private *priv, struct phy_device *phydev) out_be32(regs-ecntrl, ecntrl); out_be32(regs-maccfg2, maccfg2); - serial_printf(Speed: %d, %s duplex%s\n, phydev-speed, - (phydev-duplex) ? full : half, - (phydev-port == PORT_FIBRE) ? , fiber mode : ); + if (strcmp(getenv(stdout), nc)) + serial_printf(Speed: %d, %s duplex%s\n, phydev-speed, + (phydev-duplex) ? full : half, + (phydev-port == PORT_FIBRE) ? , fiber mode + : ); } #ifdef CONFIG_SYS_FSL_ERRATUM_NMG_ETSEC129 -- 1.7.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] net/tsec: convert the printf() to serial_printf()
In case we use netconsole for stdout and something goes wrong here and
we run into one of this printf() then there is no point of sending this
over network again since it is likely that will fail again.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/net/tsec.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 160bc05..78badfa 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -199,7 +199,7 @@ static void adjust_link(struct tsec_private *priv, struct
phy_device *phydev)
u32 ecntrl, maccfg2;
if (!phydev-link) {
- printf(%s: No link.\n, phydev-dev-name);
+ serial_printf(%s: No link.\n, phydev-dev-name);
return;
}
@@ -228,14 +228,14 @@ static void adjust_link(struct tsec_private *priv, struct
phy_device *phydev)
ecntrl |= ECNTRL_R100;
break;
default:
- printf(%s: Speed was bad\n, phydev-dev-name);
+ serial_printf(%s: Speed was bad\n, phydev-dev-name);
break;
}
out_be32(regs-ecntrl, ecntrl);
out_be32(regs-maccfg2, maccfg2);
- printf(Speed: %d, %s duplex%s\n, phydev-speed,
+ serial_printf(Speed: %d, %s duplex%s\n, phydev-speed,
(phydev-duplex) ? full : half,
(phydev-port == PORT_FIBRE) ? , fiber mode : );
}
@@ -287,7 +287,7 @@ void redundant_init(struct eth_device *dev)
/* Wait for buffer to be received */
for (t = 0; rtx.rxbd[rxIdx].status RXBD_EMPTY; t++) {
if (t = 10 * TOUT_LOOP) {
- printf(%s: tsec: rx error\n, dev-name);
+ serial_printf(%s: tsec: rx error\n,
dev-name);
break;
}
}
@@ -305,7 +305,7 @@ void redundant_init(struct eth_device *dev)
out_be32(regs-rstat, RSTAT_CLEAR_RHALT);
}
if (fail) {
- printf(loopback recv packet error!\n);
+ serial_printf(loopback recv packet error!\n);
clrbits_be32(regs-maccfg1, MACCFG1_RX_EN);
udelay(1000);
setbits_be32(regs-maccfg1, MACCFG1_RX_EN);
@@ -428,7 +428,7 @@ static int tsec_recv(struct eth_device *dev)
if (!(rtx.rxbd[rxIdx].status RXBD_STATS)) {
NetReceive(NetRxPackets[rxIdx], length - 4);
} else {
- printf(Got error %x\n,
+ serial_printf(Got error %x\n,
(rtx.rxbd[rxIdx].status RXBD_STATS));
}
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] Revert Add board_pre_console_putc to deal with early console output
Dear Simon, In message 1332219558-9143-1-git-send-email-...@chromium.org you wrote: This reverts commit 295d3942b806552503243f5cfb36aec6f1b5a9bf. It turns that this really doesn't work very nicely. Instead we should have a pre-console panic function so that we know that further execution is impossible and we don't need to worry about trampling on UARTs, etc. Signed-off-by: Simon Glass s...@chromium.org --- README | 17 - common/console.c | 10 +- include/common.h |7 --- 3 files changed, 1 insertions(+), 33 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If all you have is a hammer, everything looks like a nail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for u-boot-nds32
Dear Macpaul Lin, In message caccg+xp+jopurj4r6kq6ldannvipcwealznoetmpxp98t2d...@mail.gmail.com you wrote: --e89a8ff1c62e4e8e0a04bb93f28d Content-Type: text/plain; charset=ISO-8859-1 Dear Wolfgang, Please pull the following 2 fix patches into your master branch. Thanks! The following changes since commit dbb87bbd8eff11cf974caa2b5cc397aea444bc5a: Armada100: gplugD: Add FAT EXT2 command support (2012-03-19 00:08:26 +0100) are available in the git repository at: git://git.denx.de/u-boot-nds32.git master Macpaul Lin (2): nds32: fix ptrace and interrupt register overflow nds32/n1213: correct vector table in start.S arch/nds32/cpu/n1213/start.S| 22 +++--- arch/nds32/include/asm/ptrace.h |2 ++ arch/nds32/lib/interrupts.c |2 +- 3 files changed, 22 insertions(+), 4 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you think the problem is bad now, just wait until we've solved it. Epstein's Law ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-cfi-flash/master
Dear Stefan Roese, In message 201203211628.51225...@denx.de you wrote: please pull the following fix: The following changes since commit dbb87bbd8eff11cf974caa2b5cc397aea444bc5a: Armada100: gplugD: Add FAT EXT2 command support (2012-03-19 00:08:26 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 85c344e5f98408c0bcf988a6c6fca68c1f3c2015: cfi: fix the incomplete erased status check in buffer write (2012-03-21 16:25:33 +0100) Tao Hou (1): cfi: fix the incomplete erased status check in buffer write drivers/mtd/cfi_flash.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When a child is taught ... its programmed with simple instructions -- and at some point, if its mind develops properly, it exceeds the sum of what it was taught, thinks independently. -- Dr. Richard Daystrom, The Ultimate Computer, stardate 4731.3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootstage: Fix build error for standalone API example
Hi Simon,
On Mon, 19 Mar 2012 22:49:30 -0700
Simon Glass s...@chromium.org wrote:
This example doesn't have get_timer() defined, which causes build breakages.
Add #ifdef guards to work around this.
Signed-off-by: Simon Glass s...@chromium.org
---
lib/time.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/time.c b/lib/time.c
index 69edc3d..5f393c3 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -48,6 +48,7 @@ void mdelay(unsigned long msec)
udelay(1000);
}
+#ifdef CONFIG_BOOTSTAGE
ulong __timer_get_boot_us(void)
{
static ulong base_time;
@@ -64,3 +65,4 @@ ulong __timer_get_boot_us(void)
ulong timer_get_boot_us(void)
__attribute__((weak, alias(__timer_get_boot_us)));
+#endif
Isn't it better to move timer_get_boot_us() to common/bootstage.c ?
Or is there a plan to use this function not only in bootstage code?
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootstage: Fix build error for standalone API example
Hi Anatolij,
On Fri, Mar 23, 2012 at 3:32 PM, Anatolij Gustschin ag...@denx.de wrote:
Hi Simon,
On Mon, 19 Mar 2012 22:49:30 -0700
Simon Glass s...@chromium.org wrote:
This example doesn't have get_timer() defined, which causes build breakages.
Add #ifdef guards to work around this.
Signed-off-by: Simon Glass s...@chromium.org
---
lib/time.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/time.c b/lib/time.c
index 69edc3d..5f393c3 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -48,6 +48,7 @@ void mdelay(unsigned long msec)
udelay(1000);
}
+#ifdef CONFIG_BOOTSTAGE
ulong __timer_get_boot_us(void)
{
static ulong base_time;
@@ -64,3 +65,4 @@ ulong __timer_get_boot_us(void)
ulong timer_get_boot_us(void)
__attribute__((weak, alias(__timer_get_boot_us)));
+#endif
Isn't it better to move timer_get_boot_us() to common/bootstage.c ?
Or is there a plan to use this function not only in bootstage code?
Yes I sent through the smallest fix.
But as I said in the patch thread I am not sure which is best.
I'm happy to do it either way, so let me know and I can do a patch the
other way.
Regards,
Simon
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
On Friday 23 March 2012 11:44 PM, Scott Wood wrote: On 03/23/2012 06:44 AM, Prabhakar Kushwaha wrote: Hi Scott, On Friday 23 March 2012 01:13 AM, Scott Wood wrote: On 03/22/2012 12:52 AM, Prabhakar Kushwaha wrote: Hi Scott, Please find my reply in-lined On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR + IVOR15) to have valid and fetchable OP code. While executing in translated space (AS=1), whenever a debug exception is generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to fetch an instruction from the debug exception vector (IVPR + IVOR15); since now we are in AS=0, the application needs to ensure the proper TLB configuration to have (IVOR + IVOR15) accessible from AS=0 also. Create a temporary TLB in AS0 to make sure debug exception verctor is accessible on debug exception. Signed-off-by: Radu Lazarescuradu.lazare...@freescale.com Signed-off-by: Marius Grigorasmarius.grigo...@freescale.com Signed-off-by: Prabhakar Kushwahaprabha...@freescale.com Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). Sure. May be separate patch will be send. Let's start with just an e-mail thoroughly describing your understanding of this. It will provide necessary context for review. We can clean it up for permanent documentation once it's clear to everyone what's going on. Sure. I will start this activity from now. But i will suggest not to combine both patches. let debugger patch to go ahead , if required i will send required patch later-on. My point is that I cannot fully follow what's going on here without spending a bunch of time looking at it, and I don't see anyone else stepping up to review this, so I'd like to see a write-up of what's going on so that I can properly review these patches. Means i have to make the doc first :( OK. Its my pleasure. In the ramboot case is this really supposed to be I+G? I am not sure. But same is done under label create_init_ram_area for TLB entry 15. what you suggest. I suggest as part of the request to document all of this, you figure out what should actually be mapped in each configuration. The existing code might be wrong for some of them, but we shouldn't proceed ahead blindly and make an even bigger mess. After internal discussion we can have following settings for non-RAMBOOT(NOR boot) == I + G for RAMBOOT == I, cache inhibited is required as L1 cache is used as stack. Why does using L1 for a stack mean that the mapping must be cache inhibited? Why do we even need to use L1 for a stack with ramboot? it is done at label _start_cont. L1 is set for Stack address as switch_as label. am i wrong?? I=0 it means the memory range is cacheable, so an access to an address from that range could get the line in cache. If you are using the cache as a memory zone(L1 as stack), it may overwrite some data in cache and replace it with the last access. It will not do that -- when we use L1 (or part of it) for an early stack, we lock the cache lines. Agree.. Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. i think NAND_SPL does not require temporary TLB as NAND SPL even does not have any interrupt vector. So there's no plan to support using breakpoints or single step during the SPL? That's fine with me, but should be documented, and we should make sure this code does not run in that case. Breakpoints will work as it is. No impact will be on debugging for NAND SPL. Generally any debugger use some initial configuration file. Only problem occurs when application modifies those configuration. Then why do we need to set MSR[DE] on entry, if the debugger can take care of it? Yes. You are right. It is required only for SD/SPI boot not for NAND_SPL/NOR boot. But to make MSR[DE] bit set general way (out of #define) throughout u-boot code. I did. +lis r10,0xffc0@h +ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. Please refer above response. May be this piece of code is not required for NAND SPL Still, I'd like to know why you're writing 0xffc0 to MAS7. Only the low 4 bits of MAS7 are valid on current e500. The reason for using 0xffc0 to support e6500 - since it supports 40-bit physical addresses, the last 8 bits of MAS7 are defined. Regardless, you're setting the wrong end of MAS7. It's the *lower* bits, not the upper bits, that are used. oh.. got your point. And we should not be doing anything special for e6500 here. e6500 does
[U-Boot] Loading kernel from usb
I am currently working on a project and I am trying to load the kernel from usb instead of an sd card. How do you configure u-boot to support usb commands? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
