Re: [U-Boot] [PATCH 0/6] ARMv7: Add HYP mode switching support
On 05/31/2013 08:11 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:44PM +0200, Andre Przywara wrote: (for GIT URL and Changelog see below) ARM CPUs with the virtualization extension have a new mode called HYP mode, which allows hypervisors to safely control and monitor guests. The current hypervisor (KVM and Xen) implementations require the kernel to be entered in that HYP mode. This patch series introduces a configuration variable CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP mode. This is done automatically during execution of the bootm command (but could also be done earlier - U-Boot runs fine in HYP mode without MMU usage). I forget the u-boot specifics here, but if you boot over networking, for example, does that eventually end up calling bootm or would Hyp mode not be entered in this case? Despite the naming bootm is eventually always called when booting Linux, even bootz is a wrapper around this. Same with network boot. So unless you show me a case where this isn't, I think this is fine. Regards, Andre. I'm only raising this issue because it's important to minimize the hoops and efforts for booting in Hyp mode, since it's harmless to do so regardless of the linux kernel we're booting. [...] -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TFTP timeouts, i.mx fec problem?
Hi everyone, I have been testing for a while now on the i.mx28 evk, and I noticed that almost all tftp transfers take some time before they actually start. It will show a 'T' as first character, then followed by '#' chars. After enabling some debug info, it appeared that it would always start by sending an ARP request, but this ARP message does not get sent actually (monitored with Wireshark). After 5 seconds the 2nd ARP request is sent (this does get traced by Wireshark) and also responded and from that point all goes well. When tracing the code, it could see that fec_send is called for the 1st ARP request and also the return value indicates that sending should have been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is actually sent. My first guess would be that it has something to do with the TBD / DMA part. The fec_tbd_init also shows some note about a rare hardware condition regarding the WRAP bit (all in drivers/net/fec_mxc.c). Could it be that there is still another issue regarding the chip that causes this? If I do a tftp transfer from linux on the same board and in the same network, it does start immediately. ===DEBUG LOG=== U-Boot tftp versions.ini eth_halt: wait for stop regs eth_halt: done Trying FEC0 fec_init fec_tbd_init fec_mii_setspeed: mii_speed 003c fec_open: fec_open(dev) fec_open:Speed=100 TFTP blocksize = 1468, timeout = 5000 ms TFTP from server 192.168.0.100; our IP address is 192.168.0.109 Filename 'versions.ini'. Loading: send option timeout 5 sending ARP for 192.168.0.100 ARP broadcast 1 fec_send: status 0xc00 index 0 ret 0 T send option timeout 5 sending ARP for 192.168.0.100 ARP broadcast 1 fec_send: status 0x2c00 index 1 ret 0 Got ARP REPLY, set eth addr (00:0c:29:65:b4:8a) fec_send: status 0xc00 index 0 ret 0 received UDP (to=192.168.0.109, from=192.168.0.100, len=53) Got OACK: timeout 5 Blocksize ack: 1468, 1468 sending UDP to 192.168.0.100/00:0c:29:65:b4:8a fec_send: status 0x2c00 index 1 ret 0 received UDP (to=192.168.0.109, from=192.168.0.100, len=100) #sending UDP to 192.168.0.100/00:0c:29:65:b4:8a fec_send: status 0xc00 index 0 ret 0 0 Bytes/s done Bytes transferred = 68 (44 hex) eth_halt: wait for stop regs eth_halt: done U-Boot == Thanks in advance for any comments. Regards, Ruud ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
Dear Robert,
In message camdmj5pj_aqzaxtrdnvs8ju_skvhv7zodrbuyhgjt2jfr4o...@mail.gmail.com
you wrote:
board/boundary/nitrogen6x/nitrogen6x.c | 22 ++
include/configs/nitrogen6x.h | 11 ++-
2 files changed, 32 insertions(+), 1 deletion(-)
Could you please explain why you need custom code here?
I originally tried to use the CONFIG_SPLASH_SCREEN_PREPARE functionality.
After some frustration, I figured out that without CONFIG_LCD, it is never
actually called.
http://git.denx.de/?p=u-boot/u-boot-imx.git;a=blob;f=common/stdio.c;h=5d5117c0ed838195a2caad7c28c128247771cd92;hb=HEAD#l216
It does seem odd that there are 2 totally different paths and the other
splash screen related macros are used in both but the prepare function is
only called in the LCD case.
OK, so this is a bug that needs to be fixed - but for all boards.
Since we use CONFIG_VIDEO and not CONFIG_LCD, this seemed to be the best,
or at least the least invasive, solution.
No, this is definitely not the best solution, as it keeps the bug,
so the next one who tries to do what you are doing will run into it
again.
Pleast let's fix the problem at the cause.
Please fix the video code to also run splash_screen_prepare() at the
appropriate place. While you are at it, please also replace this
construct
1071 #ifdef CONFIG_SPLASH_SCREEN_PREPARE
1072 static inline int splash_screen_prepare(void)
1073 {
1074 return board_splash_screen_prepare();
1075 }
1076 #else
1077 static inline int splash_screen_prepare(void)
1078 {
1079 return 0;
1080 }
1081 #endif
(in common/lcd.c) and use a weak function for
splash_screen_prepare(). board_splash_screen_prepare() is no longer
needed, then (the boards can provide their own implementation of
splash_screen_prepare()).
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
Es ist offensichtlich, dass das menschliche Gehirn wie ein Computer
funktioniert. Da es keine dummen Computer gibt, gibt es also auch
keine dummen Menschen. Nur ein paar Leute, die unter DOS laufen.
-- unbekannt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Ruud, In message 15ae5a936f5e3a42a9144e66875a0a89309...@server1-derijp.clb-Benelux.lokaal you wrote: I have been testing for a while now on the i.mx28 evk, and I noticed that almost all tftp transfers take some time before they actually start. It will show a 'T' as first character, then followed by '#' chars. After enabling some debug info, it appeared that it would always start by sending an ARP request, but this ARP message does not get sent actually (monitored with Wireshark). After 5 seconds the 2nd ARP request is sent (this does get traced by Wireshark) and also responded and from that point all goes well. This is a known problem on some hardware. We usually work around this by defining CONFIG_ARP_TIMEOUT in the board config file. Try setting something like #define CONFIG_ARP_TIMEOUT200UL When tracing the code, it could see that fec_send is called for the 1st ARP request and also the return value indicates that sending should have been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is actually sent. My first guess would be that it has something to do with the TBD / DMA part. The fec_tbd_init also shows some note about a rare I'm not sure about that. It appears to depend on the PHY used on the hardware, in combination on which switch you connect the system to, and eventually a few more parameters including the phase of moon. My speculation is that in some cases the PHY may enter a low-power or idle state if not used, and drops the first packet while still waking up. drivers/net/fec_mxc.c). Could it be that there is still another issue regarding the chip that causes this? If I do a tftp transfer from linux on the same board and in the same network, it does start immediately. All I can say is that (1) this depends on the hardware and (2) if you have a combinatiuon of hardware where it happens, then it happens reliably. It would be great if you have time to investigate and find the real cause of the problem. The CONFIG_ARP_TIMEOUT workaround is a bit ugly, but works pretty well. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts. - Bertrand Russell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] ARMv7: Add HYP mode switching support
On Mon, May 06, 2013 at 03:17:44PM +0200, Andre Przywara wrote: (for GIT URL and Changelog see below) ARM CPUs with the virtualization extension have a new mode called HYP mode, which allows hypervisors to safely control and monitor guests. The current hypervisor (KVM and Xen) implementations require the kernel to be entered in that HYP mode. This patch series introduces a configuration variable CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP mode. This is done automatically during execution of the bootm command (but could also be done earlier - U-Boot runs fine in HYP mode without MMU usage). I forget the u-boot specifics here, but if you boot over networking, for example, does that eventually end up calling bootm or would Hyp mode not be entered in this case? I'm only raising this issue because it's important to minimize the hoops and efforts for booting in Hyp mode, since it's harmless to do so regardless of the linux kernel we're booting. [...] -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] sf: spansion: Add support for S25FL128S
SPANSION recommend S25FL128S supersedes S25FL129P, and the two flash
memory have the same device ID and Memory architecture. So they can
use the same config parameters.
Signed-off-by: Xie Xiaobo x@freescale.com
---
drivers/mtd/spi/spansion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 32b76e0..cfbd384 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -94,7 +94,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
.idcode2 = 0x4d01,
.pages_per_sector = 256,
.nr_sectors = 256,
- .name = S25FL129P_64K,
+ .name = S25FL129P_64K/S25FL128S_64K,
},
{
.idcode1 = 0x2019,
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
On 31/05/2013 08:56, Ruud Commandeur wrote: Hi everyone, Hi Ruud, When tracing the code, it could see that fec_send is called for the 1st ARP request and also the return value indicates that sending should have been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is actually sent. My first guess would be that it has something to do with the TBD / DMA part. The fec_tbd_init also shows some note about a rare hardware condition regarding the WRAP bit (all in drivers/net/fec_mxc.c). Could it be that there is still another issue regarding the chip that causes this? If I do a tftp transfer from linux on the same board and in the same network, it does start immediately. At first glance the problem should be with the set up of the phy. It could take longer as expected, or there are some issues with the specific PHY of the board. An issue in general code of FEC driver is not probable, because the same code runs on most of i.MXes without problems. From your report, it looks like that the link of the phy is not yet active when the fec_send is called, and then no ARP message is sent. Could you try setting #define CONFIG_ARP_TIMEOUT to some high value (when it is set, the value is often 200mS) to check if the issue disappears ? 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 v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
On 29/05/2013 16:46, Benoît Thébaudeau wrote: Hi Alison, Hi Benoit, I have just noticed that this was actually in 6/7. Why are you putting this into a separate patch? [Alison Wang] Because patch 2/7 is about VF610 CPU support, and doc/README.vf610 is also a document about VF610 SoC. Doc/README.mxc_ocotp is the document about a driver (IP OCOTP), so this driver document should be separated from CPU patch 2/7. I don't think so: It's part of what comes with the addition of the VF610 platform, so 6/7 could be merged into 2/7. But it does not really matter. It's probably also fine if you keep what you did. Stefano, any opinion? Strictly speaking, you're right. But as you mentioned, it does not really matter. Without reposting, I can myself squash 6/7 into 2/7 by merging the patchset. Best regards, Stefano -- = 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/6] ARM: add secure monitor handler to switch to non-secure state
On 05/31/2013 03:02 AM, Christoffer Dall wrote: Christoffer, thanks a lot for the thorough review. Comments inline. On Mon, May 06, 2013 at 03:17:45PM +0200, Andre Przywara wrote: A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state. Introduce a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM ARM this should not be done in SVC mode, so we have to setup a SMC handler for this. We reuse the current vector table for this and make sure that we only access the MVBAR register if the CPU supports the security extension and only if we configured the board to use it, since boards entering u-boot already in non-secure mode would crash on accessing MVBAR otherwise. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 31 --- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index e9e57e6..da48b36 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -155,6 +155,13 @@ reset: /* Set vector address in CP15 VBAR register */ ldr r0, =_start mcr p15, 0, r0, c12, c0, 0 @Set VBAR + +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r1, c0, c1, 1 @ check for security extension + andsr1, r1, #0x30 + mcrne p15, 0, r0, c12, c0, 1 @ Set secure monitor MVBAR Hmm, this smells a bit simplified to me. Support for ARMv7_VIRT should easy to integrate into u-boot even for platforms that do not boot U-boot directly into secure mode (OMAP5 GP platforms are such an example). In this case you cannot assume that you can write the secure monitor mvbar. Right, Albert kind of hinted on this already. I already fixed this in my private tree, totally removing these MVBAR writes here and instead copying the values from VBAR later just before we do the smc. Will send out a fixed version. +#endif + #endif /* the mask ROM code should have PLL and others stable */ @@ -257,6 +264,12 @@ ENTRY(c_runtime_cpu_setup) ldr r0, =_start mcr p15, 0, r0, c12, c0, 0 @Set VBAR +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r1, c0, c1, 1 @ check for security extension + andsr1, r1, #0x30 + mcrne p15, 0, r0, c12, c0, 1 @ Set secure monitor MVBAR +#endif + bx lr ENDPROC(c_runtime_cpu_setup) @@ -490,11 +503,23 @@ undefined_instruction: bad_save_user_regs bl do_undefined_instruction +/* + * software interrupt aka. secure monitor handler + * This is executed on a smc instruction, we use a smc #0 to switch + * to non-secure state + */ .align 5 software_interrupt: - get_bad_stack_swi - bad_save_user_regs - bl do_software_interrupt Why is the following block not conditional on CONFIG_ARMV7_VIRT? Again, it feels a bit funny to modify this generic mechanism to contain this code for boards that boot in NS mode but have a way to enter Hyp mode using an HVC or SMC instruction. software_interrupt is currently a panic routine. So it is not actually used by u-boot, it's just there to dump some state and eventually call reset_cpu(). So I feel that since I am now the only user of software_interrupt I don't need any special precautions and consider this routine now actually part of the HYP mode switcher. But of course I can retain the original functionality if CONFIG_ARMV7_VIRT is not defined. + mrc p15, 0, r1, c1, c1, 0 @ read SCR + bic r1, r1, #0x07f + orr r1, r1, #0x31 @ enable NS, AW, FW Are you sure you want to always route FIQ to non-secure here? Since we actually don't install any secure software and just use the secure state to do the HYP switch I don't feel like we should restrict FIQ. Since we don't use it for our own purposes, no one would be able to use it then, right? So my idea was to allow as much as possible. Don't you need to set the HCE bit? The whole register resets to 0register resets to zero. This is added later in 5/6. For reviewing purposes I split the patches up to do the non-secure switch only first. Later I add the bits to actually go to HYP mode. + + mrc p15, 0, r0, c12, c0, 0 @ save secure copy of VBAR + mcr p15, 0, r1, c1, c1, 0 @ write SCR, switch to non-sec Not quite a swith to non-sec; you're still in monitor mode. Right, _non-secure_ monitor mode. If I got this thing correctly, then secure/non-secure is a state, not a mode. Switching from secure to non-secure can only be done in monitor mode. And the state totally depends on the NS bit in SCR, so by setting this we enter non-secure world immediately. + isb + mcr p15, 0, r0, c12, c0, 0 @ write non-secure copy of VBAR I don't actually think that you
Re: [U-Boot] [PATCH 2/6] ARM: add assembly routine to switch to non-secure state
On 05/31/2013 05:04 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:46PM +0200, Andre Przywara wrote: While actually switching to non-secure state is one thing, the more important part of this process is to make sure that we still have full access to the interrupt controller (GIC). The GIC is fully aware of secure vs. non-secure state, some registers are banked, others may be configured to be accessible from secure state only. To be as generic as possible, we get the GIC memory mapped address based on the PERIPHBASE register. We check explicitly for ARM Cortex-A7 and A15 cores, assuming an A9 otherwise, as for those cores we know the offsets for the GIC CPU interface from the PERIPHBASE content. Other cores could be added as needed. With the GIC accessible, we: a) allow private interrupts to be delivered to the core (GICD_IGROUPR0 = 0x) b) enable the CPU interface (GICC_CTLR[0] = 1) c) set the priority filter to allow non-secure interrupts (GICC_PMR = 0x80) After having switched to non-secure state, we also enable the non-secure GIC CPU interface, since this register is banked. Also we allow access to all coprocessor interfaces from non-secure state by writing the appropriate bits in the NSACR register. For reasons obvious later we only use caller saved registers r0-r3. You probably want to put that in a comment in the code, and it would also be super helpful to explain the obvious part here, because most readers don't look forward in time to understand this patch... Agreed. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 47 ++ 1 file changed, 47 insertions(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index da48b36..e63e892 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -572,3 +572,50 @@ fiq: #endif /* CONFIG_USE_IRQ */ #endif /* CONFIG_SPL_BUILD */ + +#ifdef CONFIG_ARMV7_VIRT +/* Routine to initialize GIC CPU interface and switch to nonsecure state. + */ +.globl _nonsec_gic_switch +_nonsec_gic_switch: + mrc p15, 4, r2, c15, c0, 0 @ r2 = PERIPHBASE You should probably check if bits [7:0] == 0x00 here, otherwise you may end up doing some very strange stuff - if any of those bits are set you can just error out at this point, but it should be gracefully handled. Also since it's core specific, you'd probably want to check that before using it. As you found out later, I am doing this before calling this routine. But I will add a comment here to avoid confusion. + add r3, r2, #0x1000 @ GIC dist i/f offset Since this is core specific, could the offset please go in an appropriate header file? It will also eliminate the need for the comment if you just have a proper define (i.e. GIC_DIST_OFFSET ...) + mvn r1, #0 + str r1, [r3, #0x80] @ allow private interrupts Aren't you makeing an assumption about the number of available interrupts here? You should read the ITLinesNumber field from the GICD_TYPER if I'm not mistaking. This is the per core private interrupts. All bits should be implemented. From the GIC spec, chapter 4.3.4: In a multiprocessor implementation, GICD_IGROUPR0 is banked for each connected processor. This register holds the group status bits for interrupts 0-31. I also think it would be much cleaner if you again used a define for the 0x80 offset. Also, don't you need to set some enable fields on the GICD_CTLR here to enable group 1 interrupts? Since this a non-banked per-system register, I do this later in the C part. + + mrc p15, 0, r0, c0, c0, 0 @ MIDR + bfc r0, #16, #8 @ mask out variant, arch + bfc r0, #0, #4 @ and revision + movwr1, #0xc070 + movtr1, #0x4100 + cmp r0, r1 @ check for Cortex-A7 + orr r1, #0xf0 wow, nice bit fiddling. It may be quite a bit easier to read if you simply had defines for the bitmasks and real values and just did a load and placed a literal section accordingly. The sequence is necessary since we are short on registers. I agree it is a bit obfuscated, will make it more readable. + cmpne r0, r1 @ check for Cortex-A15 + movne r1, #0x100 @ GIC CPU offset for A9 So I read the ARMV7_VIRT config flag as something you can only enable on a board that actually supports the virtulization extensions, which the A9 doesn't so this should probably error out instead (or do an endless loop, or ignore the case in the code, ...). Yeah, originally I had the idea to support a non-sec switch only on non-virt capable CPUs. My first version had a separate non-sec switch command. This here is kind of a leftover of that early version. But until patch 5/6 is applied this actually
Re: [U-Boot] [PATCH 3/6] ARM: switch to non-secure state during bootm execution
On 05/31/2013 07:10 AM, Christoffer Dall wrote:
On Mon, May 06, 2013 at 03:17:47PM +0200, Andre Przywara wrote:
To actually trigger the non-secure switch we just implemented, call
the switching routine from within the bootm command implementation.
This way we automatically enable this feature without further user
intervention.
Some part of the work is done in the assembly routine in start.S,
introduced with the previous patch, but for the full glory we need
to setup the GIC distributor interface once for the whole system,
which is done in C here.
The routine is placed in arch/arm/lib to allow easy access from
different boards or CPUs.
I'm beginning to loose track of exactly which parts is in assembly and
which parts are in C, and why. We are fiddling with some gic dist.
settings in assembly, and some of them in C as well.
I fear I dropped the explanation some time during a patch split earlier.
So the assembly code is the per core part - including GICD_IGROUPR0,
which is banked per core. The reason this is in assembly is to make it
easily run right out of the SMP pen.
In C I do anything that needs to be only done once for the whole system.
More comments inline...
I think it's just the ordering or naming of the patches that is a little
confusing.
First we check for the availability of the security extensions.
The generic timer base frequency register is only accessible from
secure state, so we have to program it now. Actually this should be
done from primary firmware before, but some boards seems to omit
this, so if needed we do this here with a board specific value.
Since we need a safe way to access the GIC, we use the PERIPHBASE
registers on Cortex-A15 and A7 CPUs and do some sanity checks.
Then we actually do the GIC enablement:
a) enable the GIC distributor, both for non-secure and secure state
(GICD_CTLR[1:0] = 11b)
b) allow all interrupts to be handled from non-secure state
(GICD_IGROUPRn = 0x)
The core specific GIC setup is then done in the assembly routine.
The actual bootm trigger is pretty small: calling the routine and
doing some error reporting. A return value of 1 will be added later.
To enable the whole code we introduce the CONFIG_ARMV7_VIRT variable.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
arch/arm/include/asm/armv7.h | 7 +++
arch/arm/lib/Makefile| 2 +
arch/arm/lib/bootm.c | 20
arch/arm/lib/virt-v7.c | 113 +++
4 files changed, 142 insertions(+)
create mode 100644 arch/arm/lib/virt-v7.c
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a73630b..25afffe 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -74,4 +74,11 @@ void v7_outer_cache_inval_all(void);
void v7_outer_cache_flush_range(u32 start, u32 end);
void v7_outer_cache_inval_range(u32 start, u32 end);
+#ifdef CONFIG_ARMV7_VIRT
+int armv7_switch_nonsec(void);
+
+/* defined in cpu/armv7/start.S */
+void _nonsec_gic_switch(void);
+#endif /* CONFIG_ARMV7_VIRT */
+
#endif
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 6ae161a..37a0e71 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -58,6 +58,8 @@ COBJS-y += reset.o
COBJS-y += cache.o
COBJS-y += cache-cp15.o
+COBJS-$(CONFIG_ARMV7_VIRT) += virt-v7.o
+
SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
$(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index f3b30c5..a3d3aae 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -35,6 +35,10 @@
#include asm/bootm.h
#include linux/compiler.h
+#ifdef CONFIG_ARMV7_VIRT
+#include asm/armv7.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_SETUP_MEMORY_TAGS) || \
@@ -319,6 +323,22 @@ static void boot_prep_linux(bootm_headers_t *images)
hang();
#endif /* all tags */
}
+#ifdef CONFIG_ARMV7_VIRT
+ switch (armv7_switch_nonsec()) {
+ case 0:
+ debug(entered non-secure state\n);
+ break;
+ case 2:
+ printf(HYP mode: Security extensions not implemented.\n);
+ break;
+ case 3:
+ printf(HYP mode: CPU not supported (must be Cortex-A15 or
A7).\n);
I would drop the specifics of what's supported here.
This is in particular here since I rely on the PERIPHBASE register,
which is A15/A7 implementation specific. This is different from case 2
(which will later be changed to Virtualization extensions...)
+ break;
+ case 4:
+ printf(HYP mode: PERIPHBASE is above 4 GB, cannot access
this.\n);
+ break;
+ }
I think these hard-coded numbers are a bit ugly, either define an enum
or some defines somewhere, or just make the armv7_switch_nonsec return a
boolean value and put the prints in there.
Re: [U-Boot] [PATCH 4/6] ARM: add SMP support for non-secure switch
On 05/31/2013 07:32 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:48PM +0200, Andre Przywara wrote: Currently the non-secure switch is only done for the boot processor. To later allow full SMP support, we have to switch all secondary cores into non-secure state also. So we add an entry point for secondary CPUs coming out of low-power state and make sure we put them into WFI again after having switched to non-secure state. For this we acknowledge and EOI the wake-up IPI, then go into WFI. Once being kicked out of it later, we sanity check that the start address has actually been changed (since another attempt to switch to non-secure would block the core) and jump to the new address. The actual CPU kick is done by sending an inter-processor interrupt via the GIC to all CPU interfaces except the requesting processor. The secondary cores will then setup their respective GIC CPU interface. The address secondary cores jump to is board specific, we provide the value here for the Versatile Express board. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 27 ++- arch/arm/include/asm/armv7.h| 1 + arch/arm/lib/virt-v7.c | 9 - include/configs/vexpress_ca15_tc2.h | 1 + 4 files changed, 36 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index e63e892..02234c7 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -575,8 +575,19 @@ fiq: #ifdef CONFIG_ARMV7_VIRT /* Routine to initialize GIC CPU interface and switch to nonsecure state. + * Will be executed directly by secondary CPUs after coming out of + * WFI, or can be called directly by C code for CPU 0. + * Those two paths mandate to not use any stack and to only use registers + * r0-r3 to comply with both the C ABI and the requirement of SMP startup + * code. */ .globl _nonsec_gic_switch +.globl _smp_pen +_smp_pen: + mrs r0, cpsr + orr r0, r0, #0xc0 + msr cpsr, r0@ disable interrupts + mov lr, #0 @ clear LR to mark secondary instead of this subtle abuse of lr, why not make this routine simply take a parameter? How would this work if this is called out of SMP pen? Shall I rely on the registers being zero, then? Not very stable, I guess. I think this whole routine is special anyways, so I felt this subtle abuse is OK. An option would be to set r0 to 1 in the smp_pen path and pass 0 as the first parameter when calling from C. But then I'd need to save this value - possibly in the LR register ;-) I also slightly object against wrapping the _smp_pen around the _nonsec_gic_switch, I really think these are separate routines, where one can just call the other...? The actual routine and the purpose are the same, just the entry and exit code is different. So this fitted nicely in here. I can add a more specific comment on the different entry points. _nonsec_gic_switch: mrc p15, 4, r2, c15, c0, 0 @ r2 = PERIPHBASE add r3, r2, #0x1000 @ GIC dist i/f offset @@ -617,5 +628,19 @@ _nonsec_gic_switch: add r2, r2, #0x1000 @ GIC dist i/f offset str r1, [r2]@ allow private interrupts - mov pc, lr + cmp lr, #0 + movne pc, lr @ CPU 0 to return + @ all others: go to sleep +_ack_int: + ldr r1, [r3, #0x0c] @ read GICD acknowledge + str r1, [r3, #0x10] @ write GICD EOI + + adr r1, _smp_pen +waitloop: + wfi + ldr r0, =CONFIG_SYSFLAGS_ADDR @ load start address + ldr r0, [r0] + cmp r0, r1 @ make sure we dont execute this code I think I raised this issue previously, but this code is in a core u-boot file, but I could imagine a board with a different crazy boot protocol that required you to check two different fields and jump through other hoops to wake up from the smp pen, so I really think the whole smp pen belongs in a board specific place. Right, but I didn't want to do this prematurely without knowing what is really needed. So my plan is to refactor this when adding Arndale support. I think this is special anyways because of the SPL/non-SPL split. And although you are right about it being a core u-boot file, this whole code is protected by CONFIG_ARMV7_VIRT. For non-compliant boards one would either not enable this or add support for it. Also, the boot-wrapper code used wfe instead, not sure if there are any users that just send an event and doesn't send an IPI? Good point. Is WFE a complete superset of WFI? Then I could just change this. + beq waitloop@ again (due to a spurious wakeup) + mov
Re: [U-Boot] [PATCH 5/6] ARM: extend non-secure switch to also go into HYP mode
On 05/31/2013 07:43 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:49PM +0200, Andre Przywara wrote: For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in the exception vector table. In the assembly switching routine - which we rename to hyp_gic_switch on the way - we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only adds and adjusts some error reporting. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 34 +++--- arch/arm/include/asm/armv7.h | 4 ++-- arch/arm/lib/bootm.c | 12 +--- arch/arm/lib/virt-v7.c | 22 +++--- 4 files changed, 49 insertions(+), 23 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 02234c7..921e9d9 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -41,7 +41,7 @@ _start: b reset ldr pc, _software_interrupt ldr pc, _prefetch_abort ldr pc, _data_abort - ldr pc, _not_used + ldr pc, _hyp_trap ldr pc, _irq ldr pc, _fiq #ifdef CONFIG_SPL_BUILD @@ -49,7 +49,7 @@ _undefined_instruction: .word _undefined_instruction _software_interrupt: .word _software_interrupt _prefetch_abort: .word _prefetch_abort _data_abort: .word _data_abort -_not_used: .word _not_used +_hyp_trap: .word _hyp_trap _irq: .word _irq _fiq: .word _fiq _pad: .word 0x12345678 /* now 16*4=64 */ @@ -58,7 +58,7 @@ _undefined_instruction: .word undefined_instruction _software_interrupt: .word software_interrupt _prefetch_abort: .word prefetch_abort _data_abort: .word data_abort -_not_used: .word not_used +_hyp_trap: .word hyp_trap _irq: .word irq _fiq: .word fiq _pad: .word 0x12345678 /* now 16*4=64 */ @@ -513,12 +513,18 @@ software_interrupt: mrc p15, 0, r1, c1, c1, 0 @ read SCR bic r1, r1, #0x07f orr r1, r1, #0x31 @ enable NS, AW, FW + mrc p15, 0, r0, c0, c1, 1 @ check for Virt ext + and r0, r0, #0xf000 + cmp r0, #0x1000 you can just do ands r0, r0 ,#0xf000 and change the orreq below to orrne Can I? But I want to make sure that Virt ext is of version 1 only, anything beyond that I cannot reliably support, right? Or is there a guarantee that this is backwards compatible? + orreq r1, r1, #0x100 @ allow HVC instruction mrc p15, 0, r0, c12, c0, 0 @ save secure copy of VBAR mcr p15, 0, r1, c1, c1, 0 @ write SCR, switch to non-sec isb mcr p15, 0, r0, c12, c0, 0 @ write non-secure copy of VBAR + mcreq p15, 4, r0, c12, c0, 0 @ write HYP mode HVBAR + nit: s/HYP mode// movspc, lr .align 5 @@ -534,10 +540,9 @@ data_abort: bl do_data_abort .align 5 -not_used: - get_bad_stack - bad_save_user_regs - bl do_not_used +hyp_trap: + .byte 0x00, 0xe3, 0x0e, 0xe1@ mrs lr, elr_hyp do we really need to support this on assemblers that old? What do you mean with old? I can check again, but I think it didn't work with my self-compiled binutils 2.23. Or do I need a directive to enable this? + mov pc, lr #ifdef CONFIG_USE_IRQ @@ -574,21 +579,21 @@ fiq: #endif /* CONFIG_SPL_BUILD */ #ifdef CONFIG_ARMV7_VIRT -/* Routine to initialize GIC CPU interface and switch to nonsecure state. - * Will be executed directly by secondary CPUs after coming out of +/* Routine to initialize GIC CPU interface, switch to nonsecure and to HYP + * mode. Will be executed directly by secondary CPUs after coming out of So now this routine does three different things in different context at once, why? Not three. At most two. But actually it does only one thing: switch a single core to HYP mode. Only the entry and exit points are different. I just see that I could make the smp_pen a separate function, calling the switch function. This would also solve this LR abuse thing. Will try this. * WFI, or can be called
Re: [U-Boot] [RFC PATCH 5/7] Adjust Kconfig scripts for use by U-Boot
Hi, Tom.
We would probably want to change it to something like:
- Do you want the standard baud rate table?
Yes: 9600/19200/38400/57600/115200
No: Prompt for string value of comma sep list of rates
And in the right header:
#ifdef CONFIG_SYS_STD_BAUD_RATE
#define BAUDRATTE_TABLE { 9600, }
#else
#define BAUDRATE_TABLE { CONFIG_SYS_PROMPTED_VALUE }
#endif
Could you explain a little further?
According to Documentation/kbuild/kconfig-languate.txt,
Kconfig treats bool/tristate/string/hex/int types.
Which type can we use for CONFIG_SYS_PROMPTED_VALUE?
Kconfig allows one value for hex and int type,
so we can't use them.
For a test, I wrote Kconfig using string type as follows:
config SYS_STD_BAUD_RATE
bool Do you want the standard baud rate table?
config SYS_PROMPTED_VALUE
string Input comma sep list of baud rates
depends on !SYS_STD_BAUD_RATE
I got .config as follows:
# CONFIG_SYS_STD_BAUD_RATE is not set
CONFIG_SYS_PROMPTED_VALUE=19200,38400,115200
And I got include/generated/autoconf.h as follows:
#define CONFIG_SYS_PROMPTED_VALUE 19200,38400,115200
So, my question is how to create
a comma sep value list 19200,38400,115200
from a string 19200,38400,115200.
I am afraid
#define BAUDRATE_TABLE { CONFIG_SYS_PROMPTED_VALUE }
does not work.
I did not think of any good idea to treat this with
preprocessor.
Only idea I was stuck for was to parse the string
at runtime.
#define CONFIG_SYS_BAUDRATE_TABLE 19200,38400,115200
#define MAX_BAUD_RATE_TABLE 16
int baudrate_table[MAX_BAUD_RATE_TABLE];
int string2array(int *, const char *);
string2array(baudrate_table, CONFIG_SYS_BUADRATE_TABLE);
Any other ideas?
And also, some config files still include macros without CONFIG_ prefix.
For example, LINUX_BOOT_PARAM_ADDR, PHYS_SDRAM_1, PHYS_SDRAM_2, etc.
These don't belong in the config file, and need to be either in the
board or asm/arch/ or similar construct instead.
I see.
Actually, some include/configs/*.h files still include them,
so we need to move them to somewhere else, or add prefix
like CONFIG_LINUX_BOOT_PARAM_ADDR.
Best Regards,
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Stefano, Wolfgang, Thanks for your comments. The CONFIG_ARP_TIMEOUT was not set, so it will take the default of 5 seconds. This is also the time it takes for the first timeout. If I add a #define CONFIG_ARP_TIMEOUT200UL to my board config, I see the ARP request succeed after 2 to 4 attempts. I always see only one ARP request in Wireshark. Apparently it takes 200 - 600 msecs for the phy to wake up and respond (as Wolfgang assumes as possible and very plausible cause). Increasing the ARP_TIMEOUT to some high value like 15000UL has no use, the 5 seonds tftp timeout comes in earier and a new ARP request is sent (which is answered as before). So adding this timeout define will speed things up, and I guess I should either also increase the CONFIG_NET_RETRY_COUNT or set the ARP_TIMEOUT to 400 to prevent exceeding the retry count. But of course it would be nicer to fix the actual cause. I could try and find a way to keep the phy alive or at least try to proof that it is the phy (the LAN8720A) that causes this. To be continued... Regards, Ruud -Oorspronkelijk bericht- Van: Stefano Babic [mailto:sba...@denx.de] Verzonden: vrijdag 31 mei 2013 10:50 Aan: Ruud Commandeur CC: U-Boot list; sba...@denx.de Onderwerp: Re: TFTP timeouts, i.mx fec problem? On 31/05/2013 08:56, Ruud Commandeur wrote: Hi everyone, Hi Ruud, When tracing the code, it could see that fec_send is called for the 1st ARP request and also the return value indicates that sending should have been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is actually sent. My first guess would be that it has something to do with the TBD / DMA part. The fec_tbd_init also shows some note about a rare hardware condition regarding the WRAP bit (all in drivers/net/fec_mxc.c). Could it be that there is still another issue regarding the chip that causes this? If I do a tftp transfer from linux on the same board and in the same network, it does start immediately. At first glance the problem should be with the set up of the phy. It could take longer as expected, or there are some issues with the specific PHY of the board. An issue in general code of FEC driver is not probable, because the same code runs on most of i.MXes without problems. From your report, it looks like that the link of the phy is not yet active when the fec_send is called, and then no ARP message is sent. Could you try setting #define CONFIG_ARP_TIMEOUT to some high value (when it is set, the value is often 200mS) to check if the issue disappears ? 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 v3] OMAP: I2C: New read, write and probe functions
Hi Tom, On 30/05/13 20:07, Tom Rini wrote: On Thu, May 30, 2013 at 10:37:42AM -0400, Tom Rini wrote: On Thu, May 30, 2013 at 01:24:42AM +0300, Lubomir Popov wrote: Tested on OMAP4/5 only, but should work on older OMAPs and derivatives as well. - Rewritten i2c_read to operate correctly with all types of chips (old function could not read consistent data from some I2C slaves). - Optimised i2c_write. - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE, performs write access vs read. The old probe could hang the system under certain conditions (e.g. unconfigured pads). - The read/write/probe functions try to identify unconfigured bus. - Status functions now read irqstatus_raw as per TRM guidelines (except for OMAP243X and OMAP34XX). - Driver now supports up to I2C5 (OMAP5). Signed-off-by: Lubomir Popov lpo...@mm-sol.com With CONFIG_I2C_PROBE_WRITE set: Tested-by: Tom Rini tr...@ti.com on Beagleboard / Beagleboard xM But, crap, breaks am335x_evm (and probably beaglebones, etc). I'll dig into this more to see if I can spot something obvious tomorrow. Made it work on the am335x_evm (tested, with AM3359 on board). Problem was in the new i2c_probe, which on this board is called by the SPL and caused a hang (interestingly, when called from regular u-boot, works fine). Fix is to add a small delay. Clocking and I2C speed should be identical between SPL and U-Boot, but probably are not; I did not have time to look with a scope, but don't have any other reasonable explanation. Whatever, now it is working. I shall submit the patch tonight. Would like as well to note that the current u-boot-ti/master (freshly cloned, no changes whatsoever) does not boot on the am335x-evm: U-Boot SPL 2013.04-11562-g47c6ea0 (May 31 2013 - 09:56:46) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 ### ERROR ### Please RESET the board ### -- Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
Hi Tom, [snip] But, crap, breaks am335x_evm (and probably beaglebones, etc). I'll dig into this more to see if I can spot something obvious tomorrow. Made it work on the am335x_evm (tested, with AM3359 on board). Problem was in the new i2c_probe, which on this board is called by the SPL and caused a hang (interestingly, when called from regular u-boot, works fine). Fix is to add a small delay. Clocking and I2C speed should be identical between SPL and U-Boot, but probably are not; I did not have time to look with a scope, but don't have any other reasonable explanation. Whatever, now it is working. I shall submit the patch tonight. [snip] Just tested on Beaglebone, works fine as well. -- Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
When compressed image is loaded, it must be decompressed
to an aligned address + 2 to avoid unaligned access exception
on some ARM platforms.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Anatolij Gustschin ag...@denx.de
CC: Wolfgang Denk: w...@denx.de
---
common/cmd_bmp.c | 40 +++-
include/lcd.h|3 ++-
2 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c
index 5a52edd..fea4708 100644
--- a/common/cmd_bmp.c
+++ b/common/cmd_bmp.c
@@ -38,14 +38,19 @@ static int bmp_info (ulong addr);
/*
* Allocate and decompress a BMP image using gunzip().
*
- * Returns a pointer to the decompressed image data. Must be freed by
- * the caller after use.
+ * Returns a pointer to the decompressed image data. This pointer is
+ * is aligned to 32-bit-aligned-address + 2.
+ * See doc/README.displaying-bmps for explanation.
+ *
+ * The allocation address is passed to 'alloc_addr' and must be freed
+ * by the caller after use.
*
* Returns NULL if decompression failed, or if the decompressed data
* didn't contain a valid BMP signature.
*/
#ifdef CONFIG_VIDEO_BMP_GZIP
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+ void **alloc_addr)
{
void *dst;
unsigned long len;
@@ -60,7 +65,14 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
puts(Error: malloc in gunzip failed!\n);
return NULL;
}
- if (gunzip(dst, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) !=
0) {
+
+ bmp = dst;
+
+ /* align to 32-bit-aligned-address + 2 */
+ if ((unsigned int)bmp % 0x04 != 0x02)
+ bmp = (bmp_image_t *)(((unsigned int)dst + 0x02) ~0x01);
+
+ if (gunzip(bmp, CONFIG_SYS_VIDEO_LOGO_MAX_SIZE, (uchar *)addr, len) !=
0) {
free(dst);
return NULL;
}
@@ -68,8 +80,6 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
puts(Image could be truncated
(increase
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE)!\n);
- bmp = dst;
-
/*
* Check for bmp mark 'BM'
*/
@@ -81,10 +91,12 @@ bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long
*lenp)
debug(Gzipped BMP image detected!\n);
+ *alloc_addr = dst;
return bmp;
}
#else
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+ void **alloc_addr)
{
return NULL;
}
@@ -189,11 +201,12 @@ U_BOOT_CMD(
static int bmp_info(ulong addr)
{
bmp_image_t *bmp=(bmp_image_t *)addr;
+ void *bmp_alloc_addr = NULL;
unsigned long len;
if (!((bmp-header.signature[0]=='B')
(bmp-header.signature[1]=='M')))
- bmp = gunzip_bmp(addr, len);
+ bmp = gunzip_bmp(addr, len, bmp_alloc_addr);
if (bmp == NULL) {
printf(There is no valid bmp file at the given address\n);
@@ -205,8 +218,8 @@ static int bmp_info(ulong addr)
printf(Bits per pixel: %d\n, le16_to_cpu(bmp-header.bit_count));
printf(Compression : %d\n, le32_to_cpu(bmp-header.compression));
- if ((unsigned long)bmp != addr)
- free(bmp);
+ if (bmp_alloc_addr)
+ free(bmp_alloc_addr);
return(0);
}
@@ -225,11 +238,12 @@ int bmp_display(ulong addr, int x, int y)
{
int ret;
bmp_image_t *bmp = (bmp_image_t *)addr;
+ void *bmp_alloc_addr = NULL;
unsigned long len;
if (!((bmp-header.signature[0]=='B')
(bmp-header.signature[1]=='M')))
- bmp = gunzip_bmp(addr, len);
+ bmp = gunzip_bmp(addr, len, bmp_alloc_addr);
if (!bmp) {
printf(There is no valid bmp file at the given address\n);
@@ -244,8 +258,8 @@ int bmp_display(ulong addr, int x, int y)
# error bmp_display() requires CONFIG_LCD or CONFIG_VIDEO
#endif
- if ((unsigned long)bmp != addr)
- free(bmp);
+ if (bmp_alloc_addr)
+ free(bmp_alloc_addr);
return ret;
}
diff --git a/include/lcd.h b/include/lcd.h
index c6e7fc5..482e606 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -46,7 +46,8 @@ void lcd_initcolregs(void);
int lcd_getfgcolor(void);
/* gunzip_bmp used if CONFIG_VIDEO_BMP_GZIP */
-struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp);
+struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+void **alloc_addr);
int bmp_display(ulong addr, int x, int y);
/**
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [RFC PATCH 5/7] Adjust Kconfig scripts for use by U-Boot
On Fri, May 31, 2013 at 07:01:01PM +0900, Masahiro Yamada wrote:
Hi, Tom.
We would probably want to change it to something like:
- Do you want the standard baud rate table?
Yes: 9600/19200/38400/57600/115200
No: Prompt for string value of comma sep list of rates
And in the right header:
#ifdef CONFIG_SYS_STD_BAUD_RATE
#define BAUDRATTE_TABLE { 9600, }
#else
#define BAUDRATE_TABLE { CONFIG_SYS_PROMPTED_VALUE }
#endif
Could you explain a little further?
According to Documentation/kbuild/kconfig-languate.txt,
Kconfig treats bool/tristate/string/hex/int types.
Which type can we use for CONFIG_SYS_PROMPTED_VALUE?
[snip]
And I got include/generated/autoconf.h as follows:
#define CONFIG_SYS_PROMPTED_VALUE 19200,38400,115200
Ah, damn. I was thinking string, but that won't work as you've shown
(thanks!). Perhaps the best answer is we can do a choice of std table,
full table, 115200, 230400, 9600 and any other single values people
really need.
And also, some config files still include macros without CONFIG_ prefix.
For example, LINUX_BOOT_PARAM_ADDR, PHYS_SDRAM_1, PHYS_SDRAM_2, etc.
These don't belong in the config file, and need to be either in the
board or asm/arch/ or similar construct instead.
I see.
Actually, some include/configs/*.h files still include them,
so we need to move them to somewhere else, or add prefix
like CONFIG_LINUX_BOOT_PARAM_ADDR.
There's certainly some header cleanup that needs to happen before a full
transition can happen. In TI-land there's lots of dependencies on
headers being in the config, only a few of which are needed, and require
real thought (things like CONFIG_SYS_SDRAM_BASE,
CONFIG_SYS_INIT_SP_ADDR).
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 15/16] sf: Remove spi_flash_cmd_poll_bit()
There is no other call other than spi_flash_cmd_wait_ready(),
hence removed spi_flash_cmd_poll_bit and use the poll status code
spi_flash_cmd_wait_ready() itself.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 11 +++
drivers/mtd/spi/spi_flash_internal.h | 4
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 765d4bc..527423d 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -190,12 +190,13 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32
offset,
return ret;
}
-int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
- u8 cmd, u8 poll_bit)
+int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
{
unsigned long timebase;
int ret;
u8 status;
+ u8 poll_bit = STATUS_WIP;
+ u8 cmd = CMD_READ_STATUS;
timebase = get_timer(0);
do {
@@ -220,12 +221,6 @@ int spi_flash_cmd_poll_bit(struct spi_flash *flash,
unsigned long timeout,
return -1;
}
-int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
-{
- return spi_flash_cmd_poll_bit(flash, timeout,
- CMD_READ_STATUS, STATUS_WIP);
-}
-
int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len)
{
u32 erase_size;
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 455dc02..ac4530f 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -98,10 +98,6 @@ int spi_flash_cmd_bankaddr_read(struct spi_flash *flash,
void *data);
int spi_flash_read_common(struct spi_flash *flash, const u8 *cmd,
size_t cmd_len, void *data, size_t data_len);
-/* Send a command to the device and wait for some bit to clear itself. */
-int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
- u8 cmd, u8 poll_bit);
-
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 12/16] sf: stmicro: Add support for N25Q1024A
Add support for Numonyx N25Q1024A SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/stmicro.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index cac1013..ef4b911 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -158,6 +158,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 2048,
.name = N25Q1024,
},
+ {
+ .id = 0xbb21,
+ .pages_per_sector = 256,
+ .nr_sectors = 2048,
+ .name = N25Q1024A,
+ },
};
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 11/16] sf: stmicro: Add support for N25Q1024
Add support for Numonyx N25Q1024 SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/stmicro.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index bf61a37..cac1013 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -152,6 +152,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 1024,
.name = N25Q512A,
},
+ {
+ .id = 0xba21,
+ .pages_per_sector = 256,
+ .nr_sectors = 2048,
+ .name = N25Q1024,
+ },
};
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 10/16] sf: stmicro: Add support for N25Q512A
Add support for Numonyx N25Q512A SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/stmicro.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index e9adfa5..bf61a37 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -146,6 +146,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 1024,
.name = N25Q512,
},
+ {
+ .id = 0xbb20,
+ .pages_per_sector = 256,
+ .nr_sectors = 1024,
+ .name = N25Q512A,
+ },
};
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 13/16] sf: spansion: Add support for S25FL512S_256K
Add support for Spansion S25FL512S_256K SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spansion.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index dad4fbb..1ded39f 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -110,6 +110,13 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
.nr_sectors = 512,
.name = S25FL256S_64K,
},
+ {
+ .idcode1 = 0x0220,
+ .idcode2 = 0x4d00,
+ .pages_per_sector = 256,
+ .nr_sectors = 1024,
+ .name = S25FL512S_256K,
+ },
};
struct spi_flash *spi_flash_probe_spansion(struct spi_slave *spi, u8 *idcode)
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/16] sf: Add bank address register reading support
This patch provides support to read a flash bank address register.
reading extended/bank address register will give whether the flash
is operated on extended/bank addressing or normal addressing in
3-byte address mode.
Currently added an extended/bank address register reading support
for spansion flashes.
reff' the spec for more details about bank addr register
in Page-63, Table 8.16
http://www.spansion.com/Support/Datasheets/S25FL128S_256S_00.pdf
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 15 +++
drivers/mtd/spi/spi_flash_internal.h | 4
2 files changed, 19 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 7aba520..193de42 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -312,6 +312,21 @@ int spi_flash_cmd_bankaddr_write(struct spi_flash *flash,
u8 bank_sel)
return 0;
}
+int spi_flash_cmd_bankaddr_read(struct spi_flash *flash, void *data)
+{
+ u8 cmd;
+ u8 idcode0 = flash-idcode0;
+
+ if (idcode0 == 0x01) {
+ cmd = CMD_BANKADDR_BRRD;
+ } else {
+ printf(SF: Unsupported bank addr read %02x\n, idcode0);
+ return -1;
+ }
+
+ return spi_flash_read_common(flash, cmd, 1, data, 1);
+}
+
#ifdef CONFIG_OF_CONTROL
int spi_flash_decode_fdt(const void *blob, struct spi_flash *flash)
{
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 6e38494..2567bbc 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -30,6 +30,7 @@
/* Bank addr acess commands */
#define CMD_BANKADDR_BRWR 0x17
+#define CMD_BANKADDR_BRRD 0x16
/* Common status */
#define STATUS_WIP 0x01
@@ -83,6 +84,9 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8
sr);
/* Program the bank address register */
int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel);
+/* Read the bank address register */
+int spi_flash_cmd_bankaddr_read(struct spi_flash *flash, void *data);
+
/*
* Same as spi_flash_cmd_read() except it also claims/releases the SPI
* bus. Used as common part of the -read() operation.
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 05/16] sf: read flash bank addr register at probe time
Read the flash bank addr register to get the state of bank in
a perticular flash. and also bank write happens only when there is
a change in bank selection from user.
bank read only valid for flashes which has 16Mbytes those are
opearted in 3-byte addr mode, each bank occupies 16Mytes.
Suppose if the flash has 64Mbytes size consists of 4 banks like
bank0, bank1, bank2 and bank3.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 17 +
drivers/mtd/spi/spi_flash_internal.h | 2 ++
include/spi_flash.h | 2 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 66b6b14..4576a16 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -283,6 +283,11 @@ int spi_flash_cmd_bankaddr_write(struct spi_flash *flash,
u8 bank_sel)
u8 cmd, idcode0;
int ret;
+ if (flash-bank_curr == bank_sel) {
+ debug(SF: not require to enable bank%d\n, bank_sel);
+ return 0;
+ }
+
idcode0 = flash-idcode0;
if (idcode0 == 0x01) {
cmd = CMD_BANKADDR_BRWR;
@@ -304,6 +309,7 @@ int spi_flash_cmd_bankaddr_write(struct spi_flash *flash,
u8 bank_sel)
debug(SF: fail to write bank addr register\n);
return ret;
}
+ flash-bank_curr = bank_sel;
ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
if (ret 0) {
@@ -432,6 +438,7 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
struct spi_flash *flash = NULL;
int ret, i, shift;
u8 idcode[IDCODE_LEN], *idp;
+ u8 curr_bank = 0;
spi = spi_setup_slave(bus, cs, max_hz, spi_mode);
if (!spi) {
@@ -491,6 +498,16 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
printf(, mapped at %p, flash-memory_map);
puts(\n);
+ if (flash-size SPI_FLASH_16MB_BOUN) {
+ if (spi_flash_cmd_bankaddr_read(flash, curr_bank)) {
+ debug(SF: fail to read bank addr register\n);
+ goto err_manufacturer_probe;
+ }
+ flash-bank_curr = curr_bank;
+ } else {
+ flash-bank_curr = curr_bank;
+ }
+
spi_release_bus(spi);
return flash;
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 1b29e2d..455dc02 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -12,6 +12,8 @@
#define SPI_FLASH_PAGE_ERASE_TIMEOUT (5 * CONFIG_SYS_HZ)
#define SPI_FLASH_SECTOR_ERASE_TIMEOUT (10 * CONFIG_SYS_HZ)
+#define SPI_FLASH_16MB_BOUN0x100
+
/* Common commands */
#define CMD_READ_ID0x9f
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 5ea42e1..acac17a 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -40,6 +40,8 @@ struct spi_flash {
u32 sector_size;
/* ID code0 */
u8 idcode0;
+ /* Current flash bank */
+ u8 bank_curr;
void *memory_map; /* Address of read-only SPI flash access */
int (*read)(struct spi_flash *flash, u32 offset,
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 14/16] sf: Use spi_flash_read_common() in write status poll
Instead of using spi_xfer for SPI_XFER_BEGIN and SPI_XFER_END
separatley use common read call spi_flash_read_common() which
does the same.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 821aa2e..765d4bc 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -193,32 +193,25 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32
offset,
int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
u8 cmd, u8 poll_bit)
{
- struct spi_slave *spi = flash-spi;
unsigned long timebase;
int ret;
u8 status;
- ret = spi_xfer(spi, 8, cmd, NULL, SPI_XFER_BEGIN);
- if (ret) {
- debug(SF: Failed to send command %02x: %d\n, cmd, ret);
- return ret;
- }
-
timebase = get_timer(0);
do {
WATCHDOG_RESET();
- ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
- return -1;
+ ret = spi_flash_read_common(flash, cmd, 1, status, 1);
+ if (ret 0) {
+ debug(SF: fail to read read status register\n);
+ return ret;
+ }
if ((status poll_bit) == 0)
break;
} while (get_timer(timebase) timeout);
- spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
-
if ((status poll_bit) == 0)
return 0;
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 06/16] sf: Update sf to support all sizes of flashes
Updated the spi_flash framework to handle all sizes of flashes
using bank/extd addr reg facility
The current implementation in spi_flash supports 3-byte address mode
due to this up to 16Mbytes amount of flash is able to access for those
flashes which has an actual size of 16MB.
As most of the flashes introduces a bank/extd address registers
for accessing the flashes in 16Mbytes of banks if the flash size
is 16Mbytes, this new scheme will add the bank selection feature
for performing write/erase operations on all flashes.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 4576a16..5386884 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -74,11 +74,9 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
unsigned long page_addr, byte_addr, page_size;
size_t chunk_len, actual;
int ret;
- u8 cmd[4];
+ u8 cmd[4], bank_sel;
page_size = flash-page_size;
- page_addr = offset / page_size;
- byte_addr = offset % page_size;
ret = spi_claim_bus(flash-spi);
if (ret) {
@@ -88,6 +86,16 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
cmd[0] = CMD_PAGE_PROGRAM;
for (actual = 0; actual len; actual += chunk_len) {
+ bank_sel = offset / SPI_FLASH_16MB_BOUN;
+
+ ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
+ if (ret) {
+ debug(SF: fail to set bank%d\n, bank_sel);
+ return ret;
+ }
+
+ page_addr = offset / page_size;
+ byte_addr = offset % page_size;
chunk_len = min(len - actual, page_size - byte_addr);
if (flash-spi-max_write_size)
@@ -117,11 +125,7 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
if (ret)
break;
- byte_addr += chunk_len;
- if (byte_addr == page_size) {
- page_addr++;
- byte_addr = 0;
- }
+ offset += chunk_len;
}
spi_release_bus(flash-spi);
@@ -204,9 +208,9 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len)
{
- u32 end, erase_size;
+ u32 erase_size;
int ret;
- u8 cmd[4];
+ u8 cmd[4], bank_sel;
erase_size = flash-sector_size;
if (offset % erase_size || len % erase_size) {
@@ -224,11 +228,17 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
offset, size_t len)
cmd[0] = CMD_ERASE_4K;
else
cmd[0] = CMD_ERASE_64K;
- end = offset + len;
- while (offset end) {
+ while (len) {
+ bank_sel = offset / SPI_FLASH_16MB_BOUN;
+
+ ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
+ if (ret) {
+ debug(SF: fail to set bank%d\n, bank_sel);
+ return ret;
+ }
+
spi_flash_addr(offset, cmd);
- offset += erase_size;
debug(SF: erase %2x %2x %2x %2x (%x)\n, cmd[0], cmd[1],
cmd[2], cmd[3], offset);
@@ -244,6 +254,9 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
offset, size_t len)
ret = spi_flash_cmd_wait_ready(flash,
SPI_FLASH_PAGE_ERASE_TIMEOUT);
if (ret)
goto out;
+
+ offset += erase_size;
+ len -= erase_size;
}
out:
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/16] sf: Add extended addr read support for winbond|stmicro
This patch provides support to read a flash extended address
register for winbond and stmicro SPI flashes.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 2 ++
drivers/mtd/spi/spi_flash_internal.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 05d1792..66b6b14 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -321,6 +321,8 @@ int spi_flash_cmd_bankaddr_read(struct spi_flash *flash,
void *data)
if (idcode0 == 0x01) {
cmd = CMD_BANKADDR_BRRD;
+ } else if ((idcode0 == 0xef) || (idcode0 == 0x20)) {
+ cmd = CMD_EXTNADDR_RDEAR;
} else {
printf(SF: Unsupported bank addr read %02x\n, idcode0);
return -1;
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index de1a0df..1b29e2d 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -32,6 +32,7 @@
#define CMD_BANKADDR_BRWR 0x17
#define CMD_BANKADDR_BRRD 0x16
#define CMD_EXTNADDR_WREAR 0xC5
+#define CMD_EXTNADDR_RDEAR 0xC8
/* Common status */
#define STATUS_WIP 0x01
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 08/16] sf: Use spi_flash_addr() in write call
Use the existing spi_flash_addr() for 3-byte addressing
cmd filling in write call.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 40c0389..821aa2e 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -71,7 +71,7 @@ int spi_flash_cmd_write(struct spi_slave *spi, const u8 *cmd,
size_t cmd_len,
int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset,
size_t len, const void *buf)
{
- unsigned long page_addr, byte_addr, page_size;
+ unsigned long byte_addr, page_size;
size_t chunk_len, actual;
int ret;
u8 cmd[4], bank_sel;
@@ -94,16 +94,13 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
return ret;
}
- page_addr = offset / page_size;
byte_addr = offset % page_size;
chunk_len = min(len - actual, page_size - byte_addr);
if (flash-spi-max_write_size)
chunk_len = min(chunk_len, flash-spi-max_write_size);
- cmd[1] = page_addr 8;
- cmd[2] = page_addr;
- cmd[3] = byte_addr;
+ spi_flash_addr(offset, cmd);
debug(PP: 0x%p = cmd = { 0x%02x 0x%02x%02x%02x } chunk_len =
%zu\n,
buf + actual, cmd[0], cmd[1], cmd[2], cmd[3], chunk_len);
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/16] sf: Add bank address register writing support
This patch provides support to program a flash bank address
register.
extended/bank address register contains an information to access
the 4th byte addressing in 3-byte address mode.
Currently added an bank address register writing support for
spansion flashes.
reff' the spec for more details about bank addr register
in Page-63, Table 8.16
http://www.spansion.com/Support/Datasheets/S25FL128S_256S_00.pdf
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 37
drivers/mtd/spi/spi_flash_internal.h | 6 ++
include/spi_flash.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 0e38f59..7aba520 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -278,6 +278,40 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8
sr)
return 0;
}
+int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel)
+{
+ u8 cmd, idcode0;
+ int ret;
+
+ idcode0 = flash-idcode0;
+ if (idcode0 == 0x01) {
+ cmd = CMD_BANKADDR_BRWR;
+ } else {
+ printf(SF: Unsupported bank addr write %02x\n, idcode0);
+ return -1;
+ }
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write(flash-spi, cmd, 1, bank_sel, 1);
+ if (ret) {
+ debug(SF: fail to write bank addr register\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
+ if (ret 0) {
+ debug(SF: write bank addr register timed out\n);
+ return ret;
+ }
+
+ return 0;
+}
+
#ifdef CONFIG_OF_CONTROL
int spi_flash_decode_fdt(const void *blob, struct spi_flash *flash)
{
@@ -422,6 +456,9 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
goto err_manufacturer_probe;
}
+ /* store the manuf id, for performing specific flash ops */
+ flash-idcode0 = *idp;
+
#ifdef CONFIG_OF_CONTROL
if (spi_flash_decode_fdt(gd-fdt_blob, flash)) {
debug(SF: FDT decode error\n);
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..6e38494 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -28,6 +28,9 @@
#define CMD_ERASE_64K 0xd8
#define CMD_ERASE_CHIP 0xc7
+/* Bank addr acess commands */
+#define CMD_BANKADDR_BRWR 0x17
+
/* Common status */
#define STATUS_WIP 0x01
@@ -77,6 +80,9 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
/* Program the status register. */
int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);
+/* Program the bank address register */
+int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel);
+
/*
* Same as spi_flash_cmd_read() except it also claims/releases the SPI
* bus. Used as common part of the -read() operation.
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 3b6a44e..5ea42e1 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -38,6 +38,8 @@ struct spi_flash {
u32 page_size;
/* Erase (sector) size */
u32 sector_size;
+ /* ID code0 */
+ u8 idcode0;
void *memory_map; /* Address of read-only SPI flash access */
int (*read)(struct spi_flash *flash, u32 offset,
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 09/16] sf: stmicro: Add support for N25Q512
Add support for Numonyx N25Q512 SPI flash.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/stmicro.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mtd/spi/stmicro.c b/drivers/mtd/spi/stmicro.c
index 2a9972b..e9adfa5 100644
--- a/drivers/mtd/spi/stmicro.c
+++ b/drivers/mtd/spi/stmicro.c
@@ -140,6 +140,12 @@ static const struct stmicro_spi_flash_params
stmicro_spi_flash_table[] = {
.nr_sectors = 512,
.name = N25Q256A,
},
+ {
+ .id = 0xba20,
+ .pages_per_sector = 256,
+ .nr_sectors = 1024,
+ .name = N25Q512,
+ },
};
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 * idcode)
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 16/16] sf: Add Flag status register polling support
Flag status register polling is required for micron 512Mb flash
devices onwards, for performing erase/program operations.
Like polling for WIP(Write-In-Progress) bit in read status register,
spi_flash_cmd_wait_ready will poll for PEC(Program-Erase-Control)
bit in flag status register.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 15 ---
drivers/mtd/spi/spi_flash_internal.h | 3 +++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 527423d..8cd2988 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -195,25 +195,34 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
unsigned long timebase;
int ret;
u8 status;
+ u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
u8 cmd = CMD_READ_STATUS;
+ if ((flash-idcode0 == 0x20)
+ (flash-size = SPI_FLASH_512MB_STMIC)) {
+ poll_bit = STATUS_PEC;
+ check_status = poll_bit;
+ cmd = CMD_FLAG_STATUS;
+ }
+
timebase = get_timer(0);
do {
WATCHDOG_RESET();
ret = spi_flash_read_common(flash, cmd, 1, status, 1);
if (ret 0) {
- debug(SF: fail to read read status register\n);
+ debug(SF: fail to read %s status register\n,
+ cmd == CMD_READ_STATUS ? read : flag);
return ret;
}
- if ((status poll_bit) == 0)
+ if ((status poll_bit) == check_status)
break;
} while (get_timer(timebase) timeout);
- if ((status poll_bit) == 0)
+ if ((status poll_bit) == check_status)
return 0;
/* Timed out */
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index ac4530f..cb7a505 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -13,6 +13,7 @@
#define SPI_FLASH_SECTOR_ERASE_TIMEOUT (10 * CONFIG_SYS_HZ)
#define SPI_FLASH_16MB_BOUN0x100
+#define SPI_FLASH_512MB_STMIC 0x400
/* Common commands */
#define CMD_READ_ID0x9f
@@ -24,6 +25,7 @@
#define CMD_PAGE_PROGRAM 0x02
#define CMD_WRITE_DISABLE 0x04
#define CMD_READ_STATUS0x05
+#define CMD_FLAG_STATUS0x70
#define CMD_WRITE_ENABLE 0x06
#define CMD_ERASE_4K 0x20
#define CMD_ERASE_32K 0x52
@@ -38,6 +40,7 @@
/* Common status */
#define STATUS_WIP 0x01
+#define STATUS_PEC 0x80
/* Send a single-byte command to the device and read the response */
int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t len);
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 07/16] sf: Update sf read to support all sizes of flashes
This patch updated the spi_flash read func to support all
sizes of flashes using bank reg addr facility.
The same support has been added in below patch for erase/write
spi_flash functions:
sf: Support all sizes of flashes using bank addr reg facility
(sha1: c956f600cbb0943d0afe1004cdb503f4fcd8f415)
With these new updates on sf framework, the flashes which has 16MB
are not effected as per as performance is concern and but the
u-boot.bin size incrased ~600 bytes.
sf update(for first 16MBytes), Changes before:
U-Boot sf update 0x100 0x0 0x100
- N25Q256
16777216 bytes written, 0 bytes skipped in 199.72s, speed 86480 B/s
- W25Q128BV
16777216 bytes written, 0 bytes skipped in 351.739s, speed 48913 B/s
- S25FL256S_64K
16777216 bytes written, 0 bytes skipped in 65.659s, speed 262144 B/s
sf update(for first 16MBytes), Changes before:
U-Boot sf update 0x100 0x0 0x100
- N25Q256
16777216 bytes written, 0 bytes skipped in 198.953s, speed 86480 B/s
- W25Q128BV
16777216 bytes written, 0 bytes skipped in 350.90s, speed 49200 B/s
- S25FL256S_64K
16777216 bytes written, 0 bytes skipped in 66.521s, speed 262144 B/s
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 5386884..40c0389 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -148,7 +148,9 @@ int spi_flash_read_common(struct spi_flash *flash, const u8
*cmd,
int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 offset,
size_t len, void *data)
{
- u8 cmd[5];
+ u8 cmd[5], bank_sel;
+ u32 remain_len, read_len;
+ int ret = -1;
/* Handle memory-mapped SPI */
if (flash-memory_map) {
@@ -157,10 +159,38 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32
offset,
}
cmd[0] = CMD_READ_ARRAY_FAST;
- spi_flash_addr(offset, cmd);
cmd[4] = 0x00;
- return spi_flash_read_common(flash, cmd, sizeof(cmd), data, len);
+ while (len) {
+ bank_sel = offset / SPI_FLASH_16MB_BOUN;
+
+ ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
+ if (ret) {
+ debug(SF: fail to set bank%d\n, bank_sel);
+ return ret;
+ }
+
+ remain_len = (SPI_FLASH_16MB_BOUN * (bank_sel + 1) - offset);
+ if (len remain_len)
+ read_len = len;
+ else
+ read_len = remain_len;
+
+ spi_flash_addr(offset, cmd);
+
+ ret = spi_flash_read_common(flash, cmd, sizeof(cmd),
+ data, read_len);
+ if (ret 0) {
+ debug(SF: read failed\n);
+ break;
+ }
+
+ offset += read_len;
+ len -= read_len;
+ data += read_len;
+ }
+
+ return ret;
}
int spi_flash_cmd_poll_bit(struct spi_flash *flash, unsigned long timeout,
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 03/16] sf: Add extended addr write support for winbond|stmicro
This patch provides support to program a flash extended address
register for winbond and stmicro SPI flashes.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 2 ++
drivers/mtd/spi/spi_flash_internal.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 193de42..05d1792 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -286,6 +286,8 @@ int spi_flash_cmd_bankaddr_write(struct spi_flash *flash,
u8 bank_sel)
idcode0 = flash-idcode0;
if (idcode0 == 0x01) {
cmd = CMD_BANKADDR_BRWR;
+ } else if ((idcode0 == 0xef) || (idcode0 == 0x20)) {
+ cmd = CMD_EXTNADDR_WREAR;
} else {
printf(SF: Unsupported bank addr write %02x\n, idcode0);
return -1;
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 2567bbc..de1a0df 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -31,6 +31,7 @@
/* Bank addr acess commands */
#define CMD_BANKADDR_BRWR 0x17
#define CMD_BANKADDR_BRRD 0x16
+#define CMD_EXTNADDR_WREAR 0xC5
/* Common status */
#define STATUS_WIP 0x01
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 00/16] sf: Update sf framework to support all sizes of flashes
This series is v2 for the patch series sent few weeks back with a head sf: Accessing 16MBytes flashes in existing 3-byte addr mode. The current implementation in sf supports 3-byte address mode due to this up to 16MB amount of flash is able to access for those flashes which has an actual size of 16MB. This series of patches is more detailed/meatured changes w.r.t the current sf framework in addition to changes related to support all sizes using bank/exnt register addr accessing support. With these new updates on sf framework, the flashes which has 16MB are not effected as per as performance is concern and but the u-boot.bin size incrased ~600 bytes. sf update(for first 16MBytes), Changes before: U-Boot sf update 0x100 0x0 0x100 - N25Q256 16777216 bytes written, 0 bytes skipped in 199.72s, speed 86480 B/s - W25Q128BV 16777216 bytes written, 0 bytes skipped in 351.739s, speed 48913 B/s - S25FL256S_64K 16777216 bytes written, 0 bytes skipped in 65.659s, speed 262144 B/s sf update(for first 16MBytes), Changes after: U-Boot sf update 0x100 0x0 0x100 - N25Q256 16777216 bytes written, 0 bytes skipped in 198.953s, speed 86480 B/s - W25Q128BV 16777216 bytes written, 0 bytes skipped in 350.90s, speed 49200 B/s - S25FL256S_64K 16777216 bytes written, 0 bytes skipped in 66.521s, speed 262144 B/s The main aim of these changes is to not effect the current framework and at the same time to support the 16Mbyte flashes, becuase of this I involved few flash vendor people in CC [thought that they may/mayn't be a mailing list members] to know their views. REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST THESE CHANGES W.R.T YOUR HW IF POSSIBLE. Please let me know for any issues/concerns/questions. Thanks, Jagan. Jagannadha Sutradharudu Teki (16): sf: Add bank address register writing support sf: Add bank address register reading support sf: Add extended addr write support for winbond|stmicro sf: Add extended addr read support for winbond|stmicro sf: read flash bank addr register at probe time sf: Update sf to support all sizes of flashes sf: Update sf read to support all sizes of flashes sf: Use spi_flash_addr() in write call sf: stmicro: Add support for N25Q512 sf: stmicro: Add support for N25Q512A sf: stmicro: Add support for N25Q1024 sf: stmicro: Add support for N25Q1024A sf: spansion: Add support for S25FL512S_256K sf: Use spi_flash_read_common() in write status poll sf: Remove spi_flash_cmd_poll_bit() sf: Add Flag status register polling support drivers/mtd/spi/spansion.c | 7 ++ drivers/mtd/spi/spi_flash.c | 192 +++ drivers/mtd/spi/spi_flash_internal.h | 21 +++- drivers/mtd/spi/stmicro.c| 24 + include/spi_flash.h | 4 + 5 files changed, 203 insertions(+), 45 deletions(-) -- 1.8.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
No real success here yet. By using a scope I did see that at least the MAC is trying to send the 1st packet (activity on RMII TXD part). On the Phy, the clock is running, LED's are blinking, but the 1st packet doesn't come out. Although: occasionally it does. Also no clues found in the datasheet of the phy. For now, I have set the ARP Timeout to 200 msecs and the retries to 15. Maybe next week I give it another try with some fresh thoughts. Regards, Ruud -Oorspronkelijk bericht- Van: Ruud Commandeur Verzonden: vrijdag 31 mei 2013 12:17 Aan: 'Stefano Babic' CC: U-Boot list; 'Wolfgang Denk' Onderwerp: RE: TFTP timeouts, i.mx fec problem? Stefano, Wolfgang, Thanks for your comments. The CONFIG_ARP_TIMEOUT was not set, so it will take the default of 5 seconds. This is also the time it takes for the first timeout. If I add a #define CONFIG_ARP_TIMEOUT200UL to my board config, I see the ARP request succeed after 2 to 4 attempts. I always see only one ARP request in Wireshark. Apparently it takes 200 - 600 msecs for the phy to wake up and respond (as Wolfgang assumes as possible and very plausible cause). Increasing the ARP_TIMEOUT to some high value like 15000UL has no use, the 5 seonds tftp timeout comes in earier and a new ARP request is sent (which is answered as before). So adding this timeout define will speed things up, and I guess I should either also increase the CONFIG_NET_RETRY_COUNT or set the ARP_TIMEOUT to 400 to prevent exceeding the retry count. But of course it would be nicer to fix the actual cause. I could try and find a way to keep the phy alive or at least try to proof that it is the phy (the LAN8720A) that causes this. To be continued... Regards, Ruud -Oorspronkelijk bericht- Van: Stefano Babic [mailto:sba...@denx.de] Verzonden: vrijdag 31 mei 2013 10:50 Aan: Ruud Commandeur CC: U-Boot list; sba...@denx.de Onderwerp: Re: TFTP timeouts, i.mx fec problem? On 31/05/2013 08:56, Ruud Commandeur wrote: Hi everyone, Hi Ruud, When tracing the code, it could see that fec_send is called for the 1st ARP request and also the return value indicates that sending should have been succeeded (fec_send: status 0xc00 index 0 ret 0). But no package is actually sent. My first guess would be that it has something to do with the TBD / DMA part. The fec_tbd_init also shows some note about a rare hardware condition regarding the WRAP bit (all in drivers/net/fec_mxc.c). Could it be that there is still another issue regarding the chip that causes this? If I do a tftp transfer from linux on the same board and in the same network, it does start immediately. At first glance the problem should be with the set up of the phy. It could take longer as expected, or there are some issues with the specific PHY of the board. An issue in general code of FEC driver is not probable, because the same code runs on most of i.MXes without problems. From your report, it looks like that the link of the phy is not yet active when the fec_send is called, and then no ARP message is sent. Could you try setting #define CONFIG_ARP_TIMEOUT to some high value (when it is set, the value is often 200mS) to check if the issue disappears ? 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 V2 0/5] ARM: OMAP: Cleanup save_boot_params function
On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. OK, do you have a beaglebone or am335x_evm around? This switch up breaks them, and I'm not sure what's going on. Part of the issue is that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't so wrong as to be a problem (END wasn't quite the end, and start was in the middle of our image, but we didn't reference it). I'm going to keep poking at this as well. Thanks! -- 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] TFTP timeouts, i.mx fec problem?
Dear Stefano Babic, In message 51a86445.3040...@denx.de you wrote: At first glance the problem should be with the set up of the phy. It could take longer as expected, or there are some issues with the specific PHY of the board. An issue in general code of FEC driver is not probable, because the same code runs on most of i.MXes without problems. Well, we do have this first-ARP-failing problem on a number of boards, and especially the i.MX based boards appear to be affected - just check which boards set CONFIG_ARP_TIMEOUT in their board configs: mx31ads mx35pdk mx51evk mx53ard mx53evk mx53loco mx53smd mx6qarm2 mx6qsabre qong woodburn Actually these are only_ i.MX based boards! From your report, it looks like that the link of the phy is not yet active when the fec_send is called, and then no ARP message is sent. The question is if there is no better way to wait for the PHY to become (really) ready? Could you try setting #define CONFIG_ARP_TIMEOUT to some high value (when it is set, the value is often 200mS) to check if the issue disappears ? Indeed, this should help. But it remains just a workaround, it ain't a real fix. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can't say I've ever been lost, but I was bewildered once for three days. - Daniel Boone (Attributed) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing image
Dear Piotr Wilczek, In message 136573-15449-1-git-send-email-p.wilc...@samsung.com you wrote: When compressed image is loaded, it must be decompressed to an aligned address + 2 to avoid unaligned access exception on some ARM platforms. If you do this, you must also account for the up to 2 additional bytes needed in the allocated buffer. Otherwise you might write over the end of the buffer... 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 Die ganzen Zahlen hat der liebe Gott geschaffen, alles andere ist Menschenwerk... Leopold Kronecker ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote: On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. OK, do you have a beaglebone or am335x_evm around? This switch up breaks them, and I'm not sure what's going on. Part of the issue is that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't so wrong as to be a problem (END wasn't quite the end, and start was in the middle of our image, but we didn't reference it). I'm going to keep poking at this as well. Thanks! Answered my own question now, am33xx (andti81xx) doesn't opt-in for omap-common/hwinit-common.c -- 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] TFTP timeouts, i.mx fec problem?
Dear Wolfgang, Stefano, I'm pretty sure I found the cause: For each tftp transfer the ethernet part is re-initialised. This means that also fec_init is called. And in fec_init this piece of code resides: #ifndef CONFIG_PHYLIB if (fec-xcv_type != SEVENWIRE) miiphy_restart_aneg(dev); #endif This means (in this case) that miiphy_restart_aneg() is called. And here the phy gets a software reset and autonegotiation restart command, wich can take up to 500 msces according to the datasheet. So when we would like to send out the 1st ARP request, the phy is busy with restart and negotiation. If I skip these commands, any tftp transfer is fast as lightning! About 150 msecs between pressing enter and the completion of a small file (68 bytes). Of course, re-initialisation of all parts for each transfer sounds like the safest solution. But perhaps the phy could only be reset / initialised once after start-up. Would this be an option? Regards, Ruud -Oorspronkelijk bericht- Van: Wolfgang Denk [mailto:w...@denx.de] Verzonden: vrijdag 31 mei 2013 16:19 Aan: Stefano Babic CC: Ruud Commandeur; U-Boot list Onderwerp: Re: [U-Boot] TFTP timeouts, i.mx fec problem? Dear Stefano Babic, In message 51a86445.3040...@denx.de you wrote: At first glance the problem should be with the set up of the phy. It could take longer as expected, or there are some issues with the specific PHY of the board. An issue in general code of FEC driver is not probable, because the same code runs on most of i.MXes without problems. Well, we do have this first-ARP-failing problem on a number of boards, and especially the i.MX based boards appear to be affected - just check which boards set CONFIG_ARP_TIMEOUT in their board configs: mx31ads mx35pdk mx51evk mx53ard mx53evk mx53loco mx53smd mx6qarm2 mx6qsabre qong woodburn Actually these are only_ i.MX based boards! From your report, it looks like that the link of the phy is not yet active when the fec_send is called, and then no ARP message is sent. The question is if there is no better way to wait for the PHY to become (really) ready? Could you try setting #define CONFIG_ARP_TIMEOUT to some high value (when it is set, the value is often 200mS) to check if the issue disappears ? Indeed, this should help. But it remains just a workaround, it ain't a real fix. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can't say I've ever been lost, but I was bewildered once for three days. - Daniel Boone (Attributed) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Ruud, On 31/05/2013 16:36, Ruud Commandeur wrote: Dear Wolfgang, Stefano, I'm pretty sure I found the cause: For each tftp transfer the ethernet part is re-initialised. This means that also fec_init is called. And in fec_init this piece of code resides: #ifndef CONFIG_PHYLIB if (fec-xcv_type != SEVENWIRE) miiphy_restart_aneg(dev); #endif Indeed, this is wanted. As design, U-Boot should not touch any interface that is not needed and must close/reset the interface after usage. The main reason is that the kernel is expecting a fresh powered on system, and we get a lot of cases (USB, for instance) when the kernel cannot go on because the bootloader let the controller in an unknown status. This means (in this case) that miiphy_restart_aneg() is called. And here the phy gets a software reset and autonegotiation restart command, wich can take up to 500 msces according to the datasheet. So when we would like to send out the 1st ARP request, the phy is busy with restart and negotiation. If I skip these commands, any tftp transfer is fast as lightning! About 150 msecs between pressing enter and the completion of a small file (68 bytes). Of course, re-initialisation of all parts for each transfer sounds like the safest solution. We discussed this issue many times, yes. But perhaps the phy could only be reset / initialised once after start-up. Would this be an option? I know that there is an exception using netconsole - if the FEC driver stops after each packet, it could not work. But again, letting the controller in a well known status should be a must before booting the kernel. In current code, eth_halt() is called before booting linux only if NETCONSOLE is activated (common/cmd_bootm.c). 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] TFTP timeouts, i.mx fec problem?
Hi Wolfgang, From your report, it looks like that the link of the phy is not yet active when the fec_send is called, and then no ARP message is sent. The question is if there is no better way to wait for the PHY to become (really) ready? The phy is reinitialized after each transaction - the safiest condition to boot afterwards the kernel. Or we need a way to stop the phy only before booting, letting it on for the whole time. But again, this opens other issues, because we cannot get as in linux if the lan cable is removed (or worse, if it is connected to another switch with a different speed). Could you try setting #define CONFIG_ARP_TIMEOUT to some high value (when it is set, the value is often 200mS) to check if the issue disappears ? Indeed, this should help. But it remains just a workaround, it ain't a real fix. Right ;-( 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
[U-Boot] [Patch v2] powerpc/pixis: Fix pixis help message
pixis_reset help command prints the message without a new line \n,
which makes the prompt on the same line.
Signed-off-by: York Sun york...@freescale.com
---
board/freescale/common/pixis.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/board/freescale/common/pixis.c b/board/freescale/common/pixis.c
index 8d07061..fbb709d 100644
--- a/board/freescale/common/pixis.c
+++ b/board/freescale/common/pixis.c
@@ -480,6 +480,7 @@ static int pixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int
argc, char * const ar
|| unknown_param) {
#ifdef CONFIG_SYS_LONGHELP
puts(cmdtp-help);
+ putc('\n');
#endif
return 1;
}
@@ -512,6 +513,7 @@ static int pixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int
argc, char * const ar
set_px_mpxpll(mpxpll))) {
#ifdef CONFIG_SYS_LONGHELP
puts(cmdtp-help);
+ putc('\n');
#endif
return 1;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Hi Stefano, On Fri, May 31, 2013 at 12:46 PM, Stefano Babic sba...@denx.de wrote: The phy is reinitialized after each transaction - the safiest condition to boot afterwards the kernel. Or we need a way to stop the phy only before booting, letting it on for the whole time. But again, this opens other issues, because we cannot get as in linux if the lan cable is removed (or worse, if it is connected to another switch with a different speed). In the kernel we can reset the fec phy, so that we can always guarantee it is on a known-state. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sf: spansion: Add support for S25FL128S
On Fri, May 31, 2013 at 1:13 PM, Xie Xiaobo x@freescale.com wrote:
SPANSION recommend S25FL128S supersedes S25FL129P, and the two flash
memory have the same device ID and Memory architecture. So they can
use the same config parameters.
Signed-off-by: Xie Xiaobo x@freescale.com
---
drivers/mtd/spi/spansion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 32b76e0..cfbd384 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -94,7 +94,7 @@ static const struct spansion_spi_flash_params
spansion_spi_flash_table[] = {
.idcode2 = 0x4d01,
.pages_per_sector = 256,
.nr_sectors = 256,
- .name = S25FL129P_64K,
+ .name = S25FL129P_64K/S25FL128S_64K,
},
{
.idcode1 = 0x2019,
Thanks for this patch, but
Sent the same change with your name as author. no issues.
http://patchwork.ozlabs.org/patch/247607/
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
Hi Stefano, On Friday, May 31, 2013 10:59:03 AM, Stefano Babic wrote: On 29/05/2013 16:46, Benoît Thébaudeau wrote: Hi Alison, Hi Benoit, I have just noticed that this was actually in 6/7. Why are you putting this into a separate patch? [Alison Wang] Because patch 2/7 is about VF610 CPU support, and doc/README.vf610 is also a document about VF610 SoC. Doc/README.mxc_ocotp is the document about a driver (IP OCOTP), so this driver document should be separated from CPU patch 2/7. I don't think so: It's part of what comes with the addition of the VF610 platform, so 6/7 could be merged into 2/7. But it does not really matter. It's probably also fine if you keep what you did. Stefano, any opinion? Strictly speaking, you're right. But as you mentioned, it does not really matter. Without reposting, I can myself squash 6/7 into 2/7 by merging the patchset. OK. Reviewed-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/7] arm: vf610: Add Vybrid VF610 to mxc_ocotp document
Hi Alison, On Tuesday, May 28, 2013 10:55:46 AM, Alison Wang wrote: This patch adds Vybrid VF610 to mxc_ocotp document. Signed-off-by: Alison Wang b18...@freescale.com --- Changes in v4: New Changes in v3: None Changes in v2: None doc/README.mxc_ocotp | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/README.mxc_ocotp b/doc/README.mxc_ocotp index 9a53311..7a2863c 100644 --- a/doc/README.mxc_ocotp +++ b/doc/README.mxc_ocotp @@ -2,6 +2,7 @@ Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP) on MXC This IP can be found on the following SoCs: + - Vybrid VF610, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name Reviewed-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
Hi Andre, On Fri, 31 May 2013 11:23:16 +0200, Andre Przywara andre.przyw...@linaro.org wrote: software_interrupt is currently a panic routine. So it is not actually used by u-boot, it's just there to dump some state and eventually call reset_cpu(). So I feel that since I am now the only user of software_interrupt I don't need any special precautions and consider this routine now actually part of the HYP mode switcher. But of course I can retain the original functionality if CONFIG_ARMV7_VIRT is not defined. You should, actually. Rule #1 goes (*) 'a new config option should have zero effect on the code when not defined'. Regards, Andre. (*) Rule #1 actually goes, 'there is an infinite number of Rule #1', but that's slightly beyond the point. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add splash screen support via loading from flash
On Fri, May 31, 2013 at 12:49 AM, Wolfgang Denk w...@denx.de wrote:
Dear Robert,
In message
camdmj5pj_aqzaxtrdnvs8ju_skvhv7zodrbuyhgjt2jfr4o...@mail.gmail.com you
wrote:
board/boundary/nitrogen6x/nitrogen6x.c | 22 ++
include/configs/nitrogen6x.h | 11 ++-
2 files changed, 32 insertions(+), 1 deletion(-)
Could you please explain why you need custom code here?
I originally tried to use the CONFIG_SPLASH_SCREEN_PREPARE functionality.
After some frustration, I figured out that without CONFIG_LCD, it is never
actually called.
http://git.denx.de/?p=u-boot/u-boot-imx.git;a=blob;f=common/stdio.c;h=5d5117c0ed838195a2caad7c28c128247771cd92;hb=HEAD#l216
It does seem odd that there are 2 totally different paths and the other
splash screen related macros are used in both but the prepare function is
only called in the LCD case.
OK, so this is a bug that needs to be fixed - but for all boards.
Since we use CONFIG_VIDEO and not CONFIG_LCD, this seemed to be the best,
or at least the least invasive, solution.
No, this is definitely not the best solution, as it keeps the bug,
so the next one who tries to do what you are doing will run into it
again.
Pleast let's fix the problem at the cause.
Please fix the video code to also run splash_screen_prepare() at the
appropriate place. While you are at it, please also replace this
construct
1071 #ifdef CONFIG_SPLASH_SCREEN_PREPARE
1072 static inline int splash_screen_prepare(void)
1073 {
1074 return board_splash_screen_prepare();
1075 }
1076 #else
1077 static inline int splash_screen_prepare(void)
1078 {
1079 return 0;
1080 }
1081 #endif
(in common/lcd.c) and use a weak function for
splash_screen_prepare(). board_splash_screen_prepare() is no longer
needed, then (the boards can provide their own implementation of
splash_screen_prepare()).
I'm not quite clear on how it should be.
So if I were just fixing lcd.c to use a weak function it would look like this:
#ifdef CONFIG_SPLASH_SCREEN_PREPARE
int __splash_screen_prepare(void)
{
return 0;
}
int splash_screen_prepare(void)
__attribute__ ((weak, alias(__splash_screen_prepare)));
#endif
But it'd also have to go in cfb_console.c. Is it possible for a board
to ever use both CONFIG_LCD and CONFIG_VIDEO and if ?
Also are prototypes necessary? Looking at cfb_console for example
weak functions I see a prototype for video_set_lut in video_fb.h but I
can't find any for board_video_skip.
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
Es ist offensichtlich, dass das menschliche Gehirn wie ein Computer
funktioniert. Da es keine dummen Computer gibt, gibt es also auch
keine dummen Menschen. Nur ein paar Leute, die unter DOS laufen.
-- unbekannt
Thanks,
Robert Winkler
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] omap-common/hwinit-common.c: Mark omap_rev_string as static
Only called in this file, mark as static.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 1645120..e614641 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -84,7 +84,7 @@ u32 cortex_rev(void)
return rev;
}
-void omap_rev_string(void)
+static void omap_rev_string(void)
{
u32 omap_rev = omap_revision();
u32 soc_variant = (omap_rev 0xF000) 28;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
We need to call the save_omap_boot_params function on am33xx/ti81xx and
other newer TI SoCs, so move the function to boot-common. Only OMAP4+
has the omap_hw_init_context function so add ifdefs to not call it on
am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx
boards.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/boot-common.c | 39
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 36 --
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
board/isee/igep0033/board.c|9 ++
board/phytec/pcm051/board.c|9 ++
board/ti/am335x/board.c|9 ++
board/ti/ti814x/evm.c |9 ++
9 files changed, 78 insertions(+), 36 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index bff7e9c..76ae1b6 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -25,6 +25,45 @@
DECLARE_GLOBAL_DATA_PTR;
+void save_omap_boot_params(void)
+{
+ u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
+ u8 boot_device;
+ u32 dev_desc, dev_data;
+
+ if ((rom_params NON_SECURE_SRAM_START) ||
+ (rom_params NON_SECURE_SRAM_END))
+ return;
+
+ /*
+* rom_params can be type casted to omap_boot_parameters and
+* used. But it not correct to assume that romcode structure
+* encoding would be same as u-boot. So use the defined offsets.
+*/
+ gd-arch.omap_boot_params.omap_bootdevice = boot_device =
+ *((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
+
+ gd-arch.omap_boot_params.ch_flags =
+ *((u8 *)(rom_params + CH_FLAGS_OFFSET));
+
+ if ((boot_device = MMC_BOOT_DEVICES_START)
+ (boot_device = MMC_BOOT_DEVICES_END)) {
+#if !defined(CONFIG_AM33XX) !defined(CONFIG_TI81XX)
+ if ((omap_hw_init_context() ==
+ OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u8 *)(rom_params + BOOT_MODE_OFFSET));
+ } else
+#endif
+ {
+ dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
+ dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u32 *)(dev_data + BOOT_MODE_OFFSET));
+ }
+ }
+}
+
#ifdef CONFIG_SPL_BUILD
u32 spl_boot_device(void)
{
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index e614641..0776d5c 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -111,42 +111,6 @@ void __weak srcomp_enable(void)
{
}
-static void save_omap_boot_params(void)
-{
- u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
- u8 boot_device;
- u32 dev_desc, dev_data;
-
- if ((rom_params NON_SECURE_SRAM_START) ||
- (rom_params NON_SECURE_SRAM_END))
- return;
-
- /*
-* rom_params can be type casted to omap_boot_parameters and
-* used. But it not correct to assume that romcode structure
-* encoding would be same as u-boot. So use the defined offsets.
-*/
- gd-arch.omap_boot_params.omap_bootdevice = boot_device =
- *((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
-
- gd-arch.omap_boot_params.ch_flags =
- *((u8 *)(rom_params + CH_FLAGS_OFFSET));
-
- if ((boot_device = MMC_BOOT_DEVICES_START)
- (boot_device = MMC_BOOT_DEVICES_END)) {
- if ((omap_hw_init_context() ==
- OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
- gd-arch.omap_boot_params.omap_bootmode =
- *((u8 *)(rom_params + BOOT_MODE_OFFSET));
- } else {
- dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
- dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
- gd-arch.omap_boot_params.omap_bootmode =
- *((u32 *)(dev_data + BOOT_MODE_OFFSET));
- }
- }
-}
-
#ifdef CONFIG_ARCH_CPU_INIT
/*
* SOC specific cpu init
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index c913b5f..fedc674 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++
[U-Boot] [PATCH 2/3] am33xx: Correct NON_SECURE_SRAM_START/END
Prior to Sricharan's cleanup of the boot parameter saving code, we did not make use of NON_SECURE_SRAM_START on am33xx, so it wasn't a problem that the address was pointing to the middle of our running SPL. Correct to point to the base location of the download image area. Increase CONFIG_SPL_TEXT_BASE to account for this scratch area being used. As part of correcting these tests, make use of the fact that we've always been placing our stack outside of the download image area (which is fine, once the downloaded image is run, ROM is gone) so correct the max size test to be the ROM defined top of the download area to where we link/load at. Signed-off-by: Tom Rini tr...@ti.com --- arch/arm/include/asm/arch-am33xx/omap.h |4 ++-- include/configs/am335x_evm.h| 10 -- include/configs/igep0033.h | 10 -- include/configs/pcm051.h| 10 -- 4 files changed, 26 insertions(+), 8 deletions(-) diff --git a/arch/arm/include/asm/arch-am33xx/omap.h b/arch/arm/include/asm/arch-am33xx/omap.h index 7e3bb9c..db15159 100644 --- a/arch/arm/include/asm/arch-am33xx/omap.h +++ b/arch/arm/include/asm/arch-am33xx/omap.h @@ -29,8 +29,8 @@ * at 0x40304000(EMU base) so that our code works for both EMU and GP */ #ifdef CONFIG_AM33XX -#define NON_SECURE_SRAM_START 0x40304000 -#define NON_SECURE_SRAM_END0x4030E000 +#define NON_SECURE_SRAM_START 0x402F0400 +#define NON_SECURE_SRAM_END0x4031 #elif defined(CONFIG_TI814X) #define NON_SECURE_SRAM_START 0x4030 #define NON_SECURE_SRAM_END0x4032 diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index f019134..a4777c7 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -305,8 +305,14 @@ /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_FRAMEWORK -#define CONFIG_SPL_TEXT_BASE 0x402F0400 -#define CONFIG_SPL_MAX_SIZE(101 * 1024) +/* + * Place the image at the start of the ROM defined image space and leave + * space for SRAM scratch entries (see arch/arm/include/omap_common.h). + * We limit our size to the ROM-defined dowloaded image area, and use the + * rest of the space for stack. + */ +#define CONFIG_SPL_TEXT_BASE 0x402F0500 +#define CONFIG_SPL_MAX_SIZE(0x4030C000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR #define CONFIG_SPL_BSS_START_ADDR 0x8000 diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h index 1912d7d..dd26d9c 100644 --- a/include/configs/igep0033.h +++ b/include/configs/igep0033.h @@ -214,8 +214,14 @@ /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_FRAMEWORK -#define CONFIG_SPL_TEXT_BASE 0x402F0400 -#define CONFIG_SPL_MAX_SIZE(101 * 1024) +/* + * Place the image at the start of the ROM defined image space and leave + * space for SRAM scratch entries (see arch/arm/include/omap_common.h). + * We limit our size to the ROM-defined dowloaded image area, and use the + * rest of the space for stack. + */ +#define CONFIG_SPL_TEXT_BASE 0x402F0500 +#define CONFIG_SPL_MAX_SIZE(0x4030C000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR #define CONFIG_SPL_BSS_START_ADDR 0x8000 diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h index 478f805..a7d01f1 100644 --- a/include/configs/pcm051.h +++ b/include/configs/pcm051.h @@ -204,8 +204,14 @@ /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_FRAMEWORK -#define CONFIG_SPL_TEXT_BASE 0x402F0400 -#define CONFIG_SPL_MAX_SIZE(101 * 1024) +/* + * Place the image at the start of the ROM defined image space and leave + * space for SRAM scratch entries (see arch/arm/include/omap_common.h). + * We limit our size to the ROM-defined dowloaded image area, and use the + * rest of the space for stack. + */ +#define CONFIG_SPL_TEXT_BASE 0x402F0500 +#define CONFIG_SPL_MAX_SIZE(0x4030C000 - CONFIG_SPL_TEXT_BASE) #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR #define CONFIG_SPL_BSS_START_ADDR 0x8000 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/mpc8xxx failed to compile: operand out of range
On 05/23/2013 04:52:26 AM, Jérôme Arzel wrote: Hi all, I have an issue when I compile U-Boot for my target machine (P1022DS, 36-bit). Here is the error message: release.S: Assembler messages: release.S:154: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:286: Error: operand out of range (0xf144 is not between 0x and 0x) release.S:311: Error: operand out of range (0xf140 is not between 0x and 0x) (release.S is located to arch/powerpc/cpu/mpc85xx/release.S) And here is the code for the first error (line 150): #define toreset(x) (x - __secondary_start_page + 0xf000) /* get our PIR to figure out our table entry */ lis r3,toreset(__spin_table_addr)@h ori r3,r3,toreset(__spin_table_addr)@l I don't really know why it doesn't work, but I think that ori is inappropried, the immediate value must be a 16-bit value. I use GCC 4.7.3, compiled in x86_64 for target powerpc-none-linux-gnuspe. My U-Boot come from the repository, but older versions fail too. This appears to be a binutils bug, introduced in 2.23.2. The attached test program gives a similar error on 2.23.2, but 2.23.1 is OK. I've filed it here: http://sourceware.org/bugzilla/show_bug.cgi?id=15557 -Scottori 3,3,(y-x+0x8000)@l x: y: ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Stefano, [Joe added to Cc: list] In message 51a8c479.6010...@denx.de you wrote: This means (in this case) that miiphy_restart_aneg() is called. And here the phy gets a software reset and autonegotiation restart command, wich can take up to 500 msces according to the datasheet. So when we would like to send out the 1st ARP request, the phy is busy with restart and negotiation. If I skip these commands, any tftp transfer is fast as lightning! About 150 msecs between pressing enter and the completion of a small file (68 bytes). Of course, re-initialisation of all parts for each transfer sounds like the safest solution. We discussed this issue many times, yes. I still wonder if we should not be able to wait until the PHY has complete auto-negotiation, before we send the first packet. There should be some status bit available we could poll for, rathr than relying on a delay (which will always have to be tuned for the worst case)? 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 Quote from a recent meeting: We are going to continue having these meetings everyday until I find out why no work is getting done. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
Dear Stefano Babic, In message 51a8c5da.3090...@denx.de you wrote: The question is if there is no better way to wait for the PHY to become (really) ready? The phy is reinitialized after each transaction - the safiest condition to boot afterwards the kernel. Or we need a way to stop the phy only Yes, that is clear, we fully agree on that. But can we not test for autoneogitation completed, link up and running before we send the first packet? Or rather - why do we have this issue appearently only on i.MX? We don't see this on other ARM or on PowerPC? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] TFTP timeouts, i.mx fec problem?
On 5/31/2013 11:58 AM, Wolfgang Denk wrote: Dear Stefano Babic, In message 51a8c5da.3090...@denx.de you wrote: The question is if there is no better way to wait for the PHY to become (really) ready? The phy is reinitialized after each transaction - the safiest condition to boot afterwards the kernel. Or we need a way to stop the phy only Yes, that is clear, we fully agree on that. But can we not test for autoneogitation completed, link up and running before we send the first packet? Or rather - why do we have this issue appearently only on i.MX? We don't see this on other ARM or on PowerPC? Best regards, Wolfgang Denk Think of this as incentive to convert to the board to PHYLIB. Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4] ARM: OMAP: I2C: New read, write and probe functions
New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
(4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
OMAPs and derivatives as well. The only anticipated exception would
be the OMAP2420, which shall require driver modification.
- Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
- Optimised i2c_write.
- New i2c_probe, performs write access vs read. The old probe could
hang the system under certain conditions (e.g. unconfigured pads).
- The read/write/probe functions try to identify unconfigured bus.
- Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
- Driver now supports up to I2C5 (OMAP5).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V4 changes:
- New i2c_probe is built unconditionally, old code is removed.
CONFIG_I2C_PROBE_WRITE is no longer needed.
- Added a small delay to work around breakage in AM335X SPL.
- Some whitespace and general formatting cleanup.
V3 changes:
- Removed old functions and conditional compilation. New functions
are now built unconditionally for all SoCs using this driver. The
only chip that should break is the OMAP2420 dinosaur.
- Interrupts are enabled for OMAP243X and OMAP34XX only (where we
don't have an irqstatus_raw register).
V2 changes:
- Probe tries to identify misconfigured pads as well.
- Status is retrieved from irqstatus_raw rather than from stat.
- Some minor style format changes.
drivers/i2c/omap24xx_i2c.c | 490 +++--
1 file changed, 300 insertions(+), 190 deletions(-)
mode change 100644 = 100755 drivers/i2c/omap24xx_i2c.c
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
old mode 100644
new mode 100755
index 54e9b15..5a1c74e
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -18,6 +18,20 @@
*
* Adapted for OMAP2420 I2C, r-woodru...@ti.com
*
+ * Copyright (c) 2013 Lubomir Popov lpo...@mm-sol.com, MM Solutions
+ * New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
+ * (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
+ * OMAPs and derivatives as well. The only anticipated exception would
+ * be the OMAP2420, which shall require driver modification.
+ * - Rewritten i2c_read to operate correctly with all types of chips
+ * (old function could not read consistent data from some I2C slaves).
+ * - Optimized i2c_write.
+ * - New i2c_probe, performs write access vs read. The old probe could
+ * hang the system under certain conditions (e.g. unconfigured pads).
+ * - The read/write/probe functions try to identify unconfigured bus.
+ * - Status functions now read irqstatus_raw as per TRM guidelines
+ * (except for OMAP243X and OMAP34XX).
+ * - Driver now supports up to I2C5 (OMAP5).
*/
#include common.h
@@ -31,8 +45,11 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_TIMEOUT1000
+/* Absolutely safe for status update at 100 kHz I2C: */
+#define I2C_WAIT 200
+
static int wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u16 wait_for_event(void);
static void flush_fifo(void);
/*
@@ -137,10 +154,14 @@ void i2c_init(int speed, int slaveadd)
/* own address */
writew(slaveadd, i2c_base-oa);
writew(I2C_CON_EN, i2c_base-con);
-
- /* have to enable intrrupts or OMAP i2c module doesn't work */
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+ /*
+* Have to enable interrupts for OMAP2/3, these IPs don't have
+* an 'irqstatus_raw' register and we shall have to poll 'stat'
+*/
writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
I2C_IE_NACK_IE | I2C_IE_AL_IE, i2c_base-ie);
+#endif
udelay(1000);
flush_fifo();
writew(0x, i2c_base-stat);
@@ -150,88 +171,6 @@ void i2c_init(int speed, int slaveadd)
bus_initialized[current_bus] = 1;
}
-static int i2c_read_byte(u8 devaddr, u16 regoffset, u8 alen, u8 *value)
-{
- int i2c_error = 0;
- u16 status;
- int i = 2 - alen;
- u8 tmpbuf[2] = {(regoffset) 8, regoffset 0xff};
- u16 w;
-
- /* wait until bus not busy */
- if (wait_for_bb())
- return 1;
-
- /* one byte only */
- writew(alen, i2c_base-cnt);
- /* set slave address */
- writew(devaddr, i2c_base-sa);
- /* no stop bit needed here */
- writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
- I2C_CON_TRX, i2c_base-con);
-
- /* send register offset */
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status I2C_STAT_NACK) {
- i2c_error = 1;
- goto read_exit;
- }
- if (status I2C_STAT_XRDY) {
- w = tmpbuf[i++];
-#if !(defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
-
[U-Boot] Pull request: nand flash
The following changes since commit 8bcb6f43e98ffc76e998349e0ec32a0e359160d4: Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to f3e9d53b5f35472745077b072399aefe87f228d4: mtd: resync with Linux-3.7.1 (2013-05-30 15:25:39 -0500) Harvey Chapman (1): nand: adjust erase/read/write partition/chip size for bad blocks Prabhakar Kushwaha (1): nand/fsl_ifc: Convert to self-init Scott Wood (1): nand/fsl_elbc: detect page size at runtime Sergey Lapin (1): mtd: resync with Linux-3.7.1 htbegin (2): mtd: nand: fix the partial page write condition mtd: nand: use ssize_t instead of size_t to prevent infinite loop board/ait/cam_enc_4xx/cam_enc_4xx.c | 12 +- common/cmd_nand.c | 53 +- common/cmd_onenand.c| 30 +- common/env_onenand.c|6 +- drivers/mtd/Makefile|4 +- drivers/mtd/cfi_mtd.c | 12 +- drivers/mtd/mtdconcat.c | 98 +-- drivers/mtd/mtdcore.c | 191 drivers/mtd/mtdpart.c | 158 ++-- drivers/mtd/nand/atmel_nand.c | 17 +- drivers/mtd/nand/bfin_nand.c|2 + drivers/mtd/nand/davinci_nand.c |4 +- drivers/mtd/nand/diskonchip.c | 13 +- drivers/mtd/nand/fsl_elbc_nand.c| 56 +- drivers/mtd/nand/fsl_ifc_nand.c | 62 +- drivers/mtd/nand/fsmc_nand.c|5 +- drivers/mtd/nand/jz4740_nand.c |1 + drivers/mtd/nand/mpc5121_nfc.c |2 +- drivers/mtd/nand/mxc_nand.c | 25 +- drivers/mtd/nand/mxs_nand.c | 34 +- drivers/mtd/nand/nand_base.c| 1658 --- drivers/mtd/nand/nand_bbt.c | 822 - drivers/mtd/nand/nand_ids.c | 14 +- drivers/mtd/nand/nand_util.c| 26 +- drivers/mtd/nand/ndfc.c |1 + drivers/mtd/nand/nomadik.c |1 + drivers/mtd/nand/omap_gpmc.c|6 +- drivers/mtd/nand/s3c2410_nand.c |1 + drivers/mtd/nand/tegra_nand.c | 27 +- drivers/mtd/nand/tegra_nand.h |2 +- drivers/mtd/onenand/onenand_base.c | 82 +- drivers/mtd/onenand/onenand_bbt.c |6 +- drivers/mtd/ubi/build.c |2 +- drivers/mtd/ubi/eba.c |2 +- drivers/mtd/ubi/io.c| 12 +- drivers/mtd/ubi/kapi.c |2 +- drivers/mtd/ubi/misc.c |2 +- drivers/mtd/ubi/vtbl.c |2 +- fs/yaffs2/yaffs_mtdif.c | 18 +- fs/yaffs2/yaffs_mtdif2.c| 14 +- include/configs/P1022DS.h |2 - include/linux/mtd/bbm.h | 49 +- include/linux/mtd/mtd-abi.h | 158 include/linux/mtd/mtd.h | 203 +++-- include/linux/mtd/nand.h| 173 ++-- include/linux/string.h |3 + include/nand.h | 11 +- lib/string.c| 59 ++ 48 files changed, 2255 insertions(+), 1888 deletions(-) delete mode 100644 include/linux/mtd/mtd-abi.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Thu, May 30, 2013 at 09:29:21PM +0200, Albert ARIBAUD wrote: Hello Tom, The following changes since commit a71d45d706a5b51c348160163b6c159632273fed: powerpc/mpc85xx: Clear L1 D-cache lock (2013-05-24 16:54:14 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 3da0e5750b24a9491058df6126c7be577a276c09: arm: factorize relocate_code routine (2013-05-30 20:24:38 +0200) Albert ARIBAUD (9): Merge branch 'u-boot-pxa/master' into 'u-boot-arm/master' Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Revert wrong removal of nand_init and nand_deselect Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' Merge branch 'u-boot/master' into 'u-boot-arm/master' mx31pdk: copy SPL directly, not using relocate_code. tx25: copy SPL directly, not using relocate_code. arm: do not compile relocate_code() for SPL builds arm: factorize relocate_code routine Allen Martin (1): Tegra: clk: always use find_best_divider() for periph clocks Andre Przywara (2): ARM: vexpress: add support for Versatile Express Cortex-A15-TC2 ARM: vexpress: enable bootz and hush parser for all VExpress boards Andreas Bie??mann (1): at91sam9260ek: move board id setup to config header Axel Lin (2): ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build Beno??t Th??baudeau (40): imx: Homogenize and fix fuse register definitions imx: Add useful fuse definitions Add fuse API and commands Add fsl_iim driver mpc: iim: Switch to common fsl_iim mx51evk: Enable support for iim Add mxc_ocotp driver mx6qsabrelite: Enable support for ocotp nitrogen6x: Enable support for ocotp imx: Document fuse assignments for MAC addresses imx: iomux-v3: Fix common pad control definitions imx: iomux-v3: cosmetic: Reorganize definitions imx: iomux-v3: Restore Linux's NEW_PAD_CTRL() macro imx: iomux-v3: Include PKE and PUE to pad control pull definitions imx: iomux-v3: Add iomux-mx25.h imx: mx25pdk: Convert to iomux-v3 imx: mx25pdk: Fix GPIO assignments imx: tx25: Convert to iomux-v3 imx: zmx25: Convert to iomux-v3 imx: mx25: Remove legacy iomux support imx: iomux-v3: Add iomux-mx35.h imx: flea3: Convert to iomux-v3 imx: mx35pdk: Fix WDOG_RST iomux function imx: mx35pdk: Convert to iomux-v3 imx: woodburn: Convert to iomux-v3 imx: mx35: Remove legacy iomux support imx: iomux-mx51: Fix MX51_PAD_EIM_CS2__GPIO2_27 imx: iomux-v3: Add missing definitions to iomux-mx51.h imx: mx51evk: Convert to iomux-v3 imx: mx51_efikamx/sb: Convert to iomux-v3 imx: vision2: Convert to iomux-v3 imx: iomux-v3: Add iomux-mx53.h imx: ima3-mx53: Convert to iomux-v3 imx: mx53ard: Convert to iomux-v3 imx: mx53evk: Convert to iomux-v3 imx: mx53loco: Convert to iomux-v3 imx: mx53smd: Convert to iomux-v3 imx: m53evk: Convert to iomux-v3 imx: mx5: Remove legacy iomux support imx: mx35pdk: Fix MUX2_CTR GPIO Bo Shen (9): spi: atmel_spi: using ip version to check whether has wdrbt mmc: atmel_mci: using IP version for different setting mmc: atmel_mci: add mmc card support ARM: at91: add Atmel sama5d3 SoC new pmc register USB: ohci-at91: support sama5d3x devices ARM: atmel: add sama5d3xek support ARM: at91: fix and update README.at91 document ARM: at91: add at91sam9x5 and sama5d3x information ARM: at91: add NAND partition table and index Dan Murphy (2): ARM:Panda:Fix device tree loading for the panda-es ARM: Panda: Add flag to allow runtime enviroment varibale mods David Andrey (3): arm: zynq: U-Boot udelay 1000 FIX net: gem: Pass phy address to init net: gem: Preserve clk on emio interface Enric Balletbo i Serra (2): Add DDR3 support for IGEP COM AQUILA/CYGNUS. ARM: Add support for IGEP COM AQUILA/CYGNUS Eric Benard (3): mx28evk: add trimffs to nand command da850: provide davinci_enable_uart0 davinci: handle CONFIG_SYS_CLE_MASK and CONFIG_SYS_ALE_MASK Fabio Estevam (22): iomux-v3: Place pad control definitions into common file mx6: Add solo-lite variant support mx6sl: Add initial support for mx6slevk board imx: mx6q_4x_mt41j128.cfg: Setup CCM_CCOSR register nitrogen6x: Setup CCM_CCOSR register mx51evk: Update environment in order to allow booting a dt kernel mx51evk: Do not force the rootfs type mx5: Define a common get_board_rev() mx5: Select CONFIG_REVISION_TAG mx53ard:
Re: [U-Boot] [PATCH 2/3] am33xx: Correct NON_SECURE_SRAM_START/END
Tom == Tom Rini tr...@ti.com writes: Tom Prior to Sricharan's cleanup of the boot parameter saving code, we Tom did not make use of NON_SECURE_SRAM_START on am33xx, so it wasn't a Tom problem that the address was pointing to the middle of our running SPL. Tom Correct to point to the base location of the download image area. Tom Increase CONFIG_SPL_TEXT_BASE to account for this scratch area being Tom used. As part of correcting these tests, make use of the fact that Tom we've always been placing our stack outside of the download image area Tom (which is fine, once the downloaded image is run, ROM is gone) so Tom correct the max size test to be the ROM defined top of the download area Tom to where we link/load at. Tom Signed-off-by: Tom Rini tr...@ti.com Tom --- Tom arch/arm/include/asm/arch-am33xx/omap.h |4 ++-- Tom include/configs/am335x_evm.h| 10 -- Tom include/configs/igep0033.h | 10 -- Tom include/configs/pcm051.h| 10 -- Tom 4 files changed, 26 insertions(+), 8 deletions(-) Tom diff --git a/arch/arm/include/asm/arch-am33xx/omap.h b/arch/arm/include/asm/arch-am33xx/omap.h Tom index 7e3bb9c..db15159 100644 Tom --- a/arch/arm/include/asm/arch-am33xx/omap.h Tom +++ b/arch/arm/include/asm/arch-am33xx/omap.h Tom @@ -29,8 +29,8 @@ Tom * at 0x40304000(EMU base) so that our code works for both EMU and GP Tom */ Tom #ifdef CONFIG_AM33XX Tom -#define NON_SECURE_SRAM_START0x40304000 Tom -#define NON_SECURE_SRAM_END 0x4030E000 Tom +#define NON_SECURE_SRAM_START0x402F0400 Tom +#define NON_SECURE_SRAM_END 0x4031 Tom #elif defined(CONFIG_TI814X) Tom #define NON_SECURE_SRAM_START0x4030 Tom #define NON_SECURE_SRAM_END 0x4032 Tom diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h Tom index f019134..a4777c7 100644 Tom --- a/include/configs/am335x_evm.h Tom +++ b/include/configs/am335x_evm.h Tom @@ -305,8 +305,14 @@ Tom /* Defines for SPL */ Tom #define CONFIG_SPL Tom #define CONFIG_SPL_FRAMEWORK Tom -#define CONFIG_SPL_TEXT_BASE 0x402F0400 Tom -#define CONFIG_SPL_MAX_SIZE (101 * 1024) Tom +/* Tom + * Place the image at the start of the ROM defined image space and leave Tom + * space for SRAM scratch entries (see arch/arm/include/omap_common.h). Tom + * We limit our size to the ROM-defined dowloaded image area, and use the s/dowloaded/downloaded/ Tom + * rest of the space for stack. Tom + */ Tom +#define CONFIG_SPL_TEXT_BASE 0x402F0500 Tom +#define CONFIG_SPL_MAX_SIZE (0x4030C000 - CONFIG_SPL_TEXT_BASE) Tom #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR Tom #define CONFIG_SPL_BSS_START_ADDR0x8000 Tom diff --git a/include/configs/igep0033.h b/include/configs/igep0033.h Tom index 1912d7d..dd26d9c 100644 Tom --- a/include/configs/igep0033.h Tom +++ b/include/configs/igep0033.h Tom @@ -214,8 +214,14 @@ Tom /* Defines for SPL */ Tom #define CONFIG_SPL Tom #define CONFIG_SPL_FRAMEWORK Tom -#define CONFIG_SPL_TEXT_BASE 0x402F0400 Tom -#define CONFIG_SPL_MAX_SIZE (101 * 1024) Tom +/* Tom + * Place the image at the start of the ROM defined image space and leave Tom + * space for SRAM scratch entries (see arch/arm/include/omap_common.h). Tom + * We limit our size to the ROM-defined dowloaded image area, and use the s/dowloaded/downloaded/ Tom + * rest of the space for stack. Tom + */ Tom +#define CONFIG_SPL_TEXT_BASE 0x402F0500 Tom +#define CONFIG_SPL_MAX_SIZE (0x4030C000 - CONFIG_SPL_TEXT_BASE) Tom #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR Tom #define CONFIG_SPL_BSS_START_ADDR0x8000 Tom diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h Tom index 478f805..a7d01f1 100644 Tom --- a/include/configs/pcm051.h Tom +++ b/include/configs/pcm051.h Tom @@ -204,8 +204,14 @@ Tom /* Defines for SPL */ Tom #define CONFIG_SPL Tom #define CONFIG_SPL_FRAMEWORK Tom -#define CONFIG_SPL_TEXT_BASE 0x402F0400 Tom -#define CONFIG_SPL_MAX_SIZE (101 * 1024) Tom +/* Tom + * Place the image at the start of the ROM defined image space and leave Tom + * space for SRAM scratch entries (see arch/arm/include/omap_common.h). Tom + * We limit our size to the ROM-defined dowloaded image area, and use the s/dowloaded/downloaded/ Otherwise it looks good. Reviewed-by: Peter Korsgaard jac...@sunsite.dk -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
On Fri, May 31, 2013 at 02:52:17PM -0500, Scott Wood wrote: The following changes since commit 8bcb6f43e98ffc76e998349e0ec32a0e359160d4: Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to f3e9d53b5f35472745077b072399aefe87f228d4: mtd: resync with Linux-3.7.1 (2013-05-30 15:25:39 -0500) Harvey Chapman (1): nand: adjust erase/read/write partition/chip size for bad blocks Prabhakar Kushwaha (1): nand/fsl_ifc: Convert to self-init Scott Wood (1): nand/fsl_elbc: detect page size at runtime Sergey Lapin (1): mtd: resync with Linux-3.7.1 htbegin (2): mtd: nand: fix the partial page write condition mtd: nand: use ssize_t instead of size_t to prevent infinite loop board/ait/cam_enc_4xx/cam_enc_4xx.c | 12 +- common/cmd_nand.c | 53 +- common/cmd_onenand.c| 30 +- common/env_onenand.c|6 +- drivers/mtd/Makefile|4 +- drivers/mtd/cfi_mtd.c | 12 +- drivers/mtd/mtdconcat.c | 98 +-- drivers/mtd/mtdcore.c | 191 drivers/mtd/mtdpart.c | 158 ++-- drivers/mtd/nand/atmel_nand.c | 17 +- drivers/mtd/nand/bfin_nand.c|2 + drivers/mtd/nand/davinci_nand.c |4 +- drivers/mtd/nand/diskonchip.c | 13 +- drivers/mtd/nand/fsl_elbc_nand.c| 56 +- drivers/mtd/nand/fsl_ifc_nand.c | 62 +- drivers/mtd/nand/fsmc_nand.c|5 +- drivers/mtd/nand/jz4740_nand.c |1 + drivers/mtd/nand/mpc5121_nfc.c |2 +- drivers/mtd/nand/mxc_nand.c | 25 +- drivers/mtd/nand/mxs_nand.c | 34 +- drivers/mtd/nand/nand_base.c| 1658 --- drivers/mtd/nand/nand_bbt.c | 822 - drivers/mtd/nand/nand_ids.c | 14 +- drivers/mtd/nand/nand_util.c| 26 +- drivers/mtd/nand/ndfc.c |1 + drivers/mtd/nand/nomadik.c |1 + drivers/mtd/nand/omap_gpmc.c|6 +- drivers/mtd/nand/s3c2410_nand.c |1 + drivers/mtd/nand/tegra_nand.c | 27 +- drivers/mtd/nand/tegra_nand.h |2 +- drivers/mtd/onenand/onenand_base.c | 82 +- drivers/mtd/onenand/onenand_bbt.c |6 +- drivers/mtd/ubi/build.c |2 +- drivers/mtd/ubi/eba.c |2 +- drivers/mtd/ubi/io.c| 12 +- drivers/mtd/ubi/kapi.c |2 +- drivers/mtd/ubi/misc.c |2 +- drivers/mtd/ubi/vtbl.c |2 +- fs/yaffs2/yaffs_mtdif.c | 18 +- fs/yaffs2/yaffs_mtdif2.c| 14 +- include/configs/P1022DS.h |2 - include/linux/mtd/bbm.h | 49 +- include/linux/mtd/mtd-abi.h | 158 include/linux/mtd/mtd.h | 203 +++-- include/linux/mtd/nand.h| 173 ++-- include/linux/string.h |3 + include/nand.h | 11 +- lib/string.c| 59 ++ 48 files changed, 2255 insertions(+), 1888 deletions(-) delete mode 100644 include/linux/mtd/mtd-abi.h NAK. Almost everything is blowing up with: /home/trini/work/u-boot/u-boot/include/linux/mtd/mtd.h:12:25: fatal error: mtd/mtd-abi.h: No such file or directory compilation terminated. Which tells me this can't have had much / any run-time testing, which I'm not super comfortable on, with a re-sync of the subsystem. -- 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] Pull request: nand flash
On 05/31/2013 04:28:41 PM, Tom Rini wrote: On Fri, May 31, 2013 at 02:52:17PM -0500, Scott Wood wrote: The following changes since commit 8bcb6f43e98ffc76e998349e0ec32a0e359160d4: Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to f3e9d53b5f35472745077b072399aefe87f228d4: mtd: resync with Linux-3.7.1 (2013-05-30 15:25:39 -0500) Harvey Chapman (1): nand: adjust erase/read/write partition/chip size for bad blocks Prabhakar Kushwaha (1): nand/fsl_ifc: Convert to self-init Scott Wood (1): nand/fsl_elbc: detect page size at runtime Sergey Lapin (1): mtd: resync with Linux-3.7.1 htbegin (2): mtd: nand: fix the partial page write condition mtd: nand: use ssize_t instead of size_t to prevent infinite loop board/ait/cam_enc_4xx/cam_enc_4xx.c | 12 +- common/cmd_nand.c | 53 +- common/cmd_onenand.c| 30 +- common/env_onenand.c|6 +- drivers/mtd/Makefile|4 +- drivers/mtd/cfi_mtd.c | 12 +- drivers/mtd/mtdconcat.c | 98 +-- drivers/mtd/mtdcore.c | 191 drivers/mtd/mtdpart.c | 158 ++-- drivers/mtd/nand/atmel_nand.c | 17 +- drivers/mtd/nand/bfin_nand.c|2 + drivers/mtd/nand/davinci_nand.c |4 +- drivers/mtd/nand/diskonchip.c | 13 +- drivers/mtd/nand/fsl_elbc_nand.c| 56 +- drivers/mtd/nand/fsl_ifc_nand.c | 62 +- drivers/mtd/nand/fsmc_nand.c|5 +- drivers/mtd/nand/jz4740_nand.c |1 + drivers/mtd/nand/mpc5121_nfc.c |2 +- drivers/mtd/nand/mxc_nand.c | 25 +- drivers/mtd/nand/mxs_nand.c | 34 +- drivers/mtd/nand/nand_base.c| 1658 --- drivers/mtd/nand/nand_bbt.c | 822 - drivers/mtd/nand/nand_ids.c | 14 +- drivers/mtd/nand/nand_util.c| 26 +- drivers/mtd/nand/ndfc.c |1 + drivers/mtd/nand/nomadik.c |1 + drivers/mtd/nand/omap_gpmc.c|6 +- drivers/mtd/nand/s3c2410_nand.c |1 + drivers/mtd/nand/tegra_nand.c | 27 +- drivers/mtd/nand/tegra_nand.h |2 +- drivers/mtd/onenand/onenand_base.c | 82 +- drivers/mtd/onenand/onenand_bbt.c |6 +- drivers/mtd/ubi/build.c |2 +- drivers/mtd/ubi/eba.c |2 +- drivers/mtd/ubi/io.c| 12 +- drivers/mtd/ubi/kapi.c |2 +- drivers/mtd/ubi/misc.c |2 +- drivers/mtd/ubi/vtbl.c |2 +- fs/yaffs2/yaffs_mtdif.c | 18 +- fs/yaffs2/yaffs_mtdif2.c| 14 +- include/configs/P1022DS.h |2 - include/linux/mtd/bbm.h | 49 +- include/linux/mtd/mtd-abi.h | 158 include/linux/mtd/mtd.h | 203 +++-- include/linux/mtd/nand.h| 173 ++-- include/linux/string.h |3 + include/nand.h | 11 +- lib/string.c| 59 ++ 48 files changed, 2255 insertions(+), 1888 deletions(-) delete mode 100644 include/linux/mtd/mtd-abi.h NAK. Almost everything is blowing up with: /home/trini/work/u-boot/u-boot/include/linux/mtd/mtd.h:12:25: fatal error: mtd/mtd-abi.h: No such file or directory compilation terminated. Sigh. It's present locally, but didn't get added to the commit for some reason. I hate how git am operates in the presence of rejects, even when the --reject option is given. Given how recently it was pushed, should I amend the commit (to preserve bisectability) or make a followup patch? Which tells me this can't have had much / any run-time testing, which I'm not super comfortable on, with a re-sync of the subsystem. I doubt many people use u-boot-nand-flash.git directly, so you're never going to get much *run-time* testing prior to a merge, beyond what I do personally on a board or two. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
On Fri, May 31, 2013 at 04:44:45PM -0500, Scott Wood wrote: On 05/31/2013 04:28:41 PM, Tom Rini wrote: On Fri, May 31, 2013 at 02:52:17PM -0500, Scott Wood wrote: The following changes since commit 8bcb6f43e98ffc76e998349e0ec32a0e359160d4: Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400) are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master for you to fetch changes up to f3e9d53b5f35472745077b072399aefe87f228d4: mtd: resync with Linux-3.7.1 (2013-05-30 15:25:39 -0500) Harvey Chapman (1): nand: adjust erase/read/write partition/chip size for bad blocks Prabhakar Kushwaha (1): nand/fsl_ifc: Convert to self-init Scott Wood (1): nand/fsl_elbc: detect page size at runtime Sergey Lapin (1): mtd: resync with Linux-3.7.1 htbegin (2): mtd: nand: fix the partial page write condition mtd: nand: use ssize_t instead of size_t to prevent infinite loop board/ait/cam_enc_4xx/cam_enc_4xx.c | 12 +- common/cmd_nand.c | 53 +- common/cmd_onenand.c| 30 +- common/env_onenand.c|6 +- drivers/mtd/Makefile|4 +- drivers/mtd/cfi_mtd.c | 12 +- drivers/mtd/mtdconcat.c | 98 +-- drivers/mtd/mtdcore.c | 191 drivers/mtd/mtdpart.c | 158 ++-- drivers/mtd/nand/atmel_nand.c | 17 +- drivers/mtd/nand/bfin_nand.c|2 + drivers/mtd/nand/davinci_nand.c |4 +- drivers/mtd/nand/diskonchip.c | 13 +- drivers/mtd/nand/fsl_elbc_nand.c| 56 +- drivers/mtd/nand/fsl_ifc_nand.c | 62 +- drivers/mtd/nand/fsmc_nand.c|5 +- drivers/mtd/nand/jz4740_nand.c |1 + drivers/mtd/nand/mpc5121_nfc.c |2 +- drivers/mtd/nand/mxc_nand.c | 25 +- drivers/mtd/nand/mxs_nand.c | 34 +- drivers/mtd/nand/nand_base.c| 1658 --- drivers/mtd/nand/nand_bbt.c | 822 - drivers/mtd/nand/nand_ids.c | 14 +- drivers/mtd/nand/nand_util.c| 26 +- drivers/mtd/nand/ndfc.c |1 + drivers/mtd/nand/nomadik.c |1 + drivers/mtd/nand/omap_gpmc.c|6 +- drivers/mtd/nand/s3c2410_nand.c |1 + drivers/mtd/nand/tegra_nand.c | 27 +- drivers/mtd/nand/tegra_nand.h |2 +- drivers/mtd/onenand/onenand_base.c | 82 +- drivers/mtd/onenand/onenand_bbt.c |6 +- drivers/mtd/ubi/build.c |2 +- drivers/mtd/ubi/eba.c |2 +- drivers/mtd/ubi/io.c| 12 +- drivers/mtd/ubi/kapi.c |2 +- drivers/mtd/ubi/misc.c |2 +- drivers/mtd/ubi/vtbl.c |2 +- fs/yaffs2/yaffs_mtdif.c | 18 +- fs/yaffs2/yaffs_mtdif2.c| 14 +- include/configs/P1022DS.h |2 - include/linux/mtd/bbm.h | 49 +- include/linux/mtd/mtd-abi.h | 158 include/linux/mtd/mtd.h | 203 +++-- include/linux/mtd/nand.h| 173 ++-- include/linux/string.h |3 + include/nand.h | 11 +- lib/string.c| 59 ++ 48 files changed, 2255 insertions(+), 1888 deletions(-) delete mode 100644 include/linux/mtd/mtd-abi.h NAK. Almost everything is blowing up with: /home/trini/work/u-boot/u-boot/include/linux/mtd/mtd.h:12:25: fatal error: mtd/mtd-abi.h: No such file or directory compilation terminated. Sigh. It's present locally, but didn't get added to the commit for some reason. I hate how git am operates in the presence of rejects, even when the --reject option is given. Given how recently it was pushed, should I amend the commit (to preserve bisectability) or make a followup patch? Just ammend / re-work, yes, thanks. Which tells me this can't have had much / any run-time testing, which I'm not super comfortable on, with a re-sync of the subsystem. I doubt many people use u-boot-nand-flash.git directly, so you're never going to get much *run-time* testing prior to a merge, beyond what I do personally on a board or two. Yes, that's about what I'm looking for. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request v2: nand flash
v2: Amended the resync commit due to include/mtd/mtd-abi.h being
missing (it was present locally as an uncommitted file, which is why I
didn't see build failures).
The following changes since commit 8bcb6f43e98ffc76e998349e0ec32a0e359160d4:
Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-nand-flash.git master
for you to fetch changes up to dfe64e2c89731a3f9950d7acd8681b68df2bae03:
mtd: resync with Linux-3.7.1 (2013-05-31 17:12:03 -0500)
Harvey Chapman (1):
nand: adjust erase/read/write partition/chip size for bad blocks
Prabhakar Kushwaha (1):
nand/fsl_ifc: Convert to self-init
Scott Wood (1):
nand/fsl_elbc: detect page size at runtime
Sergey Lapin (1):
mtd: resync with Linux-3.7.1
htbegin (2):
mtd: nand: fix the partial page write condition
mtd: nand: use ssize_t instead of size_t to prevent infinite loop
board/ait/cam_enc_4xx/cam_enc_4xx.c | 12 +-
common/cmd_nand.c | 53 +-
common/cmd_onenand.c| 30 +-
common/env_onenand.c|6 +-
drivers/mtd/Makefile|4 +-
drivers/mtd/cfi_mtd.c | 12 +-
drivers/mtd/mtdconcat.c | 98 +--
drivers/mtd/mtdcore.c | 191
drivers/mtd/mtdpart.c | 158 ++--
drivers/mtd/nand/atmel_nand.c | 17 +-
drivers/mtd/nand/bfin_nand.c|2 +
drivers/mtd/nand/davinci_nand.c |4 +-
drivers/mtd/nand/diskonchip.c | 13 +-
drivers/mtd/nand/fsl_elbc_nand.c| 56 +-
drivers/mtd/nand/fsl_ifc_nand.c | 62 +-
drivers/mtd/nand/fsmc_nand.c|5 +-
drivers/mtd/nand/jz4740_nand.c |1 +
drivers/mtd/nand/mpc5121_nfc.c |2 +-
drivers/mtd/nand/mxc_nand.c | 25 +-
drivers/mtd/nand/mxs_nand.c | 34 +-
drivers/mtd/nand/nand_base.c| 1658 ---
drivers/mtd/nand/nand_bbt.c | 822 -
drivers/mtd/nand/nand_ids.c | 14 +-
drivers/mtd/nand/nand_util.c| 26 +-
drivers/mtd/nand/ndfc.c |1 +
drivers/mtd/nand/nomadik.c |1 +
drivers/mtd/nand/omap_gpmc.c|6 +-
drivers/mtd/nand/s3c2410_nand.c |1 +
drivers/mtd/nand/tegra_nand.c | 27 +-
drivers/mtd/nand/tegra_nand.h |2 +-
drivers/mtd/onenand/onenand_base.c | 82 +-
drivers/mtd/onenand/onenand_bbt.c |6 +-
drivers/mtd/ubi/build.c |2 +-
drivers/mtd/ubi/eba.c |2 +-
drivers/mtd/ubi/io.c| 12 +-
drivers/mtd/ubi/kapi.c |2 +-
drivers/mtd/ubi/misc.c |2 +-
drivers/mtd/ubi/vtbl.c |2 +-
fs/yaffs2/yaffs_mtdif.c | 18 +-
fs/yaffs2/yaffs_mtdif2.c| 14 +-
include/configs/P1022DS.h |2 -
include/linux/mtd/bbm.h | 49 +-
include/linux/mtd/mtd.h | 203 +++--
include/linux/mtd/nand.h| 173 ++--
include/linux/string.h |3 +
include/{linux = }/mtd/mtd-abi.h | 53 +-
include/nand.h | 11 +-
lib/string.c| 59 ++
48 files changed, 2307 insertions(+), 1731 deletions(-)
rename include/{linux = }/mtd/mtd-abi.h (65%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: exynos: make spl_boot common for all exynos based platforms
[1] http://www.mail-archive.com/u-boot at lists.denx.de/msg108301.html This gives 404 not found... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] ARM: add assembly routine to switch to non-secure state
On Fri, May 31, 2013 at 11:26:06AM +0200, Andre Przywara wrote: On 05/31/2013 05:04 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:46PM +0200, Andre Przywara wrote: While actually switching to non-secure state is one thing, the more important part of this process is to make sure that we still have full access to the interrupt controller (GIC). The GIC is fully aware of secure vs. non-secure state, some registers are banked, others may be configured to be accessible from secure state only. To be as generic as possible, we get the GIC memory mapped address based on the PERIPHBASE register. We check explicitly for ARM Cortex-A7 and A15 cores, assuming an A9 otherwise, as for those cores we know the offsets for the GIC CPU interface from the PERIPHBASE content. Other cores could be added as needed. With the GIC accessible, we: a) allow private interrupts to be delivered to the core (GICD_IGROUPR0 = 0x) b) enable the CPU interface (GICC_CTLR[0] = 1) c) set the priority filter to allow non-secure interrupts (GICC_PMR = 0x80) After having switched to non-secure state, we also enable the non-secure GIC CPU interface, since this register is banked. Also we allow access to all coprocessor interfaces from non-secure state by writing the appropriate bits in the NSACR register. For reasons obvious later we only use caller saved registers r0-r3. You probably want to put that in a comment in the code, and it would also be super helpful to explain the obvious part here, because most readers don't look forward in time to understand this patch... Agreed. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 47 ++ 1 file changed, 47 insertions(+) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index da48b36..e63e892 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -572,3 +572,50 @@ fiq: #endif /* CONFIG_USE_IRQ */ #endif /* CONFIG_SPL_BUILD */ + +#ifdef CONFIG_ARMV7_VIRT +/* Routine to initialize GIC CPU interface and switch to nonsecure state. + */ +.globl _nonsec_gic_switch +_nonsec_gic_switch: + mrc p15, 4, r2, c15, c0, 0 @ r2 = PERIPHBASE You should probably check if bits [7:0] == 0x00 here, otherwise you may end up doing some very strange stuff - if any of those bits are set you can just error out at this point, but it should be gracefully handled. Also since it's core specific, you'd probably want to check that before using it. As you found out later, I am doing this before calling this routine. But I will add a comment here to avoid confusion. yeah, or just expect that this address is in r0 upon calling the routine, then you're in the clear. + add r3, r2, #0x1000 @ GIC dist i/f offset Since this is core specific, could the offset please go in an appropriate header file? It will also eliminate the need for the comment if you just have a proper define (i.e. GIC_DIST_OFFSET ...) + mvn r1, #0 + str r1, [r3, #0x80] @ allow private interrupts Aren't you makeing an assumption about the number of available interrupts here? You should read the ITLinesNumber field from the GICD_TYPER if I'm not mistaking. This is the per core private interrupts. All bits should be implemented. From the GIC spec, chapter 4.3.4: In a multiprocessor implementation, GICD_IGROUPR0 is banked for each connected processor. This register holds the group status bits for interrupts 0-31. I understand it, but the comments or naming of the routine never suggested that this was the code that was called per-core. I really think that is the core objective of this function: The NS-init that each core must do, it's not really GIC specific, so I suggest you rename it. I also think it would be much cleaner if you again used a define for the 0x80 offset. Also, don't you need to set some enable fields on the GICD_CTLR here to enable group 1 interrupts? Since this a non-banked per-system register, I do this later in the C part. later in the patch series, before in the flow of the code, right? :) + + mrc p15, 0, r0, c0, c0, 0 @ MIDR + bfc r0, #16, #8 @ mask out variant, arch + bfc r0, #0, #4 @ and revision + movwr1, #0xc070 + movtr1, #0x4100 + cmp r0, r1 @ check for Cortex-A7 + orr r1, #0xf0 wow, nice bit fiddling. It may be quite a bit easier to read if you simply had defines for the bitmasks and real values and just did a load and placed a literal section accordingly. The sequence is necessary since we are short on registers. I agree it is a bit obfuscated, will make it more readable. yeah but: #define ARM_CORTEX_A15_ID 0x4100c070 .ltorg [...] ldr r0,
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
On Fri, May 31, 2013 at 11:23:16AM +0200, Andre Przywara wrote: On 05/31/2013 03:02 AM, Christoffer Dall wrote: Christoffer, thanks a lot for the thorough review. Comments inline. On Mon, May 06, 2013 at 03:17:45PM +0200, Andre Przywara wrote: A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state. Introduce a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM ARM this should not be done in SVC mode, so we have to setup a SMC handler for this. We reuse the current vector table for this and make sure that we only access the MVBAR register if the CPU supports the security extension and only if we configured the board to use it, since boards entering u-boot already in non-secure mode would crash on accessing MVBAR otherwise. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 31 --- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index e9e57e6..da48b36 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -155,6 +155,13 @@ reset: /* Set vector address in CP15 VBAR register */ ldr r0, =_start mcr p15, 0, r0, c12, c0, 0 @Set VBAR + +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r1, c0, c1, 1 @ check for security extension + andsr1, r1, #0x30 + mcrne p15, 0, r0, c12, c0, 1 @ Set secure monitor MVBAR Hmm, this smells a bit simplified to me. Support for ARMv7_VIRT should easy to integrate into u-boot even for platforms that do not boot U-boot directly into secure mode (OMAP5 GP platforms are such an example). In this case you cannot assume that you can write the secure monitor mvbar. Right, Albert kind of hinted on this already. I already fixed this in my private tree, totally removing these MVBAR writes here and instead copying the values from VBAR later just before we do the smc. Will send out a fixed version. +#endif + #endif /* the mask ROM code should have PLL and others stable */ @@ -257,6 +264,12 @@ ENTRY(c_runtime_cpu_setup) ldr r0, =_start mcr p15, 0, r0, c12, c0, 0 @Set VBAR +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r1, c0, c1, 1 @ check for security extension + andsr1, r1, #0x30 + mcrne p15, 0, r0, c12, c0, 1 @ Set secure monitor MVBAR +#endif + bx lr ENDPROC(c_runtime_cpu_setup) @@ -490,11 +503,23 @@ undefined_instruction: bad_save_user_regs bl do_undefined_instruction +/* + * software interrupt aka. secure monitor handler + * This is executed on a smc instruction, we use a smc #0 to switch + * to non-secure state + */ .align 5 software_interrupt: - get_bad_stack_swi - bad_save_user_regs - bl do_software_interrupt Why is the following block not conditional on CONFIG_ARMV7_VIRT? Again, it feels a bit funny to modify this generic mechanism to contain this code for boards that boot in NS mode but have a way to enter Hyp mode using an HVC or SMC instruction. software_interrupt is currently a panic routine. So it is not actually used by u-boot, it's just there to dump some state and eventually call reset_cpu(). Which is pretty useful to catch if something went wrong. So I feel that since I am now the only user of software_interrupt I don't need any special precautions and consider this routine now actually part of the HYP mode switcher. But of course I can retain the original functionality if CONFIG_ARMV7_VIRT is not defined. Yeah, I don't really think it's cool if a software interrupt happens somewhere completely else in the system that we do this dance, which could be super hard to detect, which is why I'm not even a fan of re-using the vector in the first place. + mrc p15, 0, r1, c1, c1, 0 @ read SCR + bic r1, r1, #0x07f + orr r1, r1, #0x31 @ enable NS, AW, FW Are you sure you want to always route FIQ to non-secure here? Since we actually don't install any secure software and just use the secure state to do the HYP switch I don't feel like we should restrict FIQ. Since we don't use it for our own purposes, no one would be able to use it then, right? So my idea was to allow as much as possible. Yeah, makes sense. Don't you need to set the HCE bit? The whole register resets to 0register resets to zero. This is added later in 5/6. For reviewing purposes I split the patches up to do the non-secure switch only first. Later I add the bits to actually go to HYP mode. The splitting of patches is fine, but it would be helpful to explain the scope a little more in the commit text perhaps, maybe I'm just being silly. + + mrc p15, 0, r0, c12, c0, 0 @ save secure copy of VBAR + mcr p15, 0, r1, c1, c1,
Re: [U-Boot] [PATCH 0/6] ARMv7: Add HYP mode switching support
On Fri, May 31, 2013 at 08:36:12AM +0200, Andre Przywara wrote: On 05/31/2013 08:11 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:44PM +0200, Andre Przywara wrote: (for GIT URL and Changelog see below) ARM CPUs with the virtualization extension have a new mode called HYP mode, which allows hypervisors to safely control and monitor guests. The current hypervisor (KVM and Xen) implementations require the kernel to be entered in that HYP mode. This patch series introduces a configuration variable CONFIG_ARMV7_VIRT which enables code to switch all cores into HYP mode. This is done automatically during execution of the bootm command (but could also be done earlier - U-Boot runs fine in HYP mode without MMU usage). I forget the u-boot specifics here, but if you boot over networking, for example, does that eventually end up calling bootm or would Hyp mode not be entered in this case? Despite the naming bootm is eventually always called when booting Linux, even bootz is a wrapper around this. Same with network boot. So unless you show me a case where this isn't, I think this is fine. Cool, I have no idea, I just wanted to be sure. Thanks, -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] ARM: switch to non-secure state during bootm execution
On Fri, May 31, 2013 at 11:30:32AM +0200, Andre Przywara wrote:
On 05/31/2013 07:10 AM, Christoffer Dall wrote:
On Mon, May 06, 2013 at 03:17:47PM +0200, Andre Przywara wrote:
To actually trigger the non-secure switch we just implemented, call
the switching routine from within the bootm command implementation.
This way we automatically enable this feature without further user
intervention.
Some part of the work is done in the assembly routine in start.S,
introduced with the previous patch, but for the full glory we need
to setup the GIC distributor interface once for the whole system,
which is done in C here.
The routine is placed in arch/arm/lib to allow easy access from
different boards or CPUs.
I'm beginning to loose track of exactly which parts is in assembly and
which parts are in C, and why. We are fiddling with some gic dist.
settings in assembly, and some of them in C as well.
I fear I dropped the explanation some time during a patch split earlier.
So the assembly code is the per core part - including GICD_IGROUPR0,
which is banked per core. The reason this is in assembly is to make
it easily run right out of the SMP pen.
In C I do anything that needs to be only done once for the whole system.
More comments inline...
I think renaming the assembly routine will go a along way. Ordering
this patch before the assembly patch with just a stub function
implementation may also have been easier to read, but that's easy for me
to say at this point.
I think it's just the ordering or naming of the patches that is a little
confusing.
First we check for the availability of the security extensions.
The generic timer base frequency register is only accessible from
secure state, so we have to program it now. Actually this should be
done from primary firmware before, but some boards seems to omit
this, so if needed we do this here with a board specific value.
Since we need a safe way to access the GIC, we use the PERIPHBASE
registers on Cortex-A15 and A7 CPUs and do some sanity checks.
Then we actually do the GIC enablement:
a) enable the GIC distributor, both for non-secure and secure state
(GICD_CTLR[1:0] = 11b)
b) allow all interrupts to be handled from non-secure state
(GICD_IGROUPRn = 0x)
The core specific GIC setup is then done in the assembly routine.
The actual bootm trigger is pretty small: calling the routine and
doing some error reporting. A return value of 1 will be added later.
To enable the whole code we introduce the CONFIG_ARMV7_VIRT variable.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
arch/arm/include/asm/armv7.h | 7 +++
arch/arm/lib/Makefile| 2 +
arch/arm/lib/bootm.c | 20
arch/arm/lib/virt-v7.c | 113
+++
4 files changed, 142 insertions(+)
create mode 100644 arch/arm/lib/virt-v7.c
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index a73630b..25afffe 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -74,4 +74,11 @@ void v7_outer_cache_inval_all(void);
void v7_outer_cache_flush_range(u32 start, u32 end);
void v7_outer_cache_inval_range(u32 start, u32 end);
+#ifdef CONFIG_ARMV7_VIRT
+int armv7_switch_nonsec(void);
+
+/* defined in cpu/armv7/start.S */
+void _nonsec_gic_switch(void);
+#endif /* CONFIG_ARMV7_VIRT */
+
#endif
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 6ae161a..37a0e71 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -58,6 +58,8 @@ COBJS-y += reset.o
COBJS-y += cache.o
COBJS-y += cache-cp15.o
+COBJS-$(CONFIG_ARMV7_VIRT) += virt-v7.o
+
SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
$(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index f3b30c5..a3d3aae 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -35,6 +35,10 @@
#include asm/bootm.h
#include linux/compiler.h
+#ifdef CONFIG_ARMV7_VIRT
+#include asm/armv7.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_SETUP_MEMORY_TAGS) || \
@@ -319,6 +323,22 @@ static void boot_prep_linux(bootm_headers_t *images)
hang();
#endif /* all tags */
}
+#ifdef CONFIG_ARMV7_VIRT
+ switch (armv7_switch_nonsec()) {
+ case 0:
+ debug(entered non-secure state\n);
+ break;
+ case 2:
+ printf(HYP mode: Security extensions not implemented.\n);
+ break;
+ case 3:
+ printf(HYP mode: CPU not supported (must be Cortex-A15 or
A7).\n);
I would drop the specifics of what's supported here.
This is in particular here since I rely on the PERIPHBASE register,
which is A15/A7 implementation specific. This is different from case
2 (which will later be changed to Virtualization
Re: [U-Boot] [PATCH 5/6] ARM: extend non-secure switch to also go into HYP mode
On Fri, May 31, 2013 at 11:34:38AM +0200, Andre Przywara wrote: On 05/31/2013 07:43 AM, Christoffer Dall wrote: On Mon, May 06, 2013 at 03:17:49PM +0200, Andre Przywara wrote: For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in the exception vector table. In the assembly switching routine - which we rename to hyp_gic_switch on the way - we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only adds and adjusts some error reporting. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/start.S | 34 +++--- arch/arm/include/asm/armv7.h | 4 ++-- arch/arm/lib/bootm.c | 12 +--- arch/arm/lib/virt-v7.c | 22 +++--- 4 files changed, 49 insertions(+), 23 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 02234c7..921e9d9 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -41,7 +41,7 @@ _start: b reset ldr pc, _software_interrupt ldr pc, _prefetch_abort ldr pc, _data_abort - ldr pc, _not_used + ldr pc, _hyp_trap ldr pc, _irq ldr pc, _fiq #ifdef CONFIG_SPL_BUILD @@ -49,7 +49,7 @@ _undefined_instruction: .word _undefined_instruction _software_interrupt: .word _software_interrupt _prefetch_abort: .word _prefetch_abort _data_abort: .word _data_abort -_not_used: .word _not_used +_hyp_trap: .word _hyp_trap _irq: .word _irq _fiq: .word _fiq _pad: .word 0x12345678 /* now 16*4=64 */ @@ -58,7 +58,7 @@ _undefined_instruction: .word undefined_instruction _software_interrupt: .word software_interrupt _prefetch_abort: .word prefetch_abort _data_abort: .word data_abort -_not_used: .word not_used +_hyp_trap: .word hyp_trap _irq: .word irq _fiq: .word fiq _pad: .word 0x12345678 /* now 16*4=64 */ @@ -513,12 +513,18 @@ software_interrupt: mrc p15, 0, r1, c1, c1, 0 @ read SCR bic r1, r1, #0x07f orr r1, r1, #0x31 @ enable NS, AW, FW + mrc p15, 0, r0, c0, c1, 1 @ check for Virt ext + and r0, r0, #0xf000 + cmp r0, #0x1000 you can just do ands r0, r0 ,#0xf000 and change the orreq below to orrne Can I? But I want to make sure that Virt ext is of version 1 only, anything beyond that I cannot reliably support, right? Or is there a guarantee that this is backwards compatible? In the ARMv7 specifications it mentions either 1 or 0 as the possible values of this field, and doesn't say anything about reserved values iirc, but maybe that shouldn't be taken that literally. Just keep the code as it is then. + orreq r1, r1, #0x100 @ allow HVC instruction mrc p15, 0, r0, c12, c0, 0 @ save secure copy of VBAR mcr p15, 0, r1, c1, c1, 0 @ write SCR, switch to non-sec isb mcr p15, 0, r0, c12, c0, 0 @ write non-secure copy of VBAR + mcreq p15, 4, r0, c12, c0, 0 @ write HYP mode HVBAR + nit: s/HYP mode// movspc, lr .align 5 @@ -534,10 +540,9 @@ data_abort: bl do_data_abort .align 5 -not_used: - get_bad_stack - bad_save_user_regs - bl do_not_used +hyp_trap: + .byte 0x00, 0xe3, 0x0e, 0xe1@ mrs lr, elr_hyp do we really need to support this on assemblers that old? What do you mean with old? I can check again, but I think it didn't work with my self-compiled binutils 2.23. Or do I need a directive to enable this? You need a directive, see the Makefile in arch/arm/kvm/Makefile and the corresponding source files in the kernel. + mov pc, lr #ifdef CONFIG_USE_IRQ @@ -574,21 +579,21 @@ fiq: #endif /* CONFIG_SPL_BUILD */ #ifdef CONFIG_ARMV7_VIRT -/* Routine to initialize GIC CPU interface and switch to nonsecure state. - * Will be executed directly by secondary CPUs after coming out of +/* Routine to initialize GIC CPU interface, switch to nonsecure and to HYP + * mode. Will be executed directly by secondary CPUs after coming out of
Re: [U-Boot] [PATCH 4/6] ARM: add SMP support for non-secure switch
On Fri, May 31, 2013 at 11:32:40AM +0200, Andre Przywara wrote:
On 05/31/2013 07:32 AM, Christoffer Dall wrote:
On Mon, May 06, 2013 at 03:17:48PM +0200, Andre Przywara wrote:
Currently the non-secure switch is only done for the boot processor.
To later allow full SMP support, we have to switch all secondary
cores into non-secure state also.
So we add an entry point for secondary CPUs coming out of low-power
state and make sure we put them into WFI again after having switched
to non-secure state.
For this we acknowledge and EOI the wake-up IPI, then go into WFI.
Once being kicked out of it later, we sanity check that the start
address has actually been changed (since another attempt to switch
to non-secure would block the core) and jump to the new address.
The actual CPU kick is done by sending an inter-processor interrupt
via the GIC to all CPU interfaces except the requesting processor.
The secondary cores will then setup their respective GIC CPU
interface.
The address secondary cores jump to is board specific, we provide
the value here for the Versatile Express board.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
arch/arm/cpu/armv7/start.S | 27 ++-
arch/arm/include/asm/armv7.h| 1 +
arch/arm/lib/virt-v7.c | 9 -
include/configs/vexpress_ca15_tc2.h | 1 +
4 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index e63e892..02234c7 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -575,8 +575,19 @@ fiq:
#ifdef CONFIG_ARMV7_VIRT
/* Routine to initialize GIC CPU interface and switch to nonsecure state.
+ * Will be executed directly by secondary CPUs after coming out of
+ * WFI, or can be called directly by C code for CPU 0.
+ * Those two paths mandate to not use any stack and to only use registers
+ * r0-r3 to comply with both the C ABI and the requirement of SMP startup
+ * code.
*/
.globl _nonsec_gic_switch
+.globl _smp_pen
+_smp_pen:
+ mrs r0, cpsr
+ orr r0, r0, #0xc0
+ msr cpsr, r0@ disable interrupts
+ mov lr, #0 @ clear LR to mark secondary
instead of this subtle abuse of lr, why not make this routine simply
take a parameter?
How would this work if this is called out of SMP pen? Shall I rely on
the registers being zero, then? Not very stable, I guess.
I think this whole routine is special anyways, so I felt this subtle
abuse is OK.
An option would be to set r0 to 1 in the smp_pen path and pass 0 as the
first parameter when calling from C. But then I'd need to save this
value - possibly in the LR register ;-)
see my example in the previous patch comments, I don't see why using the
lr like this makes anything anymore clear or more stable?
I also slightly object against wrapping the _smp_pen around the
_nonsec_gic_switch, I really think these are separate routines, where
one can just call the other...?
The actual routine and the purpose are the same, just the entry and exit
code is different. So this fitted nicely in here. I can add a more
specific comment on the different entry points.
eh, to me it reads kind of like this C function (but maybe I just choked
on this somehow):
void do_magic(bool mode)
{
if (mode) {
pull_rabit_out_of_hat();
do_card_trick();
}
saw_a_woman_in_half(); /* we always do this */
linking_rings();
if (!mode)
return;
while (1) {
vanish_statue_of_liberty();
walk_through_great_wall_of_china();
}
}
_nonsec_gic_switch:
mrc p15, 4, r2, c15, c0, 0 @ r2 = PERIPHBASE
add r3, r2, #0x1000 @ GIC dist i/f offset
@@ -617,5 +628,19 @@ _nonsec_gic_switch:
add r2, r2, #0x1000 @ GIC dist i/f offset
str r1, [r2]@ allow private interrupts
- mov pc, lr
+ cmp lr, #0
+ movne pc, lr @ CPU 0 to return
+ @ all others: go to sleep
+_ack_int:
+ ldr r1, [r3, #0x0c] @ read GICD acknowledge
+ str r1, [r3, #0x10] @ write GICD EOI
+
+ adr r1, _smp_pen
+waitloop:
+ wfi
+ ldr r0, =CONFIG_SYSFLAGS_ADDR @ load start address
+ ldr r0, [r0]
+ cmp r0, r1 @ make sure we dont execute this code
I think I raised this issue previously, but this code is in a core
u-boot file, but I could imagine a board with a different crazy boot
protocol that required you to check two different fields and jump
through other hoops to wake up from the smp pen, so I really think the
whole smp pen belongs in a
