[U-Boot] праздник стоит у дверей
Добрый день, Стремитесь ли Вы приумножать свои доходы или просто хотите преодолеть финансовые проблемы? Можете ли Вы исполнять свои желания, не ограничивая себя в финансах или это сложно для Вас? Не упустите шанс реализовать свои мечты! - Абсолютно бесплатно и гарантированно - Для каждого подходит - Не выходя из дома Если Вы искали возможность зарабатывать побочно хорошие деньги, тогда Вы должны посетить мой сайт. Если Вы начнете сейчас, Вы заработаете деньги еще сегодня. - Никакого риска - Никаких данных не нужно (только Ваше имя) Нажмите просто здесь: Если хотите узнать, как это работает нажмите здесь Я рад Вашему посещению. Александр Воропаев ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Thursday 16 June 2011 10:15 PM, Scott Wood wrote: On Thu, 16 Jun 2011 13:38:00 +0530 Aneesh Vane...@ti.com wrote: New Design Proposed by Wolfgang: * Have a top-level Makefile in the SPL root-directory - for instance 'nand_spl/Makefile' * nand_spl/Makefile builds a generic library with the generic source files at this level. What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. A crude form of this is what I had done in my patch-set. OMAP4 SDP and OMAP4 Panda Makefiles were identical because there was no board specific content. So, I moved them into an omap4.mk and rules.mk and included these two files from the board level Makefiles. But Wolfgang apparently didn't like this because I was having board level Makefile despite not having any board specific content. I still believe that extending this to more granular re-usable components such as mmc.mk, nand.mk, console.mk, fat.mk etc may be a less disruptive but effective solution. And no, I don't think we can get rid of building the objects separately, and I don't want a situation where #ifdef NAND_SPL is honored in some files but not others. Agree. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Friday 17 June 2011 03:39 AM, Wolfgang Denk wrote: Dear Scott Wood, In message20110616114556.7d3c2...@schlenkerla.am.freescale.net you wrote: What is a generic SPL library, or even a generic NAND SPL library? There is no code that is shared by all NAND SPLs. The files directly under nand_spl/ are alternatives that the board makefile can choose. I think there is tons of duplicated code that could and should be extraced into common directories. Counterproposal: keep the basic structure the same, but refactor the makefiles so that they use a common template but supply their own policy. That is, the board makefile would just set some variables to be lists of objects it's interested in (and any other relevant tunables, or special rules), and then include the common SPL makefile that will do all the symlinking and building. Or put this from the head on it's feet and use a board specific config.mk which gets included by the SPL makefile? And also 'config.mk's that are SoC specific, CPU specific etc? Otherwise the board specific config.mk will still duplicate SoC and CPU content. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] about at91 board in uboot
Dear Lin, The following is the status XU Hong is reporting to me on u-boot-atmel/master. I saw it has been silent for 2 days. I don’t know if we could do something to help maintain all the boards. I will try to help allocate some of my people to handling missing parts for our EK. I send a message about 2 days ago, asking that the SoC relevant parts are changed in a manner consistent with the changes for the 9260, like in at91sam9260_devices.c, at91sam9260.h, at91sam9260_matrix.h. Once that is done, and added to u-boot-atmel/master, the board specific patches should be rebased on that and submitted. Since nobody did volunteer so far, I was going to edit the SoC specific parts and submit them, but unfortunately that could take some time (until next week maybe, I was going to start today with that, but have paid work to finish as well :) ) I am not fond of quick and dirty solutions here, the boards are not going to be removed with this u-boot release, but will be after if no progress is seen - but we do have progress here - so no need to panic. So lets do it in two distinct steps: 1. fix SoCs 2. fix boards 9261 soc ek have been merged to atmel branch. 9rl – v3 patches have been pushed out just now and shall be ok. 9263 – soc part has been merged into atmel branch. I’m asking the ek part. 9g45 - patches were sent by 3rd party. The SoC specific changes will/should be based before those patches, and will replace the current ones. --- Original Message: Dear Friends, I have received several different patches reworking at91sam*_devices.c and at91sam9*.h. Lokking at them, none of them is completely done the way the files for at91sam9260 are done. Examples: 9260, 9263: ATMEL_ID_USART0 9261: ATMEL_ID_US0 9260 uses the CONFIG_AT91_GPIO_PULLUP define, the others do not. 9261 still uses the CONFIG_USARTx defines. Please have a look at at91sam9260 as a reference. We do need a properly fixed SoC port for 9261, 9263 and the others before individual board ports can be fixed. Just because there is a sudden rush to get things fixed for the next release should NOT tempt us to get in interim versions. With Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MMC: add marvell sdhci driver
-Original Message-
From: Lei Wen [mailto:lei...@marvell.com]
Sent: Thursday, June 16, 2011 8:48 PM
To: Andy Fleming; Rob Herring; u-boot@lists.denx.de; Prafulla Wadaskar;
Yu Tang; Prabhanjan Sarnaik; Ashish Karkare
Subject: [PATCH 2/2] MMC: add marvell sdhci driver
This could support both armada100 and pantheon serial in the mainline,
while this driver also be tested to support upcoming mg, mmp2 and mmp3
hardware.
Signed-off-by: Lei Wen lei...@marvell.com
---
drivers/mmc/Makefile |1 +
drivers/mmc/sdhci-mv.c | 21 +
The file name should be mv_sdhci.c
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/sdhci-mv.c
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 50b5117..fd84389 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_OMAP_HSMMC) += omap_hsmmc.o
COBJS-$(CONFIG_PXA_MMC) += pxa_mmc.o
COBJS-$(CONFIG_S5P_MMC) += s5p_mmc.o
COBJS-$(CONFIG_SDHCI) += sdhci.o
+COBJS-$(CONFIG_SDHCI_MV) += sdhci-mv.o
Same here CONFIG_MV_SDHCI
COBJS:= $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/mmc/sdhci-mv.c b/drivers/mmc/sdhci-mv.c
new file mode 100644
index 000..97d79ee
--- /dev/null
+++ b/drivers/mmc/sdhci-mv.c
@@ -0,0 +1,21 @@
+#include common.h
+#include malloc.h
+#include sdhci.h
+
+static char *MVSDH_NAME = sdh-mv;
mv_sdhci sounds better.
Regards..
Prafulla . .
+int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
+{
+ struct sdhci_host *host = NULL;
+ host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
+ if (!host) {
+ printf(sdh_host malloc fail!\n);
+ return 1;
+ }
+
+ host-name = MVSDH_NAME;
+ host-ioaddr = (void *)regbase;
+ host-quirks = quirks;
+ host-version = sdhci_readw(host, SDHCI_HOST_VERSION);
+ add_sdhci(host, max_clk, min_clk);
+ return 0;
+}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD Ultimate SATA SD
-Original Message- From: Philip Hands [mailto:p...@hands.com] Sent: Friday, June 17, 2011 1:33 AM To: Alexei Ozhigov Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] OpenRD Ultimate SATA SD On Thu, 16 Jun 2011 16:18:46 +0400, Alexei Ozhigov alexei.ozhi...@gmail.com wrote: ... I am experiencing the same problem with SATA right now with v2011.06-rc2 (tried also the latest master). If MVSATA_STATUS_TIMEOUT in mvsata_ide_initialize_port is ignored, SATA drive is found on the second port and I am able to read the drive's content. Inspired by what you say about timeouts, I thought perhaps increasing the timeout from 10ms to 1s might make a difference -- that worked! ... except that now, it's working regardless :-( So, I've no idea if that's really related to what's going on, because I've now gone as far as reducing the timeout to 5ms and it's _still_ working fine, so perhaps some part of the SATA subsystem was in a state that was somehow reset by waiting a bit longer for the startup once, and that's somehow fixed it. It is still working despite powering down the machine for a while, so I'm guessing whatever changed is something to do with the state of the hard drive. Sadly that means that I've now lost the ability to test this, since trying any of the versions that were previously failing now work. Anyway, Alexei, try increasing the timeout (i.e. the value being assigned to timeleft) --- if that works for you too, it seems pretty harmless, so might be appropriate for wider adoption. Copying to Albert and Michael the contributor for mvsata code. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] about at91 board in uboot
Hi Reinhard, On 06/17/2011 03:17 PM, Reinhard Meyer wrote: Dear Lin, The following is the status XU Hong is reporting to me on u-boot-atmel/master. I saw it has been silent for 2 days. I don’t know if we could do something to help maintain all the boards. I will try to help allocate some of my people to handling missing parts for our EK. I send a message about 2 days ago, asking that the SoC relevant parts are changed in a manner consistent with the changes for the 9260, like in at91sam9260_devices.c, at91sam9260.h, at91sam9260_matrix.h. Yes, we noticed that. And the patches we sent out are divided into 2 parts, one for SoC and one for EK (boards). We noticed the SoC part of SAM9263 has been merged, but EK part is not. I've already sent out an email about this but no response yet. For SAM9RL, V3 patches (SoC part and EK part) have been sent out days ago according to your comments. But, no response yet. We're sure we can not totally 100% understand all of your concerns. But we can talk with the code and finally reach the same point. Thanks for your understanding. BR, Hong Once that is done, and added to u-boot-atmel/master, the board specific patches should be rebased on that and submitted. Since nobody did volunteer so far, I was going to edit the SoC specific parts and submit them, but unfortunately that could take some time (until next week maybe, I was going to start today with that, but have paid work to finish as well :) ) I am not fond of quick and dirty solutions here, the boards are not going to be removed with this u-boot release, but will be after if no progress is seen - but we do have progress here - so no need to panic. So lets do it in two distinct steps: 1. fix SoCs 2. fix boards 9261 soc ek have been merged to atmel branch. 9rl – v3 patches have been pushed out just now and shall be ok. 9263 – soc part has been merged into atmel branch. I’m asking the ek part. 9g45 - patches were sent by 3rd party. The SoC specific changes will/should be based before those patches, and will replace the current ones. --- Original Message: Dear Friends, I have received several different patches reworking at91sam*_devices.c and at91sam9*.h. Lokking at them, none of them is completely done the way the files for at91sam9260 are done. Examples: 9260, 9263: ATMEL_ID_USART0 9261: ATMEL_ID_US0 9260 uses the CONFIG_AT91_GPIO_PULLUP define, the others do not. 9261 still uses the CONFIG_USARTx defines. Please have a look at at91sam9260 as a reference. We do need a properly fixed SoC port for 9261, 9263 and the others before individual board ports can be fixed. Just because there is a sudden rush to get things fixed for the next release should NOT tempt us to get in interim versions. With Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10] Add support for Network Space v2 and parents
Hi Prafulla and Mike, On Fri, Jun 17, 2011 at 12:42:16AM -0700, Prafulla Wadaskar wrote: -Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Friday, June 17, 2011 5:47 AM To: u-boot@lists.denx.de Cc: Simon Guinot; Prafulla Wadaskar Subject: Re: [U-Boot] [PATCH v10] Add support for Network Space v2 and parents On Wednesday, June 15, 2011 10:39:53 Simon Guinot wrote: Hi Prafulla, please dont top post It appears that this v10 patch is also wrong. The specified email encoding is UTF-8. It should be ISO-8859-1 which is the MAINTAINERS file encoding. It is the reason why the patch is discarded by patchwork. Please note that the patch diff is correct. The patch applies correctly using git-am. Let me know if a v11 is needed ? if it isnt making it to the mailing list, then yes. i didnt actually see any v10 patch hit the mailing list, and i dont think that has anything to do with encoding or patchwork. Hi Simon. Yes, even I could not see the v10 patch. I think you should send v11 in sync with rebased u-boot-marvell.git Accordlingly to u-boot mailing list archive, you should have received v10: http://lists.denx.de/pipermail/u-boot/2011-June/094283.html But OK, let's go for a v11. Regards, Simon signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD Ultimate SATA SD
2011/6/17 Prafulla Wadaskar prafu...@marvell.com: -Original Message- From: Philip Hands [mailto:p...@hands.com] Sent: Friday, June 17, 2011 1:33 AM To: Alexei Ozhigov Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] OpenRD Ultimate SATA SD On Thu, 16 Jun 2011 16:18:46 +0400, Alexei Ozhigov alexei.ozhi...@gmail.com wrote: ... I am experiencing the same problem with SATA right now with v2011.06-rc2 (tried also the latest master). If MVSATA_STATUS_TIMEOUT in mvsata_ide_initialize_port is ignored, SATA drive is found on the second port and I am able to read the drive's content. Inspired by what you say about timeouts, I thought perhaps increasing the timeout from 10ms to 1s might make a difference -- that worked! ... except that now, it's working regardless :-( So, I've no idea if that's really related to what's going on, because I've now gone as far as reducing the timeout to 5ms and it's _still_ working fine, so perhaps some part of the SATA subsystem was in a state that was somehow reset by waiting a bit longer for the startup once, and that's somehow fixed it. It is still working despite powering down the machine for a while, so I'm guessing whatever changed is something to do with the state of the hard drive. Sadly that means that I've now lost the ability to test this, since trying any of the versions that were previously failing now work. Anyway, Alexei, try increasing the timeout (i.e. the value being assigned to timeleft) --- if that works for you too, it seems pretty harmless, so might be appropriate for wider adoption. I have already tried longer timeouts for timeleft and it does not help. Also with timeout circumvention the SATA flash card I was hoping to boot from (Transcend TS1GSDOM22V) is identified as follows: Bus 0: OK Bus 1: OK Device 0: Model: TRANSCEND Firm: 20080128 Ser#: 200804070005 Type: Hard Disk Capacity: 955.8 MB = 0.9 GB (1957536 x 512) IDE read: device 0 not ready IDE read: device 0 not ready Device 1: Model: Firm: Ser#: Type: Hard Disk Capacity: not available And then the card cannot be read. First attempt shows OK although the data written to memory are wrong, next attempts result in device 0 not ready. On the other hand, Linux (Debian ARM port) does not recognize the card either. So if this problem is not related to improper initialization, the question is how SATA flash differs from regular SATA drives with respect to SATA controller in 88F6281 and if it is actually possible to work with SATA flash on OpenRD. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uncompressed uImages
Hi Mike, Thanks for the reply. if it's uncompressed, why not simply load it to the final address in the first place ? then bootm wont have to do any memcpy, it can simply jump to the entry point. In our system we use a software update mechanism where the kernel + initfs images reside in a 'package' in NAND which gets downloaded to ram first by an initial loader so that it can be verified (CRC + a cryptographic hash). This means that the sections containing the kernel are already in RAM somewhere other than the load address...! Admittedly, the mechanism could have been designed so that taking headers into account the uImage was always at a known offset but this wasn't the way it was designed unfortunately. Cheers, ~Pev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uncompressed uImages
Hi Wolfgang,
Thanks for the reply!
Why using such an odd address as 0x8055b728?
That is a symptom of the system I'm working on...!
Just follow the rules and never download the image to an address range
that overlaps with the area where the image will be unpacked / loaded
to.
I'd wondered if that was the case originally and tested this by
changing the download address to +32MB higher. This behaved with
exactly the same failure so I think that while it's a more sensible
thing to do it's a red herring with regards to what I'm seeing with
the memmove().
Please be aware that is just 365 KB above your load address, and I
guess your kernel image is way bigger than 365 KB.
Yep, I'm aware of this but I'm not keen to meddle too much with an
existing working system! Despite it being a bit dubious (and most
likely a failure if a compressed image) it works due to the way that
for uncompressed images memmove_wd() is implemented in that it copies
in smallish chunks and hence doesn't overwrite itself.
This actually copies the image 'payload' instead of the whole uImage
thereby dropping 64 bytes from the front of the copy and moving the
entry point. (I've verified this by breaking into the process and
It does not move the entry point. The entry point address is a
constant address and does never move.
If I add some debugging, I find that in the situation previously
mentioned (and equivalently if I download higher too, see above) what
happens is that in bootm_load_os() I find that at the point we reach
the memmove_wd() to move the uncompressed image :
load_start = 0x8055b798
image_len = 0x4c11c0
blob_start = 0x8055b758
blob_end = 0x80a1c958
because the memmove_wd() is called to copy to load_start, as you can
see this copies from 64 bytes above the start of the uImage. Because
of this the whole image shifts down by 64 bytes relative to the
loadaddr compared to if we'd manually downloaded the uImage to the
load address (Also, note the value of image len - the actual size of
the uImage is 0x4c1200 - i.e. the same as blob_end - blob_start)
This logic looks like :
if (load == blob_start) {
printf ( XIP %s ... , type_name);
} else {
printf ( Loading %s ... , type_name);
memmove_wd ((void *)load, (void *)image_start,
image_len, CHUNKSZ);
}
The logic here checks (load == blob_start) for XIP i.e. that the blob
state resides at the load address. Following this logic in isolation,
why does the memmove_wd() move the image to image_start instead of
blob_start if we want that to be at loadaddr as in the first check for
XIP? My understanding is that after this logic the uImage should
reside at exactly the same location whether you have followed either
the if or the else path...?
Having said that, I just checked one of our non mips boards (ARM1176)
and it seems to handle this same situation OK so I'm wondering if it's
something peculiar to the port we're working with or perhaps the MIPS
code...? My guess is that maybe it's something kernel related rather
than in u-boot.
Cheers,
~Pev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v11] Add support for Network Space v2 and parents
This patch add support for the Network Space v2 board and parents, based
on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
and Internet Space v2.
Additional information is available at:
http://lacie-nas.org/doku.php?id=network_space_v2
Signed-off-by: Simon Guinot sgui...@lacie.com
---
Changes for v2:
- add entries to MAINTAINERS file
- move boards from root Makefile to boards.cfg
- move MACH_TYPE definition into netspace_v2.h
- remove CONFIG_SYS_HZ redefinition
- turn PHY initialization message into debug()
Changes for v3: none
Changes for v4:
- enhance commit message: add SoC information
Changes for v5: none
Changes for v6:
- enable device tree support
- clean some #define in netspace_v2.h
- enhance commit message: provide description URL and mention SoC
family
- rebase against u-boot-{arm,marvell}/master branches
Changes for v7:
- rebase against u-boot-marvell/master branch
Changes for v8:
- update commit title (add netspace_v2 parents information).
- move GPIO button definition into header file.
- update CONFIG_IDENT_STRING with boards alias.
- handle wrong board definition.
- by default, use DHCP to get IP address.
Changes for v9:
- rebase against u-boot-marvell/master branch
Changes for v10:
- rebase against u-boot-marvell/master branch
Changes for v11:
- rebase against u-boot-marvell/next branch
- set email encoding to ISO-8859-1
MAINTAINERS |6 +
board/LaCie/netspace_v2/Makefile | 49 ++
board/LaCie/netspace_v2/kwbimage.cfg | 162 +
board/LaCie/netspace_v2/netspace_v2.c | 142 +
board/LaCie/netspace_v2/netspace_v2.h | 42 +
boards.cfg|3 +
include/configs/netspace_v2.h | 162 +
7 files changed, 566 insertions(+), 0 deletions(-)
create mode 100644 board/LaCie/netspace_v2/Makefile
create mode 100644 board/LaCie/netspace_v2/kwbimage.cfg
create mode 100644 board/LaCie/netspace_v2/netspace_v2.c
create mode 100644 board/LaCie/netspace_v2/netspace_v2.h
create mode 100644 include/configs/netspace_v2.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 653c928..0de32d3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -647,6 +647,12 @@ Sedji Gaouaousedji.gaou...@atmel.com
at91sam9g10ek ARM926EJS (AT91SAM9G10 SoC)
at91sam9m10g45ekARM926EJS (AT91SAM9G45 SoC)
+Simon Guinot simon.gui...@sequanux.org
+
+ inetspace_v2ARM926EJS (Kirkwood SoC)
+ netspace_v2 ARM926EJS (Kirkwood SoC)
+ netspace_max_v2 ARM926EJS (Kirkwood SoC)
+
Marius Gröger m...@sysgo.de
impa7 ARM720T (EP7211)
diff --git a/board/LaCie/netspace_v2/Makefile b/board/LaCie/netspace_v2/Makefile
new file mode 100644
index 000..a245f2c
--- /dev/null
+++ b/board/LaCie/netspace_v2/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2011 Simon Guinot sgui...@lacie.com
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := netspace_v2.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/LaCie/netspace_v2/kwbimage.cfg
b/board/LaCie/netspace_v2/kwbimage.cfg
new file mode 100644
index 000..361feeb
--- /dev/null
+++ b/board/LaCie/netspace_v2/kwbimage.cfg
@@ -0,0 +1,162 @@
+#
+# Copyright (C) 2011 Simon Guinot sgui...@lacie.com
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of
[U-Boot] [PATCH v4 3/9] armv7: rename cache related CONFIG flags
Replace the cache related CONFIG flags with more meaningful
names. Following are the changes:
CONFIG_L2_OFF- CONFIG_SYS_L2CACHE_OFF
CONFIG_SYS_NO_ICACHE - CONFIG_SYS_ICACHE_OFF
CONFIG_SYS_NO_DCACHE - CONFIG_SYS_DCACHE_OFF
Signed-off-by: Aneesh V ane...@ti.com
V2:
* Changed CONFIG_L2_OFF - CONFIG_SYS_NO_L2CACHE
V4:
* Changed all three flags to the final names suggested as above
and accordingly changed the commit message
---
arch/arm/cpu/arm1136/start.S|4 ++--
arch/arm/cpu/armv7/cpu.c|3 ---
arch/arm/include/asm/global_data.h |2 +-
arch/arm/lib/Makefile |2 --
arch/arm/lib/board.c|2 +-
arch/arm/lib/cache-cp15.c |6 +++---
board/armltd/integrator/split_by_variant.sh |8
common/cmd_bdinfo.c |2 +-
include/configs/B2.h|3 ++-
include/configs/assabet.h |2 +-
include/configs/ca9x4_ct_vxp.h |2 +-
include/configs/cerf250.h |2 +-
include/configs/cradle.h|2 +-
include/configs/csb226.h|2 +-
include/configs/dnp1110.h |2 +-
include/configs/efikamx.h |2 +-
include/configs/evb4510.h |3 ++-
include/configs/gcplus.h|2 +-
include/configs/innokom.h |2 +-
include/configs/jornada.h |2 +-
include/configs/lart.h |2 +-
include/configs/lubbock.h |2 +-
include/configs/mx51evk.h |2 +-
include/configs/mx53evk.h |2 +-
include/configs/omap4_panda.h |2 +-
include/configs/omap4_sdp4430.h |2 +-
include/configs/pleb2.h |2 +-
include/configs/pxa255_idp.h|2 +-
include/configs/s5pc210_universal.h |2 +-
include/configs/shannon.h |2 +-
include/configs/tegra2-common.h |2 +-
include/configs/trizepsiv.h |2 +-
include/configs/vision2.h |2 +-
include/configs/xaeniax.h |2 +-
include/configs/xm250.h |2 +-
include/configs/zylonite.h |2 +-
36 files changed, 42 insertions(+), 45 deletions(-)
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 3c5f3ef..200a800 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -512,10 +512,10 @@ fiq:
.align 5
.global arm1136_cache_flush
arm1136_cache_flush:
-#if !defined(CONFIG_SYS_NO_ICACHE)
+#if !defined(CONFIG_SYS_ICACHE_OFF)
mcr p15, 0, r1, c7, c5, 0 @ invalidate I cache
#endif
-#if !defined(CONFIG_SYS_NO_DCACHE)
+#if !defined(CONFIG_SYS_DCACHE_OFF)
mcr p15, 0, r1, c7, c14, 0 @ invalidate D cache
#endif
mov pc, lr @ back to caller
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index a01e0d6..bc4238f 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -35,9 +35,6 @@
#include command.h
#include asm/system.h
#include asm/cache.h
-#ifndef CONFIG_L2_OFF
-#include asm/arch/sys_proto.h
-#endif
static void cache_flush(void);
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2a84d27..7578d53 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -70,7 +70,7 @@ typedef struct global_data {
unsigned long irq_sp; /* irq stack pointer */
unsigned long start_addr_sp; /* start_addr_stackpointer */
unsigned long reloc_off;
-#if !(defined(CONFIG_SYS_NO_ICACHE) defined(CONFIG_SYS_NO_DCACHE))
+#if !(defined(CONFIG_SYS_ICACHE_OFF) defined(CONFIG_SYS_DCACHE_OFF))
unsigned long tlb_addr;
#endif
void**jt; /* jump table */
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 03b1b5e..f993d74 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,9 +39,7 @@ GLCOBJS += div0.o
COBJS-y+= board.o
COBJS-y+= bootm.o
COBJS-y+= cache.o
-ifndef CONFIG_SYS_NO_CP15_CACHE
COBJS-y+= cache-cp15.o
-endif
COBJS-y+= interrupts.o
COBJS-y+= reset.o
SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 1a784a1..6342e97 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -329,7 +329,7 @@ void board_init_f (ulong bootflag)
debug (Reserving %ldk for protected RAM at %08lx\n, reg, addr);
#endif /* CONFIG_PRAM */
-#if !(defined(CONFIG_SYS_NO_ICACHE) defined(CONFIG_SYS_NO_DCACHE))
+#if !(defined(CONFIG_SYS_ICACHE_OFF)
[U-Boot] [PATCH v4 4/9] armv7: integrate cache maintenance support
- Enable I-cache on bootup
- Enable MMU and D-cache immediately after relocation
- Do necessary initialization before enabling d-cache and MMU
- Changes to cleanup_before_linux()
- Make changes according to the new framework
Signed-off-by: Aneesh V ane...@ti.com
---
V2:
* Changes for -march=armv7a - armv5 change
* Removed the print inside the weakly linked stub function -
__arm_init_before_mmu
* Replaced CONFIG_SYS_NO_*CACHE with CONFIG_SYS_*CACHE_OFF
---
arch/arm/cpu/armv7/cpu.c | 47 +++
arch/arm/cpu/armv7/start.S | 18 +++-
arch/arm/lib/board.c |6 +
arch/arm/lib/cache-cp15.c |7 ++
arch/arm/lib/cache.c |5
5 files changed, 51 insertions(+), 32 deletions(-)
diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index bc4238f..def9ced 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -35,13 +35,10 @@
#include command.h
#include asm/system.h
#include asm/cache.h
-
-static void cache_flush(void);
+#include asm/armv7.h
int cleanup_before_linux(void)
{
- unsigned int i;
-
/*
* this function is called just before we call linux
* it prepares the processor for linux
@@ -50,31 +47,29 @@ int cleanup_before_linux(void)
*/
disable_interrupts();
- /* turn off I/D-cache */
+ /*
+* Turn off I-cache and invalidate it
+*/
icache_disable();
- dcache_disable();
-
- /* invalidate I-cache */
- cache_flush();
+ invalidate_icache_all();
-#ifndef CONFIG_L2_OFF
- /* turn off L2 cache */
- l2_cache_disable();
- /* invalidate L2 cache also */
- invalidate_dcache(get_device_type());
-#endif
- i = 0;
- /* mem barrier to sync up things */
- asm(mcr p15, 0, %0, c7, c10, 4: :r(i));
+ /*
+* turn off D-cache
+* dcache_disable() in turn flushes the d-cache and disables MMU
+*/
+ dcache_disable();
-#ifndef CONFIG_L2_OFF
- l2_cache_enable();
-#endif
+ /*
+* After D-cache is flushed and before it is disabled there may
+* be some new valid entries brought into the cache. We are sure
+* that these lines are not dirty and will not affect our execution.
+* (because unwinding the call-stack and setting a bit in CP15 SCTRL
+* is all we did during this. We have not pushed anything on to the
+* stack. Neither have we affected any static data)
+* So just invalidate the entire d-cache again to avoid coherency
+* problems for kernel
+*/
+ invalidate_dcache_all();
return 0;
}
-
-static void cache_flush(void)
-{
- asm (mcr p15, 0, %0, c7, c5, 0: :r (0));
-}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index d91ae12..0e698b6 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -255,6 +255,14 @@ clbss_l:strr2, [r0]/* clear
loop...*/
* initialization, now running from RAM.
*/
jump_2_ram:
+/*
+ * If I-cache is enabled invalidate it
+ */
+#ifndef CONFIG_SYS_ICACHE_OFF
+ mcr p15, 0, r0, c7, c5, 0 @ invalidate icache
+ mcr p15, 0, r0, c7, c10, 4 @ DSB
+ mcr p15, 0, r0, c7, c5, 4 @ ISB
+#endif
ldr r0, _board_init_r_ofs
adr r1, _start
add lr, r0, r1
@@ -290,6 +298,9 @@ cpu_init_crit:
mov r0, #0 @ set up for MCR
mcr p15, 0, r0, c8, c7, 0 @ invalidate TLBs
mcr p15, 0, r0, c7, c5, 0 @ invalidate icache
+ mcr p15, 0, r0, c7, c5, 6 @ invalidate BP array
+ mcr p15, 0, r0, c7, c10, 4 @ DSB
+ mcr p15, 0, r0, c7, c5, 4 @ ISB
/*
* disable MMU stuff and caches
@@ -298,7 +309,12 @@ cpu_init_crit:
bic r0, r0, #0x2000 @ clear bits 13 (--V-)
bic r0, r0, #0x0007 @ clear bits 2:0 (-CAM)
orr r0, r0, #0x0002 @ set bit 1 (--A-) Align
- orr r0, r0, #0x0800 @ set bit 12 (Z---) BTB
+ orr r0, r0, #0x0800 @ set bit 11 (Z---) BTB
+#ifdef CONFIG_SYS_ICACHE_OFF
+ bic r0, r0, #0x1000 @ clear bit 12 (I) I-cache
+#else
+ orr r0, r0, #0x1000 @ set bit 12 (I) I-cache
+#endif
mcr p15, 0, r0, c1, c0, 0
/*
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 6342e97..742cc68 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -464,6 +464,12 @@ void board_init_r (gd_t *id, ulong dest_addr)
gd-flags |= GD_FLG_RELOC; /* tell others: relocation done */
monitor_flash_len = _end_ofs;
+ /*
+* Enable D$:
+* I$, if needed, must be already enabled in start.S
+*/
+ dcache_enable();
+
debug (monitor flash len: %08lX\n, monitor_flash_len);
[U-Boot] [PATCH v4 6/9] armv7: add PL310 support to u-boot
PL310 is the L2$ controller from ARM used in many SoCs
including the Cortex-A9 based OMAP4430
Add support for some of the key PL310 operations
- Invalidate all
- Invalidate range
- Flush(clean invalidate) all
- Flush range
Signed-off-by: Aneesh V ane...@ti.com
---
V2:
* More descriptive commit message
* Changes for function pointer to weakly linked change
* C struct for register accesses
---
README |6 ++
arch/arm/include/asm/pl310.h | 73 ++
arch/arm/lib/Makefile|1 +
arch/arm/lib/cache-pl310.c | 115 ++
4 files changed, 195 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/pl310.h
create mode 100644 arch/arm/lib/cache-pl310.c
diff --git a/README b/README
index ca1520d..978e438 100644
--- a/README
+++ b/README
@@ -465,6 +465,12 @@ The following options need to be configured:
CONFIG_SYS_DCACHE_OFF - Do not enable data cache in U-Boot
CONFIG_SYS_L2CACHE_OFF- Do not enable L2 cache in U-Boot
+- Cache Configuration for ARM:
+ CONFIG_SYS_L2_PL310 - Enable support for ARM PL310 L2 cache
+ controller
+ CONFIG_SYS_PL310_BASE - Physical base address of PL310
+ controller register space
+
- Serial Ports:
CONFIG_PL010_SERIAL
diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h
new file mode 100644
index 000..fb506e6
--- /dev/null
+++ b/arch/arm/include/asm/pl310.h
@@ -0,0 +1,73 @@
+/*
+ * (C) Copyright 2010
+ * Texas Instruments, www.ti.com
+ * Aneesh V ane...@ti.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#ifndef _PL310_H_
+#define _PL310_H_
+
+#include linux/types.h
+
+/* Register bit fields */
+#define PL310_AUX_CTRL_ASSOCIATIVITY_MASK (1 16)
+
+struct pl310_regs {
+ u32 pl310_cache_id;
+ u32 pl310_cache_type;
+ u32 pad1[62];
+ u32 pl310_ctrl;
+ u32 pl310_aux_ctrl;
+ u32 pl310_tag_latency_ctrl;
+ u32 pl310_data_latency_ctrl;
+ u32 pad2[60];
+ u32 pl310_event_cnt_ctrl;
+ u32 pl310_event_cnt1_cfg;
+ u32 pl310_event_cnt0_cfg;
+ u32 pl310_event_cnt1_val;
+ u32 pl310_event_cnt0_val;
+ u32 pl310_intr_mask;
+ u32 pl310_masked_intr_stat;
+ u32 pl310_raw_intr_stat;
+ u32 pl310_intr_clear;
+ u32 pad3[323];
+ u32 pl310_cache_sync;
+ u32 pad4[15];
+ u32 pl310_inv_line_pa;
+ u32 pad5[2];
+ u32 pl310_inv_way;
+ u32 pad6[12];
+ u32 pl310_clean_line_pa;
+ u32 pad7[1];
+ u32 pl310_clean_line_idx;
+ u32 pl310_clean_way;
+ u32 pad8[12];
+ u32 pl310_clean_inv_line_pa;
+ u32 pad9[1];
+ u32 pl310_clean_inv_line_idx;
+ u32 pl310_clean_inv_way;
+};
+
+void pl310_inval_all(void);
+void pl310_clean_inval_all(void);
+void pl310_inval_range(u32 start, u32 end);
+void pl310_clean_inval_range(u32 start, u32 end);
+
+#endif
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index f993d74..d31321a 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -40,6 +40,7 @@ COBJS-y += board.o
COBJS-y+= bootm.o
COBJS-y+= cache.o
COBJS-y+= cache-cp15.o
+COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
COBJS-y+= interrupts.o
COBJS-y+= reset.o
SOBJS-$(CONFIG_USE_ARCH_MEMSET) += memset.o
diff --git a/arch/arm/lib/cache-pl310.c b/arch/arm/lib/cache-pl310.c
new file mode 100644
index 000..36c629c
--- /dev/null
+++ b/arch/arm/lib/cache-pl310.c
@@ -0,0 +1,115 @@
+/*
+ * (C) Copyright 2010
+ * Texas Instruments, www.ti.com
+ * Aneesh V ane...@ti.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY;
[U-Boot] [PATCH v4 7/9] armv7: adapt omap4 to the new cache maintenance framework
adapt omap4 to the new layered cache maintenance framework
Signed-off-by: Aneesh V ane...@ti.com
---
V2:
* Changes for the function pointer to weakly linked change
V4:
* Replaced CONFIG_SYS_NO_*CACHE with CONFIG_SYS_*CACHE_OFF
---
arch/arm/cpu/armv7/omap4/board.c| 12
arch/arm/cpu/armv7/omap4/lowlevel_init.S|9 +
arch/arm/include/asm/arch-omap4/sys_proto.h |2 +-
include/configs/omap4_panda.h |8 +---
include/configs/omap4_sdp4430.h |8 +---
5 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c
index fcd29a7..de4cc2a 100644
--- a/arch/arm/cpu/armv7/omap4/board.c
+++ b/arch/arm/cpu/armv7/omap4/board.c
@@ -127,3 +127,15 @@ int arch_cpu_init(void)
set_muxconf_regs();
return 0;
}
+
+#ifndef CONFIG_SYS_L2CACHE_OFF
+void v7_outer_cache_enable(void)
+{
+ set_pl310_ctrl_reg(1);
+}
+
+void v7_outer_cache_disable(void)
+{
+ set_pl310_ctrl_reg(0);
+}
+#endif
diff --git a/arch/arm/cpu/armv7/omap4/lowlevel_init.S
b/arch/arm/cpu/armv7/omap4/lowlevel_init.S
index 026dfa4..6abfbba 100644
--- a/arch/arm/cpu/armv7/omap4/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap4/lowlevel_init.S
@@ -45,3 +45,12 @@ lowlevel_init:
*/
bl s_init
pop {ip, pc}
+
+.globl set_pl310_ctrl_reg
+set_pl310_ctrl_reg:
+ PUSH{r4-r11, lr}@ save registers - ROM code may pollute
+ @ our registers
+ LDR r12, =0x102 @ Set PL310 control register - value in R0
+ .word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5
+ @ call ROM Code API to set control register
+ POP {r4-r11, pc}
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index 4813e9e..4fa4f4b 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -31,11 +31,11 @@ struct omap_sysinfo {
void gpmc_init(void);
void watchdog_init(void);
u32 get_device_type(void);
-void invalidate_dcache(u32);
void set_muxconf_regs(void);
void sr32(void *, u32, u32, u32);
u32 wait_on_value(u32, u32, void *, u32);
void sdelay(unsigned long);
+void set_pl310_ctrl_reg(u32 val);
extern const struct omap_sysinfo sysinfo;
diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index ab878f9..1daffb7 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -45,9 +45,6 @@
#define CONFIG_DISPLAY_CPUINFO 1
#define CONFIG_DISPLAY_BOARDINFO 1
-/* Keep L2 Cache Disabled */
-#define CONFIG_SYS_L2CACHE_OFF 1
-
/* Clock Defines */
#define V_OSCK 3840/* Clock output from T2 */
#define V_SCLK V_OSCK
@@ -235,4 +232,9 @@
CONFIG_SYS_INIT_RAM_SIZE - \
GENERATED_GBL_DATA_SIZE)
+#ifndef CONFIG_SYS_L2CACHE_OFF
+#define CONFIG_SYS_L2_PL3101
+#define CONFIG_SYS_PL310_BASE 0x48242000
+#endif
+
#endif /* __CONFIG_H */
diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
index 0ac407a..68ffa87 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -46,9 +46,6 @@
#define CONFIG_DISPLAY_CPUINFO 1
#define CONFIG_DISPLAY_BOARDINFO 1
-/* Keep L2 Cache Disabled */
-#define CONFIG_SYS_L2CACHE_OFF 1
-
/* Clock Defines */
#define V_OSCK 3840/* Clock output from T2 */
#define V_SCLK V_OSCK
@@ -241,4 +238,9 @@
CONFIG_SYS_INIT_RAM_SIZE - \
GENERATED_GBL_DATA_SIZE)
+#ifndef CONFIG_SYS_L2CACHE_OFF
+#define CONFIG_SYS_L2_PL3101
+#define CONFIG_SYS_PL310_BASE 0x48242000
+#endif
+
#endif /* __CONFIG_H */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 8/9] armv7: adapt omap3 to the new cache maintenance framework
adapt omap3 to the new layered cache maintenance framework
Signed-off-by: Aneesh V ane...@ti.com
---
V2:
* Changes for the function pointer to weakly linked change
V4:
* Minor change in the conditional compilation of L2 related
functions
* Replaced CONFIG_SYS_NO_*CACHE with CONFIG_SYS_*CACHE_OFF
---
arch/arm/cpu/armv7/omap3/Makefile |1 -
arch/arm/cpu/armv7/omap3/board.c| 136 --
arch/arm/cpu/armv7/omap3/cache.S| 263 ---
arch/arm/cpu/armv7/omap3/lowlevel_init.S| 32
arch/arm/include/asm/arch-omap3/omap3.h | 20 ++
arch/arm/include/asm/arch-omap3/sys_proto.h | 10 +-
6 files changed, 176 insertions(+), 286 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/omap3/cache.S
diff --git a/arch/arm/cpu/armv7/omap3/Makefile
b/arch/arm/cpu/armv7/omap3/Makefile
index 7164d50..522bcd2 100644
--- a/arch/arm/cpu/armv7/omap3/Makefile
+++ b/arch/arm/cpu/armv7/omap3/Makefile
@@ -26,7 +26,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
SOBJS := lowlevel_init.o
-SOBJS += cache.o
COBJS += board.o
COBJS += clock.o
diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c
index 6c2a132..98519a9 100644
--- a/arch/arm/cpu/armv7/omap3/board.c
+++ b/arch/arm/cpu/armv7/omap3/board.c
@@ -37,8 +37,12 @@
#include asm/arch/sys_proto.h
#include asm/arch/mem.h
#include asm/cache.h
+#include asm/armv7.h
+/* Declarations */
extern omap3_sysinfo sysinfo;
+static void omap3_setup_aux_cr(void);
+static void omap3_invalidate_l2_cache_secure(void);
/**
* Routine: delay
@@ -166,27 +170,13 @@ void s_init(void)
try_unlock_memory();
- /*
-* Right now flushing at low MPU speed.
-* Need to move after clock init
-*/
- invalidate_dcache(get_device_type());
-#ifndef CONFIG_ICACHE_OFF
- icache_enable();
-#endif
+ /* Errata workarounds */
+ omap3_setup_aux_cr();
-#ifdef CONFIG_L2_OFF
- l2_cache_disable();
-#else
- l2_cache_enable();
+#ifndef CONFIG_SYS_L2CACHE_OFF
+ /* Invalidate L2-cache from secure mode */
+ omap3_invalidate_l2_cache_secure();
#endif
- /*
-* Writing to AuxCR in U-boot using SMI for GP DEV
-* Currently SMI in Kernel on ES2 devices seems to have an issue
-* Once that is resolved, we can postpone this config to kernel
-*/
- if (get_device_type() == GP_DEVICE)
- setup_auxcr();
set_muxconf_regs();
delay(100);
@@ -292,3 +282,111 @@ int checkboard (void)
return 0;
}
#endif /* CONFIG_DISPLAY_BOARDINFO */
+
+static void omap3_emu_romcode_call(u32 service_id, u32 *parameters)
+{
+ u32 i, num_params = *parameters;
+ u32 *sram_scratch_space = (u32 *)OMAP3_PUBLIC_SRAM_SCRATCH_AREA;
+
+ /*
+* copy the parameters to an un-cached area to avoid coherency
+* issues
+*/
+ for (i = 0; i num_params; i++) {
+ __raw_writel(*parameters, sram_scratch_space);
+ parameters++;
+ sram_scratch_space++;
+ }
+
+ /* Now make the PPA call */
+ do_omap3_emu_romcode_call(service_id, OMAP3_PUBLIC_SRAM_SCRATCH_AREA);
+}
+
+static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits)
+{
+ u32 acr;
+
+ /* Read ACR */
+ asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
+ acr = ~clear_bits;
+ acr |= set_bits;
+
+ if (get_device_type() == GP_DEVICE) {
+ omap3_gp_romcode_call(OMAP3_GP_ROMCODE_API_WRITE_ACR,
+ acr);
+ } else {
+ struct emu_hal_params emu_romcode_params;
+ emu_romcode_params.num_params = 1;
+ emu_romcode_params.param1 = acr;
+ omap3_emu_romcode_call(OMAP3_EMU_HAL_API_WRITE_ACR,
+ (u32 *)emu_romcode_params);
+ }
+}
+
+static void omap3_update_aux_cr(u32 set_bits, u32 clear_bits)
+{
+ u32 acr;
+
+ /* Read ACR */
+ asm volatile (mrc p15, 0, %0, c1, c0, 1 : =r (acr));
+ acr = ~clear_bits;
+ acr |= set_bits;
+
+ /* Write ACR - affects non-secure banked bits */
+ asm volatile (mcr p15, 0, %0, c1, c0, 1 : : r (acr));
+}
+
+static void omap3_setup_aux_cr(void)
+{
+ /* Workaround for Cortex-A8 errata: #454179 #430973
+* Set IBE bit
+* Set Disable Brach Size Mispredicts bit
+* Workaround for erratum #621766
+* Enable L1NEON bit
+* ACR |= (IBE | DBSM | L1NEON) = ACR |= 0xE0
+*/
+ omap3_update_aux_cr_secure(0xE0, 0);
+}
+
+#ifndef CONFIG_SYS_L2CACHE_OFF
+/* Invalidate the entire L2 cache from secure mode */
+static void omap3_invalidate_l2_cache_secure(void)
+{
+ if (get_device_type() == GP_DEVICE) {
+
[U-Boot] [PATCH v4 9/9] armv7: adapt s5pc1xx to the new cache maintenance framework
adapt s5pc1xx to the new layered cache maintenance framework
Signed-off-by: Aneesh V ane...@ti.com
---
V2:
* Changes for the function pointer to weakly linked change
V4:
* Minor change in the conditional compilation of L2 related
code in cache.S
* Replaced CONFIG_SYS_NO_*CACHE with CONFIG_SYS_*CACHE_OFF
---
arch/arm/cpu/armv7/s5pc1xx/cache.S| 88 ++---
arch/arm/include/asm/arch-s5pc1xx/sys_proto.h |3 -
2 files changed, 6 insertions(+), 85 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5pc1xx/cache.S
b/arch/arm/cpu/armv7/s5pc1xx/cache.S
index 7734b32..c7d6221 100644
--- a/arch/arm/cpu/armv7/s5pc1xx/cache.S
+++ b/arch/arm/cpu/armv7/s5pc1xx/cache.S
@@ -23,98 +23,22 @@
* MA 02111-1307 USA
*/
-#include asm/arch/cpu.h
-
.align 5
-.global invalidate_dcache
-.global l2_cache_enable
-.global l2_cache_disable
-
-/*
- * invalidate_dcache()
- * Invalidate the whole D-cache.
- *
- * Corrupted registers: r0-r5, r7, r9-r11
- */
-invalidate_dcache:
- stmfd r13!, {r0 - r5, r7, r9 - r12, r14}
-
- cmp r0, #0xC100 @ check if the cpu is s5pc100
-
- beq finished_inval @ s5pc100 doesn't need this
- @ routine
- mrc p15, 1, r0, c0, c0, 1 @ read clidr
- andsr3, r0, #0x700 @ extract loc from clidr
- mov r3, r3, lsr #23 @ left align loc bit field
- beq finished_inval @ if loc is 0, then no need to
- @ clean
- mov r10, #0 @ start clean at cache level 0
-inval_loop1:
- add r2, r10, r10, lsr #1@ work out 3x current cache
- @ level
- mov r1, r0, lsr r2 @ extract cache type bits from
- @ clidr
- and r1, r1, #7 @ mask of the bits for current
- @ cache only
- cmp r1, #2 @ see what cache we have at
- @ this level
- blt skip_inval @ skip if no cache, or just
- @ i-cache
- mcr p15, 2, r10, c0, c0, 0 @ select current cache level
- @ in cssr
- mov r2, #0 @ operand for mcr SBZ
- mcr p15, 0, r2, c7, c5, 4 @ flush prefetch buffer to
- @ sych the new cssrcsidr,
- @ with armv7 this is 'isb',
- @ but we compile with armv5
- mrc p15, 1, r1, c0, c0, 0 @ read the new csidr
- and r2, r1, #7 @ extract the length of the
- @ cache lines
- add r2, r2, #4 @ add 4 (line length offset)
- ldr r4, =0x3ff
- andsr4, r4, r1, lsr #3 @ find maximum number on the
- @ way size
- clz r5, r4 @ find bit position of way
- @ size increment
- ldr r7, =0x7fff
- andsr7, r7, r1, lsr #13 @ extract max number of the
- @ index size
-inval_loop2:
- mov r9, r4 @ create working copy of max
- @ way size
-inval_loop3:
- orr r11, r10, r9, lsl r5@ factor way and cache number
- @ into r11
- orr r11, r11, r7, lsl r2@ factor index number into r11
- mcr p15, 0, r11, c7, c6, 2 @ invalidate by set/way
- subsr9, r9, #1 @ decrement the way
- bge inval_loop3
- subsr7, r7, #1 @ decrement the index
- bge inval_loop2
-skip_inval:
- add r10, r10, #2@ increment cache number
- cmp r3, r10
- bgt inval_loop1
-finished_inval:
- mov r10, #0 @ swith back to cache level 0
- mcr p15, 2, r10, c0, c0, 0 @ select current cache level
- @ in cssr
- mcr p15, 0, r10, c7, c5, 4 @ flush prefetch buffer,
- @ with armv7 this is 'isb',
- @ but we compile with armv5
-
- ldmfd r13!, {r0 - r5, r7, r9 - r12, pc}
-l2_cache_enable:
+#ifndef CONFIG_SYS_L2CACHE_OFF
+.global
[U-Boot] OMAP3: NAND init problems
Hi list, I'am trying to get the NAND-flash to work in my OMAP3 SPL. I essentially call these functions after the base init: gpmc_init(); nand_init(); But in nand_init() the cpu jumps somewhere in memory. I tracked that down to nand_get_flash_type() to the call chip-select_chip(mtd, 0); Some digging shows that the select_chip function pointer isn't initialized - just garbage. Just before the call to nand_get_flash_type() is a call to nand_set_defaults(chip, busw) which IMHO should be responsible to set the function-pointers. But this function tests for non-zero value - garbage is non-zero. Do I miss something for NAND init? Thanks in advance! Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11] Add support for Network Space v2 and parents
-Original Message-
From: Simon Guinot [mailto:simon.gui...@sequanux.org]
Sent: Friday, June 17, 2011 2:39 PM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Simon Guinot
Subject: [PATCH v11] Add support for Network Space v2 and parents
This patch add support for the Network Space v2 board and parents, based
on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
and Internet Space v2.
Additional information is available at:
http://lacie-nas.org/doku.php?id=network_space_v2
Signed-off-by: Simon Guinot sgui...@lacie.com
---
Changes for v2:
- add entries to MAINTAINERS file
- move boards from root Makefile to boards.cfg
- move MACH_TYPE definition into netspace_v2.h
- remove CONFIG_SYS_HZ redefinition
- turn PHY initialization message into debug()
Changes for v3: none
Changes for v4:
- enhance commit message: add SoC information
Changes for v5: none
Changes for v6:
- enable device tree support
- clean some #define in netspace_v2.h
- enhance commit message: provide description URL and mention SoC
family
- rebase against u-boot-{arm,marvell}/master branches
Changes for v7:
- rebase against u-boot-marvell/master branch
Changes for v8:
- update commit title (add netspace_v2 parents information).
- move GPIO button definition into header file.
- update CONFIG_IDENT_STRING with boards alias.
- handle wrong board definition.
- by default, use DHCP to get IP address.
Changes for v9:
- rebase against u-boot-marvell/master branch
Changes for v10:
- rebase against u-boot-marvell/master branch
Changes for v11:
- rebase against u-boot-marvell/next branch
- set email encoding to ISO-8859-1
MAINTAINERS |6 +
board/LaCie/netspace_v2/Makefile | 49 ++
board/LaCie/netspace_v2/kwbimage.cfg | 162
+
board/LaCie/netspace_v2/netspace_v2.c | 142
+
board/LaCie/netspace_v2/netspace_v2.h | 42 +
boards.cfg|3 +
include/configs/netspace_v2.h | 162
+
7 files changed, 566 insertions(+), 0 deletions(-)
create mode 100644 board/LaCie/netspace_v2/Makefile
create mode 100644 board/LaCie/netspace_v2/kwbimage.cfg
create mode 100644 board/LaCie/netspace_v2/netspace_v2.c
create mode 100644 board/LaCie/netspace_v2/netspace_v2.h
create mode 100644 include/configs/netspace_v2.h
Applied to u-boot-marvell.git next branch
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-marvell.git
-Original Message- From: Prafulla Wadaskar Sent: Thursday, June 16, 2011 4:54 PM To: 'Albert ARIBAUD' Cc: 'Wolfgang Denk'; 'u-boot@lists.denx.de'; Ashish Karkare; Prabhanjan Sarnaik Subject: Pull request u-boot-marvell.git Hi Albert Please kindly pull The following changes since commit 7b2fac7654f7420c2787f74ec3b1540fa3b343e9: Aneesh V (1): omap730p2: fix build breaks are available in the git repository at: u-boot-marvell.git next branch. Holger Brunck (4): arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI arm/km: fix u-boot.kwb build breakage arm/km: remove unneeded define arm/km: replace suenx targets with km_kirkwood Valentin Longchamp (3): arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS arm/km: ethernet support for mgcoge3un arm/km: add support for portl2 board Hi Albert I have pushed one more patch on this branch i.e. Simon Guinot (1): Add support for Network Space v2 and parent With additions: board/LaCie/netspace_v2/Makefile| 49 board/LaCie/netspace_v2/kwbimage.cfg| 162 +++ board/LaCie/netspace_v2/netspace_v2.c | 142 +++ board/LaCie/netspace_v2/netspace_v2.h | 42 +++ include/configs/netspace_v2.h | 162 +++ Please kindly consider this for pull or let me know if I need to generate separate pull request for the same. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: NAND init problems
Dear Simon Schwarz, Am 17.06.2011 um 12:03 schrieb Simon Schwarz: Hi list, I'am trying to get the NAND-flash to work in my OMAP3 SPL. I essentially call these functions after the base init: gpmc_init(); nand_init(); But in nand_init() the cpu jumps somewhere in memory. I tracked that down to nand_get_flash_type() to the call chip-select_chip(mtd, 0); Some digging shows that the select_chip function pointer isn't initialized - just garbage. Just before the call to nand_get_flash_type() is a call to nand_set_defaults(chip, busw) which IMHO should be responsible to set the function-pointers. But this function tests for non-zero value - garbage is non-zero. so is this uninitialized? Why don't you set this to an explicit value (e.g. zero) just before going into the nand_init() chain. Where is your 'struct nand_chip' instance located (in .bss, in .data)? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
Hi Rick, I've been browsing through the mailing list and found a similar patch [1] sent about a half a year ago by: John Rigby john.ri...@linaro.org It has neither been accepted, nor rejected. It looks like John's patch is a bit cleaner and has a more complete commit message. I can test it on DM3730/AM3703/OMAP3530 and some time later on AM3517. Can you please, also test it on your available hardware? Sandeep, can you please, take a look at this? [1] http://patchwork.ozlabs.org/patch/76803/ On 06/16/11 22:52, Rick Bronson wrote: Hi Igor, Yes, I have tested this on the AM3715 but not on any other parts. Cheers, Rick On 05/17/11 00:52, r...@efn.org wrote: Signed-off-by: Rick Bronson r...@efn.org --- arch/arm/cpu/armv7/omap-common/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/timer.c b/arch/arm/cpu/armv7/omap-common/timer.c index 9beebb1..3c9d488 100644 --- a/arch/arm/cpu/armv7/omap-common/timer.c +++ b/arch/arm/cpu/armv7/omap-common/timer.c @@ -44,7 +44,7 @@ static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE; */ #define TIMER_CLOCK(V_SCLK / (2 CONFIG_SYS_PTV)) -#define TIMER_LOAD_VAL 0x +#define TIMER_LOAD_VAL 0 /* counter starts from 0 on reload */ Has this been tested? If yes, then on what hardware (board)? Is it only AM SoCs or DM too? -- Regards, Igor. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 2/2] arm: Tegra2: GPIO: enable GPIO for Tegra2 boards
Signed-off-by: Tom Warren twar...@nvidia.com --- Changes in V2: - enable GPIO for all boards (tegra2-common.h) Changes in V3: - enable use of common cmd_gpio include/configs/tegra2-common.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h index febce35..295ee11 100644 --- a/include/configs/tegra2-common.h +++ b/include/configs/tegra2-common.h @@ -160,4 +160,6 @@ CONFIG_SYS_INIT_RAM_SIZE - \ GENERATED_GBL_DATA_SIZE) +#define CONFIG_TEGRA2_GPIO +#define CONFIG_CMD_GPIO #endif /* __TEGRA2_COMMON_H */ -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 0/2] GPIO: Tegra2: add GPIO driver for Tegra2
This patchset adds a GPIO driver for Tegra2 SoC, and enables it for all boards Changes in V2: - use 'gpio_pin' enum in gpio.h (Simon Glass review request) - change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request) - change 'offset' to 'pin' globally - enable GPIO for all boards (tegra2-common.h) Changes in V3: - use common cmd_gpio; remove redundant cmd processing code - add gpio_request, gpio_free and gpio_toggle - alias 'gpio_status' to 'gpio_info' for use in cmd_gpio Changes in V4: - update code as per Mike Frysinger's review comments - rewrite gpio_info, aka gpio_status Changes in V5: - NUL-terminate the name string in gpio_request Tom Warren (2): GPIO: Tegra2: add GPIO driver for Tegra2 arm: Tegra2: GPIO: enable GPIO for Tegra2 boards arch/arm/include/asm/arch-tegra2/gpio.h | 250 +-- arch/arm/include/asm/gpio.h | 38 + drivers/gpio/Makefile |1 + drivers/gpio/tegra2_gpio.c | 255 +++ include/configs/tegra2-common.h |2 + 5 files changed, 536 insertions(+), 10 deletions(-) create mode 100644 arch/arm/include/asm/gpio.h create mode 100644 drivers/gpio/tegra2_gpio.c -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Signed-off-by: Tom Warren twar...@nvidia.com
---
Changes in V2:
- use 'gpio_pin' enum in gpio.h (Simon Glass review request)
- change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request)
- change 'offset' to 'pin' globally
Changes in V3:
- use common cmd_gpio; remove redundant cmd processing code
- add gpio_request, gpio_free and gpio_toggle
- alias 'gpio_status' to 'gpio_info' for use in cmd_gpio
Changes in V4:
- update code as per Mike Frysinger's review comments
- rewrite gpio_info, aka gpio_status
Changes in V5:
- NUL-terminate the name string in gpio_request
arch/arm/include/asm/arch-tegra2/gpio.h | 250 +--
arch/arm/include/asm/gpio.h | 38 +
drivers/gpio/Makefile |1 +
drivers/gpio/tegra2_gpio.c | 255 +++
4 files changed, 534 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/gpio.h
create mode 100644 drivers/gpio/tegra2_gpio.c
diff --git a/arch/arm/include/asm/arch-tegra2/gpio.h
b/arch/arm/include/asm/arch-tegra2/gpio.h
index 0fb8f0d..41e66fe 100644
--- a/arch/arm/include/asm/arch-tegra2/gpio.h
+++ b/arch/arm/include/asm/arch-tegra2/gpio.h
@@ -23,11 +23,13 @@
#define _TEGRA2_GPIO_H_
/*
- * The Tegra 2x GPIO controller has 222 GPIOs arranged in 8 banks of 4 ports,
+ * The Tegra 2x GPIO controller has 224 GPIOs arranged in 7 banks of 4 ports,
* each with 8 GPIOs.
*/
-#define TEGRA_GPIO_PORTS 4 /* The number of ports per bank */
-#define TEGRA_GPIO_BANKS 8 /* The number of banks */
+#define TEGRA_GPIO_PORTS 4 /* number of ports per bank */
+#define TEGRA_GPIO_BANKS 7 /* number of banks */
+#define MAX_NUM_GPIOS (TEGRA_GPIO_PORTS * TEGRA_GPIO_BANKS * 8)
+#define GPIO_NAME_SIZE 20 /* gpio_request max label len */
/* GPIO Controller registers for a single bank */
struct gpio_ctlr_bank {
@@ -45,15 +47,243 @@ struct gpio_ctlr {
struct gpio_ctlr_bank gpio_bank[TEGRA_GPIO_BANKS];
};
-#define GPIO_BANK(x) ((x) 5)
-#define GPIO_PORT(x) (((x) 3) 0x3)
-#define GPIO_BIT(x)((x) 0x7)
+#define GPIO_BANK(x) ((x) 5)
+#define GPIO_PORT(x) (((x) 3) 0x3)
+#define GPIO_FULLPORT(x) ((x) 3)
+#define GPIO_BIT(x)((x) 0x7)
+
+enum gpio_pin {
+ GPIO_PA0 = 0, /* pin 0 */
+ GPIO_PA1,
+ GPIO_PA2,
+ GPIO_PA3,
+ GPIO_PA4,
+ GPIO_PA5,
+ GPIO_PA6,
+ GPIO_PA7,
+ GPIO_PB0, /* pin 8 */
+ GPIO_PB1,
+ GPIO_PB2,
+ GPIO_PB3,
+ GPIO_PB4,
+ GPIO_PB5,
+ GPIO_PB6,
+ GPIO_PB7,
+ GPIO_PC0, /* pin 16 */
+ GPIO_PC1,
+ GPIO_PC2,
+ GPIO_PC3,
+ GPIO_PC4,
+ GPIO_PC5,
+ GPIO_PC6,
+ GPIO_PC7,
+ GPIO_PD0, /* pin 24 */
+ GPIO_PD1,
+ GPIO_PD2,
+ GPIO_PD3,
+ GPIO_PD4,
+ GPIO_PD5,
+ GPIO_PD6,
+ GPIO_PD7,
+ GPIO_PE0, /* pin 32 */
+ GPIO_PE1,
+ GPIO_PE2,
+ GPIO_PE3,
+ GPIO_PE4,
+ GPIO_PE5,
+ GPIO_PE6,
+ GPIO_PE7,
+ GPIO_PF0, /* pin 40 */
+ GPIO_PF1,
+ GPIO_PF2,
+ GPIO_PF3,
+ GPIO_PF4,
+ GPIO_PF5,
+ GPIO_PF6,
+ GPIO_PF7,
+ GPIO_PG0, /* pin 48 */
+ GPIO_PG1,
+ GPIO_PG2,
+ GPIO_PG3,
+ GPIO_PG4,
+ GPIO_PG5,
+ GPIO_PG6,
+ GPIO_PG7,
+ GPIO_PH0, /* pin 56 */
+ GPIO_PH1,
+ GPIO_PH2,
+ GPIO_PH3,
+ GPIO_PH4,
+ GPIO_PH5,
+ GPIO_PH6,
+ GPIO_PH7,
+ GPIO_PI0, /* pin 64 */
+ GPIO_PI1,
+ GPIO_PI2,
+ GPIO_PI3,
+ GPIO_PI4,
+ GPIO_PI5,
+ GPIO_PI6,
+ GPIO_PI7,
+ GPIO_PJ0, /* pin 72 */
+ GPIO_PJ1,
+ GPIO_PJ2,
+ GPIO_PJ3,
+ GPIO_PJ4,
+ GPIO_PJ5,
+ GPIO_PJ6,
+ GPIO_PJ7,
+ GPIO_PK0, /* pin 80 */
+ GPIO_PK1,
+ GPIO_PK2,
+ GPIO_PK3,
+ GPIO_PK4,
+ GPIO_PK5,
+ GPIO_PK6,
+ GPIO_PK7,
+ GPIO_PL0, /* pin 88 */
+ GPIO_PL1,
+ GPIO_PL2,
+ GPIO_PL3,
+ GPIO_PL4,
+ GPIO_PL5,
+ GPIO_PL6,
+ GPIO_PL7,
+ GPIO_PM0, /* pin 96 */
+ GPIO_PM1,
+ GPIO_PM2,
+ GPIO_PM3,
+ GPIO_PM4,
+ GPIO_PM5,
+ GPIO_PM6,
+ GPIO_PM7,
+ GPIO_PN0, /* pin 104 */
+ GPIO_PN1,
+ GPIO_PN2,
+ GPIO_PN3,
+ GPIO_PN4,
+ GPIO_PN5,
+ GPIO_PN6,
+ GPIO_PN7,
+ GPIO_PO0, /* pin 112 */
+ GPIO_PO1,
+ GPIO_PO2,
+ GPIO_PO3,
+ GPIO_PO4,
+ GPIO_PO5,
+ GPIO_PO6,
+ GPIO_PO7,
+ GPIO_PP0, /* pin 120 */
+ GPIO_PP1,
+ GPIO_PP2,
+ GPIO_PP3,
+ GPIO_PP4,
+ GPIO_PP5,
+ GPIO_PP6,
+
Re: [U-Boot] [PATCH 1/1] Fix hang when entering udelay after GPTIMER2 overflows (about 22 minutes on AM37x)
Hi Igor, Yes, I agree. John's patch is better. I'll try to test it this weekend. If you don't hear from me, ping me on Monday. Thanks, Rick Hi Rick, I've been browsing through the mailing list and found a similar patch [1] sent about a half a year ago by: John Rigby john.ri...@linaro.org It has neither been accepted, nor rejected. It looks like John's patch is a bit cleaner and has a more complete commit message. I can test it on DM3730/AM3703/OMAP3530 and some time later on AM3517. Can you please, also test it on your available hardware? Sandeep, can you please, take a look at this? [1] http://patchwork.ozlabs.org/patch/76803/ On 06/16/11 22:52, Rick Bronson wrote: Hi Igor, Yes, I have tested this on the AM3715 but not on any other parts. Cheers, Rick On 05/17/11 00:52, r...@efn.org wrote: Signed-off-by: Rick Bronson r...@efn.org --- arch/arm/cpu/armv7/omap-common/timer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/timer.c b/arch/arm/cpu/armv7/omap-common/timer.c index 9beebb1..3c9d488 100644 --- a/arch/arm/cpu/armv7/omap-common/timer.c +++ b/arch/arm/cpu/armv7/omap-common/timer.c @@ -44,7 +44,7 @@ static struct gptimer *timer_base = (struct gptimer *)CONFIG_SYS_TIMERBASE; */ #define TIMER_CLOCK (V_SCLK / (2 CONFIG_SYS_PTV)) -#define TIMER_LOAD_VAL 0x +#define TIMER_LOAD_VAL 0 /* counter starts from 0 on reload */ Has this been tested? If yes, then on what hardware (board)? Is it only AM SoCs or DM too? -- Regards, Igor. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang,
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
This work borrows from the work of Daniel Schwierzeck
staged here:
https://github.com/danielschwierzeck/u-boot-spl/commits/spl
However the approach is quite different from that of Daniel's.
Appreciate everybody's feedback about this approach.
---
Makefile|7 +++
include/configs/omap4_sdp4430.h |1 +
spl/Makefile| 95
+++
spl/mmc/Makefile| 55 ++
4 files changed, 158 insertions(+), 0 deletions(-)
create mode 100644 spl/Makefile
create mode 100644 spl/mmc/Makefile
diff --git a/Makefile b/Makefile
index dcf5d93..4a2cb58 100644
--- a/Makefile
+++ b/Makefile
@@ -311,6 +311,7 @@ BOARD_SIZE_CHECK =
endif
# Always append ALL so that arch config.mk's can add custom ones
+ALL += spl
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
ifeq ($(CONFIG_NAND_U_BOOT),y)
@@ -326,6 +327,7 @@ ifeq ($(CONFIG_MMC_U_BOOT),y)
ALL += $(obj)mmc_spl/u-boot-mmc-spl.bin
endif
+
all: $(ALL)
$(obj)u-boot.hex: $(obj)u-boot
@@ -420,6 +422,9 @@ $(obj)u-boot-onenand.bin: onenand_ipl $(obj)u-boot.bin
mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
+ $(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
$(VERSION_FILE):
@@ -1133,6 +1138,7 @@ clean:
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
@rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
+ @rm -f
$(obj)spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@@ -1158,6 +1164,7 @@ clobber: clean
@[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l
-print | xargs rm -f
@[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type
l -print | xargs rm -f
@[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l
-print | xargs rm -f
+ @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print |
xargs rm -f
ifeq ($(OBJTREE),$(SRCTREE))
mrproper \
diff --git a/include/configs/omap4_sdp4430.h
b/include/configs/omap4_sdp4430.h
index 68ffa87..3122d1c 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -243,4 +243,5 @@
#define CONFIG_SYS_PL310_BASE 0x48242000
#endif
+#define CONFIG_SYS_SPL_MMC_SUPPORT
#endif /* __CONFIG_H */
diff --git a/spl/Makefile b/spl/Makefile
new file mode 100644
index 000..8dc6e88
--- /dev/null
+++ b/spl/Makefile
@@ -0,0 +1,95 @@
+#
+# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
+#
+# This file is released under the terms of GPL v2 and any later version.
+# See the file COPYING in the root directory of the source tree for
details.
+#
+
+include $(TOPDIR)/config.mk
+LIBS-$(CONFIG_SYS_SPL_MMC_SUPPORT) = mmc/libmmc.o
+# The following commented for the time-being, but will be enabled in
+# real implementation
+LIBS-$(CONFIG_SYS_SPL_FAT_SUPPORT) += fat/libfat.o
+LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o
+LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o
+LIBS += $(shell if [ -f $(ARCH)/Makefile ]; then echo \
+ $(ARCH)/lib$(ARCH).o; fi)
+LIBS += $(shell if [ -f $(ARCH)/$(CPU)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/lib$(CPU).o; fi)
+LIBS += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/Makefile ]; then echo \
+ $(ARCH)/$(CPU)/$(SOC)/lib$(SOC).o; fi)
+LIBS += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/Makefile ]; then
echo \
+ $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/lib$(BOARD).o; fi)
+
+LIBS-y := $(addprefix $(obj),$(sort $(LIBS-y)))
+
+__LIBS := $(subst $(obj),,$(LIBS-y))
+
+ifndef SPL_LDSCRIPT
+ ifdef CONFIG_SYS_SPL_LDSCRIPT
+ # need to strip off double quotes
+ SPL_LDSCRIPT := $(subst ,,$(CONFIG_SYS_SPL_LDSCRIPT))
+ endif
+endif
+
+ifndef SPL_LDSCRIPT
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT :=
$(TOPDIR)/spl/$(ARCH)/$(CPU)/$(SOC)/$(BOARDDIR)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT :=
$(TOPDIR)/spl/$(ARCH)/$(CPU)/$(SOC)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+ SPL_LDSCRIPT := $(TOPDIR)/spl/$(ARCH)/$(CPU)/u-boot-spl.lds
+ endif
+ ifeq ($(wildcard $(SPL_LDSCRIPT)),)
+$(error could not find linker script)
+ endif
+endif
+LNDIR := $(OBJTREE)/spl
+
+# Special flags for
Re: [U-Boot] OMAP3: NAND init problems
Dear Simon Schwarz, please don't use TOFU, use inline quoting and also send to the list. Am 17.06.2011 um 17:18 schrieb Simon Schwarz: Dear Andreas, i tried setting it - but this should be already working code - therefore if I have to set the values manually it is very likely that I did something wrong while adapting it for the SPL. Sounds correct. I can't find anything in the devkit8000 implementation which sets these values - and NAND is working nonetheless. Yes, armv7 start.S initializes .bss to zero in normal case (after relocation - see clear_bss). Is that called in your case (SPL with not mainline code) too? nand_chip is in bss (which is in RAM). IMHO this shouldn't be a problem because RAM is initialized before, right? Yes, if it is initialized correctly (zero out the bss section!), remember our talk some days ago. But I just guessing cause of your statement 'the function pointer are initialized to garbage' in your first mail, it may be a completely other cause. Please let us know what it was. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang, On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Daniel Schwierzeck, In message banlktim9ae2aszklidh53vd+hjpz7gv...@mail.gmail.com you wrote: The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. This is very much wrong. In the general case, you still need relocation (because the final start address of the U-Boot code canonly be determined at runtime), and you definitely need the code in board_init_r(). I guess we are talking about different kinds of SPL. In my understanding a SPL runs inside an internal SRAM, initializes any external RAM and loads U-Boot from any kind of memory or flash device into that RAM at a fixed load address and then jumps to that address. In this case no relocation is needed. Some kind of SoC specific booting mechanism like a NAND-IPL or hard-wired Boot-ROM loads the SPL initially into SRAM and jumps to it. available in media specific directories such as nand_spl/ and mmc_spl/. Symbolic links? No. Let's put this stuff into spl/common/ To use the spl directory as remote build directory, the obj and src variables must be tweaked a little. To keep this changes minimal, it is not possible to have further source files and directories inside the spl directory. I suggest to put common spl code in TOPDIR/lib/spl/common, TOPDIR/lib/spl/nand and so on. No. All SPL related stuff should go into spl/ ok Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Fri, 17 Jun 2011 20:45:19 +0200 Daniel Schwierzeck daniel.schwierz...@googlemail.com wrote: Dear Wolfgang, On Thu, Jun 16, 2011 at 11:47 PM, Wolfgang Denk w...@denx.de wrote: Dear Daniel Schwierzeck, In message banlktim9ae2aszklidh53vd+hjpz7gv...@mail.gmail.com you wrote: The relocate_code and board_init_r functions must not be compiled, they are not needed anyway. This can be simply controlled with -DCONFIG_UBOOT_SPL_BUILD. This is very much wrong. In the general case, you still need relocation (because the final start address of the U-Boot code canonly be determined at runtime), and you definitely need the code in board_init_r(). I guess we are talking about different kinds of SPL. In my understanding a SPL runs inside an internal SRAM, initializes any external RAM and loads U-Boot from any kind of memory or flash device into that RAM at a fixed load address and then jumps to that address. In this case no relocation is needed. Some kind of SoC specific booting mechanism like a NAND-IPL or hard-wired Boot-ROM loads the SPL initially into SRAM and jumps to it. It starts from an SRAM, but often relocates to RAM before loading the final image. In some cases the SRAM is also used by hardware as the I/O buffer, so we need to vacate it before any further NAND operations. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano, Le 15/06/2011 11:28, Stefano Babic a écrit : Hi Albert, please pull from u-boot-imx. There are only fix for a couple of still broken boards. The following changes since commit 9571865e0d32b1bcf8a6625497d1cd5d4bbad354: Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-06-08 23:29:04 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Your request is based on u-boot/master... Can you please resend a pull request based on u-boot-arm/master? Please wait until I have pulled in Prafulla's pull request then you can fetch u-boot-arm/master and rebase on it. Sorry for the delay. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: NAND init problems
hi, On Fri Jun 17, 2011 at 12:03:31PM +0200, Simon Schwarz wrote: I'am trying to get the NAND-flash to work in my OMAP3 SPL. I essentially call these functions after the base init: gpmc_init(); nand_init(); I guess this is the same as nand_spl. Do you use nand_boot.c in the spl code. This file has the nand_chip object declared as a local variable on the stack, and not bss. But in nand_init() the cpu jumps somewhere in memory. I tracked that down to nand_get_flash_type() to the call chip-select_chip(mtd, 0); Some digging shows that the select_chip function pointer isn't initialized - just garbage. If you check the nand_boot function in the nand_boot.c, it calls board_nand_init, and not nand_init, so i guess you are using a different path here. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi again Stefano, Le 17/06/2011 21:24, Albert ARIBAUD a écrit : Hi Stefano, Le 15/06/2011 11:28, Stefano Babic a écrit : Hi Albert, please pull from u-boot-imx. There are only fix for a couple of still broken boards. The following changes since commit 9571865e0d32b1bcf8a6625497d1cd5d4bbad354: Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-06-08 23:29:04 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Your request is based on u-boot/master... Can you please resend a pull request based on u-boot-arm/master? Please wait until I have pulled in Prafulla's pull request then you can fetch u-boot-arm/master and rebase on it. Sorry for the delay. Update: actually, can you rebase on u-boot-arm/master as it is currently, and submit your pull request now? I'll pull Marvell in later. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh V ane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber:clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Why are these in mmc? What is it you propose would be in these files? +$(LIBS-y): depend + $(MAKE) -C $(dir $(subst $(obj),,$@)) all If no libraries are selected, this will produce a rule with an empty target, which is undefined behavior. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-marvell.git
(resent as this was not sent to the list, sorry Prafulla for the duplicate) Hi Prafulla, Le 16/06/2011 13:23, Prafulla Wadaskar a écrit : Hi Albert Please kindly pull The following changes since commit 7b2fac7654f7420c2787f74ec3b1540fa3b343e9: Aneesh V (1): omap730p2: fix build breaks are available in the git repository at: u-boot-marvell.git next branch. Are these meant for this release, i.e. should I pull that in u-boot-arm/master? If so, can you please rebase your master branch onto your next branch? Next is supposed to hold commits waiting for next merge window. Also: uboot@lilith:~/src/u-boot-arm$ git fetch u-boot-marvell remote: error: refs/remotes/origin/mkimage does not point to a valid object! remote: Counting objects: 88, done. remote: Compressing objects: 100% (38/38), done. remote: Total 68 (delta 51), reused 38 (delta 29) Unpacking objects: 100% (68/68), done. From git://git.denx.de/u-boot-marvell + 0b41af5...7b2fac7 master - u-boot-marvell/master (forced update) + 02e1082...7e481f6 next - u-boot-marvell/next (forced update) uboot@lilith:~/src/u-boot-arm$ Anyone know what the error message about refs/remote/origin/mkimage means? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD Ultimate SATA SD
Hi, Le 17/06/2011 10:29, Alexei Ozhigov a écrit : 2011/6/17 Prafulla Wadaskarprafu...@marvell.com: -Original Message- From: Philip Hands [mailto:p...@hands.com] Sent: Friday, June 17, 2011 1:33 AM To: Alexei Ozhigov Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] OpenRD Ultimate SATA SD On Thu, 16 Jun 2011 16:18:46 +0400, Alexei Ozhigov alexei.ozhi...@gmail.com wrote: ... I am experiencing the same problem with SATA right now with v2011.06-rc2 (tried also the latest master). If MVSATA_STATUS_TIMEOUT in mvsata_ide_initialize_port is ignored, SATA drive is found on the second port and I am able to read the drive's content. Inspired by what you say about timeouts, I thought perhaps increasing the timeout from 10ms to 1s might make a difference -- that worked! ... except that now, it's working regardless :-( So, I've no idea if that's really related to what's going on, because I've now gone as far as reducing the timeout to 5ms and it's _still_ working fine, so perhaps some part of the SATA subsystem was in a state that was somehow reset by waiting a bit longer for the startup once, and that's somehow fixed it. It is still working despite powering down the machine for a while, so I'm guessing whatever changed is something to do with the state of the hard drive. Sadly that means that I've now lost the ability to test this, since trying any of the versions that were previously failing now work. Anyway, Alexei, try increasing the timeout (i.e. the value being assigned to timeleft) --- if that works for you too, it seems pretty harmless, so might be appropriate for wider adoption. I have already tried longer timeouts for timeleft and it does not help. Also with timeout circumvention the SATA flash card I was hoping to boot from (Transcend TS1GSDOM22V) is identified as follows: Bus 0: OK Bus 1: OK Device 0: Model: TRANSCEND Firm: 20080128 Ser#: 200804070005 Type: Hard Disk Capacity: 955.8 MB = 0.9 GB (1957536 x 512) IDE read: device 0 not ready IDE read: device 0 not ready Device 1: Model: Firm: Ser#: Type: Hard Disk Capacity: not available And then the card cannot be read. First attempt shows OK although the data written to memory are wrong, next attempts result in device 0 not ready. On the other hand, Linux (Debian ARM port) does not recognize the card either. So if this problem is not related to improper initialization, the question is how SATA flash differs from regular SATA drives with respect to SATA controller in 88F6281 and if it is actually possible to work with SATA flash on OpenRD. Can you #define DEBUG at the start of common/cmd_ide.c and rerun the test? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
