Support for HTKW mcx board
Subsystems (7)
v3 cover Support for HTKW mcx board
Hi All,
these patches introduce support for HTKW mcx board (AM3517-based) including DaVinci EMAC driver fixes to work on AM35xx, SPL fixes and OMAP3 EHCI support.
This is an updated version of previously posted patches:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/116535
Patches are rebased on the current master and no-op implementation for dcache operations on arm926ejs added.
PATCH v3 1/13 davinci_emac: move arch-independent defines to separate header
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs also. This patch moves common defines from arch-davinci/emac_defs.h to drivers/net/davinci_emac.h
DaVinci specific PHY drivers hacked to include the new header. We might want to switch to phylib in future.
--- arch/arm/cpu/arm926ejs/davinci/dp83848.c | 1 + arch/arm/cpu/arm926ejs/davinci/et1011c.c | 1 + arch/arm/cpu/arm926ejs/davinci/ksz8873.c | 1 + arch/arm/cpu/arm926ejs/davinci/lxt972.c | 1 + arch/arm/include/asm/arch-davinci/emac_defs.h | 289 ----------------------- drivers/net/davinci_emac.c | 1 + drivers/net/davinci_emac.h | 314 +++++++++++++++++++++++++ 7 files changed, 319 insertions(+), 289 deletions(-) create mode 100644 drivers/net/davinci_emac.h
arch/arm/cpu/arm926ejs/davinci/dp83848.c +1 -0
@@ -29,6 +29,7 @@#include <net.h> #include <dp83848.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h" #ifdef CONFIG_DRIVER_TI_EMAC
arch/arm/cpu/arm926ejs/davinci/et1011c.c +1 -0
@@ -22,6 +22,7 @@#include <net.h> #include <miiphy.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h" #ifdef CONFIG_DRIVER_TI_EMAC
arch/arm/cpu/arm926ejs/davinci/ksz8873.c +1 -0
@@ -36,6 +36,7 @@#include <net.h> #include <asm/arch/emac_defs.h> #include <asm/io.h> +#include "../../../../../drivers/net/davinci_emac.h" int ksz8873_is_phy_connected (int phy_addr) {
arch/arm/cpu/arm926ejs/davinci/lxt972.c +1 -0
@@ -30,6 +30,7 @@#include <miiphy.h> #include <lxt971a.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h" #ifdef CONFIG_DRIVER_TI_EMAC
arch/arm/include/asm/arch-davinci/emac_defs.h +0 -289
295 lines not on this page · raw message
drivers/net/davinci_emac.c +1 -0
@@ -43,6 +43,7 @@#include <malloc.h> #include <asm/arch/emac_defs.h> #include <asm/io.h> +#include "davinci_emac.h" unsigned int emac_dbg =0 ; #define debug_emac(fmt,args...) if (emac_dbg) printf(fmt,##args)
drivers/net/davinci_emac.h new file +314 -0
314 lines not on this page · raw message
Signature · 1 line
1.7.6.4
PATCH 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 8 lines · Ilya Yanok
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs also. This patch moves common defines from
arch-davinci/emac_defs.htodrivers/net/davinci_emac.hDaVinci specific PHY drivers hacked to include the new header. We might want to switch to phylib in future.
Signed-off-by Ilya Yanok <[email protected]>
I missed the 0/13 email but, patches 1 to 10 will be queued up into u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything about 12 (but it's delegated to someone else) and I've commented on
13. This should at least reduce the repost burden, thanks for all your patience here!
Signature · 1 line
Tom
PATCH v3 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 8 lines · Tom Rini
Quoted 7 lines · Ilya Yanok
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs also. This patch moves common defines from
arch-davinci/emac_defs.htodrivers/net/davinci_emac.hDaVinci specific PHY drivers hacked to include the new header. We might want to switch to phylib in future.
Quoted 7 lines
Quoted 1 line
Signed-off-by Ilya Yanok <[email protected]>I missed the 0/13 email but, patches 1 to 10 will be queued up into u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything about 12 (but it's delegated to someone else) and I've commented on
13. This should at least reduce the repost burden, thanks for all your patience here!
Good to hear, you are a co-custodian for u-boot-ti, I really like it, but... You should let patches hang a little on the list...
This version was published just 1.5 days ago...
You should let people look into this, otherwise, you can find yourself reapplying new versions or applying fixes to what could have been fixed...
Signature · 2 lines
Regards, Igor.
PATCH 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 17 lines · Igor Grinberg
Quoted 8 lines · Tom Rini
Quoted 7 lines · Ilya Yanok
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs also. This patch moves common defines from
arch-davinci/emac_defs.htodrivers/net/davinci_emac.hDaVinci specific PHY drivers hacked to include the new header. We might want to switch to phylib in future.
Quoted 7 lines
Quoted 1 line
Signed-off-by Ilya Yanok <[email protected]>I missed the 0/13 email but, patches 1 to 10 will be queued up into u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything about 12 (but it's delegated to someone else) and I've commented on
13. ?This should at least reduce the repost burden, thanks for all your patience here!
Quoted 3 lines
Good to hear, you are a co-custodian for u-boot-ti, I really like it, but... You should let patches hang a little on the list...
This version was published just 1.5 days ago...
True, but the changes you object to were around for a while longer than that. And really what needs to happen with this driver is switching to phylib (like the kernel version does).
Signature · 1 line
Tom
PATCH v3 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 18 lines · Tom Rini
Quoted 17 lines · Igor Grinberg
Quoted 15 lines · Tom Rini
Quoted 8 lines · Ilya Yanok
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs also. This patch moves common defines from
arch-davinci/emac_defs.htodrivers/net/davinci_emac.hDaVinci specific PHY drivers hacked to include the new header. We might want to switch to phylib in future.
Signed-off-by Ilya Yanok <[email protected]>I missed the 0/13 email but, patches 1 to 10 will be queued up into u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything about 12 (but it's delegated to someone else) and I've commented on
13. This should at least reduce the repost burden, thanks for all your patience here!
Quoted 7 lines
Quoted 3 lines
Good to hear, you are a co-custodian for u-boot-ti, I really like it, but... You should let patches hang a little on the list...
This version was published just 1.5 days ago...True, but the changes you object to were around for a while longer than that. And really what needs to happen with this driver is switching to phylib (like the kernel version does).
That is also true, I admit.
Meanwhile, shouldn't we make at least this one kind of clearer? Because, future intend is not an excuse for ugly code, right?
Signature · 2 lines
Regards, Igor.
PATCH 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 23 lines · Igor Grinberg
Quoted 22 lines · Tom Rini
Quoted 20 lines · Igor Grinberg
Quoted 8 lines · Tom Rini
Quoted 7 lines · Ilya Yanok
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs also. This patch moves common defines from
arch-davinci/emac_defs.htodrivers/net/davinci_emac.hDaVinci specific PHY drivers hacked to include the new header. We might want to switch to phylib in future.
Quoted 7 lines
Quoted 1 line
Signed-off-by Ilya Yanok <[email protected]>I missed the 0/13 email but, patches 1 to 10 will be queued up into u-boot-ti, Scott mentioned a problem with 11, I haven't seen anything about 12 (but it's delegated to someone else) and I've commented on
13. ?This should at least reduce the repost burden, thanks for all your patience here!Good to hear, you are a co-custodian for u-boot-ti, I really like it, but... You should let patches hang a little on the list...
This version was published just 1.5 days ago...
Quoted 7 lines
Quoted 3 lines
True, but the changes you object to were around for a while longer than that. ?And really what needs to happen with this driver is switching to phylib (like the kernel version does).
That is also true, I admit.
Meanwhile, shouldn't we make at least this one kind of clearer? Because, future intend is not an excuse for ugly code, right?
Relative includes are also relatively common. This wins on depth, true. Albert? Wolfgang? Is this "too ugly to live" and we need to fix it or live with it until we can switch to phylib?
Signature · 1 line
Tom
PATCH v3 1/13 davinci_emac: move arch-independent defines to separate header
In reply to Ilya YanokHi Ilya,
Quoted 24 lines · Ilya Yanok
DaVinci EMAC is found not only on DaVinci SoCs but on some OMAP3 SoCs also. This patch moves common defines from
arch-davinci/emac_defs.htodrivers/net/davinci_emac.hDaVinci specific PHY drivers hacked to include the new header. We might want to switch to phylib in future.
Signed-off-by Ilya Yanok <[email protected]>--- arch/arm/cpu/arm926ejs/davinci/dp83848.c | 1 + arch/arm/cpu/arm926ejs/davinci/et1011c.c | 1 + arch/arm/cpu/arm926ejs/davinci/ksz8873.c | 1 + arch/arm/cpu/arm926ejs/davinci/lxt972.c | 1 + arch/arm/include/asm/arch-davinci/emac_defs.h | 289 ----------------------- drivers/net/davinci_emac.c | 1 + drivers/net/davinci_emac.h | 314 +++++++++++++++++++++++++ 7 files changed, 319 insertions(+), 289 deletions(-) create mode 100644 drivers/net/davinci_emac.harch/arm/cpu/arm926ejs/davinci/dp83848.c +0
-0
arch/arm/cpu/arm926ejs/davinci/dp83848.c line 32
Quoted 4 lines
arch/arm/cpu/arm926ejs/davinci/dp83848.c +1
-0@@ -29,6 +29,7 @@#include <net.h> #include <dp83848.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h"
Doesn't this look terrible?
I'd suggest, to split the davinci_emac.h to driver private part (if there is) and to public part.
Then put the public part into the include/ directory - just as, for example, dm9000 does.
Other then that, the patch indeed good and very useful. Thanks.
[...]
arch/arm/cpu/arm926ejs/davinci/ksz8873.c line 39
Quoted 9 lines
arch/arm/cpu/arm926ejs/davinci/ksz8873.c +1
-0@@ -36,6 +36,7 @@#include <net.h> #include <asm/arch/emac_defs.h> #include <asm/io.h> +#include "../../../../../drivers/net/davinci_emac.h"
grrr..
arch/arm/cpu/arm926ejs/davinci/lxt972.c line 33
Quoted 12 lines
arch/arm/cpu/arm926ejs/davinci/ksz8873.c +0
-0int ksz8873_is_phy_connected (int phy_addr) {arch/arm/cpu/arm926ejs/davinci/lxt972.c +1
-0@@ -30,6 +30,7 @@#include <miiphy.h> #include <lxt971a.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h"
grrr..
[...]
drivers/net/davinci_emac.c line 46
Quoted 9 lines
drivers/net/davinci_emac.c +1
-0@@ -43,6 +43,7 @@#include <malloc.h> #include <asm/arch/emac_defs.h> #include <asm/io.h> +#include "davinci_emac.h"
then here, it will be both:
#include <davinci_emac.h>
#include "davinci_emac.h"
[...]
Signature · 2 lines
Regards, Igor.
PATCH v3 1/13 davinci_emac: move arch-independent defines to separate header
Hi Igor,
sorry for the late answer.
Quoted 11 lines · Igor Grinberg
arch/arm/cpu/arm926ejs/davinci/dp83848.c line 32
Quoted 9 lines
arch/arm/cpu/arm926ejs/davinci/dp83848.c +1
-0@@ -29,6 +29,7 @@#include <net.h> #include <dp83848.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h" Doesn't this look terrible?
Yes, it does. But this will be removed once someone will switch the driver to phylib.
Quoted 4 lines
I'd suggest, to split the
davinci_emac.hto driver private part (if there is) and to public part.
Then put the public part into theinclude/directory - just as, for example, dm9000 does.
Uh.. As for me, polluting the public includes is not very good idea as well. And again I think switching to phylib use is the right solution. This should be rather simple.
Regards, Ilya.
PATCH v3 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 17 lines · Ilya Yanok
Hi Igor,
sorry for the late answer.
Quoted 11 lines · Igor Grinberg
arch/arm/cpu/arm926ejs/davinci/dp83848.c line 32
Quoted 9 lines
arch/arm/cpu/arm926ejs/davinci/dp83848.c +1
-0@@ -29,6 +29,7 @@#include <net.h> #include <dp83848.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h" Doesn't this look terrible?
Quoted 2 lines
Yes, it does. But this will be removed once someone will switch the driver to phylib.
Hmmm... and who will be that someone?
Is it on someone's TODO list?
Quoted 8 lines
Quoted 5 lines
I'd suggest, to split the
davinci_emac.hto driver private part (if there is) and to public part.
Then put the public part into theinclude/directory - just as, for example, dm9000 does.Uh.. As for me, polluting the public includes is not very good idea as well.
Why is that? If you need the functionality used outside of the drivers/net directory, then I think it is the way.
To reduce the garbage in include/ it can be split into subdirs, so for example all network related .h files will reside in include/net/
Quoted 2 lines
And again I think switching to phylib use is the right solution. This should be rather simple.
Agreed, but if you still see this ugly thing in a year or so, it will mean that you just merged ugly code with hope that it will be fixed some day and it has been a year already, right?
Instead, my proposed solution will not prevent switching to phylib, but will still look better even if that someone (who supposed to do the switch) will not switch the driver to phylib. Unless, you want it to look ugly, so that someone will hurry up...
If it is so painful for you to use my proposed solution or you think it is worth than the current one, you can merge this. I don't really want to block it.
Signature · 2 lines
Regards, Igor.
PATCH 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 18 lines · Igor Grinberg
Quoted 17 lines · Ilya Yanok
Hi Igor,
sorry for the late answer.
Quoted 11 lines · Igor Grinberg
Quoted 9 lines
arch/arm/cpu/arm926ejs/davinci/dp83848.c +0
-0@@ -29,6 +29,7 @@?#include <
net.h>
?#include <dp83848.h>
?#include <asm/arch/emac_defs.h>
+#include "../../../../../drivers/net/davinci_emac.h"Doesn't this look terrible?
Quoted 5 lines
Quoted 2 lines
Yes, it does. But this will be removed once someone will switch the driver to phylib.
Hmmm... and who will be that someone?
Is it on someone's TODO list?
With my TI hat on, me.
Signature · 1 line
Tom
PATCH v3 1/13 davinci_emac: move arch-independent defines to separate header
Quoted 19 lines · Tom Rini
Quoted 18 lines · Igor Grinberg
Quoted 17 lines · Ilya Yanok
Hi Igor,
sorry for the late answer.
Quoted 11 lines · Igor Grinberg
arch/arm/cpu/arm926ejs/davinci/dp83848.c line 32
Quoted 9 lines
arch/arm/cpu/arm926ejs/davinci/dp83848.c +1
-0@@ -29,6 +29,7 @@#include <net.h> #include <dp83848.h> #include <asm/arch/emac_defs.h> +#include "../../../../../drivers/net/davinci_emac.h" Doesn't this look terrible?
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Yes, it does. But this will be removed once someone will switch the driver to phylib.
Hmmm... and who will be that someone?
Is it on someone's TODO list?With my TI hat on, me.
Hey, that's great to hear! :)
Signature · 2 lines
Regards, Igor.
PATCH v3 2/13 davinci_emac: use internal addresses in buffer descriptors
In reply to Ilya YanokOn AM35xx CPPI RAM had different addresses when accessed from the CPU and from the EMAC. We need to account this to deal with the buffer descriptors correctly.
--- drivers/net/davinci_emac.c | 39 ++++++++++++++++++++++++++++++--------- 1 files changed, 30 insertions(+), 9 deletions(-)
drivers/net/davinci_emac.c +30 -9
@@ -48,6 +48,27 @@unsigned int emac_dbg =0 ; #define debug_emac(fmt,args...) if (emac_dbg) printf(fmt,##args) +#ifdef EMAC_HW_RAM_ADDR +static inline unsigned long BD_TO_HW (unsigned long x) +{ +if (x ==0 ) +return 0 ; + +return x -EMAC_WRAPPER_RAM_ADDR +EMAC_HW_RAM_ADDR ; +} + +static inline unsigned long HW_TO_BD (unsigned long x) +{ +if (x ==0 ) +return 0 ; + +return x -EMAC_HW_RAM_ADDR +EMAC_WRAPPER_RAM_ADDR ; +} +#else +#define BD_TO_HW (x) (x) +#define HW_TO_BD (x) (x) +#endif +#ifdef DAVINCI_EMAC_GIG_ENABLE #define emac_gigabit_enable (phy_addr) davinci_eth_gigabit_enable(phy_addr)#else
@@ -448,7 +469,7 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis)/* Create RX queue and set receive process in place */ emac_rx_active_head = emac_rx_desc;for (cnt =0 ; cnt <EMAC_MAX_RX_BUFFERS ; cnt++) { - rx_desc->next = (u_int32_t)(rx_desc +1 ); + rx_desc->next =BD_TO_HW ((u_int32_t)(rx_desc +1 )); rx_desc->buffer = &emac_rx_buffers[cnt * (EMAC_MAX_ETHERNET_PKT_SIZE +EMAC_PKT_ALIGN )]; rx_desc->buff_off_len =EMAC_MAX_ETHERNET_PKT_SIZE ; rx_desc->pkt_flag_len =EMAC_CPPI_OWNERSHIP_BIT ;
@@ -501,7 +522,7 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis)emac_gigabit_enable (active_phy_addr[index]);/* Start receive process */ -writel ((u_int32_t )emac_rx_desc, &adap_emac->RX0HDP); +writel (BD_TO_HW ((u_int32_t )emac_rx_desc), &adap_emac->RX0HDP);debug_emac ("- emac_open\n" );
@@ -619,7 +640,7 @@ static int davinci_eth_send_packet (struct eth_device *dev,EMAC_CPPI_OWNERSHIP_BIT | EMAC_CPPI_EOP_BIT);/* Send the packet */ -writel ((unsigned long )emac_tx_desc, &adap_emac->TX0HDP); +writel (BD_TO_HW ((unsigned long )emac_tx_desc), &adap_emac->TX0HDP);/* Wait for packet to complete or link down */ while (1 ) {
@@ -663,14 +684,14 @@ static int davinci_eth_rcv_packet (struct eth_device *dev) }/* Ack received packet descriptor */ -writel ((unsigned long )rx_curr_desc, &adap_emac->RX0CP); +writel (BD_TO_HW ((ulong )rx_curr_desc), &adap_emac->RX0CP); curr_desc = rx_curr_desc; emac_rx_active_head = - (volatile emac_desc *) rx_curr_desc->next; + (volatile emac_desc *) (HW_TO_BD (rx_curr_desc->next));if (status &EMAC_CPPI_EOQ_BIT ) {if (emac_rx_active_head) { -writel ((unsigned long )emac_rx_active_head, +writel (BD_TO_HW ((ulong )emac_rx_active_head), &adap_emac->RX0HDP); }else { emac_rx_queue_active =0 ;
@@ -688,7 +709,7 @@ static int davinci_eth_rcv_packet (struct eth_device *dev) emac_rx_active_head = curr_desc; emac_rx_active_tail = curr_desc;if (emac_rx_queue_active !=0 ) { -writel ((unsigned long )emac_rx_active_head, +writel (BD_TO_HW ((ulong )emac_rx_active_head), &adap_emac->RX0HDP);printf ("INFO: emac_rcv_pkt: active queue head = 0, HDP fired\n" ); emac_rx_queue_active =1 ;
@@ -696,10 +717,10 @@ static int davinci_eth_rcv_packet (struct eth_device *dev) }else { tail_desc = emac_rx_active_tail; emac_rx_active_tail = curr_desc; - tail_desc->next = (unsigned int ) curr_desc; + tail_desc->next =BD_TO_HW ((ulong ) curr_desc); status = tail_desc->pkt_flag_len;if (status &EMAC_CPPI_EOQ_BIT ) { -writel ((unsigned long )curr_desc, +writel (BD_TO_HW ((ulong )curr_desc), &adap_emac->RX0HDP); status &= ~EMAC_CPPI_EOQ_BIT ; tail_desc->pkt_flag_len = status;
Signature · 1 line
1.7.6.4
PATCH v3 3/13 davinci_emac: conditionally compile specific PHY support
In reply to Ilya Yanok--- drivers/net/davinci_emac.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
drivers/net/davinci_emac.c +8 -0
@@ -803,6 +803,7 @@ int davinci_emac_initialize(void) phy_id |= tmp &0x0000ffff ;switch (phy_id) { +#ifdef PHY_KSZ8873 case PHY_KSZ8873 :sprintf (phy[i].name,"KSZ8873 @ 0x%02x" , active_phy_addr[i]);
@@ -811,6 +812,8 @@ int davinci_emac_initialize(void) phy[i].get_link_speed = ksz8873_get_link_speed; phy[i].auto_negotiate = ksz8873_auto_negotiate;break ; +#endif +#ifdef PHY_LXT972 case PHY_LXT972 :sprintf (phy[i].name,"LXT972 @ 0x%02x" , active_phy_addr[i]);
@@ -819,6 +822,8 @@ int davinci_emac_initialize(void) phy[i].get_link_speed = lxt972_get_link_speed; phy[i].auto_negotiate = lxt972_auto_negotiate;break ; +#endif +#ifdef PHY_DP83848 case PHY_DP83848 :sprintf (phy[i].name,"DP83848 @ 0x%02x" , active_phy_addr[i]);
@@ -827,6 +832,8 @@ int davinci_emac_initialize(void) phy[i].get_link_speed = dp83848_get_link_speed; phy[i].auto_negotiate = dp83848_auto_negotiate;break ; +#endif +#ifdef PHY_ET1011C case PHY_ET1011C :sprintf (phy[i].name,"ET1011C @ 0x%02x" , active_phy_addr[i]);
@@ -835,6 +842,7 @@ int davinci_emac_initialize(void) phy[i].get_link_speed = et1011c_get_link_speed; phy[i].auto_negotiate = gen_auto_negotiate;break ; +#endif default :sprintf (phy[i].name,"GENERIC @ 0x%02x" , active_phy_addr[i]);
Signature · 1 line
1.7.6.4
PATCH v3 4/13 arm926ejs: add noop implementation for dcache ops
In reply to Ilya YanokAdded noop implementation for dcache operations that will buzz about missing real implementation and disable the dcache. This fixes compilation of DaVinci EMAC driver on arm926ejs.
--- arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 75 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/cache.c
arch/arm/cpu/arm926ejs/Makefile +1 -1
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(CPU).o START = start.o -COBJS = cpu.o +COBJS = cpu.o cache.o ifdef CONFIG_SPL_BUILD ifdef CONFIG_SPL_NO_CPU_SUPPORT_CODE
arch/arm/cpu/arm926ejs/cache.c new file +75 -0
75 lines not on this page · raw message
Signature · 1 line
1.7.6.4
PATCH v3 5/13 davinci_emac: fix for running with dcache enabled
In reply to Ilya YanokDaVinci EMAC is present on TI AM35xx SoCs (ARMv7) which run with D-Cache enabled by default. So we have to take care and flush/invalidate the cache before/after the DMA operations.
Please note that the receive buffer alignment to 32 byte boundary comes from the old driver version I don't know if it is really needed or alignment to cache line size is enough.
--- drivers/net/davinci_emac.c | 41 +++++++++++++++++++++++++++++++++++++++-- drivers/net/davinci_emac.h | 5 +++-- 2 files changed, 42 insertions(+), 4 deletions(-)
drivers/net/davinci_emac.c +39 -2
@@ -41,6 +41,7 @@#include <net.h> #include <miiphy.h> #include <malloc.h> +#include <linux/compiler.h> #include <asm/arch/emac_defs.h> #include <asm/io.h> #include "davinci_emac.h"
@@ -105,7 +106,8 @@ static volatile emac_desc *emac_rx_active_tail = 0;static int emac_rx_queue_active =0 ;/* Receive packet buffers */ -static unsigned char emac_rx_buffers[EMAC_MAX_RX_BUFFERS * (EMAC_MAX_ETHERNET_PKT_SIZE +EMAC_PKT_ALIGN )]; +static unsigned char emac_rx_buffers[EMAC_MAX_RX_BUFFERS *EMAC_RXBUF_SIZE ] +__aligned(ARCH_DMA_MINALIGN) ;#ifndef CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT #define CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT 3
@@ -119,6 +121,26 @@ static u_int8_t num_phy;phy_t phy[CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT ]; +static inline void davinci_flush_rx_descs (void ) +{ +/* flush the whole RX descs area */ +flush_dcache_range (EMAC_WRAPPER_RAM_ADDR +EMAC_RX_DESC_BASE , +EMAC_WRAPPER_RAM_ADDR +EMAC_TX_DESC_BASE ); +} + +static inline void davinci_invalidate_rx_descs (void ) +{ +/* invalidate the whole RX descs area */ +invalidate_dcache_range (EMAC_WRAPPER_RAM_ADDR +EMAC_RX_DESC_BASE , +EMAC_WRAPPER_RAM_ADDR +EMAC_TX_DESC_BASE ); +} + +static inline void davinci_flush_desc (emac_desc *desc) +{ +flush_dcache_range ((unsigned long )desc, + (unsigned long )desc +sizeof (*desc)); +} +static int davinci_eth_set_mac_addr (struct eth_device *dev) {unsigned long mac_hi;
@@ -470,7 +492,7 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis) emac_rx_active_head = emac_rx_desc;for (cnt =0 ; cnt <EMAC_MAX_RX_BUFFERS ; cnt++) { rx_desc->next =BD_TO_HW ((u_int32_t)(rx_desc +1 )); - rx_desc->buffer = &emac_rx_buffers[cnt * (EMAC_MAX_ETHERNET_PKT_SIZE +EMAC_PKT_ALIGN )]; + rx_desc->buffer = &emac_rx_buffers[cnt *EMAC_RXBUF_SIZE ]; rx_desc->buff_off_len =EMAC_MAX_ETHERNET_PKT_SIZE ; rx_desc->pkt_flag_len =EMAC_CPPI_OWNERSHIP_BIT ; rx_desc++;
@@ -482,6 +504,8 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis) emac_rx_active_tail = rx_desc; emac_rx_queue_active =1 ; +davinci_flush_rx_descs (); +/* Enable TX/RX */ writel (EMAC_MAX_ETHERNET_PKT_SIZE , &adap_emac->RXMAXLEN);writel (0 , &adap_emac->RXBUFFEROFFSET);
@@ -639,6 +663,11 @@ static int davinci_eth_send_packet (struct eth_device *dev,EMAC_CPPI_SOP_BIT |EMAC_CPPI_OWNERSHIP_BIT | EMAC_CPPI_EOP_BIT); + +flush_dcache_range ((unsigned long )packet, + (unsigned long )packet + length); +davinci_flush_desc (emac_tx_desc); +/* Send the packet */ writel (BD_TO_HW ((unsigned long )emac_tx_desc), &adap_emac->TX0HDP);
@@ -671,6 +700,8 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)volatile emac_desc *tail_desc;int status, ret =-1 ; +davinci_invalidate_rx_descs (); + rx_curr_desc = emac_rx_active_head; status = rx_curr_desc->pkt_flag_len;if ((rx_curr_desc) && ((status &EMAC_CPPI_OWNERSHIP_BIT ) ==0 )) {
@@ -678,6 +709,9 @@ static int davinci_eth_rcv_packet (struct eth_device *dev)/* Error in packet - discard it and requeue desc */ printf ("WARN: emac_rcv_pkt: Error in packet\n" ); }else { +unsigned long tmp = (unsigned long )rx_curr_desc->buffer; + +invalidate_dcache_range (tmp, tmp +EMAC_RXBUF_SIZE );NetReceive (rx_curr_desc->buffer, (rx_curr_desc->buff_off_len &0xffff )); ret = rx_curr_desc->buff_off_len &0xffff ;
@@ -703,6 +737,7 @@ static int davinci_eth_rcv_packet (struct eth_device *dev) rx_curr_desc->buff_off_len =EMAC_MAX_ETHERNET_PKT_SIZE ; rx_curr_desc->pkt_flag_len =EMAC_CPPI_OWNERSHIP_BIT ; rx_curr_desc->next =0 ; +davinci_flush_desc (rx_curr_desc);if (emac_rx_active_head ==0 ) {printf ("INFO: emac_rcv_pkt: active queue head = 0\n" );
@@ -720,11 +755,13 @@ static int davinci_eth_rcv_packet (struct eth_device *dev) tail_desc->next =BD_TO_HW ((ulong ) curr_desc); status = tail_desc->pkt_flag_len;if (status &EMAC_CPPI_EOQ_BIT ) { +davinci_flush_desc (tail_desc);writel (BD_TO_HW ((ulong )curr_desc), &adap_emac->RX0HDP); status &= ~EMAC_CPPI_EOQ_BIT ; tail_desc->pkt_flag_len = status; } +davinci_flush_desc (tail_desc); }return (ret); }
drivers/net/davinci_emac.h +3 -2
@@ -24,8 +24,9 @@/* Ethernet Min/Max packet size */ #define EMAC_MIN_ETHERNET_PKT_SIZE 60#define EMAC_MAX_ETHERNET_PKT_SIZE 1518 -/* 1518 + 18 = 1536 (packet aligned on 32 byte boundry) */ -#define EMAC_PKT_ALIGN 18 +/* Buffer size (should be aligned on 32 byte and cache line) */ +#define EMAC_RXBUF_SIZE ALIGN(ALIGN(EMAC_MAX_ETHERNET_PKT_SIZE, 32),\ + ARCH_DMA_MINALIGN)/* Number of RX packet buffers * NOTE: Only 1 buffer supported as of now
Signature · 1 line
1.7.6.4
PATCH v3 6/13 davinci_emac: hardcode 100Mbps for AM35xx and RMII
In reply to Ilya YanokFor some reason code setting the speed based on the PHY feedback causes troubles on AM3517 so hardcode 100Mbps for now.
--- drivers/net/davinci_emac.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
drivers/net/davinci_emac.c +2 -1
@@ -520,7 +520,8 @@ static int davinci_eth_open(struct eth_device *dev, bd_t *bis)writel (1 , &adap_emac->RXUNICASTSET);/* Enable MII interface and Full duplex mode */ -#ifdef CONFIG_SOC_DA8XX +#if defined(CONFIG_SOC_DA8XX ) || \ + (defined(CONFIG_OMAP34XX ) && defined(CONFIG_DRIVER_TI_EMAC_USE_RMII )) writel((EMAC_MACCONTROL_MIIEN_ENABLE | EMAC_MACCONTROL_FULLDUPLEX_ENABLE | EMAC_MACCONTROL_RMIISPEED_100),
Signature · 1 line
1.7.6.4
PATCH v3 7/13 AM35xx: add EMAC support
In reply to Ilya YanokAM35xx has DaVinci-compatible EMAC.
--- arch/arm/cpu/armv7/omap3/Makefile | 1 + arch/arm/cpu/armv7/omap3/emac.c | 44 +++++++++++++++++++++ arch/arm/include/asm/arch-omap3/am35x_def.h | 3 + arch/arm/include/asm/arch-omap3/emac_defs.h | 56 +++++++++++++++++++++++++++ 4 files changed, 104 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap3/emac.c create mode 100644 arch/arm/include/asm/arch-omap3/emac_defs.h
arch/arm/cpu/armv7/omap3/Makefile +1 -0
@@ -32,6 +32,7 @@ COBJS += clock.o COBJS += mem.o COBJS += sys_info.o +COBJS-$(CONFIG_DRIVER_TI_EMAC) += emac.o COBJS-$(CONFIG_EMIF4) += emif4.o COBJS-$(CONFIG_SDRC) += sdrc.o
arch/arm/cpu/armv7/omap3/emac.c new file +44 -0
44 lines not on this page · raw message
arch/arm/include/asm/arch-omap3/am35x_def.h +3 -0
@@ -32,6 +32,9 @@#ifndef __KERNEL_STRICT_NAMES#ifndef __ASSEMBLY__ +/* IP_SW_RESET bits */ +#define CPGMACSS_SW_RST (1 << 1)/* reset CPGMAC */ +/* General register mappings of system control module */ #define AM35X_SCM_GEN_BASE 0x48002270 struct am35x_scm_general {
arch/arm/include/asm/arch-omap3/emac_defs.h new file +56 -0
56 lines not on this page · raw message
Signature · 1 line
1.7.6.4
PATCH v3 8/13 AM3517: move AM3517 specific mux defines to generic header
In reply to Ilya YanokAM3517 specific CONTROL_PADCONF_* defines moved from board-specific files to <asm/arch-omap3/mux.h>
--- arch/arm/include/asm/arch-omap3/mux.h | 41 +++++++++++++++++++++++++++++++++ board/logicpd/am3517evm/am3517evm.h | 40 -------------------------------- board/ti/am3517crane/am3517crane.h | 39 ------------------------------- 3 files changed, 41 insertions(+), 79 deletions(-)
arch/arm/include/asm/arch-omap3/mux.h +41 -0
@@ -404,6 +404,47 @@#define CONTROL_PADCONF_SDRC_CKE0 0x0262#define CONTROL_PADCONF_SDRC_CKE1 0x0264 +/* AM3517 specific mux configuration */ +#define CONTROL_PADCONF_SYS_NRESWARM 0x0A08 +/* CCDC */ +#define CONTROL_PADCONF_CCDC_PCLK 0x01E4 +#define CONTROL_PADCONF_CCDC_FIELD 0x01E6 +#define CONTROL_PADCONF_CCDC_HD 0x01E8 +#define CONTROL_PADCONF_CCDC_VD 0x01EA +#define CONTROL_PADCONF_CCDC_WEN 0x01EC +#define CONTROL_PADCONF_CCDC_DATA0 0x01EE +#define CONTROL_PADCONF_CCDC_DATA1 0x01F0 +#define CONTROL_PADCONF_CCDC_DATA2 0x01F2 +#define CONTROL_PADCONF_CCDC_DATA3 0x01F4 +#define CONTROL_PADCONF_CCDC_DATA4 0x01F6 +#define CONTROL_PADCONF_CCDC_DATA5 0x01F8 +#define CONTROL_PADCONF_CCDC_DATA6 0x01FA +#define CONTROL_PADCONF_CCDC_DATA7 0x01FC +/* RMII */ +#define CONTROL_PADCONF_RMII_MDIO_DATA 0x01FE +#define CONTROL_PADCONF_RMII_MDIO_CLK 0x0200 +#define CONTROL_PADCONF_RMII_RXD0 0x0202 +#define CONTROL_PADCONF_RMII_RXD1 0x0204 +#define CONTROL_PADCONF_RMII_CRS_DV 0x0206 +#define CONTROL_PADCONF_RMII_RXER 0x0208 +#define CONTROL_PADCONF_RMII_TXD0 0x020A +#define CONTROL_PADCONF_RMII_TXD1 0x020C +#define CONTROL_PADCONF_RMII_TXEN 0x020E +#define CONTROL_PADCONF_RMII_50MHZ_CLK 0x0210 +#define CONTROL_PADCONF_USB0_DRVBUS 0x0212 +/* CAN */ +#define CONTROL_PADCONF_HECC1_TXD 0x0214 +#define CONTROL_PADCONF_HECC1_RXD 0x0216 + +#define CONTROL_PADCONF_SYS_BOOT7 0x0218 +#define CONTROL_PADCONF_SDRC_DQS0N 0x021A +#define CONTROL_PADCONF_SDRC_DQS1N 0x021C +#define CONTROL_PADCONF_SDRC_DQS2N 0x021E +#define CONTROL_PADCONF_SDRC_DQS3N 0x0220 +#define CONTROL_PADCONF_STRBEN_DLY0 0x0222 +#define CONTROL_PADCONF_STRBEN_DLY1 0x0224 +#define CONTROL_PADCONF_SYS_BOOT8 0x0226 +#define MUX_VAL (OFFSET ,VALUE )\ writew((VALUE), OMAP34XX_CTRL_BASE + (OFFSET));
board/logicpd/am3517evm/am3517evm.h +0 -40
@@ -31,46 +31,6 @@ const omap3_sysinfo sysinfo = {"AM3517EVM Board" , "NAND", }; -/* AM3517 specific mux configuration */ -#define CONTROL_PADCONF_SYS_NRESWARM 0x0A08 -/* CCDC */ -#define CONTROL_PADCONF_CCDC_PCLK 0x01E4 -#define CONTROL_PADCONF_CCDC_FIELD 0x01E6 -#define CONTROL_PADCONF_CCDC_HD 0x01E8 -#define CONTROL_PADCONF_CCDC_VD 0x01EA -#define CONTROL_PADCONF_CCDC_WEN 0x01EC -#define CONTROL_PADCONF_CCDC_DATA0 0x01EE -#define CONTROL_PADCONF_CCDC_DATA1 0x01F0 -#define CONTROL_PADCONF_CCDC_DATA2 0x01F2 -#define CONTROL_PADCONF_CCDC_DATA3 0x01F4 -#define CONTROL_PADCONF_CCDC_DATA4 0x01F6 -#define CONTROL_PADCONF_CCDC_DATA5 0x01F8 -#define CONTROL_PADCONF_CCDC_DATA6 0x01FA -#define CONTROL_PADCONF_CCDC_DATA7 0x01FC -/* RMII */ -#define CONTROL_PADCONF_RMII_MDIO_DATA 0x01FE -#define CONTROL_PADCONF_RMII_MDIO_CLK 0x0200 -#define CONTROL_PADCONF_RMII_RXD0 0x0202 -#define CONTROL_PADCONF_RMII_RXD1 0x0204 -#define CONTROL_PADCONF_RMII_CRS_DV 0x0206 -#define CONTROL_PADCONF_RMII_RXER 0x0208 -#define CONTROL_PADCONF_RMII_TXD0 0x020A -#define CONTROL_PADCONF_RMII_TXD1 0x020C -#define CONTROL_PADCONF_RMII_TXEN 0x020E -#define CONTROL_PADCONF_RMII_50MHZ_CLK 0x0210 -#define CONTROL_PADCONF_USB0_DRVBUS 0x0212 -/* CAN */ -#define CONTROL_PADCONF_HECC1_TXD 0x0214 -#define CONTROL_PADCONF_HECC1_RXD 0x0216 - -#define CONTROL_PADCONF_SYS_BOOT7 0x0218 -#define CONTROL_PADCONF_SDRC_DQS0N 0x021A -#define CONTROL_PADCONF_SDRC_DQS1N 0x021C -#define CONTROL_PADCONF_SDRC_DQS2N 0x021E -#define CONTROL_PADCONF_SDRC_DQS3N 0x0220 -#define CONTROL_PADCONF_STRBEN_DLY0 0x0222 -#define CONTROL_PADCONF_STRBEN_DLY1 0x0224 -#define CONTROL_PADCONF_SYS_BOOT8 0x0226/* * IEN - Input Enable
board/ti/am3517crane/am3517crane.h +0 -39
@@ -30,45 +30,6 @@ const omap3_sysinfo sysinfo = {"CraneBoard" , "NAND", }; -/* AM3517 specific mux configuration */ -#define CONTROL_PADCONF_SYS_NRESWARM 0x0A08 -/* CCDC */ -#define CONTROL_PADCONF_CCDC_PCLK 0x01E4 -#define CONTROL_PADCONF_CCDC_FIELD 0x01E6 -#define CONTROL_PADCONF_CCDC_HD 0x01E8 -#define CONTROL_PADCONF_CCDC_VD 0x01EA -#define CONTROL_PADCONF_CCDC_WEN 0x01EC -#define CONTROL_PADCONF_CCDC_DATA0 0x01EE -#define CONTROL_PADCONF_CCDC_DATA1 0x01F0 -#define CONTROL_PADCONF_CCDC_DATA2 0x01F2 -#define CONTROL_PADCONF_CCDC_DATA3 0x01F4 -#define CONTROL_PADCONF_CCDC_DATA4 0x01F6 -#define CONTROL_PADCONF_CCDC_DATA5 0x01F8 -#define CONTROL_PADCONF_CCDC_DATA6 0x01FA -#define CONTROL_PADCONF_CCDC_DATA7 0x01FC -/* RMII */ -#define CONTROL_PADCONF_RMII_MDIO_DATA 0x01FE -#define CONTROL_PADCONF_RMII_MDIO_CLK 0x0200 -#define CONTROL_PADCONF_RMII_RXD0 0x0202 -#define CONTROL_PADCONF_RMII_RXD1 0x0204 -#define CONTROL_PADCONF_RMII_CRS_DV 0x0206 -#define CONTROL_PADCONF_RMII_RXER 0x0208 -#define CONTROL_PADCONF_RMII_TXD0 0x020A -#define CONTROL_PADCONF_RMII_TXD1 0x020C -#define CONTROL_PADCONF_RMII_TXEN 0x020E -#define CONTROL_PADCONF_RMII_50MHZ_CLK 0x0210 -#define CONTROL_PADCONF_USB0_DRVBUS 0x0212 -/* CAN */ -#define CONTROL_PADCONF_HECC1_TXD 0x0214 -#define CONTROL_PADCONF_HECC1_RXD 0x0216 -#define CONTROL_PADCONF_SYS_BOOT7 0x0218 -#define CONTROL_PADCONF_SDRC_DQS0N 0x021A -#define CONTROL_PADCONF_SDRC_DQS1N 0x021C -#define CONTROL_PADCONF_SDRC_DQS2N 0x021E -#define CONTROL_PADCONF_SDRC_DQS3N 0x0220 -#define CONTROL_PADCONF_STRBEN_DLY0 0x0222 -#define CONTROL_PADCONF_STRBEN_DLY1 0x0224 -#define CONTROL_PADCONF_SYS_BOOT8 0x0226/* * IEN - Input Enable
Signature · 1 line
1.7.6.4
PATCH v3 9/13 nand_spl_simple: add support for software ECC
In reply to Ilya YanokThis patch adds support for software ECC to the nand_spl_simple driver. To enable this one have to define CONFIG_SPL_NAND_SOFTECC.
Tested on OMAP3.
--- drivers/mtd/nand/nand_ecc.c | 2 +- drivers/mtd/nand/nand_spl_simple.c | 11 ++++++++++- 2 files changed, 11 insertions(+), 2 deletions(-)
drivers/mtd/nand/nand_ecc.c +1 -1
@@ -50,7 +50,7 @@* only nand_correct_data() is needed */ -#ifndef CONFIG_NAND_SPL +#if !defined(CONFIG_NAND_SPL ) || defined(CONFIG_SPL_NAND_SOFTECC )/* * Pre-calculated 256-way 1 byte column parity */
drivers/mtd/nand/nand_spl_simple.c +10 -1
@@ -21,6 +21,7 @@#include <common.h> #include <nand.h> #include <asm/io.h> +#include <linux/mtd/nand_ecc.h> static int nand_ecc_pos[] =CONFIG_SYS_NAND_ECCPOS ;static nand_info_t mtd;
@@ -204,7 +205,8 @@ static int nand_read_page(int block, int page, void *dst) oob_data = ecc_calc +0x200 ;for (i =0 ; eccsteps; eccsteps--, i += eccbytes, p += eccsize) { - this->ecc.hwctl (&mtd,NAND_ECC_READ ); +if (this->ecc.mode !=NAND_ECC_SOFT ) + this->ecc.hwctl (&mtd,NAND_ECC_READ ); this->read_buf (&mtd, p, eccsize); this->ecc.calculate (&mtd, p, &ecc_calc[i]); }
@@ -274,6 +276,13 @@ void nand_init(void) (void __iomem *)CONFIG_SYS_NAND_BASE ;board_nand_init (&nand_chip); +#ifdef CONFIG_SPL_NAND_SOFTECC +if (nand_chip.ecc.mode ==NAND_ECC_SOFT ) { + nand_chip.ecc.calculate = nand_calculate_ecc; + nand_chip.ecc.correct = nand_correct_data; + } +#endif +if (nand_chip.select_chip) nand_chip.select_chip (&mtd,0 ); }
Signature · 1 line
1.7.6.4
PATCH 9/13 nand_spl_simple: add support for software ECC
Quoted 10 lines · Ilya Yanok
This patch adds support for software ECC to the
nand_spl_simpledriver. To enable this one have to defineCONFIG_SPL_NAND_SOFTECC.Tested on OMAP3.
Signed-off-by Ilya Yanok <[email protected]>--- drivers/mtd/nand/nand_ecc.c | 2 +- drivers/mtd/nand/nand_spl_simple.c | 11 ++++++++++- 2 files changed, 11 insertions(+), 2 deletions(-)
-Scott
PATCH v3 10/13 omap_gpmc: use SOFTECC in SPL if it's enabled
In reply to Ilya YanokUse software ECC for the SPL build if support for software ECC in SPL is enabled.
--- drivers/mtd/nand/omap_gpmc.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
drivers/mtd/nand/omap_gpmc.c +3 -1
@@ -348,7 +348,7 @@ int board_nand_init(struct nand_chip *nand) nand->chip_delay =100 ;/* Default ECC mode */ -#ifndef CONFIG_SPL_BUILD +#if !defined(CONFIG_SPL_BUILD ) || defined(CONFIG_SPL_NAND_SOFTECC ) nand->ecc.mode =NAND_ECC_SOFT ;#else nand->ecc.mode =NAND_ECC_HW ;
@@ -359,7 +359,9 @@ int board_nand_init(struct nand_chip *nand) nand->ecc.correct = omap_correct_data; nand->ecc.calculate = omap_calculate_ecc;omap_hwecc_init (nand); +#endif +#ifdef CONFIG_SPL_BUILD if (nand->options &NAND_BUSWIDTH_16 ) nand->read_buf = nand_read_buf16;else
Signature · 1 line
1.7.6.4
PATCH 10/13 omap_gpmc: use SOFTECC in SPL if it's enabled
Quoted 7 lines · Ilya Yanok
Use software ECC for the SPL build if support for software ECC in SPL is enabled.
Signed-off-by Ilya Yanok <[email protected]>--- drivers/mtd/nand/omap_gpmc.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
-Scott
PATCH v3 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
In reply to Ilya YanokCurrently nand_spl_simple puts it's temp data at 0x10000 offset in SDRAM which is likely to contain already loaded data. I can't see any way to determine some safe address automagically so make it up to board porter to provide the safe-to-use address via CONFIG_SPL_NAND_WORKSPACE value.
--- drivers/mtd/nand/nand_spl_simple.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
drivers/mtd/nand/nand_spl_simple.c +6 -1
@@ -199,8 +199,13 @@ static int nand_read_page(int block, int page, void *dst)/* No malloc available for now, just use some temporary locations * in SDRAM +* Please provide some safe value for CONFIG_SPL_NAND_WORKSPACE in +* your board configuration, this is just a guess!! */ - ecc_calc = (u_char *)(CONFIG_SYS_SDRAM_BASE +0x10000 ); +#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x10000) +#endif + ecc_calc = (u_char *)CONFIG_SPL_NAND_WORKSPACE ; ecc_code = ecc_calc +0x100 ; oob_data = ecc_calc +0x200 ;
Signature · 1 line
1.7.6.4
PATCH 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
Quoted 19 lines · Ilya Yanok
Currently
nand_spl_simpleputs it's temp data at0x10000offset in SDRAM which is likely to contain already loaded data. I can't see any way to determine some safe address automagically so make it up to board porter to provide the safe-to-use address viaCONFIG_SPL_NAND_WORKSPACEvalue.Signed-off-by Ilya Yanok <[email protected]>--- drivers/mtd/nand/nand_spl_simple.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)drivers/mtd/nand/nand_spl_simple.c +1
-0@@ -199,8 +199,13 @@ static int nand_read_page(int block, int page, void *dst)/* No malloc available for now, just use some temporary locations * in SDRAM +* Please provide some safe value for CONFIG_SPL_NAND_WORKSPACE in
drivers/mtd/nand/nand_spl_simple.c static int nand_read_page(int block, int page, void *dst) · line 211
Quoted 10 lines
drivers/mtd/nand/nand_spl_simple.c +5
-1+* your board configuration, this is just a guess!! */ - ecc_calc = (u_char *)(CONFIG_SYS_SDRAM_BASE +0x10000 ); +#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x10000) +#endif + ecc_calc = (u_char *)CONFIG_SPL_NAND_WORKSPACE ; ecc_code = ecc_calc +0x100 ; oob_data = ecc_calc +0x200 ;
Please document this config symbol in README.
-Scott
PATCH v3 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
In reply to Ilya YanokHi Ilya,
Quoted 18 lines · Ilya Yanok
Currently
nand_spl_simpleputs it's temp data at0x10000offset in SDRAM which is likely to contain already loaded data. I can't see any way to determine some safe address automagically so make it up to board porter to provide the safe-to-use address viaCONFIG_SPL_NAND_WORKSPACEvalue.Signed-off-by Ilya Yanok <[email protected]>--- drivers/mtd/nand/nand_spl_simple.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)drivers/mtd/nand/nand_spl_simple.c +0
-0@@ -199,8 +199,13 @@ static int nand_read_page(int block, int page, void *dst)/* No malloc available for now, just use some temporary locations * in SDRAM
drivers/mtd/nand/nand_spl_simple.c static int nand_read_page(int block, int page, void *dst) · line 210
Quoted 10 lines
drivers/mtd/nand/nand_spl_simple.c +6
-1+* Please provide some safe value for CONFIG_SPL_NAND_WORKSPACE in +* your board configuration, this is just a guess!! */ - ecc_calc = (u_char *)(CONFIG_SYS_SDRAM_BASE +0x10000 ); +#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x10000) +#endif + ecc_calc = (u_char *)CONFIG_SPL_NAND_WORKSPACE ; ecc_code = ecc_calc +0x100 ; oob_data = ecc_calc +0x200 ;
If you change this, you probably should change also
the second version of this function (CONFIG_SYS_NAND_HW_ECC_OOBFIRST) or instead pass it as a parameter to the finction(s) from an upper layer.
Have you tried to use the stack as a buffer for those calculations?
Signature · 2 lines
Regards, Igor.
PATCH 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
In reply to Ilya Yanokdrivers/mtd/nand/nand_spl_simple.c
Quoted 12 lines · Ilya Yanok
Currently
nand_spl_simpleputs it's temp data at0x10000offset in SDRAM which is likely to contain already loaded data. I can't see any way to determine some safe address automagically so make it up to board porter to provide the safe-to-use address viaCONFIG_SPL_NAND_WORKSPACEvalue.Signed-off-by Ilya Yanok <[email protected]>--- drivers/mtd/nand/nand_spl_simple.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)drivers/mtd/nand/nand_spl_simple.c +0
-0
Hi Ilya,
drivers/mtd/nand/nand_spl_simple.c static int nand_read_page(int block, int page, void *dst) · line 207
Quoted 13 lines
drivers/mtd/nand/nand_spl_simple.c +5
-1@@ -199,8 +199,13 @@ static int nand_read_page(int block, int page, void *dst)/* No malloc available for now, just use some temporary locations * in SDRAM +* Please provide some safe value for CONFIG_SPL_NAND_WORKSPACE in +* your board configuration, this is just a guess!! */ - ecc_calc = (u_char *)(CONFIG_SYS_SDRAM_BASE +0x10000 ); +#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x10000) +#endif
Maybe it is better to not have a default value somewhere in the SDRAM and to get a compile error. If we do not want to fix also the related boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...).
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================
PATCH v3 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
Hi Stefano,
Quoted 6 lines · Stefano Babic
drivers/mtd/nand/nand_spl_simple.c static int nand_read_page(int block, int page, void *dst) · line 207
Quoted 3 lines
drivers/mtd/nand/nand_spl_simple.c +3
-0+#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x10000) +#endif Maybe it is better to not have a default value somewhere in the SDRAM and to get a compile error. If we do not want to fix also the related
My intention was not to break something as I can't fix every board using this driver. That's why I preserved the existing address for the case where CONFIG_SPL_NAND_WORKSPACE is not defined.
Quoted 3 lines
boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...).
Probably. Wolfgang, Scott, do you think we should add a warning here?
Regards, Ilya.
PATCH 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
Quoted 10 lines · Ilya Yanok
Hi Stefano,
Quoted 6 lines · Stefano Babic
drivers/mtd/nand/nand_spl_simple.c static int nand_read_page(int block, int page, void *dst) · line 207
Quoted 3 lines
drivers/mtd/nand/nand_spl_simple.c +3
-0+#ifndef CONFIG_SPL_NAND_WORKSPACE +#define CONFIG_SPL_NAND_WORKSPACE (CONFIG_SYS_SDRAM_BASE + 0x10000) +#endif Maybe it is better to not have a default value somewhere in the SDRAM and to get a compile error. If we do not want to fix also the related
Quoted 3 lines
My intention was not to break something as I can't fix every board using this driver. That's why I preserved the existing address for the case where
CONFIG_SPL_NAND_WORKSPACEis not defined.
How many boards are using the new SPL for NAND so far? It shouldn't be that bad to just fix them.
-Scott
PATCH 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
In reply to Ilya YanokDear Ilya Yanok,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 4 lines
boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...).
Probably. Wolfgang, Scott, do you think we should add a warning here?
How much space are we talking about? Can it be put on the stack?
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Lead me not into temptation... I can find it myself.
PATCH v3 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
Dear Wolfgang,
Quoted 7 lines · Wolfgang Denk
Quoted 5 lines
Quoted 3 lines
boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...).
Probably. Wolfgang, Scott, do you think we should add a warning here?
How much space are we talking about? Can it be put on the stack?
Well, currently the code uses 0x200 + CONFIG_SYS_NAND_OOBSIZE bytes but I think a lot of this space is unused. What we really need is CONFIG_SYS_NAND_ECCTOTAL + CONFIG_SYS_NAND_OOBSIZE. This is probably acceptable to put on the stack.
Regards, Ilya.
PATCH 11/13 nand_spl_simple: store temp data at CONFIG_SPL_NAND_WORKSPACE
In reply to Wolfgang DenkQuoted 4 lines · Wolfgang Denk
Dear Ilya Yanok,
Quoted 1 line · In message <[email protected]> you wrote:
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
boards, we could at least use a #warn message to advise at compile time that a default value is taken (and at the end, to force the board maintainers to fix it...).
Probably. Wolfgang, Scott, do you think we should add a warning here?
How much space are we talking about? Can it be put on the stack?
I think we are talking about 24 bytes, getting the value for CONFIG_SYS_NAND_ECCTOTAL in the configuration file.
Reading the code it is not clear to me why the computed ecc is stored in this way at a fixed offset in RAM - anybody knows why cannot we set a static char ecc_calc[] at the beginning of the nand_spl_simple.c file ?
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================
PATCH v3 12/13 ehci-omap: driver for EHCI host on OMAP3
In reply to Ilya YanokTaken from Beagle code. Tested on mcx board (AM3517-based).
--- board/ti/beagle/beagle.c | 101 -------------------------- drivers/usb/host/Makefile | 1 + drivers/usb/host/ehci-omap.c | 156 ++++++++++++++++++++++++++++++++++++++++ include/configs/omap3_beagle.h | 3 + 4 files changed, 160 insertions(+), 101 deletions(-) create mode 100644 drivers/usb/host/ehci-omap.c
board/ti/beagle/beagle.c +0 -101
@@ -40,15 +40,6 @@#include <asm/arch/sys_proto.h> #include <asm/gpio.h> #include <asm/mach-types.h> -#ifdef CONFIG_USB_EHCI -#include <usb.h> -#include <asm/arch/clocks.h> -#include <asm/arch/clocks_omap3.h> -#include <asm/arch/ehci_omap3.h> -/* from drivers/usb/host/ehci-core.h */ -extern struct ehci_hccr *hccr; -extern volatile struct ehci_hcor *hcor; -#endif #include "beagle.h" #include <command.h>
@@ -376,104 +367,12 @@ int board_mmc_init(bd_t *bis)#endif #ifdef CONFIG_USB_EHCI - -#define GPIO_PHY_RESET 147 - -/* Reset is needed otherwise the kernel-driver will throw an error. */ -int ehci_hcd_stop (void ) -{ -pr_debug ("Resetting OMAP3 EHCI\n" ); -gpio_set_value (GPIO_PHY_RESET ,0 ); -writel (OMAP_UHH_SYSCONFIG_SOFTRESET ,OMAP3_UHH_BASE +OMAP_UHH_SYSCONFIG ); -/* disable USB clocks */ -struct prcm *prcm_base = (struct prcm *)PRCM_BASE ; -sr32 (&prcm_base->iclken_usbhost,0 ,1 ,0 ); -sr32 (&prcm_base->fclken_usbhost,0 ,2 ,0 ); -sr32 (&prcm_base->iclken3_core,2 ,1 ,0 ); -sr32 (&prcm_base->fclken3_core,2 ,1 ,0 ); -return 0 ; -} -/* Call usb_stop() before starting the kernel */ void show_boot_progress (int val) {if (val ==15 )usb_stop (); } - -/* -* Initialize the OMAP3 EHCI controller and PHY on the BeagleBoard. -* Based on "drivers/usb/host/ehci-omap.c" from Linux 2.6.37. -* See there for additional Copyrights. -*/ -int ehci_hcd_init (void ) -{ -pr_debug ("Initializing OMAP3 ECHI\n" ); - -/* Put the PHY in RESET */ -gpio_request (GPIO_PHY_RESET ,"" ); -gpio_direction_output (GPIO_PHY_RESET ,0 ); -gpio_set_value (GPIO_PHY_RESET ,0 ); - -/* Hold the PHY in RESET for enough time till DIR is high */ -/* Refer: ISSUE1 */ -udelay (10 ); - -struct prcm *prcm_base = (struct prcm *)PRCM_BASE ; -/* Enable USBHOST_L3_ICLK (USBHOST_MICLK) */ -sr32 (&prcm_base->iclken_usbhost,0 ,1 ,1 ); -/* -* Enable USBHOST_48M_FCLK (USBHOST_FCLK1) -* and USBHOST_120M_FCLK (USBHOST_FCLK2) -*/ -sr32 (&prcm_base->fclken_usbhost,0 ,2 ,3 ); -/* Enable USBTTL_ICLK */ -sr32 (&prcm_base->iclken3_core,2 ,1 ,1 ); -/* Enable USBTTL_FCLK */ -sr32 (&prcm_base->fclken3_core,2 ,1 ,1 ); -pr_debug ("USB clocks enabled\n" ); - -/* perform TLL soft reset, and wait until reset is complete */ -writel (OMAP_USBTLL_SYSCONFIG_SOFTRESET , -OMAP3_USBTLL_BASE +OMAP_USBTLL_SYSCONFIG ); -/* Wait for TLL reset to complete */ -while (!(readl (OMAP3_USBTLL_BASE +OMAP_USBTLL_SYSSTATUS ) - &OMAP_USBTLL_SYSSTATUS_RESETDONE )); -pr_debug ("TLL reset done\n" ); - -writel (OMAP_USBTLL_SYSCONFIG_ENAWAKEUP | -OMAP_USBTLL_SYSCONFIG_SIDLEMODE | -OMAP_USBTLL_SYSCONFIG_CACTIVITY , -OMAP3_USBTLL_BASE +OMAP_USBTLL_SYSCONFIG ); - -/* Put UHH in NoIdle/NoStandby mode */ -writel (OMAP_UHH_SYSCONFIG_ENAWAKEUP - |OMAP_UHH_SYSCONFIG_SIDLEMODE - |OMAP_UHH_SYSCONFIG_CACTIVITY - |OMAP_UHH_SYSCONFIG_MIDLEMODE , -OMAP3_UHH_BASE +OMAP_UHH_SYSCONFIG ); - -/* setup burst configurations */ -writel (OMAP_UHH_HOSTCONFIG_INCR4_BURST_EN - |OMAP_UHH_HOSTCONFIG_INCR8_BURST_EN - |OMAP_UHH_HOSTCONFIG_INCR16_BURST_EN , -OMAP3_UHH_BASE +OMAP_UHH_HOSTCONFIG ); - -/* -* Refer ISSUE1: -* Hold the PHY in RESET for enough time till -* PHY is settled and ready -*/ -udelay (10 ); -gpio_set_value (GPIO_PHY_RESET ,1 ); - - hccr = (struct ehci_hccr *)(OMAP3_EHCI_BASE ); - hcor = (struct ehci_hcor *)(OMAP3_EHCI_BASE +0x10 ); - -pr_debug ("OMAP3 EHCI init done\n" ); -return 0 ; -} -#endif /* CONFIG_USB_EHCI */ /*
drivers/usb/host/Makefile +1 -0
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_USB_EHCI_FSL) += ehci-fsl.o endif COBJS-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o COBJS-$(CONFIG_USB_EHCI_MXS) += ehci-mxs.o +COBJS-$(CONFIG_USB_EHCI_OMAP) += ehci-omap.o COBJS-$(CONFIG_USB_EHCI_PPC4XX) += ehci-ppc4xx.o COBJS-$(CONFIG_USB_EHCI_IXP4XX) += ehci-ixp.o COBJS-$(CONFIG_USB_EHCI_KIRKWOOD) += ehci-kirkwood.o
drivers/usb/host/ehci-omap.c new file +156 -0
156 lines not on this page · raw message
include/configs/omap3_beagle.h +3 -0
@@ -133,6 +133,9 @@/* USB EHCI */ #define CONFIG_CMD_USB #define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_OMAP +/*#define CONFIG_EHCI_DCACHE*/ /* leave it disabled for now */ +#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 147#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3#define CONFIG_USB_HOST_ETHER #define CONFIG_USB_ETHER_SMSC95XX
Signature · 1 line
1.7.6.4
PATCH v3 13/13 mcx: support for HTKW mcx board
In reply to Ilya YanokThis patch adds support for the HTKW mcx AM3517-based board. Serial, Ethernet, NAND, MMC, RTC, EHCI USB host and both NAND and MMC SPLs are supported.
Requires updated mach-types file.
--- MAINTAINERS | 4 + board/htkw/mcx/Makefile | 38 +++++ board/htkw/mcx/mcx.c | 88 ++++++++++ board/htkw/mcx/mcx.h | 408 +++++++++++++++++++++++++++++++++++++++++++++++ boards.cfg | 1 + include/configs/mcx.h | 378 +++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 917 insertions(+), 0 deletions(-) create mode 100644 board/htkw/mcx/Makefile create mode 100644 board/htkw/mcx/mcx.c create mode 100644 board/htkw/mcx/mcx.h create mode 100644 include/configs/mcx.h
MAINTAINERS +4 -0
@@ -889,6 +889,10 @@ Richard Woodruff <[email protected]> omap2420h4 ARM1136EJS +Ilya Yanok <[email protected]> + + mcx ARM ARMV7 (AM35x SoC) + Syed Mohammed Khasim <[email protected]> Sughosh Ganu <[email protected]>
board/htkw/mcx/Makefile new file +38 -0
@@ -0,0 +1,38 @@ +# +# Copyright (C) 2011 Ilya Yanok, Emcraft Systems +# +# Based on ti/evm/Makefile +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc. +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).o + +COBJS := $(BOARD).o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB): $(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +######################################################################### + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend
board/htkw/mcx/mcx.c new file +88 -0
88 lines not on this page · raw message
board/htkw/mcx/mcx.h new file +408 -0
408 lines not on this page · raw message
boards.cfg +1 -0
@@ -194,6 +194,7 @@ omap3_evm_quick_mmc arm armv7 evm ti omap3_evm_quick_nand arm armv7 evm ti omap3 omap3_sdp3430 arm armv7 sdp3430 ti omap3 devkit8000 arm armv7 devkit8000 timll omap3 +mcx arm armv7 mcx htkw omap3 omap4_panda arm armv7 panda ti omap4 omap4_sdp4430 arm armv7 sdp4430 ti omap4 omap5_evm arm armv7 omap5_evm ti omap5
include/configs/mcx.h new file +378 -0
378 lines not on this page · raw message
Signature · 1 line
1.7.6.4
PATCH 13/13 mcx: support for HTKW mcx board
Quoted 3 lines · Ilya Yanok
This patch adds support for the HTKW mcx AM3517-based board. Serial, Ethernet, NAND, MMC, RTC, EHCI USB host and both NAND and MMC SPLs are supported.
[snip]
Quoted 2 lines
+#if
defined(CONFIG_GENERIC_MMC)&&defined(CONFIG_OMAP_HSMMC)&& \
+ ? ? ? !defined(CONFIG_SPL_BUILD)
OMAP_HSMMC requires GENERIC_MMC so just defined(CONFIG_OMAP_HSMMC) && !definedCONFIG_SPL_BUILD) like the rest is all that's needed.
[snip to config header]
Quoted 1 line
+#undef
CONFIG_USE_IRQ? ? ? ? ? ? ? ? ? ? ? ? ?/* no support for IRQs */
Should be removed, isn't used.
include/configs/mcx.h
Quoted 4 lines
include/configs/mcx.h new file +4
-0+/* +* DDR related +*/ +#define CONFIG_OMAP3_MICRON_DDR ? ? ? ? ? ? ? ? ? ? ? ?/* Micron DDR */
This is unused with SPL.
Quoted 2 lines
+#define
CONFIG_SYS_MAXARGS? ? ? ? ? ? 32 ? ? ?/* max number of command */
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* args */
Are you sure you don't just need 16 here? This is arguments to u-boot commands and not related to being able to pass in lots of stuff to the kernel via command line. (And yes, I know where you got this from, putting those to 16 is on my low hanging fruit list).
And from that same source you copy/pasted a few incorrect multiline comments (the /* ------... ones).
Review
Quoted 5 lines
(quoted diff) +5
-0+#define CONFIG_STACKSIZE ? ? ? (128 << 10) ? ? /* regular stack 128 KiB */ +#ifdef CONFIG_USE_IRQ +#define CONFIG_STACKSIZE_IRQ ? (4 << 10) ? ? ? /* IRQ stack 4 KiB */ +#define CONFIG_STACKSIZE_FIQ ? (4 << 10) ? ? ? /* FIQ stack 4 KiB */ +#endif
And given we don't define CONFIG_USE_IRQ..
Quoted 1 line
+#define
CONFIG_SPL_MAX_SIZE? ? ? ? ? ?0xB400 ?/* 45 K */
Better as (45 << 10).
Signature · 1 line
Tom
PATCH 13/13 mcx: support for HTKW mcx board
Quoted 3 lines
Quoted 1 line
+#define
CONFIG_SPL_MAX_SIZE? ? ? ? ? ?0xB400 ?/* 45 K */Better as (45 << 10).
Maybe 45 * 1024?
PATCH 13/13 mcx: support for HTKW mcx board
Quoted 5 lines · Andy Fleming
Quoted 3 lines
Quoted 1 line
+#define
CONFIG_SPL_MAX_SIZE? ? ? ? ? ?0xB400 ?/* 45 K */Better as (45 << 10).
Maybe 45 * 1024?
I swear I saw Wolfgang say (45 << 10) for another board (and we do N << 10 in other places in the config files) but either way.
Signature · 1 line
Tom
PATCH 13/13 mcx: support for HTKW mcx board
In reply to Andy FlemingDear Andy Fleming,
Quoted 5 lines · In message <CAKWjMd7_sXJxfJX=vVyYSXW8nv33PZfUCFSTeLCu7Qu-KnPSjQ@mail.gmail.com>…
Quoted 3 lines
Quoted 1 line
+#define
CONFIG_SPL_MAX_SIZE=A0 =A0 =A0 =A0 =A0 =A00xB400 =A0/* 45 K */Better as (45 << 10).
Maybe 45 * 1024?
Matter of taste... For KiB it makes not much difference, but for MiB a "45 << 20" is way easier to write and read than a "45 * 1024 * 1024".
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] The price of curiosity is a terminal experience. - Terry Pratchett, _The Dark Side of the Sun_
PATCH v3 13/13 mcx: support for HTKW mcx board
In reply to Ilya YanokSeveral comments in addition to Tom's comments below.
Quoted 19 lines · Ilya Yanok
This patch adds support for the HTKW mcx AM3517-based board. Serial, Ethernet, NAND, MMC, RTC, EHCI USB host and both NAND and MMC SPLs are supported.
Requires updated mach-types file.
Signed-off-by Ilya Yanok <[email protected]>--- MAINTAINERS | 4 + board/htkw/mcx/Makefile | 38 +++++ board/htkw/mcx/mcx.c | 88 ++++++++++ board/htkw/mcx/mcx.h | 408 +++++++++++++++++++++++++++++++++++++++++++++++ boards.cfg | 1 + include/configs/mcx.h | 378 +++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 917 insertions(+), 0 deletions(-) create mode 100644 board/htkw/mcx/Makefile create mode 100644 board/htkw/mcx/mcx.c create mode 100644 board/htkw/mcx/mcx.h create mode 100644 include/configs/mcx.h
[...]
Quoted 5 lines
board/htkw/mcx/mcx.c new file +0
-0
[...]
board/htkw/mcx/mcx.c line 50
Quoted 4 lines
board/htkw/mcx/mcx.c new file +4
-0+ +/* +* Routine: misc_init_r +* Description: Init i2c, ethernet, etc... (done here so udelay works)
Please, fix the comment.
Quoted 7 lines
+ */
board/htkw/mcx/mcx.c new file +6
-0+int misc_init_r (void ) +{ +dieid_num_r (); + +return 0 ; +}
[...]
board/htkw/mcx/mcx.c line 75
Quoted 6 lines
board/htkw/mcx/mcx.c new file +6
-0+#if defined(CONFIG_GENERIC_MMC ) && defined(CONFIG_OMAP_HSMMC ) && \ + !defined(CONFIG_SPL_BUILD ) +int board_mmc_init (bd_t *bis) +{ +omap_mmc_init (0 ); +return 0 ;
return omap_mmc_init(0);
I would also define this function ("weak") in some common place, so we will not need to copy/paste it all over the boards, but of course, it is not a blocker and I don't request this from you. Only if you want to... :-)
board/htkw/mcx/mcx.c line 84
Quoted 9 lines
board/htkw/mcx/mcx.c new file +9
-0+} +#endif + +#ifdef CONFIG_USB_EHCI_OMAP +#define USB_HOST_PWR_EN 132 +int board_usb_init (void ) +{ +gpio_request (USB_HOST_PWR_EN ,"USB_HOST_PWR_EN" ); +gpio_direction_output (USB_HOST_PWR_EN ,1 );
probably, you should check here for failure and
return the right value? may be printf something?
Quoted 4 lines
board/htkw/mcx/mcx.c new file +4
-0+ + return 0; +} +#endif
[...]
Signature · 2 lines
Regards, Igor.
PATCH v3 13/13 mcx: support for HTKW mcx board
Hi Igor,
thanks for your comments.
Quoted 9 lines · Igor Grinberg
board/htkw/mcx/mcx.c line 75
Quoted 6 lines
board/htkw/mcx/mcx.c new file +6
-0+#if defined(CONFIG_GENERIC_MMC ) && defined(CONFIG_OMAP_HSMMC ) && \ + !defined(CONFIG_SPL_BUILD ) +int board_mmc_init (bd_t *bis) +{ +omap_mmc_init (0 ); +return 0 ;return
omap_mmc_init(0);
Quoted 4 lines
I would also define this function ("weak") in some common place, so we will not need to copy/paste it all over the boards, but of course, it is not a blocker and I don't request this from you. Only if you want to... :-)
Well, we can use cpu_mmc_init() for this. But what slot(s) should we initialized in this common function? First? All?
Regards, Ilya.
PATCH 13/13 mcx: support for HTKW mcx board
Quoted 14 lines · Ilya Yanok
Hi Igor,
thanks for your comments.
Quoted 9 lines · Igor Grinberg
board/htkw/mcx/mcx.c
Quoted 6 lines
board/htkw/mcx/mcx.c new file +6
-0+#if defined(CONFIG_GENERIC_MMC ) && defined(CONFIG_OMAP_HSMMC ) && \ + ? ?!defined(CONFIG_SPL_BUILD) +int board_mmc_init (bd_t *bis) +{ + ? ?omap_mmc_init(0); + ? ?return 0;return
omap_mmc_init(0);
Quoted 7 lines
Quoted 4 lines
I would also define this function ("weak") in some common place, so we will not need to copy/paste it all over the boards, but of course, it is not a blocker and I don't request this from you. Only if you want to... :-)
Well, we can use
cpu_mmc_init()for this. But what slot(s) should we initialized in this common function? First? All?
The problem we have here is that board_mmc_init and cpu_mmc_init are already both weak and you can't replace one weak function with another weak function (or if you can, you need to play linker games). I had given this a quick stab but not reported back since I hadn't finished the rest of the related task (SPL and MMC support for am335x).
Signature · 1 line
Tom
PATCH v3 13/13 mcx: support for HTKW mcx board
Hi Tom,
Quoted 14 lines · Tom Rini
Quoted 14 lines
Quoted 13 lines
board/htkw/mcx/mcx.c line 75
Quoted 6 lines
board/htkw/mcx/mcx.c new file +6
-0+#if defined(CONFIG_GENERIC_MMC ) && defined(CONFIG_OMAP_HSMMC ) && \ + !defined(CONFIG_SPL_BUILD ) +int board_mmc_init (bd_t *bis) +{ +omap_mmc_init (0 ); +return 0 ;return
omap_mmc_init(0);I would also define this function ("weak") in some common place, so we will not need to copy/paste it all over the boards, but of course, it is not a blocker and I don't request this from you. Only if you want to... :-)
Quoted 8 lines
Quoted 2 lines
Well, we can use
cpu_mmc_init()for this. But what slot(s) should we initialized in this common function? First? All?The problem we have here is that
board_mmc_initandcpu_mmc_initare already both weak and you can't replace one weak function with another weak function (or if you can, you need to play linker games). I had given this a quick stab but not reported back since I hadn't finished the rest of the related task (SPL and MMC support for am335x).
I don't really understand the issue. We don't even have to play with the weak functions, generic MMC code already does this. We can just provide the cpu_mmc_init function for OMAPs (which we don't have at the moment). The only problem I can see is how to tell this cpu_mmc_init function which slots to initialize. Probably we could use some configuration defines for this.
Regards, Ilya.
PATCH 13/13 mcx: support for HTKW mcx board
Quoted 26 lines · Ilya Yanok
Hi Tom,
Quoted 14 lines · Tom Rini
Quoted 14 lines
Quoted 13 lines
board/htkw/mcx/mcx.c
Quoted 6 lines
board/htkw/mcx/mcx.c new file +6
-0+#if defined(CONFIG_GENERIC_MMC ) && defined(CONFIG_OMAP_HSMMC ) && \ + ? ?!defined(CONFIG_SPL_BUILD) +int board_mmc_init (bd_t *bis) +{ + ? ?omap_mmc_init(0); + ? ?return 0;return
omap_mmc_init(0);I would also define this function ("weak") in some common place, so we will not need to copy/paste it all over the boards, but of course, it is not a blocker and I don't request this from you. Only if you want to... :-)
Quoted 8 lines
Quoted 2 lines
Well, we can use
cpu_mmc_init()for this. But what slot(s) should we initialized in this common function? First? All?The problem we have here is that
board_mmc_initandcpu_mmc_initare already both weak and you can't replace one weak function with another weak function (or if you can, you need to play linker games). ?I had given this a quick stab but not reported back since I hadn't finished the rest of the related task (SPL and MMC support for am335x).
Quoted 6 lines
I don't really understand the issue. We don't even have to play with the weak functions, generic MMC code already does this. We can just provide the
cpu_mmc_initfunction for OMAPs (which we don't have at the moment). The only problem I can see is how to tell thiscpu_mmc_initfunction which slots to initialize. Probably we could use some configuration defines for this.
Ah, I hadn't been thinking of it that way. Perhaps a omap-common/mmc.c that tries and init's them all will do, but needs a lot of testing first. And a little bit of thinking to make sure the one interface case isn't ugly too (am33xx).
Signature · 1 line
Tom
v3 cover Support for HTKW mcx board
In reply to Ilya YanokHi Ilya,
Quoted 11 lines · Ilya Yanok
Hi All,
these patches introduce support for HTKW mcx board (AM3517-based) including DaVinci EMAC driver fixes to work on AM35xx, SPL fixes and OMAP3 EHCI support.
This is an updated version of previously posted patches:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/116535Patches are rebased on the current master and no-op implementation for dcache operations on arm926ejs added.
Please, add version history, next time, so it can be easily understood, what has been fixed and what hasn't been fixed. It makes a review of the new version much easier.
Also, if you use '--cover-letter' with git format-patch, you also get a nice diff stat, which can help identify, what files are involved.
Signature · 2 lines
Regards, Igor.
v3 cover Support for HTKW mcx board
Hi Igor,
Quoted 11 lines · Igor Grinberg
Quoted 9 lines
these patches introduce support for HTKW mcx board (AM3517-based) including DaVinci EMAC driver fixes to work on AM35xx, SPL fixes and OMAP3 EHCI support.
This is an updated version of previously posted patches:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/116535Patches are rebased on the current master and no-op implementation for dcache operations on arm926ejs added.
Please, add version history, next time, so it can be easily
Ok.
Quoted 2 lines
understood, what has been fixed and what hasn't been fixed. It makes a review of the new version much easier.
Actually I've addressed all comments during previous round. The only difference from V2 is added no-op cache functions for arm926ejs.
Quoted 2 lines
Also, if you use '--cover-letter' with git format-patch, you also get a nice diff stat, which can help identify, what files are involved.
Will do.
Thanks.
Regards, Ilya.
v3 cover Support for HTKW mcx board
Quoted 15 lines · Ilya Yanok
Hi Igor,
Quoted 11 lines · Igor Grinberg
Quoted 9 lines
these patches introduce support for HTKW mcx board (AM3517-based) including DaVinci EMAC driver fixes to work on AM35xx, SPL fixes and OMAP3 EHCI support.
This is an updated version of previously posted patches:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/116535Patches are rebased on the current master and no-op implementation for dcache operations on arm926ejs added.
Please, add version history, next time, so it can be easily
Quoted 7 lines
Ok.
Quoted 2 lines
understood, what has been fixed and what hasn't been fixed. It makes a review of the new version much easier.
Actually I've addressed all comments during previous round. The only difference from V2 is added no-op cache functions for arm926ejs.
Good!
IMO, having *all* versions history in each new version is more useful then just the incremental updates, but either way is better than nothing ;-) .
Quoted 11 lines
Quoted 3 lines
Also, if you use '--cover-letter' with git format-patch, you also get a nice diff stat, which can help identify, what files are involved.
Will do.
Thanks.
Regards, Ilya.
Signature · 2 lines
Regards, Igor.