[U-Boot] [PATCH v2] dwmmc: make driver usable for non-exynos platforms
There's no point in having of dwmmc.h per architecure - we're talking
about device driver (DesignWare MMC controller) which is expected to
work with any CPU it is attached to.
Actually this change should have been an essential part of commit:
===
6f0b7caa671f92c2d4676c84381d17fb90f7d2cd
DWMMC: SMDK5420: Disable SMU for eMMC
===
Or even better I'd prefer all non pure DW MMC functionality (those item
in ifdefs) to be moved to corresponding files like exynos_dw_mmc.c via
call-backs etc. This will keep DW MMC driver clean and simple.
As it is said in http://www.denx.de/wiki/U-Boot/DesignPrinciples:
===
8. Keep it Maintainable
Avoid #ifdefs where possible
===
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Mischa Jonker mjon...@synopsys.com
Cc: Jaehoon Chung jh80.ch...@samsung.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Alim Akhtar alim.akh...@samsung.com
Cc: Rajeshwari Shinde rajeshwar...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Changes compared to initial version:
Instead of modification of headers only disable some parts of code with
ifdefs.
---
drivers/mmc/dw_mmc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 1e0f72b..fdae40b 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -11,7 +11,9 @@
#include mmc.h
#include dwmmc.h
#include asm-generic/errno.h
+#ifdef CONFIG_EXYNOS5420
#include asm/arch/dwmmc.h
+#endif
#define PAGE_SIZE 4096
@@ -302,6 +304,7 @@ static int dwmci_init(struct mmc *mmc)
struct dwmci_host *host = (struct dwmci_host *)mmc-priv;
u32 fifo_size;
+#ifdef CONFIG_EXYNOS5420
if (host-quirks DWMCI_QUIRK_DISABLE_SMU) {
dwmci_writel(host, EMMCP_MPSBEGIN0, 0);
dwmci_writel(host, EMMCP_SEND0, 0);
@@ -311,6 +314,7 @@ static int dwmci_init(struct mmc *mmc)
MPSCTRL_NON_SECURE_READ_BIT |
MPSCTRL_NON_SECURE_WRITE_BIT | MPSCTRL_VALID);
}
+#endif
dwmci_writel(host, DWMCI_PWREN, 1);
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] cmd_eeprom: bug fix for i2c read/write
On Fri, 2013-11-29 at 17:32 +0800, Kuo-Jung Su wrote: Unfortunately I still cannot agree with you. In my opinion I2C driver has nothing to do with current situation. Yes, that's why I said the root cause is U-Boot's I2C model. The address should never be rebuilt/reformated inside the I2C driver. The better solution is to update the i2c_read/i2c_write to: int i2c_read(struct i2c_adapter *adap, u8 dev, uint *addr, int alen, uchar *buf, int len) or int i2c_read(struct i2c_adapter *adap, u8 dev, uchar *buf, int len) i.e., drop the use of uint 'addr' Well, even in current state of I2C core and some particular drivers (like DW I2C) no reformat of address happens as far as I can tell. But I cannot tell about each and every I2C driver in U-boot. Still if you'd like to modify U-Boot's I2C model it is up to you to start this discussion/work if you haven't start it yet (sorry I don't read entire U-boot mailing list daily). But then it's good to modify all drivers as well so nobody gets dead/not-built I2C drivers at some point, right? It's purely how manufacturers of EEPROM use I2C. For example I we use PCF8594C-2 EEPROM. Here's a datasheet - http://www.nxp.com/documents/data_sheet/PCF8594C_2.pdf Its capacity is 512 bytes. And as you may see from Fig 3. Device addressing. Each IC houses 2 virtual EEPROMs (each housing 256 bytes of data). Yes, it looks like a special case which use BIT0 of device address for page selection. Which means we can't directly pass the device address to i2c_read/i2c_write. But it's still o.k to directly the 'offset' as what we did before. Frankly I don't understand how passing entire offset will work in this particular corner-case. From my explanation you see that we have to mimic 8-bit address of target byte in EEPROM. And even if our I2C controller may use 10 bits for addressing it is something that we don't want use here - we need 8-bit as we do now. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dwmmc: make driver usable for non-exynos platforms
On Fri, 2013-11-29 at 18:57 +0900, Jaehoon Chung wrote: I think good that just removed the #include asm/arch/dwmmc.h. Instead, Exnyos specific code can move into dw-mmc-exynos.c with callback function. (I didn't know whcih Soc is used with MPSCTRL register.) Because of this you selected this offset 0x9c and experience no problems. But at some point you may get HW configured to use 64-bit addressing and you'll need to use another offset for Exynos-specific things. I understand that as SW engineer you have not much things to do here but would be good if you communicate this to HW engineers. If other soc is used 0x9c offset as other register? 0x9c is used the CLKSEL at exynos. we need to consider other soc. Then it's good that exynos specific code will move into dw-mmc-exynos.c. isn't? Ok, so please look at my re-spin I already sent (you were on CC-list). There I only mask problematic bits of code - so driver works again for me (I'm on other architecture BTW - not ARM). But if you're willing to clean-up dwmmc code from Exynos-specific parts I'll be more than happy. Well it doesn't stop us from application of my v2 that will be a temporary fix until clean-up. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dwmmc: make driver usable for non-exynos platforms
On Fri, 2013-11-29 at 19:00 +0900, Jaehoon Chung wrote: remove this and use callback function like the host-board_init()? if (host-board_init()) host-board_init(host); Then we can reuse the this function for board specific code. Anyway, I think that exynos code didn't exist at here(dw-mmc.c). Best Regards, Jaehoon Chung dwmci_writel(host, DWMCI_PWREN, 1); I may do this change but I don't own corresponding HW (Exynos-5420 based) so I won't be able to test my changes. And that's why I propose to apply this patch so driver is now again gets built for any platform and if anybody who have access to Exynos-5420 HW have some time to clean-up then it's good, anyways people will be happy again :) -Alexey P.S. I saw you reply on v1 patch you just sent - so feel free to clean-up the driver if it's ok for you or let's keep my work-around for now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: remove the exynos specific code in dw-mmc.c
Acked-by: Alexey Brodkin abrod...@synopsys.com On Fri, 2013-11-29 at 20:08 +0900, Jaehoon Chung wrote: dw-mmc.c is the general driver file. So, remove the exynos specific code at dw-mmc.c. Instead, exynos specific cod can be move into exynos-dw_mmc.c. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dwmmc: make driver usable for non-exynos platforms
All looks good from my side; Please do a boot test on the real hardware and let me know before I can apply. Hi Pantelis, confirming - builds/works good for me. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dwmmc: make driver usable for non-exynos platforms
On Mon, 2013-12-02 at 14:45 +0900, Jaehoon Chung wrote: Hi, Rajeshwari It didn't need to include this patch. Best Regards, Jaehoon Chung Agree, there's no need in this particular patch any more. Jaehoon Chung did appropriate changes in dwmmc driver. Thanks for collaboration. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] cmd_eeprom: bug fix for i2c read/write
On Mon, 2013-12-02 at 16:02 +0800, Kuo-Jung Su wrote: From: Kuo-Jung Su dant...@faraday-tech.com diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c index 02539c4..3924805 100644 --- a/common/cmd_eeprom.c +++ b/common/cmd_eeprom.c @@ -161,7 +161,7 @@ int eeprom_read (unsigned dev_addr, unsigned offset, uchar *buffer, unsigned cnt #if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) spi_read (addr, alen, buffer, len); #else - if (i2c_read (addr[0], addr[1], alen-1, buffer, len) != 0) + if (i2c_read(addr[0], offset, alen - 1, buffer, len)) rcode = 1; #endif buffer += len; I think this change is whether incomplete or improper. Let's look at source code above line 161: = 125 #if CONFIG_SYS_I2C_EEPROM_ADDR_LEN == 1 !defined(CONFIG_SPI_X) 126 uchar addr[2]; 127 128 blk_off = offset 0xFF;/* block offset */ 129 130 addr[0] = offset 8; /* block number */ 131 addr[1] = blk_off; /* block offset */ 132 alen= 2; 133 #else 134 uchar addr[3]; 135 136 blk_off = offset 0xFF;/* block offset */ 137 138 addr[0] = offset 16; /* block number */ 139 addr[1] = offset 8; /* upper address octet */ 140 addr[2] = blk_off; /* lower address octet */ 141 alen= 3; 142 #endif /* CONFIG_SYS_I2C_EEPROM_ADDR_LEN, CONFIG_SPI_X */ 143 144 addr[0] |= dev_addr;/* insert device address */ = From these line you see that addr[0] is set like this: === If CONFIG_SYS_I2C_EEPROM_ADDR_LEN == 1: addr[0] = offset 8; If CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1: addr[0] = offset 16; And in both cases then OR with dev_addr: addr[0] |= dev_addr; === In other words it gets both real I2S slave address + MSB bits of offset. But note that offset value stays unchanged. So if you pass both addr[0] (which already has MSB bits of offset) and offset itself then you'll get completely incorrect I2C command. @@ -339,7 +339,7 @@ int eeprom_write (unsigned dev_addr, unsigned offset, uchar *buffer, unsigned cn /* Write is enabled ... now write eeprom value. */ #endif - if (i2c_write (addr[0], addr[1], alen-1, buffer, len) != 0) + if (i2c_write(addr[0], offset, alen - 1, buffer, len)) rcode = 1; #endif Same goes to eeprom_write. Moreover I'd say that this address/offset tricks are very EEPROM-specific and because of this we'd better keep it here and don't modify generic I2C code. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm: exynos: remove the unused define.
On Tue, 2013-12-03 at 14:00 +0900, Jaehoon Chung wrote: These defines didn't use anywhere. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- arch/arm/include/asm/arch-exynos/dwmmc.h |4 1 file changed, 4 deletions(-) Acked-by: Alexey Brodkin abrod...@synopsys.com Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] cmd_eeprom: bug fix for i2c read/write
On Tue, 2013-12-03 at 08:55 +0800, Kuo-Jung Su wrote:
The comment bellow clearly explain the issue here.
soft_i2c.c: line 351 ~ 367:
#ifdef CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
/*
* EEPROM chips that implement address overflow are ones
* like Catalyst 24WC04/08/16 which has 9/10/11 bits of
* address and the extra bits end up in the chip address
* bit slots. This makes a 24WC08 (1Kbyte) chip look like
* four 256 byte chips.
*
* Note that we consider the length of the address field to
* still be one byte because the extra address bits are
* hidden in the chip address.
*/
chip |= ((addr (alen * 8)) CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW);
PRINTD(i2c_read: fix addr_overflow: chip %02X addr %02X\n,
chip, addr);
#endif
Indeed comment is pretty clear.
But IMHO this code is very generic (how is it bound to any specific
device driver?) and because of this I believe it should be in common I2C
sources but not in device-specific ones.
Otherwise do we need to copy-paste this snippet to all I2C drivers?
I do like the code above for modification of slave address (chip) -
for me it looks very clear and CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW makes
perfect sense.
So why don't we try to push this in generic eeprom_{read|write}?
Yes,the address/offset tricks are device specific (not only EEPROM, it
also applies to Audio Codecs..etc.)
Saying device specific I meant not I2C driver specific but attached
I2C slave specific.
As you correctly stated this kind of tricky addressing is used by
EEPROMs, audio codecs etc.
So when we need to work with EEPPROM with ADDR_OVERFLOW I expect to
enable CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW in configuration.
But imagine if the same I2C bus has another slave which expects normal
I2C addressing. So how then you're going to configure your I2C driver so
it correctly works with both slaves?
My vision of resolution is like this: I2C driver always work in normal
addressing mode - just uses chip and address values as they are,
but in higher level code like in ours cmd_eeprom we may modify both
chip and offset values for each particular type of attached I2C
device.
But this code was there over a decade. And if everything works just
fine, why bother ?
Well as it turned out not everything worked that fine. As I discovered
dw_i2c didn't work because of missing address re-calculation.
Indeed I may agree with your previous patch:
=
if (i2c_write(dev_addr, offset, alen - 1, buffer, len))
=
and implement address modification in dw_i2c driver.
But still there're questions:
1. Which other drivers will require update? and who's going to check/fix
it there?
2. Why do we need all this address modification part in cmd_eeprom.c?
And if we don't need - who's going to clean this up?
BTW what I cannot understand is why soft_i2c_read has this chip
modification part while soft_i2c_write doesn't? Is it done on purpose?
And how it actually works at all then?
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc/dwmmc: modify FIFO threshold only if value explicitly set
On Wed, 2013-11-27 at 22:07 +0900, Jaehoon Chung wrote: Acked-by: Jaehoon Chung jh80.ch...@samsung.com Any chance to get this patch applied? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 4/4] cmd_eeprom: bug fix for i2c read/write
Hi Heiko, On Mon, 2013-12-09 at 07:56 +0100, Heiko Schocher wrote: Applied to u-boot.i2c.git, thanks! I'm wondering if you've seen a discussion between me and Kuo-jung regarding this patch and consequences of it being applied. Do you mind to comment on questions we discussed there? My main concern is how to keep underlying I2C drivers working because as I wrote some of them will not function any more correctly. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lib/time - fix usec_to_tick calculation for hi freq system timers
Current implementation works fine if usec * get_tbclk() fits in 32
bits. Otherwise result will be cut down to 32-bit.
Fix is obvious - first extend data type of either operand.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Mischa Jonker mjon...@synopsys.com
---
lib/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/time.c b/lib/time.c
index 09bb05a..80003c3 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -71,7 +71,7 @@ unsigned long __weak notrace timer_get_us(void)
}
static unsigned long long usec_to_tick(unsigned long usec)
{
- uint64_t tick = usec * get_tbclk();
+ uint64_t tick = (uint64_t)usec * get_tbclk();
usec *= get_tbclk();
do_div(tick, 100);
return tick;
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lib/time - remove obsolete code
Seems like this is a reminder of some legacy stuff.
Definitely of no use now.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Mischa Jonker mjon...@synopsys.com
---
lib/time.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/time.c b/lib/time.c
index 80003c3..c47bff7 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -72,7 +72,6 @@ unsigned long __weak notrace timer_get_us(void)
static unsigned long long usec_to_tick(unsigned long usec)
{
uint64_t tick = (uint64_t)usec * get_tbclk();
- usec *= get_tbclk();
do_div(tick, 100);
return tick;
}
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 4/4] cmd_eeprom: bug fix for i2c read/write
On Mon, 2013-12-09 at 12:21 +0100, Heiko Schocher wrote:
I thought the v3 patch just rolls things back as patch comment states:
Changes for v3:
- It turns out that what we did before 2013-11-13
(i.e., cmd_eeprom: fix i2c_{read|write} usage if env is in I2C EEPROM)
is still the best one, this patch simply rollback to it with coding
style fix.
Without this roll back, I think, some boards are broken now in current
mainline... so first we should go this step back.
I'd say it's very questionable. For example if you look at I2C driver
that Kuo-Jung refers to (soft_i2c) you'll find that with my patch
applied (the one you've just rolled back) it will work flawlessly
because:
1. chip address there has double applied MSB bits of offset (the first
time it gets applied in cmd_eeprom)
2. Only LSB byte of offset gets written in I2C device if addr_len = 1.
This one makes IMHO much more sense because it excludes an extra chip
address modification - so it's clear that it will be done by particular
I2C driver so people won't be confused with their expectations.
BTW what I cannot understand is why soft_i2c_read has this chip
modification part while soft_i2c_write doesn't? Is it done on purpose?
And how it actually works at all then?
Good question ... maybe currently only used on i2c reads ?
Frankly I have only 1 supposition regarding this strange state of things
in soft_i2c_write. Because without any doubts the same modification of
chip address is applicable to both read and write because it is an
integral part of data addressing.
But due to discussed a lot in this thread double chip address
modification (application of MSB bits of offset) proper support of
chip address was never implemented in soft_i2c_write. As you
correctly mentioned - real ancient code works and nobody has problems
with it. Well, just because we have current implementation of
eeprom_write that does chip address modification soft_i2c may not
have this feature in both read and write.
So I'd prefer to go with previous version of patch sent by Kuo-Jung
http://patchwork.ozlabs.org/patch/294733/
And indeed this will break functionality of currently incomplete
implementation of soft_i2c_write.
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_f: explicitly disable console on early boot
On Thu, 2013-11-28 at 13:55 +0400, Alexey Brodkin wrote: On Wed, 2013-11-27 at 18:43 -0700, Simon Glass wrote: I have a similar patch locally, but it actually does memset() on the whole structure. Some archs handle this setup differently. For example both ARM and x86 now allocate it in low level code so there is no need for the board_f code to allocate a global data structure. Another approach would be to move zero_global_data from init_sequence_f to the very beginning of board_init_f right after global data allocation. But IMHO it is a bit more significant modification so I decided to start from the simplest fix that resolves a particular issue I see. Any chance for this patch to be applied or described problem has to be resolved/worked-around in any other way? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_eeprom - fix bus recovery for eeprom_bus_read
env_eeprom_bus is no longer in use (it was introduced in commit 548738b4d43af841ff58c787bce297ac6a8bf7d1 cmd_eeprom: I2C updates). As in eeprom_bus_write we just reset I2C bus with the one we saved in old_bus. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Wolfgang Denk w...@denx.de Cc: Tom Rini tr...@ti.com Cc: Heiko Schocher h...@denx.de --- common/env_eeprom.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/common/env_eeprom.c b/common/env_eeprom.c index 0dcdd1f..0db2bb6 100644 --- a/common/env_eeprom.c +++ b/common/env_eeprom.c @@ -24,7 +24,6 @@ DECLARE_GLOBAL_DATA_PTR; env_t *env_ptr; char *env_name_spec = EEPROM; -int env_eeprom_bus = -1; static int eeprom_bus_read(unsigned dev_addr, unsigned offset, uchar *buffer, unsigned cnt) @@ -40,8 +39,7 @@ static int eeprom_bus_read(unsigned dev_addr, unsigned offset, rcode = eeprom_read(dev_addr, offset, buffer, cnt); #if defined(CONFIG_I2C_ENV_EEPROM_BUS) - if (old_bus != env_eeprom_bus) - i2c_set_bus_num(old_bus); + i2c_set_bus_num(old_bus); #endif return rcode; @@ -63,6 +61,7 @@ static int eeprom_bus_write(unsigned dev_addr, unsigned offset, #if defined(CONFIG_I2C_ENV_EEPROM_BUS) i2c_set_bus_num(old_bus); #endif + return rcode; } -- 1.8.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] serial/serial_arc - add driver for ARC UART
Driver for non-standard on-chip UART, instantiated in the ARC (Synopsys)
FPGA Boards such as ARCAngel4/ML50x
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Mischa Jonker mjon...@synopsys.com
Cc: Francois Bedard fbed...@synopsys.com
Cc: Tom Rini tr...@ti.com
Cc: Wolfgang Denk w...@denx.de
Cc: Stefano Babic sba...@denx.de
---
drivers/serial/Makefile | 1 +
drivers/serial/serial.c | 2 +
drivers/serial/serial_arc.c | 105
3 files changed, 108 insertions(+)
create mode 100644 drivers/serial/serial_arc.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 6b4cade..5eb4601 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_ZYNQ_SERIAL) += serial_zynq.o
obj-$(CONFIG_BFIN_SERIAL) += serial_bfin.o
obj-$(CONFIG_FSL_LPUART) += serial_lpuart.o
obj-$(CONFIG_MXS_AUART) += mxs_auart.o
+obj-$(CONFIG_ARC_SERIAL) += serial_arc.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index df2b84a..05cb369 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -160,6 +160,7 @@ serial_initfunc(sa1100_serial_initialize);
serial_initfunc(sh_serial_initialize);
serial_initfunc(arm_dcc_initialize);
serial_initfunc(mxs_auart_initialize);
+serial_initfunc(arc_serial_initialize);
/**
* serial_register() - Register serial driver with serial driver core
@@ -253,6 +254,7 @@ void serial_initialize(void)
sh_serial_initialize();
arm_dcc_initialize();
mxs_auart_initialize();
+ arc_serial_initialize();
serial_assign(default_serial_console()-name);
}
diff --git a/drivers/serial/serial_arc.c b/drivers/serial/serial_arc.c
new file mode 100644
index 000..e63d25d
--- /dev/null
+++ b/drivers/serial/serial_arc.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2013 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include common.h
+#include serial.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct arc_serial_regs {
+ unsigned int id0;
+ unsigned int id1;
+ unsigned int id2;
+ unsigned int id3;
+ unsigned int data;
+ unsigned int status;
+ unsigned int baudl;
+ unsigned int baudh;
+};
+
+/* Bit definitions of STATUS register */
+#define UART_RXEMPTY (1 5)
+#define UART_OVERFLOW_ERR (1 1)
+#define UART_TXEMPTY (1 7)
+
+struct arc_serial_regs *regs;
+
+static void arc_serial_setbrg(void)
+{
+ int arc_console_baud;
+
+ if (!gd-baudrate)
+ gd-baudrate = CONFIG_BAUDRATE;
+
+ arc_console_baud = gd-cpu_clk / (gd-baudrate * 4) - 1;
+ writel(arc_console_baud 0xff, regs-baudl);
+ writel((arc_console_baud 0xff00) 8, regs-baudh);
+}
+
+static int arc_serial_init(void)
+{
+ regs = (struct arc_serial_regs *)CONFIG_ARC_UART_BASE;
+ serial_setbrg();
+ return 0;
+}
+
+static void arc_serial_putc(const char c)
+{
+ if (c == '\n')
+ arc_serial_putc('\r');
+
+ while (!(readl(regs-status) UART_TXEMPTY))
+ ;
+
+ writel(c, regs-data);
+}
+
+static int arc_serial_tstc(void)
+{
+ return !(readl(regs-status) UART_RXEMPTY);
+}
+
+static int arc_serial_getc(void)
+{
+ while (!arc_serial_tstc())
+ ;
+
+ /* Check for overflow errors */
+ if (readl(regs-status) UART_OVERFLOW_ERR)
+ return 0;
+
+ return readl(regs-data) 0xFF;
+}
+
+static void arc_serial_puts(const char *s)
+{
+ while (*s)
+ arc_serial_putc(*s++);
+}
+
+static struct serial_device arc_serial_drv = {
+ .name = arc_serial,
+ .start = arc_serial_init,
+ .stop = NULL,
+ .setbrg = arc_serial_setbrg,
+ .putc = arc_serial_putc,
+ .puts = arc_serial_puts,
+ .getc = arc_serial_getc,
+ .tstc = arc_serial_tstc,
+};
+
+void arc_serial_initialize(void)
+{
+ serial_register(arc_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+ return arc_serial_drv;
+}
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib/time - fix usec_to_tick calculation for hi freq system timers
Hi Tom,
On Mon, 2013-12-09 at 16:57 +0400, Alexey Brodkin wrote:
Current implementation works fine if usec * get_tbclk() fits in 32
bits. Otherwise result will be cut down to 32-bit.
Fix is obvious - first extend data type of either operand.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Mischa Jonker mjon...@synopsys.com
---
lib/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/time.c b/lib/time.c
index 09bb05a..80003c3 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -71,7 +71,7 @@ unsigned long __weak notrace timer_get_us(void)
}
static unsigned long long usec_to_tick(unsigned long usec)
{
- uint64_t tick = usec * get_tbclk();
+ uint64_t tick = (uint64_t)usec * get_tbclk();
usec *= get_tbclk();
do_div(tick, 100);
return tick;
Any chance to get it applied?
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial/serial_arc - add driver for ARC UART
On Fri, 2013-12-13 at 08:07 -0500, Tom Rini wrote: Looks fine, please list this as a pre-requisite patch when posting the rest of the board, thanks! Hi Tom, is my understanding correct that this patch will be accepted as it is but later when I do submission of corresponding board I just need to indicate that this driver is a pre-requisite (so commiter makes sure this patch is already applied)? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib/time - fix usec_to_tick calculation for hi freq system timers
On Fri, 2013-12-13 at 09:09 -0500, Tom Rini wrote: Please note that I'm taking http://patchwork.ozlabs.org/patch/297361/ as the solution for this problem, thanks! As long as it resolves overflow issue (and from that patch I'd say it should) I'm totally fine with it. Thanks. P.S. funny enough this overflow issue bites multiple people these days (but earlier it seems like everybody was happy though). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/designware_i2c - add suppor of CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
Since we agreed on legacy implementation of eeprom_{read|write}
(http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work
again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with
anumber of built-in ICs with different chip addresses.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Tom Rini tr...@ti.com
cc: Armando Visconti armando.visco...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Heiko Schocher h...@denx.de
Cc: Vipin KUMAR vipin.ku...@st.com
Cc: Tom Rix tom@windriver.com
Cc: Mischa Jonker mjon...@synopsys.com
Cc: Kuo-Jung Su dant...@faraday-tech.com
---
drivers/i2c/designware_i2c.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index cb2ac04..9ed9295 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -266,6 +266,25 @@ int i2c_read(uchar chip, uint addr, int alen, uchar
*buffer, int len)
{
unsigned long start_time_rx;
+#ifdef CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
+ /*
+* EEPROM chips that implement address overflow are ones
+* like Catalyst 24WC04/08/16 which has 9/10/11 bits of
+* address and the extra bits end up in the chip address
+* bit slots. This makes a 24WC08 (1Kbyte) chip look like
+* four 256 byte chips.
+*
+* Note that we consider the length of the address field to
+* still be one byte because the extra address bits are
+* hidden in the chip address.
+*/
+ chip |= ((addr (alen * 8)) CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW);
+ addr = ~(CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW (alen * 8));
+
+ debug(%s: fix addr_overflow: chip %02x addr %02x\n, __func__, chip,
+ addr);
+#endif
+
if (check_params(addr, alen, buffer, len))
return 1;
@@ -307,6 +326,25 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
int nb = len;
unsigned long start_time_tx;
+#ifdef CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
+ /*
+* EEPROM chips that implement address overflow are ones
+* like Catalyst 24WC04/08/16 which has 9/10/11 bits of
+* address and the extra bits end up in the chip address
+* bit slots. This makes a 24WC08 (1Kbyte) chip look like
+* four 256 byte chips.
+*
+* Note that we consider the length of the address field to
+* still be one byte because the extra address bits are
+* hidden in the chip address.
+*/
+ chip |= ((addr (alen * 8)) CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW);
+ addr = ~(CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW (alen * 8));
+
+ debug(%s: fix addr_overflow: chip %02x addr %02x\n, __func__, chip,
+ addr);
+#endif
+
if (check_params(addr, alen, buffer, len))
return 1;
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc/dwmmc: Using calloc instead malloc
On Wed, 2013-12-18 at 09:08 -0600, Chin Liang See wrote: To enhance the SDMMC DesignWare driver to use calloc instead of malloc. This will avoid the incident that uninitialized members of mmc structure are later used for NULL comparison. IMHO pretty sane change. Actually I had local memset right after this malloc to make sure all members are zeroed. But with this change we have a clean structure right away. I'm wondering why calloc is not used in every driver for device specific structure allocation. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 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:
* Implement all accesses to shared structures between CPU and GMAC via
uncached reads/writes (readl/writel).
* Flush cache for data passed from CPU to GMAC
* Invalidate cache for data passed from GMAC to CPU
I tried to implement items above keeping as much code unchanged as
possible. So logic of operation is kept as it is.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Vipin Kumar vipin.ku...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Mischa Jonker mjon...@synopsys.com
---
drivers/net/designware.c | 91 ++--
1 file changed, 58 insertions(+), 33 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 22155b4..04ae02c 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -30,26 +30,30 @@ static void tx_descs_init(struct eth_device *dev)
for (idx = 0; idx CONFIG_TX_DESCR_NUM; idx++) {
desc_p = desc_table_p[idx];
- desc_p-dmamac_addr = txbuffs[idx * CONFIG_ETH_BUFSIZE];
- desc_p-dmamac_next = desc_table_p[idx + 1];
+ writel(txbuffs[idx * CONFIG_ETH_BUFSIZE],
+ desc_p-dmamac_addr);
+ writel(desc_table_p[idx + 1], desc_p-dmamac_next);
#if defined(CONFIG_DW_ALTDESCRIPTOR)
- desc_p-txrx_status = ~(DESC_TXSTS_TXINT | DESC_TXSTS_TXLAST |
- DESC_TXSTS_TXFIRST | DESC_TXSTS_TXCRCDIS | \
- DESC_TXSTS_TXCHECKINSCTRL | \
- DESC_TXSTS_TXRINGEND | DESC_TXSTS_TXPADDIS);
-
- desc_p-txrx_status |= DESC_TXSTS_TXCHAIN;
- desc_p-dmamac_cntl = 0;
- desc_p-txrx_status = ~(DESC_TXSTS_MSK | DESC_TXSTS_OWNBYDMA);
+ writel(readl(desc_p-txrx_status) ~(DESC_TXSTS_TXINT |
+ DESC_TXSTS_TXLAST | DESC_TXSTS_TXFIRST |
+ DESC_TXSTS_TXCRCDIS | DESC_TXSTS_TXCHECKINSCTRL |
+ DESC_TXSTS_TXRINGEND | DESC_TXSTS_TXPADDIS),
+ desc_p-txrx_status);
+
+ writel(readl(desc_p-txrx_status) | DESC_TXSTS_TXCHAIN,
+ desc_p-txrx_status);
+ writel(0, desc_p-dmamac_cntl);
+ writel(readl(desc_p-txrx_status) ~(DESC_TXSTS_MSK |
+ DESC_TXSTS_OWNBYDMA), desc_p-txrx_status);
#else
- desc_p-dmamac_cntl = DESC_TXCTRL_TXCHAIN;
- desc_p-txrx_status = 0;
+ writel(DESC_TXCTRL_TXCHAIN, desc_p-dmamac_cntl);
+ writel(0, desc_p-txrx_status);
#endif
}
/* Correcting the last pointer of the chain */
- desc_p-dmamac_next = desc_table_p[0];
+ writel(desc_table_p[0], desc_p-dmamac_next);
writel((ulong)desc_table_p[0], dma_p-txdesclistaddr);
}
@@ -63,20 +67,30 @@ static void rx_descs_init(struct eth_device *dev)
struct dmamacdescr *desc_p;
u32 idx;
+ /* Before passing buffers to GMAC we need to make sure zeros
+* written there right after priv structure allocation were
+* flushed into RAM.
+* Otherwise there's a chance to get some of them flushed in RAM when
+* GMAC is already pushing data to RAM via DMA. This way incoming from
+* GMAC data will be corrupted. */
+ flush_dcache_range((unsigned int)rxbuffs, (unsigned int)rxbuffs +
+ RX_TOTAL_BUFSIZE);
+
for (idx = 0; idx CONFIG_RX_DESCR_NUM; idx++) {
desc_p = desc_table_p[idx];
- desc_p-dmamac_addr = rxbuffs[idx * CONFIG_ETH_BUFSIZE];
- desc_p-dmamac_next = desc_table_p[idx + 1];
- desc_p-dmamac_cntl =
- (MAC_MAX_FRAME_SZ DESC_RXCTRL_SIZE1MASK) | \
- DESC_RXCTRL_RXCHAIN;
+ writel(rxbuffs[idx * CONFIG_ETH_BUFSIZE],
+ desc_p-dmamac_addr);
+ writel(desc_table_p[idx + 1], desc_p-dmamac_next);
+
+ writel((MAC_MAX_FRAME_SZ DESC_RXCTRL_SIZE1MASK) |
+ DESC_RXCTRL_RXCHAIN, desc_p-dmamac_cntl);
- desc_p-txrx_status = DESC_RXSTS_OWNBYDMA;
+ writel(DESC_RXSTS_OWNBYDMA, desc_p-txrx_status);
}
/* Correcting the last pointer of the chain */
- desc_p-dmamac_next = desc_table_p[0];
+ writel(desc_table_p[0], desc_p-dmamac_next);
writel((ulong)desc_table_p[0], dma_p-rxdesclistaddr);
}
@@ -198,26 +212,32 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
struct dmamacdescr *desc_p = priv-tx_mac_descrtable[desc_num];
/* Check if the descriptor is owned by CPU */
- if (desc_p-txrx_status DESC_TXSTS_OWNBYDMA) {
+ if (readl
[U-Boot] [PATCH] mmc/dwmmc: use bounce buffer for data exchange between CPU and MMC controller
Bounce buffer implementation takes care of proper data buffer alignemt
and correct flush/invalidation of data cache at once so we no longer
depend on input data variety and make sure CPU and MMC controller deal
with expected data in case of enabled data cache.
Bounce buffer requires to add its definition (CONFIG_BOUNCE_BUFFER) in
board configuration, otherwise corresponding library won't be compiled
and linker will fail to build resulting executable.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Mischa Jonker mjon...@synopsys.com
Cc: Alim Akhtar alim.akh...@samsung.com
Cc: Rajeshwari Shinde rajeshwar...@samsung.com
Cc: Jaehoon Chung jh80.ch...@samsung.com
Cc: Amar amarendra...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Cc: Andy Fleming aflem...@freescale.com
---
drivers/mmc/dw_mmc.c| 32 ++--
include/configs/arndale.h | 1 +
include/configs/exynos5250-dt.h | 1 +
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 19d9b0b..a149d97 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -6,6 +6,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include bouncebuf.h
#include common.h
#include malloc.h
#include mmc.h
@@ -41,11 +42,13 @@ static void dwmci_set_idma_desc(struct dwmci_idmac *idmac,
}
static void dwmci_prepare_data(struct dwmci_host *host,
- struct mmc_data *data, struct dwmci_idmac *cur_idmac)
+ struct mmc_data *data,
+ struct dwmci_idmac *cur_idmac,
+ void *bounce_buffer)
{
unsigned long ctrl;
unsigned int i = 0, flags, cnt, blk_cnt;
- ulong data_start, data_end, start_addr;
+ ulong data_start, data_end;
blk_cnt = data-blocks;
@@ -55,11 +58,6 @@ static void dwmci_prepare_data(struct dwmci_host *host,
data_start = (ulong)cur_idmac;
dwmci_writel(host, DWMCI_DBADDR, (unsigned int)cur_idmac);
- if (data-flags == MMC_DATA_READ)
- start_addr = (unsigned int)data-dest;
- else
- start_addr = (unsigned int)data-src;
-
do {
flags = DWMCI_IDMAC_OWN | DWMCI_IDMAC_CH ;
flags |= (i == 0) ? DWMCI_IDMAC_FS : 0;
@@ -70,7 +68,7 @@ static void dwmci_prepare_data(struct dwmci_host *host,
cnt = data-blocksize * 8;
dwmci_set_idma_desc(cur_idmac, flags, cnt,
- start_addr + (i * PAGE_SIZE));
+ (u32)bounce_buffer + (i * PAGE_SIZE));
if (blk_cnt = 8)
break;
@@ -117,6 +115,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
u32 retry = 1;
u32 mask, ctrl;
ulong start = get_timer(0);
+ struct bounce_buffer bbstate;
while (dwmci_readl(host, DWMCI_STATUS) DWMCI_BUSY) {
if (get_timer(start) timeout) {
@@ -127,8 +126,19 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_ALL);
- if (data)
- dwmci_prepare_data(host, data, cur_idmac);
+ if (data) {
+ if (data-flags == MMC_DATA_READ) {
+ bounce_buffer_start(bbstate, data-dest,
+ data-blocksize *
+ data-blocks, GEN_BB_WRITE);
+ } else {
+ bounce_buffer_start(bbstate, data-src,
+ data-blocksize *
+ data-blocks, GEN_BB_READ);
+ }
+ dwmci_prepare_data(host, data, cur_idmac,
+ bbstate.bounce_buffer);
+ }
dwmci_writel(host, DWMCI_CMDARG, cmd-cmdarg);
@@ -204,6 +214,8 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
ctrl = dwmci_readl(host, DWMCI_CTRL);
ctrl = ~(DWMCI_DMA_EN);
dwmci_writel(host, DWMCI_CTRL, ctrl);
+
+ bounce_buffer_stop(bbstate);
}
udelay(100);
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index a3cb56b..3d29caf 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -85,6 +85,7 @@
#define CONFIG_DWMMC
#define CONFIG_EXYNOS_DWMMC
#define CONFIG_SUPPORT_EMMC_BOOT
+#define CONFIG_BOUNCE_BUFFER
#define CONFIG_BOARD_EARLY_INIT_F
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 8fb904c..b39bafc 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -102,6 +102,7 @@
#define CONFIG_DWMMC
#define CONFIG_EXYNOS_DWMMC
[U-Boot] [PATCH v2] mmc/dwmmc: use bounce buffer for data exchange between CPU and MMC controller
Bounce buffer implementation takes care of proper data buffer alignemt
and correct flush/invalidation of data cache at once so we no longer
depend on input data variety and make sure CPU and MMC controller deal
with expected data in case of enabled data cache.
Bounce buffer requires to add its definition (CONFIG_BOUNCE_BUFFER) in
board configuration, otherwise corresponding library won't be compiled
and linker will fail to build resulting executable.
Difference since v1 - fixed compile-time warning with type casting to
void *:
passing argument 2 of ‘bounce_buffer_start’ discards ‘const’ qualifier
from pointer target type
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Mischa Jonker mjon...@synopsys.com
Cc: Alim Akhtar alim.akh...@samsung.com
Cc: Rajeshwari Shinde rajeshwar...@samsung.com
Cc: Jaehoon Chung jh80.ch...@samsung.com
Cc: Amar amarendra...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Cc: Andy Fleming aflem...@gmail.com
---
drivers/mmc/dw_mmc.c| 32 ++--
include/configs/arndale.h | 1 +
include/configs/exynos5250-dt.h | 1 +
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 19d9b0b..1e34f36 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -6,6 +6,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include bouncebuf.h
#include common.h
#include malloc.h
#include mmc.h
@@ -41,11 +42,13 @@ static void dwmci_set_idma_desc(struct dwmci_idmac *idmac,
}
static void dwmci_prepare_data(struct dwmci_host *host,
- struct mmc_data *data, struct dwmci_idmac *cur_idmac)
+ struct mmc_data *data,
+ struct dwmci_idmac *cur_idmac,
+ void *bounce_buffer)
{
unsigned long ctrl;
unsigned int i = 0, flags, cnt, blk_cnt;
- ulong data_start, data_end, start_addr;
+ ulong data_start, data_end;
blk_cnt = data-blocks;
@@ -55,11 +58,6 @@ static void dwmci_prepare_data(struct dwmci_host *host,
data_start = (ulong)cur_idmac;
dwmci_writel(host, DWMCI_DBADDR, (unsigned int)cur_idmac);
- if (data-flags == MMC_DATA_READ)
- start_addr = (unsigned int)data-dest;
- else
- start_addr = (unsigned int)data-src;
-
do {
flags = DWMCI_IDMAC_OWN | DWMCI_IDMAC_CH ;
flags |= (i == 0) ? DWMCI_IDMAC_FS : 0;
@@ -70,7 +68,7 @@ static void dwmci_prepare_data(struct dwmci_host *host,
cnt = data-blocksize * 8;
dwmci_set_idma_desc(cur_idmac, flags, cnt,
- start_addr + (i * PAGE_SIZE));
+ (u32)bounce_buffer + (i * PAGE_SIZE));
if (blk_cnt = 8)
break;
@@ -117,6 +115,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
u32 retry = 1;
u32 mask, ctrl;
ulong start = get_timer(0);
+ struct bounce_buffer bbstate;
while (dwmci_readl(host, DWMCI_STATUS) DWMCI_BUSY) {
if (get_timer(start) timeout) {
@@ -127,8 +126,19 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
dwmci_writel(host, DWMCI_RINTSTS, DWMCI_INTMSK_ALL);
- if (data)
- dwmci_prepare_data(host, data, cur_idmac);
+ if (data) {
+ if (data-flags == MMC_DATA_READ) {
+ bounce_buffer_start(bbstate, (void*)data-dest,
+ data-blocksize *
+ data-blocks, GEN_BB_WRITE);
+ } else {
+ bounce_buffer_start(bbstate, (void*)data-src,
+ data-blocksize *
+ data-blocks, GEN_BB_READ);
+ }
+ dwmci_prepare_data(host, data, cur_idmac,
+ bbstate.bounce_buffer);
+ }
dwmci_writel(host, DWMCI_CMDARG, cmd-cmdarg);
@@ -204,6 +214,8 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
ctrl = dwmci_readl(host, DWMCI_CTRL);
ctrl = ~(DWMCI_DMA_EN);
dwmci_writel(host, DWMCI_CTRL, ctrl);
+
+ bounce_buffer_stop(bbstate);
}
udelay(100);
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index a3cb56b..3d29caf 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -85,6 +85,7 @@
#define CONFIG_DWMMC
#define CONFIG_EXYNOS_DWMMC
#define CONFIG_SUPPORT_EMMC_BOOT
+#define CONFIG_BOUNCE_BUFFER
#define CONFIG_BOARD_EARLY_INIT_F
diff --git a/include/configs/exynos5250-dt.h b/include/configs
[U-Boot] [PATCH] net: execute miiphy_init if CONFIG_PHYLIB defined
In common/Makefile miiphyutil.o gets built if any of the following items enabled: * CONFIG_PHYLIB * CONFIG_MII * CONFIG_CMD_MII So it's possible to not define CONFIG_MII or CONFIG_CMD_MII and still use functions like miiphy_get_dev_by_name. In its turn miiphy_get_dev_by_name traverses mii_devs list which is not initialized because miiphy_init never got called. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Joe Hershberger joe.hershber...@ni.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Simon Glass s...@chromium.org Cc: Wolfgang Denk w...@denx.de --- net/eth.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/eth.c b/net/eth.c index c96e767..32bd10c 100644 --- a/net/eth.c +++ b/net/eth.c @@ -279,7 +279,7 @@ int eth_initialize(bd_t *bis) eth_current = NULL; bootstage_mark(BOOTSTAGE_ID_NET_ETH_START); -#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) +#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) || defined(CONFIG_PHYLIB) miiphy_init(); #endif -- 1.8.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] 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
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Vipin Kumar vipin.ku...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Mischa Jonker mjon...@synopsys.com
Compared to v1:
1. Dropped all extra readl/writel since it makes no sense in terms
of data access via D$.
2. Added flush/invalidation of buffer descriptors after/before its data
access.
---
drivers/net/designware.c | 53 +---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 22155b4..53a95bf 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -51,6 +51,11 @@ static void tx_descs_init(struct eth_device *dev)
/* Correcting the last pointer of the chain */
desc_p-dmamac_next = desc_table_p[0];
+ /* Flush all Tx buffer descriptors at once */
+ flush_dcache_range((unsigned int)priv-tx_mac_descrtable,
+ (unsigned int)priv-tx_mac_descrtable +
+ sizeof(priv-tx_mac_descrtable));
+
writel((ulong)desc_table_p[0], dma_p-txdesclistaddr);
}
@@ -63,6 +68,15 @@ static void rx_descs_init(struct eth_device *dev)
struct dmamacdescr *desc_p;
u32 idx;
+ /* Before passing buffers to GMAC we need to make sure zeros
+* written there right after priv structure allocation were
+* flushed into RAM.
+* Otherwise there's a chance to get some of them flushed in RAM when
+* GMAC is already pushing data to RAM via DMA. This way incoming from
+* GMAC data will be corrupted. */
+ flush_dcache_range((unsigned int)rxbuffs, (unsigned int)rxbuffs +
+ RX_TOTAL_BUFSIZE);
+
for (idx = 0; idx CONFIG_RX_DESCR_NUM; idx++) {
desc_p = desc_table_p[idx];
desc_p-dmamac_addr = rxbuffs[idx * CONFIG_ETH_BUFSIZE];
@@ -78,6 +92,11 @@ static void rx_descs_init(struct eth_device *dev)
/* Correcting the last pointer of the chain */
desc_p-dmamac_next = desc_table_p[0];
+ /* Flush all Rx buffer descriptors at once */
+ flush_dcache_range((unsigned int)priv-rx_mac_descrtable,
+ (unsigned int)priv-rx_mac_descrtable +
+ sizeof(priv-rx_mac_descrtable));
+
writel((ulong)desc_table_p[0], dma_p-rxdesclistaddr);
}
@@ -197,6 +216,11 @@ 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));
+
/* Check if the descriptor is owned by CPU */
if (desc_p-txrx_status DESC_TXSTS_OWNBYDMA) {
printf(CPU not owner of tx frame\n);
@@ -205,6 +229,10 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
memcpy((void *)desc_p-dmamac_addr, packet, length);
+ /* Flush data to be sent */
+ flush_dcache_range((unsigned long)desc_p-dmamac_addr,
+ (unsigned long)desc_p-dmamac_addr + length);
+
#if defined(CONFIG_DW_ALTDESCRIPTOR)
desc_p-txrx_status |= DESC_TXSTS_TXFIRST | DESC_TXSTS_TXLAST;
desc_p-dmamac_cntl |= (length DESC_TXCTRL_SIZE1SHFT) \
@@ -220,6 +248,10 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
desc_p-txrx_status = DESC_TXSTS_OWNBYDMA;
#endif
+ /* Flush modified buffer descriptor */
+ flush_dcache_range((unsigned long)desc_p,
+ (unsigned long)desc_p + sizeof(struct dmamacdescr));
+
/* Test the wrap-around condition. */
if (++desc_num = CONFIG_TX_DESCR_NUM)
desc_num = 0;
@@ -235,18 +267,28 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
static int dw_eth_recv(struct eth_device *dev)
{
struct dw_eth_dev *priv = dev-priv;
- u32 desc_num = priv-rx_currdescnum;
+ u32 status, desc_num = priv-rx_currdescnum;
struct dmamacdescr *desc_p = priv-rx_mac_descrtable[desc_num];
-
- u32 status = desc_p-txrx_status;
int length = 0;
+ /* Invalidate entire buffer descriptor */
+ invalidate_dcache_range((unsigned long)desc_p,
+ (unsigned long)desc_p
[U-Boot] [PATCH] net/designware: add explicit reset of {tx|rx}_currdescnum
Driver init function might be called multiple times.
On every init Tx/Rx buffer descriptors are initialized: descs_init
- {tx|rx}_descs_init.
In its turn those init functions set MAC's {tx|rx}desclistaddr to
point on the first buffer descriptor in the list.
So CPU to start operation from the first buffer descriptor as well after
every init we have to reset {tx|rx}_currdescnum.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Vipin Kumar vipin.ku...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Mischa Jonker mjon...@synopsys.com
---
drivers/net/designware.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 53a95bf..d1cc25b 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -57,6 +57,7 @@ static void tx_descs_init(struct eth_device *dev)
sizeof(priv-tx_mac_descrtable));
writel((ulong)desc_table_p[0], dma_p-txdesclistaddr);
+ priv-tx_currdescnum = 0;
}
static void rx_descs_init(struct eth_device *dev)
@@ -98,6 +99,7 @@ static void rx_descs_init(struct eth_device *dev)
sizeof(priv-rx_mac_descrtable));
writel((ulong)desc_table_p[0], dma_p-rxdesclistaddr);
+ priv-rx_currdescnum = 0;
}
static void descs_init(struct eth_device *dev)
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/designware - switch driver to phylib usage
With this change driver will benefit from existing phylib and thus
custom phy functionality implemented in the driver will go away:
* Instantiation of the driver is now much shorter - 2 parameters
instead of 4.
* Simplified phy management/functoinality in driver is replaced with
rich functionality of phylib.
* Support of custom phy initialization is now done with existing
board_phy_config.
Note that after this change some previously used config options
(driver-specific PHY configuration) will be obsolete and they are simply
substituted with similar options of phylib.
For example:
* CONFIG_DW_AUTONEG - no need in this one. Autonegotiation is enabled
by default.
* CONFIG_DW_SEARCH_PHY - if one wants to specify attached phy
explicitly CONFIG_PHY_ADDR board config option has to be used, otherwise
automatically the first discovered on MDIO bus phy will be used
I believe there's no need now in doc/README.designware_eth because
user only needs to instantiate the driver with designware_initialize
whose prototype exists in include/netdev.h.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Vipin Kumar vipin.ku...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Mischa Jonker mjon...@synopsys.com
---
board/bf609-ezkit/bf609-ezkit.c | 4 +-
board/spear/spear300/spear300.c | 3 +-
board/spear/spear310/spear310.c | 3 +-
board/spear/spear320/spear320.c | 3 +-
board/spear/spear600/spear600.c | 3 +-
board/spear/x600/x600.c | 25 +--
doc/README.designware_eth | 25 ---
drivers/net/designware.c| 462 +---
drivers/net/designware.h| 18 +-
include/configs/bf609-ezkit.h | 3 +-
include/configs/spear-common.h | 4 +-
include/configs/spear6xx_evb.h | 3 +
include/netdev.h| 2 +-
13 files changed, 179 insertions(+), 379 deletions(-)
delete mode 100644 doc/README.designware_eth
diff --git a/board/bf609-ezkit/bf609-ezkit.c b/board/bf609-ezkit/bf609-ezkit.c
index 0388226..19853fc 100644
--- a/board/bf609-ezkit/bf609-ezkit.c
+++ b/board/bf609-ezkit/bf609-ezkit.c
@@ -40,12 +40,12 @@ int board_eth_init(bd_t *bis)
if (CONFIG_DW_PORTS 1) {
static const unsigned short pins[] = P_RMII0;
if (!peripheral_request_list(pins, emac0))
- ret += designware_initialize(0, EMAC0_MACCFG, 1, 0);
+ ret += designware_initialize(EMAC0_MACCFG, 0);
}
if (CONFIG_DW_PORTS 2) {
static const unsigned short pins[] = P_RMII1;
if (!peripheral_request_list(pins, emac1))
- ret += designware_initialize(1, EMAC1_MACCFG, 1, 0);
+ ret += designware_initialize(EMAC1_MACCFG, 0);
}
return ret;
diff --git a/board/spear/spear300/spear300.c b/board/spear/spear300/spear300.c
index e25aba2..6b6bd9f 100644
--- a/board/spear/spear300/spear300.c
+++ b/board/spear/spear300/spear300.c
@@ -53,8 +53,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DESIGNWARE_ETH)
u32 interface = PHY_INTERFACE_MODE_MII;
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) = 0)
+ if (designware_initialize(CONFIG_SPEAR_ETHBASE, interface) = 0)
ret++;
#endif
return ret;
diff --git a/board/spear/spear310/spear310.c b/board/spear/spear310/spear310.c
index 70f9aa1..a4c6a8e 100644
--- a/board/spear/spear310/spear310.c
+++ b/board/spear/spear310/spear310.c
@@ -54,8 +54,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DESIGNWARE_ETH)
u32 interface = PHY_INTERFACE_MODE_MII;
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) = 0)
+ if (designware_initialize(CONFIG_SPEAR_ETHBASE, interface) = 0)
ret++;
#endif
#if defined(CONFIG_MACB)
diff --git a/board/spear/spear320/spear320.c b/board/spear/spear320/spear320.c
index f6b1fdd..ab732a7 100644
--- a/board/spear/spear320/spear320.c
+++ b/board/spear/spear320/spear320.c
@@ -65,8 +65,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DESIGNWARE_ETH)
u32 interface = PHY_INTERFACE_MODE_MII;
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) = 0)
+ if (designware_initialize(CONFIG_SPEAR_ETHBASE, interface) = 0)
ret++;
#endif
#if defined(CONFIG_MACB)
diff --git a/board/spear/spear600/spear600.c b/board/spear/spear600/spear600.c
index e996a0e..8472002 100644
--- a/board/spear/spear600/spear600.c
+++ b/board/spear/spear600/spear600.c
@@ -51,8 +51,7 @@ int board_eth_init(bd_t *bis)
#if defined(CONFIG_DW_AUTONEG)
interface = PHY_INTERFACE_MODE_GMII;
#endif
- if (designware_initialize(0, CONFIG_SPEAR_ETHBASE, CONFIG_DW0_PHY,
- interface) = 0
Re: [U-Boot] [PATCH] net/designware - switch driver to phylib usage
Completely forgot to mention that there's a prerequisite (http://patchwork.ozlabs.org/patch/309319/): == [PATCH] net: execute miiphy_init if CONFIG_PHYLIB defined == This makes sure that phylib will be correctly initialized even if there's no explicit mention of either entry in board configuration: * CONFIG_MII * CONFIG_CMD_MII Even though all existing boards do have CONFIG_MII set still it's good to have all missing parts in place. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board_r - fixup functions table after relocation
init_sequence_r is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to void to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.
As a consequence on execution after relocation initcall_run_list will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Tom Rini tr...@ti.com
Cc: Simon Glass s...@chromium.org
Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Doug Anderson diand...@chromium.org
---
common/board_r.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..8f45943 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -903,9 +903,14 @@ init_fnc_t init_sequence_r[] = {
void board_init_r(gd_t *new_gd, ulong dest_addr)
{
+ int i;
#ifndef CONFIG_X86
gd = new_gd;
#endif
+ /* Fixup table after relocation */
+ for (i = 0; i sizeof(init_sequence_r)/sizeof(void *); i++)
+ init_sequence_r[i] += gd-reloc_off;
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation
On Wed, 2014-01-15 at 11:27 +, thomas.lan...@lantiq.com wrote: I think this is only required/possible for architectures which define CONFIG_NEEDS_MANUAL_RELOC, others don't have gd-reloc_off if (initcall_run_list(init_sequence_r)) hang(); Hi Thomas, I think it's a generic item for all boards that use common/board_r.c and common/board_f.c. I.e. have CONFIG_BOARD_EARLY_INIT_F and CONFIG_BOARD_EARLY_INIT_R defined. I see that in common/board_f.c it is used for example in setup_reloc() and this function is executed regardless platform. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] designware_i2c: Enhance DesignWare I2C driver address support
On Wed, 2014-01-15 at 08:58 -0600, Chin Liang See wrote:
Enhance the DesignWare I2C driver to support address length more
than 1 byte. This enhancement is required as some I2C slave
device such as EEPROM chip might have 16 bit address byte.
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index cb2ac04..c0ac5f7 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -205,27 +205,21 @@ static int check_params(uint addr, int alen, uchar
*buffer, int len)
return 1;
}
- if (alen 1) {
- printf(addr len %d not supported\n, alen);
- return 1;
- }
-
- if (addr + len 256) {
- printf(address out of range\n);
- return 1;
- }
-
return 0;
}
Hi Chin,
if you strip down functionality of check_params() to one single check
I would recommend you to remove check_params() at all and do in-place
check for buffer existence.
Moreover you may just use assert for this check because this buffer is
passed by u-boot (no need to check every parameter passed to any
function in run-time) so in production/release build it won't exist at
all.
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/designware_i2c - add suppor of CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
On Mon, 2013-12-16 at 15:30 +0400, Alexey Brodkin wrote:
Since we agreed on legacy implementation of eeprom_{read|write}
(http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work
again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with
anumber of built-in ICs with different chip addresses.
Hi Heiko,
any chance to get this one applied?
Note this is not an enhancement - this is a required fix due to
roll-back (http://patchwork.ozlabs.org/patch/295825/) of my previous fix
in http://patchwork.ozlabs.org/patch/289346/
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] designware_i2c: Enhance DesignWare I2C driver address support
On Wed, 2014-01-15 at 09:45 -0600, Chin Liang See wrote: Changes for v2 - Removed the function check_params() Ok, so you decided to not add assert check instead. I think it's ok - it's not a requirement. Others don't do it as well so let's leave it as it is. Acked-by: Alexey Brodkin abrod...@synopsys.com Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation
On Wed, 2014-01-15 at 22:43 +0100, Albert ARIBAUD wrote: Hi Alexey, On Wed, 15 Jan 2014 15:19:56 +0400, Alexey Brodkin alexey.brod...@synopsys.com wrote: init_sequence_r is just an array that consists of compile-time adresses of init functions. Since this is basically an array of integers (pointers to void to be more precise) it won't be modified during relocation - it will be just copied to new location as it is. IIRC, in ARM we switched from GOT to ELF relocation precisely so that data would be relocated as well as code, and I think it actually is, otherwise we'd have a lot of complains. Therefore I fail to understand the statements above. Can someone tell me what I'm getting wrong? Unfortunately I don't have any supported in U-Boot ARM board handy and run U-boot on another architecture at all (Synopsys DesignWare ARC) so I'm not sure if on ARM functions from init_sequence_r list are executed from RAM (i.e. from location where they were relocated). I use GOT relocation and see following outputs. 1. Without manual init_sequence_r modification: U-Boot 2014.01-rc1-00207-ga065b75-dirty (Jan 16 2014 - 21:30:12) initcall: 81000890 U-Boot code: 8100 - 8103FE00 BSS: - 81044278 initcall: 810008f4 DRAM: initcall: 81000a84 Monitor len: 00044278 Ram size: 1000 Ram top: 9000 initcall: 81000b24 initcall: 81000b48 initcall: 81000b5c Reserving 272k for U-Boot at: 8ffbb000 initcall: 81000bd0 Reserving 2048k for malloc() at: 8fdbae00 initcall: 81000c24 Reserving 64 Bytes for Board Info at: 8fdbadc0 initcall: 81000c9c initcall: 81000cb0 Reserving 132 Bytes for Global Data at: 8fdbad3c initcall: 81000d18 initcall: 81000de8 initcall: 81000e78 initcall: 8100092c 256 MiB initcall: 81000e5c initcall: 81000e1c New Stack Pointer is: 8fdbad20 initcall: 81000e94 initcall: 81000ed4 Relocation Offset is: 0efbb000 Relocating to 8ffbb000, new gd at 8fdbad3c, sp at 8fdbad20 initcall: 81000f60 initcall: 81001074 initcall: 81001088 initcall: 810010f4 initcall: 81001120 initcall: 810011b0 Now running in RAM - U-Boot at: 8ffbb000 initcall: 81000760 2. With manual init_sequence_r modification U-Boot 2014.01-rc1-00207-ga065b75-dirty (Jan 16 2014 - 21:26:42) initcall: 81000890 U-Boot code: 8100 - 8103FE00 BSS: - 81044278 initcall: 810008f4 DRAM: initcall: 81000a84 Monitor len: 00044278 Ram size: 1000 Ram top: 9000 initcall: 81000b24 initcall: 81000b48 initcall: 81000b5c Reserving 272k for U-Boot at: 8ffbb000 initcall: 81000bd0 Reserving 2048k for malloc() at: 8fdbae00 initcall: 81000c24 Reserving 64 Bytes for Board Info at: 8fdbadc0 initcall: 81000c9c initcall: 81000cb0 Reserving 132 Bytes for Global Data at: 8fdbad3c initcall: 81000d18 initcall: 81000de8 initcall: 81000e78 initcall: 8100092c 256 MiB initcall: 81000e5c initcall: 81000e1c New Stack Pointer is: 8fdbad20 initcall: 81000e94 initcall: 81000ed4 Relocation Offset is: 0efbb000 Relocating to 8ffbb000, new gd at 8fdbad3c, sp at 8fdbad20 initcall: 81000f60 initcall: 8ffbc074 initcall: 8ffbc088 initcall: 8ffbc0f4 initcall: 8ffbc120 initcall: 8ffbc1b0 Now running in RAM - U-Boot at: 8ffbb000 initcall: 8ffbb760 Note how in second case mapped initcalls executed. If anybody may try to build U-Boot with global DEBUG defined and paste his log in this thread it would be helpful. Maybe it's just my faulty implementation of relocation but it might be that nobody ever noticed this because I think only initcalls are affected. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation
On Wed, 2014-01-15 at 09:56 -0700, Simon Glass wrote: I have not checked to make sure that the array contents remains un-relocated. Did you see this? Hi Simon, yes, I do see it. Please refer to my outputs below: 1. Without manual init_sequence_r modification: U-Boot 2014.01-rc1-00207-ga065b75-dirty (Jan 16 2014 - 21:30:12) initcall: 81000890 U-Boot code: 8100 - 8103FE00 BSS: - 81044278 initcall: 810008f4 DRAM: initcall: 81000a84 Monitor len: 00044278 Ram size: 1000 Ram top: 9000 initcall: 81000b24 initcall: 81000b48 initcall: 81000b5c Reserving 272k for U-Boot at: 8ffbb000 initcall: 81000bd0 Reserving 2048k for malloc() at: 8fdbae00 initcall: 81000c24 Reserving 64 Bytes for Board Info at: 8fdbadc0 initcall: 81000c9c initcall: 81000cb0 Reserving 132 Bytes for Global Data at: 8fdbad3c initcall: 81000d18 initcall: 81000de8 initcall: 81000e78 initcall: 8100092c 256 MiB initcall: 81000e5c initcall: 81000e1c New Stack Pointer is: 8fdbad20 initcall: 81000e94 initcall: 81000ed4 Relocation Offset is: 0efbb000 Relocating to 8ffbb000, new gd at 8fdbad3c, sp at 8fdbad20 initcall: 81000f60 initcall: 81001074 initcall: 81001088 initcall: 810010f4 initcall: 81001120 initcall: 810011b0 Now running in RAM - U-Boot at: 8ffbb000 initcall: 81000760 2. With manual init_sequence_r modification U-Boot 2014.01-rc1-00207-ga065b75-dirty (Jan 16 2014 - 21:26:42) initcall: 81000890 U-Boot code: 8100 - 8103FE00 BSS: - 81044278 initcall: 810008f4 DRAM: initcall: 81000a84 Monitor len: 00044278 Ram size: 1000 Ram top: 9000 initcall: 81000b24 initcall: 81000b48 initcall: 81000b5c Reserving 272k for U-Boot at: 8ffbb000 initcall: 81000bd0 Reserving 2048k for malloc() at: 8fdbae00 initcall: 81000c24 Reserving 64 Bytes for Board Info at: 8fdbadc0 initcall: 81000c9c initcall: 81000cb0 Reserving 132 Bytes for Global Data at: 8fdbad3c initcall: 81000d18 initcall: 81000de8 initcall: 81000e78 initcall: 8100092c 256 MiB initcall: 81000e5c initcall: 81000e1c New Stack Pointer is: 8fdbad20 initcall: 81000e94 initcall: 81000ed4 Relocation Offset is: 0efbb000 Relocating to 8ffbb000, new gd at 8fdbad3c, sp at 8fdbad20 initcall: 81000f60 initcall: 8ffbc074 initcall: 8ffbc088 initcall: 8ffbc0f4 initcall: 8ffbc120 initcall: 8ffbc1b0 Now running in RAM - U-Boot at: 8ffbb000 initcall: 8ffbb760 Note how in second case mapped initcalls executed. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation
On Thu, 2014-01-16 at 21:27 +0100, Albert ARIBAUD wrote: GOT relocation does not relocate references within data, contrary to ELF. Maybe it's just my faulty implementation of relocation but it might be that nobody ever noticed this because I think only initcalls are affected. Well, initcalls are quite essential, I guess. Agree, but IMHO it may not hurt if they are executed from initial location until this initial memory was overwritten which I don't expect to happen till the end of init sequence. So the only way to learn that init calls were executed from wrong location was examination of boot log in DEBUG mode. When you say my faulty implementation of relocation... do you mean some implementation different from what is currently in mainline? Well as I'm preparing for submission port for new (for mainline U-Boot) architecture and relocation code as I see is implemented in arch-specific assembly code so my implementation of relocation code is indeed differs from currently available ones in U-Boot. But I copied my implementation from PIC-based relocation of NDS32 so in general I now think it has to work (as good as PIC-relocation culd work in current U-Boot). -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation
On Fri, 2014-01-17 at 00:40 +0400, Alexey Brodkin wrote: On Thu, 2014-01-16 at 21:27 +0100, Albert ARIBAUD wrote: Well, I've just realized that very similar thing is done in fixup_cmdtable. So I believe with addition of CONFIG_NEEDS_MANUAL_RELOC wrapper my change may make some sense. Any comments/thoughts? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/designware_i2c - add suppor of CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
On Fri, 2014-01-17 at 07:42 +0100, Heiko Schocher wrote: Hello Alexey, I picked it up, see: http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=summary http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=32d041e218c6a22e92d91629902fd03a90934b6a Note this is not an enhancement - this is a required fix due to roll-back (http://patchwork.ozlabs.org/patch/295825/) of my previous fix in http://patchwork.ozlabs.org/patch/289346/ Waiting for a testreport for another patch ... If I get no response, I send a pull request for this patch tomorrow ... Oops, sorry I didn't look at your tree before reminding. Thanks so much for your time. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/designware - switch driver to phylib usage
On Mon, 2014-01-13 at 15:11 +0400, Alexey Brodkin wrote: With this change driver will benefit from existing phylib and thus custom phy functionality implemented in the driver will go away: * Instantiation of the driver is now much shorter - 2 parameters instead of 4. * Simplified phy management/functoinality in driver is replaced with rich functionality of phylib. * Support of custom phy initialization is now done with existing board_phy_config. I'm wondering if any owner of bf609-ezkit or spear board(s) may try this change and provide some feedback? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Pull request
On Mon, 2014-01-20 at 10:24 +0100, Michal Simek wrote: Hi Tom, look below. On 01/18/2014 08:28 AM, Heiko Schocher wrote: Hello Tom, please pull some small fixes from u-boot-i2c.git Thanks! The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 -0500) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master for you to fetch changes up to 8e0b3c020057b3f7345b6696029a80eaf162e7f3: i2c: zynq: Add support for the second i2c controller (2014-01-13 09:06:08 +0100) Alexey Brodkin (2): env_eeprom - fix bus recovery for eeprom_bus_read drivers/designware_i2c - add suppor of CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW Darwin Rambo (1): i2c: Fix i2c speed command Hisashi Nakamura (1): rcar_i2c: Fix receiving wait condition Kuo-Jung Su (1): i2c: fti2c010: fix compiler warning on paddr[] Michael Burr (2): i2c: zynq: Support for 0-length register address I have found that I cherry-picked this patch incorrectly from origin one and it is breaking current functionality. I have already sent email to Heiko that this is patch is wrong. I don't know if Heiko wants to send new pull request or you can just remove that 2 patches on the top of Heiko's tree. Hi Michal, could you please clarify which particular patches from mentioned pull-request break current functionality? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] board_r - fixup functions table after relocation
This is only required for PIC relocation and doesn't apply to modern
PIE relocation which does data relocation as well as code.
init_sequence_r is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to void to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.
As a consequence on execution after relocation initcall_run_list will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Tom Rini tr...@ti.com
Cc: Simon Glass s...@chromium.org
Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Doug Anderson diand...@chromium.org
Cc: Thomas Langer thomas.lan...@lantiq.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Changes to v1:
* Added CONFIG_NEEDS_MANUAL_RELOC wrapper so this change only applies
to PIC relocation.
---
common/board_r.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..3462590 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -903,9 +903,16 @@ init_fnc_t init_sequence_r[] = {
void board_init_r(gd_t *new_gd, ulong dest_addr)
{
+ int i;
#ifndef CONFIG_X86
gd = new_gd;
#endif
+
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ for (i = 0; i sizeof(init_sequence_r)/sizeof(void *); i++)
+ init_sequence_r[i] += gd-reloc_off;
+#endif
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] board_r - fixup functions table after relocation
This is only required for PIC relocation and doesn't apply to modern
PIE relocation which does data relocation as well as code.
init_sequence_r is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to void to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.
As a consequence on execution after relocation initcall_run_list will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Tom Rini tr...@ti.com
Cc: Simon Glass s...@chromium.org
Cc: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Doug Anderson diand...@chromium.org
Cc: Thomas Langer thomas.lan...@lantiq.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Changes to v2:
* Use ARRAY_SIZE as suggested by Simon Glass
* Added CONFIG_NEEDS_MANUAL_RELOC wrapper for temporary index variable
i to fix compile-time warning for boards without
CONFIG_NEEDS_MANUAL_RELOC
---
common/board_r.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..c2d0763 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -903,9 +903,19 @@ init_fnc_t init_sequence_r[] = {
void board_init_r(gd_t *new_gd, ulong dest_addr)
{
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ int i;
+#endif
+
#ifndef CONFIG_X86
gd = new_gd;
#endif
+
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ for (i = 0; i ARRAY_SIZE(init_sequence_r); i++)
+ init_sequence_r[i] += gd-reloc_off;
+#endif
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] board_r - fixup functions table after relocation
Hi Simon, On Tue, 2014-01-21 at 09:13 -0700, Simon Glass wrote: Hi, It's unfortunate that we need to carry over CONFIG_NEEDS_MANUAL_RELOC to the new common board init code. But if we do, this patch looks reasonable, so: I think as long as PIC relocation is supported in U-Boot (for some architectures) it's good to accept fixes for it. And I have to confess that this kind of fixes are missing in many other places. That's why I switched to PIE as well so this particular patch doesn't change anything for me now. But for those who still use PIC it might be helpful - that's why I did another re-spin. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/designware - switch driver to phylib usage
Hi Sonic, On Wed, 2014-01-22 at 17:10 +0800, Sonic Zhang wrote: Hi Alexey, I failed to apply your patch on the 2014.01 release head. Indeed this one requires 2 other patches which didn't made it to mainline yet. Do you mind to try to apply both patches (http://patchwork.ozlabs.org/patch/309762/ and http://patchwork.ozlabs.org/patch/309764/) before this one? Even though I do see now that there're whitespace errors in 2 of 3 patches I'd like to test functionality of the patch on hardware that differs from mine. Your confirmation/update would be very helpful. In the meantime I'll update patches so they don't have whitespace errors any more. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Marek, On Fri, 2014-09-19 at 06:27 +0200, Marek Vasut wrote: On Thursday, September 18, 2014 at 10:52:12 AM, Alexey Brodkin wrote: If that's an introduction to porting U-Boot, it might bring to light some new ideas about the porting process and also point out some obstacles we were not aware of. I think it's a good idea to have such a war story ;-) Agree, so I'll re-focus my speech to more technical questions like challenges I met, things to improve etc. Do you guys want to get my presentation beforehand or I may just bring it with me? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Mini Summit
Hi Detlev, On Tue, 2014-10-07 at 11:38 +0200, Detlev Zundel wrote: Hello Masahiro-san, [...] Perhaps, is it better to insert 5-minute break between talks? Speakers might need to get something prepared. (connecting their laptop to the beamer, etc.) Of course. I did not explicitely include this in the agenda, but such a 5 minute break is what I'll strive to maintain. I would even propose to have a backup setup for slides presentation. I remember I once tried to use a beamer attached to my Fedora-driven laptop and didn't succeed with that. Moreover new gen laptops may only have like mini-DisplayPort output instead of VGA so there's a probability some laptops won't have a chance to be connected to existing (not that advanced/modern) beamer. So given you guys have all presentations beforehand (I believe in for of PDFs) would be good to have an ability to display them if my laptop refuses to work with beamer again. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image-fdt: boot_get_fdt() return value when no DTB exists
Hi Tom, On Wed, 2014-10-22 at 12:48 -0400, Tom Rini wrote: On Wed, Oct 22, 2014 at 05:17:49PM +0300, Noam Camus wrote: From: Noam Camus no...@ezchip.com I believe that when no DTB is around we should return 1. This why I fixed such scenarious to not return zero anymore. Else kernel might get NULL pointer to DTB which doesn't exists. Signed-off-by: Noam Camus no...@ezchip.com While this is probably OK and not an issue, my only what if is, what about for appened device trees? Which device tree do you mean? The one built in uImage or in FIT image? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: designware: Convert driver to multibus/multiadapter framework
Hi Stefan, On Thu, 2014-10-23 at 13:06 +0200, Stefan Roese wrote: In preparation for the SoCFPGA support of the designware I2C driver, convert this driver to the common CONFIG_SYS_I2C framework. This patch converts all users of this driver, this is: - ST spearxxx boards - AXS101 (ARC700 platform) I couldn't test this patch on those boards. Only compile tested for all spear boards. And tested on SoCFPGA. Signed-off-by: Stefan Roese s...@denx.de Cc: Heiko Schocher h...@denx.de Cc: Marek Vasut ma...@denx.de Cc: Vipin Kumar vipin.ku...@st.com Cc: Alexey Brodkin abrod...@synopsys.com --- arch/arm/cpu/arm926ejs/spear/cpu.c | 2 +- drivers/i2c/Makefile | 2 +- drivers/i2c/designware_i2c.c | 294 - include/configs/axs101.h | 9 +- include/configs/spear-common.h | 4 +- include/configs/x600.h | 4 +- 6 files changed, 142 insertions(+), 173 deletions(-) -static struct i2c_regs *i2c_regs_p = -(struct i2c_regs *)CONFIG_SYS_I2C_BASE; + default: + printf(wrong hwadapnr: %d\n, adap-hwadapnr); + } Well, I'd say wrong hwadapnr is not very informative. Maybe something more human-friendly? Anyway this is just a nitpicking. I tried updated driver on AXS101 and it builds and works for me fine. So please add: Acked-by: Alexey Brodkin abrod...@synopsys.com Tested-by: Alexey Brodkin abrod...@synopsys.com -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] axs101: Fix type mismatch warning
Hi Vasili,
On Tue, 2014-08-26 at 13:46 +0300, Vasili Galka wrote:
Initialization of pointer from integer shall be designated by explicit
type cast.
Signed-off-by: Vasili Galka vvv...@gmail.com
Cc: Alexey Brodkin alexey.brod...@synopsys.com
---
board/synopsys/axs101/nand.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/synopsys/axs101/nand.c b/board/synopsys/axs101/nand.c
index c7f90c4..ed2bb6d 100644
--- a/board/synopsys/axs101/nand.c
+++ b/board/synopsys/axs101/nand.c
@@ -62,8 +62,8 @@ struct nand_bd {
uint32_t buffer_ptr1; /* DES3 */
};
-#define NAND_REG_WRITE(r, v) writel(v, CONFIG_SYS_NAND_BASE + r)
-#define NAND_REG_READ(r) readl(CONFIG_SYS_NAND_BASE + r)
+#define NAND_REG_WRITE(r, v) writel(v, (volatile void __iomem
*)(CONFIG_SYS_NAND_BASE + r))
+#define NAND_REG_READ(r) readl((const volatile void __iomem
*)(CONFIG_SYS_NAND_BASE + r))
static struct nand_bd *bd; /* DMA buffer descriptors */
Thanks a lot for your patch.
It does fix warnings in board/synopsys/axs101/nand.c
But could you please make sure lines are properly wrapped?
This is what checkpatch.pl reports:
--
$ scripts/checkpatch.pl \[PATCH\]_axs101
\:_Fix_type_mismatch_warning.mbox
WARNING: line over 80 characters
#83: FILE: board/synopsys/axs101/nand.c:65:
+#define NAND_REG_WRITE(r, v) writel(v, (volatile void __iomem
*)(CONFIG_SYS_NAND_BASE + r))
WARNING: Use of volatile is usually wrong: see
Documentation/volatile-considered-harmful.txt
#83: FILE: board/synopsys/axs101/nand.c:65:
+#define NAND_REG_WRITE(r, v) writel(v, (volatile void __iomem
*)(CONFIG_SYS_NAND_BASE + r))
WARNING: line over 80 characters
#84: FILE: board/synopsys/axs101/nand.c:66:
+#define NAND_REG_READ(r) readl((const volatile void __iomem
*)(CONFIG_SYS_NAND_BASE + r))
WARNING: Use of volatile is usually wrong: see
Documentation/volatile-considered-harmful.txt
#84: FILE: board/synopsys/axs101/nand.c:66:
+#define NAND_REG_READ(r) readl((const volatile void __iomem
*)(CONFIG_SYS_NAND_BASE + r))
total: 0 errors, 4 warnings, 0 checks, 10 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE
USLEEP_RANGE
[PATCH]_axs101:_Fix_type_mismatch_warning.mbox has style problems,
please review.
--
I mean messages saying WARNING: line over 80 characters.
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common: fix compiler warning on wrong printf format
bounce_buffer-len_aligned is of type size_t, but on some arches/compilers
size_t might be an alias to whether int, long or their signed/unsigned
flavors.
So to make compiler happy we explicitly cast to int which is expected in
printf for %d format.
this fixes following warning:
--
common/bouncebuf.c: In function ‘addr_aligned’:
common/bouncebuf.c:26:3: warning: format ‘%d’ expects argument of type ‘int’,
but argument 2 has type ‘size_t’ [-Wformat=]
debug(Unaligned buffer length %d\n, /*(int)*/state-len);
^
--
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Vasili Galka vvv...@gmail.com
Cc: Tom Rini tr...@ti.com
---
common/bouncebuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/bouncebuf.c b/common/bouncebuf.c
index 9eece6d..0828d4b 100644
--- a/common/bouncebuf.c
+++ b/common/bouncebuf.c
@@ -23,7 +23,7 @@ static int addr_aligned(struct bounce_buffer *state)
/* Check if length is aligned */
if (state-len != state-len_aligned) {
- debug(Unaligned buffer length %d\n, state-len);
+ debug(Unaligned buffer length %d\n, (int)state-len);
return 0;
}
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-arc/master
Hi Tom, The following changes since commit 7bee1c91a94db19bd26f92cc67be35d3592c6429: Merge branch 'ag...@denx.de' of git://git.denx.de/u-boot-staging (2014-08-25 08:34:39 -0400) are available in the git repository at: git://git.denx.de/u-boot-arc.git master for you to fetch changes up to 2fea4f5addb40d7551ed754175acbec7f2750005: axs101: Fix type mismatch warning (2014-08-26 18:54:02 +0400) Vasili Galka (2): arc: Fix printf size_t format related warnings (again...) axs101: Fix type mismatch warning arch/arc/include/asm/posix_types.h | 4 board/synopsys/axs101/nand.c | 6 -- 2 files changed, 8 insertions(+), 2 deletions(-) Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] axs101: Fix type mismatch warning
Hi Vasili,
On Tue, 2014-08-26 at 17:50 +0300, Vasili Galka wrote:
Initialization of pointer from integer shall be designated by explicit
type cast.
Signed-off-by: Vasili Galka vvv...@gmail.com
Cc: Alexey Brodkin alexey.brod...@synopsys.com
---
Changes for v2:
- Verified complience with checkpatch.pl (wrapped long lines)
board/synopsys/axs101/nand.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/board/synopsys/axs101/nand.c b/board/synopsys/axs101/nand.c
index c7f90c4..ff35286 100644
--- a/board/synopsys/axs101/nand.c
+++ b/board/synopsys/axs101/nand.c
@@ -62,8 +62,10 @@ struct nand_bd {
uint32_t buffer_ptr1; /* DES3 */
};
-#define NAND_REG_WRITE(r, v) writel(v, CONFIG_SYS_NAND_BASE + r)
-#define NAND_REG_READ(r) readl(CONFIG_SYS_NAND_BASE + r)
+#define NAND_REG_WRITE(r, v) \
+ writel(v, (volatile void __iomem *)(CONFIG_SYS_NAND_BASE + r))
+#define NAND_REG_READ(r) \
+ readl((const volatile void __iomem *)(CONFIG_SYS_NAND_BASE + r))
static struct nand_bd *bd; /* DMA buffer descriptors */
Applied,
Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arc: Fix printf size_t format related warnings (again...)
Hi Vasili, On Tue, 2014-08-26 at 13:44 +0300, Vasili Galka wrote: The basic idea: Define size_t using the __SIZE_TYPE__ compiler-defined type. For detailed explanation see similar patch for the nios2 arch: http://patchwork.ozlabs.org/patch/379938/ Signed-off-by: Vasili Galka vvv...@gmail.com Cc: Alexey Brodkin alexey.brod...@synopsys.com --- arch/arc/include/asm/posix_types.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arc/include/asm/posix_types.h b/arch/arc/include/asm/posix_types.h index 20415f0..51347a4 100644 --- a/arch/arc/include/asm/posix_types.h +++ b/arch/arc/include/asm/posix_types.h @@ -16,7 +16,11 @@ typedef int__kernel_pid_t; typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; +#ifdef __GNUC__ +typedef __SIZE_TYPE____kernel_size_t; +#else typedef unsigned int __kernel_size_t; +#endif typedef int __kernel_ssize_t; typedef int __kernel_ptrdiff_t; typedef long __kernel_time_t; Applied, Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] common: fix compiler warning on wrong printf format
From: Alexey Brodkin alexey.brod...@synopsys.com
bounce_buffer-len_aligned is of type size_t so use %zd.
this fixes following warning:
--
common/bouncebuf.c: In function addr_aligned:
common/bouncebuf.c:26:3: warning: format %d expects argument of type int,
but argument 2 has type size_t [-Wformat=]
debug(Unaligned buffer length %d\n, /*(int)*/state-len);
^
--
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Vasili Galka vvv...@gmail.com
Cc: Tom Rini tr...@ti.com
cc: Chris Packham judge.pack...@gmail.com
---
Compared to v1 proper format (%zd) is used in string instead of type casting.
---
common/bouncebuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/bouncebuf.c b/common/bouncebuf.c
index 9eece6d..8dde8fd 100644
--- a/common/bouncebuf.c
+++ b/common/bouncebuf.c
@@ -23,7 +23,7 @@ static int addr_aligned(struct bounce_buffer *state)
/* Check if length is aligned */
if (state-len != state-len_aligned) {
- debug(Unaligned buffer length %d\n, state-len);
+ debug(Unaligned buffer length %zd\n, state-len);
return 0;
}
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] common: fix compiler warning on wrong printf format
Hi Vasili, On Thu, 2014-08-28 at 17:17 +0300, Vasili Galka wrote: On Thu, Aug 28, 2014 at 4:15 PM, Alexey Brodkin alexey.brod...@synopsys.com wrote: From: Alexey Brodkin alexey.brod...@synopsys.com bounce_buffer-len_aligned is of type size_t so use %zd. this fixes following warning: -- common/bouncebuf.c: In function addr_aligned: common/bouncebuf.c:26:3: warning: format %d expects argument of type int, but argument 2 has type size_t [-Wformat=] debug(Unaligned buffer length %d\n, /*(int)*/state-len); ^ -- Hmm, why not just use my original patch which included exactly this? http://patchwork.ozlabs.org/patch/383041/ Well, I'm not following all the messages sent to this mailing list so didn't know about your patch. So as soon as I observed a problem I created a patch and sent it. I see your patch fixes more things so definitely it should be applied instead. Sorry for noise. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Call for participation in the U-Boot Mini Summit 2014
Hi Detlev, On Wed, 2014-09-03 at 18:56 +0200, Przemyslaw Marczak wrote: Hello Detlev, On 08/11/2014 05:48 PM, Przemyslaw Marczak wrote: Hello Detlev, On 01/13/2014 06:12 PM, Detlev Zundel wrote: Hi, as already indicated, we are looking forward to our next U-Boot Mini Summit at Embedded Linux Conference Europe 2014 which will take place in Düsseldorf, Germany from October 13 - 15. The call for papers of the main conference is now open[1] and if you want to submit a talk for the main tracks, you should note the deadline of July 11. For our U-Boot Mini Summit, I'd like to get the schedule completed synchronized to the schedule release of the main event, which is August 12. So please submit talk proposals here with at least me on CC. To coordinate the event better, I have setup another wiki page[2] that can and _should_ be edited by the interested parties. Feel free for example to add yourself to the interested participants so that we get an idea of how many of the U-Boot developers will be there. Best wishes Detlev Sorry for my late input on this regard. But if there's still a possibility to have another talk I'd like to propose mine ARC - new first-class citizen in U-Boot (which was declined for main ELCE2014 event). Abstract is in-lined below. === U-Boot is a de-facto standard bootloader for Linux-driven embedded systems. It provides flexible means for loading kernel and if required image of filesystem from different media be it embedded non-volatile memory, attached storage or even network share. Linux kernel was ported to DesignWare ARC a while ago and starting from version 3.9 the port was accepted upstream. Now to enable real-life device booting on custom hardware decision was made to port U-Boot for ARC. This presentation unveils reasons to start the project, highlights milestones passed during porting process, touches some pitfalls and encourages more engineers and companies to use and contribute to U-Boot project. === I'm not sure if this kind of speech is of any interest for existing U-boot developers, but I may indeed emphasize technical aspects now. Any feedback is more than welcome. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] designware_i2c: remove 10msec delay in i2c_xfer_finish
This delay applies to any data transfer on I2C bus. For example 1kB data read with per-byte access (which happens if environment is stored in I2C EEPROM) takes more than 10 seconds. Moreover data bus driver has to care about bus state and data transfer, but not about internal states of attached devices. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com cc: Armando Visconti armando.visco...@st.com Cc: Stefan Roese s...@denx.de Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Heiko Schocher h...@denx.de Cc: Vipin KUMAR vipin.ku...@st.com Cc: Tom Rix tom@windriver.com Cc: Mischa Jonker mjon...@synopsys.com --- drivers/i2c/designware_i2c.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c index c5c6015..cb2ac04 100644 --- a/drivers/i2c/designware_i2c.c +++ b/drivers/i2c/designware_i2c.c @@ -249,9 +249,6 @@ static int i2c_xfer_finish(void) i2c_flush_rxfifo(); - /* Wait for read/write operation to complete on actual memory */ - udelay(1); - return 0; } -- 1.8.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_eeprom: fix i2c_{read|write} usage if env is in I2C EEPROM
Data offset is not used directly in case of I2C EEPROM. Istead it is split into block number and offset within mentioned block. Which are addr[0] and addr[1] respectively. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com cc: Peter Tyser pty...@xes-inc.com Cc: Heiko Schocher h...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Stefan Roese s...@denx.de Cc: Mischa Jonker mjon...@synopsys.com --- common/cmd_eeprom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c index ef694d8..02539c4 100644 --- a/common/cmd_eeprom.c +++ b/common/cmd_eeprom.c @@ -161,7 +161,7 @@ int eeprom_read (unsigned dev_addr, unsigned offset, uchar *buffer, unsigned cnt #if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) spi_read (addr, alen, buffer, len); #else - if (i2c_read (addr[0], offset, alen-1, buffer, len) != 0) + if (i2c_read (addr[0], addr[1], alen-1, buffer, len) != 0) rcode = 1; #endif buffer += len; @@ -339,7 +339,7 @@ int eeprom_write (unsigned dev_addr, unsigned offset, uchar *buffer, unsigned cn /* Write is enabled ... now write eeprom value. */ #endif - if (i2c_write (addr[0], offset, alen-1, buffer, len) != 0) + if (i2c_write (addr[0], addr[1], alen-1, buffer, len) != 0) rcode = 1; #endif -- 1.8.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] designware_i2c: disable i2c controller during target address setup
As it is stated in DesignWare I2C databook: writes to IC_TAR (0x4)
register succeed only when IC_ENABLE[0] is set to 0.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Tom Rini tr...@ti.com
cc: Armando Visconti armando.visco...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Heiko Schocher h...@denx.de
Cc: Vipin KUMAR vipin.ku...@st.com
Cc: Tom Rix tom@windriver.com
Cc: Mischa Jonker mjon...@synopsys.com
---
drivers/i2c/designware_i2c.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index c2f0662..c5c6015 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -151,7 +151,19 @@ void i2c_init(int speed, int slaveadd)
*/
static void i2c_setaddress(unsigned int i2c_addr)
{
+ unsigned int enbl;
+
+ /* Disable i2c */
+ enbl = readl(i2c_regs_p-ic_enable);
+ enbl = ~IC_ENABLE_0B;
+ writel(enbl, i2c_regs_p-ic_enable);
+
writel(i2c_addr, i2c_regs_p-ic_tar);
+
+ /* Enable i2c */
+ enbl = readl(i2c_regs_p-ic_enable);
+ enbl |= IC_ENABLE_0B;
+ writel(enbl, i2c_regs_p-ic_enable);
}
/*
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild/makefile: allow building host tools separately
Sometimes it is required to build only host U-Boot tools without building U-Boot itself for either board. For example: * In buildroot uboot-tools could be built for host just to have an ability to create uImage. * Linux distributions ship mkimage utility as a separate substance. This patch allows building host U-Boot tools separately from U-Boot itself and what is more important user only needs to have host compiler (gcc). To build host tools just execute: = make tools HOST_TOOLS_ONLY=yes = Without this patch to generate tools user needs: 1. Configure any existing board with make XXX_config 2. Execute tools building but still cross-compiler will be invoked and if there's no proper cross-compiler in PATH compilation will fail. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com Cc: Simon Glass s...@chromium.org --- Kbuild | 5 + Makefile | 7 +++ 2 files changed, 12 insertions(+) diff --git a/Kbuild b/Kbuild index 1d89761..b5e348d 100644 --- a/Kbuild +++ b/Kbuild @@ -4,6 +4,9 @@ # 1) Generate generic-asm-offsets.h # 2) Generate asm-offsets.h +# Don't execute target below if building host tools only +ifneq ($(HOST_TOOLS_ONLY),yes) + # # 1) Generate generic-asm-offsets.h @@ -85,3 +88,5 @@ $(CPUDIR)/$(SOC)/asm-offsets.s: $(CPUDIR)/$(SOC)/asm-offsets.c FORCE $(obj)/$(offsets-file): $(CPUDIR)/$(SOC)/asm-offsets.s $(call cmd,offsets) + +endif diff --git a/Makefile b/Makefile index b795338..2fb8ea1 100644 --- a/Makefile +++ b/Makefile @@ -481,9 +481,12 @@ ifeq ($(dot-config),1) # load other configuration include $(srctree)/config.mk +# Don't check for config.mk presence if building host tools only +ifneq ($(HOST_TOOLS_ONLY),yes) ifeq ($(wildcard include/config.mk),) $(error System not configured - see README) endif +endif # If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use # that (or fail if absent). Otherwise, search for a linker script in a @@ -994,10 +997,14 @@ ifeq ($(CONFIG_SYS_GENERIC_BOARD),y) @/bin/false endif endif + +# Don't check for ldscript presence if building host tools only +ifneq ($(HOST_TOOLS_ONLY),yes) ifeq ($(wildcard $(LDSCRIPT)),) @echo 2 Could not find linker script. @/bin/false endif +endif archprepare: prepare1 scripts_basic -- 1.8.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/designware: align DMA buffer descriptors to D$ line
It's important to have ability to flush/invalidate each DMA buffer descriptor
individually to prevent incoherency of adjacent BDs.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Vineet Gupta vgu...@synopsys.com
Cc: Joe Hershberger joe.hershber...@ni.com
Cc: Vipin Kumar vipin.ku...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Shiraz Hashim shiraz.has...@st.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Amit Virdi amit.vi...@st.com
Cc: Sonic Zhang sonic.zh...@analog.com
---
drivers/net/designware.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index afeacce..382b0c7 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -110,7 +110,7 @@ struct dmamacdescr {
u32 dmamac_cntl;
void *dmamac_addr;
struct dmamacdescr *dmamac_next;
-} __aligned(16);
+} __aligned(ARCH_DMA_MINALIGN);
/*
* txrx_status definitions
--
1.8.5.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] axs101: flush DMA buffer descriptors before DMA transactons starts
CPU sets DMA buffer descriptors with data required for inetrnal DMA such as: * Ownership of BD * Buffer size * Pointer to data buffer in memory Then we need to make sure DMA engine of NAND controller gets proper data. For this we flush buffer rescriptor. Then we're ready for DMA transaction. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Vineet Gupta vgu...@synopsys.com Cc: Tom Rini tr...@ti.com --- board/synopsys/axs101/nand.c | 8 1 file changed, 8 insertions(+) diff --git a/board/synopsys/axs101/nand.c b/board/synopsys/axs101/nand.c index 8672803..c7f90c4 100644 --- a/board/synopsys/axs101/nand.c +++ b/board/synopsys/axs101/nand.c @@ -107,6 +107,10 @@ static void axs101_nand_write_buf(struct mtd_info *mtd, const u_char *buf, writel(bbstate.bounce_buffer, bd-buffer_ptr0); writel(0, bd-buffer_ptr1); + /* Flush modified buffer descriptor */ + flush_dcache_range((unsigned long)bd, + (unsigned long)bd + sizeof(struct nand_bd)); + /* Issue write command */ NAND_REG_WRITE(AC_FIFO, B_CT_WRITE | B_WFR | B_IWC | B_LC | (len-1)); @@ -137,6 +141,10 @@ static void axs101_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len) writel(bbstate.bounce_buffer, bd-buffer_ptr0); writel(0, bd-buffer_ptr1); + /* Flush modified buffer descriptor */ + flush_dcache_range((unsigned long)bd, + (unsigned long)bd + sizeof(struct nand_bd)); + /* Issue read command */ NAND_REG_WRITE(AC_FIFO, B_CT_READ | B_WFR | B_IWC | B_LC | (len - 1)); -- 1.8.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] axs101 - increase EEPROM page write delay from 32 to 64 msec
With 32 milliseconds delay on some boards EEMPROM got written inconsistently. With 64 msec all of our existig boards show properly written EEPROM. Cc: Tom Rini tr...@ti.com Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- include/configs/axs101.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/axs101.h b/include/configs/axs101.h index f6b569a..8d03110 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -103,7 +103,7 @@ #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 #define CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW1 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3 -#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 32 +#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 64 /* * SD/MMC configuration -- 1.8.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild/makefile: allow building host tools separately
Hi Masahiro-san, On Fri, 2014-03-28 at 15:36 +0900, Masahiro Yamada wrote: Hi Alexey, This may be the similar discussion to http://u-boot.10912.n7.nabble.com/U-Boot-could-not-cross-compile-u-boot-tools-td174911.html It looks not that relevant to me. For example even before switching U-Boot to Kbuild it was not possible to build host tools simply without patching sources/headers or configuring real target. Or I might be missing something here. Providing a separate make target seems preferable. Maybe like this? To build host tools just execute: = make tools-only = Fully agree. I thought about it right after I sent you initial patch. And I am not happy about adding ifdef to everywhere. So do I. But I don't see other way around unfortunately. So, how about a patch like this? diff --git a/Makefile b/Makefile index c744718..12e1075 100644 --- a/Makefile +++ b/Makefile @@ -409,7 +409,7 @@ timestamp_h := include/generated/timestamp_autogenerated.h no-dot-config-targets := clean clobber mrproper distclean \ help %docs check% coccicheck \ -ubootversion backup +ubootversion backup tools-only config-targets := 0 mixed-targets := 0 @@ -1128,6 +1128,9 @@ checkarmreloc: u-boot env: scripts_basic $(Q)$(MAKE) $(build)=tools/$@ +tools-only: scripts_basic + $(Q)$(MAKE) $(build)=tools + tools-all: export HOST_TOOLS_ALL=y tools-all: env tools ; Doesn't work for me: $ make tools-only HOSTCC scripts/basic/fixdep HOSTCC tools/aisimage.o HOSTCC tools/crc32.o HOSTCC tools/default_image.o HOSTCC tools/dumpimage.o In file included from include/version.h:11:0, from tools/dumpimage.c:11: include/timestamp.h:11:47: fatal error: generated/timestamp_autogenerated.h: No such file or directory #include generated/timestamp_autogenerated.h ^ compilation terminated. make[1]: *** [tools/dumpimage.o] Error 1 make: *** [tools-only] Error 2 -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild/makefile: allow building host tools separately
Hi Masahiro-san, On Mon, 2014-03-31 at 10:43 +0900, Masahiro Yamada wrote: I wanted to show retionale why a make target tools-only is better than HOST_TOOLS_ONLY=yes. Completely agree. I should have think a bit more before sending initial patch because right after the email was sent I thought why didn't I use a new target? :) New target looks much better than some random variable. It's shorter and easier to use. Doesn't work for me: $ make tools-only HOSTCC scripts/basic/fixdep HOSTCC tools/aisimage.o HOSTCC tools/crc32.o HOSTCC tools/default_image.o HOSTCC tools/dumpimage.o In file included from include/version.h:11:0, from tools/dumpimage.c:11: include/timestamp.h:11:47: fatal error: generated/timestamp_autogenerated.h: No such file or directory #include generated/timestamp_autogenerated.h ^ compilation terminated. make[1]: *** [tools/dumpimage.o] Error 1 make: *** [tools-only] Error 2 Oops - My bad. I was disabling timestamp. Could you fix like this? tools-only: scripts_basic $(version_h) $(timestamp_h) $(Q)$(MAKE) $(build)=tools Works as a charm for me as well. Do you mind to submit your changes (because it was you who implemented it properly and I don't want to steal your credits)? Or I do it still on your behalf putting you in as an author? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
On Mon, 2014-03-31 at 17:33 +0900, Masahiro Yamada wrote: Prior to Kbuild, U-Boot could build under tools/ directory withour configuring for a specific board. That feature was lost when switching to Kbuild. This patch revives it again by adding a make target tools-only. Usage: $ make tools-only Neither board configuration nor cross compiler are required to build host tools. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Suggested-by: Alexey Brodkin alexey.brod...@synopsys.com Cc: Alexey Brodkin alexey.brod...@synopsys.com Cc: Simon Glass s...@chromium.org Cc: Tom Rini tr...@ti.com Works as expected for me. Acked-by: Alexey Brodkin abrod...@synopsys.com -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
Hi Tom, On Mon, 2014-03-31 at 11:16 -0400, Tom Rini wrote: On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: Prior to Kbuild, U-Boot could build under tools/ directory withour configuring for a specific board. That feature was lost when switching to Kbuild. This patch revives it again by adding a make target tools-only. Usage: $ make tools-only Neither board configuration nor cross compiler are required to build host tools. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Suggested-by: Alexey Brodkin alexey.brod...@synopsys.com Cc: Alexey Brodkin alexey.brod...@synopsys.com Cc: Simon Glass s...@chromium.org Cc: Tom Rini tr...@ti.com Problem is that we make enabling the signature code (which adds more deps on the host) based on the config, and this was intentional. So I'm not sure if we want to do this exactly, at least right now. Could you please add a bit more clarifications for your comment. I don't quite understand why do I need to have any info from a board configuration when building mkimage utility. Maybe I'm missing something. And the problem is without proposed patch it's virtually impossible (or I don't know how) to build mkimage without configuring the real board. For example what Linux distros will do to build generic mkimage tool? And I think it is very important to resolve before U-Boot v2014.04 gets released. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
On Mon, 2014-03-31 at 11:31 -0400, Tom Rini wrote: On Mon, Mar 31, 2014 at 03:24:19PM +, Alexey Brodkin wrote: Hi Tom, On Mon, 2014-03-31 at 11:16 -0400, Tom Rini wrote: On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: Prior to Kbuild, U-Boot could build under tools/ directory withour configuring for a specific board. That feature was lost when switching to Kbuild. This patch revives it again by adding a make target tools-only. Usage: $ make tools-only Neither board configuration nor cross compiler are required to build host tools. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Suggested-by: Alexey Brodkin alexey.brod...@synopsys.com Cc: Alexey Brodkin alexey.brod...@synopsys.com Cc: Simon Glass s...@chromium.org Cc: Tom Rini tr...@ti.com Problem is that we make enabling the signature code (which adds more deps on the host) based on the config, and this was intentional. So I'm not sure if we want to do this exactly, at least right now. Could you please add a bit more clarifications for your comment. I don't quite understand why do I need to have any info from a board configuration when building mkimage utility. Maybe I'm missing something. And the problem is without proposed patch it's virtually impossible (or I don't know how) to build mkimage without configuring the real board. For example what Linux distros will do to build generic mkimage tool? So, if you check out tools/mkimage.c you can see that if CONFIG_FIT_SIGNATURE is set we add options for doing rsa/etc signatures on parts of a FIT image (see doc/uImage.FIT/signature.txt). But then you need to have crypto libraries on the host available for linking. When not set we capture the relevant flags and print out a message to stderr. Since generic distros today hate FIT images even more than legacy images, I'm not overly concerned about that, today. So why don't we accept proposed patch so at least there will be a simple way to build generic mkimage people usually need? If needed we may do more changes in the patch. For example we may add warning message saying that FIT images won't be supported by this generic mkimage etc. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] axs101 - increase EEPROM page write delay from 32 to 64 msec
Hi Tom, On Mon, 2014-03-24 at 17:27 +0400, Alexey Brodkin wrote: With 32 milliseconds delay on some boards EEMPROM got written inconsistently. With 64 msec all of our existig boards show properly written EEPROM. Cc: Tom Rini tr...@ti.com Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- include/configs/axs101.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/axs101.h b/include/configs/axs101.h index f6b569a..8d03110 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -103,7 +103,7 @@ #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 #define CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW 1 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS3 -#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS32 +#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS64 /* * SD/MMC configuration Do you mind to apply this one? Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] axs101: bump DDR size from 256 to 512 Mb
Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- include/configs/axs101.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/axs101.h b/include/configs/axs101.h index 8d03110..c22d6d0 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -16,7 +16,7 @@ #define CONFIG_SYS_CLK_FREQ75000 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ -/* dwgmac doesn't work with D$ enabled now */ +/* NAND controller DMA doesn't work correctly with D$ enabled */ #define CONFIG_SYS_DCACHE_OFF /* @@ -40,7 +40,7 @@ #define CONFIG_SYS_DDR_SDRAM_BASE 0x8000 #define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE -#define CONFIG_SYS_SDRAM_SIZE 0x1000 /* 256 Mb */ +#define CONFIG_SYS_SDRAM_SIZE 0x2000 /* 512 Mb */ #define CONFIG_SYS_INIT_SP_ADDR\ (CONFIG_SYS_SDRAM_BASE + 0x1000 - GENERATED_GBL_DATA_SIZE) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Changes for boards I maintain
Hi Tom, Now I have my own tree (u-boot-arc) and I may commit there changes for ARC architecture. But I'm wondering if I may commit changes to boards I maintain in the same u-boot-arc repo as well? Currently these are all in board/synopsys folder. Or I need to send patches for my boards to the mailing list and you'll apply them to the master u-boot git? Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net/designware: ensure device private data is DMA aligned.
Dear Ian,
On Sat, 2014-04-19 at 14:52 +0100, Ian Campbell wrote:
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;
Thanks for this fix.
It was a left-over from initially submitted driver and I missed this
hard-coded item.
Still I haven't tried to execute this on the real board.
Hope to do it soon but I don't expect any issues.
Regards,
Alexey
Reviewed-by: Alexey Brodkin abrod...@synopsys.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] net/designware: invalidate entire descriptor in dw_eth_send
Dear Ian,
On Sat, 2014-04-19 at 14:52 +0100, Ian Campbell wrote:
- /* 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) {
Unfortunately I cannot recall exactly why I wanted to invalidate only
status field.
Now looking at this code I may assume that I wanted to save some CPU
cycles. Because:
1. We don't care about all other fields except status. GMAC only
changes status field when it resets OWNED_BY_DMA flag and all other
fields CPU writes but not reads while sending packets.
2. We may save quite a few CPU cycles if only invalidating minimum
amount of bytes (remember each read from external memory may cost 100s
of cycles).
So I would advise:
1. Don't invalidate sizeof(struct dmamacdescr) but only
roundup(sizeof(desc_p-txrx_status), ARCH_DMA_MINALIGN)).
2. In the following lines implements rounding as well:
/* Flush data to be sent */
flush_dcache_range((unsigned long)desc_p-dmamac_addr,
(unsigned long)desc_p-dmamac_addr + length);
We may be sure desc_p-dmamac_addr is properly aligned, but length
could be not-aligned. So I'd replace length with roundup(length,
ARCH_DMA_MINALIGN) as you did in 3rd patch.
3. Check carefully if there're other instances of probably unaligned
cache operations. I erroneously didn't care about alignment on cache
invalidation/flushing because my implementation of those cache
operations deals with non-aligned start/end internally within
invalidate/flush functions - which might be not that good even if it's
convenient for me.
4. Why don't you squeeze all 3 patches in 1 and name it like fix
alignment issues with caches on some platforms? Basically with all 3
patches you fix one and only issue and application of any one of those 3
patches doesn't solve your problem, right?
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] net/designware: invalidate entire descriptor in dw_eth_send
Hi Ian,
On Thu, 2014-04-24 at 20:14 +0100, Ian Campbell wrote:
On Thu, 2014-04-24 at 17:41 +, Alexey Brodkin wrote:
1. Don't invalidate sizeof(struct dmamacdescr) but only
roundup(sizeof(desc_p-txrx_status), ARCH_DMA_MINALIGN)).
OK. (Although given the realities of the real world values of
ARCH_DMA_MINALIGN on every arch and the sizes of the structs fields
involved this isn't actually buying you anything at all)
Well this particular structure is of size sizeof(uint32_t) * 4 = 16
bytes. And I may suppose that cache lines could be shorter than 16 bytes
even though it could be pretty rare situation. So definitely not a big
deal.
But since we're dealing with macros here all mentioned calculations will
be done by pre-processor and execution performance won't be affected.
2. In the following lines implements rounding as well:
Will fix as well.
3. Check carefully if there're other instances of probably unaligned
cache operations.
I thought a bit more about this situation and now I'm not that sure if
we need to align addresses we pass to cache invalidate/flush functions.
Because IMHO drivers shouldn't care about specifics of particular
platform or architecture. Otherwise we'll need to patch each and every
driver only for cache invalidate/flush functions. I looked how these
functions are used in other drivers and see that in most of cases no
additional alignment precautions were implemented. People just pass
start and end addresses.
In its turn platform and architecture provides cache invalidate/flush
functions implement its functionality depending on hardware specifics.
For example on architectures that may only flush/invalidate with
granularity of 1 cache line cache invalidate/flush functions make sure
to start processing from the start of the cache line to which start
address falls and end processing when cache line where end address falls
is processed.
I may assume that there're architectures that automatically understand
from which cache line to start and at which line to stop processing.
But if your architecture requires cache line aligned addresses to be
used for start/end addresses you may look for examples in ARC
(http://git.denx.de/?p=u-boot/u-boot-arc.git;a=blob;f=arch/arc/cpu/arc700/cache.c),,
MIPS
(http://git.denx.de/?p=u-boot/u-boot-arc.git;a=blob;f=arch/mips/cpu/mips32/cpu.c),
SH
(http://git.denx.de/?p=u-boot/u-boot-arc.git;a=blob;f=arch/sh/cpu/sh4/cache.c),
and what's interesting even implementation you use have semi-proper
start/end addresses handling -
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/lib/cache-pl310.c
Here's your invalidation procedure:
/* invalidate memory from start to stop-1 */
void v7_outer_cache_inval_range(u32 start, u32 stop)
{
/* PL310 currently supports only 32 bytes cache line */
u32 pa, line_size = 32;
/*
* If start address is not aligned to cache-line do not
* invalidate the first cache-line
*/
if (start (line_size - 1)) {
printf(ERROR: %s - start address is not aligned - 0x%08x\n,
__func__, start);
/* move to next cache line */
start = (start + line_size - 1) ~(line_size - 1);
}
/*
* If stop address is not aligned to cache-line do not
* invalidate the last cache-line
*/
if (stop (line_size - 1)) {
printf(ERROR: %s - stop address is not aligned - 0x%08x\n,
__func__, stop);
/* align to the beginning of this cache line */
stop = ~(line_size - 1);
}
for (pa = start; pa stop; pa = pa + line_size)
writel(pa, pl310-pl310_inv_line_pa);
pl310_cache_sync();
}
1. I don't understand why start from the next cache line if start
address is not aligned to cache line boundary? I'd say that you want to
invalidate cache line that contains unaligned start address. Otherwise
first bytes won't be invalidated, right?
2. Why do we throw _error_ message. I may understand if you emit
_warning_ message in case of debug build (with DEBUG defined). Well in
current implementation (see 1) it could be error because behavior is
really dangerous. But if you start from correct cache line only warning
in debug mode makes sense (IMHO).
3. Stop/end address in contrast might need to be extended depending on
HW implementation (see above comment).
And here's your flush procedure:
===
void v7_outer_cache_flush_range(u32 start, u32 stop)
{
/* PL310 currently supports only 32 bytes cache line */
u32 pa, line_size = 32;
/*
* Align to the beginning of cache-line - this ensures that
* the first 5 bits are 0 as required by PL310 TRM
*/
start = ~(line_size - 1);
for (pa = start; pa stop; pa = pa + line_size)
writel(pa, pl310-pl310_clean_inv_line_pa
[U-Boot] please pull u-boot-arc master
Dear Tom, The following changes since commit adcdeacc3eda1e5949e54062aa99c299e12483be: Merge branch 'master' of git://git.denx.de/u-boot-mips (2014-04-23 11:07:11 -0400) are available in the git repository at: ssh://gu-...@git.denx.de/u-boot-arc master for you to fetch changes up to 0cdd762027340ad82fdc2bf7476e8e791529a251: axs101: bump DDR size from 256 to 512 Mb (2014-04-25 18:00:23 +0400) Alexey Brodkin (2): axs101: increase EEPROM page write delay from 32 to 64 msec axs101: bump DDR size from 256 to 512 Mb include/configs/axs101.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- Best regards, Alexey Brodkin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-arc master
Hi Tom, On Fri, 2014-04-25 at 15:45 -0400, Tom Rini wrote: On Fri, Apr 25, 2014 at 02:24:57PM +, Alexey Brodkin wrote: Dear Tom, The following changes since commit adcdeacc3eda1e5949e54062aa99c299e12483be: Merge branch 'master' of git://git.denx.de/u-boot-mips (2014-04-23 11:07:11 -0400) are available in the git repository at: ssh://gu-...@git.denx.de/u-boot-arc master Note we usually use one of the git:// URIs here :) I understand it. But unfortunately in our company most ports are closed for external resources except SSH. That's why I may only use SSH for secure pull/push from/to external repos. If this is completely not-acceptable for you I'll try to work with IT people and get access to U-boot repos via GIT protocol, but this might be a bit problematic. But IMHO since in pull request you have full command line for pulling I may expect that it should not complicate your operation significantly. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Failure on attempt to build env tools
Hi Marek, I noticed you recently committed support of AES encryption in U-Boot tools here - http://git.denx.de/?p=u-boot.git;a=commit;h=a8a752c084031905940129f8a6ba303925e0fac9 And now I cannot build env tools. Here's how to reproduce my experience: === $ make yourboard_config $ make env make[1]: *** No rule to make target `tools/env/aes.c', needed by `tools/env/aes.o'. Stop. make: *** [env] Error 2 === And from tools/env/Makefile I see that target aes.o exists while aes.c itself is situated in ./lib folder. Could you please try to build env tools and if you see the same error could you please fix it? If it's me who builds env tools improperly could you please teach me how to build them correctly? -- Best regards, Alexey Brodkin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: env: Add aes.c placeholder
Hi Marek, On Mon, 2014-04-28 at 11:56 +0200, Marek Vasut wrote: Add missing aes.c placeholder which includes lib/aes.c . Without this one, tools/env/ will fail to build. Signed-off-by: Marek Vasut ma...@denx.de Cc: Alexey Brodkin alexey.brod...@synopsys.com Cc: Masahiro Yamada yamad...@jp.panasonic.com --- tools/env/aes.c | 1 + 1 file changed, 1 insertion(+) create mode 100644 tools/env/aes.c diff --git a/tools/env/aes.c b/tools/env/aes.c new file mode 100644 index 000..9e42679 --- /dev/null +++ b/tools/env/aes.c @@ -0,0 +1 @@ +#include ../../lib/aes.c With this patch I may now build env tools. So... Tested-by: Alexey Brodkin abrod...@synopsys.com Would be good to apply this one to master ASAP so others don't suffer from the missing part. Regards, Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] net/designware: invalidate entire descriptor in dw_eth_send
Dear Ian,
On Sun, 2014-04-27 at 19:47 +0100, Ian Campbell wrote:
This is the driver for one particular ARM cache controller and not the
one used for the SoC. In any case it does proper start/end handling
only for cache flush operations, not cache invalidate.
Cache invalidate is a potentially destructive operation (throwing away
data in the caches), having it operate on anything more than the precise
region requested would be very surprising to almost anyone I think.
...
I think you are missing the important differences between a cache
flush and a cache invalidate.
IMHO cache invalidation and flush operations are sort of antipodes.
With invalidation you discard all data in corresponding line in cache
and replace it with freshly read data from memory.
With flush you move cache line to corresponding memory location
overriding previously existing values in memory.
So if you deal with 2 independent data fields which both share the same
one cache line it's potentially dangerous to do both flush and
invalidate of this cache line.
In case of MMU utilization we have a luxury of uncached access, so we
may safely access control structures in memory with granularity which is
available for this particular CPU. This is AFAIK drivers deal with
buffer descriptors in Linux kernel.
In case of U-Boot where we prefer to keep things simple we don't use
MMU. So no generic way for cache bypassing. Still some architectures
like ARC700 have special instructions for accessing memory bypassing
cache but I prever to not use them and keep sources
platform-independent.
And in this situation IMHO the only safe solution could be in proper
design of data layout. In other words we need to keep independent data
blocks aligned to cache line.
And as you may see from designware.h buffer descriptor structure is
aligned:
==
struct dmamacdescr {
u32 txrx_status;
u32 dmamac_cntl;
void *dmamac_addr;
struct dmamacdescr *dmamac_next;
} __aligned(ARCH_DMA_MINALIGN);
==
Regards,
Alexey
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] net/designware: Reduce DMA burst length
Hi Marek, On Mon, 2014-04-28 at 07:55 +0200, Marek Vasut wrote: On Monday, April 28, 2014 at 07:51:49 AM, Chen-Yu Tsai wrote: On Mon, Apr 28, 2014 at 2:08 AM, Marek Vasut ma...@denx.de wrote: On Sunday, April 27, 2014 at 05:29:29 PM, Chen-Yu Tsai wrote: On Sun, Apr 27, 2014 at 11:25 PM, Ian Campbell i...@hellion.org.uk wrote: On Sat, 2014-04-26 at 20:28 +0200, Marek Vasut wrote: On Friday, April 18, 2014 at 08:05:50 PM, Ian Campbell wrote: From: Jens Kuske jensku...@gmail.com The GMAC module in Allwinner sunxi SoCs seems to have problems with burst lengths 8. Is there any explanation for the problems please ? Jens or Wens, can you answer this? IIRC, with burst lengths 8, GMAC doesn't work, no ping, no DHCP. I don't remember if it was TX or RX that suffered, or even both. Hope this clarifies things a bit. No, it does not at all, sorry. What you describe are symptoms, but what I want to know is what is the root cause of those symptoms. You did not explain that. I can not offer much more explanation. The value was hardcoded in Allwinner's code. The datasheets don't offer much, except this line might be related: (DMA) Descriptor architecture, allowing large blocks of data transfer with minimum CPU intervention; each descriptor can transfer up to 4 KB data. Also probably related: 4KB TX FIFO for transmission packets and 16KB RX FIFO for reception packets. I'm not an expert in hardware. We could ask Allwinner, but given past inquiries from the linux-sunxi community, I'd say getting a reply on hardware specifics is unlikely to happen. So my guess is that this is limited by the DWMAC IP Allwinner licensed from Synopsys. Even though I'm not an expert in DW GMAC I may confirm that it has tons of settings people may use for fine-tuning performance and I may assume that there're corner cases when some settings may lead to real problems. And IMHO if different boards may need different configurations why don't we satisfy their needs. But it's good to keep others who used to use existing settings happy too. If you look in corresponding driver in Linux kernel (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro) you'll see much more complicated code compared to driver in U-Boot. And among other things you may see some GMAC parameters could be set per platform. And Programmable Burst Length (PBL) is one of them. Look at stmmac_init_dma_engine() in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c You may see default PBL (DEFAULT_DMA_PBL = 8) is used if other value is not provided by platform. So I would propose to act this way: 1. Introduce driver-specific config value. Something like DW_GMAC_DEFAULT_DMA_PBL and in designware.h set it to BURST_8. I hope driver in Linux was used a lot and this value could be treated as safe. 2. Ask people to try this new setting on existing boards that use DW GMAC. If everybody is happy there's nothing else to do here. 3. Otherwise if people report regressions add mentioned config option in board configuration files for problematic boards. I think with this approach everybody will be happy. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_bdinfo: check for CONFIG_ARC instead of CONFIG_ARC700
For all flavours of ARC we execute the same code in bdinfo so we may
safely check for CONFIG_ARC. This is especially important since we're
about to add more types of ARC so existing check won't work in all
cases.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Tom Rini tr...@ti.com
---
common/cmd_bdinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index f0b713c..e6d8a7a 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -515,7 +515,7 @@ int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
return 0;
}
-#elif defined(CONFIG_ARC700)
+#elif defined(CONFIG_ARC)
int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arc: introduce mdbtrick target
MetaWare debugger doesn't support PIE (position-independent executable) so the only way to load U-Boot in MDB is to fake it by: 1. Reset PIE flag in ELF header 2. Strip all debug information from elf Even though it could be done manually but having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying make mdbtrick. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com --- arch/arc/Makefile | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arc/Makefile b/arch/arc/Makefile index de25cc9..03ea6db 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -6,3 +6,18 @@ head-y := arch/arc/cpu/$(CPU)/start.o libs-y += arch/arc/cpu/$(CPU)/ libs-y += arch/arc/lib/ + +# MetaWare debugger doesn't support PIE (position-independent executable) +# so the only way to load U-Boot in MDB is to fake it by: +# 1. Reset PIE flag in ELF header +# 2. Strip all debug information from elf +ifdef CONFIG_SYS_LITTLE_ENDIAN + EXEC_TYPE_OFFSET=16 +else + EXEC_TYPE_OFFSET=17 +endif + +mdbtrick: u-boot + $(Q)printf '\x02' | dd of=u-boot bs=1 seek=$(EXEC_TYPE_OFFSET) count=1 \ + conv=notrunc /dev/null + $(Q)$(CROSS_COMPILE)strip -g u-boot -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arc: introduce mdbtrick target
Hi Wolfgang, On Fri, 2014-12-26 at 11:00 +0100, Wolfgang Denk wrote: Dear Alexey, In message 1419587516-30541-1-git-send-email-abrod...@synopsys.com you wrote: MetaWare debugger doesn't support PIE (position-independent executable) so the only way to load U-Boot in MDB is to fake it by: 1. Reset PIE flag in ELF header 2. Strip all debug information from elf Even though it could be done manually but having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying make mdbtrick. I wonder if such manipulation helps? Are you really able to debug PIE code on the target just by fooling the debugger about it like this? I would expect that it would fail to work if it really doesn't support PIE? Well the point is MDB is still used as a primary tool for interaction with target via JTAG. Moreover some very advanced features are not yet implemented in GDB for ARC (and not sure if they will be implemnted sometime soon given complexity and rare need for those features for common user). So if we're talking about development process when U-Boot is loaded in target memory not by low-level boot-loader but manually through JTAG chances are high developer uses MDB for it. Without manipulation we're talking about (BTW I got it documented quite a while ago here http://www.denx.de/wiki/U-Boot/ARCNotes) MDB will refuse to even start - so no chance to load elf contents on target. Then if we now apply the manipulation MDB will happily start and will load all required sections into the target. Indeed there will be no source-level debug info available. And still MDB will do its work on showing disassembly, registers, accessing low-level debug facilities etc. So as a summary - this is pretty dirty hack but it simplifies life a lot for us. Hope this explanation makes sense. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] initcall: add explicit hint if initcall was relocated
Commit initcall: Improve debugging support makes sense and indeed
simplifies process of matching initcalls executed with static
disassembly.
Until you are debugging relocation functionality.
Existign output may make you think that at some point execution somehow
returned back to non-relocated area. And there're many reasons/problems
that may provoke this behavior.
In order to make things clear let's add explicit mention in case initall
was actually relocated like this:
--
initcall: 810015f8
Relocation Offset is: 0efcf000
Relocating to 8ffcf000, new gd at 8fdced3c, sp at 8fdced20
initcall: 810015b8
initcall: 8ffd093c
initcall: 8ffd0a14
initcall: 81001940 (relocated to 8ffd0940)
initcall: 81001958 (relocated to 8ffd0958)
--
Note unexpected jump from 0x8f... area to 0x81... area.
Without explanation this raises many questions: execution jumped in
relocated area right as expected and then for some reason returned back?
But I hope comment in brackets will save some time for those curious
developers who are careful enough to catch unexpected jump to pre-reloc
area or those unlucky ones who'll have to deal with relocation
debugging.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
---
lib/initcall.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/initcall.c b/lib/initcall.c
index 39f4b3f..7142744 100644
--- a/lib/initcall.c
+++ b/lib/initcall.c
@@ -19,7 +19,11 @@ int initcall_run_list(const init_fnc_t init_sequence[])
if (gd-flags GD_FLG_RELOC)
reloc_ofs = gd-reloc_off;
- debug(initcall: %p\n, (char *)*init_fnc_ptr - reloc_ofs);
+ debug(initcall: %p, (char *)*init_fnc_ptr - reloc_ofs);
+ if (gd-flags GD_FLG_RELOC)
+ debug( (relocated to %p)\n, (char *)*init_fnc_ptr);
+ else
+ debug(\n);
ret = (*init_fnc_ptr)();
if (ret) {
printf(initcall sequence %p failed at call %p
(err=%d)\n,
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arc: introduce mdbtrick target
MetaWare debugger (MDB) is still used as a primary tool for interaction with target via JTAG. Moreover some very advanced features are not yet implemented in GDB for ARC (and not sure if they will be implemnted sometime soon given complexity and rare need for those features for common user). So if we're talking about development process when U-Boot is loaded in target memory not by low-level boot-loader but manually through JTAG chances are high developer uses MDB for it. But MDB doesn't support PIE (position-independent executable) - it will refuse to even start - that means no chance to load elf contents on target. Then the only way to load U-Boot in MDB is to fake it by: 1. Reset PIE flag in ELF header This is simpe - on attempt to open elf MDB checks header and if it doesn't match its expectation refuces to use provided elf. 2. Strip all debug information from elf If (1) is done then MDB will open elf but on parsing of elf's debug info it will refuse to process due to debug info it cannot understand (symbols with PIE relocation). Even though it could be done manually (I got it documented quite a while ago here http://www.denx.de/wiki/U-Boot/ARCNotes) having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying make mdbtrick. Then if we now apply the manipulation MDB will happily start and will load all required sections into the target. Indeed there will be no source-level debug info available. But still MDB will do its work on showing disassembly, global symbols, registers, accessing low-level debug facilities etc. As a summary - this is a pretty dirty hack but it simplifies life a lot for us ARc developers. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de --- In v2 I only updated commit message with more info on why we do need this change --- arch/arc/Makefile | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arc/Makefile b/arch/arc/Makefile index de25cc9..03ea6db 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -6,3 +6,18 @@ head-y := arch/arc/cpu/$(CPU)/start.o libs-y += arch/arc/cpu/$(CPU)/ libs-y += arch/arc/lib/ + +# MetaWare debugger doesn't support PIE (position-independent executable) +# so the only way to load U-Boot in MDB is to fake it by: +# 1. Reset PIE flag in ELF header +# 2. Strip all debug information from elf +ifdef CONFIG_SYS_LITTLE_ENDIAN + EXEC_TYPE_OFFSET=16 +else + EXEC_TYPE_OFFSET=17 +endif + +mdbtrick: u-boot + $(Q)printf '\x02' | dd of=u-boot bs=1 seek=$(EXEC_TYPE_OFFSET) count=1 \ + conv=notrunc /dev/null + $(Q)$(CROSS_COMPILE)strip -g u-boot -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] common: mark commands as default to match config_cmd_default.h
Now when we may select commands via menuconfig let's adjust default settings with config_cmd_default.h. As the next step we may get rid of config_cmd_default.h inclusion in include/configs/*.h and config_cmd_default.h itself. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Masahiro Yamada yamad...@jp.panasonic.com Cc: Tom Rini tr...@ti.com --- common/Kconfig | 19 +++ 1 file changed, 19 insertions(+) diff --git a/common/Kconfig b/common/Kconfig index fd84fa0..cbc4f5b 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -24,11 +24,13 @@ menu Info commands config CMD_BDI bool bdinfo + default y help Print board info config CMD_CONSOLE bool coninfo + default y help Print console devices and information. @@ -43,6 +45,7 @@ menu Boot commands config CMD_BOOTD bool bootd + default y help Run the command stored in the environment bootcmd, i.e. bootd does the same thing as run bootcmd. @@ -61,11 +64,13 @@ config CMD_GO config CMD_RUN bool run + default y help Run the command in the given environment variable. config CMD_IMI bool iminfo + default y help Print header information for application image. @@ -76,6 +81,7 @@ config CMD_IMLS config CMD_XIMG bool imxtract + default y help Extract a part of a multi-image. @@ -97,11 +103,13 @@ config CMD_IMPORTENV config CMD_EDITENV bool editenv + default y help Edit environment variable. config CMD_SAVEENV bool saveenv + default y help Run the command in the given environment variable. @@ -111,6 +119,7 @@ menu Memory commands config CMD_MEMORY bool md, mm, nm, mw, cp, cmp, base, loop + default y help Memeory commands. md - memory display @@ -155,11 +164,13 @@ menu Device access commands config CMD_LOADB bool loadb + default y help Load a binary file over serial line. config CMD_LOADS bool loads + default y help Load an S-Record file over serial line @@ -193,6 +204,7 @@ config CMD_USB config CMD_FPGA bool fpga + default y help FPGA support. @@ -203,16 +215,19 @@ menu Shell scripting commands config CMD_ECHO bool echo + default y help Echo args to console config CMD_ITEST bool itest + default y help Return true/false on integer compare. config CMD_SOURCE bool source + default y help Run script from memory @@ -222,6 +237,7 @@ menu Network commands config CMD_NET bool bootp, tftpboot + default y help Network commands. bootp - boot image via network using BOOTP/TFTP protocol @@ -249,6 +265,7 @@ config CMD_DHCP config CMD_NFS bool nfs + default y help Boot image via network using NFS protocol. @@ -294,6 +311,7 @@ config CMD_TIME # TODO: rename to CMD_SLEEP config CMD_MISC bool sleep + default y help Delay execution for some time @@ -304,6 +322,7 @@ config CMD_TIMER config CMD_SETGETDCR bool getdcr, setdcr, getidcr, setidcr + default y depends on 4xx help getdcr - Get an AMCC PPC 4xx DCR's value -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] config_cmd_default.h: wrap each definition in ifndef
Now with switch to Kconfig it's possible to select commands via menuconfig or defconfigs. Moreover some commands are enabled by default in both config_cmd_default.h as a legacy way and in common/Kconfig. And on attempt to build U-Boot following warnings are printed for definitions made in both: -- In file included from include/configs/arcangel4.h:45:0, from include/config.h:4, from include/common.h:18, from examples/standalone/stubs.c:1: include/config_cmd_default.h:20:0: warning: CONFIG_CMD_BDI redefined [enabled by default] #define CONFIG_CMD_BDI /* bdinfo */ ^ In file included from ././include/linux/kconfig.h:4:0, from command-line:0: include/generated/autoconf.h:10:0: note: this is the location of the previous definition #define CONFIG_CMD_BDI 1 ^ -- An obvious fix is to wrap all definitions in config_cmd_default.h since we still have to keep it util we're done with complete switch to Kconfig. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com --- include/config_cmd_default.h | 42 ++ 1 file changed, 42 insertions(+) diff --git a/include/config_cmd_default.h b/include/config_cmd_default.h index 73c9544..b33f21b 100644 --- a/include/config_cmd_default.h +++ b/include/config_cmd_default.h @@ -16,28 +16,70 @@ * hardware, not fully tested, etc.). */ +#ifndef CONFIG_CMD_BDI #define CONFIG_CMD_BDI /* bdinfo */ +#endif +#ifndef CONFIG_CMD_BOOTD #define CONFIG_CMD_BOOTD /* bootd*/ +#endif +#ifndef CONFIG_CMD_CONSOLE #define CONFIG_CMD_CONSOLE /* coninfo */ +#endif +#ifndef CONFIG_CMD_ECHO #define CONFIG_CMD_ECHO/* echo arguments */ +#endif +#ifndef CONFIG_CMD_EDITENV #define CONFIG_CMD_EDITENV /* editenv */ +#endif +#ifndef CONFIG_CMD_FPGA #define CONFIG_CMD_FPGA/* FPGA configuration Support */ +#endif +#ifndef CONFIG_CMD_IMI #define CONFIG_CMD_IMI /* iminfo */ +#endif +#ifndef CONFIG_CMD_ITEST #define CONFIG_CMD_ITEST /* Integer (and string) test*/ +#endif #ifndef CONFIG_SYS_NO_FLASH +#ifndef CONFIG_CMD_FLASH #define CONFIG_CMD_FLASH /* flinfo, erase, protect */ +#endif +#ifndef CONFIG_CMD_IMLS #define CONFIG_CMD_IMLS/* List all found images*/ #endif +#endif /* CONFIG_SYS_NO_FLASH */ +#ifndef CONFIG_CMD_LOADB #define CONFIG_CMD_LOADB /* loadb*/ +#endif +#ifndef CONFIG_CMD_LOADS #define CONFIG_CMD_LOADS /* loads*/ +#endif +#ifndef CONFIG_CMD_MEMORY #define CONFIG_CMD_MEMORY /* md mm nm mw cp cmp crc base loop */ +#endif +#ifndef CONFIG_CMD_MISC #define CONFIG_CMD_MISC/* Misc functions like sleep etc*/ +#endif +#ifndef CONFIG_CMD_NET #define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/ +#endif +#ifndef CONFIG_CMD_NFS #define CONFIG_CMD_NFS /* NFS support */ +#endif +#ifndef CONFIG_CMD_RUN #define CONFIG_CMD_RUN /* run command in env variable */ +#endif +#ifndef CONFIG_CMD_SAVEENV #define CONFIG_CMD_SAVEENV /* saveenv */ +#endif +#ifndef CONFIG_CMD_SETGETDCR #define CONFIG_CMD_SETGETDCR /* DCR support on 4xx */ +#endif +#ifndef CONFIG_CMD_SOURCE #define CONFIG_CMD_SOURCE /* source command support */ +#endif +#ifndef CONFIG_CMD_XIMG #define CONFIG_CMD_XIMG/* Load part of Multi Image */ +#endif #endif /* _CONFIG_CMD_DEFAULT_H */ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] select default commands in Kconfig
Now when we may select commands via menuconfig let's adjust default settings with config_cmd_default.h. As the next step we may get rid of config_cmd_default.h inclusion in include/configs/*.h and config_cmd_default.h itself. But while config_cmd_default.h is still there we need to work-around compile-time warnings. Alexey Brodkin (2): common: mark commands as default to match config_cmd_default.h config_cmd_default.h: wrap each definition in ifndef common/Kconfig | 19 +++ include/config_cmd_default.h | 42 ++ 2 files changed, 61 insertions(+) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/12] arc: add more flavours of ARC700 series CPU
Now we may select a particular version of ARC700: * ARC750D or * ARC770D It allows more flexible (or more fine tuned) configuration of U-Boot. Before that change we relied on minimal configuration but now we may use specific features of each CPU. Moreover allows us to escape manual selection of options that exist in both CPUs but may have say different version like MMUv2 in ARC750D vs MMUv3 in ARC770D. Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- arch/arc/Kconfig | 40 arch/arc/config.mk | 4 arch/arc/include/asm/arcregs.h | 2 ++ arch/arc/include/asm/cache.h | 6 ++ include/configs/arcangel4-be.h | 1 - include/configs/arcangel4.h| 1 - include/configs/axs101.h | 1 - include/configs/tb100.h| 1 - 8 files changed, 52 insertions(+), 4 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index c6b1efe..f7d2964 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -8,6 +8,46 @@ config SYS_CPU default arcv1 choice + prompt CPU selection + default CPU_ARC770D + +config CPU_ARC750D + bool ARC 750D + select ARC_MMU_V2 + help + Choose this option to build an U-Boot for ARC750D CPU. + +config CPU_ARC770D + bool ARC 770D + select ARC_MMU_V3 + help + Choose this option to build an U-Boot for ARC770D CPU. + +endchoice + +choice + prompt MMU Version + default ARC_MMU_V3 if CPU_ARC770D + default ARC_MMU_V2 if CPU_ARC750D + +config ARC_MMU_V2 + bool MMU v2 + depends on CPU_ARC750D + help + Fixed the deficiency of v1 - possible thrashing in memcpy sceanrio + when 2 D-TLB and 1 I-TLB entries index into same 2way set. + +config ARC_MMU_V3 + bool MMU v3 + depends on CPU_ARC770D + help + Introduced with ARC700 4.10: New Features + Variable Page size (1k-16k), var JTLB size 128 x (2 or 4) + Shared Address Spaces (SASID) + +endchoice + +choice prompt Target select config TARGET_TB100 diff --git a/arch/arc/config.mk b/arch/arc/config.mk index 5321987..dd180ef 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -25,6 +25,10 @@ ifdef CONFIG_ARC_MMU_VER CONFIG_MMU = 1 endif +ifdef CONFIG_CPU_ARC770D +PLATFORM_CPPFLAGS += -mlock -mswape +endif + PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -gdwarf-2 # Needed for relocation diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h index 8ace87f..31627e6 100644 --- a/arch/arc/include/asm/arcregs.h +++ b/arch/arc/include/asm/arcregs.h @@ -7,6 +7,8 @@ #ifndef _ASM_ARC_ARCREGS_H #define _ASM_ARC_ARCREGS_H +#include asm/cache.h + /* * ARC architecture has additional address space - auxiliary registers. * These registers are mostly used for configuration purposes. diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h index 16e7568..368d1f0 100644 --- a/arch/arc/include/asm/cache.h +++ b/arch/arc/include/asm/cache.h @@ -20,4 +20,10 @@ #define ARCH_DMA_MINALIGN 128 #endif +#if defined(CONFIG_ARC_MMU_V2) +#define CONFIG_ARC_MMU_VER 2 +#elif defined(CONFIG_ARC_MMU_V3) +#define CONFIG_ARC_MMU_VER 3 +#endif + #endif /* __ASM_ARC_CACHE_H */ diff --git a/include/configs/arcangel4-be.h b/include/configs/arcangel4-be.h index 2ca209e..a43590b 100644 --- a/include/configs/arcangel4-be.h +++ b/include/configs/arcangel4-be.h @@ -11,7 +11,6 @@ * CPU configuration */ #define CONFIG_SYS_BIG_ENDIAN -#define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 64 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ diff --git a/include/configs/arcangel4.h b/include/configs/arcangel4.h index 2afb63d..565f70e 100644 --- a/include/configs/arcangel4.h +++ b/include/configs/arcangel4.h @@ -10,7 +10,6 @@ /* * CPU configuration */ -#define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 64 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ diff --git a/include/configs/axs101.h b/include/configs/axs101.h index a8a9cb3..b94687c 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -10,7 +10,6 @@ /* * CPU configuration */ -#define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ diff --git a/include/configs/tb100.h b/include/configs/tb100.h index a598343..f353950 100644 --- a/include/configs/tb100.h +++ b/include/configs/tb100.h @@ -12,7 +12,6 @@ /* * CPU configuration */ -#define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/12] arc: define and use PTAG AUX regs for MMUv3 only
DC_PTAG and IC_PTAG registers only exist in MMUv3.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
---
arch/arc/include/asm/arcregs.h | 4 ++--
arch/arc/lib/cache.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h
index 31627e6..6a36a81 100644
--- a/arch/arc/include/asm/arcregs.h
+++ b/arch/arc/include/asm/arcregs.h
@@ -23,7 +23,7 @@
#define ARC_AUX_IC_IVIC0x10
#define ARC_AUX_IC_CTRL0x11
#define ARC_AUX_IC_IVIL0x19
-#if (CONFIG_ARC_MMU_VER 2)
+#if (CONFIG_ARC_MMU_VER == 3)
#define ARC_AUX_IC_PTAG0x1E
#endif
#define ARC_BCR_IC_BUILD 0x77
@@ -42,7 +42,7 @@
#define ARC_AUX_DC_IVDL0x4A
#define ARC_AUX_DC_FLSH0x4B
#define ARC_AUX_DC_FLDL0x4C
-#if (CONFIG_ARC_MMU_VER 2)
+#if (CONFIG_ARC_MMU_VER == 3)
#define ARC_AUX_DC_PTAG0x5C
#endif
#define ARC_BCR_DC_BUILD 0x72
diff --git a/arch/arc/lib/cache.c b/arch/arc/lib/cache.c
index fa19a13..fa2a1e7 100644
--- a/arch/arc/lib/cache.c
+++ b/arch/arc/lib/cache.c
@@ -101,7 +101,7 @@ void flush_dcache_all(void)
#ifndef CONFIG_SYS_DCACHE_OFF
static void dcache_flush_line(unsigned addr)
{
-#if (CONFIG_ARC_MMU_VER 2)
+#if (CONFIG_ARC_MMU_VER == 3)
write_aux_reg(ARC_AUX_DC_PTAG, addr);
#endif
write_aux_reg(ARC_AUX_DC_FLDL, addr);
@@ -115,7 +115,7 @@ static void dcache_flush_line(unsigned addr)
* Invalidate I$ for addresses range just flushed from D$.
* If we try to execute data flushed above it will be valid/correct
*/
-#if (CONFIG_ARC_MMU_VER 2)
+#if (CONFIG_ARC_MMU_VER == 3)
write_aux_reg(ARC_AUX_IC_PTAG, addr);
#endif
write_aux_reg(ARC_AUX_IC_IVIL, addr);
@@ -145,7 +145,7 @@ void invalidate_dcache_range(unsigned long start, unsigned
long end)
end = end (~(CONFIG_SYS_CACHELINE_SIZE - 1));
for (addr = start; addr = end; addr += CONFIG_SYS_CACHELINE_SIZE) {
-#if (CONFIG_ARC_MMU_VER 2)
+#if (CONFIG_ARC_MMU_VER == 3)
write_aux_reg(ARC_AUX_DC_PTAG, addr);
#endif
write_aux_reg(ARC_AUX_DC_IVDL, addr);
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/12] arc: remove CPU hard-coded selection from board description in include/configs
With switch to Kconfig we only need very board-specific descriptions in include/configs. CPU selection is performed with either defconfig or manually via menuconfig. Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- include/configs/arcangel4-be.h | 1 - include/configs/arcangel4.h| 1 - include/configs/axs101.h | 1 - include/configs/tb100.h| 1 - 4 files changed, 4 deletions(-) diff --git a/include/configs/arcangel4-be.h b/include/configs/arcangel4-be.h index 76163ab..2ca209e 100644 --- a/include/configs/arcangel4-be.h +++ b/include/configs/arcangel4-be.h @@ -11,7 +11,6 @@ * CPU configuration */ #define CONFIG_SYS_BIG_ENDIAN -#define CONFIG_ARC700 #define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 64 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ diff --git a/include/configs/arcangel4.h b/include/configs/arcangel4.h index 81934a4..2afb63d 100644 --- a/include/configs/arcangel4.h +++ b/include/configs/arcangel4.h @@ -10,7 +10,6 @@ /* * CPU configuration */ -#define CONFIG_ARC700 #define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 64 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ diff --git a/include/configs/axs101.h b/include/configs/axs101.h index c61ddd6..a8a9cb3 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -10,7 +10,6 @@ /* * CPU configuration */ -#define CONFIG_ARC700 #define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ diff --git a/include/configs/tb100.h b/include/configs/tb100.h index e9218f7..a598343 100644 --- a/include/configs/tb100.h +++ b/include/configs/tb100.h @@ -12,7 +12,6 @@ /* * CPU configuration */ -#define CONFIG_ARC700 #define CONFIG_ARC_MMU_VER 3 #define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/12] arc: memcmp - fix zero-delay loop utilization
From: Igor Guryanov gurya...@synopsys.com It's prohibited to put branch instruction in the very end of zero-delay loop. On execution this causes Illegal instruction exception. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Signed-off-by: Igor Guryanov gurya...@synopsys.com --- arch/arc/lib/memcmp.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arc/lib/memcmp.S b/arch/arc/lib/memcmp.S index fa5aac5..87bccab 100644 --- a/arch/arc/lib/memcmp.S +++ b/arch/arc/lib/memcmp.S @@ -29,6 +29,7 @@ memcmp: ld.a%r4, [%r0, 8] ld.a%r5, [%r1, 8] brneWORD2, %r12, .Lodd + nop .Loop_end: asl_s SHIFT, SHIFT, 3 bhs_s .Last_cmp @@ -105,6 +106,7 @@ memcmp: ldb.a %r4, [%r0, 2] ldb.a %r5, [%r1, 2] brne%r3, %r12, .Lbyte_odd + nop .Lbyte_end: bcc .Lbyte_even brne%r4, %r5, .Lbyte_even -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/12] ARC: more improvements
This series is focused on following items: * Move more config options to Kconfig - Cache settings - Endianess - Monitor base * Clean-up of board configuration headers * Build libgcc in U-Boot for portability Alexey Brodkin (11): arc: remove CPU hard-coded selection from board description in include/configs arc: add more flavours of ARC700 series CPU arc: define and use PTAG AUX regs for MMUv3 only arc: select cache settings via menuconfig arc: add selection of endianess in Kconfig arc: hard-code CONFIG_SYS_GENERIC_BOARD into asm/config.h arc: get rid of useless CONFIG_SKIP_LOWLEVEL_INIT arc: hard-code CONFIG_ARCH_EARLY_INIT_R in asm/config.h arc: move SYS_MONITOR_BASE setup in Konfig arc: move CPU flags selection to the main config.mk arc: build libgcc in U-Boot Igor Guryanov (1): arc: memcmp - fix zero-delay loop utilization Kconfig| 2 +- arch/Kconfig | 1 + arch/arc/Kconfig | 71 - arch/arc/config.mk | 15 ++- arch/arc/cpu/arcv1/config.mk | 7 -- arch/arc/include/asm/arcregs.h | 6 +- arch/arc/include/asm/cache.h | 19 ++-- arch/arc/include/asm/config.h | 2 + arch/arc/lib/Makefile | 2 + arch/arc/lib/_millicodethunk.S | 226 + arch/arc/lib/cache.c | 7 +- arch/arc/lib/libgcc2.c | 161 + arch/arc/lib/libgcc2.h | 132 arch/arc/lib/memcmp.S | 2 + board/synopsys/Kconfig | 10 -- board/synopsys/MAINTAINERS | 1 - configs/arcangel4-be_defconfig | 4 +- configs/arcangel4_defconfig| 1 + configs/axs101_defconfig | 5 +- configs/tb100_defconfig| 4 +- include/configs/arcangel4-be.h | 91 - include/configs/arcangel4.h| 12 --- include/configs/axs101.h | 15 --- include/configs/tb100.h| 10 -- 24 files changed, 639 insertions(+), 167 deletions(-) delete mode 100644 arch/arc/cpu/arcv1/config.mk create mode 100644 arch/arc/lib/_millicodethunk.S create mode 100644 arch/arc/lib/libgcc2.c create mode 100644 arch/arc/lib/libgcc2.h delete mode 100644 include/configs/arcangel4-be.h -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/12] arc: hard-code CONFIG_SYS_GENERIC_BOARD into asm/config.h
There're no other options for ARC except generic board so ther's no point to define CONFIG_SYS_GENERIC_BOARD per board. We now have it set fo all ARC boards. Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- arch/arc/include/asm/config.h | 1 + include/configs/arcangel4.h | 1 - include/configs/axs101.h | 1 - include/configs/tb100.h | 1 - 4 files changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/arc/include/asm/config.h b/arch/arc/include/asm/config.h index e5be078..c1e9b44 100644 --- a/arch/arc/include/asm/config.h +++ b/arch/arc/include/asm/config.h @@ -7,6 +7,7 @@ #ifndef __ASM_ARC_CONFIG_H_ #define __ASM_ARC_CONFIG_H_ +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_GENERIC_GLOBAL_DATA #define CONFIG_SYS_BOOT_RAMDISK_HIGH diff --git a/include/configs/arcangel4.h b/include/configs/arcangel4.h index 3268c56..60f3077 100644 --- a/include/configs/arcangel4.h +++ b/include/configs/arcangel4.h @@ -15,7 +15,6 @@ /* * Board configuration */ -#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is in RAM already */ #define CONFIG_ARCH_EARLY_INIT_R diff --git a/include/configs/axs101.h b/include/configs/axs101.h index ff3fad3..2340d99 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -15,7 +15,6 @@ /* * Board configuration */ -#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is in RAM already */ #define CONFIG_ARCH_EARLY_INIT_R diff --git a/include/configs/tb100.h b/include/configs/tb100.h index 32675c4..c6878fc 100644 --- a/include/configs/tb100.h +++ b/include/configs/tb100.h @@ -17,7 +17,6 @@ /* * Board configuration */ -#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_ARCH_EARLY_INIT_R /* -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/12] arc: select cache settings via menuconfig
This change allows to keep board description clean and minimalistic. This is especially helpful if one board may house different CPUs with different features. It is applicable to both FPGA-based boards or those that have CPUs mounted on interchnagable daughter-boards. Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- arch/arc/Kconfig | 19 +++ arch/arc/include/asm/cache.h | 13 + arch/arc/lib/cache.c | 1 + configs/axs101_defconfig | 4 +++- configs/tb100_defconfig| 3 ++- include/configs/arcangel4-be.h | 1 - include/configs/arcangel4.h| 1 - include/configs/axs101.h | 4 include/configs/tb100.h| 1 - 9 files changed, 30 insertions(+), 17 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index f7d2964..397b179 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -47,6 +47,25 @@ config ARC_MMU_V3 endchoice +config SYS_ICACHE_OFF + bool Do not use Instruction Cache + default n + +config SYS_DCACHE_OFF + bool Do not use Data Cache + default n + +config ARC_CACHE_LINE_SHIFT + int Cache Line Length (as power of 2) + range 5 7 + default 6 + depends on !SYS_DCACHE_OFF || !SYS_DCACHE_OFF + help + Starting with ARC700 4.9, Cache line length is configurable, + This option specifies N, with Line-len = 2 power N + So line lengths of 32, 64, 128 are specified by 5,6,7, respectively + Linux only supports same line lengths for I and D caches. + choice prompt Target select diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h index 368d1f0..2725961 100644 --- a/arch/arc/include/asm/cache.h +++ b/arch/arc/include/asm/cache.h @@ -9,15 +9,12 @@ #include config.h -/* - * The current upper bound for ARC L1 data cache line sizes is 128 bytes. - * We use that value for aligning DMA buffers unless the board config has - * specified an alternate cache line size. - */ -#ifdef CONFIG_SYS_CACHELINE_SIZE -#define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE +#ifdef CONFIG_ARC_CACHE_LINE_SHIFT +#define CONFIG_SYS_CACHELINE_SIZE (1 CONFIG_ARC_CACHE_LINE_SHIFT) +#define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE #else -#define ARCH_DMA_MINALIGN 128 +/* Satisfy users of ARCH_DMA_MINALIGN */ +#define ARCH_DMA_MINALIGN 128 #endif #if defined(CONFIG_ARC_MMU_V2) diff --git a/arch/arc/lib/cache.c b/arch/arc/lib/cache.c index fa2a1e7..a227723 100644 --- a/arch/arc/lib/cache.c +++ b/arch/arc/lib/cache.c @@ -6,6 +6,7 @@ #include config.h #include asm/arcregs.h +#include asm/cache.h /* Bit values in IC_CTRL */ #define IC_CTRL_CACHE_DISABLE (1 0) diff --git a/configs/axs101_defconfig b/configs/axs101_defconfig index 5c0ca11..d165e41 100644 --- a/configs/axs101_defconfig +++ b/configs/axs101_defconfig @@ -1,3 +1,5 @@ CONFIG_ARC=y CONFIG_TARGET_AXS101=y -CONFIG_SYS_CLK_FREQ=75000 \ No newline at end of file +CONFIG_SYS_CLK_FREQ=75000 +CONFIG_ARC_CACHE_LINE_SHIFT=5 +CONFIG_SYS_DCACHE_OFF=y \ No newline at end of file diff --git a/configs/tb100_defconfig b/configs/tb100_defconfig index d2de03b..e17a495 100644 --- a/configs/tb100_defconfig +++ b/configs/tb100_defconfig @@ -1,3 +1,4 @@ CONFIG_ARC=y CONFIG_TARGET_TB100=y -CONFIG_SYS_CLK_FREQ=5 \ No newline at end of file +CONFIG_SYS_CLK_FREQ=5 +CONFIG_ARC_CACHE_LINE_SHIFT=5 diff --git a/include/configs/arcangel4-be.h b/include/configs/arcangel4-be.h index a43590b..b0bc8bc 100644 --- a/include/configs/arcangel4-be.h +++ b/include/configs/arcangel4-be.h @@ -11,7 +11,6 @@ * CPU configuration */ #define CONFIG_SYS_BIG_ENDIAN -#define CONFIG_SYS_CACHELINE_SIZE 64 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ /* diff --git a/include/configs/arcangel4.h b/include/configs/arcangel4.h index 565f70e..3268c56 100644 --- a/include/configs/arcangel4.h +++ b/include/configs/arcangel4.h @@ -10,7 +10,6 @@ /* * CPU configuration */ -#define CONFIG_SYS_CACHELINE_SIZE 64 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ /* diff --git a/include/configs/axs101.h b/include/configs/axs101.h index b94687c..ff3fad3 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -10,12 +10,8 @@ /* * CPU configuration */ -#define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ -/* NAND controller DMA doesn't work correctly with D$ enabled */ -#define CONFIG_SYS_DCACHE_OFF - /* * Board configuration */ diff --git a/include/configs/tb100.h b/include/configs/tb100.h index f353950..32675c4 100644 --- a/include/configs/tb100.h +++ b/include/configs/tb100.h @@ -12,7 +12,6 @@ /* * CPU configuration */ -#define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ /* -- 2.1.0 ___ U-Boot mailing list
[U-Boot] [PATCH 06/12] arc: add selection of endianess in Kconfig
This change allows to keep board description clean and minimalistic. This is especially helpful if one board may house different CPUs with different features. It is applicable to both FPGA-based boards or those that have CPUs mounted on interchnagable daughter-boards. Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- arch/arc/Kconfig | 9 +++-- arch/arc/config.mk | 4 +- board/synopsys/Kconfig | 10 - board/synopsys/MAINTAINERS | 1 - configs/arcangel4-be_defconfig | 3 +- include/configs/arcangel4-be.h | 88 -- 6 files changed, 11 insertions(+), 104 deletions(-) delete mode 100644 include/configs/arcangel4-be.h diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 397b179..04fc7b6 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -47,6 +47,12 @@ config ARC_MMU_V3 endchoice +config CPU_BIG_ENDIAN + bool Enable Big Endian Mode + default n + help + Build kernel for Big Endian Mode of ARC CPU + config SYS_ICACHE_OFF bool Do not use Instruction Cache default n @@ -75,9 +81,6 @@ config TARGET_TB100 config TARGET_ARCANGEL4 bool Support arcangel4 -config TARGET_ARCANGEL4_BE - bool Support arcangel4-be - config TARGET_AXS101 bool Support axs101 diff --git a/arch/arc/config.mk b/arch/arc/config.mk index dd180ef..4f2d31f 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -4,8 +4,10 @@ # SPDX-License-Identifier: GPL-2.0+ # -ifndef CONFIG_SYS_BIG_ENDIAN +ifndef CONFIG_CPU_BIG_ENDIAN CONFIG_SYS_LITTLE_ENDIAN = 1 +else +CONFIG_SYS_BIG_ENDIAN = 1 endif ifdef CONFIG_SYS_LITTLE_ENDIAN diff --git a/board/synopsys/Kconfig b/board/synopsys/Kconfig index f614f88..8ab48cd 100644 --- a/board/synopsys/Kconfig +++ b/board/synopsys/Kconfig @@ -7,13 +7,3 @@ config SYS_CONFIG_NAME default arcangel4 endif - -if TARGET_ARCANGEL4_BE - -config SYS_VENDOR - default synopsys - -config SYS_CONFIG_NAME - default arcangel4-be - -endif diff --git a/board/synopsys/MAINTAINERS b/board/synopsys/MAINTAINERS index 720edd8..43114ce 100644 --- a/board/synopsys/MAINTAINERS +++ b/board/synopsys/MAINTAINERS @@ -3,5 +3,4 @@ M: Alexey Brodkin abrod...@synopsys.com S: Maintained F: include/configs/arcangel4.h F: configs/arcangel4_defconfig -F: include/configs/arcangel4-be.h F: configs/arcangel4-be_defconfig diff --git a/configs/arcangel4-be_defconfig b/configs/arcangel4-be_defconfig index 0c3ab4e..5d2e126 100644 --- a/configs/arcangel4-be_defconfig +++ b/configs/arcangel4-be_defconfig @@ -1,3 +1,4 @@ CONFIG_ARC=y -CONFIG_TARGET_ARCANGEL4_BE=y +CONFIG_TARGET_ARCANGEL4=y CONFIG_SYS_CLK_FREQ=7000 +CONFIG_CPU_BIG_ENDIAN=y diff --git a/include/configs/arcangel4-be.h b/include/configs/arcangel4-be.h deleted file mode 100644 index b0bc8bc..000 --- a/include/configs/arcangel4-be.h +++ /dev/null @@ -1,88 +0,0 @@ -/* - * Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved. - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -#ifndef _CONFIG_ARCANGEL4_H_ -#define _CONFIG_ARCANGEL4_H_ - -/* - * CPU configuration - */ -#define CONFIG_SYS_BIG_ENDIAN -#define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ - -/* - * Board configuration - */ -#define CONFIG_SYS_GENERIC_BOARD -#define CONFIG_SKIP_LOWLEVEL_INIT /* U-Boot is in RAM already */ - -#define CONFIG_ARCH_EARLY_INIT_R - -/* - * Memory configuration - */ -#define CONFIG_SYS_TEXT_BASE 0x8100 -#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE - -#define CONFIG_SYS_DDR_SDRAM_BASE 0x8000 -#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE -#define CONFIG_SYS_SDRAM_SIZE 0x1000 /* 256 Mb */ - -#define CONFIG_SYS_INIT_SP_ADDR\ - (CONFIG_SYS_SDRAM_BASE + 0x1000 - GENERATED_GBL_DATA_SIZE) - -#define CONFIG_SYS_MALLOC_LEN 0x20/* 2 MB */ -#define CONFIG_SYS_BOOTM_LEN 0x200 /* 32 MB */ -#define CONFIG_SYS_LOAD_ADDR 0x8200 - -#define CONFIG_SYS_NO_FLASH - -/* - * UART configuration - * - */ -#define CONFIG_ARC_SERIAL -#define CONFIG_ARC_UART_BASE 0xC0FC1000 -#define CONFIG_BAUDRATE115200 - -/* - * Command line configuration - */ -#include config_cmd_default.h - -#define CONFIG_CMD_ELF - -#define CONFIG_OF_LIBFDT - -#define CONFIG_AUTO_COMPLETE -#define CONFIG_SYS_MAXARGS 16 - -/* - * Environment settings - */ -#define CONFIG_ENV_IS_NOWHERE -#define CONFIG_ENV_SIZE0x00200 /* 512 bytes */ -#define CONFIG_ENV_OFFSET 0 - -/* - * Environment configuration - */ -#define CONFIG_BOOTDELAY 3 -#define CONFIG_BOOTFILEuImage -#define CONFIG_BOOTARGSconsole=ttyARC0,115200n8 -#define CONFIG_LOADADDRCONFIG_SYS_LOAD_ADDR - -/* - * Console
[U-Boot] [PATCH 09/12] arc: hard-code CONFIG_ARCH_EARLY_INIT_R in asm/config.h
Common arch_early_init_r() is used in arc/lib/cpu.c for all ARC boards so there's no sense in separate per-board definitions. Signed-off-by: Alexey Brodkin abrod...@synopsys.com --- arch/arc/include/asm/config.h | 1 + include/configs/arcangel4.h | 5 - include/configs/axs101.h | 5 - include/configs/tb100.h | 5 - 4 files changed, 1 insertion(+), 15 deletions(-) diff --git a/arch/arc/include/asm/config.h b/arch/arc/include/asm/config.h index c1e9b44..b4e9099 100644 --- a/arch/arc/include/asm/config.h +++ b/arch/arc/include/asm/config.h @@ -10,6 +10,7 @@ #define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_GENERIC_GLOBAL_DATA #define CONFIG_SYS_BOOT_RAMDISK_HIGH +#define CONFIG_ARCH_EARLY_INIT_R #define CONFIG_LMB diff --git a/include/configs/arcangel4.h b/include/configs/arcangel4.h index 003a45d..80d6438 100644 --- a/include/configs/arcangel4.h +++ b/include/configs/arcangel4.h @@ -13,11 +13,6 @@ #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ /* - * Board configuration - */ -#define CONFIG_ARCH_EARLY_INIT_R - -/* * Memory configuration */ #define CONFIG_SYS_TEXT_BASE 0x8100 diff --git a/include/configs/axs101.h b/include/configs/axs101.h index 4064ed2..e9a3231 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -12,11 +12,6 @@ */ #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ -/* - * Board configuration - */ -#define CONFIG_ARCH_EARLY_INIT_R - #define ARC_FPGA_PERIPHERAL_BASE 0xE000 #define ARC_APB_PERIPHERAL_BASE0xF000 #define ARC_DWMMC_BASE (ARC_FPGA_PERIPHERAL_BASE + 0x15000) diff --git a/include/configs/tb100.h b/include/configs/tb100.h index c6878fc..54eca6f 100644 --- a/include/configs/tb100.h +++ b/include/configs/tb100.h @@ -15,11 +15,6 @@ #define CONFIG_SYS_TIMER_RATE CONFIG_SYS_CLK_FREQ /* - * Board configuration - */ -#define CONFIG_ARCH_EARLY_INIT_R - -/* * Memory configuration */ #define CONFIG_SYS_TEXT_BASE 0x8400 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
