Re: [U-Boot] [linux-sunxi] Uboot error: address not aligned in v7_dcache_inval_range
On Sun, 2014-04-13 at 23:45 -0400, Shixin Zeng wrote:
Hi,
I compiled the current u-boot from
https://github.com/jwrdegoede/u-boot-sunxi.git for cubieboard2, and
wrote it to the SD card. I was trying to boot the kernel on my
computer over network by tftp, however it failed when I ran dhcp or
tftp command in uboot with a tons of:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x7fb677e0
ERROR: v7_dcache_inval_range - stop address is not aligned - 0x7fb67820
I'm seeing this on Cubieboard2 and Cubietruck. It appears to be down to
a change to the upstream designware driver:
commit 50b0df814b0f75c08a3d45a017016a75af3edb5d
Author: Alexey Brodkin alexey.brod...@synopsys.com
Date: Wed Jan 22 20:49:09 2014 +0400
net/designware: make driver compatible with data cache
Up until now this driver only worked with data cache disabled.
To make it work with enabled data cache following changes were required:
* Flush Tx/Rx buffer descriptors their modification
* Invalidate Tx/Rx buffer descriptors before reading its values
* Flush cache for data passed from CPU to GMAC
* Invalidate cache for data passed from GMAC to CPU
http://git.denx.de/?p=u-boot.git;a=commit;h=50b0df814b0f75c08a3d45a017016a75af3edb5d
I suppose this was only tested on some architecture which allows DMA
flush/invaidation at a fairly fine granularity (at least down to 4 byte
boundaries)
Making sure that struct dw_eth_dev is DMA aligned helps with the
invalidate of the descriptors in dw_eth_recv (see below) but with that
the invalidate of the txrx_status field in dw_eth_send is still
problematic -- the field is only 4 bytes, so although the descriptor is
aligned the end is not.
Ian.
commit 8878d858ede12584b885fa9439f9093bf2186a90
Author: Ian Campbell i...@hellion.org.uk
Date: Sat Apr 19 14:16:04 2014 +0100
net/designware: ensure device private data is DMA aligned.
struct dw_eth_dev contains fields which are accessed via DMA, so make sure
it
is aligned to a dma boundary. Without this I see:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x7fb677e0
Signed-off-by: Ian Campbell ian.campb...@citrix.com
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 6ece479..1120f70 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -412,7 +412,8 @@ int designware_initialize(ulong base_addr, u32 interface)
* Since the priv structure contains the descriptors which need a strict
* buswidth alignment, memalign is used to allocate memory
*/
- priv = (struct dw_eth_dev *) memalign(16, sizeof(struct dw_eth_dev));
+ priv = (struct dw_eth_dev *) memalign(ARCH_DMA_MINALIGN,
+ sizeof(struct dw_eth_dev));
if (!priv) {
free(dev);
return -ENOMEM;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] net/designware: align cache invalidation on rx
Signed-off-by: Ian Campbell i...@hellion.org.uk --- drivers/net/designware.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/designware.c b/drivers/net/designware.c index 7d14cec..30446d3 100644 --- a/drivers/net/designware.c +++ b/drivers/net/designware.c @@ -354,7 +354,7 @@ static int dw_eth_recv(struct eth_device *dev) /* Invalidate received data */ invalidate_dcache_range((unsigned long)desc_p-dmamac_addr, (unsigned long)desc_p-dmamac_addr + - length); + roundup(length, ARCH_DMA_MINALIGN)); NetReceive(desc_p-dmamac_addr, length); -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] net/designware: ensure device private data is DMA aligned.
struct dw_eth_dev contains fields which are accessed via DMA, so make sure it
is aligned to a dma boundary. Without this I see:
ERROR: v7_dcache_inval_range - start address is not aligned - 0x7fb677e0
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
drivers/net/designware.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 6ece479..1120f70 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -412,7 +412,8 @@ int designware_initialize(ulong base_addr, u32 interface)
* Since the priv structure contains the descriptors which need a strict
* buswidth alignment, memalign is used to allocate memory
*/
- priv = (struct dw_eth_dev *) memalign(16, sizeof(struct dw_eth_dev));
+ priv = (struct dw_eth_dev *) memalign(ARCH_DMA_MINALIGN,
+ sizeof(struct dw_eth_dev));
if (!priv) {
free(dev);
return -ENOMEM;
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] net/designware: invalidate entire descriptor in dw_eth_send
Some platforms cannot invalidate the cache at four byte intervals, so
invalidate the entire descriptor.
Signed-off-by: Ian Campbell i...@hellion.org.uk
---
drivers/net/designware.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 1120f70..7d14cec 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -280,10 +280,13 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
u32 desc_num = priv-tx_currdescnum;
struct dmamacdescr *desc_p = priv-tx_mac_descrtable[desc_num];
- /* Invalidate only status field for the following check */
- invalidate_dcache_range((unsigned long)desc_p-txrx_status,
- (unsigned long)desc_p-txrx_status +
- sizeof(desc_p-txrx_status));
+ /* Strictly we only need to invalidate the status field for
+* the following check, but on some platforms we cannot
+* invalidate only 4 bytes, so invalidate the the whole thing
+* which is known to be DMA aligned. */
+ invalidate_dcache_range((unsigned long)desc_p,
+ (unsigned long)desc_p +
+ sizeof(struct dmamacdescr));
/* Check if the descriptor is owned by CPU */
if (desc_p-txrx_status DESC_TXSTS_OWNBYDMA) {
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] config: enable CONFIG_API in distro config
On Fri, 2014-04-18 at 11:43 -0600, Simon Glass wrote: Hi Stephen, On 18 April 2014 11:23, Stephen Warren swar...@wwwdotorg.org wrote: On 04/18/2014 09:35 AM, Tom Rini wrote: On Thu, Apr 10, 2014 at 03:55:48PM -0500, Rob Herring wrote: From: Rob Herring r...@kernel.org CONFIG_API is needed for u-boot apps such as grub2, so enable it for distro config. Cc: Dennis Gilmore den...@ausil.us Signed-off-by: Rob Herring r...@kernel.org This breaks a number of boards that have opted in to the distro config. The full list is: whistler trimslice beaver tec paz00 ventana cardhu harmony dalmore plutux medcom-wide rpi_b venice2 colibri_t20_iris tec-ng seaboard How do you guys want to handle this? I can apply now and they can be fixed up later, or I can wait for fixup patches to come out and apply them all at once. Thanks! I've sent patches that solve all the build problems on Tegra with CONFIG_API enabled. That said, I still conceptually object to config_distro_defaults.h enabling API support in order to support grub; I believe the distros need to get together and nail down a *single* boot mechanism to standardize upon, rather than having Fedora support BootloaderSpec, Ubuntu/Linaro(?) support Grub, something else support LILO, something else support UEFI, AIUI the distros *are* standardising: on grub2. AIUI BootloaderSpec is a spec to standardise the configuration of UEFI. It is used to install the distro's bootloader (often grub2) into the UEFI boot list, for grub-on-UEFI scenarios. Where the lowlevel firmware is u-boot then they want to use grub2 on it so that things are consistently grub no matter whether the platform uses UEFI, u-boot, PC BIOS etc. etc. Without this, we'll force every U-Boot binary to be bloated with all kinds of redundant code. Having a single standard mechanism was always the point of config_distro_defaults.h in my mind. If we really need Grub support, wouldn't it be better to have U-Boot parse and execute grub.cfg, just like it does extlinux.cfg? That seems to make a lot more sense to me. How hard can it possibly be? Very. grub.cfg is essentially a complete bash-a-like programming language. At work we try to parse it for Xen's pygrub utility and it breaks pretty frequently when people introduce random new variables etc. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] config: enable CONFIG_API in distro config
On Sat, 2014-04-19 at 02:05 +0100, Leif Lindholm wrote: Ian Campbell wrote some neat patches for patching the (grub) kernel link addres at grub-install time, which would be an improvement, but is also quite invasive over several ports: http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00426.html Even with this you still need some sort of distro mechanism for determining the grub load address for the platform at installation time, which is a pain. Leif and I also poked at the possibility of a relocatable (i.e. PIC/PIE) grub image, but just couldn't get the compiler to produce anything halfway correct (not sure why, but it was getting into some of the dustier corners of gcc/ld options). Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] rtc: add support maxim dallas rtc ds1347
From 48802d37079bfc3e705cd43af78b7b2186a02046 Mon Sep 17 00:00:00 2001
From: Raghavendra Ganiga ravi23gan...@gmail.com
Date: Thu, 17 Apr 2014 23:14:22 +0530
Subject: [PATCH] rtc: add support maxim dallas rtc ds1347
This is a patch to add support for
maxim dallas rtc ds1347
Signed-off-by: Raghavendra Chandra Ganiga ravi23gan...@gmail.com
---
drivers/rtc/Makefile |1 +
drivers/rtc/ds1347.c | 180 ++
2 files changed, 181 insertions(+)
create mode 100644 drivers/rtc/ds1347.c
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 003d322..d26d4e1 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_RTC_DS1306) += ds1306.o
obj-$(CONFIG_RTC_DS1307) += ds1307.o
obj-$(CONFIG_RTC_DS1338) += ds1307.o
obj-$(CONFIG_RTC_DS1337) += ds1337.o
+obj-$(CONFIG_RTC_DS1347) += ds1347.o
obj-$(CONFIG_RTC_DS1374) += ds1374.o
obj-$(CONFIG_RTC_DS1388) += ds1337.o
obj-$(CONFIG_RTC_DS1556) += ds1556.o
diff --git a/drivers/rtc/ds1347.c b/drivers/rtc/ds1347.c
new file mode 100644
index 000..b452c36
--- /dev/null
+++ b/drivers/rtc/ds1347.c
@@ -0,0 +1,180 @@
+/*
+ * Dallas Maxim RTC DS1347 Driver
+ *
+ * Copyright (C) 2014 Raghavendra Chandra Ganiga ravi23gan...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include rtc.h
+#include spi.h
+
+#if defined(CONFIG_CMD_DATE)
+
+/*
+* DS1347 Registers
+*/
+#define RTC_SECONDS_REG0x01
+#define RTC_MINUTES_REG0x03
+#define RTC_HOURS_REG 0x05
+#define RTC_DATE_REG 0x07
+#define RTC_MONTH_REG 0x09
+#define RTC_DAY_REG0x0B
+#define RTC_YEAR_REG 0x0D
+#define RTC_CONTROL_REG0x0F
+#define RTC_CENTURY_REG0x13
+#define RTC_ALARM_CONFIG_REG 0x15
+#define RTC_STATUS_REG 0x17
+#define RTC_ALARM_SEC_REG 0x19
+#define RTC_ALARM_MIN_REG 0x1B
+#define RTC_ALARM_HOUR_REG 0x1D
+#define RTC_ALARM_DATE_REG 0x1F
+#define RTC_ALARM_MONTH_REG0x21
+#define RTC_ALARM_DAY_REG 0x23
+#define RTC_ALARM_YEAR_REG 0x25
+#define RTC_BURST_REG 0x3F
+
+static struct spi_slave *slave;
+
+static unsigned char rtc_read(unsigned char address);
+static int rtc_write(unsigned char address, unsigned char value);
+
+int rtc_get(struct rtc_time *tm)
+{
+ int ret;
+ unsigned char data, century;
+ if (!slave) {
+ slave = spi_setup_slave(CONFIG_DS1347_BUS,
+ CONFIG_DS1347_CS, 100,
+ SPI_MODE_3);
+ if (!slave)
+ return -1;
+ }
+
+ ret = spi_claim_bus(slave);
+ if (ret)
+ return -1;
+
+ data = rtc_read(RTC_SECONDS_REG);
+ tm-tm_sec = bcd2bin(data);
+
+ data = rtc_read(RTC_MINUTES_REG);
+ tm-tm_min = bcd2bin(data);
+
+ data = rtc_read(RTC_HOURS_REG);
+ tm-tm_hour = bcd2bin(data);
+
+ data = rtc_read(RTC_DATE_REG);
+ tm-tm_mday = bcd2bin(data);
+
+ data = rtc_read(RTC_MONTH_REG);
+ tm-tm_mon = bcd2bin(data);
+
+ /* use the century register support in rtc */
+ century = rtc_read(RTC_CENTURY_REG);
+ data = rtc_read(RTC_YEAR_REG);
+ tm-tm_year = bcd2bin(data) + (bcd2bin(century) * 100);
+
+ data = rtc_read(RTC_DAY_REG);
+ tm-tm_wday = bcd2bin(data) - 1;
+
+ tm-tm_yday = 0;
+ tm-tm_isdst= 0;
+
+ spi_release_bus(slave);
+
+ return 0;
+}
+
+int rtc_set(struct rtc_time *tm)
+{
+ int ret;
+ unsigned char data;
+
+ if (!slave) {
+ slave = spi_setup_slave(CONFIG_DS1347_BUS,
+ CONFIG_DS1347_CS, 100,
+ SPI_MODE_3);
+
+ if (!slave)
+ return -1;
+ }
+
+ ret = spi_claim_bus(slave);
+ if (ret)
+ return -1;
+
+ rtc_write(RTC_SECONDS_REG, bin2bcd(tm-tm_sec));
+
+ rtc_write(RTC_MINUTES_REG, bin2bcd(tm-tm_min));
+
+ rtc_write(RTC_HOURS_REG, bin2bcd(tm-tm_hour));
+
+ rtc_write(RTC_DATE_REG, bin2bcd(tm-tm_mday));
+
+ rtc_write(RTC_MONTH_REG, bin2bcd(tm-tm_mon));
+
+ /* use the century register support in rtc */
+ data = tm-tm_year / 100;
+ rtc_write(RTC_CENTURY_REG, bin2bcd(data));
+
+ data = tm-tm_year % 100;
+ rtc_write(RTC_YEAR_REG, bin2bcd(data));
+
+ rtc_write(RTC_DAY_REG, bin2bcd(tm-tm_wday + 1));
+
+ spi_release_bus(slave);
+
+ return 0;
+}
+
+void rtc_reset(void)
+{
+ int ret;
+
+ if (!slave) {
+ slave = spi_setup_slave(CONFIG_DS1347_BUS,
+ CONFIG_DS1347_CS, 100,
+ SPI_MODE_3);
+
+ if (!slave)
+ return;
+ }
+
+
Re: [U-Boot] [linux-sunxi] Re: [PATCH 2/3] net/designware: invalidate entire descriptor in dw_eth_send
On Sat, 2014-04-19 at 10:14 -0400, Stefan Monnier wrote: Some platforms cannot invalidate the cache at four byte intervals, so invalidate the entire descriptor. Wouldn't it be simpler to make invalidate_dcache_range round up to the nearest aligned boundaries? Can there ever be situations where invalidating too much could be a problem? Yes, if there was any data you cared about in the rounded up region after the region you were actually trying to invalidate. invalidate here means throw away the content of the cache line without writing back to ram, which is what you want if the content of RAM is more up to date than the cache (because the device has DMAd to it). So invalidating more than was asked for would more than likely lead to subtle errors. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] config: enable CONFIG_API in distro config
On Fri, 2014-04-18 at 11:23 -0600, Stephen Warren wrote: That said, I still conceptually object to config_distro_defaults.h enabling API support in order to support grub; A worse problem is that I'm far from convinced that the API is suitable to be used in production. The mechanism for determining the API entry point involves scanning the region around some address looking for a signature. The search area is determined by the coincidence that the API signature struct is allocated with u-boot's malloc and can therefore be found somewhere near the GD pointer, which happens to be in a register which is luckily not corrupted when booting. grub has a hack for at least one platform which mallocd more data and therefore the signature ended up outside of the region to be searched. The calling convention is also somewhat poorly specified, and has been broken at least once because the app is required to preserve u-boot's GD pointer in the correct register and that register has changed at least once inadvertently because the GD register isn't (wasn't?) considered API. http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/174287 Maybe some of this is just down to the API not being very widely used in practice, but to me it has the smell of a prototype which got out of hand and became an API without someone revisiting the issues which made it experimental to start with... Look at the history of api/* and example/api/*. Other than occasional build fixes and generic changes which touch it nothing has really changed since the very first experimental commit... Sorry if this comes across as ragging on the API, but my experience with using it for grub-on-u-boot was incredibly frustrating and not very reassuring... Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] am33xx: add SSC enable macro
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- Changes: v2: use CM_CLKMODE_DPLL_SSC_EN_MASK in board file of Siemens device arch/arm/include/asm/arch-am33xx/clock.h | 2 ++ board/siemens/rut/board.c| 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-am33xx/clock.h b/arch/arm/include/asm/arch-am33xx/clock.h index 7637457..f00fad3 100644 --- a/arch/arm/include/asm/arch-am33xx/clock.h +++ b/arch/arm/include/asm/arch-am33xx/clock.h @@ -42,6 +42,8 @@ #define MODULE_CLKCTRL_IDLEST_DISABLED 3 /* CM_CLKMODE_DPLL */ +#define CM_CLKMODE_DPLL_SSC_EN_SHIFT 12 +#define CM_CLKMODE_DPLL_SSC_EN_MASK(1 12) #define CM_CLKMODE_DPLL_REGM4XEN_SHIFT 11 #define CM_CLKMODE_DPLL_REGM4XEN_MASK (1 11) #define CM_CLKMODE_DPLL_LPMODE_EN_SHIFT10 diff --git a/board/siemens/rut/board.c b/board/siemens/rut/board.c index e0ada3f..1752df2 100644 --- a/board/siemens/rut/board.c +++ b/board/siemens/rut/board.c @@ -400,7 +400,7 @@ static int conf_disp_pll(int m, int n) #if defined(DISPL_PLL_SPREAD_SPECTRUM) writel(0x64, cmwkup-resv6[3]); /* 0x50 */ writel(0x800, cmwkup-resv6[2]); /* 0x4c */ - writel(readl(cmwkup-clkmoddplldisp) | (1 12), + writel(readl(cmwkup-clkmoddplldisp) | CM_CLKMODE_DPLL_SSC_EN_MASK, cmwkup-clkmoddplldisp); /* 0x98 */ #endif return 0; -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] lsxl: rework boot scripts
Am 2014-04-01 20:09, schrieb Michael Walle: Move addresses for kernel, ramdisk and fdt blob to own variables. Add dtb blob loading to all existing boot scripts, dtb filenames were taken from vanilla kernel. Introduce new boot script bootcmd_legacy, which only loads a kernel and a ramdisk. Make this the default boot script. This should also restore the behaviour of the original bootloader. Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Tom Rini tr...@ti.com Signed-off-by: Michael Walle mich...@walle.cc ping 2 albert, could you merge this? prafulla does not seem to answer. -- michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
