[PATCH 1/1] mmc: fsl_esdhc_imx: Fix error message
Add missing newline character and also add the return code of
regulator_set_value() to the output.
Signed-off-by: Alexander Stein
---
drivers/mmc/fsl_esdhc_imx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index a9b8d7dd67f..03de7dcd505 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -766,7 +766,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
ret = regulator_set_value(priv->vqmmc_dev,
330);
if (ret) {
- printf("Setting to 3.3V error");
+ printf("Setting to 3.3V error: %d\n", ret);
return -EIO;
}
mdelay(5);
@@ -784,7 +784,7 @@ static int esdhc_set_voltage(struct mmc *mmc)
ret = regulator_set_value(priv->vqmmc_dev,
180);
if (ret) {
- printf("Setting to 1.8V error");
+ printf("Setting to 1.8V error: %d\n", ret);
return -EIO;
}
}
--
2.34.1
Re: [PATCH] tqma6: Fix DDR configuration
Hi Miquel, Am Donnerstag, 23. November 2023, 14:12:33 CET schrieb Miquel Raynal: > Hi Markus, > > markus.nie...@ew.tq-group.com wrote on Thu, 23 Nov 2023 14:04:43 +0100: > > Hello Miquel, > > > > > Initially investigating a Linux network issue causing a lot of drop and > > > poor network performances on a custom system based on a TQMA6A module > > > (based on an iMX6Q), [1st link below]. > > > > > > I eventually correlated my observations with a contention at the NIC > > > level when in concurrency with the graphics pipeline. Troubleshooting > > > this in the kernel lead to disabling DMA bursts accesses made by the IPU > > > in order to avoid triggering the QoS at the interconnect level, reducing > > > from 50 to 10% the drop rate on eth0, [2nd link below]. The solution > > > worked on my setup but not on others, which still suffered from > > > abnormally high drop rates even with this "fix". > > > > > > After looking a while into TQ Systems BSP I figured out a number of > > > differences in recent U-Boot out-of-tree patches they had in their > > > repository [3rd link]. Parsing the differences one after the other lead > > > me to this final solution. > > > > > > The reset pad of the DDR controller was apparently misconfigured, Bit > > > 18-19 picturing the "DDR select field". The current value b11 is > > > reserved. The only defined value as of version 6 of the iMX6Q manual was > > > b00 "DDR3 and LPDDR2 mode". In practice no register difference has been > > > spotted after changing this configuration but all issues tracked thus > > > far just vanished. All previous fixes have been proven irrelevant. Just > > > clearing this field solved all our network issues and the drop rate as > > > measured by iperf3 felt back to 0%. > > > > > > Link: > > > https://lore.kernel.org/netdev/20231012193410.3d1812cf@xps-13/ > > > > > > Link: > > > https://lists.freedesktop.org/archives/dri-devel/2023-October/428251.htm > > > l > > > > > > Link: > > > https://github.com/tq-systems/u-boot-tqmaxx/commit/15eb6abbefbf6916c2846 > > > 7b85485911dad3da6bc > > > > > > Signed-off-by: Miquel Raynal < > > > miquel.ray...@bootlin.com > > > > > > --- > > > > > > board/tq/tqma6/tqma6q.cfg | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/board/tq/tqma6/tqma6q.cfg b/board/tq/tqma6/tqma6q.cfg > > > index a49489aed3f..a345c4de93d 100644 > > > --- a/board/tq/tqma6/tqma6q.cfg > > > +++ b/board/tq/tqma6/tqma6q.cfg > > > @@ -36,7 +36,7 @@ DATA 4, MX6_IOM_DRAM_SDCLK_1, 0x8030 > > > > > > DATA 4, MX6_IOM_DRAM_CAS, 0x8030 > > > DATA 4, MX6_IOM_DRAM_RAS, 0x8030 > > > DATA 4, MX6_IOM_GRP_ADDDS, 0x0030 > > > > > > -DATA 4, MX6_IOM_DRAM_RESET, 0x000C3030 > > > +DATA 4, MX6_IOM_DRAM_RESET, 0x3030 > > > > Thank you for pointing this out. Originally this error came from an > > older/ancient reference manual. Sorry that we missed to bring this > > upstream. We will send the changes for DCD data in the next days. > > No problem, I'm glad this can now be solved. By any chance, could you > point to the relevant location of the manual (ddr or imx6 ?) explaining > what this is actually about? Because I failed to bring any real > explanation to my observations so far. It's a bit hidden but the comment above that list indicates these settings are iomuxc configurations. In this case the register IOMUXC_SW_PAD_CTL_PAD_DRAM_RESET. See i.MX6Q RM Rev.6 05/2020 section 36.4.347. Your patch configures the field "DDR Select Field" from reserved3 to DDR3_LPDDR2. It seems this field has to be set to 0 in every case. Thanks again and best regards, Alexander > Thanks, > Miquèl -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider http://www.tq-group.com/
Re: U-Boot support for IMX8MP dual-role
Hello Tim, Am Freitag, 16. September 2022, 20:43:54 CEST schrieb Tim Harvey: > Greetings, > > I'm wondering if anyone has done any work to get dual-role USB working > for the IMX8MP (or any other dwc3 host based board) and how they went > about it if so. > > The imx8mp-venice-gw74xx has dual-role support through a USB Type-C > connector with a TPS25821 (driverless) that monitors the CC signals > and manages VBUS, as well as asserts gpio's: > FAULT# - pinmuxed to OC pin > SINK# - used as GPIO for role > POL# - used for SS mux to connector > > For linux this is managed with a usb-role-switch dt prop and a > connector node with compatible of gpio-usb-b-connector and id-gpios > [1]. I did not see anything like that in use in U-Boot for dwc3 hosts > but perhaps I was looking in the wrong place. > > For U-Boot I can get this type-C connector to work in host mode only > by changing dr_mode="otg" to dr_mode="host". With the default dt prop > dr_mode=otg dwc3-generic-peripheral is bound instead of > dwc3-generic-host thus no host controller is found. > > It seems to me that dwc3_glue_bind needs support added to be able to > check id-gpios or vbus-gpios if usb-role-switch and something like > gpio-usb-b-connector or linux,extcon-usb-gpio are used. Does this > sound like the correct implementation? > > I notice that drivers/usb/host/xhci-dwc3.c which is a driver for the > dwc3 core (compatible snps,dwc3) and this does look at usb-role-swich > however this driver as a subnode of fsl,imx8mp-dwc3 (glue) does not > bind and perhaps that is an issue. In that driver usb-role-switch > causes the driver to use role-switch-default-mode for the default mode > which still does not look at an id/vbus pin so that would not be > feature complete either. For imx8mp you probably need something like [1] to support usb-role-switch. But I am not aware how things are done in u-boot. Best regards, Alexander [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ commit/?id=a102f07e4edf0f1cf06bf9825ab10e26a29dd945 > Best Regards, > > TIm > 1 > https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/commit/? > h=for-next&id=c8a4192d238e9258ab0bc916b3c138a4722af215
Re: [U-Boot] [PATCH 1/1] spi: fsl_qspi: Pet watchdog even more
On Tuesday 13 June 2017 20:36:35, York Sun wrote: > On 06/01/2017 04:26 AM, Alexander Stein wrote: > > Pet the watchdog once upon each command call (qspi_xfer) and during > > each loop iteration in several commands. > > > > This fixes a watchdog reset especially during erase command. > > Funny you keep petting the watchdog for this driver. I am curious what > watchdog are you using? Why no one else suffer the reset. We use a SP706T with a timeout of 1.6s. Propably this short timeout causes the problem for me only. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] spi: fsl_qspi: Pet watchdog even more
Pet the watchdog once upon each command call (qspi_xfer) and during
each loop iteration in several commands.
This fixes a watchdog reset especially during erase command.
Signed-off-by: Alexander Stein
---
drivers/spi/fsl_qspi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index e61c67b088..1dfa89afc9 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -493,6 +493,8 @@ static void qspi_op_rdbank(struct fsl_qspi_priv *priv, u8
*rxbuf, u32 len)
;
while (1) {
+ WATCHDOG_RESET();
+
reg = qspi_read32(priv->flags, ®s->rbsr);
if (reg & QSPI_RBSR_RDBFL_MASK) {
data = qspi_read32(priv->flags, ®s->rbdr[0]);
@@ -530,6 +532,8 @@ static void qspi_op_rdid(struct fsl_qspi_priv *priv, u32
*rxbuf, u32 len)
i = 0;
while ((RX_BUFFER_SIZE >= len) && (len > 0)) {
+ WATCHDOG_RESET();
+
rbsr_reg = qspi_read32(priv->flags, ®s->rbsr);
if (rbsr_reg & QSPI_RBSR_RDBFL_MASK) {
data = qspi_read32(priv->flags, ®s->rbdr[i]);
@@ -702,6 +706,8 @@ static void qspi_op_rdsr(struct fsl_qspi_priv *priv, void
*rxbuf, u32 len)
;
while (1) {
+ WATCHDOG_RESET();
+
reg = qspi_read32(priv->flags, ®s->rbsr);
if (reg & QSPI_RBSR_RDBFL_MASK) {
data = qspi_read32(priv->flags, ®s->rbdr[0]);
@@ -757,6 +763,8 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int
bitlen,
static u32 wr_sfaddr;
u32 txbuf;
+ WATCHDOG_RESET();
+
if (dout) {
if (flags & SPI_XFER_BEGIN) {
priv->cur_seqid = *(u8 *)dout;
--
2.13.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing
Hi Fabio, On Friday 04 December 2015 18:54:15, Fabio Estevam wrote: > On Wed, Nov 4, 2015 at 6:19 AM, Alexander Stein > wrote: > > When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog > > timeout might occur meanwhile. So pet the watchdog while operating on > > the flash. > > I guess the same problem would occur when you do long file transfers > via TFTP, via USB, via eMMC, right? I didn't notice this problem with TFTP which takes ~3s. I don't have the opportunity to use USB oder eMMC on this hardware. > Shouldn't you fix the watchdog timeout value instead? If I read this > thread correctly you set the watchdog timeout to be 1.5 s, which seems > to be too low. You might be right, but there absolutely no way to change that timeout. It's _fixed_ in hardware. If you can't serve it, you got reset. It's that simple, no matter what. Best regards, Alexander -- Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.st...@systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax:+49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing
On Friday 04 December 2015 12:10:47, York Sun wrote: > > On 12/03/2015 05:56 PM, Wang Huan-B18965 wrote: > >> On 12/03/2015 01:49 AM, Wang Huan-B18965 wrote: > >> > >> > >> > >>>> > >>>> The actual command which results in a watchdog reset is 'sf read > >>>> 0x8104 0x20 0x40'. Please note that this uses an external > >>>> watchdog which is enabled by default and resets after ~1.5s. The > >>>> command itself takes about 2s (taken from my watch). > >>>> > >>> [Alison Wang] I could not reproduce the issue. Maybe I don't have the > >>> external watchdog which will reset after ~1.5s as Alexander mentioned. > >>> > >>> U-Boot 2015.10-00273-g7ee52af (Dec 03 2015 - 17:32:24 +0800) > >>> > >>> CPU: Freescale LayerScape LS1021E, Version: 2.0, (0x87081120) > >>> Clock Configuration: > >>>CPU0(ARMV7):1000 MHz, > >>>Bus:300 MHz, DDR:800 MHz (1600 MT/s data rate), Reset > >>> Configuration Word (RCW): > >>>: 0608000a > >>>0010: 3000 7900 40025a00 21046000 > >>>0020: 2000 > >>>0030: 20024800 881b7540 > >>> Model: LS1021A TWR Board > >>> Board: LS1021ATWR > >>> I2C: ready > >>> DRAM: 1 GiB > >>> Using SERDES1 Protocol: 48 (0x30) > >>> MMC: FSL_SDHC: 0 > >>> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, > >>> total 16 MiB > >>> EEPROM: NXID v1 > >>> PCIe1: Root Complex no link, regs @ 0x340 > >>> PCIe2: disabled > >>> In:serial > >>> Out: serial > >>> Err: serial > >>> SEC: RNG instantiated > >>> SATA link 0 timeout. > >>> AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode > >>> flags: 64bit ncq pm clo only pmp fbss pio slum part ccc Found 0 > >>> device(s). > >>> SCSI: Net: eTSEC1 is in sgmii mode. > >>> eTSEC2 is in sgmii mode. > >>> eTSEC1, eTSEC2, eTSEC3 [PRIME] > >>> => => sf probe > >>> SF: Detected N25Q128 with page size 256 Bytes, erase size 64 KiB, > >>> total 16 MiB => sf read 0x8104 0x20 0x40 device 0 offset > >>> 0x20, size 0x40 > >>> SF: 4194304 bytes @ 0x20 Read: OK > >>> => > >> > >> Alison and Alexander, > >> > >> My concerns are > >> > >> Is the watchdog triggered reasonably? > > [Alison Wang] I think as Alexander set the watchdog to 1s timeout, so the > > trigger occurs at that time. Well, 'set' is not exactly correct. It is 'set' by hardware (power sequencer), thus fixed in hardware. No way to change it. > >> How long does it take to load the file? > > [Alison Wang] About 2s. > >> Is SPI running at reasonable speed? > > [Alison Wang] Yes. > >> Is there other similar situations such as loading large file off NOR > >> flash? > > [Alison Wang] If we don't set the watchdog to 1s timeout, both loading > > Large file to serial flash or NOR flash, there is not such situation. > > If we set the watchdog to 1s timeout, I think there are both such > > situation. > > > > Alexander, do you agree with my answer? Please give your comments too. :) I can't test NOR, there is just none. But loading from TFTP works fine (about 3s download time), so it seems rather a QSPI driver problem. Other answers are same for me. > If an external watchdog is used, any long operation may trigger it. Yep, especially there is no way to avoid that, despite petting it at reasonable intervals. Best regards, Alexander -- Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.st...@systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax:+49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing
Hi, On Thursday 03 December 2015 09:49:40, Huan Wang wrote: > [Alison Wang] I could not reproduce the issue. Maybe I don't have the > external watchdog which will reset after ~1.5s as Alexander mentioned. Could you try to set the internal watchdog to 1s timeout? This should be more or less the same scenario. Best regards, Alexander -- Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.st...@systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax:+49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing
On Wednesday 25 November 2015 02:20:53, Huan Wang wrote: > [Alison Wang] I didn't meet any issue when using sf commands to write and > read the serial flash. > > Hi, Alexander, > > Could you show me the detail commands and process when you meet > such issue? Then I can try to reproduce on my board. Yep, here is the output: > U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50) > > CPU: Freescale LayerScape LS1021E, Version: 2.0, (0x87081120) > > Clock Configuration: >CPU0(ARMV7):960 MHz, >Bus:288 MHz, DDR:800 MHz (1600 MT/s data rate), > Reset Configuration Word (RCW): >: 0608000a >0010: 7000 08407922 4a00 21046000 >0020: 0021ef00 >0030: 20024800 0888f340 > QSPI >Watchdog enabled > I2C: ready > DRAM: Initializing DDR > Detected UDIMM Fixed DDR on board > 512 MiB (DDR3, 16-bit, CL=11, ECC off) > Using SERDES1 Protocol: 112 (0x70) > MMC: FSL_SDHC: 0 > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, > In:serial > Out: serial > Err: serial > SF: Detected S25FL512S_256K with page size 512 Bytes, erase size 256 KiB, > total 64 MiB SF: 262144 bytes @ 0x18 Read: OK > Firmware 'Microcode version 0.0.1 for LS1021a r1.0' for 1021 V1.0 > QE: uploading microcode 'Microcode for LS1021a r1.0' version 0.0.1 > SCSI: Net: eTSEC2 is in sgmii mode. > eTSEC1 [PRIME], eTSEC2 > Hit any key to stop autoboot: 0 > => sf read 0x8104 0x20 0x40 > > > U-Boot 2015.01-00671-g78773b9 (Nov 25 2015 - 10:28:50) > > CPU: Freescale LayerScape LS1021E, Version: 2.0, (0x87081120) > > Clock Configuration: >CPU0(ARMV7):960 MHz, >Bus:288 MHz, DDR:800 MHz (1600 MT/s data rate), > Reset Configuration Word (RCW): >: 0608000a >0010: 7000 08407922 4a00 21046000 >0020: 0021ef00 >0030: 20024800 0888f340 > QSPI >Watchdog enabled > I2C: ready > DRAM: Initializing DDR > Detected UDIMM Fixed DDR on board > [...] and so on... The actual command which results in a watchdog reset is 'sf read 0x8104 0x20 0x40'. Please note that this uses an external watchdog which is enabled by default and resets after ~1.5s. The command itself takes about 2s (taken from my watch). Best regards, Alexander -- Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.st...@systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax:+49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing
On Monday 23 November 2015 10:51:49, York Sun wrote: > On 11/04/2015 12:19 AM, Alexander Stein wrote: > > When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog > > timeout might occur meanwhile. So pet the watchdog while operating on > > the flash. > > Alexander, > > On which platform was this watchdog issue found? On a custom board based on LS1021A. The (GPIO based) watchdog timeout is about 1.5s Best regards, Alexander -- Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.st...@systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax:+49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] fsl_qspi: Pet the watchdog while reading/writing
When reading a large blob. e.g. a linux kernel (several MiBs) a watchdog
timeout might occur meanwhile. So pet the watchdog while operating on
the flash.
Signed-off-by: Alexander Stein
---
drivers/spi/fsl_qspi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index ed39114..feec3e8 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "fsl_qspi.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -527,6 +528,8 @@ static void qspi_op_read(struct fsl_qspi_priv *priv, u32
*rxbuf, u32 len)
to_or_from = priv->sf_addr + priv->cur_amba_base;
while (len > 0) {
+ WATCHDOG_RESET();
+
qspi_write32(priv->flags, ®s->sfar, to_or_from);
size = (len > RX_BUFFER_SIZE) ?
@@ -574,6 +577,8 @@ static void qspi_op_write(struct fsl_qspi_priv *priv, u8
*txbuf, u32 len)
status_reg = 0;
while ((status_reg & FLASH_STATUS_WEL) != FLASH_STATUS_WEL) {
+ WATCHDOG_RESET();
+
qspi_write32(priv->flags, ®s->ipcr,
(SEQID_WREN << QSPI_IPCR_SEQID_SHIFT) | 0);
while (qspi_read32(priv->flags, ®s->sr) & QSPI_SR_BUSY_MASK)
--
2.4.10
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: ls1021a: Ensure Generic Timer disabled before jumping into the OS
Hi,
On Tuesday 27 October 2015 02:52:43, Huan Wang wrote:
> Do you have any comment about this patch?
> Thanks.
> > > On Tuesday 04 August 2015 09:55:37, Alison Wang wrote:
> > > > This patch addresses a problem mentioned recently on this mailing
> > > list:
> > > > [1].
> > > >
> > > > In that posting a LS1021 based system was locking up at about 5
> > > > minutes after boot,but the problem was mysteriously related to the
> > > > toolchain used for building u-boot.Debugging the problem reveals a
> > > > stuck interrupt 29 on the GIC.
> > > >
> > > > It appears Freescale's LS1021 support in u-boot erroneously sets the
> > > > 64-bit ARM generic PL1 physical time CompareValue register to all-
> > > ones
> > > > with a 32-bit value.This causes the timer compare to fire 344
> > > > seconds after u-boot configures it.Depending on how fast u-boot gets
> > > > the kernel booted,this amounts to about 5-minutes of Linux uptime
> > > > before locking up.
> > > >
> > > > Apparently the bug is masked by some toolchains. Perhaps this is
> > > > explained by default compiler options, word sizes, or binutils
> > > versions.
> > > >
> > > > To fix the above issue, the generic physical timer is disabled
> > > > before jumping to the OS.
> > > >
> > > > [1]
> > > > https://lists.yoctoproject.org/pipermail/meta-freescale/2015-
> > > June/0144
> > > > 00.html
> > > >
> > > > Signed-off-by: Chris Kilgour
> > > > Signed-off-by: Alison Wang
> > > > ---
> > > > arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c
> > > > b/arch/arm/cpu/armv7/ls102xa/cpu.c
> > > > index 75f0d8c..298422f 100644
> > > > --- a/arch/arm/cpu/armv7/ls102xa/cpu.c
> > > > +++ b/arch/arm/cpu/armv7/ls102xa/cpu.c
> > > > @@ -346,3 +346,13 @@ void smp_kick_all_cpus(void)
> > > > out_be32(&gur->brrl, 0x2);
> > > > }
> > > > #endif
> > > > +
> > > > +void arch_preboot_os(void)
> > > > +{
> > > > + unsigned long ctrl;
> > > > +
> > > > + /* Disable PL1 Physical Timer */
> > > > + asm("mrc p15, 0, %0, c14, c2, 1" : "=r" (ctrl));
> > > > + ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
> > > > + asm("mcr p15, 0, %0, c14, c2, 1" : : "r" (ctrl)); }
> > >
> > > This only disables the timer when booting linux. Does the possibly
> > > misconfigured timer compare value (only lower 32-bits are set to
> > > 0x) have any side-effects within u-boot? I don't currently
> > > know the timer is used there.
> > > I would prefer that the inline assembly code in timer_init is fixed to
> > > pass an 64-bit variable to mcrr. Maybe someone will take that code
> > > snippet as an example and such problems occur again. Opinions?
> > >
> >
> > [Alison Wang] Thanks for your reply. I agree with you that the
> > misconfigured Timer compare value should be fixed too. So except this
> > patch, the patch on http://patchwork.ozlabs.org/patch/495476/ need to be
> > applied too.
Same opinion here. Both patches should be applied.
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.st...@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax:+49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: ls1021a: Ensure Generic Timer disabled before jumping into the OS
Hello Alison,
On Tuesday 04 August 2015 09:55:37, Alison Wang wrote:
> This patch addresses a problem mentioned recently on this mailing list:
> [1].
>
> In that posting a LS1021 based system was locking up at about 5 minutes
> after boot,but the problem was mysteriously related to the toolchain
> used for building u-boot.Debugging the problem reveals a stuck
> interrupt 29 on the GIC.
>
> It appears Freescale's LS1021 support in u-boot erroneously sets the
> 64-bit ARM generic PL1 physical time CompareValue register to all-ones
> with a 32-bit value.This causes the timer compare to fire 344 seconds
> after u-boot configures it.Depending on how fast u-boot gets the
> kernel booted,this amounts to about 5-minutes of Linux uptime before
> locking up.
>
> Apparently the bug is masked by some toolchains. Perhaps this is
> explained by default compiler options, word sizes, or binutils versions.
>
> To fix the above issue, the generic physical timer is disabled
> before jumping to the OS.
>
> [1]
> https://lists.yoctoproject.org/pipermail/meta-freescale/2015-June/014400.html
>
> Signed-off-by: Chris Kilgour
> Signed-off-by: Alison Wang
> ---
> arch/arm/cpu/armv7/ls102xa/cpu.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c
> b/arch/arm/cpu/armv7/ls102xa/cpu.c
> index 75f0d8c..298422f 100644
> --- a/arch/arm/cpu/armv7/ls102xa/cpu.c
> +++ b/arch/arm/cpu/armv7/ls102xa/cpu.c
> @@ -346,3 +346,13 @@ void smp_kick_all_cpus(void)
> out_be32(&gur->brrl, 0x2);
> }
> #endif
> +
> +void arch_preboot_os(void)
> +{
> + unsigned long ctrl;
> +
> + /* Disable PL1 Physical Timer */
> + asm("mrc p15, 0, %0, c14, c2, 1" : "=r" (ctrl));
> + ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
> + asm("mcr p15, 0, %0, c14, c2, 1" : : "r" (ctrl));
> +}
This only disables the timer when booting linux. Does the possibly
misconfigured timer compare value (only lower 32-bits are set to 0x)
have any side-effects within u-boot? I don't currently know the timer is used
there.
I would prefer that the inline assembly code in timer_init is fixed to pass an
64-bit variable to mcrr. Maybe someone will take that code snippet as an
example and such problems occur again. Opinions?
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.st...@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax:+49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: ls1021a: Ensure LS1021 ARM Generic Timer CompareValue Set 64-bit
On Wednesday 15 July 2015 15:13:05, Alison Wang wrote: > This patch addresses a problem mentioned recently on this mailing list: > [1]. > > In that posting a LS1021 based system was locking up at about 5 minutes > after boot, but the problem was mysteriously related to the toolchain > used for building u-boot. Debugging the problem reveals a stuck > interrupt 29 on the GIC. > > It appears Freescale's LS1021 support in u-boot erroneously sets the > 64-bit ARM generic PL1 physical time CompareValue register to all-ones > with a 32-bit value. This causes the timer compare to fire 344 seconds > after u-boot configures it. Depending on how fast u-boot gets the > kernel booted, this amounts to about 5-minutes of Linux uptime before > locking up. > > Apparently the bug is masked by some toolchains. Perhaps this is > explained by default compiler options, word sizes, or binutils versions. > At any rate this patch makes the manipulation explicitly 64-bit which > alleviates the issue. initcall_run_list is the function "hiding" or not "hiding" this problem when calling timer_init. It is using r4 and r5 for it's loop variables. On gcc-4.8 and gcc-4.9 the usage of those two registers are switched. So a newer gcc uses a slightly different register allocation. While this function is perfectly fine, depending on the r4 register timer_init uses a different value for the upper 32-bit of CNTP_CVAL resulting in the different behavior. I've compared two u-boots objdumps showing and not showing this problem which _only_ differ in those 2 register usages. Best regards, Alexander -- Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH alexander.st...@systec-electronic.com Legal and Commercial Address: Am Windrad 2 08468 Heinsdorfergrund Germany Office: +49 (0) 3765 38600-0 Fax:+49 (0) 3765 38600-4100 Managing Directors: Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt; Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp Commercial Registry: Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] arm: ls102xa: timer: Fix undefined behavior
PL1 Physical Comp Value is set in inline assembly by using mcrr.
The %Q0 and %R0 modifier required a 64-bit argument but only a 32-bit is
passed. This results in the following code:
[...]
82000ccc: e3e03000mvn r3, #0
82000cd0: ec443f2emcrr15, 2, r3, r4, cr14
[...]
While r4 is uninitialized it depends on the value in initcall_run_list
how the timer is programmed.
It has been observed that this code works by coincidence with one
toolchain while it breaks with another one which uses different registers
in initcall_run_list.
Fix this by actually using a 64-bit variable.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/armv7/ls102xa/timer.c| 3 ++-
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/ls102xa/timer.c
b/arch/arm/cpu/armv7/ls102xa/timer.c
index 11b17b2..f964288 100644
--- a/arch/arm/cpu/armv7/ls102xa/timer.c
+++ b/arch/arm/cpu/armv7/ls102xa/timer.c
@@ -56,7 +56,8 @@ static inline unsigned long long us_to_tick(unsigned long
long usec)
int timer_init(void)
{
struct sctr_regs *sctr = (struct sctr_regs *)SCTR_BASE_ADDR;
- unsigned long ctrl, val, freq;
+ unsigned long ctrl, freq;
+ u64 val;
/* Enable System Counter */
writel(SYS_COUNTER_CTRL_ENABLE, &sctr->cntcr);
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index d34044a..e45c20e 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -31,7 +31,7 @@
#define RCWSR4_SRDS1_PRTCL_SHIFT 24
#define RCWSR4_SRDS1_PRTCL_MASK0xff00
-#define TIMER_COMP_VAL 0x
+#define TIMER_COMP_VAL ~0ULL
#define ARCH_TIMER_CTRL_ENABLE (1 << 0)
#define SYS_COUNTER_CTRL_ENABLE(1 << 24)
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Raspberry Pi2 performance
Hi, after getting dcache support for Raspberry Pi 1 (see other thread) to work: I wanted to do that for rpi2 too. But even without dcaches rpi2 is slower than rpi1 for both MMC and USB ethernet. I have no idea why, but trying the new dhry command from current origin/master confirms my suspicion. bcm2835 (w/o dcache): U-Boot> dhry 100 iterations in 10948 ms: 91340/s, 51 DMIPS bcm2835 (w/ dcache): U-Boot> dhry 100 iterations in 1656 ms: 603864/s, 343 DMIPS bcm2836 (w/o dcache): U-Boot> dhry 100 iterations in 43247 ms: 23122/s, 13 DMIPS Independent from the dcache difference it seems totally wrong to me that the bcm2836 is about 4 times slower than the bcm2835. I have this in my config.txt of bcm2835: > kernel=u-boot.bin > > #force rpi to assume there is always a HDMI link > hdmi_force_hotplug=1 > #force normal HDMI (incl. sound) > hdmi_drive=2 > > gpu_mem=16 > > arm_freq=800 > core_freq=300 > sdram_freq=400 > over_voltage=0 While having only this line at bcm2836: > kernel=u-boot.bin Does someone experience the same? What might be wrong here? Do I need some config.txt settings to get bcm2836 running as fast as it should. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/7] arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw mailbox
When using dcache the setup data for the mailbox must be actually written
into memory before calling into firmware. Thus flush and invalidate the
memory.
Signed-off-by: Alexander Stein
Acked-by: Stephen Warren
Tested-by: Stephen Warren
---
Changes in v3:
* Use ARCH_DMA_MINALIGN instead of fixed 32
* Adjust comment in header
Changes in v2:
* Add hint in header about alignment requirements
* Invalidate cache after calling into mailbox
* round size up to next cacheline size
arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +++
arch/arm/mach-bcm283x/mbox.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 54d369c..ff959c8 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -522,6 +522,9 @@ int bcm2835_mbox_call_raw(u32 chan, u32 send, u32 *recv);
* a termination value are expected to immediately follow the header in
* memory, as required by the property protocol.
*
+ * Each struct bcm2835_mbox_hdr passed must be allocated with
+ * ALLOC_CACHE_ALIGN_BUFFER(x, y, z) to ensure proper cache flush/invalidate.
+ *
* Returns 0 for success, any other value for error.
*/
int bcm2835_mbox_call_prop(u32 chan, struct bcm2835_mbox_hdr *buffer);
diff --git a/arch/arm/mach-bcm283x/mbox.c b/arch/arm/mach-bcm283x/mbox.c
index 1af9be7..311bd8f 100644
--- a/arch/arm/mach-bcm283x/mbox.c
+++ b/arch/arm/mach-bcm283x/mbox.c
@@ -111,9 +111,18 @@ int bcm2835_mbox_call_prop(u32 chan, struct
bcm2835_mbox_hdr *buffer)
dump_buf(buffer);
#endif
+ flush_dcache_range((unsigned long)buffer,
+ (unsigned long)((void *)buffer +
+ roundup(buffer->buf_size, ARCH_DMA_MINALIGN)));
+
ret = bcm2835_mbox_call_raw(chan, phys_to_bus((u32)buffer), &rbuffer);
if (ret)
return ret;
+
+ invalidate_dcache_range((unsigned long)buffer,
+ (unsigned long)((void *)buffer +
+ roundup(buffer->buf_size, ARCH_DMA_MINALIGN)));
+
if (rbuffer != phys_to_bus((u32)buffer)) {
printf("mbox: Response buffer mismatch\n");
return -1;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/7] dwc2: Add dcache support
This adds dcache support for dwc2. The DMA buffers must be DMA aligned and
is flushed for outgoing transactions before starting transfer. For
ingoing transactions it is invalidated after the transfer has finished.
Signed-off-by: Alexander Stein
Acked-by: Stephen Warren
---
Changes in v4:
* Updated USB buffer comment about required alignment
drivers/usb/host/dwc2.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index eee60a2..b7fb4f8 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -21,9 +21,9 @@
#define DWC2_STATUS_BUF_SIZE 64
#define DWC2_DATA_BUF_SIZE (64 * 1024)
-/* We need doubleword-aligned buffers for DMA transfers */
-DEFINE_ALIGN_BUFFER(uint8_t, aligned_buffer, DWC2_DATA_BUF_SIZE, 8);
-DEFINE_ALIGN_BUFFER(uint8_t, status_buffer, DWC2_STATUS_BUF_SIZE, 8);
+/* We need cacheline-aligned buffers for DMA transfers and dcache support */
+DEFINE_ALIGN_BUFFER(uint8_t, aligned_buffer, DWC2_DATA_BUF_SIZE,
ARCH_DMA_MINALIGN);
+DEFINE_ALIGN_BUFFER(uint8_t, status_buffer, DWC2_STATUS_BUF_SIZE,
ARCH_DMA_MINALIGN);
#define MAX_DEVICE 16
#define MAX_ENDPOINT 16
@@ -802,9 +802,14 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe,
int *pid, int in,
(*pid << DWC2_HCTSIZ_PID_OFFSET),
&hc_regs->hctsiz);
- if (!in)
+ if (!in) {
memcpy(aligned_buffer, (char *)buffer + done, len);
+ flush_dcache_range((unsigned long)aligned_buffer,
+ (unsigned long)((void *)aligned_buffer +
+ roundup(len, ARCH_DMA_MINALIGN)));
+ }
+
writel(phys_to_bus((unsigned long)aligned_buffer),
&hc_regs->hcdma);
@@ -820,6 +825,11 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe,
int *pid, int in,
if (in) {
xfer_len -= sub;
+
+ invalidate_dcache_range((unsigned long)aligned_buffer,
+ (unsigned long)((void *)aligned_buffer +
+ roundup(xfer_len, ARCH_DMA_MINALIGN)));
+
memcpy(buffer + done, aligned_buffer, xfer_len);
if (sub)
stop_transfer = 1;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/7] dcache support for Raspberry Pi 1
This patchset enables dcache support for Raspberry Pi 1.
First the cache support code for arm1136 and 1176 was merged.
CONFIG_SYS_CACHELINE_SIZE is defined as 32 bytes which is used as alignment
for mailbox buffer allocations.
Then rpi mailbox code has now dcache flush for writing the mailbox request and
a dcache invalidation for receiving the mailbox answer.
Finally the CONFIG_SYS_DCACHE_OFF switch got removed from rpi1 config. It is
still set for rpi2 config.
dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to
12.3 MiB/s. TFTP download over USB Ethernet increases from 2,3 MiB/s to
2,6 to 3,3 MiB/s (seems to vary a lot).
This was tested by the following commands:
> fatload mmc 0:1 ${kernel_addr_r} zImage
and
> tftp u-boot.bin
Changes in v4:
* Added Acked-By and Tested-By of Stephen Warren
* Set CONFIG_SYS_CACHELINE_SIZE for rpi and rpi2 appropriately
* Updated USB buffer comment about required alignment
* Used git format-patch -M to generate patches
Changes in v3:
* dwc2 dcache support
* Use ALLOC_CACHE_ALIGN_BUFFER for mailbox buffer allocation
* Use ARCH_DMA_MINALIGN for size to roundup
Changes in v2:
* Merge arm1136/1176 cache code
* Use cacheline size as mailbox buffer alignment
* Flush/invalidate mailbox buffer up to cacheline size
Alexander Stein (7):
arm1136: Remove dead code
arm1136/arm1176: Merge cache handling code
ARM: bcm283x: Define CONFIG_SYS_CACHELINE_SIZE
ARM: bcm283x: Allocate all mailbox buffers cacheline aligned
arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw
mailbox
dwc2: Add dcache support
arm/rpi: Enable dcache
arch/arm/cpu/arm11/Makefile | 8 +
arch/arm/cpu/{arm1136 => arm11}/cpu.c | 10 --
arch/arm/cpu/arm1136/Makefile | 1 -
arch/arm/cpu/arm1176/Makefile | 4 ++-
arch/arm/cpu/arm1176/cpu.c| 51 ---
arch/arm/mach-bcm283x/include/mach/mbox.h | 3 ++
arch/arm/mach-bcm283x/mbox.c | 9 ++
board/raspberrypi/rpi/rpi.c | 10 +++---
drivers/usb/host/dwc2.c | 18 ---
drivers/video/bcm2835.c | 4 +--
include/configs/rpi-common.h | 1 -
include/configs/rpi.h | 2 ++
include/configs/rpi_2.h | 2 ++
13 files changed, 48 insertions(+), 75 deletions(-)
create mode 100644 arch/arm/cpu/arm11/Makefile
rename arch/arm/cpu/{arm1136 => arm11}/cpu.c (94%)
delete mode 100644 arch/arm/cpu/arm1176/cpu.c
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/7] ARM: bcm283x: Define CONFIG_SYS_CACHELINE_SIZE
The cacheline is always 32 bytes for arm1176 CPUs, so define it at board config level for cache handling code. The ARM Cortex-A7 has a dcache line size of 64 bytes. Signed-off-by: Alexander Stein Acked-by: Stephen Warren Tested-by: Stephen Warren --- Changes in v4: * Set CONFIG_SYS_CACHELINE_SIZE for rpi and rpi2 separately as they differ include/configs/rpi.h | 2 ++ include/configs/rpi_2.h | 1 + 2 files changed, 3 insertions(+) diff --git a/include/configs/rpi.h b/include/configs/rpi.h index ab2f4db..86422e3 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -7,6 +7,8 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_CACHELINE_SIZE 32 + #include "rpi-common.h" #endif diff --git a/include/configs/rpi_2.h b/include/configs/rpi_2.h index 2e7e74f..13dc8de 100644 --- a/include/configs/rpi_2.h +++ b/include/configs/rpi_2.h @@ -9,6 +9,7 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BCM2836 +#define CONFIG_SYS_CACHELINE_SIZE 64 #include "rpi-common.h" -- 2.4.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/7] ARM: bcm283x: Allocate all mailbox buffers cacheline aligned
The mailbox buffer is required to be at least 16 bytes aligned, but for
cache invalidation and/or flush it needs to be cacheline aligned.
Use ALLOC_CACHE_ALIGN_BUFFER for all mailbox buffer allocations.
Signed-off-by: Alexander Stein
Acked-by: Stephen Warren
Tested-by: Stephen Warren
---
Changes in v3:
* Use ALLOC_CACHE_ALIGN_BUFFER instead of ALLOC_ALIGN_BUFFER +
CONFIG_SYS_CACHELINE_SIZE
board/raspberrypi/rpi/rpi.c | 10 +-
drivers/video/bcm2835.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 96fe870..d21750e 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -182,7 +182,7 @@ u32 rpi_board_rev = 0;
int dram_init(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1);
int ret;
BCM2835_MBOX_INIT_HDR(msg);
@@ -212,7 +212,7 @@ static void set_fdtfile(void)
static void set_usbethaddr(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1);
int ret;
if (!models[rpi_board_rev].has_onboard_eth)
@@ -245,7 +245,7 @@ int misc_init_r(void)
static int power_on_module(u32 module)
{
- ALLOC_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1);
int ret;
BCM2835_MBOX_INIT_HDR(msg_pwr);
@@ -269,7 +269,7 @@ static int power_on_module(u32 module)
static void get_board_rev(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_board_rev, msg, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_board_rev, msg, 1);
int ret;
const char *name;
@@ -324,7 +324,7 @@ int board_init(void)
int board_mmc_init(bd_t *bis)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1);
int ret;
power_on_module(BCM2835_MBOX_POWER_DEVID_SDHCI);
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 1f18231..61d054d 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -38,8 +38,8 @@ struct msg_setup {
void lcd_ctrl_init(void *lcdbase)
{
- ALLOC_ALIGN_BUFFER(struct msg_query, msg_query, 1, 16);
- ALLOC_ALIGN_BUFFER(struct msg_setup, msg_setup, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_query, msg_query, 1);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_setup, msg_setup, 1);
int ret;
u32 w, h;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/7] arm1136/arm1176: Merge cache handling code
As both cores are similar merge the cache handling code for both CPUs
to arm11 directory.
Signed-off-by: Alexander Stein
Acked-by: Stephen Warren
Tested-by: Stephen Warren
---
Changes in v4:
* Used git format-patch -M to generate patches
arch/arm/cpu/arm11/Makefile | 8 ++
arch/arm/cpu/{arm1136 => arm11}/cpu.c | 0
arch/arm/cpu/arm1136/Makefile | 1 -
arch/arm/cpu/arm1176/Makefile | 4 ++-
arch/arm/cpu/arm1176/cpu.c| 51 ---
5 files changed, 11 insertions(+), 53 deletions(-)
create mode 100644 arch/arm/cpu/arm11/Makefile
rename arch/arm/cpu/{arm1136 => arm11}/cpu.c (100%)
delete mode 100644 arch/arm/cpu/arm1176/cpu.c
diff --git a/arch/arm/cpu/arm11/Makefile b/arch/arm/cpu/arm11/Makefile
new file mode 100644
index 000..2379b0f
--- /dev/null
+++ b/arch/arm/cpu/arm11/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y = cpu.o
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm11/cpu.c
similarity index 100%
rename from arch/arm/cpu/arm1136/cpu.c
rename to arch/arm/cpu/arm11/cpu.c
diff --git a/arch/arm/cpu/arm1136/Makefile b/arch/arm/cpu/arm1136/Makefile
index 56a9390..5d6f0aa 100644
--- a/arch/arm/cpu/arm1136/Makefile
+++ b/arch/arm/cpu/arm1136/Makefile
@@ -6,7 +6,6 @@
#
extra-y= start.o
-obj-y = cpu.o
obj-$(CONFIG_MX31) += mx31/
obj-$(CONFIG_MX35) += mx35/
diff --git a/arch/arm/cpu/arm1176/Makefile b/arch/arm/cpu/arm1176/Makefile
index deec427..cd6dc9c 100644
--- a/arch/arm/cpu/arm1176/Makefile
+++ b/arch/arm/cpu/arm1176/Makefile
@@ -8,5 +8,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj- += dummy.o
extra-y= start.o
-obj-y = cpu.o
+
+obj-y += ../arm11/
diff --git a/arch/arm/cpu/arm1176/cpu.c b/arch/arm/cpu/arm1176/cpu.c
deleted file mode 100644
index 2d81651..000
--- a/arch/arm/cpu/arm1176/cpu.c
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * (C) Copyright 2004 Texas Insturments
- *
- * (C) Copyright 2002
- * Sysgo Real-Time Solutions, GmbH
- * Marius Groeger
- *
- * (C) Copyright 2002
- * Gary Jennejohn, DENX Software Engineering,
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/*
- * CPU specific code
- */
-
-#include
-#include
-#include
-
-static void cache_flush (void);
-
-int cleanup_before_linux (void)
-{
- /*
-* this function is called just before we call linux
-* it prepares the processor for linux
-*
-* we turn off caches etc ...
-*/
-
- disable_interrupts ();
-
- /* turn off I/D-cache */
- icache_disable();
- dcache_disable();
- /* flush I/D-cache */
- cache_flush();
-
- return 0;
-}
-
-/* flush I/D-cache */
-static void cache_flush (void)
-{
- /* invalidate both caches and flush btb */
- asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (0));
- /* mem barrier to sync things */
- asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (0));
-}
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/7] arm1136: Remove dead code
Apparently lcd_panel_disable is not defined anywhere, so no config for
an arm1136 board would have set CONFIG_LCD. Remove the unused code.
Signed-off-by: Alexander Stein
Acked-by: Stephen Warren
Tested-by: Stephen Warren
---
arch/arm/cpu/arm1136/cpu.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index a7aed4b..5d4b3c2 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -32,16 +32,6 @@ int cleanup_before_linux (void)
disable_interrupts ();
-#ifdef CONFIG_LCD
- {
- extern void lcd_disable(void);
- extern void lcd_panel_disable(void);
-
- lcd_disable(); /* proper disable of lcd & panel */
- lcd_panel_disable();
- }
-#endif
-
/* turn off I/D-cache */
icache_disable();
dcache_disable();
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/7] arm/rpi: Enable dcache
Now that mailbox driver supports cache flush and invalidation, we can enable dcache. Signed-off-by: Alexander Stein Acked-by: Stephen Warren Tested-by: Stephen Warren --- include/configs/rpi-common.h | 1 - include/configs/rpi_2.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 1012cdd..dd638c4 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -14,7 +14,6 @@ #define CONFIG_SYS_GENERIC_BOARD #define CONFIG_BCM2835 #define CONFIG_ARCH_CPU_INIT -#define CONFIG_SYS_DCACHE_OFF #define CONFIG_SYS_TIMER_RATE 100 #define CONFIG_SYS_TIMER_COUNTER \ diff --git a/include/configs/rpi_2.h b/include/configs/rpi_2.h index 13dc8de..bea4ebd 100644 --- a/include/configs/rpi_2.h +++ b/include/configs/rpi_2.h @@ -10,6 +10,7 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BCM2836 #define CONFIG_SYS_CACHELINE_SIZE 64 +#define CONFIG_SYS_DCACHE_OFF #include "rpi-common.h" -- 2.4.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/7] ARM: bcm283x: Allocate all mailbox buffers cacheline aligned
The mailbox buffer is required to be at least 16 bytes aligned, but for
cache invalidation and/or flush it needs to be cacheline aligned.
Use ALLOC_CACHE_ALIGN_BUFFER for all mailbox buffer allocations.
Signed-off-by: Alexander Stein
---
Changes in v3:
* Use ALLOC_CACHE_ALIGN_BUFFER instead of ALLOC_ALIGN_BUFFER +
CONFIG_SYS_CACHELINE_SIZE
board/raspberrypi/rpi/rpi.c | 10 +-
drivers/video/bcm2835.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 96fe870..d21750e 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -182,7 +182,7 @@ u32 rpi_board_rev = 0;
int dram_init(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1);
int ret;
BCM2835_MBOX_INIT_HDR(msg);
@@ -212,7 +212,7 @@ static void set_fdtfile(void)
static void set_usbethaddr(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1);
int ret;
if (!models[rpi_board_rev].has_onboard_eth)
@@ -245,7 +245,7 @@ int misc_init_r(void)
static int power_on_module(u32 module)
{
- ALLOC_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1);
int ret;
BCM2835_MBOX_INIT_HDR(msg_pwr);
@@ -269,7 +269,7 @@ static int power_on_module(u32 module)
static void get_board_rev(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_board_rev, msg, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_board_rev, msg, 1);
int ret;
const char *name;
@@ -324,7 +324,7 @@ int board_init(void)
int board_mmc_init(bd_t *bis)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1);
int ret;
power_on_module(BCM2835_MBOX_POWER_DEVID_SDHCI);
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 1f18231..61d054d 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -38,8 +38,8 @@ struct msg_setup {
void lcd_ctrl_init(void *lcdbase)
{
- ALLOC_ALIGN_BUFFER(struct msg_query, msg_query, 1, 16);
- ALLOC_ALIGN_BUFFER(struct msg_setup, msg_setup, 1, 16);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_query, msg_query, 1);
+ ALLOC_CACHE_ALIGN_BUFFER(struct msg_setup, msg_setup, 1);
int ret;
u32 w, h;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/7] dwc2: Add dcache support
This adds dcache support for dwc2. The DMA buffers must be DMA aligned and
is flushed for outgoing transactions before starting transfer. For
ingoing transactions it is invalidated after the transfer has finished.
Signed-off-by: Alexander Stein
---
drivers/usb/host/dwc2.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index eee60a2..03fba8f 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -22,8 +22,8 @@
#define DWC2_DATA_BUF_SIZE (64 * 1024)
/* We need doubleword-aligned buffers for DMA transfers */
-DEFINE_ALIGN_BUFFER(uint8_t, aligned_buffer, DWC2_DATA_BUF_SIZE, 8);
-DEFINE_ALIGN_BUFFER(uint8_t, status_buffer, DWC2_STATUS_BUF_SIZE, 8);
+DEFINE_ALIGN_BUFFER(uint8_t, aligned_buffer, DWC2_DATA_BUF_SIZE,
ARCH_DMA_MINALIGN);
+DEFINE_ALIGN_BUFFER(uint8_t, status_buffer, DWC2_STATUS_BUF_SIZE,
ARCH_DMA_MINALIGN);
#define MAX_DEVICE 16
#define MAX_ENDPOINT 16
@@ -802,9 +802,14 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe,
int *pid, int in,
(*pid << DWC2_HCTSIZ_PID_OFFSET),
&hc_regs->hctsiz);
- if (!in)
+ if (!in) {
memcpy(aligned_buffer, (char *)buffer + done, len);
+ flush_dcache_range((unsigned long)aligned_buffer,
+ (unsigned long)((void *)aligned_buffer +
+ roundup(len, ARCH_DMA_MINALIGN)));
+ }
+
writel(phys_to_bus((unsigned long)aligned_buffer),
&hc_regs->hcdma);
@@ -820,6 +825,11 @@ int chunk_msg(struct usb_device *dev, unsigned long pipe,
int *pid, int in,
if (in) {
xfer_len -= sub;
+
+ invalidate_dcache_range((unsigned long)aligned_buffer,
+ (unsigned long)((void *)aligned_buffer +
+ roundup(xfer_len, ARCH_DMA_MINALIGN)));
+
memcpy(buffer + done, aligned_buffer, xfer_len);
if (sub)
stop_transfer = 1;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/7] dcache support for Raspberry Pi 1
This patchset enables dcache support for Raspberry Pi 1.
First the cache support code for arm1136 and 1176 was merged.
CONFIG_SYS_CACHELINE_SIZE is defined as 32 bytes which is used as alignment
for mailbox buffer allocations.
Then rpi mailbox code has now dcache flush for writing the mailbox request and
a dcache invalidation for receiving the mailbox answer.
Finally the CONFIG_SYS_DCACHE_OFF switch got removed from rpi1 config. It is
still set for rpi2 config.
dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to
12.3 MiB/s. TFTP download over USB Ethernet increases from 2,3 MiB/s to
2,6 to 3,3 MiB/s (seems to vary a lot).
This was tested by the following commands:
> fatload mmc 0:1 ${kernel_addr_r} zImage
and
> tftp u-boot.bin
Changes in v3:
* dwc2 dcache support
* Use ALLOC_CACHE_ALIGN_BUFFER for mailbox buffer allocation
* Use ARCH_DMA_MINALIGN for size to roundup
Changes in v2:
* Merge arm1136/1176 cache code
* Use cacheline size as mailbox buffer alignment
* Flush/invalidate mailbox buffer up to cacheline size
Alexander Stein (7):
arm1136: Remove dead code
arm1136/arm1176: Merge cache handling code
ARM: bcm283x: Define CONFIG_SYS_CACHELINE_SIZE
ARM: bcm283x: Allocate all mailbox buffers cacheline aligned
arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw
mailbox
dwc2: Add dcache support
arm/rpi: Enable dcache
arch/arm/cpu/arm11/Makefile | 8 ++
arch/arm/cpu/arm11/cpu.c | 150
arch/arm/cpu/arm1136/Makefile | 1 -
arch/arm/cpu/arm1136/cpu.c| 160 --
arch/arm/cpu/arm1176/Makefile | 4 +-
arch/arm/cpu/arm1176/cpu.c| 51 --
arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +
arch/arm/mach-bcm283x/mbox.c | 9 ++
board/raspberrypi/rpi/rpi.c | 10 +-
drivers/usb/host/dwc2.c | 16 ++-
drivers/video/bcm2835.c | 4 +-
include/configs/rpi-common.h | 2 +-
include/configs/rpi_2.h | 1 +
13 files changed, 195 insertions(+), 224 deletions(-)
create mode 100644 arch/arm/cpu/arm11/Makefile
create mode 100644 arch/arm/cpu/arm11/cpu.c
delete mode 100644 arch/arm/cpu/arm1136/cpu.c
delete mode 100644 arch/arm/cpu/arm1176/cpu.c
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/7] arm1136: Remove dead code
Apparently lcd_panel_disable is not defined anywhere, so no config for
an arm1136 board would have set CONFIG_LCD. Remove the unused code.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm1136/cpu.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index a7aed4b..5d4b3c2 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -32,16 +32,6 @@ int cleanup_before_linux (void)
disable_interrupts ();
-#ifdef CONFIG_LCD
- {
- extern void lcd_disable(void);
- extern void lcd_panel_disable(void);
-
- lcd_disable(); /* proper disable of lcd & panel */
- lcd_panel_disable();
- }
-#endif
-
/* turn off I/D-cache */
icache_disable();
dcache_disable();
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] arm1136/arm1176: Merge cache handling code
As both cores are similar merge the cache handling code for both CPUs
to arm11 directory.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm11/Makefile | 8 +++
arch/arm/cpu/arm11/cpu.c | 150 ++
arch/arm/cpu/arm1136/Makefile | 1 -
arch/arm/cpu/arm1136/cpu.c| 150 --
arch/arm/cpu/arm1176/Makefile | 4 +-
arch/arm/cpu/arm1176/cpu.c| 51 --
6 files changed, 161 insertions(+), 203 deletions(-)
create mode 100644 arch/arm/cpu/arm11/Makefile
create mode 100644 arch/arm/cpu/arm11/cpu.c
delete mode 100644 arch/arm/cpu/arm1136/cpu.c
delete mode 100644 arch/arm/cpu/arm1176/cpu.c
diff --git a/arch/arm/cpu/arm11/Makefile b/arch/arm/cpu/arm11/Makefile
new file mode 100644
index 000..2379b0f
--- /dev/null
+++ b/arch/arm/cpu/arm11/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y = cpu.o
diff --git a/arch/arm/cpu/arm11/cpu.c b/arch/arm/cpu/arm11/cpu.c
new file mode 100644
index 000..5d4b3c2
--- /dev/null
+++ b/arch/arm/cpu/arm11/cpu.c
@@ -0,0 +1,150 @@
+/*
+ * (C) Copyright 2004 Texas Insturments
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH
+ * Marius Groeger
+ *
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering,
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * CPU specific code
+ */
+
+#include
+#include
+#include
+
+static void cache_flush(void);
+
+int cleanup_before_linux (void)
+{
+ /*
+* this function is called just before we call linux
+* it prepares the processor for linux
+*
+* we turn off caches etc ...
+*/
+
+ disable_interrupts ();
+
+ /* turn off I/D-cache */
+ icache_disable();
+ dcache_disable();
+ /* flush I/D-cache */
+ cache_flush();
+
+ return 0;
+}
+
+static void cache_flush(void)
+{
+ unsigned long i = 0;
+ /* clean entire data cache */
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (i));
+ /* invalidate both caches and flush btb */
+ asm volatile("mcr p15, 0, %0, c7, c7, 0" : : "r" (i));
+ /* mem barrier to sync things */
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (i));
+}
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+
+#ifndef CONFIG_SYS_CACHELINE_SIZE
+#define CONFIG_SYS_CACHELINE_SIZE 32
+#endif
+
+void invalidate_dcache_all(void)
+{
+ asm volatile("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
+}
+
+void flush_dcache_all(void)
+{
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+static int check_cache_range(unsigned long start, unsigned long stop)
+{
+ int ok = 1;
+
+ if (start & (CONFIG_SYS_CACHELINE_SIZE - 1))
+ ok = 0;
+
+ if (stop & (CONFIG_SYS_CACHELINE_SIZE - 1))
+ ok = 0;
+
+ if (!ok)
+ debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
+ start, stop);
+
+ return ok;
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (!check_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm volatile("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (!check_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm volatile("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+ flush_dcache_range(start, start + size);
+}
+
+#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
+void invalidate_dcache_all(void)
+{
+}
+
+void flush_dcache_all(void)
+{
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+}
+#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
+
+#if !defined(CONFIG_SYS_ICACHE_OFF) || !defined(CONFIG_SYS_DCACHE_OFF)
+void enable_caches(void)
+{
+#ifndef CONFIG_SYS_ICACHE_OFF
+ icache_enable();
+#endif
+#ifndef CONFIG_SYS_DCACHE_OFF
+ dcache_enable();
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/arm1136/Makefile b/arch/arm/cpu/arm1136/Makefile
index 56a9390..5d6f0aa 100644
--- a/arch/arm/cpu/arm1136/Makefile
+++ b/arch/arm/cpu/arm1136/Makefile
@@ -6
[U-Boot] [PATCH v3 7/7] arm/rpi: Enable dcache
Now that mailbox driver supports cache flush and invalidation, we can enable dcache. Signed-off-by: Alexander Stein --- include/configs/rpi-common.h | 1 - include/configs/rpi_2.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index e75fb1e..43b460b 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -14,7 +14,6 @@ #define CONFIG_SYS_GENERIC_BOARD #define CONFIG_BCM2835 #define CONFIG_ARCH_CPU_INIT -#define CONFIG_SYS_DCACHE_OFF #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE 100 diff --git a/include/configs/rpi_2.h b/include/configs/rpi_2.h index 2e7e74f..0ecd399 100644 --- a/include/configs/rpi_2.h +++ b/include/configs/rpi_2.h @@ -9,6 +9,7 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BCM2836 +#define CONFIG_SYS_DCACHE_OFF #include "rpi-common.h" -- 2.4.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/7] arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw mailbox
When using dcache the setup data for the mailbox must be actually written
into memory before calling into firmware. Thus flush and invalidate the
memory.
Signed-off-by: Alexander Stein
---
Changes in v3:
* Use ARCH_DMA_MINALIGN instead of fixed 32
* Adjust comment in header
Changes in v2:
* Add hint in header about alignment requirements
* Invalidate cache after calling into mailbox
* round size up to next cacheline size
arch/arm/mach-bcm283x/include/mach/mbox.h | 3 +++
arch/arm/mach-bcm283x/mbox.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 54d369c..ff959c8 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -522,6 +522,9 @@ int bcm2835_mbox_call_raw(u32 chan, u32 send, u32 *recv);
* a termination value are expected to immediately follow the header in
* memory, as required by the property protocol.
*
+ * Each struct bcm2835_mbox_hdr passed must be allocated with
+ * ALLOC_CACHE_ALIGN_BUFFER(x, y, z) to ensure proper cache flush/invalidate.
+ *
* Returns 0 for success, any other value for error.
*/
int bcm2835_mbox_call_prop(u32 chan, struct bcm2835_mbox_hdr *buffer);
diff --git a/arch/arm/mach-bcm283x/mbox.c b/arch/arm/mach-bcm283x/mbox.c
index 1af9be7..311bd8f 100644
--- a/arch/arm/mach-bcm283x/mbox.c
+++ b/arch/arm/mach-bcm283x/mbox.c
@@ -111,9 +111,18 @@ int bcm2835_mbox_call_prop(u32 chan, struct
bcm2835_mbox_hdr *buffer)
dump_buf(buffer);
#endif
+ flush_dcache_range((unsigned long)buffer,
+ (unsigned long)((void *)buffer +
+ roundup(buffer->buf_size, ARCH_DMA_MINALIGN)));
+
ret = bcm2835_mbox_call_raw(chan, phys_to_bus((u32)buffer), &rbuffer);
if (ret)
return ret;
+
+ invalidate_dcache_range((unsigned long)buffer,
+ (unsigned long)((void *)buffer +
+ roundup(buffer->buf_size, ARCH_DMA_MINALIGN)));
+
if (rbuffer != phys_to_bus((u32)buffer)) {
printf("mbox: Response buffer mismatch\n");
return -1;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] ARM: bcm283x: Define CONFIG_SYS_CACHELINE_SIZE
The cacheline is always 32 bytes for arm1176 CPUs, so define it at board config level for cache handling code. Signed-off-by: Alexander Stein --- include/configs/rpi-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 1012cdd..e75fb1e 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -15,6 +15,7 @@ #define CONFIG_BCM2835 #define CONFIG_ARCH_CPU_INIT #define CONFIG_SYS_DCACHE_OFF +#define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE 100 #define CONFIG_SYS_TIMER_COUNTER \ -- 2.4.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/6] arm/rpi: Enable dcache
On Monday 20 July 2015, 23:00:04 wrote Alexander Stein: > Now that mailbox driver supports cache flush and invalidation, we can > enable dcache. > > Signed-off-by: Alexander Stein Well, I just noticed that the dwc2 driver does not support dache yet. I'm on the way to add that there too and will send v3. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] dcache support for Raspberry Pi 1
This patchset enables dcache support for Raspberry Pi 1.
First the cache support code for arm1136 and 1176 was merged.
CONFIG_SYS_CACHELINE_SIZE is defined as 32 bytes which is used as alignment
for mailbox buffer allocations.
Then rpi mailbox code has now dcache flush for writing the mailbox request and
a dcache invalidation for receiving the mailbox answer.
Finally the CONFIG_SYS_DCACHE_OFF switch got removed from rpi1 config. It is
still set for rpi2 config.
dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to
12.3 MiB/s.
This was tested by the following command:
> fatload mmc 0:1 ${kernel_addr_r} zImage
Changes in v2:
* Merge arm1136/1176 cache code
* Use cacheline size as mailbox buffer alignment
* Flush/invalidate mailbox buffer up to cacheline size
Alexander Stein (6):
arm1136: Remove dead code
arm1136/arm1176: Merge cache handling code
ARM: bcm283x: Define CONFIG_SYS_CACHELINE_SIZE
ARM: bcm283x: Allocate all mailbox buffers cacheline aligned
arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw
mailbox
arm/rpi: Enable dcache
arch/arm/cpu/arm11/Makefile | 8 ++
arch/arm/cpu/arm11/cpu.c | 150
arch/arm/cpu/arm1136/Makefile | 1 -
arch/arm/cpu/arm1136/cpu.c| 160 --
arch/arm/cpu/arm1176/Makefile | 4 +-
arch/arm/cpu/arm1176/cpu.c| 51 --
arch/arm/mach-bcm283x/include/mach/mbox.h | 4 +
arch/arm/mach-bcm283x/mbox.c | 9 ++
board/raspberrypi/rpi/rpi.c | 10 +-
drivers/video/bcm2835.c | 4 +-
include/configs/rpi-common.h | 2 +-
include/configs/rpi_2.h | 1 +
12 files changed, 183 insertions(+), 221 deletions(-)
create mode 100644 arch/arm/cpu/arm11/Makefile
create mode 100644 arch/arm/cpu/arm11/cpu.c
delete mode 100644 arch/arm/cpu/arm1136/cpu.c
delete mode 100644 arch/arm/cpu/arm1176/cpu.c
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] arm/rpi: Enable dcache
Now that mailbox driver supports cache flush and invalidation, we can enable dcache. Signed-off-by: Alexander Stein --- Changes in v2: * Only enable dcache on rpi1, but not on rpi2 include/configs/rpi-common.h | 1 - include/configs/rpi_2.h | 1 + 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index e75fb1e..43b460b 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -14,7 +14,6 @@ #define CONFIG_SYS_GENERIC_BOARD #define CONFIG_BCM2835 #define CONFIG_ARCH_CPU_INIT -#define CONFIG_SYS_DCACHE_OFF #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE 100 diff --git a/include/configs/rpi_2.h b/include/configs/rpi_2.h index 2e7e74f..0ecd399 100644 --- a/include/configs/rpi_2.h +++ b/include/configs/rpi_2.h @@ -9,6 +9,7 @@ #define CONFIG_SKIP_LOWLEVEL_INIT #define CONFIG_BCM2836 +#define CONFIG_SYS_DCACHE_OFF #include "rpi-common.h" -- 2.4.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] ARM: bcm283x: Allocate all mailbox buffers cacheline aligned
The mailbox buffer is required to be at least 16 bytes aligned, but for
cache invalidation and/or flush it needs to be cacheline aligned.
Use CONFIG_SYS_CACHELINE_SIZE alignment for all mailbox buffer allocations.
Signed-off-by: Alexander Stein
---
board/raspberrypi/rpi/rpi.c | 10 +-
drivers/video/bcm2835.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 96fe870..d5d3fec 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -182,7 +182,7 @@ u32 rpi_board_rev = 0;
int dram_init(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1,
CONFIG_SYS_CACHELINE_SIZE);
int ret;
BCM2835_MBOX_INIT_HDR(msg);
@@ -212,7 +212,7 @@ static void set_fdtfile(void)
static void set_usbethaddr(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1,
CONFIG_SYS_CACHELINE_SIZE);
int ret;
if (!models[rpi_board_rev].has_onboard_eth)
@@ -245,7 +245,7 @@ int misc_init_r(void)
static int power_on_module(u32 module)
{
- ALLOC_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1,
CONFIG_SYS_CACHELINE_SIZE);
int ret;
BCM2835_MBOX_INIT_HDR(msg_pwr);
@@ -269,7 +269,7 @@ static int power_on_module(u32 module)
static void get_board_rev(void)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_board_rev, msg, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_get_board_rev, msg, 1,
CONFIG_SYS_CACHELINE_SIZE);
int ret;
const char *name;
@@ -324,7 +324,7 @@ int board_init(void)
int board_mmc_init(bd_t *bis)
{
- ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_get_clock_rate, msg_clk, 1,
CONFIG_SYS_CACHELINE_SIZE);
int ret;
power_on_module(BCM2835_MBOX_POWER_DEVID_SDHCI);
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 1f18231..30e22cc 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -38,8 +38,8 @@ struct msg_setup {
void lcd_ctrl_init(void *lcdbase)
{
- ALLOC_ALIGN_BUFFER(struct msg_query, msg_query, 1, 16);
- ALLOC_ALIGN_BUFFER(struct msg_setup, msg_setup, 1, 16);
+ ALLOC_ALIGN_BUFFER(struct msg_query, msg_query, 1,
CONFIG_SYS_CACHELINE_SIZE);
+ ALLOC_ALIGN_BUFFER(struct msg_setup, msg_setup, 1,
CONFIG_SYS_CACHELINE_SIZE);
int ret;
u32 w, h;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw mailbox
When using dcache the setup data for the mailbox must be actually written
into memory before calling into firmware. Thus flush and invalidate the
memory.
Signed-off-by: Alexander Stein
---
Changes in v2:
* Add hint in header about alignment requirements
* Invalidate cache after calling into mailbox
* round size up to next cacheline size
arch/arm/mach-bcm283x/include/mach/mbox.h | 4
arch/arm/mach-bcm283x/mbox.c | 9 +
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 54d369c..ae1b904 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -522,6 +522,10 @@ int bcm2835_mbox_call_raw(u32 chan, u32 send, u32 *recv);
* a termination value are expected to immediately follow the header in
* memory, as required by the property protocol.
*
+ * Each struct bcm2835_mbox_hdr passed must be allocated with
+ * ALLOC_ALIGN_BUFFER(x, y, z, CONFIG_SYS_CACHELINE_SIZE) to ensure proper
+ * cache flush/invalidate.
+ *
* Returns 0 for success, any other value for error.
*/
int bcm2835_mbox_call_prop(u32 chan, struct bcm2835_mbox_hdr *buffer);
diff --git a/arch/arm/mach-bcm283x/mbox.c b/arch/arm/mach-bcm283x/mbox.c
index 1af9be7..740db0c 100644
--- a/arch/arm/mach-bcm283x/mbox.c
+++ b/arch/arm/mach-bcm283x/mbox.c
@@ -111,9 +111,18 @@ int bcm2835_mbox_call_prop(u32 chan, struct
bcm2835_mbox_hdr *buffer)
dump_buf(buffer);
#endif
+ flush_dcache_range((unsigned long)buffer,
+ (unsigned long)((void *)buffer +
+ roundup(buffer->buf_size, 32)));
+
ret = bcm2835_mbox_call_raw(chan, phys_to_bus((u32)buffer), &rbuffer);
if (ret)
return ret;
+
+ invalidate_dcache_range((unsigned long)buffer,
+ (unsigned long)((void *)buffer +
+ roundup(buffer->buf_size, 32)));
+
if (rbuffer != phys_to_bus((u32)buffer)) {
printf("mbox: Response buffer mismatch\n");
return -1;
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] arm1136/arm1176: Merge cache handling code
As both cores are similar merge the cache handling code for both CPUs
to arm11 directory.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm11/Makefile | 8 +++
arch/arm/cpu/arm11/cpu.c | 150 ++
arch/arm/cpu/arm1136/Makefile | 1 -
arch/arm/cpu/arm1136/cpu.c| 150 --
arch/arm/cpu/arm1176/Makefile | 4 +-
arch/arm/cpu/arm1176/cpu.c| 51 --
6 files changed, 161 insertions(+), 203 deletions(-)
create mode 100644 arch/arm/cpu/arm11/Makefile
create mode 100644 arch/arm/cpu/arm11/cpu.c
delete mode 100644 arch/arm/cpu/arm1136/cpu.c
delete mode 100644 arch/arm/cpu/arm1176/cpu.c
diff --git a/arch/arm/cpu/arm11/Makefile b/arch/arm/cpu/arm11/Makefile
new file mode 100644
index 000..2379b0f
--- /dev/null
+++ b/arch/arm/cpu/arm11/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y = cpu.o
diff --git a/arch/arm/cpu/arm11/cpu.c b/arch/arm/cpu/arm11/cpu.c
new file mode 100644
index 000..5d4b3c2
--- /dev/null
+++ b/arch/arm/cpu/arm11/cpu.c
@@ -0,0 +1,150 @@
+/*
+ * (C) Copyright 2004 Texas Insturments
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH
+ * Marius Groeger
+ *
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering,
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * CPU specific code
+ */
+
+#include
+#include
+#include
+
+static void cache_flush(void);
+
+int cleanup_before_linux (void)
+{
+ /*
+* this function is called just before we call linux
+* it prepares the processor for linux
+*
+* we turn off caches etc ...
+*/
+
+ disable_interrupts ();
+
+ /* turn off I/D-cache */
+ icache_disable();
+ dcache_disable();
+ /* flush I/D-cache */
+ cache_flush();
+
+ return 0;
+}
+
+static void cache_flush(void)
+{
+ unsigned long i = 0;
+ /* clean entire data cache */
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (i));
+ /* invalidate both caches and flush btb */
+ asm volatile("mcr p15, 0, %0, c7, c7, 0" : : "r" (i));
+ /* mem barrier to sync things */
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (i));
+}
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+
+#ifndef CONFIG_SYS_CACHELINE_SIZE
+#define CONFIG_SYS_CACHELINE_SIZE 32
+#endif
+
+void invalidate_dcache_all(void)
+{
+ asm volatile("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
+}
+
+void flush_dcache_all(void)
+{
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+static int check_cache_range(unsigned long start, unsigned long stop)
+{
+ int ok = 1;
+
+ if (start & (CONFIG_SYS_CACHELINE_SIZE - 1))
+ ok = 0;
+
+ if (stop & (CONFIG_SYS_CACHELINE_SIZE - 1))
+ ok = 0;
+
+ if (!ok)
+ debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
+ start, stop);
+
+ return ok;
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (!check_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm volatile("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (!check_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm volatile("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+ flush_dcache_range(start, start + size);
+}
+
+#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
+void invalidate_dcache_all(void)
+{
+}
+
+void flush_dcache_all(void)
+{
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+}
+#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
+
+#if !defined(CONFIG_SYS_ICACHE_OFF) || !defined(CONFIG_SYS_DCACHE_OFF)
+void enable_caches(void)
+{
+#ifndef CONFIG_SYS_ICACHE_OFF
+ icache_enable();
+#endif
+#ifndef CONFIG_SYS_DCACHE_OFF
+ dcache_enable();
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/arm1136/Makefile b/arch/arm/cpu/arm1136/Makefile
index 56a9390..5d6f0aa 100644
--- a/arch/arm/cpu/arm1136/Makefile
+++ b/arch/arm/cpu/arm1136/Makefile
@@ -6
[U-Boot] [PATCH v2 3/6] ARM: bcm283x: Define CONFIG_SYS_CACHELINE_SIZE
The cacheline is always 32 bytes for arm1176 CPUs, so define it at board config level for cache handling code. Signed-off-by: Alexander Stein --- include/configs/rpi-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 1012cdd..e75fb1e 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -15,6 +15,7 @@ #define CONFIG_BCM2835 #define CONFIG_ARCH_CPU_INIT #define CONFIG_SYS_DCACHE_OFF +#define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE 100 #define CONFIG_SYS_TIMER_COUNTER \ -- 2.4.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] arm1136: Remove dead code
Apparently lcd_panel_disable is not defined anywhere, so no config for
an arm1136 board would have set CONFIG_LCD. Remove the unused code.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm1136/cpu.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index a7aed4b..5d4b3c2 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -32,16 +32,6 @@ int cleanup_before_linux (void)
disable_interrupts ();
-#ifdef CONFIG_LCD
- {
- extern void lcd_disable(void);
- extern void lcd_panel_disable(void);
-
- lcd_disable(); /* proper disable of lcd & panel */
- lcd_panel_disable();
- }
-#endif
-
/* turn off I/D-cache */
icache_disable();
dcache_disable();
--
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1
On Friday 10 July 2015, 23:17:58 wrote Stephen Warren: > On 07/04/2015 03:48 AM, Alexander Stein wrote: > > This patchset enables dcache support for Raspberry Pi 1. > > First the cache support code was made similar to existing arm1136 code. > > The invalidate and flush functions were inprovoed to accept also > > non-cacheline > > aligned addresses. This reduces the cacheline size knowledge from generic > > code. > > As mentioned in some other responses, client code must be aware of the > cacheline size, so the cache management code shouldn't try to handle > misaligned requests, but should error out. > > BTW, ALLOC_ALIGN_BUFFER() is probably what you need to fix any > misbehaved client code. It turns out this is already used everywhere, but the aligned is only 16 instead of 32. Is there some neat define for the cache size to be used everywhere without defining it in the board config? This would make no sense as according to ARM1176 TRM the cache size is fixed to 32 bytes. So CONFIG_SYS_CACHELINE_SIZE is defined in arch/arm/cpu/arm1176/cpu.c if not defined at board config. I could use ALLOC_CACHE_ALIGN_BUFFER instead, but this would use an (unnecessary) 64 byte alignment, unless CONFIG_SYS_CACHELINE_SIZE is defined. Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] arm/rpi: Enable dcache
On Friday 10 July 2015, 23:24:58 wrote Stephen Warren: > On 07/04/2015 03:48 AM, Alexander Stein wrote: > > Now that mailbox driver supports cache flush and invalidation, we can > > enable dcache. > > Did you also test that HDMI output doesn't show any issues after this > change? I think there's already cache-flushing in the LCD console code, > so it should be fine, but best to check. I don't use HDMI on my board, just serial and SSH. But how may this affect that code if it is already flushing caches? Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] arm1176/cpu: Add icache and dcache support
On Friday 10 July 2015, 23:21:32 wrote Stephen Warren: > On 07/04/2015 03:48 AM, Alexander Stein wrote: > > The code is copied 1:1 from arm1136 which uses the same cp15 registers. > > Same comment here. Perhaps create a cache-armv6.c (or whatever name is > appropriate; I'm not sure if ARMv6 mandates caches work this way, or if > ARM11 is a better name, or ...? I know that cortex-m0 and cortex-m1 are also ARMv6(-M). I have no idea how cache works there or even if there is any. I think ARM11 seems more suitable for me. But where to put? Currently each CPU core has it's own directory. Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] arm1176/cpu: Match cache_flush to arm1136
On Friday 10 July 2015, 23:20:07 wrote Stephen Warren: > On 07/04/2015 03:48 AM, Alexander Stein wrote: > > This is effectively the same code but it also does a clean cache before > > invalidating and doing a memory barrier. > > Is it possible to share this function with arm1136 rather than > cut/pasting it? I guess it's pretty small so not a huge deal, but still. I guess this would be possible, but you would cross subdirectoy boundaries for arm1136 and arm1176. Dunno if this is acceptable or even if there are subtle differences between those. Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1
Hello Albert,
On Monday 06 July 2015, 23:26:41 wrote Albert ARIBAUD:
> On Mon, 06 Jul 2015 20:24:31 +0200, Alexander Stein
> wrote:
> > Hello Albert,
> >
> > On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD:
> > > On Sat, 4 Jul 2015 11:48:39 +0200, Alexander Stein
> > > wrote:
> > >
> > > > dcache supprt increases the MMC read performance on RPI 1 from 5,4
> > > > MiB/s to
> > > > 12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just
> > > > get
> > > > error messages about non-cacheline aligned address upon invalidation.
> > >
> > > Could it be that code needed to support dcache is not the same for
> > > rpi_2's bcm2836 than it is for rpi's bcm2835?
> >
> > Sure, bcm2835 is a armv6 while bcm2836 is a armv7.
> >
> > > Anyway: if code properly handles unaligned addresses then it should not
> > > throw an error message about it. Can you look into why the error is
> > > thrown?
> >
> > Apparently it does not handle non-cacheline aligned addresses transparently
> > or silently.
> >
> > Here is the part of the code:
> > > static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)
> > > {
> > > /*
> > >* If start address is not aligned to cache-line do not
> > >* invalidate the first cache-line
> > >*/
> > > if (start & (line_len - 1)) {
> > > printf("ERROR: %s - start address is not aligned - 0x%08x\n",
> > > __func__, start);
> > > /* move to next cache line */
> > > start = (start + line_len - 1) & ~(line_len - 1);
> > > }
> >
> > I don't know why (a) the cache invalidation is only done from the next
> > cache line and (b) why this can't be done transparently without printing an
> > error.
> > But currently I'm not keen on fiddling with armv7 caches.
>
> Well, I can see why.
>
> Let's assume were invalidating the second half of a cache line because
> that's where a buffer starts which we want to force-read from external
> memory because some device fille dthis buffer with important data.
>
> Now, most probably the compiler and linker will have used the addresses
> before our buffer to map some variables which may be unrelated to the
> buffer.
>
> At the time we're told to invalidate the buffer, these variables may be
> modified in-cache but not yet written out to external memory. If we
> invalidate the first cache line, then we erase these modifications --
> they're lost.
>
> Now, this is an unsolvable problem -- we can't flush these variables
> before invalidating, because then we would flush the whole cache line,
> which would overwrite and trash the buffer in external memory.
>
> So anyway, we're doomed; there is nothing we can do -- hence the ERROR
> message. From the on, we can either just give up and go hang(), or we
> can try to save whatever can be, skip the half cache line and start
> invalidating at the next boundary.
>
> (same goes for the last address: it has to be at the end of a cache
> line, or else we can neither invalidate nor flush.)
Thanks for thise detailed explanation. I agree this is really a problem.
But how should this behandled: The raspberry pi messagebox handling sends a
message which might have more or less arbitrary length.
I think it might be possible to achieve in every case that those message starts
at the beginning of a cacheline. But the end might be
at different positions with different messages sent. You must flush your data
to get the firmware actually see this and you must invalidate to eventually
read the answer data which is located at the same position.
I guess I might just have not hit your described problem in my board (yet).
Best regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1
Hello Albert,
On Monday 06 July 2015, 09:39:40 wrote Albert ARIBAUD:
> On Sat, 4 Jul 2015 11:48:39 +0200, Alexander Stein
> wrote:
>
> > dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to
> > 12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just get
> > error messages about non-cacheline aligned address upon invalidation.
>
> Could it be that code needed to support dcache is not the same for
> rpi_2's bcm2836 than it is for rpi's bcm2835?
Sure, bcm2835 is a armv6 while bcm2836 is a armv7.
> Anyway: if code properly handles unaligned addresses then it should not
> throw an error message about it. Can you look into why the error is
> thrown?
Apparently it does not handle non-cacheline aligned addresses transparently or
silently.
Here is the part of the code:
> static void v7_dcache_inval_range(u32 start, u32 stop, u32 line_len)
> {
> /*
>* If start address is not aligned to cache-line do not
>* invalidate the first cache-line
>*/
> if (start & (line_len - 1)) {
> printf("ERROR: %s - start address is not aligned - 0x%08x\n",
> __func__, start);
> /* move to next cache line */
> start = (start + line_len - 1) & ~(line_len - 1);
> }
I don't know why (a) the cache invalidation is only done from the next cache
line and (b) why this can't be done transparently without printing an error.
But currently I'm not keen on fiddling with armv7 caches.
Best regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] arm1176/cpu: Add icache and dcache support
The code is copied 1:1 from arm1136 which uses the same cp15 registers.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm1176/cpu.c | 97 ++
1 file changed, 97 insertions(+)
diff --git a/arch/arm/cpu/arm1176/cpu.c b/arch/arm/cpu/arm1176/cpu.c
index 24b5cc7..2ff0e25 100644
--- a/arch/arm/cpu/arm1176/cpu.c
+++ b/arch/arm/cpu/arm1176/cpu.c
@@ -51,3 +51,100 @@ static void cache_flush(void)
/* mem barrier to sync things */
asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (i));
}
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+
+#ifndef CONFIG_SYS_CACHELINE_SIZE
+#define CONFIG_SYS_CACHELINE_SIZE 32
+#endif
+
+void invalidate_dcache_all(void)
+{
+ asm volatile("mcr p15, 0, %0, c7, c6, 0" : : "r" (0));
+}
+
+void flush_dcache_all(void)
+{
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+static int check_cache_range(unsigned long start, unsigned long stop)
+{
+ int ok = 1;
+
+ if (start & (CONFIG_SYS_CACHELINE_SIZE - 1))
+ ok = 0;
+
+ if (stop & (CONFIG_SYS_CACHELINE_SIZE - 1))
+ ok = 0;
+
+ if (!ok)
+ debug("CACHE: Misaligned operation at range [%08lx, %08lx]\n",
+ start, stop);
+
+ return ok;
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (!check_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm volatile("mcr p15, 0, %0, c7, c6, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+ if (!check_cache_range(start, stop))
+ return;
+
+ while (start < stop) {
+ asm volatile("mcr p15, 0, %0, c7, c14, 1" : : "r" (start));
+ start += CONFIG_SYS_CACHELINE_SIZE;
+ }
+
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+ flush_dcache_range(start, start + size);
+}
+
+#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
+void invalidate_dcache_all(void)
+{
+}
+
+void flush_dcache_all(void)
+{
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+}
+#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
+
+#if !defined(CONFIG_SYS_ICACHE_OFF) || !defined(CONFIG_SYS_DCACHE_OFF)
+void enable_caches(void)
+{
+#ifndef CONFIG_SYS_ICACHE_OFF
+ icache_enable();
+#endif
+#ifndef CONFIG_SYS_DCACHE_OFF
+ dcache_enable();
+#endif
+}
+#endif
--
2.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] arm1176/cpu: Align cache flushing addresses to cacheline size
cache flushing addresses must be cacheline size aligned, so mask the
start and stop address appropriately.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm1176/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/cpu/arm1176/cpu.c b/arch/arm/cpu/arm1176/cpu.c
index 2ff0e25..5ac8e79 100644
--- a/arch/arm/cpu/arm1176/cpu.c
+++ b/arch/arm/cpu/arm1176/cpu.c
@@ -57,6 +57,7 @@ static void cache_flush(void)
#ifndef CONFIG_SYS_CACHELINE_SIZE
#define CONFIG_SYS_CACHELINE_SIZE 32
#endif
+#define CACHLINE_MASK (CONFIG_SYS_CACHELINE_SIZE - 1)
void invalidate_dcache_all(void)
{
@@ -88,6 +89,9 @@ static int check_cache_range(unsigned long start, unsigned
long stop)
void invalidate_dcache_range(unsigned long start, unsigned long stop)
{
+ stop = (stop + CACHLINE_MASK) & ~CACHLINE_MASK;
+ start &= ~CACHLINE_MASK;
+
if (!check_cache_range(start, stop))
return;
@@ -99,6 +103,9 @@ void invalidate_dcache_range(unsigned long start, unsigned
long stop)
void flush_dcache_range(unsigned long start, unsigned long stop)
{
+ stop = (stop + CACHLINE_MASK) & ~CACHLINE_MASK;
+ start &= ~CACHLINE_MASK;
+
if (!check_cache_range(start, stop))
return;
--
2.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw mailbox
When using dcache the setup data for the mailbox must be actually written into memory before calling into firmware. Thus flush and invalidate the memory. Signed-off-by: Alexander Stein --- arch/arm/mach-bcm283x/mbox.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-bcm283x/mbox.c b/arch/arm/mach-bcm283x/mbox.c index 1af9be7..237c76c 100644 --- a/arch/arm/mach-bcm283x/mbox.c +++ b/arch/arm/mach-bcm283x/mbox.c @@ -111,6 +111,12 @@ int bcm2835_mbox_call_prop(u32 chan, struct bcm2835_mbox_hdr *buffer) dump_buf(buffer); #endif + flush_dcache_range((unsigned long)buffer, + (unsigned long)((void *)buffer + + buffer->buf_size)); + invalidate_dcache_range((unsigned long)buffer, + (unsigned long)((void *)buffer + + buffer->buf_size)); ret = bcm2835_mbox_call_raw(chan, phys_to_bus((u32)buffer), &rbuffer); if (ret) return ret; -- 2.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] arm1176/cpu: Match cache_flush to arm1136
This is effectively the same code but it also does a clean cache before
invalidating and doing a memory barrier.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm1176/cpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/arm1176/cpu.c b/arch/arm/cpu/arm1176/cpu.c
index 2d81651..24b5cc7 100644
--- a/arch/arm/cpu/arm1176/cpu.c
+++ b/arch/arm/cpu/arm1176/cpu.c
@@ -41,11 +41,13 @@ int cleanup_before_linux (void)
return 0;
}
-/* flush I/D-cache */
-static void cache_flush (void)
+static void cache_flush(void)
{
+ unsigned long i = 0;
+ /* clean entire data cache */
+ asm volatile("mcr p15, 0, %0, c7, c10, 0" : : "r" (i));
/* invalidate both caches and flush btb */
- asm ("mcr p15, 0, %0, c7, c7, 0": :"r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c7, 0" : : "r" (i));
/* mem barrier to sync things */
- asm ("mcr p15, 0, %0, c7, c10, 4": :"r" (0));
+ asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (i));
}
--
2.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] dcache support for Raspberry Pi 1
This patchset enables dcache support for Raspberry Pi 1.
First the cache support code was made similar to existing arm1136 code.
The invalidate and flush functions were inprovoed to accept also non-cacheline
aligned addresses. This reduces the cacheline size knowledge from generic
code.
Then rpi mailbox code has now dcache flush for writing the mailbox request and
a dcache invalidation for receiving the mailbox answer.
Finally the CONFIG_SYS_DCACHE_OFF switch got removed from rpi config.
dcache supprt increases the MMC read performance on RPI 1 from 5,4 MiB/s to
12.3 MiB/s. It doesn't seem to have any affect on RPI 2 though. I just get
error messages about non-cacheline aligned address upon invalidation.
The performance stucks at 1.2 MiB/s.
This was tested by the following command:
> fatload mmc 0:1 ${kernel_addr_r} zImage
Alexander Stein (5):
arm1176/cpu: Match cache_flush to arm1136
arm1176/cpu: Add icache and dcache support
arm1176/cpu: Align cache flushing addresses to cacheline size
arm/mach-bcm283x/mbox: Flush and invalidate dcache when using fw
mailbox
arm/rpi: Enable dcache
arch/arm/cpu/arm1176/cpu.c | 114 +--
arch/arm/mach-bcm283x/mbox.c | 6 +++
include/configs/rpi-common.h | 1 -
3 files changed, 116 insertions(+), 5 deletions(-)
--
2.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] arm/rpi: Enable dcache
Now that mailbox driver supports cache flush and invalidation, we can enable dcache. Signed-off-by: Alexander Stein --- include/configs/rpi-common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h index 1012cdd..dd638c4 100644 --- a/include/configs/rpi-common.h +++ b/include/configs/rpi-common.h @@ -14,7 +14,6 @@ #define CONFIG_SYS_GENERIC_BOARD #define CONFIG_BCM2835 #define CONFIG_ARCH_CPU_INIT -#define CONFIG_SYS_DCACHE_OFF #define CONFIG_SYS_TIMER_RATE 100 #define CONFIG_SYS_TIMER_COUNTER \ -- 2.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] mmc: bcm2835_sdhci: Use calloc to allocate bcm2835_sdhci_host
Any feedback on this?
Best regards,
Alexander
On Friday 17 April 2015, 17:33:17 wrote Alexander Stein:
> We need to clear the allocated memory explicitly as the included
> struct sdhci_host has function pointers. Those are compared to NULL to
> test if this (optional) feature is supported. Leaving them undefined let
> u-boot jump to arbitrary memory.
>
> Signed-off-by: Alexander Stein
> ---
> drivers/mmc/bcm2835_sdhci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
> index 92f7d89..127dbe3 100644
> --- a/drivers/mmc/bcm2835_sdhci.c
> +++ b/drivers/mmc/bcm2835_sdhci.c
> @@ -154,9 +154,9 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
> struct bcm2835_sdhci_host *bcm_host;
> struct sdhci_host *host;
>
> - bcm_host = malloc(sizeof(*bcm_host));
> + bcm_host = calloc(1, sizeof(*bcm_host));
> if (!bcm_host) {
> - printf("sdhci_host malloc fail!\n");
> + printf("sdhci_host calloc fail!\n");
> return 1;
> }
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] mmc: bcm2835_sdhci: Use calloc to allocate bcm2835_sdhci_host
We need to clear the allocated memory explicitly as the included
struct sdhci_host has function pointers. Those are compared to NULL to
test if this (optional) feature is supported. Leaving them undefined let
u-boot jump to arbitrary memory.
Signed-off-by: Alexander Stein
---
drivers/mmc/bcm2835_sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
index 92f7d89..127dbe3 100644
--- a/drivers/mmc/bcm2835_sdhci.c
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -154,9 +154,9 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
struct bcm2835_sdhci_host *bcm_host;
struct sdhci_host *host;
- bcm_host = malloc(sizeof(*bcm_host));
+ bcm_host = calloc(1, sizeof(*bcm_host));
if (!bcm_host) {
- printf("sdhci_host malloc fail!\n");
+ printf("sdhci_host calloc fail!\n");
return 1;
}
--
2.3.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot does not build when lensfun is installed on host system
s/aisimage.c:35:2: warning: (near initialization for 'aisimage_cmds[12]') [enabled by default] tools/aisimage.c:35:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:35:2: warning: (near initialization for 'aisimage_cmds[12]') [enabled by default] tools/aisimage.c:36:2: warning: braces around scalar initializer [enabled by default] tools/aisimage.c:36:2: warning: (near initialization for 'aisimage_cmds[13]') [enabled by default] tools/aisimage.c:36:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:36:2: warning: (near initialization for 'aisimage_cmds[13]') [enabled by default] tools/aisimage.c:36:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:36:2: warning: (near initialization for 'aisimage_cmds[13]') [enabled by default] tools/aisimage.c:37:2: warning: braces around scalar initializer [enabled by default] tools/aisimage.c:37:2: warning: (near initialization for 'aisimage_cmds[14]') [enabled by default] tools/aisimage.c:37:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:37:2: warning: (near initialization for 'aisimage_cmds[14]') [enabled by default] tools/aisimage.c:37:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:37:2: warning: (near initialization for 'aisimage_cmds[14]') [enabled by default] tools/aisimage.c:38:2: warning: braces around scalar initializer [enabled by default] tools/aisimage.c:38:2: warning: (near initialization for 'aisimage_cmds[15]') [enabled by default] tools/aisimage.c:38:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:38:2: warning: (near initialization for 'aisimage_cmds[15]') [enabled by default] tools/aisimage.c:38:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:38:2: warning: (near initialization for 'aisimage_cmds[15]') [enabled by default] tools/aisimage.c:39:2: warning: braces around scalar initializer [enabled by default] tools/aisimage.c:39:2: warning: (near initialization for 'aisimage_cmds[16]') [enabled by default] tools/aisimage.c:39:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:39:2: warning: (near initialization for 'aisimage_cmds[16]') [enabled by default] tools/aisimage.c:39:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:39:2: warning: (near initialization for 'aisimage_cmds[16]') [enabled by default] tools/aisimage.c:40:2: warning: braces around scalar initializer [enabled by default] tools/aisimage.c:40:2: warning: (near initialization for 'aisimage_cmds[17]') [enabled by default] tools/aisimage.c:40:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:40:2: warning: (near initialization for 'aisimage_cmds[17]') [enabled by default] tools/aisimage.c:40:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:40:2: warning: (near initialization for 'aisimage_cmds[17]') [enabled by default] tools/aisimage.c:41:2: warning: braces around scalar initializer [enabled by default] tools/aisimage.c:41:2: warning: (near initialization for 'aisimage_cmds[18]') [enabled by default] tools/aisimage.c:41:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:41:2: warning: (near initialization for 'aisimage_cmds[18]') [enabled by default] tools/aisimage.c:41:2: warning: excess elements in scalar initializer [enabled by default] tools/aisimage.c:41:2: warning: (near initialization for 'aisimage_cmds[18]') [enabled by default] tools/aisimage.c: In function 'aisimage_print_header': tools/aisimage.c:151:4: warning: implicit declaration of function 'get_table_entry_name' [-Wimplicit-function-declaration] tools/aisimage.c:151:4: warning: format '%s' expects argument of type 'char *', but argument 3 has type 'int' [-Wformat] tools/aisimage.c: In function 'aisimage_generate': tools/aisimage.c:317:5: warning: implicit declaration of function 'get_table_entry_id' [-Wimplicit-function-declaration] tools/aisimage.c:335:25: error: request for member 'sname' in something not a structure or union tools/aisimage.c: In function 'aisimage_check_image_types': tools/aisimage.c:366:14: error: 'IH_TYPE_AISIMAGE' undeclared (first use in this function) tools/aisimage.c:366:14: note: each undeclared identifier is reported only once for each function it appears in tools/aisimage.c:370:1: warning: control reaches end of non-void function [-Wreturn-type] make[1]: *** [tools/aisimage.o] Error 1 make: *** [tools] Error 2 -- Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH Am Windrad 2 08468 Heinsdorfergrund Tel.: 03765 38600-1156 Fax: 03765 38600-4100 Email: alexander.st...@systec-electronic.com Website: www.systec-electronic.com Managing Director: Dipl.-Phys. Siegmar Schmidt Commercial registry: Amtsgericht Chemnitz, HRB 28082 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot-up time optimization. Where to start?
Dear Wolfgang, Am Donnerstag, 5. Mai 2011, 07:32:20 schrieb Wolfgang Denk: > In message <201105030848.17576.alexander.st...@systec-electronic.com> you wrote: > > This specific version was selected due to relocation problems on ARM. But > > I expect the dcache doesn't have that big influence on the named code > > part as the environment is already in RAM. > > Your expectation is most likely completely wrong. Reading from / > writing to uncached RAM is painfully slow compared to a system with > caches turned on. And if you - as I speculate - need to checksum a > huge amount of data, this will delay things without need. > > > Are you also still using the old environment code in your port, or is > the new, hash table based one? When using the old code, there are > additional penalties for using a needlessly big environment as each > call to setenv() will recalculate the checksum. I was digging into this problem for a short time. And yes, the CRC checksumcalculation takes about 25ms each run. So setenv is called for each stdin,stdout and stderr. which sums up to ~75ms. So you're right this is the old environment code. Here a dcache will speed up the execution of course. But our standard startup just stars U-Boot and copies the Linux kernel into RAM and starts it. There is not much use of dcache during copy here. > > > (III) you are running on a narrow > > > system bus (16 bit) with non-optimal RAM timings; > > > > It is using a 32-Bit RAM-Bus. So, no. > > And your NOR flash? It is connected 16-bit like most devices only support, but it is setup to use page read mode. > And your memory timings? Should be pretty good. > > > (IV) you do all this > > > with caches turned off; > > > > dcaches should be off, while icaches are on. So yes and no. > > DC of makes things awfully slow. See comments of commits c3330e9, > 95c6f6d and 7e4a9e6 - for plain RAM bound operations like > copying/uncompressing an image from RAM to RAM switchign on the DC can > accelerate the system by a factor of up to >15. Yes, from RAM to RAM, dcache will help a lot. But we neither copy from RAM to RAM nor do we uncompressing. > > > (V) you measure some numbers but you don;t > > > understand what they mean. > > > > These numbers show me that this part of code increases the start time of > > a considerable amount. > > You don;t even understand that you have > 100 KiB of environment size > which gets checksummed without need. Mh, this might be an option for further ports. > Fact is, the code that you claim takes 100 (or 500) ms to run has no > potential for such a long run time unless your system is seriously > misconfigured. I guess it runs at least 100 times faster on all > systems I have access to. Well, as already said this is related to CRC calculation of environment. I did a fast port to v2011.03 and the setenv is a lot faster, which is due the new env code base. But I also noticed the time until kernel_entry is called is about 30ms later after reset than on the old code base. But I didn't investigate any time further to see what caused this. But AFAICS also the new U-Boot code doesn't enable dcache on ARM1136 either. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot-up time optimization. Where to start?
Dear Wolfgang,
Am Montag, 2. Mai 2011, 19:00:47 schrieb Wolfgang Denk:
> In message <201105021640.27241.alexander.st...@systec-electronic.com> you
wrote:
> > Ok, let me be more precise on this.
> > We used U-Boot v2010.09 on a custom board running on an I.MX35 (ARM1136).
>
> Let's summarize known facts:
>
> 1. You are talking about an out-of-tree port, i. e. code which is
>completely unknown here, so it is basicly impossible to comment.
>We can barely speculate.
I'm aware of that. But on the other hand, cmd_nvedit.c and console.c are both
generic parts.
As Detlev have written, this is not the cause of the problem. Let's see if I
find time again for this.
> 2. This is an ARM board.
>
> 3. This is an old version before cache support for ARM was added.
This specific version was selected due to relocation problems on ARM. But I
expect the dcache doesn't have that big influence on the named code part as
the environment is already in RAM.
> > We noticed the following code snippet took relatively long.
> >
> > From common/console.c in console_init_r(void):
> > > /* Setting environment variables */
> > > for (i = 0; i < 3; i++) {
> > >
> > > setenv(stdio_names[i], stdio_devices[i]->name);
> > >
> > > }
> >
> > We added PIN toggling around this part of code and measured something
> > >100ms. A collegue said it was ~100ms, I remembered ~500ms. Dunno who is
> > right.
>
> Both numbers are way off.
>
> Let me speculate: (I) you have a _huge_ environment allocated for your
> board, probably > 100 KiB or more;
> Environment size: 2098/131067 bytes
So, no.
> (II) you are loading it from a slow
> storage device, probably NAND flash;
The environment is stored in NOR-Flash. So, no.
> (III) you are running on a narrow
> system bus (16 bit) with non-optimal RAM timings;
It is using a 32-Bit RAM-Bus. So, no.
> (IV) you do all this
> with caches turned off;
dcaches should be off, while icaches are on. So yes and no.
> (V) you measure some numbers but you don;t
> understand what they mean.
These numbers show me that this part of code increases the start time of a
considerable amount.
The workaround resulted in a faster startup without notable side effect.
I'm aware this is not the fix of the problem.
So yes and no.
> I bet some beer that at least 3 of these speculations hit the point.
You better not want to bet here :-)
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot-up time optimization. Where to start?
Hi Detlev,
Am Montag, 2. Mai 2011, 17:31:15 schrieb Detlev Zundel:
> Hi Alexander,
>
> > Dear Wolfgang,
> >
> > Am Mittwoch, 27. April 2011, 21:08:50 schrieb Wolfgang Denk:
> >> In message <201104271759.11818.alexander.st...@systec-electronic.com>
> >> you
> >
> > wrote:
> >> > Setting stdin, stdout and stderr takes a lot of time (IIRC ~500ms).
> >> > Which IMO is useless on a bootloader without LCD support.
> >>
> >> Statements like this are completely worhtless if you don;t tell
> >> exactly on which architecture and board, and with which exact version
> >> of U-Boot such numbers have been measured.
> >
> > Ok, let me be more precise on this.
> > We used U-Boot v2010.09 on a custom board running on an I.MX35 (ARM1136).
> > We noticed the following code snippet took relatively long.
> >
> >>From common/console.c in console_init_r(void):
> >> /* Setting environment variables */
> >> for (i = 0; i < 3; i++) {
> >>
> >>setenv(stdio_names[i], stdio_devices[i]->name);
> >>
> >> }
> >
> > We added PIN toggling around this part of code and measured something
> > >100ms. A collegue said it was ~100ms, I remembered ~500ms. Dunno who is
> > right.
>
> It doesn't really matter who is right - 100ms is way off for setting
> these variables. Looking into common/cmd_nvedit.c, these variables have
> a special handling and there are ifdef's involved, so its not
> straightforward to read. You should really find out, where in there the
> time is spent for your board and fix the problem ;)
Our 'fix' was removing the stated lines at all.
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot-up time optimization. Where to start?
Dear Wolfgang,
Am Mittwoch, 27. April 2011, 21:08:50 schrieb Wolfgang Denk:
> In message <201104271759.11818.alexander.st...@systec-electronic.com> you
wrote:
> > Setting stdin, stdout and stderr takes a lot of time (IIRC ~500ms). Which
> > IMO is useless on a bootloader without LCD support.
>
> Statements like this are completely worhtless if you don;t tell
> exactly on which architecture and board, and with which exact version
> of U-Boot such numbers have been measured.
Ok, let me be more precise on this.
We used U-Boot v2010.09 on a custom board running on an I.MX35 (ARM1136).
We noticed the following code snippet took relatively long.
>From common/console.c in console_init_r(void):
> /* Setting environment variables */
> for (i = 0; i < 3; i++) {
> setenv(stdio_names[i], stdio_devices[i]->name);
> }
We added PIN toggling around this part of code and measured something >100ms.
A collegue said it was ~100ms, I remembered ~500ms. Dunno who is right.
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot-up time optimization. Where to start?
Hi, Am Mittwoch, 27. April 2011, 15:39:18 schrieb Simon Schwarz: > I just started to work on my bachelor thesis. It is about "Linux boot-up > time optimization". The past days I spend analyzing what consumes the most > time in the boot process. > > I found that u-boot takes pretty much as long as the whole Linux kernel > (the one we are using). > > I started digging into the source and I think I have a big picture of what > is going on. I already learned from the mailing list that it is a good idea > to start a discussion early if you plan to change something and want it > upstream. At this point of my thesis I'am free to choose where I start - > only string attached is that if it is platform specific it has to be TI > OMAP3. > > So here is my question: Where do you see the most potential to optimize > u-boot? Setting stdin, stdout and stderr takes a lot of time (IIRC ~500ms). Which IMO is useless on a bootloader without LCD support. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can't erase or read NOR using mtd part-id
Hello, On Wednesday 09 February 2011, 17:16:37 Alexandre Gambier wrote: > thanks for your reply. > I'm running u-boot 1.3.1. I got it from STLinux. ouch, that's pretty old. > I will try to set CONFIG_JFFS2. > But does it mean it will erase the partition using JFFS2 ? No, the feature depended on both MTDPARTS and JFFS2 which has changed by now. If this doesn't work. I can't help you (see above) Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can't erase or read NOR using mtd part-id
Hello, On Wednesday 09 February 2011, 16:52:35 Alexandre Gambier wrote: > I'm using u-boot to boot a Linux-based device. Which version og u-boot are you running? > I created some MTD partitions for my NOR and NAND flashes. > > Here is the configuration: > > device nor0 , # parts = 4 > #: namesizeoffset mask_flags > 0: U-Boot 0x0008 0x 0 > 1: Environment 0x0002 0x0008 0 > 2: Kernel 0x0040 0x000a 0 > 3: FreeNOR 0x0036 0x004a 0 > > device nand0 , # parts = 2 > #: namesizeoffset mask_flags > 0: FS 0x0200 0x 0 > 1: FreeNAND0x0600 0x0200 0 > > active partition: nor0,0 - (U-Boot) 0x0008 @ 0x > > defaults: > mtdids : nor0=NOR,nand0=NAND > mtdparts: > mtdparts=NOR:512k(U-Boot),128k(Environment),4M(Kernel),-(FreeNOR);NAND:32M( > FS),-(FreeNAND) > > When I want to erase the U-Boot partition I can't use the command `erase > U-Boot`, the following error occurs : "incorrect device type in U-Boot". > I must use the command `erase 1:0-7`. > > Is-it normal ? Some old version also had to set CONFIG_JFFS2 to get erase & friends to accept mtdparts. HTH Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm relocation: Fix calculation of board_init_r
Signed-off-by: Alexander Stein --- Hello, I just played a bit with my at91sam9g20ek and tried using a new u-boot. So I compiled 656b990daa84bfdd512407ee2e3d2610e305a455 (atmel/wip110202) load it into memory using jtag to 0x2200 while it was linked to 0x2000. I stepped through the relocation code and at start.S:291 'mov pc, lr' the pc gets an invalid address (0x25F81D70 while memory ends at 0x2400). While stepping to start.S:286 some registers have the following contents: r0: 0d70 r1: 2200 r9: 03f81000 lr: 22000d70 The content if r0 seems ok, but r1 seems wrong, it should be 0x2000. Indeed r1 should contain the linked address of _start not the address relative from the current code. Just for the records, here is the output of u-boot while DEBUG is set in board.c: U-Boot 2010.12-00322-g656b990-dirty (Feb 03 2011 - 20:40:07) U-Boot code: 2000 -> 2002DAE8 BSS: -> 2006EE80 CPU: AT91SAM9G20 Crystal frequency: 18.432 MHz CPU clock: 396.288 MHz Master clock : 132.096 MHz monitor len: 0006EE80 ramsize: 0400 TLB table at: 23ff Top of RAM usable for U-Boot at: 23ff Reserving 443k for U-Boot at: 23f81000 Reserving 644k for malloc() at: 23ee Reserving 24 Bytes for Board Info at: 23edffe8 Reserving 144 Bytes for Global Data at: 23edff58 New Stack Pointer is: 23edff50 RAM Configuration: Bank #0: 2000 64 MiB relocation Offset is: 03f81000 If I load u-boot to the linking address (no relocation needed), everything works fine, obviously. Best regards, Alexander arch/arm/cpu/arm926ejs/start.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index eb93ac9..f4c177e 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -281,7 +281,7 @@ _nand_boot_ofs: .word nand_boot #else ldr r0, _board_init_r_ofs - adr r1, _start + ldr r1, _TEXT_BASE add lr, r0, r1 add lr, lr, r9 /* setup parameters for board_init_r */ -- 1.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] AT91 cleanup, was: Re: [PATCH 02/11] at91: Add USART & DBGU base addres s defines
Hello, On Tuesday 02 November 2010, 15:11:00 Reinhard Meyer wrote: > I leaped a bit ahead there, and did some cleanups already. Note that they > are not complete and are up for discussion. In order to avoid flooding the > list with patches, you can have a look at u-boot-atmel, at91cleanup > branch. At a first look it seems OK to me. Could be a good starting base. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] at91: Add defines for spi SoC access
Dear Reinhard, On Monday 01 November 2010, 13:31:38 Reinhard Meyer wrote: > In this particular case the driver is not yet using the (existing) struct > at91_spi at all > > > WAIT!!! > > There is the COMMON driver atmel_spi.c with atmel_spi.h in drivers/spi. > > There need not be and should not be an at91_spi.h; or do I miss > something here? Well, the cause for adding those defines is atmel_dataflash_spi.c not atmel_spi.c. See also PATCH 8/11 Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/11] at91: Add USART & DBGU base address defines
Dear Andreas, On Monday 01 November 2010, 11:57:14 Andreas Bießmann wrote: > Am 01.11.2010 um 09:29 schrieb Alexander Stein: > > Signed-off-by: Alexander Stein > > --- > > arch/arm/include/asm/arch-at91/at91cap9.h| 12 > > arch/arm/include/asm/arch-at91/at91sam9260.h |7 +++ > > arch/arm/include/asm/arch-at91/at91sam9261.h |4 > > arch/arm/include/asm/arch-at91/at91sam9263.h |3 +++ > > arch/arm/include/asm/arch-at91/at91sam9g45.h |5 + > > arch/arm/include/asm/arch-at91/at91sam9rl.h |4 > > 6 files changed, 31 insertions(+), 4 deletions(-) > > > > --- a/arch/arm/include/asm/arch-at91/at91sam9g45.h > > +++ b/arch/arm/include/asm/arch-at91/at91sam9g45.h > > @@ -51,9 +51,14 @@ > > #define AT91SAM9G45_ID_VDEC 30 /* Video Decoder */ > > #define AT91SAM9G45_ID_IRQ0 31 /* Advanced Interrupt Controller */ > > > > +#define AT91_USART0_BASE 0xfff8c000 > > +#define AT91_USART1_BASE 0xfff9 > > +#define AT91_USART2_BASE 0xfff94000 > > +#define AT91_USART3_BASE 0xfff98000 > > #define AT91_EMAC_BASE 0xfffbc000 > > #define AT91_SMC_BASE 0xe800 > > #define AT91_MATRIX_BASE0xea00 > > +#define AT91_DBGU_BASE 0xee00 > > #define AT91_PIO_BASE 0xf200 > > #define AT91_PMC_BASE 0xfc00 > > #define AT91_RSTC_BASE 0xfd00 > > diff --git a/arch/arm/include/asm/arch-at91/at91sam9rl.h > > b/arch/arm/include/asm/arch-at91/at91sam9rl.h index 8eb0d4f..ffa6687 > > 100644 > > > > > > --- a/arch/arm/include/asm/arch-at91/at91sam9rl.h > > +++ b/arch/arm/include/asm/arch-at91/at91sam9rl.h > > @@ -44,6 +44,10 @@ > > #define AT91SAM9RL_ID_AC97C 24 /* AC97 Controller */ > > #define AT91SAM9RL_ID_IRQ0 31 /* Advanced Interrupt Controller (IRQ0) */ > > > > +#define AT91_US0_BASE 0xfffb > > +#define AT91_US1_BASE 0xfffb4000 > > +#define AT91_US2_BASE 0xfffb8000 > > +#define AT91_US3_BASE 0xfffbc000 > > #define AT91_SDRAMC_BASE0xea00 > > #define AT91_SMC_BASE 0xec00 > > #define AT91_MATRIX_BASE0xee00 > > can we just use one naming scheme here? I dunno whether it should be > AT91_USx or AT91_USARTx but it should be the same in any case. Yes, sure. I justed copied the dfine and reworded it to match the AT91_$COMPONENT_BASE scheme. Always using USARTx is fine though. Best regards, Alexander Stein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] at91: Add defines for spi SoC access
On Monday 01 November 2010, 09:43:57 Reinhard Meyer wrote:
> Dear Alexander Stein,
>
> > Signed-off-by: Alexander Stein
> > ---
> >
> > arch/arm/include/asm/arch-at91/at91_spi.h | 14 ++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-at91/at91_spi.h
> > b/arch/arm/include/asm/arch-at91/at91_spi.h index c520e89..75d4324
> > 100644
> > --- a/arch/arm/include/asm/arch-at91/at91_spi.h
> > +++ b/arch/arm/include/asm/arch-at91/at91_spi.h
> > @@ -33,6 +33,20 @@ typedef struct at91_spi {
> >
> > at91_pdc_t pdc;
> >
> > } at91_spi_t;
>
> If we touch header and driver anyway, we could get rid of the depreciated
> typedefs, to get conform to the coding style.
>
> See discussion about that 1-2 days ago :)
Ok, will do a repost after some time.
> > +#define AT91_SPI_CR_SPIEN 0x0001
> > +#define AT91_SPI_CR_SWRST 0x0080
> > +
> > +#define AT91_SPI_MR_MSTR 0x0001
> > +#define AT91_SPI_MR_MODFDIS0x0004
> > +#define AT91_SPI_MR_PCS0x000f
> > +
> > +#define AT91_SPI_SR_RXBUFF 0x0040
> > +#define AT91_SPI_SR_SPIENS 0x0001
> > +
> > +#define AT91_SPI_CSR_NCPHA 0x0001
> > +#define AT91_SPI_CSR_DLYBS 0x00ff
> > +#define AT91_SPI_CSR_DLYBCT0xff00
> > +
> >
> > #ifdef CONFIG_AT91_LEGACY
>
> After that patch, do we still need LEGACY?
I'm unsure about that yet. Anyway I would prefer to remove CONFIG_AT91_LEGACY
globally at all occurrences.
Best regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] various at91 patches to make some boards compilable again
Dear Reinhard Meyer, On Monday 01 November 2010, 09:40:52 Reinhard Meyer wrote: > > This patch series changes some at91 boards to SoC access and adds some > > defines to make the boards compilable again. > > Please note: All changes are untested! > > Ok, I will look over them, and apply them in a test branch here, if they > don't break my board I think they can be mainlined, BUT you would need to > be the maintainer of those boards. Well, I have only occasional access to at91sam9g20ek and at91sam9263ek atm. All other boards were just done by adjusting the same things. I'm unsure how well I could maintain those boards. > But if we receive no positive test reports in some time, those boards > ultimately have to be deleted. > > I can only test on an at91sam9xe-ek. Ok, i see. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/11] at91: Add spi base addresses
Signed-off-by: Alexander Stein --- arch/arm/include/asm/arch-at91/at91cap9.h|2 ++ arch/arm/include/asm/arch-at91/at91sam9260.h |2 ++ arch/arm/include/asm/arch-at91/at91sam9261.h |2 ++ arch/arm/include/asm/arch-at91/at91sam9263.h |2 ++ arch/arm/include/asm/arch-at91/at91sam9g45.h |2 ++ arch/arm/include/asm/arch-at91/at91sam9rl.h |1 + 6 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/at91cap9.h b/arch/arm/include/asm/arch-at91/at91cap9.h index f109c66..2bd0718 100644 --- a/arch/arm/include/asm/arch-at91/at91cap9.h +++ b/arch/arm/include/asm/arch-at91/at91cap9.h @@ -56,6 +56,8 @@ #define AT91_USART0_BASE 0xfff8c000 #define AT91_USART1_BASE 0xfff9 #define AT91_USART2_BASE 0xfff94000 +#define AT91_SPI0_BASE 0xfffa4000 +#define AT91_SPI1_BASE 0xfffa8000 #define AT91_DBGU_BASE 0xee00 #define AT91_PIO_BASE 0xf200 #define AT91_PMC_BASE 0xfc00 diff --git a/arch/arm/include/asm/arch-at91/at91sam9260.h b/arch/arm/include/asm/arch-at91/at91sam9260.h index 4b1b09f..bc3f2fd 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9260.h +++ b/arch/arm/include/asm/arch-at91/at91sam9260.h @@ -53,6 +53,8 @@ #define AT91_USART1_BASE 0xfffb4000 #define AT91_USART2_BASE 0xfffb8000 #define AT91_EMAC_BASE 0xfffc4000 +#define AT91_SPI0_BASE 0xfffc8000 +#define AT91_SPI1_BASE 0xfffcc000 #define AT91_USART3_BASE 0xfffd #define AT91_USART4_BASE 0xfffd4000 #define AT91_USART5_BASE 0xfffd8000 diff --git a/arch/arm/include/asm/arch-at91/at91sam9261.h b/arch/arm/include/asm/arch-at91/at91sam9261.h index 49be91f..22b4e4f 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9261.h +++ b/arch/arm/include/asm/arch-at91/at91sam9261.h @@ -46,6 +46,8 @@ #define AT91_USART0_BASE 0xfffb #define AT91_USART1_BASE 0xfffb4000 #define AT91_USART2_BASE 0xfffb8000 +#define AT91_SPI0_BASE 0xfffc8000 +#define AT91_SPI1_BASE 0xfffcc000 #define AT91_SDRAMC_BASE 0xea00 #define AT91_SMC_BASE 0xec00 #define AT91_MATRIX_BASE 0xee00 diff --git a/arch/arm/include/asm/arch-at91/at91sam9263.h b/arch/arm/include/asm/arch-at91/at91sam9263.h index cdda301..ac55282 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9263.h +++ b/arch/arm/include/asm/arch-at91/at91sam9263.h @@ -50,6 +50,8 @@ #define AT91_US0_BASE 0xfff8c000 #define AT91_US1_BASE 0xfff9 #define AT91_US2_BASE 0xfff94000 +#define AT91_SPI0_BASE 0xfffa4000 +#define AT91_SPI1_BASE 0xfffa8000 #define AT91_EMAC_BASE 0xfffbc000 #define AT91_ECC0_BASE 0xe000 #define AT91_SDRAMC0_BASE 0xe200 diff --git a/arch/arm/include/asm/arch-at91/at91sam9g45.h b/arch/arm/include/asm/arch-at91/at91sam9g45.h index b6767fd..931e4a2 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9g45.h +++ b/arch/arm/include/asm/arch-at91/at91sam9g45.h @@ -55,6 +55,8 @@ #define AT91_USART1_BASE 0xfff9 #define AT91_USART2_BASE 0xfff94000 #define AT91_USART3_BASE 0xfff98000 +#define AT91_SPI0_BASE 0xfffa4000 +#define AT91_SPI1_BASE 0xfffa8000 #define AT91_EMAC_BASE 0xfffbc000 #define AT91_SMC_BASE 0xe800 #define AT91_MATRIX_BASE 0xea00 diff --git a/arch/arm/include/asm/arch-at91/at91sam9rl.h b/arch/arm/include/asm/arch-at91/at91sam9rl.h index ffa6687..0e2b73e 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9rl.h +++ b/arch/arm/include/asm/arch-at91/at91sam9rl.h @@ -48,6 +48,7 @@ #define AT91_US1_BASE 0xfffb4000 #define AT91_US2_BASE 0xfffb8000 #define AT91_US3_BASE 0xfffbc000 +#define AT91_SPI_BASE 0xfffcc000 #define AT91_SDRAMC_BASE 0xea00 #define AT91_SMC_BASE 0xec00 #define AT91_MATRIX_BASE 0xee00 -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/11] at91: Add defines for spi SoC access
Signed-off-by: Alexander Stein
---
arch/arm/include/asm/arch-at91/at91_spi.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_spi.h
b/arch/arm/include/asm/arch-at91/at91_spi.h
index c520e89..75d4324 100644
--- a/arch/arm/include/asm/arch-at91/at91_spi.h
+++ b/arch/arm/include/asm/arch-at91/at91_spi.h
@@ -33,6 +33,20 @@ typedef struct at91_spi {
at91_pdc_t pdc;
} at91_spi_t;
+#define AT91_SPI_CR_SPIEN 0x0001
+#define AT91_SPI_CR_SWRST 0x0080
+
+#define AT91_SPI_MR_MSTR 0x0001
+#define AT91_SPI_MR_MODFDIS0x0004
+#define AT91_SPI_MR_PCS0x000f
+
+#define AT91_SPI_SR_RXBUFF 0x0040
+#define AT91_SPI_SR_SPIENS 0x0001
+
+#define AT91_SPI_CSR_NCPHA 0x0001
+#define AT91_SPI_CSR_DLYBS 0x00ff
+#define AT91_SPI_CSR_DLYBCT0xff00
+
#ifdef CONFIG_AT91_LEGACY
#define AT91_SPI_CR0x00/* Control Register */
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/11] atmel_dataflash: Update to SoC access
Signed-off-by: Alexander Stein
---
arch/arm/include/asm/arch-at91/hardware.h | 10 ++--
drivers/spi/atmel_dataflash_spi.c | 109 +++--
2 files changed, 60 insertions(+), 59 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/hardware.h
b/arch/arm/include/asm/arch-at91/hardware.h
index f5f80e0..06ae26c 100644
--- a/arch/arm/include/asm/arch-at91/hardware.h
+++ b/arch/arm/include/asm/arch-at91/hardware.h
@@ -22,22 +22,22 @@
#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20)
#include
#define AT91_BASE_MCI AT91SAM9260_BASE_MCI
-#define AT91_BASE_SPI AT91SAM9260_BASE_SPI0
+#define AT91_BASE_SPI AT91_SPI0_BASE
#define AT91_ID_UHPAT91SAM9260_ID_UHP
#define AT91_PMC_UHP AT91SAM926x_PMC_UHP
#elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9G10)
#include
-#define AT91_BASE_SPI AT91SAM9261_BASE_SPI0
+#define AT91_BASE_SPI AT91_SPI0_BASE
#define AT91_ID_UHPAT91SAM9261_ID_UHP
#define AT91_PMC_UHP AT91SAM926x_PMC_UHP
#elif defined(CONFIG_AT91SAM9263)
#include
-#define AT91_BASE_SPI AT91SAM9263_BASE_SPI0
+#define AT91_BASE_SPI AT91_SPI0_BASE
#define AT91_ID_UHPAT91SAM9263_ID_UHP
#define AT91_PMC_UHP AT91SAM926x_PMC_UHP
#elif defined(CONFIG_AT91SAM9RL)
#include
-#define AT91_BASE_SPI AT91SAM9RL_BASE_SPI
+#define AT91_BASE_SPI AT91_SPI_BASE
#define AT91_ID_UHPAT91SAM9RL_ID_UHP
#elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45)
#include
@@ -47,7 +47,7 @@
#define AT91_PMC_UHPAT91SAM926x_PMC_UHP
#elif defined(CONFIG_AT91CAP9)
#include
-#define AT91_BASE_SPI AT91CAP9_BASE_SPI0
+#define AT91_BASE_SPI AT91_SPI0_BASE
#define AT91_ID_UHPAT91CAP9_ID_UHP
#define AT91_PMC_UHP AT91CAP9_PMC_UHP
#elif defined(CONFIG_AT91X40)
diff --git a/drivers/spi/atmel_dataflash_spi.c
b/drivers/spi/atmel_dataflash_spi.c
index 4a5c4aa..f325647 100644
--- a/drivers/spi/atmel_dataflash_spi.c
+++ b/drivers/spi/atmel_dataflash_spi.c
@@ -20,10 +20,7 @@
*/
#include
-#ifndef CONFIG_AT91_LEGACY
-#define CONFIG_AT91_LEGACY
-#warning Please update to use C structur SoC access !
-#endif
+
#include
#include
#include
@@ -40,93 +37,96 @@
void AT91F_SpiInit(void)
{
+ at91_spi_t *spi = (at91_spi_t *) AT91_BASE_SPI;
+
/* Reset the SPI */
- writel(AT91_SPI_SWRST, AT91_BASE_SPI + AT91_SPI_CR);
+ writel(AT91_SPI_CR_SWRST, &spi->cr);
/* Configure SPI in Master Mode with No CS selected !!! */
- writel(AT91_SPI_MSTR | AT91_SPI_MODFDIS | AT91_SPI_PCS,
- AT91_BASE_SPI + AT91_SPI_MR);
+ writel(AT91_SPI_MR_MSTR | AT91_SPI_MR_MODFDIS | AT91_SPI_MR_PCS,
+ &spi->mr);
/* Configure CS0 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
+ writel(AT91_SPI_CSR_NCPHA |
+ (AT91_SPI_CSR_DLYBS & DATAFLASH_TCSS) |
+ (AT91_SPI_CSR_DLYBCT & DATAFLASH_TCHS) |
((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- AT91_BASE_SPI + AT91_SPI_CSR(0));
+ &spi->csr[0]);
#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS1
/* Configure CS1 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
+ writel(AT91_SPI_CSR_NCPHA |
+ (AT91_SPI_CSR_DLYBS & DATAFLASH_TCSS) |
+ (AT91_SPI_CSR_DLYBCT & DATAFLASH_TCHS) |
((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- AT91_BASE_SPI + AT91_SPI_CSR(1));
+ &spi->csr[1]);
#endif
#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS2
/* Configure CS2 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
+ writel(AT91_SPI_CSR_NCPHA |
+ (AT91_SPI_CSR_DLYBS & DATAFLASH_TCSS) |
+ (AT91_SPI_CSR_DLYBCT & DATAFLASH_TCHS) |
((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- AT91_BASE_SPI + AT91_SPI_CSR(2));
+ &spi->csr[2]);
#endif
#ifdef CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS3
/* Configure CS3 */
- writel(AT91_SPI_NCPHA |
- (AT91_SPI_DLYBS & DATAFLASH_TCSS) |
- (AT91_SPI_DLYBCT & DATAFLASH_TCHS) |
+ writel(AT91_SPI_CSR_NCPHA |
+ (AT91_SPI_CSR_DLYBS & DATAFLASH_TCSS) |
+ (AT91_SPI_CSR_DLYBCT & DATAFLASH_TCHS) |
((get_mck_clk_rate() / AT91_SPI_CLK) << 8),
- AT91_BASE_SPI + AT91_SPI_CSR(3));
+ &spi->csr[3]);
#endif
/* SPI_Enable */
- writel(AT91_SPI_SPIEN, AT91_BASE_SPI + AT91_SPI_CR);
+ writel(AT91_SPI_CR_SPIEN, &spi->cr);
- while (!(readl(AT91_BASE_SPI + AT91_SPI_SR) & AT91_SPI_SPIENS));
+ w
[U-Boot] [PATCH 05/11] at91: Fix pdc register names and add some defines
Signed-off-by: Alexander Stein
---
arch/arm/include/asm/arch-at91/at91_pdc.h |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_pdc.h
b/arch/arm/include/asm/arch-at91/at91_pdc.h
index 42f87ca..2ee6c9d 100644
--- a/arch/arm/include/asm/arch-at91/at91_pdc.h
+++ b/arch/arm/include/asm/arch-at91/at91_pdc.h
@@ -28,12 +28,17 @@ typedef struct at91_pdc {
u32 rcr;/* 0x104 Receive Counter Register */
u32 tpr;/* 0x108 Transmit Pointer Register */
u32 tcr;/* 0x10C Transmit Counter Register */
- u32 pnpr; /* 0x110 Receive Next Pointer Register */
- u32 pncr; /* 0x114 Receive Next Counter Register */
+ u32 rnpr; /* 0x110 Receive Next Pointer Register */
+ u32 rncr; /* 0x114 Receive Next Counter Register */
u32 tnpr; /* 0x118 Transmit Next Pointer Register */
u32 tncr; /* 0x11C Transmit Next Counter Register */
u32 ptcr; /* 0x120 Transfer Control Register */
u32 ptsr; /* 0x124 Transfer Status Register */
} at91_pdc_t;
+#define AT91_PDC_PTCR_RXTEN0x0001
+#define AT91_PDC_PTCR_RXTDIS 0x0002
+#define AT91_PDC_PTCR_TXTEN0x0100
+#define AT91_PDC_PTCR_TXTDIS 0x0200
+
#endif
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/11] at91sam9263ek: make compilable again
Signed-off-by: Alexander Stein
---
board/atmel/at91sam9263ek/at91sam9263ek.c |6 +++---
include/configs/at91sam9263ek.h | 15 +++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c
b/board/atmel/at91sam9263ek/at91sam9263ek.c
index 91efc07..c9c8eac 100644
--- a/board/atmel/at91sam9263ek/at91sam9263ek.c
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -252,7 +252,7 @@ int board_init(void)
/* arch number of AT91SAM9263EK-Board */
gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9263EK;
/* adress of boot parameters */
- gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
at91_serial_hw_init();
#ifdef CONFIG_CMD_NAND
@@ -276,8 +276,8 @@ int board_init(void)
int dram_init(void)
{
- gd->bd->bi_dram[0].start = PHYS_SDRAM;
- gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = CONFIG_SYS_SDRAM_SIZE;
return 0;
}
diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
index f6cb406..33c921b 100644
--- a/include/configs/at91sam9263ek.h
+++ b/include/configs/at91sam9263ek.h
@@ -27,6 +27,8 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#include
+
/* ARM asynchronous clock */
#define CONFIG_SYS_AT91_MAIN_CLOCK 16367660/* 16.367 MHz crystal */
#define CONFIG_SYS_HZ 1000
@@ -34,6 +36,7 @@
#define CONFIG_ARM926EJS 1 /* This is an ARM926EJS Core*/
#define CONFIG_AT91SAM9263 1 /* It's an Atmel AT91SAM9263 SoC*/
#define CONFIG_AT91SAM9263EK 1 /* on an AT91SAM9263EK Board*/
+#define CONFIG_AT91FAMILY
#define CONFIG_ARCH_CPU_INIT
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
@@ -101,8 +104,8 @@
/* SDRAM */
#define CONFIG_NR_DRAM_BANKS 1
-#define PHYS_SDRAM 0x2000
-#define PHYS_SDRAM_SIZE0x0400 /* 64 megs */
+#define CONFIG_SYS_SDRAM_BASE 0x2000
+#define CONFIG_SYS_SDRAM_SIZE SZ_64M /* 64 megs */
/* DataFlash */
#define CONFIG_ATMEL_DATAFLASH_SPI
@@ -291,7 +294,7 @@
#define CONFIG_SYS_LOAD_ADDR 0x2200 /* load address
*/
-#define CONFIG_SYS_MEMTEST_START PHYS_SDRAM
+#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
#define CONFIG_SYS_MEMTEST_END 0x23e0
#ifdef CONFIG_SYS_USE_DATAFLASH
@@ -340,8 +343,12 @@
* Size of malloc() pool
*/
#define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE + 128*1024,
0x1000)
+/* size in bytes reserved for initial data */
+
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + SZ_4K \
+ - GENERATED_GBL_DATA_SIZE)
-#define CONFIG_STACKSIZE (32*1024) /* regular stack */
+#define CONFIG_STACKSIZE (SZ_32K)/* regular stack */
#ifdef CONFIG_USE_IRQ
#error CONFIG_USE_IRQ not supported
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/11] at91: Use AT91_USART0_BASE instead of AT91_USART0
Signed-off-by: Alexander Stein --- arch/arm/include/asm/arch-at91/memory-map.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/memory-map.h b/arch/arm/include/asm/arch-at91/memory-map.h index f605f37..dd42bec 100644 --- a/arch/arm/include/asm/arch-at91/memory-map.h +++ b/arch/arm/include/asm/arch-at91/memory-map.h @@ -26,10 +26,10 @@ #include -#define USART0_BASE AT91_USART0 -#define USART1_BASE AT91_USART1 -#define USART2_BASE AT91_USART2 -#define USART3_BASE (AT91_BASE_SYS + AT91_DBGU) +#define USART0_BASE AT91_USART0_BASE +#define USART1_BASE AT91_USART1_BASE +#define USART2_BASE AT91_USART2_BASE +#define USART3_BASE AT91_DBGU_BASE #define SPI0_BASE AT91_BASE_SPI #endif /* __ASM_ARM_ARCH_MEMORYMAP_H__ */ -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/11] at91sam9261ek: make compilable again
Signed-off-by: Alexander Stein
---
board/atmel/at91sam9261ek/at91sam9261ek.c |6 +++---
include/configs/at91sam9261ek.h | 15 +++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/board/atmel/at91sam9261ek/at91sam9261ek.c
b/board/atmel/at91sam9261ek/at91sam9261ek.c
index de5cfae..afe561f 100644
--- a/board/atmel/at91sam9261ek/at91sam9261ek.c
+++ b/board/atmel/at91sam9261ek/at91sam9261ek.c
@@ -246,7 +246,7 @@ int board_init(void)
gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9261EK;
#endif
/* adress of boot parameters */
- gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
at91_serial_hw_init();
#ifdef CONFIG_CMD_NAND
@@ -273,8 +273,8 @@ int board_eth_init(bd_t *bis)
int dram_init(void)
{
- gd->bd->bi_dram[0].start = PHYS_SDRAM;
- gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = CONFIG_SYS_SDRAM_SIZE;
return 0;
}
diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h
index 401478b..05eb15a 100644
--- a/include/configs/at91sam9261ek.h
+++ b/include/configs/at91sam9261ek.h
@@ -27,6 +27,8 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#include
+
#define CONFIG_AT91_LEGACY
/* ARM asynchronous clock */
@@ -39,6 +41,7 @@
#else
#define CONFIG_AT91SAM9261 1 /* It's an Atmel AT91SAM9261 SoC*/
#endif
+#define CONFIG_AT91FAMILY
#define CONFIG_ARCH_CPU_INIT
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
@@ -108,8 +111,8 @@
/* SDRAM */
#define CONFIG_NR_DRAM_BANKS 1
-#define PHYS_SDRAM 0x2000
-#define PHYS_SDRAM_SIZE0x0400 /* 64 megs */
+#define CONFIG_SYS_SDRAM_BASE 0x2000
+#define CONFIG_SYS_SDRAM_SIZE SZ_64M /* 64 megs */
/* DataFlash */
#define CONFIG_ATMEL_DATAFLASH_SPI
@@ -168,7 +171,7 @@
#define CONFIG_SYS_LOAD_ADDR 0x2200 /* load address
*/
-#define CONFIG_SYS_MEMTEST_START PHYS_SDRAM
+#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
#define CONFIG_SYS_MEMTEST_END 0x23e0
#ifdef CONFIG_SYS_USE_DATAFLASH_CS0
@@ -230,8 +233,12 @@
* Size of malloc() pool
*/
#define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE + 128*1024,
0x1000)
+/* size in bytes reserved for initial data */
+
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + SZ_4K \
+ - GENERATED_GBL_DATA_SIZE)
-#define CONFIG_STACKSIZE (32*1024) /* regular stack */
+#define CONFIG_STACKSIZE (SZ_32K)/* regular stack */
#ifdef CONFIG_USE_IRQ
#error CONFIG_USE_IRQ not supported
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/11] at91sam9260ek: Convert to SoC
Signed-off-by: Alexander Stein
---
board/atmel/at91sam9260ek/at91sam9260ek.c | 88 +---
board/atmel/at91sam9260ek/led.c | 12 ++--
include/configs/at91sam9260ek.h | 12 ++--
3 files changed, 53 insertions(+), 59 deletions(-)
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 063ddbf..8126c4f 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -48,48 +49,55 @@ DECLARE_GLOBAL_DATA_PTR;
static void at91sam9260ek_nand_hw_init(void)
{
unsigned long csa;
+ at91_smc_t *smc= (at91_smc_t *) AT91_SMC_BASE;
+ at91_matrix_t *matrix = (at91_matrix_t *) AT91_MATRIX_BASE;
+ at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
/* Enable CS3 */
- csa = at91_sys_read(AT91_MATRIX_EBICSA);
- at91_sys_write(AT91_MATRIX_EBICSA,
- csa | AT91_MATRIX_CS3A_SMC_SMARTMEDIA);
+ csa = readl(&matrix->csa) | AT91_MATRIX_CSA_EBI_CS3A;
+ writel(csa, &matrix->csa);
/* Configure SMC CS3 for NAND/SmartMedia */
- at91_sys_write(AT91_SMC_SETUP(3),
- AT91_SMC_NWESETUP_(1) | AT91_SMC_NCS_WRSETUP_(0) |
- AT91_SMC_NRDSETUP_(1) | AT91_SMC_NCS_RDSETUP_(0));
- at91_sys_write(AT91_SMC_PULSE(3),
- AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) |
- AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
- at91_sys_write(AT91_SMC_CYCLE(3),
- AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
- at91_sys_write(AT91_SMC_MODE(3),
- AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
- AT91_SMC_EXNWMODE_DISABLE |
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ &smc->cs[3].setup);
+
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) |
+ AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
+ &smc->cs[3].pulse);
+
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
+ &smc->cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
#ifdef CONFIG_SYS_NAND_DBW_16
- AT91_SMC_DBW_16 |
+ AT91_SMC_MODE_DBW_16 |
#else /* CONFIG_SYS_NAND_DBW_8 */
- AT91_SMC_DBW_8 |
+ AT91_SMC_MODE_DBW_8 |
#endif
- AT91_SMC_TDF_(2));
+ AT91_SMC_MODE_TDF_CYCLE(2),
+ &smc->cs[3].mode);
- at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_PIOC);
+ writel(1 << AT91SAM9260_ID_PIOC, &pmc->pcer);
/* Configure RDY/BSY */
- at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+ at91_set_pio_input(CONFIG_SYS_NAND_READY_PIN, 1);
/* Enable NandFlash */
- at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+ at91_set_pio_input(CONFIG_SYS_NAND_ENABLE_PIN, 1);
}
#endif
#ifdef CONFIG_MACB
static void at91sam9260ek_macb_hw_init(void)
{
- unsigned long rstc;
+ unsigned long erstl;
+ at91_pmc_t *pmc= (at91_pmc_t *) AT91_PMC_BASE;
+ at91_pio_t *pio= (at91_pio_t *) AT91_PIO_BASE;
+ at91_rstc_t *rstc = (at91_rstc_t *) AT91_RSTC_BASE;
/* Enable clock */
- at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_EMAC);
+ writel(1 << AT91SAM9260_ID_EMAC, &pmc->pcer);
/*
* Disable pull-up on:
@@ -102,39 +110,25 @@ static void at91sam9260ek_macb_hw_init(void)
*
* PHY has internal pull-down
*/
- writel(pin_to_mask(AT91_PIN_PA14) |
- pin_to_mask(AT91_PIN_PA15) |
- pin_to_mask(AT91_PIN_PA17) |
- pin_to_mask(AT91_PIN_PA25) |
- pin_to_mask(AT91_PIN_PA26) |
- pin_to_mask(AT91_PIN_PA28),
- pin_to_controller(AT91_PIN_PA0) + PIO_PUDR);
- rstc = at91_sys_read(AT91_RSTC_MR) & AT91_RSTC_ERSTL;
+ writel((1 << 17) | (1 << 14) | (1 << 15) | (1 << 25) | (1 << 26) | (1
<< 28), &pio->pioa.pudr);
- /* Need to reset PHY -> 500ms reset */
- at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-(AT91_RSTC_ERSTL & (0x0D << 8)) |
-AT91_RSTC_URSTEN);
+ erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK;
- at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_EXTRST);
+ /* Need to reset PHY -> 500ms reset */
+ writel(AT91_RSTC_KEY | AT91_RSTC_M
[U-Boot] [PATCH 11/11] at91cap9adk: make compilable again
Signed-off-by: Alexander Stein
---
board/atmel/at91cap9adk/at91cap9adk.c |6 +++---
include/configs/at91cap9adk.h | 15 +++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/board/atmel/at91cap9adk/at91cap9adk.c
b/board/atmel/at91cap9adk/at91cap9adk.c
index 2ab8bc2..ce77a13 100644
--- a/board/atmel/at91cap9adk/at91cap9adk.c
+++ b/board/atmel/at91cap9adk/at91cap9adk.c
@@ -306,7 +306,7 @@ int board_init(void)
/* arch number of AT91CAP9ADK-Board */
gd->bd->bi_arch_number = MACH_TYPE_AT91CAP9ADK;
/* adress of boot parameters */
- gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
at91_serial_hw_init();
at91cap9_slowclock_hw_init();
@@ -331,8 +331,8 @@ int board_init(void)
int dram_init(void)
{
- gd->bd->bi_dram[0].start = PHYS_SDRAM;
- gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = CONFIG_SYS_SDRAM_SIZE;
return 0;
}
diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
index 49c923f..8768c53 100644
--- a/include/configs/at91cap9adk.h
+++ b/include/configs/at91cap9adk.h
@@ -27,6 +27,8 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#include
+
#define CONFIG_AT91_LEGACY
/* ARM asynchronous clock */
@@ -36,6 +38,7 @@
#define CONFIG_ARM926EJS 1 /* This is an ARM926EJS Core*/
#define CONFIG_AT91CAP91 /* It's an Atmel AT91CAP9 SoC
*/
#define CONFIG_AT91CAP9ADK 1 /* on an AT91CAP9ADK Board */
+#define CONFIG_AT91FAMILY
#define CONFIG_ARCH_CPU_INIT
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
@@ -100,8 +103,8 @@
/* SDRAM: Careful: this supposes an AT91CAP-MEM33 expansion card */
#define CONFIG_NR_DRAM_BANKS 1
-#define PHYS_SDRAM 0x7000
-#define PHYS_SDRAM_SIZE0x0400 /* 64 megs */
+#define CONFIG_SYS_SDRAM_BASE 0x7000
+#define CONFIG_SYS_SDRAM_SIZE SZ_64M /* 64 megs */
/* DataFlash */
#define CONFIG_ATMEL_DATAFLASH_SPI
@@ -155,7 +158,7 @@
#define CONFIG_SYS_LOAD_ADDR 0x7200 /* load address
*/
-#define CONFIG_SYS_MEMTEST_START PHYS_SDRAM
+#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
#define CONFIG_SYS_MEMTEST_END 0x73e0
#define CONFIG_SYS_USE_DATAFLASH 1
@@ -208,8 +211,12 @@
* Size of malloc() pool
*/
#define CONFIG_SYS_MALLOC_LEN ROUND(CONFIG_ENV_SIZE + 128*1024,
0x1000)
+/* size in bytes reserved for initial data */
+
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + SZ_4K \
+ - GENERATED_GBL_DATA_SIZE)
-#define CONFIG_STACKSIZE (32*1024) /* regular stack */
+#define CONFIG_STACKSIZE (SZ_32K)/* regular stack */
#ifdef CONFIG_USE_IRQ
#error CONFIG_USE_IRQ not supported
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/11] at91: Add USART & DBGU base address defines
Signed-off-by: Alexander Stein --- arch/arm/include/asm/arch-at91/at91cap9.h| 12 arch/arm/include/asm/arch-at91/at91sam9260.h |7 +++ arch/arm/include/asm/arch-at91/at91sam9261.h |4 arch/arm/include/asm/arch-at91/at91sam9263.h |3 +++ arch/arm/include/asm/arch-at91/at91sam9g45.h |5 + arch/arm/include/asm/arch-at91/at91sam9rl.h |4 6 files changed, 31 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/at91cap9.h b/arch/arm/include/asm/arch-at91/at91cap9.h index 5af6fdc..f109c66 100644 --- a/arch/arm/include/asm/arch-at91/at91cap9.h +++ b/arch/arm/include/asm/arch-at91/at91cap9.h @@ -53,10 +53,14 @@ #define AT91CAP9_ID_IRQ0 30 /* Advanced Interrupt Controller (IRQ0) */ #define AT91CAP9_ID_IRQ1 31 /* Advanced Interrupt Controller (IRQ1) */ -#define AT91_PIO_BASE 0xf200 -#define AT91_PMC_BASE 0xfc00 -#define AT91_RSTC_BASE 0xfd00 -#define AT91_PIT_BASE 0xfd30 +#define AT91_USART0_BASE 0xfff8c000 +#define AT91_USART1_BASE 0xfff9 +#define AT91_USART2_BASE 0xfff94000 +#define AT91_DBGU_BASE 0xee00 +#define AT91_PIO_BASE 0xf200 +#define AT91_PMC_BASE 0xfc00 +#define AT91_RSTC_BASE 0xfd00 +#define AT91_PIT_BASE 0xfd30 #ifdef CONFIG_AT91_LEGACY diff --git a/arch/arm/include/asm/arch-at91/at91sam9260.h b/arch/arm/include/asm/arch-at91/at91sam9260.h index cb34a94..4b1b09f 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9260.h +++ b/arch/arm/include/asm/arch-at91/at91sam9260.h @@ -49,10 +49,17 @@ #define AT91SAM9260_ID_IRQ130 /* Advanced Interrupt Controller (IRQ1) */ #define AT91SAM9260_ID_IRQ231 /* Advanced Interrupt Controller (IRQ2) */ +#define AT91_USART0_BASE 0xfffb +#define AT91_USART1_BASE 0xfffb4000 +#define AT91_USART2_BASE 0xfffb8000 #define AT91_EMAC_BASE 0xfffc4000 +#define AT91_USART3_BASE 0xfffd +#define AT91_USART4_BASE 0xfffd4000 +#define AT91_USART5_BASE 0xfffd8000 #define AT91_SDRAMC_BASE 0xea00 #define AT91_SMC_BASE 0xec00 #define AT91_MATRIX_BASE 0xee00 +#define AT91_DBGU_BASE 0xf200 #define AT91_PIO_BASE 0xf400 #define AT91_PMC_BASE 0xfc00 #define AT91_RSTC_BASE 0xfd00 diff --git a/arch/arm/include/asm/arch-at91/at91sam9261.h b/arch/arm/include/asm/arch-at91/at91sam9261.h index 7ca0283..49be91f 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9261.h +++ b/arch/arm/include/asm/arch-at91/at91sam9261.h @@ -43,9 +43,13 @@ #define AT91SAM9261_ID_IRQ130 /* Advanced Interrupt Controller (IRQ1) */ #define AT91SAM9261_ID_IRQ231 /* Advanced Interrupt Controller (IRQ2) */ +#define AT91_USART0_BASE 0xfffb +#define AT91_USART1_BASE 0xfffb4000 +#define AT91_USART2_BASE 0xfffb8000 #define AT91_SDRAMC_BASE 0xea00 #define AT91_SMC_BASE 0xec00 #define AT91_MATRIX_BASE 0xee00 +#define AT91_DBGU_BASE 0xf200 #define AT91_PIO_BASE 0xf400 #define AT91_PMC_BASE 0xfc00 #define AT91_RSTC_BASE 0xfd00 diff --git a/arch/arm/include/asm/arch-at91/at91sam9263.h b/arch/arm/include/asm/arch-at91/at91sam9263.h index 4ada1ce..cdda301 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9263.h +++ b/arch/arm/include/asm/arch-at91/at91sam9263.h @@ -47,6 +47,9 @@ #define AT91SAM9263_ID_IRQ030 /* Advanced Interrupt Controller (IRQ0) */ #define AT91SAM9263_ID_IRQ131 /* Advanced Interrupt Controller (IRQ1) */ +#define AT91_US0_BASE 0xfff8c000 +#define AT91_US1_BASE 0xfff9 +#define AT91_US2_BASE 0xfff94000 #define AT91_EMAC_BASE 0xfffbc000 #define AT91_ECC0_BASE 0xe000 #define AT91_SDRAMC0_BASE 0xe200 diff --git a/arch/arm/include/asm/arch-at91/at91sam9g45.h b/arch/arm/include/asm/arch-at91/at91sam9g45.h index 445f4b2..b6767fd 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9g45.h +++ b/arch/arm/include/asm/arch-at91/at91sam9g45.h @@ -51,9 +51,14 @@ #define AT91SAM9G45_ID_VDEC30 /* Video Decoder */ #define AT91SAM9G45_ID_IRQ031 /* Advanced Interrupt Controller */ +#define AT91_USART0_BASE 0xfff8c000 +#define AT91_USART1_BASE 0xfff9 +#define AT91_USART2_BASE 0xfff94000 +#define AT91_USART3_BASE 0xfff98000 #define AT91_EMAC_BASE 0xfffbc000 #define AT91_SMC_BASE 0xe800 #define AT91_MATRIX_BASE 0xea00 +#define AT91_DBGU_BASE 0xee00 #define AT91_PIO_BASE 0xf200 #define AT91_PMC_BASE 0xfc00 #define AT91_RSTC_BASE 0xfd00 diff --git a/arch/arm/include/asm/arch-at91/at91sam9rl.h b/arch/arm/include/asm/arch-at91/at91sam9rl.h index 8eb0d4f..ffa6687 100644 --- a/arch/arm/include/asm/arch-at91
[U-Boot] [PATCH 01/11] at91sam9260: Replace PHYS_SDRAM with CONFIG_SYS_SDRAM_BASE
Same for PHYS_SDRAM_SIZE and CONFIG_SYS_SDRAM_SIZE and use SZ_* macros
Signed-off-by: Alexander Stein
---
board/atmel/at91sam9260ek/at91sam9260ek.c |6 +++---
include/configs/at91sam9260ek.h | 17 -
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c
b/board/atmel/at91sam9260ek/at91sam9260ek.c
index 64c6d17..063ddbf 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -153,7 +153,7 @@ int board_init(void)
gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9260EK;
#endif
/* adress of boot parameters */
- gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
at91_serial_hw_init();
#ifdef CONFIG_CMD_NAND
@@ -171,8 +171,8 @@ int board_init(void)
int dram_init(void)
{
- gd->bd->bi_dram[0].start = PHYS_SDRAM;
- gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = CONFIG_SYS_SDRAM_SIZE;
return 0;
}
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index 5e7dee5..8aee5a6 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -27,6 +27,8 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#include
+
#define CONFIG_AT91_LEGACY
/* ARM asynchronous clock */
@@ -40,6 +42,7 @@
#else
#define CONFIG_AT91SAM9260 1 /* It's an Atmel AT91SAM9260 SoC*/
#endif
+#define CONFIG_AT91FAMILY
#define CONFIG_ARCH_CPU_INIT
#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */
@@ -93,8 +96,8 @@
/* SDRAM */
#define CONFIG_NR_DRAM_BANKS 1
-#define PHYS_SDRAM 0x2000
-#define PHYS_SDRAM_SIZE0x0400 /* 64 megs */
+#define CONFIG_SYS_SDRAM_BASE 0x2000
+#define CONFIG_SYS_SDRAM_SIZE SZ_64M
/* DataFlash */
#define CONFIG_ATMEL_DATAFLASH_SPI
@@ -150,7 +153,7 @@
#define CONFIG_SYS_LOAD_ADDR 0x2200 /* load address
*/
-#define CONFIG_SYS_MEMTEST_START PHYS_SDRAM
+#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
#define CONFIG_SYS_MEMTEST_END 0x23e0
#ifdef CONFIG_SYS_USE_DATAFLASH_CS0
@@ -211,9 +214,13 @@
/*
* Size of malloc() pool
*/
-#define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE + 128*1024,
0x1000)
+#define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE + SZ_128K,
0x1000)
+/* size in bytes reserved for initial data */
+
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + SZ_4K \
+ - GENERATED_GBL_DATA_SIZE)
-#define CONFIG_STACKSIZE (32*1024) /* regular stack */
+#define CONFIG_STACKSIZE (SZ_32K)/* regular stack */
#ifdef CONFIG_USE_IRQ
#error CONFIG_USE_IRQ not supported
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] various at91 patches to make some boards compilable again
This patch series changes some at91 boards to SoC access and adds some defines to make the boards compilable again. Please note: All changes are untested! Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] current ARM development head
Hello, I noticed that there is a lot of changes in ARM part of u-boot. Especially the new relocation is a bit tricky. So I'm wondering what and where is the current ARM development head, especially the at91 part. Is it u-boot master branch or some other repository/branch? Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] include/asm-offsets.h: automatically generate assembler constants
On Tuesday 26 October 2010, 16:00:00 Wolfgang Denk wrote: > @@ -453,7 +456,7 @@ $(obj)System.map: $(obj)u-boot > @$(call SYSTEM_MAP,$<) > $(obj)System.map > > # > -# Auto-generate the autoconf.mk file (which is included by all makefiles) > +# Auto-generate the autoconi.mk file (which is included by all makefiles) > # > # This target actually generates 2 files; autoconf.mk and autoconf.mk.dep. > # the dep file is only include in this top level makefile to determine > when I think thats a typo. Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dlmalloc.c: Fix gcc alias warning
Hello,
On Thursday 14 October 2010, 08:41:20 Joakim Tjernlund wrote:
> Fix these warnings:
> dlmalloc.c: In function 'free':
> dlmalloc.c:2507: warning: dereferencing pointer '({anonymous})' does break
> strict-aliasing rules dlmalloc.c:2507: warning: dereferencing pointer
> '({anonymous})' does break strict-aliasing rules dlmalloc.c:2507: warning:
> dereferencing pointer '({anonymous})' does break strict-aliasing rules
>
> Some
> page(http://blog.worldofcoding.com/2010/02/solving-gcc-44-strict-aliasing-
> problems.html) suggests adding __attribute__((__may_alias__)). Doing so
> makes the warnings go away. ---
> common/dlmalloc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
> index 2276532..c78cacc 100644
> --- a/common/dlmalloc.c
> +++ b/common/dlmalloc.c
> @@ -1155,7 +1155,7 @@ struct malloc_chunk
>INTERNAL_SIZE_T size; /* Size in bytes, including overhead. */
>struct malloc_chunk* fd; /* double links -- used only if free. */
>struct malloc_chunk* bk;
> -};
> +} __attribute__((__may_alias__)) ;
>
> typedef struct malloc_chunk* mchunkptr;
>
> @@ -1443,7 +1443,7 @@ nextchunk->
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> #define NAV 128 /* number of bins */
>
> -typedef struct malloc_chunk* mbinptr;
> +typedef struct malloc_chunk* mbinptr __attribute__((__may_alias__));
>
> /* access macros */
Though I don't know the actual code why not use a union instead?
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib_arm: fix build error with gcc 4.4 and above
Hello,
On Thursday 16 September 2010, 19:44:20 you wrote:
> This patch fixes lib_arm/board.c build errors.
> The combination of "weak" alias and "inline" attributes
> lead to a compile time error when using gcc version 4.4 and above.
>
> Signed-off-by: Stanislav O. Bezzubtsev
> ---
> lib_arm/board.c | 18 +-
> 1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/lib_arm/board.c b/lib_arm/board.c
> index d6864bc..2f027a9 100644
> --- a/lib_arm/board.c
> +++ b/lib_arm/board.c
> @@ -124,23 +124,23 @@ void *sbrk (ptrdiff_t increment)
> * May be supplied by boards if desired
> */
> void inline __coloured_LED_init (void) {}
> -void inline coloured_LED_init (void) __attribute__((weak,
> alias("__coloured_LED_init"))); +void coloured_LED_init (void)
> __attribute__((weak, alias("__coloured_LED_init"))); void inline
> __red_LED_on (void) {}
> -void inline red_LED_on (void) __attribute__((weak,
> alias("__red_LED_on"))); +void red_LED_on (void) __attribute__((weak,
> alias("__red_LED_on"))); void inline __red_LED_off(void) {}
> -void inline red_LED_off(void) __attribute__((weak,
> alias("__red_LED_off"))); +void red_LED_off(void)
> __attribute__((weak, alias("__red_LED_off"))); void inline
> __green_LED_on(void) {}
> -void inline green_LED_on(void) __attribute__((weak,
> alias("__green_LED_on"))); +void green_LED_on(void) __attribute__((weak,
> alias("__green_LED_on"))); void inline __green_LED_off(void) {}
> -void inline green_LED_off(void)__attribute__((weak,
> alias("__green_LED_off"))); +void green_LED_off(void)__attribute__((weak,
> alias("__green_LED_off"))); void inline __yellow_LED_on(void) {}
> -void inline yellow_LED_on(void)__attribute__((weak,
> alias("__yellow_LED_on"))); +void yellow_LED_on(void)__attribute__((weak,
> alias("__yellow_LED_on"))); void inline __yellow_LED_off(void) {}
> -void inline yellow_LED_off(void)__attribute__((weak,
> alias("__yellow_LED_off"))); +void
> yellow_LED_off(void)__attribute__((weak, alias("__yellow_LED_off"))); void
> inline __blue_LED_on(void) {}
> -void inline blue_LED_on(void)__attribute__((weak,
> alias("__blue_LED_on"))); +void blue_LED_on(void)__attribute__((weak,
> alias("__blue_LED_on"))); void inline __blue_LED_off(void) {}
> -void inline blue_LED_off(void)__attribute__((weak,
> alias("__blue_LED_off"))); +void blue_LED_off(void)__attribute__((weak,
> alias("__blue_LED_off")));
>
> /
> * Init Utilities*
This has already been fixed in f865fcbbb35851e75fee9c3a3fa8e0f71d9e6463
(include since tag v2009.11-rc2)
Regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] at91: Add arch_preboot_os which disables PIT in a faster way
When disabled the PIT runs until it reaches the CPIV value.
The Linux PIT driver stops the PIT and waits until it stopped. This can
take over 100ms. Simply stopping in u-boot isn't sufficient as the PIT
will still be running when Linux is waiting until it stopped.
So, we stop it in u-boot by setting the compare value to a value slightly
greater than the current running counter to make the PIT stopped in short
time.
Signed-off-by: Alexander Stein
---
Changes in v3:
* Really fix comment
arch/arm/cpu/arm926ejs/at91/cpu.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/cpu.c
b/arch/arm/cpu/arm926ejs/at91/cpu.c
index 141a7d1..110c361 100644
--- a/arch/arm/cpu/arm926ejs/at91/cpu.c
+++ b/arch/arm/cpu/arm926ejs/at91/cpu.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -47,6 +48,21 @@ int arch_cpu_init(void)
return at91_clock_init(CONFIG_SYS_AT91_MAIN_CLOCK);
}
+void arch_preboot_os(void)
+{
+ ulong cpiv;
+ at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE;
+
+ cpiv = AT91_PIT_MR_PIV_MASK(readl(&pit->piir));
+
+ /*
+* Disable PITC
+* Add 0x1000 to current counter to stop it faster
+* without waiting for wrapping back to 0
+*/
+ writel(cpiv + 0x1000, &pit->mr);
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
--
1.7.2.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] at91: Add arch_preboot_os which disables PIT in a faster way
When disabled the PIT runs until it reaches the CPIV value.
The Linux PIT driver stops the PIT and waits until it stopped. This can
take over 100ms. Simply stopping in u-boot isn't sufficient as the PIT
will still be running when Linux is waiting until it stopped.
So, we stop it in u-boot by setting the compare value to a value slightly
greater than the current running counter to make the PIT stopped in short
time.
Signed-off-by: Alexander Stein
---
Changes in v2:
* Fix comment
arch/arm/cpu/arm926ejs/at91/cpu.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/cpu.c
b/arch/arm/cpu/arm926ejs/at91/cpu.c
index 141a7d1..62e7678 100644
--- a/arch/arm/cpu/arm926ejs/at91/cpu.c
+++ b/arch/arm/cpu/arm926ejs/at91/cpu.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -47,6 +48,20 @@ int arch_cpu_init(void)
return at91_clock_init(CONFIG_SYS_AT91_MAIN_CLOCK);
}
+void arch_preboot_os(void)
+{
+ ulong cpiv;
+ at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE;
+
+ cpiv = AT91_PIT_MR_PIV_MASK(readl(&pit->piir));
+
+ /* Disable PITC
+* Add 0x1000 to current counter to stop it faster
+* without waiting for wrapping back to 0
+*/
+ writel(cpiv + 0x1000, &pit->mr);
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] AT91 Fix: return value of get_tbclk
Hello Eric, On Wednesday 18 August 2010, 09:17:26 you wrote: > > Hello, > > > > Am Samstag, 7. August 2010, 19:49:42 schrieb Jens Scharsig: > > > * Fix: return value of get_tbclk > > > * this fixes issue with prematurely restart/retry, if > > > > > > BOOT_RETRY_TIMEOUT is used > > > > This issue also arises, if you use CONFIG_AUTOBOOT_KEYED & friends > > I tried both BOOT_RETRY_TIMEOUT and CONFIG_AUTOBOOT_KEYED & > CONFIG_AUTOBOOT_STOP_STR, Both work well on AT91SAM9260EK > > Which board did you tried? That's some time ago and I don't remember which u-boot version that was. I think i came across that problem on the AT91SAM9G20EK and our own SAM9G20 board. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFD] store env size in env area (+ cookie + len)
On Thursday 12 August 2010, 09:27:31 you wrote: > Why not store the size of the environment sector as env variable? The > size should be only needed for storing the environment and not for > loading (as it is terminated by a '\0'). So we could load the > environment, check for "env_size" and if its not there take the value > from fw_env.config Another possibility is to use an own mtd partition for env storage. This way you shouldn't need to know any size or offset at all. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] CONFIG_CMD_JFFS2 is not necessary to use mtdparts on erase & protect on/off
The include is still necessary though.
Signed-off-by: Alexander Stein
---
common/cmd_flash.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/common/cmd_flash.c b/common/cmd_flash.c
index ff43965..3e6bab2 100644
--- a/common/cmd_flash.c
+++ b/common/cmd_flash.c
@@ -31,7 +31,7 @@
#include
#endif
-#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
+#if defined(CONFIG_CMD_MTDPARTS)
#include
/* partition handling routines */
@@ -325,7 +325,7 @@ int do_flerase (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
flash_info_t *info;
ulong bank, addr_first, addr_last;
int n, sect_first, sect_last;
-#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
+#if defined(CONFIG_CMD_MTDPARTS)
struct mtd_device *dev;
struct part_info *part;
u8 dev_type, dev_num, pnum;
@@ -355,7 +355,7 @@ int do_flerase (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
return rcode;
}
-#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
+#if defined(CONFIG_CMD_MTDPARTS)
/* erase - erase partition */
if ((argc == 2) && (mtd_id_parse(argv[1], NULL, &dev_type, &dev_num) ==
0)) {
mtdparts_init();
@@ -465,7 +465,7 @@ int do_protect (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
#if !defined(CONFIG_SYS_NO_FLASH) || defined(CONFIG_HAS_DATAFLASH)
ulong addr_first, addr_last;
#endif
-#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
+#if defined(CONFIG_CMD_MTDPARTS)
struct mtd_device *dev;
struct part_info *part;
u8 dev_type, dev_num, pnum;
@@ -555,7 +555,7 @@ int do_protect (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
return rcode;
}
-#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
+#if defined(CONFIG_CMD_MTDPARTS)
/* protect on/off */
if ((argc == 3) && (mtd_id_parse(argv[2], NULL, &dev_type, &dev_num) ==
0)) {
mtdparts_init();
@@ -687,7 +687,7 @@ int flash_sect_protect (int p, ulong addr_first, ulong
addr_last)
/**/
-#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
+#if defined(CONFIG_CMD_MTDPARTS)
# define TMP_ERASE "erase \n- erase partition\n"
# define TMP_PROT_ON "protect on \n- protect partition\n"
# define TMP_PROT_OFF "protect off \n- make partition writable\n"
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] memmove_wd: Allow overlapping memory area
Dear Wolfgang, August 2010, 13:43:32 schrieb Wolfgang Denk: > > Well, that's at least one possibility but it is very annoying that > > something like memmove that works fine so far suddenly stops working > > when watchdog support is enabled. > > Yes, I understand this. It's also annoying when you've been using > compressed images just fine for years and suddenly they stop working > because the kernel grows beyond some magic (and undefined) limit. > > Better do not build on undefined behaviour. Yes, of course. But it seems difficult to recognise thing like a simple memmove with dest < src as an undefined behavior. > Please note that I'm not against fixing this problem, but if we > address it, it should be fixed correctly, i. e. in sich a way that it > will always work, not only for certain cases. So how to fix this then? I'm totally inexperienced to compressed images. Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] at91: Don't initialize watchdog if CONFIG_SKIP_WATCHDOG_INIT is defined
Hello Mike, Am Montag, 9. August 2010, 09:13:45 schrieb Mike Frysinger: > > On AT91 the watchdog mode register can only be written once after reset. > > If this register is written by u-boot e.g. a Linux driver can't > > reconfigure the watchdog later. If the watchdog is left untouched this > > is possible. Without touching the mode register the watchdog has a > > default setup and u-boot is still able to trigger the watchdog. > > > > [...] > > > > +- CONFIG_SKIP_WATCHDOG_INIT > > + > > + [arm AT91 only] If this variable is defined, then the > > + watchdog will not be programmed upon u-boot start. > > + On AT91 the watchdog mode register can only be written > > + once after reset. If this register is written by u-boot > > + e.g. a Linux driver can't reconfigure the watchdog later. > > If + the watchdog is left untouched this is possible. + > > Without touching the mode register the watchdog has a > > default + setup and u-boot is still able to trigger the > > watchdog. > > isnt the at91 logic inverted ? shouldnt the watchdog programming only > be done when someone has opted in to it via some watchdog define ? This was my first version, but Wolfgang NAK'ed it as he see this as the wrong approach. See http://article.gmane.org/gmane.comp.boot-loaders.u-boot/81589 Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] memmove_wd: Allow overlapping memory area
Dear Wolfgang,
Am Montag, 9. August 2010, 11:26:56 schrieb Wolfgang Denk:
> > IIRC the problem arose when i downloaded my image to 0x2000 (SD-RAM)
> > using TFTP and my Linux kernel entry point was at 0x20008000. So when
>
> Don;t do this, then. Such kind of overlap has never been supported.
> Even if it would work in your case of uncompressed images, it is bound
> to fail for compressed ones where the uncompressed code grows faster
> then compressed data get consumed.
Well, that's at least one possibility but it is very annoying that something
like memmove that works fine so far suddenly stops working when watchdog
support is enabled.
> > > > + if (to <= from)
> > > > + {
> > > > + memmove (to, from, tail);
> > > > + to += tail;
> > > > + from += tail;
> > > > + } else {
> > > > + memmove (to + len - tail, from + len - tail,
> > > > tail);
> > >
> > > In which way is this supposed to allow overlapping memory areas?
> >
> > With this change u-boot starts to copy from the end to the beginning thus
> > preventing overriding the source. This change was adopted from memmove
> > (lib/string.c) which handles this case correctly.
>
> You are just shifting the problem to another area, but you are not
> solving it. Without your patch there is a problem when the initial
> area overlaps, with your problem there is one when the tail overlaps.
Well, why is this situation then handled by memmove?
Best regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] memmove_wd: Allow overlapping memory area
Dear Wolfgang,
Am Montag, 9. August 2010, 00:18:19 schrieb Wolfgang Denk:
> In message <1279701826-20083-1-git-send-email-alexander.st...@systec-
electronic.com> you wrote:
> > Signed-off-by: Alexander Stein
> > ---
> >
> > common/image.c | 11 ---
> > 1 files changed, 8 insertions(+), 3 deletions(-)
>
> Why would this be needed? Do you have an error scenario?
IIRC the problem arose when i downloaded my image to 0x2000 (SD-RAM) using
TFTP and my Linux kernel entry point was at 0x20008000. So when
CONFIG_HW_WATCHDOG is defined u-boot starts copying from the beginning thus
overriding the source. Finally i got decompression errors upon Linux kernel
start.
Without CONFIG_HW_WATCHDOG memmove_wd is simply memmove which handled this
cased correctly.
> > + if (to <= from)
> > + {
> > + memmove (to, from, tail);
> > + to += tail;
> > + from += tail;
> > + } else {
> > + memmove (to + len - tail, from + len - tail, tail);
>
> In which way is this supposed to allow overlapping memory areas?
With this change u-boot starts to copy from the end to the beginning thus
preventing overriding the source. This change was adopted from memmove
(lib/string.c) which handles this case correctly.
Best regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] at91: Don't initialize watchdog if CONFIG_SKIP_WATCHDOG_INIT is defined
On AT91 the watchdog mode register can only be written once after reset. If this register is written by u-boot e.g. a Linux driver can't reconfigure the watchdog later. If the watchdog is left untouched this is possible. Without touching the mode register the watchdog has a default setup and u-boot is still able to trigger the watchdog. Signed-off-by: Alexander Stein --- Changes in v2: * Add a new specific option CONFIG_SKIP_WATCHDOG_INIT * Add some documentation Changes in v3: * Be more verbose in describing the problem in the commit message and README Changes in v4: * Fix commit message README | 11 +++ arch/arm/cpu/arm926ejs/at91/lowlevel_init.S |2 ++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/README b/README index b6bf451..9fbb6c9 100644 --- a/README +++ b/README @@ -2827,6 +2827,17 @@ Low Level (hardware related) configuration options: some other boot loader or by a debugger which performs these initializations itself. +- CONFIG_SKIP_WATCHDOG_INIT + + [arm AT91 only] If this variable is defined, then the + watchdog will not be programmed upon u-boot start. + On AT91 the watchdog mode register can only be written + once after reset. If this register is written by u-boot + e.g. a Linux driver can't reconfigure the watchdog later. If + the watchdog is left untouched this is possible. + Without touching the mode register the watchdog has a default + setup and u-boot is still able to trigger the watchdog. + - CONFIG_PRELOADER Modifies the behaviour of start.S when compiling a loader diff --git a/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S b/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S index 559c35c..0645ba8 100644 --- a/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S +++ b/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S @@ -186,8 +186,10 @@ SDRAM_setup_end: .ltorg SMRDATA: +#ifndef CONFIG_SKIP_WATCHDOG_INIT .word AT91_ASM_WDT_MR .word CONFIG_SYS_WDTC_WDMR_VAL +#endif /* configure PIOx as EBI0 D[16-31] */ #if defined(CONFIG_AT91SAM9263) .word AT91_ASM_PIOD_PDR -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] AT91 Fix: return value of get_tbclk
Hello,
Am Samstag, 7. August 2010, 19:49:42 schrieb Jens Scharsig:
> * Fix: return value of get_tbclk
> * this fixes issue with prematurely restart/retry, if BOOT_RETRY_TIMEOUT
> is used
This issue also arises, if you use CONFIG_AUTOBOOT_KEYED & friends
> Signed-off-by: Jens Scharsig
> ---
> the V3 supports the actually file structure.
> the original patch
> http://lists.denx.de/pipermail/u-boot/2010-April/069415.html use the old
> directory /cpu/arch structure.
>
> arch/arm/cpu/arm926ejs/at91/timer.c |5 +
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/at91/timer.c
> b/arch/arm/cpu/arm926ejs/at91/timer.c index d21eebf..8efc34b 100644
> --- a/arch/arm/cpu/arm926ejs/at91/timer.c
> +++ b/arch/arm/cpu/arm926ejs/at91/timer.c
> @@ -138,8 +138,5 @@ ulong get_timer(ulong base)
> */
> ulong get_tbclk(void)
> {
> - ulong tbclk;
> -
> - tbclk = CONFIG_SYS_HZ;
> - return tbclk;
> + return timer_freq;
> }
Best regards,
Alexander
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: Add arch_preboot_os which disables PIT in a faster way
When disabled the PIT runs until it reaches the CPIV value.
The Linux PIT driver stops the PIT and waits until it stopped. This can
take over 100ms. Simply stopping in u-boot isn't sufficient as the PIT
will still be running when Linux is waiting until it stopped.
So, we stop it in u-boot by setting the compare value to a value slightly
greater than the current running counter to make the PIT stopped in short
time.
Signed-off-by: Alexander Stein
---
arch/arm/cpu/arm926ejs/at91/cpu.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/at91/cpu.c
b/arch/arm/cpu/arm926ejs/at91/cpu.c
index 141a7d1..af86ee2 100644
--- a/arch/arm/cpu/arm926ejs/at91/cpu.c
+++ b/arch/arm/cpu/arm926ejs/at91/cpu.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -47,6 +48,20 @@ int arch_cpu_init(void)
return at91_clock_init(CONFIG_SYS_AT91_MAIN_CLOCK);
}
+void arch_preboot_os(void)
+{
+ ulong cpiv;
+ at91_pit_t *pit = (at91_pit_t *) AT91_PIT_BASE;
+
+ cpiv = AT91_PIT_MR_PIV_MASK(readl(&pit->piir));
+
+ /* Disble PITC
+* Add 0x1000 to current counter to stop it faster
+* without waiting for wrapping back to 0
+*/
+ writel(cpiv + 0x1000, &pit->mr);
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91_pit: Fix AT91_PIT_MR_PIV_MASK macro
Signed-off-by: Alexander Stein
---
arch/arm/include/asm/arch-at91/at91_pit.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-at91/at91_pit.h
b/arch/arm/include/asm/arch-at91/at91_pit.h
index 5615a02..61aca79 100644
--- a/arch/arm/include/asm/arch-at91/at91_pit.h
+++ b/arch/arm/include/asm/arch-at91/at91_pit.h
@@ -25,7 +25,7 @@ typedef struct at91_pit {
#defineAT91_PIT_MR_IEN 0x0200
#defineAT91_PIT_MR_EN 0x0100
-#defineAT91_PIT_MR_PIV_MASK(x & 0x000f)
+#defineAT91_PIT_MR_PIV_MASK(x) (x & 0x000f)
#defineAT91_PIT_MR_PIV(x) (x & AT91_PIT_MR_PIV_MASK)
#ifdef CONFIG_AT91_LEGACY
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How can i add intterrupt for AT91SAM9260EK board
Hello, Am Donnerstag, 29. Juli 2010, 08:25:53 schrieb Reinhard Meyer: > You have add interrupt handling (write source) to AT91 in general and > provide a patch for that. > > But first you have to define why you need interrupts (in the u-boot > phase) in the first place. One reason would be to workaround errata 44.3.5.1 (RSTC: Reset During SDRAM Accesses) on the AT91SAM9G20 which traps the reset interrupt to shutdown the SDRAM controller properly -.- Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] at91: Don't initialize watchdog if CONFIG_SKIP_WATCHDOG_INIT is undefined
On AT91 the watchdog mode register can only be written once after reset. If this register is written by u-boot e.g. a Linux driver can't reconfigure the watchdog later. If the watchdog is left untouched this is possible. Without touching the mode register the watchdog has a default setup and u-boot is still able to trigger the watchdog. Signed-off-by: Alexander Stein --- Changes in v2: * Add a new specific option CONFIG_SKIP_WATCHDOG_INIT * Add some documentation Changes in v3: * Be more verbose in describing the problem in the commit message and README README | 11 +++ arch/arm/cpu/arm926ejs/at91/lowlevel_init.S |2 ++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/README b/README index a9c98f2..110668d 100644 --- a/README +++ b/README @@ -2817,6 +2817,17 @@ Low Level (hardware related) configuration options: some other boot loader or by a debugger which performs these initializations itself. +- CONFIG_SKIP_WATCHDOG_INIT + + [arm AT91 only] If this variable is defined, then the + watchdog will not be programmed upon u-boot start. + On AT91 the watchdog mode register can only be written + once after reset. If this register is written by u-boot + e.g. a Linux driver can't reconfigure the watchdog later. If + the watchdog is left untouched this is possible. + Without touching the mode register the watchdog has a default + setup and u-boot is still able to trigger the watchdog. + - CONFIG_PRELOADER Modifies the behaviour of start.S when compiling a loader diff --git a/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S b/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S index 559c35c..0645ba8 100644 --- a/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S +++ b/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S @@ -186,8 +186,10 @@ SDRAM_setup_end: .ltorg SMRDATA: +#ifndef CONFIG_SKIP_WATCHDOG_INIT .word AT91_ASM_WDT_MR .word CONFIG_SYS_WDTC_WDMR_VAL +#endif /* configure PIOx as EBI0 D[16-31] */ #if defined(CONFIG_AT91SAM9263) .word AT91_ASM_PIOD_PDR -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] at91: Don't initialize watchdog if CONFIG_SKIP_WATCHDOG_INIT is undefined
This allows Linux to initialize and use the watchdog with the included driver. Signed-off-by: Alexander Stein --- Changes in v2: * Add a new specific option CONFIG_SKIP_WATCHDOG_INIT * Add some documentation README |5 + arch/arm/cpu/arm926ejs/at91/lowlevel_init.S |2 ++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/README b/README index a9c98f2..502054d 100644 --- a/README +++ b/README @@ -2817,6 +2817,11 @@ Low Level (hardware related) configuration options: some other boot loader or by a debugger which performs these initializations itself. +- CONFIG_SKIP_WATCHDOG_INIT + + [arm AT91 only] If this variable is defined, then the + watchdog will not be programmed upon u-boot start. + - CONFIG_PRELOADER Modifies the behaviour of start.S when compiling a loader diff --git a/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S b/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S index 559c35c..0645ba8 100644 --- a/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S +++ b/arch/arm/cpu/arm926ejs/at91/lowlevel_init.S @@ -186,8 +186,10 @@ SDRAM_setup_end: .ltorg SMRDATA: +#ifndef CONFIG_SKIP_WATCHDOG_INIT .word AT91_ASM_WDT_MR .word CONFIG_SYS_WDTC_WDMR_VAL +#endif /* configure PIOx as EBI0 D[16-31] */ #if defined(CONFIG_AT91SAM9263) .word AT91_ASM_PIOD_PDR -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
