[U-Boot] [U-boot] -mno-unaligned-access question
Hi, experts: I have a question about compiler option -mno-unaligned-access. Why not open -mno-unaligned-access compiler option globally by default when compiling u-boot? It seems if one driver needs to open it, should set it in Makefile individually: $(obj) tst/tst.o: CFLAGS += $(PLATFORM_NO_UNALIGNED) Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Executing U-Boot from Another Boot Loader
Hi, I have a VxWorks Boot Loader running on my P3041 and from there I'm willing to execute a U-Boot image that was previously burnt in my flash. The U-Boot image - u-boot-p3041ds-2011.09-r5.bin - is 512KB and is burnt at the address of 0xF802,, ending at 0xF809, (no env. parameters were burnt). So from the VxWorks Boot Loader I branch to the address of 0xF802, and get an exception. I also try branching to 0xF809,FFFC, but again the U-Boot shell won't show up. Could you please help me on that? Where can I find the U-Boot entry point and how should I load it manually? Thanks, Roy This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot mini-summit at ELCE 2013 in Edinburgh - call for participation!
Dear Jagan, On Thu, Mar 21, 2013 at 10:21 PM, Detlev Zundel d...@denx.de wrote: Hi fellow U-Boot developers, people meeting us at our booth at the Embedded World trade show in Nürnberg this year may already have heard rumours about it but now it is official - there will be an U-Boot mini-summit at the Emdedd Linux Conference Europe in Edinburgh, UK [1]. I am planning to attend...!! Excellent, I added you to the wiki page[1]. [...] Of course everybody is invited to suggest a presentation, but an informal poll turned up these topics of interest: - Driver model - Kconfig - Patman tutorial - U-Boot configuration through device tree - Falcon boot for everybody - DFU - Android fastboot Does anyone occupied Android fastboot? It seems you just did that ;) Is there any list that shows topics vs speakers?, if so please share. See the wiki page. Thanks Detlev [1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2013 -- Greenspun's Tenth Rule of Programming: Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Hi Fabio,
CC to Eric and Troy.
On 11/09/2013 23:14, Fabio Estevam wrote:
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index c832bd9..0f91fe2 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -313,7 +313,7 @@ int board_video_skip(void)
if (!panel) {
for (i = 0; i ARRAY_SIZE(displays); i++) {
struct display_info_t const *dev = displays+i;
- if (dev-detect(dev)) {
+ if (dev-detect dev-detect(dev)) {
The same should happen on the Nitrogen board. Should this fix extended
to the other boards using hdmi ?
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mx6sabresd: Reset counter to prevent error message
Hi Fabio,
On 11/09/2013 23:14, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
If a HDMI cable is not connected, the following message is seen on boot:
CPU: Freescale i.MX6Q rev1.1 at 792 MHz
Reset cause: POR
Board: MX6-SabreSD
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
No panel detected: default to HDMI
unsupported panel HDMI
Reset the 'i' variable to fix the 'unsupported panel' message.
This follows the same idea of commit 47ac53d7ae (imx:
nitrogen6x/mx6qsabrelite:
Fix bug in board_video_skip).
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 0f91fe2..61fe67c 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -322,6 +322,7 @@ int board_video_skip(void)
if (!panel) {
panel = displays[0].mode.name;
printf(No panel detected: default to %s\n, panel);
+ i = 0;
}
Robert sents the same fix for nitrogen6x, and it was integrated. The two
functions board_video_skip() are exactly the same. What about to
factorize the code putting it maybe in imx-common ?
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hello,
Going back to this old thread I have some news regarding the problem with TFTP
transmissions blocking (timed out) after 10 seconds on the FEC of the MX28.
See below:
On 07/17/2013 05:55 PM, Hector Palacios wrote:
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam feste...@gmail.com wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
hector.palac...@digi.com wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr} file100M'
in your EVK?
Yes, this is what I have been running since the beginning.
If it doesn't fail, could you try running it again after playing with
the environment (setting/printing some variables).
I can't reproduce the problem here.
As I said, this issue appeared with different TFTP servers and is
independent of whether the dcache is or not enabled.
Can you transfer from a PC to another PC via TFTP?
Yes I can.
Another thing of interest would be a 'tcpdump' pcap capture of that connection.
I was initially filtering out only TFTP packets of my wireshark trace and all
looked
correct. After taking a second look to the full trace I see now a hint.
Around 7 seconds after starting the TFTP transfer the server is sending an ARP
to the
target asking for the owner of the target's IP. The target is receiving this
ARP and
apparently responding (at least this is what my debug code shows as it gets into
arp.c:ArpReceive(), case ARPOP_REQUEST and sending a packet), but this ARP
reply from
the target is not reaching the network. My sniffer does not capture this reply.
The server resends the ARP request twice more (seconds 8 and 9) to the target
and
since it doesn't get a reply then sends a broadcast ARP (seconds 10) asking who
has
that IP. Since nobody responds it stops sending data.
The times that it works (and I don't know the magic behind using a numeric
address
versus using ${loadaddr} when they have the same value), the ARP replies do
reach the
network and the server continues the transmission normally.
Using a v2009 U-Boot, the behaviour is exactly the same, but the target's ARP
replies
always reach the network, and the transfers always succeed.
Since Fabio cannot reproduce it I guess it must be a local ghost. :o(
We tracked down the issue to an ARP request from the server that was never answered by
the target. We later noticed that the problem did not happen anymore when building
U-Boot with a different toolchain and that the issue seemed to be in the alignment of
the RX buffer in the stack, which old GCC compilers seem to do wrong.
Here is a patch:
From: Robert Hodaszi robert.hoda...@digi.com
Date: Fri, 6 Sep 2013 09:50:52 +0200
Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment because
of GCC bug
Older GCC versions don't handle well alignment on stack variables.
The temporary RX buffer is a local variable, so it is on the stack.
Because the FEC driver is using DMA for transmission, receive and
transmit buffers should be aligned on 64 byte. The transmit buffers are
not allocated in the driver internally, it sends the packets directly
as it gets them. So these packets should be aligned.
When the ARP layer wants to reply to an ARP request, it uses the FEC
driver's temporary RX buffer (used to pass data to the ARP layer) to
store the new packet, and pass it back to the FEC driver's send function.
Because of a GCC bug, this buffer is not aligned well, and when the
driver tries to send it, it first rounds the address down to the
alignment boundary. That causes invalid data.
To fix it, don't put the temporary onto the stack.
Signed-off-by: Robert Hodaszi robert.hoda...@digi.com
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/net/fec_mxc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index f4f72b7..315017e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -828,7 +828,10 @@ static int fec_recv(struct eth_device *dev)
uint16_t bd_status;
uint32_t addr, size, end;
int i;
- uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
+ /* Don't place this variable on the stack, because older GCC version
+* doesn't handle alignement on stack well.
+*/
+ static uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
/*
* Check if any critical events have happened
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: IGEP0033: Update timing to run DDR at 400MHz.
On Tue, Sep 10, 2013 at 11:12 AM, Enric Balletbo i Serra
eballe...@gmail.com wrote:
From: Enric Balletbo i Serra eballe...@iseebcn.com
We can run the DDR at 400MHz, so update the timings for that purpose.
Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com
---
arch/arm/include/asm/arch-am33xx/ddr_defs.h | 24
board/isee/igep0033/board.c | 4 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index 95f7a9a..fe48b5f 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -110,20 +110,20 @@
#define MT41J512M8RH125_IOCTRL_VALUE 0x18B
/* Samsung K4B2G1646E-BIH9 */
-#define K4B2G1646EBIH9_EMIF_READ_LATENCY 0x06
-#define K4B2G1646EBIH9_EMIF_TIM1 0x0888A39B
-#define K4B2G1646EBIH9_EMIF_TIM2 0x2A04011A
-#define K4B2G1646EBIH9_EMIF_TIM3 0x501F820F
-#define K4B2G1646EBIH9_EMIF_SDCFG 0x61C24AB2
-#define K4B2G1646EBIH9_EMIF_SDREF 0x093B
+#define K4B2G1646EBIH9_EMIF_READ_LATENCY 0x07
+#define K4B2G1646EBIH9_EMIF_TIM1 0x0AAAE51B
+#define K4B2G1646EBIH9_EMIF_TIM2 0x2A1D7FDA
+#define K4B2G1646EBIH9_EMIF_TIM3 0x501F83FF
+#define K4B2G1646EBIH9_EMIF_SDCFG 0x61C052B2
+#define K4B2G1646EBIH9_EMIF_SDREF 0x0C30
#define K4B2G1646EBIH9_ZQ_CFG 0x50074BE4
#define K4B2G1646EBIH9_DLL_LOCK_DIFF 0x1
-#define K4B2G1646EBIH9_RATIO 0x40
-#define K4B2G1646EBIH9_INVERT_CLKOUT 0x1
-#define K4B2G1646EBIH9_RD_DQS 0x3B
-#define K4B2G1646EBIH9_WR_DQS 0x85
-#define K4B2G1646EBIH9_PHY_FIFO_WE 0x100
-#define K4B2G1646EBIH9_PHY_WR_DATA 0xC1
+#define K4B2G1646EBIH9_RATIO 0x80
+#define K4B2G1646EBIH9_INVERT_CLKOUT 0x0
+#define K4B2G1646EBIH9_RD_DQS 0x35
+#define K4B2G1646EBIH9_WR_DQS 0x3A
+#define K4B2G1646EBIH9_PHY_FIFO_WE 0x97
+#define K4B2G1646EBIH9_PHY_WR_DATA 0x76
#define K4B2G1646EBIH9_IOCTRL_VALUE0x18B
/**
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index 9e91f68..a9c34c6 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -64,7 +64,7 @@ static struct emif_regs ddr3_emif_reg_data = {
#define OSC(V_OSCK/100)
const struct dpll_params dpll_ddr = {
- 303, OSC-1, 1, -1, -1, -1, -1};
+ 400, OSC-1, 1, -1, -1, -1, -1};
const struct dpll_params *get_dpll_ddr_params(void)
{
@@ -83,7 +83,7 @@ void set_mux_conf_regs(void)
void sdram_init(void)
{
- config_ddr(303, K4B2G1646EBIH9_IOCTRL_VALUE, ddr3_data,
+ config_ddr(400, K4B2G1646EBIH9_IOCTRL_VALUE, ddr3_data,
ddr3_cmd_ctrl_data, ddr3_emif_reg_data, 0);
}
#endif
--
1.8.1.2
Reviewed-by: Javier Martinez Canillas jav...@dowhile0.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v2] dfu: Extract common DFU code to handle dfu_alt_info environment variable
Dear Lukasz Majewski, New dfu_init_env_entities() function has been extracted from cmd_dfu.c and stored at dfu core. This is a dfu centric code, so it shall be processed in the core. Change-Id: I756c5de922fa31399d8804eaadc004ee98844ec2 Signed-off-by: Lukasz Majewski l.majew...@samsung.com Tested-by: Heiko Schocher h...@denx.de Applied, thanks! And sorry for the confusion! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problem with -pie flag.
Hi, I have a global variable problem with u-boot when i enabled with '-pie' flag during linking time. In the interrupt handler i set the global variable to 1 initially is set to 0 but i am not able to see the updated global variable after return from interrupt handler. But it is happen when i disabled the '-pie' flag. I have one more question on -pie flag. That is '-pie' flag produces the relative symbols for u-boot relocation support. Though i disabled the -pie flag i am able to relocate the code to the newer location successfully how it is possible. Note: I also checked with different tool chains of arm-none-eabi- Thanks balaji ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Hector Palacios,
Hello,
Going back to this old thread I have some news regarding the problem with
TFTP transmissions blocking (timed out) after 10 seconds on the FEC of the
MX28. See below:
On 07/17/2013 05:55 PM, Hector Palacios wrote:
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevam feste...@gmail.com
wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
hector.palac...@digi.com wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr}
file100M' in your EVK?
Yes, this is what I have been running since the beginning.
If it doesn't fail, could you try running it again after playing with
the environment (setting/printing some variables).
I can't reproduce the problem here.
As I said, this issue appeared with different TFTP servers and is
independent of whether the dcache is or not enabled.
Can you transfer from a PC to another PC via TFTP?
Yes I can.
Another thing of interest would be a 'tcpdump' pcap capture of that
connection.
I was initially filtering out only TFTP packets of my wireshark trace and
all looked correct. After taking a second look to the full trace I see
now a hint. Around 7 seconds after starting the TFTP transfer the server
is sending an ARP to the target asking for the owner of the target's IP.
The target is receiving this ARP and apparently responding (at least
this is what my debug code shows as it gets into arp.c:ArpReceive(),
case ARPOP_REQUEST and sending a packet), but this ARP reply from the
target is not reaching the network. My sniffer does not capture this
reply.
The server resends the ARP request twice more (seconds 8 and 9) to the
target and since it doesn't get a reply then sends a broadcast ARP
(seconds 10) asking who has that IP. Since nobody responds it stops
sending data.
The times that it works (and I don't know the magic behind using a
numeric address versus using ${loadaddr} when they have the same value),
the ARP replies do reach the network and the server continues the
transmission normally.
Using a v2009 U-Boot, the behaviour is exactly the same, but the target's
ARP replies always reach the network, and the transfers always succeed.
Since Fabio cannot reproduce it I guess it must be a local ghost. :o(
We tracked down the issue to an ARP request from the server that was never
answered by the target. We later noticed that the problem did not happen
anymore when building U-Boot with a different toolchain and that the issue
seemed to be in the alignment of the RX buffer in the stack, which old GCC
compilers seem to do wrong.
Here is a patch:
From: Robert Hodaszi robert.hoda...@digi.com
Date: Fri, 6 Sep 2013 09:50:52 +0200
Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment
because of GCC bug
Older GCC versions don't handle well alignment on stack variables.
The temporary RX buffer is a local variable, so it is on the stack.
Because the FEC driver is using DMA for transmission, receive and
transmit buffers should be aligned on 64 byte. The transmit buffers are
not allocated in the driver internally, it sends the packets directly
as it gets them. So these packets should be aligned.
When the ARP layer wants to reply to an ARP request, it uses the FEC
driver's temporary RX buffer (used to pass data to the ARP layer) to
store the new packet, and pass it back to the FEC driver's send function.
Because of a GCC bug
Can you point to this GCC bug in the GCC bugzilla or something?
this buffer is not aligned well, and when the
driver tries to send it, it first rounds the address down to the
alignment boundary. That causes invalid data.
To fix it, don't put the temporary onto the stack.
Signed-off-by: Robert Hodaszi robert.hoda...@digi.com
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/net/fec_mxc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index f4f72b7..315017e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -828,7 +828,10 @@ static int fec_recv(struct eth_device *dev)
uint16_t bd_status;
uint32_t addr, size, end;
int i;
- uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
+ /* Don't place this variable on the stack, because older GCC
version +* doesn't handle alignement on stack well.
+*/
+ static uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
The buffer might as well be allocated using ALLOC_CACHE_ALIGN_BUFFER() from
include/common.h . Still, are you _really_ sure the buffer is unaligned ? Do
you
have a testcase maybe ?
btw. I am able to replicate this issue sometimes even using GCC 4.8.0 .
Best regards,
Marek Vasut
___
U-Boot mailing
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Robert Hodaszi, html head meta content=text/html; charset=ISO-8859-1 http-equiv=Content-Type /head body bgcolor=#FF text=#00 div class=moz-cite-prefixHi,br br There are a lot of bug announcement, just make a search:br meta http-equiv=content-type content=text/html; charset=ISO-8859-1 a href=http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721;http://gcc.gnu.or g/bugzilla/show_bug.cgi?id=33721/abr meta http-equiv=content-type content=text/html; charset=ISO-8859-1 a href=http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660;http://gcc.gnu.or g/bugzilla/show_bug.cgi?id=16660/abr br Also, I printed out the buffer addresses, and that temporary RX buffer was not aligned. So the transmit function rounded it down to the alignment boundary, and so caused invalid data transmission. (By the way. Shouldn't the transmit function check whether the alignment is proper, and throw an error message, instead of round it down? That would make more sense.)br div class=moz-signaturebr Best regards,br Robert Hodaszi /div br On 2013-09-12 12:50, Marek Vasut wrote:br /div blockquote cite=mid:201309121250.36579.ma...@denx.de type=cite pre wrap=Dear Hector Palacios, [...] Sorry, I cannot decode this. Can you please send plain-text emails? Thank you Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/usb:Differentiate USB controller base address
Introduce different macros for storing addresses of multiple
USB controllers. This is required for successful initialization
and usage of multiple USB controllers inside u-boot
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
arch/powerpc/cpu/mpc83xx/cpu_init.c | 2 +-
arch/powerpc/include/asm/immap_512x.h | 6 +++---
arch/powerpc/include/asm/immap_83xx.h | 18 --
arch/powerpc/include/asm/immap_85xx.h | 9 +
drivers/usb/host/ehci-fsl.c | 15 +--
drivers/usb/host/ehci-mpc512x.c | 4 ++--
include/usb/ehci-fsl.h| 13 ++---
7 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index d568f88..d9b6e47 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
@@ -315,7 +315,7 @@ void cpu_init_f (volatile immap_t * im)
#endif
#if defined(CONFIG_USB_EHCI_FSL) defined(CONFIG_MPC831x)
uint32_t temp;
- struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
+ struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB1_ADDR;
/* Configure interface. */
setbits_be32(ehci-control, REFSEL_16MHZ | UTMI_PHY_EN);
diff --git a/arch/powerpc/include/asm/immap_512x.h
b/arch/powerpc/include/asm/immap_512x.h
index 01c9eff..dc655aa 100644
--- a/arch/powerpc/include/asm/immap_512x.h
+++ b/arch/powerpc/include/asm/immap_512x.h
@@ -1255,9 +1255,9 @@ static inline u32 get_pata_base (void)
}
#endif /* __ASSEMBLY__ */
-#define CONFIG_SYS_MPC512x_USB_OFFSET 0x4000
-#define CONFIG_SYS_MPC512x_USB_ADDR \
- (CONFIG_SYS_IMMR + CONFIG_SYS_MPC512x_USB_OFFSET)
+#define CONFIG_SYS_MPC512x_USB1_OFFSET 0x4000
+#define CONFIG_SYS_MPC512x_USB1_ADDR \
+ (CONFIG_SYS_IMMR + CONFIG_SYS_MPC512x_USB1_OFFSET)
#define IIM_BASE_ADDR (CONFIG_SYS_IMMR + offsetof(immap_t, iim))
diff --git a/arch/powerpc/include/asm/immap_83xx.h
b/arch/powerpc/include/asm/immap_83xx.h
index 57189c9..3c86ff6 100644
--- a/arch/powerpc/include/asm/immap_83xx.h
+++ b/arch/powerpc/include/asm/immap_83xx.h
@@ -764,9 +764,11 @@ typedef struct immap {
} immap_t;
#ifdef CONFIG_HAS_FSL_MPH_USB
-#define CONFIG_SYS_MPC83xx_USB_OFFSET 0x22000 /* use the MPH controller */
+#define CONFIG_SYS_MPC83xx_USB1_OFFSET 0x22000/* use the MPH
controller */
+#define CONFIG_SYS_MPC83xx_USB2_OFFSET 0
#else
-#define CONFIG_SYS_MPC83xx_USB_OFFSET 0x23000 /* use the DR controller */
+#define CONFIG_SYS_MPC83xx_USB1_OFFSET 0
+#define CONFIG_SYS_MPC83xx_USB2_OFFSET 0x23000/* use the DR
controller */
#endif
#elif defined(CONFIG_MPC8313)
@@ -1031,11 +1033,15 @@ typedef struct immap {
#define CONFIG_SYS_MPC83xx_ESDHC_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_MPC83xx_ESDHC_OFFSET)
-#ifndef CONFIG_SYS_MPC83xx_USB_OFFSET
-#define CONFIG_SYS_MPC83xx_USB_OFFSET 0x23000
+#ifndef CONFIG_SYS_MPC83xx_USB1_OFFSET
+#define CONFIG_SYS_MPC83xx_USB1_OFFSET 0x23000
+#endif
+#define CONFIG_SYS_MPC83xx_USB1_ADDR \
+ (CONFIG_SYS_IMMR + CONFIG_SYS_MPC83xx_USB1_OFFSET)
+#if defined(CONFIG_MPC834x)
+#define CONFIG_SYS_MPC83xx_USB2_ADDR \
+ (CONFIG_SYS_IMMR + CONFIG_SYS_MPC83xx_USB2_OFFSET)
#endif
-#define CONFIG_SYS_MPC83xx_USB_ADDR \
- (CONFIG_SYS_IMMR + CONFIG_SYS_MPC83xx_USB_OFFSET)
#define CONFIG_SYS_LBC_ADDR (((immap_t *)CONFIG_SYS_IMMR)-im_lbc)
#define CONFIG_SYS_TSEC1_OFFSET0x24000
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 3a10d77..147ce4f 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -2938,7 +2938,6 @@ struct ccsr_pman {
#endif
#define CONFIG_SYS_MPC85xx_USB1_OFFSET 0x21
#define CONFIG_SYS_MPC85xx_USB2_OFFSET 0x211000
-#define CONFIG_SYS_MPC85xx_USB_OFFSET CONFIG_SYS_MPC85xx_USB1_OFFSET
#define CONFIG_SYS_MPC85xx_USB1_PHY_OFFSET 0x214000
#define CONFIG_SYS_MPC85xx_USB2_PHY_OFFSET 0x214100
#define CONFIG_SYS_MPC85xx_SATA1_OFFSET0x22
@@ -2991,7 +2990,7 @@ struct ccsr_pman {
#define CONFIG_SYS_MPC85xx_IFC_OFFSET 0x1e000
#define CONFIG_SYS_MPC85xx_L2_OFFSET 0x2
#define CONFIG_SYS_MPC85xx_DMA_OFFSET 0x21000
-#define CONFIG_SYS_MPC85xx_USB_OFFSET 0x22000
+#define CONFIG_SYS_MPC85xx_USB1_OFFSET 0x22000
#define CONFIG_SYS_MPC85xx_USB2_OFFSET 0x23000
#ifdef CONFIG_TSECV2
#define CONFIG_SYS_TSEC1_OFFSET0xB
@@ -3092,8 +3091,10 @@ struct ccsr_pman {
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_CORENET_SERDES_OFFSET)
#define CONFIG_SYS_FSL_CORENET_SERDES2_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_CORENET_SERDES2_OFFSET)
-#define CONFIG_SYS_MPC85xx_USB_ADDR \
- (CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_USB_OFFSET)
[U-Boot] [PATCH 1/2] powerpc/usb:Define CONFIG_USB_MAX_CONTROLLER_COUNT for all 85xx socs
CONFIG_USB_MAX_CONTROLLER_COUNT macro recently defined for
initializing all USB controllers on a given platform. This
macro is defined for all 85xx socs
Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/fdt.c| 6 --
arch/powerpc/include/asm/config_mpc85xx.h | 24
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index eb7cbbc..9273745 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -15,7 +15,9 @@
#include phy.h
#include hwconfig.h
-#define FSL_MAX_NUM_USB_CTRLS 2
+#ifndef CONFIG_USB_MAX_CONTROLLER_COUNT
+#define CONFIG_USB_MAX_CONTROLLER_COUNT1
+#endif
#if defined(CONFIG_MP) (defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx))
static int ft_del_cpuhandle(void *blob, int cpuhandle)
@@ -128,7 +130,7 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
char str[5];
int i, j;
- for (i = 1; i = FSL_MAX_NUM_USB_CTRLS; i++) {
+ for (i = 1; i = CONFIG_USB_MAX_CONTROLLER_COUNT; i++) {
int mode_idx = -1, phy_idx = -1;
snprintf(str, 5, %s%d, usb, i);
if (hwconfig(str)) {
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index 15e44de..b395e1c 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -127,6 +127,7 @@
#define CONFIG_SYS_FSL_SEC_COMPAT 4
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_NUM_DDR_CONTROLLERS 1
+#define CONFIG_USB_MAX_CONTROLLER_COUNT1
#define CONFIG_SYS_FSL_IFC_BANK_COUNT 4
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_PCIE_COMPAT fsl,qoriq-pcie-v2.2
@@ -146,6 +147,7 @@
#define CONFIG_TSECV2
#define CONFIG_FSL_PCIE_DISABLE_ASPM
#define CONFIG_SYS_FSL_SEC_COMPAT 2
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
@@ -154,6 +156,7 @@
#elif defined(CONFIG_P1012)
#define CONFIG_MAX_CPUS1
#define CONFIG_SYS_FSL_NUM_LAWS12
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
#define CONFIG_SYS_PPC_E500_DEBUG_TLB 2
#define CONFIG_TSECV2
#define CONFIG_FSL_PCIE_DISABLE_ASPM
@@ -169,6 +172,7 @@
#elif defined(CONFIG_P1013)
#define CONFIG_MAX_CPUS1
#define CONFIG_SYS_FSL_NUM_LAWS12
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
#define CONFIG_SYS_PPC_E500_DEBUG_TLB 2
#define CONFIG_TSECV2
#define CONFIG_SYS_FSL_SEC_COMPAT 2
@@ -186,6 +190,7 @@
#define CONFIG_SYS_FSL_SEC_COMPAT 4
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_NUM_DDR_CONTROLLERS 1
+#define CONFIG_USB_MAX_CONTROLLER_COUNT1
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
#define CONFIG_SYS_FSL_ERRATUM_IFC_A002769
@@ -200,6 +205,7 @@
#define CONFIG_SYS_NUM_FMAN1
#define CONFIG_SYS_NUM_FM1_DTSEC 2
#define CONFIG_NUM_DDR_CONTROLLERS 1
+#define CONFIG_USB_MAX_CONTROLLER_COUNT1
#define CONFIG_SYS_QMAN_NUM_PORTALS3
#define CONFIG_SYS_BMAN_NUM_PORTALS3
#define CONFIG_SYS_FM_MURAM_SIZE 0x1
@@ -216,6 +222,7 @@
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
#elif defined(CONFIG_P1021)
#define CONFIG_MAX_CPUS2
@@ -230,6 +237,7 @@
#define QE_MURAM_SIZE 0x6000UL
#define MAX_QE_RISC1
#define QE_NUM_OF_SNUM 28
+#define CONFIG_USB_MAX_CONTROLLER_COUNT1
#elif defined(CONFIG_P1022)
#define CONFIG_MAX_CPUS2
@@ -237,6 +245,7 @@
#define CONFIG_SYS_PPC_E500_DEBUG_TLB 2
#define CONFIG_TSECV2
#define CONFIG_SYS_FSL_SEC_COMPAT 2
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
@@ -249,6 +258,7 @@
#define CONFIG_SYS_NUM_FMAN1
#define CONFIG_SYS_NUM_FM1_DTSEC 2
#define CONFIG_NUM_DDR_CONTROLLERS 1
+#define CONFIG_USB_MAX_CONTROLLER_COUNT1
#define CONFIG_SYS_QMAN_NUM_PORTALS3
#define CONFIG_SYS_BMAN_NUM_PORTALS3
#define CONFIG_SYS_FM_MURAM_SIZE 0x1
@@ -265,6 +275,7 @@
#define CONFIG_TSECV2
#define CONFIG_FSL_PCIE_DISABLE_ASPM
#define CONFIG_SYS_FSL_SEC_COMPAT 2
+#define CONFIG_USB_MAX_CONTROLLER_COUNT2
#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
@@ -273,6 +284,7 @@
#elif defined(CONFIG_P1025)
#define
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi,
Sorry, hopefully that will be a plain-text.
There are a lot of bug announcement, just make a search:
gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Also, I printed out the buffer addresses, and that temporary RX buffer
was not aligned. So the transmit function rounded it down to the
alignment boundary, and so caused invalid data transmission. (By the
way. Shouldn't the transmit function check whether the alignment is
proper, and throw an error message, instead of round it down? That would
make more sense.)
Best regards,
Robert Hodaszi
On 2013-09-12 12:50, Marek Vasut wrote:
Dear Hector Palacios,
Hello,
Going back to this old thread I have some news regarding the problem with
TFTP transmissions blocking (timed out) after 10 seconds on the FEC of the
MX28. See below:
On 07/17/2013 05:55 PM, Hector Palacios wrote:
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevamfeste...@gmail.com
wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
hector.palac...@digi.com wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr}
file100M' in your EVK?
Yes, this is what I have been running since the beginning.
If it doesn't fail, could you try running it again after playing with
the environment (setting/printing some variables).
I can't reproduce the problem here.
As I said, this issue appeared with different TFTP servers and is
independent of whether the dcache is or not enabled.
Can you transfer from a PC to another PC via TFTP?
Yes I can.
Another thing of interest would be a 'tcpdump' pcap capture of that
connection.
I was initially filtering out only TFTP packets of my wireshark trace and
all looked correct. After taking a second look to the full trace I see
now a hint. Around 7 seconds after starting the TFTP transfer the server
is sending an ARP to the target asking for the owner of the target's IP.
The target is receiving this ARP and apparently responding (at least
this is what my debug code shows as it gets into arp.c:ArpReceive(),
case ARPOP_REQUEST and sending a packet), but this ARP reply from the
target is not reaching the network. My sniffer does not capture this
reply.
The server resends the ARP request twice more (seconds 8 and 9) to the
target and since it doesn't get a reply then sends a broadcast ARP
(seconds 10) asking who has that IP. Since nobody responds it stops
sending data.
The times that it works (and I don't know the magic behind using a
numeric address versus using ${loadaddr} when they have the same value),
the ARP replies do reach the network and the server continues the
transmission normally.
Using a v2009 U-Boot, the behaviour is exactly the same, but the target's
ARP replies always reach the network, and the transfers always succeed.
Since Fabio cannot reproduce it I guess it must be a local ghost. :o(
We tracked down the issue to an ARP request from the server that was never
answered by the target. We later noticed that the problem did not happen
anymore when building U-Boot with a different toolchain and that the issue
seemed to be in the alignment of the RX buffer in the stack, which old GCC
compilers seem to do wrong.
Here is a patch:
From: Robert Hodaszirobert.hoda...@digi.com
Date: Fri, 6 Sep 2013 09:50:52 +0200
Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment
because of GCC bug
Older GCC versions don't handle well alignment on stack variables.
The temporary RX buffer is a local variable, so it is on the stack.
Because the FEC driver is using DMA for transmission, receive and
transmit buffers should be aligned on 64 byte. The transmit buffers are
not allocated in the driver internally, it sends the packets directly
as it gets them. So these packets should be aligned.
When the ARP layer wants to reply to an ARP request, it uses the FEC
driver's temporary RX buffer (used to pass data to the ARP layer) to
store the new packet, and pass it back to the FEC driver's send function.
Because of a GCC bug
Can you point to this GCC bug in the GCC bugzilla or something?
this buffer is not aligned well, and when the
driver tries to send it, it first rounds the address down to the
alignment boundary. That causes invalid data.
To fix it, don't put the temporary onto the stack.
Signed-off-by: Robert Hodaszirobert.hoda...@digi.com
Signed-off-by: Hector Palacioshector.palac...@digi.com
---
drivers/net/fec_mxc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index f4f72b7..315017e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -828,7 +828,10 @@ static int fec_recv(struct eth_device *dev)
uint16_t bd_status;
uint32_t addr, size, end;
int i;
- uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
+ /* Don't place this variable on the stack, because older GCC
version +
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi,
Sorry, hopefully that will be a plain-text.
There are a lot of bug announcement, just make a search:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Also, I printed out the buffer addresses, and that temporary RX buffer
was not aligned. So the transmit function rounded it down to the
alignment boundary, and so caused invalid data transmission. (By the
way. Shouldn't the transmit function check whether the alignment is
proper, and throw an error message, instead of round it down? That would
make more sense.)
Best regards,
Robert Hodaszi
On 2013-09-12 12:50, Marek Vasut wrote:
Dear Hector Palacios,
Hello,
Going back to this old thread I have some news regarding the problem with
TFTP transmissions blocking (timed out) after 10 seconds on the FEC of the
MX28. See below:
On 07/17/2013 05:55 PM, Hector Palacios wrote:
Dear Marek,
On 07/16/2013 06:44 AM, Marek Vasut wrote:
Dear Fabio Estevam,
On Tue, Jul 16, 2013 at 12:51 AM, Fabio Estevamfeste...@gmail.com
wrote:
On Mon, Jul 15, 2013 at 12:09 PM, Hector Palacios
hector.palac...@digi.com wrote:
@Fabio: could you manually run the command 'tftp ${loadaddr}
file100M' in your EVK?
Yes, this is what I have been running since the beginning.
If it doesn't fail, could you try running it again after playing with
the environment (setting/printing some variables).
I can't reproduce the problem here.
As I said, this issue appeared with different TFTP servers and is
independent of whether the dcache is or not enabled.
Can you transfer from a PC to another PC via TFTP?
Yes I can.
Another thing of interest would be a 'tcpdump' pcap capture of that
connection.
I was initially filtering out only TFTP packets of my wireshark trace and
all looked correct. After taking a second look to the full trace I see
now a hint. Around 7 seconds after starting the TFTP transfer the server
is sending an ARP to the target asking for the owner of the target's IP.
The target is receiving this ARP and apparently responding (at least
this is what my debug code shows as it gets into arp.c:ArpReceive(),
case ARPOP_REQUEST and sending a packet), but this ARP reply from the
target is not reaching the network. My sniffer does not capture this
reply.
The server resends the ARP request twice more (seconds 8 and 9) to the
target and since it doesn't get a reply then sends a broadcast ARP
(seconds 10) asking who has that IP. Since nobody responds it stops
sending data.
The times that it works (and I don't know the magic behind using a
numeric address versus using ${loadaddr} when they have the same value),
the ARP replies do reach the network and the server continues the
transmission normally.
Using a v2009 U-Boot, the behaviour is exactly the same, but the target's
ARP replies always reach the network, and the transfers always succeed.
Since Fabio cannot reproduce it I guess it must be a local ghost. :o(
We tracked down the issue to an ARP request from the server that was never
answered by the target. We later noticed that the problem did not happen
anymore when building U-Boot with a different toolchain and that the issue
seemed to be in the alignment of the RX buffer in the stack, which old GCC
compilers seem to do wrong.
Here is a patch:
From: Robert Hodaszirobert.hoda...@digi.com
Date: Fri, 6 Sep 2013 09:50:52 +0200
Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment
because of GCC bug
Older GCC versions don't handle well alignment on stack variables.
The temporary RX buffer is a local variable, so it is on the stack.
Because the FEC driver is using DMA for transmission, receive and
transmit buffers should be aligned on 64 byte. The transmit buffers are
not allocated in the driver internally, it sends the packets directly
as it gets them. So these packets should be aligned.
When the ARP layer wants to reply to an ARP request, it uses the FEC
driver's temporary RX buffer (used to pass data to the ARP layer) to
store the new packet, and pass it back to the FEC driver's send function.
Because of a GCC bug
Can you point to this GCC bug in the GCC bugzilla or something?
this buffer is not aligned well, and when the
driver tries to send it, it first rounds the address down to the
alignment boundary. That causes invalid data.
To fix it, don't put the temporary onto the stack.
Signed-off-by: Robert Hodaszirobert.hoda...@digi.com
Signed-off-by: Hector Palacioshector.palac...@digi.com
---
drivers/net/fec_mxc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index f4f72b7..315017e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -828,7 +828,10 @@ static int fec_recv(struct eth_device *dev)
uint16_t bd_status;
uint32_t addr, size, end;
int i;
- uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN);
+ /* Don't place this variable on the stack, because older
[U-Boot] [PATCH 0/2]powerpc/usb:Intergrate multiple USB controller support
Make multiple USB controllers work inside u-boot by doing the following: - Defining max. no of USB controllers for each soc - Defining proper base address for each controller so that initialization code can work for each of them Ramneek Mehresh (2): powerpc/usb:Define CONFIG_USB_MAX_CONTROLLER_COUNT for all 85xx socs powerpc/usb:Differentiate USB controller base address arch/powerpc/cpu/mpc83xx/cpu_init.c | 2 +- arch/powerpc/cpu/mpc8xxx/fdt.c| 6 -- arch/powerpc/include/asm/config_mpc85xx.h | 24 arch/powerpc/include/asm/immap_512x.h | 6 +++--- arch/powerpc/include/asm/immap_83xx.h | 18 -- arch/powerpc/include/asm/immap_85xx.h | 9 + drivers/usb/host/ehci-fsl.c | 15 +-- drivers/usb/host/ehci-mpc512x.c | 4 ++-- include/usb/ehci-fsl.h| 13 ++--- 9 files changed, 74 insertions(+), 23 deletions(-) -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Re-work eMMC environment
board/ti/am335x/README talks about eMMC env on the main partition, with redundancy, rather than in one of the boot partitions. Switch to using the main partition + redundant copy. Signed-off-by: Tom Rini tr...@ti.com --- include/configs/am335x_evm.h |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 3de30fc..da353d7 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -344,10 +344,11 @@ 128k(u-boot-env2),3464k(kernel), \ -(rootfs) #elif defined(CONFIG_EMMC_BOOT) -#undef CONFIG_ENV_IS_NOWHERE #define CONFIG_ENV_IS_IN_MMC -#define CONFIG_SYS_MMC_ENV_DEV 1 -#define CONFIG_SYS_MMC_ENV_PART2 +#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */ +#define CONFIG_ENV_OFFSET 0xE +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) +#define CONFIG_SYS_REDUNDAND_ENVIRONMENT #endif /* SPI flash. */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] at91: add support for CDU9G25 board
This patch adds support for our companies board CDU9G25 with Atmel AT91SAM9G25,
128MB DDR2, 256MB NAND.
Signed-off-by: Jiri Prchal jiri.prc...@aksignal.cz
---
v2
Fixed static IP and MAC addr cofiguration by random MAC and DHCP.
Added entry to MAINTAINERS.
Fixed line lenght, trailing spaces and other cosmetics.
v3
Removed static eth_gadget addresses.
MAC address set from serial number of F-RAM.
Kept CONFIG_SERVERIP as default configuration.
MAINTAINERS |3 +
board/cdu9g25/Makefile| 34 +++
board/cdu9g25/cdu9g25.c | 201 +
board/cdu9g25/config.mk |1 +
boards.cfg|1 +
include/configs/cdu9g25.h | 216 +
6 files changed, 456 insertions(+)
create mode 100644 board/cdu9g25/Makefile
create mode 100644 board/cdu9g25/cdu9g25.c
create mode 100644 board/cdu9g25/config.mk
create mode 100644 include/configs/cdu9g25.h
diff --git a/MAINTAINERS b/MAINTAINERS
index bd0f3a0..9d0008a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -851,6 +851,9 @@ Matt Porter mpor...@ti.com
ti814x_evm ARM ARMV7 (TI814x Soc)
+Jiri Prchal jiri.prc...@aksignal.cz
+ cdu9g25 ARM926EJS (AT91SAM9G25 SoC)
+
Dave Purdy david.c.pu...@gmail.com
pogo_e02ARM926EJS (Kirkwood SoC)
diff --git a/board/cdu9g25/Makefile b/board/cdu9g25/Makefile
new file mode 100644
index 000..b644a83
--- /dev/null
+++ b/board/cdu9g25/Makefile
@@ -0,0 +1,34 @@
+#
+# U-boot - Makefile
+#
+# (C) Copyright 2013
+# Jiri Prchal jiri.prc...@aksignal.cz
+# AK signal www.aksignal.cz
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= cdu9g25.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/cdu9g25/cdu9g25.c b/board/cdu9g25/cdu9g25.c
new file mode 100644
index 000..70c7647
--- /dev/null
+++ b/board/cdu9g25/cdu9g25.c
@@ -0,0 +1,201 @@
+/*
+ * (C) Copyright 2013
+ * Jiri Prchal jiri.prc...@aksignal.cz
+ * AK signal www.aksignal.cz
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include malloc.h
+#include asm/io.h
+#include asm/arch/at91sam9x5_matrix.h
+#include asm/arch/at91sam9_smc.h
+#include asm/arch/at91_common.h
+#include asm/arch/at91_pmc.h
+#include asm/arch/at91_rstc.h
+#include asm/arch/at91_spi.h
+#include asm/arch/gpio.h
+#include asm/arch/clk.h
+#include atmel_hlcdc.h
+#include atmel_mci.h
+#include spi.h
+#include net.h
+#include netdev.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* - */
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+
+static void cdu9g25_nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ unsigned long csa;
+
+ /* Enable CS3 */
+ csa = readl(matrix-ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, matrix-ebicsa);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+ smc-cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(5) |
+ AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(6),
+ smc-cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(6),
+ smc-cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(1),
+ smc-cs[3].mode);
+
+ writel(1 ATMEL_ID_PIOCD, pmc-pcer);
+
+ /* Configure RDY/BSY */
+ at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+
+ /* Enable NandFlash */
+ at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+
+ at91_set_a_periph(AT91_PIO_PORTD, 0, 1);/* NAND OE */
+ at91_set_a_periph(AT91_PIO_PORTD, 1, 1);/* NAND WE */
+ at91_set_a_periph(AT91_PIO_PORTD, 2, 1);/* NAND ALE */
+ at91_set_a_periph(AT91_PIO_PORTD, 3, 1);/* NAND CLE */
+}
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+ debug(spi_cs_is_valid: bus=%u cs=%u\n, bus, cs);
[U-Boot] Pull request: u-boot-arm/master
Hello Tom, The following changes since commit 68e1747f9c0506159e8ecc9a4feb58e9c65a7b39: socfpga: Creating driver for Reset Manager (2013-09-06 12:09:06 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 5480ac32171ab0e38c48c9f585fa650c7867f6a1: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-09-11 09:59:27 +0200) Albert ARIBAUD (1): Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Chander Kashyap (3): CONFIG: EXYNOS5: Replace misnomer SMDK5250 with EXYNOS5250 and update Makefiles exynos5250: Add arndale board support dts: samsung: arndale: Fix include path Inderpal Singh (1): exynos5250: arndale: Add mmc support Minkyu Kang (2): arm: smdkc100: remove config.mk file arm: goni: remove config.mk file Piotr Wilczek (2): arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 drivers:power:max77686: add function to set voltage and mode Przemyslaw Marczak (2): arm:mmc:goni/exynos: Fix wrong mmc base register devices offset. arm:goni:mmc: Add sd card detection and initialization. MAINTAINERS | 4 + Makefile | 2 +- arch/arm/include/asm/arch-exynos/gpio.h | 17 ++- arch/arm/include/asm/arch-exynos/mmc.h | 6 +- arch/arm/include/asm/arch-s5pc1xx/mmc.h | 6 +- board/samsung/arndale/Makefile | 34 + board/samsung/arndale/arndale.c | 101 board/samsung/arndale/arndale_spl.c | 50 ++ board/samsung/dts/exynos5250-arndale.dts | 39 + board/samsung/goni/config.mk | 18 --- board/samsung/goni/goni.c| 33 +++- board/samsung/smdkc100/config.mk | 16 -- boards.cfg | 1 + drivers/power/pmic/pmic_max77686.c | 192 +++ include/configs/arndale.h| 255 +++ include/configs/exynos5250-dt.h | 2 +- include/configs/s5p_goni.h | 3 + include/configs/smdkc100.h | 3 + include/power/max77686_pmic.h| 26 tools/Makefile | 3 +- 20 files changed, 766 insertions(+), 45 deletions(-) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/dts/exynos5250-arndale.dts delete mode 100644 board/samsung/goni/config.mk delete mode 100644 board/samsung/smdkc100/config.mk create mode 100644 include/configs/arndale.h Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: fsl_esdhc: Check the result from malloc()
malloc can fail, so we should better check its return value before using it. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/mmc/fsl_esdhc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index f87e647..a7170b4 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -518,6 +518,8 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg) return -1; mmc = malloc(sizeof(struct mmc)); + if (!mmc) + return -ENOMEM; sprintf(mmc-name, FSL_SDHC); regs = (struct fsl_esdhc *)cfg-esdhc_base; -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/5] core support of arm64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/2013 09:39 AM, FengHua wrote:
hi Rob, Thank you for your checking of this patch.
-原始邮件- 发件人: Rob Herring robherri...@gmail.com 发送时间:
2013年9月11日 星期三 收件人: feng...@phytium.com.cn 抄送:
u-boot@lists.denx.de, tr...@ti.com 主题: Re: [U-Boot] [PATCH v7
1/5] core support of arm64
On 09/10/2013 03:12 AM, feng...@phytium.com.cn wrote:
[snip]
+++ b/arch/arm/cpu/armv8/cache_v8.c
[snip]
+#include common.h +#include asm/system.h +#include
asm/arch/mmu.h
[snip]
+/* + * Stub implementations for outer cache operations + */
+void __v8_outer_cache_enable(void) {} +void
v8_outer_cache_enable(void) + __attribute__((weak,
alias(__v8_outer_cache_enable)));
These can just be:
void __weak v8_outer_cache_enable(void) {}
This format do not works at aarch64-gcc.
This file (and the others doing weak attributes) just needs to add
linux/compiler.h
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSMcnfAAoJENk4IS6UOR1W/b0P/3dwyBIhPbKypNt58cqSz29W
2qCC2IoQZmCyEVRTH/2hLwr1Bw6VZknZovDd2TV959oCUULfScTeOTlgUoqaXDSJ
aVBVfHf9uZWU7aCqVYsyIu1hAHfN82LCVsKIF6uJvHAo4h8rr1x7MeFTi5tmssST
UgWW3xZKeElI8pWwNnSVaAb1yY7X91LbHOCoVP2zbd/k0mxdjHvihIcaxSLv8iTp
vrOJCLBeHj6lpYP9Q68QzDeV0i9XFUyCEIwdF4n/9xTjnvVB6Q+PFAxKfZTCowyp
rnhpMK0wvvKDSg+B2JHdLrUH9RxElfcS1EocRmeku36zH9DEeUzMO2G4W7e+A0YE
E4gL3GsXN3UdLBGCOC1xdV9wAZSM+Mj3bGTExnPhsE0waF70JlDwjyIiGNhtrqfl
+l1Nh8icw6Os4CNDKSS+y8DjNhptlNXoxYxWb/HZP92+jU4mZ95H4Pei8zAfJD50
pvoNhu8jO3gxxG4MzJ6baSpT8tuBerSCISUi22IrJxnztxkiP4EjX7pVFWVhN/Cf
cI5zksWGHoSx+/3vDFYm/p9L5wiA9jAlcGNvE2nAYEtZxS6oEeXY1UrCbpCVMnrv
A7S6YkPUbyRhqjVl0Jwg3HPTJkqp1beOFURFKYsYtL8OM1rRG2rkvcF31uhleSG7
fM0pk3vlasNCp813iR5u
=CWhV
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Robert Hodaszi, Hi, Sorry, hopefully that will be a plain-text. There are a lot of bug announcement, just make a search: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721 This was apparently fixed three years ago. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660 And this one six years ago ... Also, I printed out the buffer addresses, and that temporary RX buffer was not aligned. So the transmit function rounded it down to the alignment boundary, and so caused invalid data transmission. (By the way. Shouldn't the transmit function check whether the alignment is proper, and throw an error message, instead of round it down? That would make more sense.) Looking at the code one more time, it'd make most sense to simply allocate the buffer NOT on stack, but with some memalign-kind-of call to avoid this abuse of stack. You see, the max packet size is around 2k, which is quite a lot. How does this proposal sound to you ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Robert Hodaszi, I just brought up two samples, that it was a long-term problem. Now it is fixed. But if somebody is trying to compile the U-Boot with an older toolchain, it could cause problems. I had problems with 4.4.6. Yes, 2k is a lot, and I would not put it on the stack. That was just a quick fix. It would be nicer to allocate the memory with malloc, and should do that at initialization time. Please do not top-post. Memalign should do here with proper rounding. Can you prepare another patch please? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
On 2013-09-12 16:31, Marek Vasut wrote: Dear Robert Hodaszi, Please do not top-post. Memalign should do here with proper rounding. Can you prepare another patch please? Best regards, Marek Vasut Ok. I will try to do that tomorrow. Best regards, Robert Hodaszi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 1/5] core support of arm64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2013 10:10 PM, FengHua wrote: hi, The following codes are originated from linux kernel. I am not sure whether license issues exist. I list the original codes at the bottom. Please check it and give me some advice. If license issues actually exist I would like to remove it. The exception state push action just should be so. The answer is that you MUST attribute things correctly. It's OK and good to bring in code from the kernel. We just make sure those things are marked as GPL-2.0 and not GPL-2.0+ - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMc9yAAoJENk4IS6UOR1WyAwQAJ/l/b/kd20z1XQXlVQSXjtl NatCefcuIzsHtGBtXncreWNqbyHdyyp2GRQx7oAKwDd//Y62xnoqNNlTtCkItq+C W6o6ofI1gYqq5j5GbziwHtt4tZMcB4VpW9OxmPGJgKARrr5Mb6Fy12yAPo9/dUNB qghlz9PXr3LH4JdaQ761EEBQSNdUWSevotuHtUga+ID/3C+kfEUkjYyQ6STlY1c6 zfr99t1JPnQMESOVjYFdrB/zm3i1RC9qIq03BKxnkwBnPmvedrAhwcu3S8u250oh fiCn0pqXP7qIn/x+W4VfY2I/K3Fusp3Rc+0NWG5kIfSl++OlK2Q8bvilME05eO02 cZ2Y18v/3mWL+l4XxdyCRVzIR0MjUHBY+nH03byLailebwqMXKDie3/LM+wuf2eB S407T+yf7LKwRq0Opkjl5oFpr+p6uqovCw+VrtYIVDNExHY0YSvAkoebSOIlPZH4 Nh2QUydTk3W4z+0GkjA52IvZKiC38fKCxVRZzgPQYfz24yLFRHWPAAepx3VYvBeY q/e0oNBS5JpG+1ZBJdOe5nXgRcYIQqQ5/2bSbyME5fgoBIqPK65JFreDdRCd+kRp aCAJ8Vbct6rijSM+jrcSSgJ94nxu+DG8N03soFcRvT1C06vkjMnA68nu3mX43CnN U+9pWTJ1Y+QS0t907HfW =CM86 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] mx6sabresd: Reset counter to prevent error message
Hi Stefano,
On 09/12/2013 03:17 AM, Stefano Babic wrote:
Hi Fabio,
On 11/09/2013 23:14, Fabio Estevam wrote:
From: Fabio Estevam fabio.este...@freescale.com
If a HDMI cable is not connected, the following message is seen on boot:
CPU: Freescale i.MX6Q rev1.1 at 792 MHz
Reset cause: POR
Board: MX6-SabreSD
DRAM: 1 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
No panel detected: default to HDMI
unsupported panel HDMI
Reset the 'i' variable to fix the 'unsupported panel' message.
This follows the same idea of commit 47ac53d7ae (imx: nitrogen6x/mx6qsabrelite:
Fix bug in board_video_skip).
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 0f91fe2..61fe67c 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -322,6 +322,7 @@ int board_video_skip(void)
if (!panel) {
panel = displays[0].mode.name;
printf(No panel detected: default to %s\n, panel);
+ i = 0;
}
Robert sents the same fix for nitrogen6x, and it was integrated. The two
functions board_video_skip() are exactly the same. What about to
factorizee the code putting it maybe in imx-common ?
We can do this, but as I mentioned in my earlier e-mail, I hope
this code doesn't have a long shelf life.
It seems reasonable to have a small number of displays supported
by various boards (those offered as part of standard EVKs), but
we integrate dozens of displays every year and it's not reasonable
to change the code base for all of them.
To distill some earlier conversations:
- Display timing information should be data, and preferably
stored in the environment so it can be used early in the boot
process.
- Display selection in U-Boot should be translatable into
kernel parameters (bootargs or device-tree)
The main problem lies in the second, since at the moment, both
the 3.0.35 kernel tree and the 3.5.7 kernel tree use either mode
strings or named display types as display configuration. The
mode strings (VESA GTF timings) are useful, but not all panels
work optimally with those timings, causing the kernel to suffer
the same requirement to update a data table for the new display.
For any that didn't participate in the earlier discussion, some
notes can be found in this thread:
http://lists.denx.de/pipermail/u-boot/2013-July/thread.html#159514
After my first shudder at using DT for this, I am currently of
the belief that some form of detailed timing as is done in the
kernel FB bindings is appropriate:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/fb/mxsfb.txt?id=refs/tags/v3.11
The primary concern I have is whether adding the ability to
parse this nested structure is appropriate, and again, the
inability to pass the information to current i.MX6 kernels.
I think the right thing may be to simply require **all**
fields from the DT structure and allow prompting of each.
And of course, add kernel patches to allow them to accept
the detailed information.
Please let me know your thoughts on this.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform
On Tue, 2013-09-03 at 11:26 +0530, Pekon Gupta wrote:
diff --git a/doc/README.nand b/doc/README.nand
index 913e9b5..f72f618 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -169,6 +169,19 @@ Configuration Options:
Please convert your driver even if you don't need the extra
flexibility, so that one day we can eliminate the old mechanism.
+ CONFIG_SYS_NAND_ONFI_DETECTION
+ Enables detection of ONFI compliant devices during probe.
+ And fetching device parameters flashed on device, by parsing
+ ONFI parameter page.
I don't see this used anywhere in the patch (defined in config headers,
yes, but not ifdeffed).
What does DETECTION add here, versus just CONFIG_NAND_ONFI?
It should be CONFIG rather than CONFIG_SYS because it just controls
whether the support is built, not making an assertion about the
hardware, right?
+ CONFIG_BCH
+ Enables software based BCH ECC algorithm present in lib/bch.c
+ This is used by SoC platforms which do not have in-build hardware
+ engine to calculate and correct BCH ECC.
s/in-build/a built-in/
+ CONFIG_SYS_NAND_ECCSCHEME
+ specifies which ECC scheme to use.
Specifies it how? What are the possible values?
If the answer involves enum omap_ecc, then OMAP should be somewhere in
the name.
+#define BADBLOCK_MARKER_LENGTH 0x2
+#define SECTOR_BYTES 512
Why hex, especially since you don't use it on the larger number?
+/**
+ * omap_select_ecc_scheme - configures driver for particular ecc-scheme
+ * @nand: NAND chip device structure
+ * @ecc_scheme: ecc scheme to configure
+ * @pagesize: number of main-area bytes per page of NAND device
+ * @oobsize: number of OOB/spare bytes per page of NAND device
+ */
+static int omap_select_ecc_scheme(struct nand_chip *nand, int ecc_scheme,
+ unsigned int pagesize, unsigned int oobsize) {
+ struct nand_bch_priv*bch= nand-priv;
+ struct nand_ecclayout *ecclayout = nand-ecc.layout;
+ int i;
+
+ /* Reset ecc interface */
+ nand-ecc.mode = NAND_ECC_NONE;
+ nand-ecc.read_page = NULL;
+ nand-ecc.write_page= NULL;
+ nand-ecc.read_oob = NULL;
+ nand-ecc.write_oob = NULL;
+ nand-ecc.hwctl = NULL;
+ nand-ecc.correct = NULL;
+ nand-ecc.calculate = NULL;
+
+ switch (ecc_scheme) {
+ case OMAP_ECC_HAM1_CODE_SW:
+ debug(nand: selected OMAP_ECC_HAM1_CODE_SW\n);
+ nand-ecc.mode = NAND_ECC_SOFT;
+ nand-ecc.layout= NULL;
+ nand-ecc.size = 0;
+ nand-ecc.strength = 1;
+ bch-ecc_scheme = OMAP_ECC_HAM1_CODE_SW;
+ break;
+ case OMAP_ECC_HAM1_CODE_HW_ROMCODE:
+ debug(nand: selected OMAP_ECC_HAM1_CODE_HW_ROMCODE\n);
+ nand-ecc.mode = NAND_ECC_HW;
+ nand-ecc.strength = 1;
+ nand-ecc.size = 512;
+ nand-ecc.bytes = 3;
+ nand-ecc.hwctl = omap_enable_hwecc;
+ nand-ecc.correct = omap_correct_data;
+ nand-ecc.calculate = omap_calculate_ecc;
+ /* define ecc-layout */
+ ecclayout-eccbytes = nand-ecc.bytes *
+ (pagesize / SECTOR_BYTES);
+ for (i = 0; i ecclayout-eccbytes; i++)
+ ecclayout-eccpos[i] = i +
+ BADBLOCK_MARKER_LENGTH;
+ ecclayout-oobfree[0].offset = i +
+ BADBLOCK_MARKER_LENGTH;
+ ecclayout-oobfree[0].length = oobsize - nand-ecc.bytes -
+ BADBLOCK_MARKER_LENGTH;
+ bch-ecc_scheme = OMAP_ECC_HAM1_CODE_HW_ROMCODE;
+ break;
+#ifdef CONFIG_BCH
+ case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
+ debug(nand: selected OMAP_ECC_BCH8_CODE_HW_DETECTION_SW\n);
+ nand-ecc.mode = NAND_ECC_HW;
+ nand-ecc.strength = 8;
+ nand-ecc.size = 512;
+ nand-ecc.bytes = 13;
+ nand-ecc.hwctl = omap_enable_ecc_bch;
+ nand-ecc.correct = omap_correct_data_bch_sw;
+ nand-ecc.calculate = omap_calculate_ecc_bch_sw;
+ /* BCH SW library is used for error detection */
+ bch_priv.control= init_bch(13, 8, 0x201b);
+ if (!bch_priv.control) {
+ printf(nand: error: could not init_bch()\n);
+ return -ENODEV;
+ }
+ /* define ecc-layout */
+ ecclayout-eccbytes = nand-ecc.bytes *
+ (pagesize /
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
On Thu, Sep 12, 2013 at 3:53 PM, Wolfgang Denk w...@denx.de wrote: Dear Fabio Estevam, In message caomzo5by6kdocown_srwhpe7ssmjarez2bcfxggff-_wrdg...@mail.gmail.com you wrote: It makes perfect sense to allocate variable with function scope only on the stack. That's what the stack has been invented for. This buffer in the fec driver will be used in DMA transfer, so maybe that's the reason we should use malloc instead of using the stack? What has DMA to do with that? We're talking about alignment only. I mentioned DMA because we align the buffer with __aligned(ARCH_DMA_MINALIGN). Will try to see if I can reproduce the problem here, but the last time I tried I was not able to. Maybe the gcc version that Robert and Hector pointed out may explain the different behaviour. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] arm:samsung:serial Extract common UART code
Hi Minkyu,
Hi Minkyu
Dear Lukasz,
On 13/08/13 06:15, Lukasz Majewski wrote:
This commit brings removal of duplicated code for UART IP block
embedded at Samsung SoCs.
New include/asm/samsung-common directory has been created to store
common code for existing and future Samsung targets.
Moreover building of UART code now depends on more verbose
CONFIG_S5P_SERIAL. Thereof all relevant boards configs have been
adjusted.
Signed-off-by: Lukasz Majewski l.majew...@majess.pl
---
Changes for v3:
- Comply with SPDX license format
Changes for v2:
- Remove S3C64XX define from the code
---
arch/arm/include/asm/arch-exynos/uart.h| 44
--- arch/arm/include/asm/arch-s5pc1xx/uart.h |
44 --- arch/arm/include/asm/samsung-common/uart.h
| 64
drivers/serial/Makefile|2 +-
drivers/serial/serial_s5p.c| 13 +-
include/configs/exynos5250-dt.h|1 +
include/configs/origen.h |1 +
include/configs/s5p_goni.h |1 +
include/configs/s5pc210_universal.h|1 +
include/configs/smdkc100.h |1 +
include/configs/smdkv310.h |1 +
include/configs/trats.h|1 + 12 files
changed, 74 insertions(+), 100 deletions(-) delete mode 100644
arch/arm/include/asm/arch-exynos/uart.h delete mode 100644
arch/arm/include/asm/arch-s5pc1xx/uart.h create mode 100644
arch/arm/include/asm/samsung-common/uart.h
diff --git a/arch/arm/include/asm/arch-exynos/uart.h
b/arch/arm/include/asm/arch-exynos/uart.h deleted file mode 100644
index 33d6ba3..000
--- a/arch/arm/include/asm/arch-exynos/uart.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * (C) Copyright 2009 Samsung Electronics
- * Minkyu Kang mk7.k...@samsung.com
- * Heungjun Kim riverful@samsung.com
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#ifndef __ASM_ARCH_UART_H_
-#define __ASM_ARCH_UART_H_
-
-#ifndef __ASSEMBLY__
-/* baudrate rest value */
-union br_rest {
- unsigned short slot; /* udivslot */
- unsigned char value; /* ufracval */
-};
-
-struct s5p_uart {
- unsigned intulcon;
- unsigned intucon;
- unsigned intufcon;
- unsigned intumcon;
- unsigned intutrstat;
- unsigned intuerstat;
- unsigned intufstat;
- unsigned intumstat;
- unsigned char utxh;
- unsigned char res1[3];
- unsigned char urxh;
- unsigned char res2[3];
- unsigned intubrdiv;
- union br_rest rest;
- unsigned char res3[0xffd0];
-};
-
-static inline int s5p_uart_divslot(void)
-{
- return 0;
-}
-
-#endif /* __ASSEMBLY__ */
-
-#endif
diff --git a/arch/arm/include/asm/arch-s5pc1xx/uart.h
b/arch/arm/include/asm/arch-s5pc1xx/uart.h deleted file mode
100644 index 26db098..000
--- a/arch/arm/include/asm/arch-s5pc1xx/uart.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * (C) Copyright 2009 Samsung Electronics
- * Minkyu Kang mk7.k...@samsung.com
- * Heungjun Kim riverful@samsung.com
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#ifndef __ASM_ARCH_UART_H_
-#define __ASM_ARCH_UART_H_
-
-#ifndef __ASSEMBLY__
-/* baudrate rest value */
-union br_rest {
- unsigned short slot; /* udivslot */
- unsigned char value; /* ufracval */
-};
-
-struct s5p_uart {
- unsigned intulcon;
- unsigned intucon;
- unsigned intufcon;
- unsigned intumcon;
- unsigned intutrstat;
- unsigned intuerstat;
- unsigned intufstat;
- unsigned intumstat;
- unsigned char utxh;
- unsigned char res1[3];
- unsigned char urxh;
- unsigned char res2[3];
- unsigned intubrdiv;
- union br_rest rest;
- unsigned char res3[0x3d0];
-};
-
-static inline int s5p_uart_divslot(void)
-{
- return 1;
-}
-
-#endif /* __ASSEMBLY__ */
-
-#endif
diff --git a/arch/arm/include/asm/samsung-common/uart.h
b/arch/arm/include/asm/samsung-common/uart.h new file mode 100644
index 000..ce92399
--- /dev/null
+++ b/arch/arm/include/asm/samsung-common/uart.h
@@ -0,0 +1,64 @@
+/*
+ * (C) Copyright 2009 Samsung Electronics
+ * Minkyu Kang mk7.k...@samsung.com
+ * Heungjun Kim riverful@samsung.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_UART_H_
+#define __ASM_ARCH_UART_H_
+
+#ifndef __ASSEMBLY__
+/* baudrate rest value */
+union br_rest {
+ unsigned short slot; /* udivslot */
+ unsigned char value; /* ufracval */
+};
+
+struct s5p_uart {
+ unsigned intulcon;
+ unsigned int
Re: [U-Boot] [PATCH] am335x_evm: Re-work eMMC environment
On Thu, Sep 12, 2013 at 08:46:50AM -0400, Tom Rini wrote: board/ti/am335x/README talks about eMMC env on the main partition, with redundancy, rather than in one of the boot partitions. Switch to using the main partition + redundant copy. Signed-off-by: Tom Rini tr...@ti.com I'm going to re-tract this and update the README instead, along with switching to redundant env support. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Marek Vasut, In message 201309121605.04824.ma...@denx.de you wrote: Looking at the code one more time, it'd make most sense to simply allocate the buffer NOT on stack, but with some memalign-kind-of call to avoid this abuse of stack. You see, the max packet size is around 2k, which is quite a lot. How does this proposal sound to you ? It makes perfect sense to allocate variable with function scope only on the stack. That's what the stack has been invented for. If there is a bug with that, this mug must be isolated and fixed. It makes zero sense to just paper over it. Best regards, Wolfgang Denk -- 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: w...@denx.de Two wrongs don't make a right, but three rights make a left. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc SPL framework: Avoiding relocate_code
On Mon, 2013-09-09 at 16:43 +0530, Prabhakar Kushwaha wrote: Hi, SPL framework is used to support multi-stage booting. Where first level boot loader is created via SPL having relocate_code() function. I am working on a Freescale's SoC which has less internal SRAM. I don't want to use relocate_code() as to support this function, I need to reduce SPL bin to SRAM/2 size. is there way to avoid relocate_code function ? I tried with below sequence, but it is not working for me :( .globlrelocate_code relocate_code: mrr1,r3/* Set new stack pointer*/ mrr9,r4/* Save copy of Init Data pointer*/ mrr10,r5/* Save copy of Destination Address*/ GET_GOT #ifndef CONFIG_SPL_BUILD -- -- #endif .globlin_ram in_ram: Well, you certainly don't want to disable it for all SPLs... The reason is bss variables which are mapped to 0x_ onwards because bsssection are mapped after 0xfffc in lds. They are not available during SPL execution. is there way to relocate bss section in the execution range of SPL? Are you talking about a scenario in which the SPL is loaded into SRAM rather than (e.g.) the NAND buffer? In that case, why is U-Boot not linked at the actual SRAM address? No copy should be needed in that case, and the BSS will not be at zero. If you are talking about a NAND buffer style boot (i.e. not a PBL-using chip), then you must relocate, so the NAND buffer can be reused for I/O (and in any case the SRAM is much larger than the NAND buffer on Freescale PPC chips that I'm familiar with). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Executing U-Boot from Another Boot Loader
Dear Roy Caspi, In message f977efba9bba814ea37842e54344726d28664...@tlrd-mail.telrad.co.il you wrote: I have a VxWorks Boot Loader running on my P3041 and from there I'm willing to execute a U-Boot image that was previously burnt in my flash. The U-Boot image - u-boot-p3041ds-2011.09-r5.bin - is 512KB and is burnt at the address of 0xF802,, ending at 0xF809, (no env. parameters were burnt). So from the VxWorks Boot Loader I branch to the address of 0xF802, and get an exception. I also try branching to 0xF809,FFFC, but again the U-Boot shell won't show up. Could you please help me on that? Where can I find the U-Boot entry point and how should I load it manually? U-Boot expects to be run on a CPU that comes fresh out of reset, i. e. it starts at the reset entry point. You must modify the code (more or leass heavily) so that allt he things that were already done get skipped. Some board have a RAMBOOT config option where you could check what needs to be done. But then - is it worth it? Just install U-Boot and let it do it's work. U-Boot can also boot VxWorks, so there should be no need to keep the old loader. Best regards, Wolfgang Denk -- 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: w...@denx.de A mouse is an elephant built by the Japanese. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_BAUDRATE doesn't match
Stephan,
The processor is a 460SX (shares the same data sheet as 460GT).
In my /include/configs/boardname.h file I include amcc-common.h which
has what you suggested:
/*
* UART
*/
#define CONFIG_SYS_NS16550
#define CONFIG_SYS_NS16550_SERIAL
#define CONFIG_SYS_NS16550_REG_SIZE 1
#define CONFIG_SYS_NS16550_CLK get_serial_clock()
#define CONFIG_BAUDRATE 115200
#define CONFIG_SYS_BAUDRATE_TABLE \
{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
Thanks,
Greg
--
View this message in context:
http://u-boot.10912.n7.nabble.com/CONFIG-BAUDRATE-doesn-t-match-tp162206p163043.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Robert Hodaszi, In message 5231a0c0.8070...@digi.com you wrote: Sorry, hopefully that will be a plain-text. There are a lot of bug announcement, just make a search: gcc.gnu.org/bugzilla/show_bug.cgi?id=33721 gcc.gnu.org/bugzilla/show_bug.cgi?id=16660 Hm... what exactly are the values of STACK_BOUNDARY and PREFERRED_STACK_BOUNDARY for the failing version of GCC, then? Best regards, Wolfgang Denk -- 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: w...@denx.de Each team building another component has been using the most recent tested version of the integrated system as a test bed for debugging its piece. Their work will be set back by having that test bed change under them. Of course it must. But the changes need to be quantized. Then each user has periods of productive stability, interrupted by bursts of test-bed change. This seems to be much less disruptive than a constant rippling and trembling. - Frederick Brooks Jr., The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
I just brought up two samples, that it was a long-term problem. Now it is fixed. But if somebody is trying to compile the U-Boot with an older toolchain, it could cause problems. I had problems with 4.4.6. Yes, 2k is a lot, and I would not put it on the stack. That was just a quick fix. It would be nicer to allocate the memory with malloc, and should do that at initialization time. Best regards, Robert Hodaszi On 2013-09-12 16:05, Marek Vasut wrote: Dear Robert Hodaszi, Hi, Sorry, hopefully that will be a plain-text. There are a lot of bug announcement, just make a search: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33721 This was apparently fixed three years ago. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660 And this one six years ago ... Also, I printed out the buffer addresses, and that temporary RX buffer was not aligned. So the transmit function rounded it down to the alignment boundary, and so caused invalid data transmission. (By the way. Shouldn't the transmit function check whether the alignment is proper, and throw an error message, instead of round it down? That would make more sense.) Looking at the code one more time, it'd make most sense to simply allocate the buffer NOT on stack, but with some memalign-kind-of call to avoid this abuse of stack. You see, the max packet size is around 2k, which is quite a lot. How does this proposal sound to you ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Fabio Estevam, In message caomzo5by6kdocown_srwhpe7ssmjarez2bcfxggff-_wrdg...@mail.gmail.com you wrote: It makes perfect sense to allocate variable with function scope only on the stack. That's what the stack has been invented for. This buffer in the fec driver will be used in DMA transfer, so maybe that's the reason we should use malloc instead of using the stack? What has DMA to do with that? We're talking about alignment only. At least in the kernel, we don't use stack for DMA buffers. Yes, but them, the kernel uses a much more complicated memory setup, with somewhat different mappings for different regions. We don't do that - or do we? IMO we use a single mapping for the whole RAM ? Best regards, Wolfgang Denk -- 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: w...@denx.de Far back in the mists of ancient time, in the great and glorious days of the former Galactic Empire, life was wild, rich and largely tax free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Hector Palacios, In message 523195ca.3010...@digi.com you wrote: Here is a patch: From: Robert Hodaszi robert.hoda...@digi.com Date: Fri, 6 Sep 2013 09:50:52 +0200 Subject: [PATCH] net: fec: fix invalid temporary RX buffer alignment because of GCC bug Older GCC versions don't handle well alignment on stack variables. Can you please be specific - which exact versions of GCC are supposed to misbehave here? To fix it, don't put the temporary onto the stack. This is not a good idea, as it wastes a memory for no good reason. Signed-off-by: Robert Hodaszi robert.hoda...@digi.com Signed-off-by: Hector Palacios hector.palac...@digi.com --- drivers/net/fec_mxc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index f4f72b7..315017e 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -828,7 +828,10 @@ static int fec_recv(struct eth_device *dev) uint16_t bd_status; uint32_t addr, size, end; int i; - uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); + /* Don't place this variable on the stack, because older GCC version +* doesn't handle alignement on stack well. +*/ + static uchar buff[FEC_MAX_PKT_SIZE] __aligned(ARCH_DMA_MINALIGN); I have to admit that I doubt the explanation - somthing else is probaly wrong instead. I would really like to know which compiler version misbehaves, and what the generated code looks like, both in the working and in the broken case. Thanks. Best regards, Wolfgang Denk -- 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: w...@denx.de I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] net: fec_mxc: Add support for mx6 solo-lite
From: Fabio Estevam fabio.este...@freescale.com
Similarly as mx25 and mx53, mx6solo-lite needs to setup the MII gasket for RMII
mode.
Add support for mx6solo-lite.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Based on FSL BSP, which uses U-boot 2013.04.
drivers/net/fec_mxc.c | 2 +-
drivers/net/fec_mxc.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index e14a359..f4a0c5d 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -453,7 +453,7 @@ static int fec_open(struct eth_device *edev)
*/
writel(readl(fec-eth-ecntrl) | FEC_ECNTRL_ETHER_EN,
fec-eth-ecntrl);
-#if defined(CONFIG_MX25) || defined(CONFIG_MX53)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX53) || defined(CONFIG_MX6SL)
udelay(100);
/*
* setup the MII gasket for RMII mode
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 4b4f8b7..0717cc6 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -135,7 +135,7 @@ struct ethernet_regs {
uint32_t res14[7]; /* MBAR_ETH + 0x2E4-2FC */
-#if defined(CONFIG_MX25) || defined(CONFIG_MX53)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX53) || defined(CONFIG_MX6SL)
uint16_t miigsk_cfgr; /* MBAR_ETH + 0x300 */
uint16_t res15[3]; /* MBAR_ETH + 0x302-306 */
uint16_t miigsk_enr;/* MBAR_ETH + 0x308 */
@@ -202,7 +202,7 @@ struct ethernet_regs {
#define FEC_X_DES_ACTIVE_TDAR 0x0100
#define FEC_R_DES_ACTIVE_RDAR 0x0100
-#if defined(CONFIG_MX25) || defined(CONFIG_MX53)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX53) || defined(CONFIG_MX6SL)
/* defines for MIIGSK */
/* RMII frequency control: 0=50MHz, 1=5MHz */
#define MIIGSK_CFGR_FRCONT (1 6)
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6slevk: Add Ethernet support
From: Fabio Estevam fabio.este...@freescale.com
mx6slevk has a SMSC8720 connected in RMII mode.
Add support for it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Based on FSL BSP, which uses U-boot 2013.04.
arch/arm/cpu/armv7/mx6/clock.c | 30 +
arch/arm/include/asm/arch-mx6/clock.h | 1 +
arch/arm/include/asm/arch-mx6/iomux.h | 5 +++
arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 12 ++
board/freescale/mx6slevk/mx6slevk.c| 68 ++
include/configs/mx6slevk.h | 14 ++
6 files changed, 130 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 7efb0d2..87d7167 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -282,6 +282,36 @@ static u32 get_mmdc_ch0_clk(void)
return freq / (podf + 1);
}
+
+int enable_fec_anatop_clock(void)
+{
+ u32 reg = 0;
+ s32 timeout = 10;
+
+ struct anatop_regs __iomem *anatop =
+ (struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
+
+ reg = readl(anatop-pll_enet);
+ if ((reg BM_ANADIG_PLL_ENET_POWERDOWN) ||
+ (!(reg BM_ANADIG_PLL_ENET_LOCK))) {
+ reg = ~BM_ANADIG_PLL_ENET_POWERDOWN;
+ writel(reg, ANATOP_BASE_ADDR + 0xe0);
+ while (timeout--) {
+ if (readl(anatop-pll_enet) BM_ANADIG_PLL_ENET_LOCK)
+ break;
+ }
+ if (timeout 0)
+ return -ETIMEDOUT;
+ }
+
+ /* Enable FEC clock */
+ reg |= BM_ANADIG_PLL_ENET_ENABLE;
+ reg = ~BM_ANADIG_PLL_ENET_BYPASS;
+ writel(reg, anatop-pll_enet);
+
+ return 0;
+}
+
#else
static u32 get_mmdc_ch0_clk(void)
{
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index c493687..93f29a7 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -50,4 +50,5 @@ void enable_usboh3_clk(unsigned char enable);
int enable_sata_clock(void);
int enable_i2c_clk(unsigned char enable, unsigned i2c_num);
void enable_ipu_clock(void);
+int enable_fec_anatop_clock(void);
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/asm/arch-mx6/iomux.h
b/arch/arm/include/asm/arch-mx6/iomux.h
index f4cfd4f..ff13a1e 100644
--- a/arch/arm/include/asm/arch-mx6/iomux.h
+++ b/arch/arm/include/asm/arch-mx6/iomux.h
@@ -27,6 +27,11 @@
#define IOMUXC_GPR13_SATA_PHY_2_MASK (0x1f2)
#define IOMUXC_GPR13_SATA_PHY_1_MASK (30)
+#define IOMUX_GPR1_FEC_CLOCK_MUX1_SEL_MASK (0x3 17)
+#define IOMUX_GPR1_FEC_CLOCK_MUX2_SEL_MASK (0x1 14)
+#define IOMUX_GPR1_FEC_MASK(IOMUX_GPR1_FEC_CLOCK_MUX1_SEL_MASK \
+ | IOMUX_GPR1_FEC_CLOCK_MUX2_SEL_MASK)
+
#define IOMUXC_GPR13_SATA_PHY_8_RXEQ_0P5DB (024)
#define IOMUXC_GPR13_SATA_PHY_8_RXEQ_1P0DB (124)
#define IOMUXC_GPR13_SATA_PHY_8_RXEQ_1P5DB (224)
diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
index b39a354..5f9c90a 100644
--- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
@@ -18,5 +18,17 @@ enum {
MX6_PAD_SD2_DAT3__USDHC2_DAT3 =
IOMUX_PAD(0x0570, 0x0268, 0, 0x, 0, 0),
MX6_PAD_UART1_RXD__UART1_RXD=
IOMUX_PAD(0x05A0, 0x0298, 0, 0x07FC, 0, 0),
MX6_PAD_UART1_TXD__UART1_TXD=
IOMUX_PAD(0x05A4, 0x029C, 0, 0x, 0, 0),
+
+ MX6_PAD_FEC_MDC__FEC_MDC=
IOMUX_PAD(0x41c, 0x12c, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_MDIO__FEC_MDIO =
IOMUX_PAD(0x420, 0x130, 0, 0x6f4, 1, 0),
+ MX6_PAD_FEC_CRS_DV__FEC_RX_DV =
IOMUX_PAD(0x418, 0x128, 0, 0x704, 1, 0),
+ MX6_PAD_FEC_RXD0__FEC_RX_DATA0 =
IOMUX_PAD(0x42c, 0x13c, 0, 0x6f8, 0, 0),
+ MX6_PAD_FEC_RXD1__FEC_RX_DATA1 =
IOMUX_PAD(0x430, 0x140, 0, 0x6fc, 1, 0),
+ MX6_PAD_FEC_TX_EN__FEC_TX_EN=
IOMUX_PAD(0x438, 0x148, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_TXD0__FEC_TX_DATA0 =
IOMUX_PAD(0x43c, 0x14c, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_TXD1__FEC_TX_DATA1 =
IOMUX_PAD(0x440, 0x150, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_REF_CLK__FEC_REF_OUT=
IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
+ MX6_PAD_FEC_RX_ER__GPIO_4_19=
IOMUX_PAD(0x0428, 0x0138, 5, 0x, 0, 0),
+ MX6_PAD_FEC_TX_CLK__GPIO_4_21 =
IOMUX_PAD(0x0434, 0x0144, 5, 0x, 0, 0),
};
#endif /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index 5b6ef81..2d995b9 100644
---
[U-Boot] i.MX6DL/S regression in mx6dl_pins.h
Hi all, It seems to be all about displays and mux/pad registers for me these days. I just tracked down an issue related to commit 87d720e0c that causes improper display on our RGB displays. In particular, the pad settings for these two registers lost their drive-strength value: MX6_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2 MX6_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 I could make the case that things like pad drive strength are a board-level tuning function, and belong in board-specific files, but I think all RGB displays used with i.MX6 need these values (and they should probably match the 6DQ). Let me know if you'd like me to send a patch for this. I have some other notes regarding consolidation of 6DQ and 6DLS that I'll send separately. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
Hi Tom, On Thu, 12 Sep 2013 11:11:16 -0400, Tom Rini tr...@ti.com wrote: On Thu, Sep 12, 2013 at 03:18:51PM +0200, Albert ARIBAUD wrote: Hello Tom, The following changes since commit 68e1747f9c0506159e8ecc9a4feb58e9c65a7b39: socfpga: Creating driver for Reset Manager (2013-09-06 12:09:06 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 5480ac32171ab0e38c48c9f585fa650c7867f6a1: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-09-11 09:59:27 +0200) Albert ARIBAUD (1): Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Chander Kashyap (3): CONFIG: EXYNOS5: Replace misnomer SMDK5250 with EXYNOS5250 and update Makefiles exynos5250: Add arndale board support dts: samsung: arndale: Fix include path Inderpal Singh (1): exynos5250: arndale: Add mmc support Minkyu Kang (2): arm: smdkc100: remove config.mk file arm: goni: remove config.mk file Piotr Wilczek (2): arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 drivers:power:max77686: add function to set voltage and mode Przemyslaw Marczak (2): arm:mmc:goni/exynos: Fix wrong mmc base register devices offset. arm:goni:mmc: Add sd card detection and initialization. MAINTAINERS | 4 + Makefile | 2 +- arch/arm/include/asm/arch-exynos/gpio.h | 17 ++- arch/arm/include/asm/arch-exynos/mmc.h | 6 +- arch/arm/include/asm/arch-s5pc1xx/mmc.h | 6 +- board/samsung/arndale/Makefile | 34 + board/samsung/arndale/arndale.c | 101 board/samsung/arndale/arndale_spl.c | 50 ++ board/samsung/dts/exynos5250-arndale.dts | 39 + board/samsung/goni/config.mk | 18 --- board/samsung/goni/goni.c| 33 +++- board/samsung/smdkc100/config.mk | 16 -- boards.cfg | 1 + drivers/power/pmic/pmic_max77686.c | 192 +++ include/configs/arndale.h| 255 +++ include/configs/exynos5250-dt.h | 2 +- include/configs/s5p_goni.h | 3 + include/configs/smdkc100.h | 3 + include/power/max77686_pmic.h| 26 tools/Makefile | 3 +- 20 files changed, 766 insertions(+), 45 deletions(-) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/dts/exynos5250-arndale.dts delete mode 100644 board/samsung/goni/config.mk delete mode 100644 board/samsung/smdkc100/config.mk create mode 100644 include/configs/arndale.h Applied to u-boot/master, thanks! Thanks. For information, I have merged u-boot/master back into u-boot-arm/master (fast-forwarded, actually). Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Thu, Sep 12, 2013 at 03:18:51PM +0200, Albert ARIBAUD wrote: Hello Tom, The following changes since commit 68e1747f9c0506159e8ecc9a4feb58e9c65a7b39: socfpga: Creating driver for Reset Manager (2013-09-06 12:09:06 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 5480ac32171ab0e38c48c9f585fa650c7867f6a1: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-09-11 09:59:27 +0200) Albert ARIBAUD (1): Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Chander Kashyap (3): CONFIG: EXYNOS5: Replace misnomer SMDK5250 with EXYNOS5250 and update Makefiles exynos5250: Add arndale board support dts: samsung: arndale: Fix include path Inderpal Singh (1): exynos5250: arndale: Add mmc support Minkyu Kang (2): arm: smdkc100: remove config.mk file arm: goni: remove config.mk file Piotr Wilczek (2): arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 drivers:power:max77686: add function to set voltage and mode Przemyslaw Marczak (2): arm:mmc:goni/exynos: Fix wrong mmc base register devices offset. arm:goni:mmc: Add sd card detection and initialization. MAINTAINERS | 4 + Makefile | 2 +- arch/arm/include/asm/arch-exynos/gpio.h | 17 ++- arch/arm/include/asm/arch-exynos/mmc.h | 6 +- arch/arm/include/asm/arch-s5pc1xx/mmc.h | 6 +- board/samsung/arndale/Makefile | 34 + board/samsung/arndale/arndale.c | 101 board/samsung/arndale/arndale_spl.c | 50 ++ board/samsung/dts/exynos5250-arndale.dts | 39 + board/samsung/goni/config.mk | 18 --- board/samsung/goni/goni.c| 33 +++- board/samsung/smdkc100/config.mk | 16 -- boards.cfg | 1 + drivers/power/pmic/pmic_max77686.c | 192 +++ include/configs/arndale.h| 255 +++ include/configs/exynos5250-dt.h | 2 +- include/configs/s5p_goni.h | 3 + include/configs/smdkc100.h | 3 + include/power/max77686_pmic.h| 26 tools/Makefile | 3 +- 20 files changed, 766 insertions(+), 45 deletions(-) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/dts/exynos5250-arndale.dts delete mode 100644 board/samsung/goni/config.mk delete mode 100644 board/samsung/smdkc100/config.mk create mode 100644 include/configs/arndale.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
Wolfgang Denk wd at denx.de writes: Dear Mateusz, In message 5123E16B.1060907 at gmail.com you wrote: Is there anyone that can support me with enforcing GPL compliance on company that ships product with binary u-boot? Or did that in the past? We can try. They're made (branded is probably better word) by local companies, and my guess is that most of them is violating GPL. Guesses are not good enough in such legal affairs. I can't do much myself (except for nagging them for source code), as it's not my copyrights that they're infringing. So did you contact the vendor and ask for the source code? And did they answer, and what exactly? Best regards, Wolfgang Denk Hi there Has there been any progress on this GPL non-compliance issue? Similar products as mentioned by the OP are also available in the USA. I have purchased one of them, a HomeWorX HW-150PVR manufactured and distributed by Mediasonic, which seems to be a DBA for Major League Global Enterprise LLC, 16968 Gale Ave., City of Industry, CA 91745, USA. A product of identical functionality is the iView-3500STB manufactured and distributed by Wiltronic Corporation. Both products are set-top boxes with ATSC TV tuners and a USB port for recording and playback of content. The main board has a MS7816 SoC made by MStar Semiconductor of Taiwan. On startup the onboard serial port outputs: = = = begin = = = UART_115200 BIST0-OK _snPDMDrv_PM_RtcGetCounter(CurrentCounter=0) Hello U-Boot U-Boot 1.1.6 (Feb 27 2013 - 22:42:31) Board: MSTAR KRNOUS (CPU Speed 552 MHz) DRAM: 64 X 0 MBytes U-Boot is running at DRAM 0x8760 ###BOARD CONFIGURATION# DEFAULT ENBALE L2-Cache FPU(ENABLE) ENABLE_DDR3_16BIT_MODE DDR_FREQUENCY(1066MHz) ###BOARD CONFIGURATION# Module: USB FAT FLASH SPI LOGO OSD ENV=SERIAL Flash is detected (0x0C00, 0xC8, 0x40, 0x16) MDrv_SERFLASH_GetInfo() u32AccessWidth = 1 u32TotalSize = 4194304 u32SecNum = 64 u32SecSize = 65536 In:serial Out: serial Err: serial GPIO PIN 6 HIGH!!! ... = = = end = = = This version of U-Boot installed in the product seems to have been significantly enhanced by MStar. The `help' menu is: = = = begin = = = MStar # help ? - alias for 'help' do Lzma for compress image base- print or set address offset bdinfo - print Board Info structure boot_logo - Logo display bootm - boot application image from memory cmp - memory compare coninfo - print console devices and information cp - memory copy cpmsbin - Copy ms bin file (Chakra) from nand to dram crc32 - checksum calculation cusid check the image is release by the valid guys dcache - enable or disable data cache dmx_init - initialize the demux setting dmx_init - initialize the demux setting draw_pixel - draw a pixel with color draw_string - draw string with color draw_rect - draw rect with color draw_string - draw string with color du - Disable UART env2flash - read environment parameter file and restore it to flash envbin - read out environment parameter and store it to usb disk erase - erase FLASH memory fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) fatwrite - write binary file to a dos filesystem flinfo - print FLASH memory information go - start application at address 'addr' help- print online help loop- infinite loop on address range md - memory display mm - memory modify (auto-incrementing) mstar - update kernal root file system automatically by script file mtest - simple RAM test mw - memory write (fill) ustar - update kernal root file system automatically by script file nm - memory modify (constant address) ostar - update kernal root file system automatically by script file oad_get_size - Get the file size from OAD download osd_create - create osd layer osd_destroy - destroy osd layer pnlinfo - set panel info and save to nand flahs printenv- print environment variables protect - enable or disable FLASH write protection reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage set_paneltype [type] - Set Mboot panel type and store the type value in env setenv - set environment variables spi_dma - SPI copy data from flash to DRAM by PIU DMA spi_ea - SPI erase all spi_eb - SPI erase block spi_gfo - SPI get flash info spi_gr - SPI get Chip Rev spi_id - SPI read ID spi_in - SPI initialization spi_r - SPI read commands spi_rb - SPI read buffer spi_rdc - SPI read code from SPI flash to DRAM spi_rs - SPI read status spi_w - SPI write commands spi_wb - SPI write buffer spi_wp - SPI write protect spi_wrc - SPI write code from DRAM to SPI flash sspi- SPI utility commands sysinfo - set
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
On Thu, Sep 12, 2013 at 3:17 PM, Wolfgang Denk w...@denx.de wrote: Dear Marek Vasut, In message 201309121605.04824.ma...@denx.de you wrote: Looking at the code one more time, it'd make most sense to simply allocate the buffer NOT on stack, but with some memalign-kind-of call to avoid this abuse of stack. You see, the max packet size is around 2k, which is quite a lot. How does this proposal sound to you ? It makes perfect sense to allocate variable with function scope only on the stack. That's what the stack has been invented for. This buffer in the fec driver will be used in DMA transfer, so maybe that's the reason we should use malloc instead of using the stack? At least in the kernel, we don't use stack for DMA buffers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6DL/S regression in mx6dl_pins.h
Hi Eric, On Thu, Sep 12, 2013 at 6:56 PM, Eric Nelson eric.nel...@boundarydevices.com wrote: Hi all, It seems to be all about displays and mux/pad registers for me these days. I just tracked down an issue related to commit 87d720e0c that causes improper display on our RGB displays. In particular, the pad settings for these two registers lost their drive-strength value: MX6_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2 MX6_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 I could make the case that things like pad drive strength are a board-level tuning function, and belong in board-specific files, but I think all RGB displays used with i.MX6 need these values (and they should probably match the 6DQ). Let me know if you'd like me to send a patch for this. Yes, please send a patch for this when you have a chance. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Dear Robert Hodaszi, On 2013-09-12 16:31, Marek Vasut wrote: Dear Robert Hodaszi, Please do not top-post. Memalign should do here with proper rounding. Can you prepare another patch please? Best regards, Marek Vasut Ok. I will try to do that tomorrow. Cool, thanks ! Nice find btw ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mx6sabresd: Avoid hang when HDMI cable is not connected
Thanks Stefano,
On 09/12/2013 02:47 AM, Stefano Babic wrote:
Hi Fabio,
CC to Eric and Troy.
On 11/09/2013 23:14, Fabio Estevam wrote:
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index c832bd9..0f91fe2 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -313,7 +313,7 @@ int board_video_skip(void)
if (!panel) {
for (i = 0; i ARRAY_SIZE(displays); i++) {
struct display_info_t const *dev = displays+i;
- if (dev-detect(dev)) {
+ if (dev-detect dev-detect(dev)) {
The same should happen on the Nitrogen board. Should this fix extended
to the other boards using hdmi ?
This isn't needed yet in the stock (main-line) code base, since
we haven't added any panels without detection.
We do have a form this patch and a lot of panels in our local tree
on Github, but wanted to avoid unnecessary noise on the list
because we've integrated a dozen or so panels and the existing
structure really doesn't scale.
We had a separate discussion regarding treating the displays
as data (environment), but have stalled somewhat on that front.
The current device-tree code for i.MX6 uses mode strings instead
of the detailed timing data that's really needed for a proper
solution.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx6sabresd: Return error if cpu_eth_init() fails
From: Fabio Estevam fabio.este...@freescale.com Currently board_eth_init() always return 0, but we should propagate the error when cpu_eth_init() fails. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/freescale/mx6sabresd/mx6sabresd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/mx6sabresd/mx6sabresd.c b/board/freescale/mx6sabresd/mx6sabresd.c index c832bd9..425f734 100644 --- a/board/freescale/mx6sabresd/mx6sabresd.c +++ b/board/freescale/mx6sabresd/mx6sabresd.c @@ -421,7 +421,7 @@ int board_eth_init(bd_t *bis) if (ret) printf(FEC MXC: %s:failed\n, __func__); - return 0; + return ret; } int board_early_init_f(void) -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6qsabreauto: Return error if cpu_eth_init() fails
From: Fabio Estevam fabio.este...@freescale.com Currently board_eth_init() always return 0, but we should propagate the error when cpu_eth_init() fails. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- board/freescale/mx6qsabreauto/mx6qsabreauto.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c b/board/freescale/mx6qsabreauto/mx6qsabreauto.c index 1cdf2cb..c55ee87 100644 --- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c +++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c @@ -200,7 +200,7 @@ int board_eth_init(bd_t *bis) if (ret) printf(FEC MXC: %s:failed\n, __func__); - return 0; + return ret; } #define BOARD_REV_B 0x200 -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx35pdk: Remove CONFIG_SYS_CACHELINE_SIZE
From: Fabio Estevam fabio.este...@freescale.com In arch/arm/cpu/arm1136/cpu.c we have: #ifndef CONFIG_SYS_CACHELINE_SIZE #define CONFIG_SYS_CACHELINE_SIZE 32 #endif ,so there is no need to define 'CONFIG_SYS_CACHELINE_SIZE' with the default size in the board config file. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx35pdk.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h index 68b225a..a25b20e 100644 --- a/include/configs/mx35pdk.h +++ b/include/configs/mx35pdk.h @@ -23,7 +23,6 @@ /* Set TEXT at the beginning of the NOR flash */ #define CONFIG_SYS_TEXT_BASE 0xA000 -#define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_BOARD_LATE_INIT -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] at91: add support for CDU9G25 board
Dear Jiri Prchal,
In message 1378991839-16732-1-git-send-email-jiri.prc...@aksignal.cz you
wrote:
...
+err_spi_setup_slave:
+ if (!is_valid_ether_addr(sernum)) {
+ debug(Using random MAC address\n);
+ eth_random_enetaddr(sernum);
+ }
Pleas change this debug() into a puts() [or rather a printf() and also
print the value.] The user is supposed to know when something goes
badly wrong and random addresses get used, and what these are.
+ eth_setenv_enetaddr(ethaddr, sernum);
NAK. Here you unconditionally overwrite the MAC address, even if one
is already present in the environment. This must never be done. If
the user defines an address, shis shall always be respected.
Thanks.
Best regards,
Wolfgang Denk
--
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: w...@denx.de
Unser Kopf ist rund, damit das Denken die Richtung wechseln kann.
-- Francis Picabia
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] arm:samsung:serial Extract common UART code
On 29 August 2013 02:31, Lukasz Majewski l.majew...@majess.pl wrote:
Hi Minkyu
Dear Lukasz,
On 13/08/13 06:15, Lukasz Majewski wrote:
This commit brings removal of duplicated code for UART IP block
embedded at Samsung SoCs.
New include/asm/samsung-common directory has been created to store
common code for existing and future Samsung targets.
Moreover building of UART code now depends on more verbose
CONFIG_S5P_SERIAL. Thereof all relevant boards configs have been
adjusted.
Signed-off-by: Lukasz Majewski l.majew...@majess.pl
---
Changes for v3:
- Comply with SPDX license format
Changes for v2:
- Remove S3C64XX define from the code
---
arch/arm/include/asm/arch-exynos/uart.h| 44
--- arch/arm/include/asm/arch-s5pc1xx/uart.h |
44 --- arch/arm/include/asm/samsung-common/uart.h
| 64
drivers/serial/Makefile|2 +-
drivers/serial/serial_s5p.c| 13 +-
include/configs/exynos5250-dt.h|1 +
include/configs/origen.h |1 +
include/configs/s5p_goni.h |1 +
include/configs/s5pc210_universal.h|1 +
include/configs/smdkc100.h |1 +
include/configs/smdkv310.h |1 +
include/configs/trats.h|1 + 12 files
changed, 74 insertions(+), 100 deletions(-) delete mode 100644
arch/arm/include/asm/arch-exynos/uart.h delete mode 100644
arch/arm/include/asm/arch-s5pc1xx/uart.h create mode 100644
arch/arm/include/asm/samsung-common/uart.h
diff --git a/arch/arm/include/asm/arch-exynos/uart.h
b/arch/arm/include/asm/arch-exynos/uart.h deleted file mode 100644
index 33d6ba3..000
--- a/arch/arm/include/asm/arch-exynos/uart.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * (C) Copyright 2009 Samsung Electronics
- * Minkyu Kang mk7.k...@samsung.com
- * Heungjun Kim riverful@samsung.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __ASM_ARCH_UART_H_
-#define __ASM_ARCH_UART_H_
-
-#ifndef __ASSEMBLY__
-/* baudrate rest value */
-union br_rest {
- unsigned short slot; /* udivslot */
- unsigned char value; /* ufracval */
-};
-
-struct s5p_uart {
- unsigned intulcon;
- unsigned intucon;
- unsigned intufcon;
- unsigned intumcon;
- unsigned intutrstat;
- unsigned intuerstat;
- unsigned intufstat;
- unsigned intumstat;
- unsigned char utxh;
- unsigned char res1[3];
- unsigned char urxh;
- unsigned char res2[3];
- unsigned intubrdiv;
- union br_rest rest;
- unsigned char res3[0xffd0];
-};
-
-static inline int s5p_uart_divslot(void)
-{
- return 0;
-}
-
-#endif /* __ASSEMBLY__ */
-
-#endif
diff --git a/arch/arm/include/asm/arch-s5pc1xx/uart.h
b/arch/arm/include/asm/arch-s5pc1xx/uart.h deleted file mode 100644
index 26db098..000
--- a/arch/arm/include/asm/arch-s5pc1xx/uart.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * (C) Copyright 2009 Samsung Electronics
- * Minkyu Kang mk7.k...@samsung.com
- * Heungjun Kim riverful@samsung.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __ASM_ARCH_UART_H_
-#define __ASM_ARCH_UART_H_
-
-#ifndef __ASSEMBLY__
-/* baudrate rest value */
-union br_rest {
- unsigned short slot; /* udivslot */
- unsigned char value; /* ufracval */
-};
-
-struct s5p_uart {
- unsigned intulcon;
- unsigned intucon;
- unsigned intufcon;
- unsigned intumcon;
- unsigned intutrstat;
- unsigned intuerstat;
- unsigned intufstat;
- unsigned intumstat;
- unsigned char utxh;
- unsigned char res1[3];
- unsigned char urxh;
- unsigned char res2[3];
- unsigned intubrdiv;
- union br_rest rest;
- unsigned char res3[0x3d0];
-};
-
-static inline int s5p_uart_divslot(void)
-{
- return 1;
-}
-
-#endif /* __ASSEMBLY__ */
-
-#endif
diff --git a/arch/arm/include/asm/samsung-common/uart.h
b/arch/arm/include/asm/samsung-common/uart.h new file mode 100644
index 000..ce92399
--- /dev/null
+++ b/arch/arm/include/asm/samsung-common/uart.h
@@ -0,0 +1,64 @@
+/*
+ * (C) Copyright 2009 Samsung Electronics
+ * Minkyu Kang mk7.k...@samsung.com
+ * Heungjun Kim riverful@samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_UART_H_
+#define __ASM_ARCH_UART_H_
+
+#ifndef __ASSEMBLY__
+/* baudrate rest value */
+union br_rest {
+ unsigned short slot; /* udivslot */
+ unsigned char value; /* ufracval */
+};
+
+struct s5p_uart {
+ unsigned intulcon;
+ unsigned intucon;
+ unsigned int
[U-Boot] [PATCH] PCIe:change the method to get the address of a requested capability in configuration space.
Previously, the address of a requested capability is define like that
#define PCI_DCR0x78
But, the addresses of capabilities is different with regard to PCIe revs.
So this method is not flexible.
Now a function to get the address of a requested capability is added and used.
It can get the address dynamically by capability ID.
The step of this function:
1. Read Status register in PCIe configuration space to confirm that
Capabilities List is valid.
2. Find the address of Capabilities Pointer Register.
3. Find the address of requested capability from the first capability.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
arch/powerpc/include/asm/fsl_pci.h | 13 +---
drivers/pci/fsl_pci_init.c | 44 +++---
drivers/pci/pci.c | 65 ++
include/pci.h | 10 ++
4 files changed, 108 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_pci.h
b/arch/powerpc/include/asm/fsl_pci.h
index 90b0a2f..6b12afa 100644
--- a/arch/powerpc/include/asm/fsl_pci.h
+++ b/arch/powerpc/include/asm/fsl_pci.h
@@ -32,22 +32,11 @@
/* Freescale-specific PCI config registers */
#define FSL_PCI_PBFR 0x44
-#ifdef CONFIG_SYS_FSL_PCI_VER_3_X
+#ifndef CONFIG_SYS_FSL_PCI_VER_3_X
/* Currently only the PCIe capability is used, so hardcode the offset.
* if more capabilities need to be justified, the capability link method
* should be applied here
*/
-#define FSL_PCIE_CAP_ID0x70
-#define PCI_DCR0x78/* PCIe Device Control Register */
-#define PCI_DSR0x7a/* PCIe Device Status Register */
-#define PCI_LSR0x82/* PCIe Link Status Register */
-#define PCI_LCR0x80/* PCIe Link Control Register */
-#else
-#define FSL_PCIE_CAP_ID0x4c
-#define PCI_DCR0x54/* PCIe Device Control Register */
-#define PCI_DSR0x56/* PCIe Device Status Register */
-#define PCI_LSR0x5e/* PCIe Link Status Register */
-#define PCI_LCR0x5c/* PCIe Link Control Register */
#define FSL_PCIE_CFG_RDY 0x4b0
#endif
#define FSL_PCI_CFG_READY 1 /* Endpoint: allow inbound configuration */
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 76337fe..492efcf 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -308,6 +308,15 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
int enabled, r, inbound = 0;
u16 ltssm;
u8 temp8, pcie_cap;
+ int pcie_cap_pos;
+ int pci_dcr;
+ int pci_dsr;
+ int pci_lsr;
+
+#if defined(CONFIG_FSL_PCIE_DISABLE_ASPM)
+ int pci_lcr;
+#endif
+
volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)cfg_addr;
struct pci_region *reg = hose-regions + hose-region_count;
pci_dev_t dev = PCI_BDF(hose-first_busno, 0, 0);
@@ -380,7 +389,12 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
hose-region_count++;
/* see if we are a PCIe or PCI controller */
- pci_hose_read_config_byte(hose, dev, FSL_PCIE_CAP_ID, pcie_cap);
+ pcie_cap_pos = pci_hose_find_capability(hose, dev, PCI_CAP_ID_EXP);
+ pci_dcr = pcie_cap_pos + 0x08;
+ pci_dsr = pcie_cap_pos + 0x0a;
+ pci_lsr = pcie_cap_pos + 0x12;
+
+ pci_hose_read_config_byte(hose, dev, pcie_cap_pos, pcie_cap);
#ifdef CONFIG_SRIO_PCIE_BOOT_MASTER
/* boot from PCIE --master */
@@ -419,15 +433,16 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
* - Master PERR (pci)
* - ICCA (PCIe)
*/
- pci_hose_read_config_dword(hose, dev, PCI_DCR, temp32);
+ pci_hose_read_config_dword(hose, dev, pci_dcr, temp32);
temp32 |= 0xf000e; /* set URR, FER, NFER (but not CER) */
- pci_hose_write_config_dword(hose, dev, PCI_DCR, temp32);
+ pci_hose_write_config_dword(hose, dev, pci_dcr, temp32);
#if defined(CONFIG_FSL_PCIE_DISABLE_ASPM)
+ pci_lcr = pcie_cap_pos + 0x10;
temp32 = 0;
- pci_hose_read_config_dword(hose, dev, PCI_LCR, temp32);
+ pci_hose_read_config_dword(hose, dev, pci_lcr, temp32);
temp32 = ~0x03;/* Disable ASPM */
- pci_hose_write_config_dword(hose, dev, PCI_LCR, temp32);
+ pci_hose_write_config_dword(hose, dev, pci_lcr, temp32);
udelay(1);
#endif
if (pcie_cap == PCI_CAP_ID_EXP) {
@@ -507,7 +522,7 @@ void fsl_pci_init(struct pci_controller *hose, struct
fsl_pci_info *pci_info)
out_be32(pci-pme_msg_int_en, 0x);
/* Print the negotiated PCIe link width */
-
Re: [U-Boot] [PATCH 1/2] net: fec_mxc: Add support for mx6 solo-lite
On Thu, Sep 12, 2013 at 7:41 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Similarly as mx25 and mx53, mx6solo-lite needs to setup the MII gasket for RMII mode. Add support for mx6solo-lite. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Seems safe enough to go into 2013.10, doesn't it? :-) -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 0/5] arm64 patch
From: David Feng feng...@phytium.com.cn The porting has been merged with arm architecture. Most architecture codes are placed in arch/arm/cpu/armv8 directory. Generic board is also supported after a few bugs are fixed. u-boot could be running at EL1 or EL2. Changes for v7: - Integrate SMC9 patch of sharma bhupesh. - remove v8_outer_cache* which is not need currently. - Change license tag. - Mov crt0.S/relocate.S/interrupts.c to arm/lib and rename them with _64 suffix. - Make el3/el2 initializing process of start.S as two separate routines. It could be easier to be replaced with processor specific codes. - Remove exception stack save and restore routine, it is unnecessary now. Changes for v6: - Check the patches with checkpatch.pl and get rid of almost all warnings. There are a few warnings still, but I think it should be that. - change printf format in cmd_pxe.c, use %zd indtead of %ld to format size_t type variable. - add macro PGTABLE_SIZE to identify tlb table size. Changes for v5: - Make modification to inappropriate licensed file and bugs according to ScottWood's advice. Thanks Scott for his checking to these patches. - Enable u-boot's running at EL1. - Get rid of compiling warnings originated from cmd_pxe.c. Changes for v4: - fix the generic board_f.c, remove zero_global_data from init_sequence_f array and move it to board_init_f() function with CONFIG_X86 switch. The previous fixup is inaccurate. - Replace __ARMEB__ with __AARCH64EB__ in byteorder.h and unaligned.h, gcc for aarch64 use __AARCH64EB__ and __AARCH64EL__ to identify endian. - Some modification to README.armv8 Changes for v3: - merge arm64 to arm architecture. David Feng (5): core support of arm64 board support of vexpress_aemv8a generic board patch of manual reloc and zero gd_t 64bit initrd start address support remove compiling warnings MAINTAINERS |4 + arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 38 +++ arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 228 arch/arm/cpu/armv8/config.mk| 16 ++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 68 + arch/arm/cpu/armv8/start.S | 236 + arch/arm/cpu/armv8/timer.c | 80 ++ arch/arm/cpu/armv8/tlb.S| 30 +++ arch/arm/cpu/armv8/u-boot.lds | 71 + arch/arm/include/asm/arch-armv8/gpio.h | 11 + arch/arm/include/asm/arch-armv8/mmu.h | 106 arch/arm/include/asm/byteorder.h| 12 + arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h | 10 + arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 20 ++ arch/arm/include/asm/posix_types.h | 10 + arch/arm/include/asm/proc-armv/ptrace.h | 37 +++ arch/arm/include/asm/proc-armv/system.h | 59 - arch/arm/include/asm/system.h | 84 ++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 + arch/arm/lib/board.c| 16 +- arch/arm/lib/bootm.c| 16 ++ arch/arm/lib/crt0_64.S | 116 arch/arm/lib/interrupts_64.c| 122 + arch/arm/lib/relocate_64.S | 57 board/armltd/dts/vexpress64.dts | 439 +++ board/armltd/vexpress64/Makefile| 27 ++ board/armltd/vexpress64/vexpress64.c| 70 + boards.cfg |1 + common/board_f.c| 19 +- common/board_r.c| 18 ++ common/cmd_pxe.c|4 +- common/fdt_support.c| 66 ++--- common/image.c |1 + doc/README.armv8| 18 ++ examples/standalone/stubs.c | 15 ++ include/configs/vexpress_aemv8a.h | 193 ++ include/image.h |1 + 46 files changed, 2518 insertions(+), 52 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644
[U-Boot] [PATCH v8 4/5] 64bit initrd start address support
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/fdt_support.c | 66 ++
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index b034c98..9bc5821 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,6 +21,34 @@
*/
DECLARE_GLOBAL_DATA_PTR;
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+ const fdt32_t *cell;
+
+ cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+ if (cell fdt32_to_cpu(*cell) == 2)
+ return 8;
+
+ return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+ int shift = (size - 1) * 8;
+ while (size-- 0) {
+ *addr++ = (val shift) 0xff;
+ shift -= 8;
+ }
+}
+
/**
* fdt_getprop_u32_default - Find a node and return it's property or a default
*
@@ -131,9 +159,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
{
- int nodeoffset;
+ int nodeoffset, addr_cell_len;
int err, j, total;
- fdt32_t tmp;
+ fdt64_t tmp;
const char *path;
uint64_t addr, size;
@@ -170,9 +198,11 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
return err;
}
+ addr_cell_len = get_cells_len(fdt, #address-cells);
+
path = fdt_getprop(fdt, nodeoffset, linux,initrd-start, NULL);
if ((path == NULL) || force) {
- tmp = cpu_to_fdt32(initrd_start);
+ write_cell((u8 *)tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-start, tmp, sizeof(tmp));
if (err 0) {
@@ -181,7 +211,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end, int force)
fdt_strerror(err));
return err;
}
- tmp = cpu_to_fdt32(initrd_end);
+ write_cell((u8 *)tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
linux,initrd-end, tmp, sizeof(tmp));
if (err 0) {
@@ -343,34 +373,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, tmp, 4, create);
}
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
- const fdt32_t *cell;
-
- cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
- if (cell fdt32_to_cpu(*cell) == 2)
- return 8;
-
- return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
- int shift = (size - 1) * 8;
- while (size-- 0) {
- *addr++ = (val shift) 0xff;
- shift -= 8;
- }
-}
-
#ifdef CONFIG_NR_DRAM_BANKS
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 5/5] remove compiling warnings
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/cmd_pxe.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index a2fb50a..df58522 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -57,7 +57,7 @@ static int format_mac_pxe(char *outbuf, size_t outbuf_len)
uchar ethaddr[6];
if (outbuf_len 21) {
- printf(outbuf is too small (%d 21)\n, outbuf_len);
+ printf(outbuf is too small (%zd 21)\n, outbuf_len);
return -EINVAL;
}
@@ -100,7 +100,7 @@ static int get_bootfile_path(const char *file_path, char
*bootfile_path,
path_len = (last_slash - bootfile) + 1;
if (bootfile_path_size path_len) {
- printf(bootfile_path too small. (%d %d)\n,
+ printf(bootfile_path too small. (%zd %zd)\n,
bootfile_path_size, path_len);
return -1;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 3/5] generic board patch of manual reloc and zero gd_t
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
common/board_f.c | 19 +++
common/board_r.c | 18 ++
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 0ada1af..f6ca610 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -458,7 +458,7 @@ static int reserve_round_4k(void)
static int reserve_mmu(void)
{
/* reserve TLB table */
- gd-arch.tlb_size = 4096 * 4;
+ gd-arch.tlb_size = PGTABLE_SIZE;
gd-relocaddr -= gd-arch.tlb_size;
/* round down to next 64 kB limit */
@@ -610,7 +610,7 @@ static int reserve_stacks(void)
* TODO(s...@chromium.org): Perhaps create arch_reserve_stack()
* to handle this and put in arch/xxx/lib/stack.c
*/
-# ifdef CONFIG_ARM
+# if defined(CONFIG_ARM) !defined(CONFIG_ARMV8)
# ifdef CONFIG_USE_IRQ
gd-start_addr_sp -= (CONFIG_STACKSIZE_IRQ + CONFIG_STACKSIZE_FIQ);
debug(Reserving %zu Bytes for IRQ stack at: %08lx\n,
@@ -807,11 +807,6 @@ static int mark_bootstage(void)
}
static init_fnc_t init_sequence_f[] = {
-#if !defined(CONFIG_CPM2) !defined(CONFIG_MPC512X) \
- !defined(CONFIG_MPC83xx) !defined(CONFIG_MPC85xx) \
- !defined(CONFIG_MPC86xx) !defined(CONFIG_X86)
- zero_global_data,
-#endif
#ifdef CONFIG_SANDBOX
setup_ram_buf,
#endif
@@ -1001,10 +996,18 @@ void board_init_f(ulong boot_flags)
{
#ifndef CONFIG_X86
gd_t data;
-
gd = data;
#endif
+ /*
+* Zero gd_t first, otherwise the debug print(if DEBUG defined)
+* in initcall_run_list function before zero_global_data is called
+* will go wrong.
+*/
+#ifndef CONFIG_X86
+ zero_global_data();
+#endif
+
gd-flags = boot_flags;
if (initcall_run_list(init_sequence_f))
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..7217e3c 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -157,6 +157,13 @@ static int initr_reloc_global_data(void)
*/
gd-env_addr += gd-relocaddr - CONFIG_SYS_MONITOR_BASE;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the command table manually
+*/
+ fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),
+ ll_entry_count(cmd_tbl_t, cmd));
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
return 0;
}
@@ -899,6 +906,7 @@ init_fnc_t init_sequence_r[] = {
initr_modem,
#endif
run_main_loop,
+ NULL,
};
void board_init_r(gd_t *new_gd, ulong dest_addr)
@@ -906,6 +914,16 @@ void board_init_r(gd_t *new_gd, ulong dest_addr)
#ifndef CONFIG_X86
gd = new_gd;
#endif
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+ /*
+* We have to relocate the init_sequence_r table manually
+*/
+ init_fnc_t *init_fnc_ptr;
+ for (init_fnc_ptr = init_sequence_r; *init_fnc_ptr; ++init_fnc_ptr)
+ *init_fnc_ptr = (init_fnc_t *)
+ ((unsigned long)(*init_fnc_ptr) + gd-reloc_off);
+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
+
if (initcall_run_list(init_sequence_r))
hang();
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 2/5] board support of vexpress_aemv8a
From: David Feng feng...@phytium.com.cn
Signed-off-by: David Feng feng...@phytium.com.cn
---
MAINTAINERS |4 +
board/armltd/dts/vexpress64.dts | 439 ++
board/armltd/vexpress64/Makefile | 27 +++
board/armltd/vexpress64/vexpress64.c | 70 ++
boards.cfg |1 +
include/configs/vexpress_aemv8a.h| 193 +++
6 files changed, 734 insertions(+)
create mode 100644 board/armltd/dts/vexpress64.dts
create mode 100644 board/armltd/vexpress64/Makefile
create mode 100644 board/armltd/vexpress64/vexpress64.c
create mode 100644 include/configs/vexpress_aemv8a.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e50fc4..d142307 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1095,6 +1095,10 @@ Sergey Yanovich ynv...@gmail.com
lp8x4x xscale/pxa
+David Feng feng...@phytium.com.cn
+
+ vexpress_aemv8a ARM ARMV8 (Quad Core)
+
-
Unknown / orphaned boards:
diff --git a/board/armltd/dts/vexpress64.dts b/board/armltd/dts/vexpress64.dts
new file mode 100644
index 000..067fea7
--- /dev/null
+++ b/board/armltd/dts/vexpress64.dts
@@ -0,0 +1,439 @@
+/*
+ * ARM Ltd. Fast Models
+ *
+ * Architecture Envelope Model (AEM) ARMv8-A
+ * ARMAEMv8AMPCT
+ *
+ * RTSM_VE_AEMv8A.lisa
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+ /* boot configurations for u-boot */
+ config {
+ /*bootdelay = 1;*/
+ kernel-offset = 0x10;
+ rootdisk-offset = 0x80;
+ bootcmd = bootm 0x10 0x80:0x200;
+ };
+};
+
+/ {
+ model = RTSM_VE_AEMv8A;
+ compatible = arm,rtsm_ve,aemv8a, arm,vexpress;
+ interrupt-parent = gic;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ /* chosen */
+ /* generated by u-boot */
+
+
+ aliases {
+ serial0 = v2m_serial0;
+ serial1 = v2m_serial1;
+ serial2 = v2m_serial2;
+ serial3 = v2m_serial3;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 0;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 1;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 2;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,armv8;
+ reg = 3;
+ enable-method = spin-table;
+ cpu-release-addr = 0x0 0x8000fff8;
+ };
+ };
+
+ memory@8000 {
+ device_type = memory;
+ reg = 0x 0x8000 0 0x8000,
+ 0x0008 0x8000 0 0x8000;
+ };
+
+ gic: interrupt-controller@2c001000 {
+ compatible = arm,cortex-a15-gic, arm,cortex-a9-gic;
+ #interrupt-cells = 3;
+ #address-cells = 0;
+ interrupt-controller;
+ reg = 0x0 0x2c001000 0 0x1000,
+ 0x0 0x2c002000 0 0x1000,
+ 0x0 0x2c004000 0 0x2000,
+ 0x0 0x2c006000 0 0x2000;
+ interrupts = 1 9 0xf04;
+ };
+
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff01,
+1 14 0xff01,
+1 11 0xff01,
+1 10 0xff01;
+ clock-frequency = 1;
+ };
+
+ pmu {
+ compatible = arm,armv8-pmuv3;
+ interrupts = 0 60 4,
+0 61 4,
+0 62 4,
+0 63 4;
+ };
+
+ smb {
+ compatible = simple-bus;
+
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0 0x0800 0x0400,
+1 0 0 0x1400 0x0400,
+2 0 0 0x1800 0x0400,
+3 0 0 0x1c00 0x0400,
+4 0 0 0x0c00 0x0400,
+5 0 0 0x1000 0x0400;
+
+
[U-Boot] [PATCH v8 1/5] core support of arm64
From: David Feng feng...@phytium.com.cn Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/config.mk |4 + arch/arm/cpu/armv8/Makefile | 38 + arch/arm/cpu/armv8/cache.S | 130 + arch/arm/cpu/armv8/cache_v8.c | 228 + arch/arm/cpu/armv8/config.mk| 16 +++ arch/arm/cpu/armv8/cpu.c| 67 + arch/arm/cpu/armv8/exceptions.S | 68 + arch/arm/cpu/armv8/start.S | 236 +++ arch/arm/cpu/armv8/timer.c | 80 +++ arch/arm/cpu/armv8/tlb.S| 30 arch/arm/cpu/armv8/u-boot.lds | 71 ++ arch/arm/include/asm/arch-armv8/gpio.h | 11 ++ arch/arm/include/asm/arch-armv8/mmu.h | 106 ++ arch/arm/include/asm/byteorder.h| 12 ++ arch/arm/include/asm/cache.h|5 + arch/arm/include/asm/config.h | 10 ++ arch/arm/include/asm/global_data.h |6 +- arch/arm/include/asm/io.h | 15 +- arch/arm/include/asm/macro.h| 20 +++ arch/arm/include/asm/posix_types.h | 10 ++ arch/arm/include/asm/proc-armv/ptrace.h | 37 + arch/arm/include/asm/proc-armv/system.h | 59 +++- arch/arm/include/asm/system.h | 84 +++ arch/arm/include/asm/types.h|4 + arch/arm/include/asm/u-boot.h |4 + arch/arm/include/asm/unaligned.h|2 +- arch/arm/lib/Makefile | 14 ++ arch/arm/lib/board.c| 16 ++- arch/arm/lib/bootm.c| 16 +++ arch/arm/lib/crt0_64.S | 116 +++ arch/arm/lib/interrupts_64.c| 122 arch/arm/lib/relocate_64.S | 57 common/image.c |1 + doc/README.armv8| 18 +++ examples/standalone/stubs.c | 15 ++ include/image.h |1 + 36 files changed, 1719 insertions(+), 10 deletions(-) create mode 100644 arch/arm/cpu/armv8/Makefile create mode 100644 arch/arm/cpu/armv8/cache.S create mode 100644 arch/arm/cpu/armv8/cache_v8.c create mode 100644 arch/arm/cpu/armv8/config.mk create mode 100644 arch/arm/cpu/armv8/cpu.c create mode 100644 arch/arm/cpu/armv8/exceptions.S create mode 100644 arch/arm/cpu/armv8/start.S create mode 100644 arch/arm/cpu/armv8/timer.c create mode 100644 arch/arm/cpu/armv8/tlb.S create mode 100644 arch/arm/cpu/armv8/u-boot.lds create mode 100644 arch/arm/include/asm/arch-armv8/gpio.h create mode 100644 arch/arm/include/asm/arch-armv8/mmu.h create mode 100644 arch/arm/lib/crt0_64.S create mode 100644 arch/arm/lib/interrupts_64.c create mode 100644 arch/arm/lib/relocate_64.S create mode 100644 doc/README.armv8 diff --git a/arch/arm/config.mk b/arch/arm/config.mk index ce3903b..f1c6a7b 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -74,7 +74,9 @@ endif endif # needed for relocation +ifndef CONFIG_ARMV8 LDFLAGS_u-boot += -pie +endif # # FIXME: binutils versions 2.22 have a bug in the assembler where @@ -95,6 +97,8 @@ endif endif # check that only R_ARM_RELATIVE relocations are generated +ifndef CONFIG_ARMV8 ifneq ($(CONFIG_SPL_BUILD),y) ALL-y += checkarmreloc endif +endif diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile new file mode 100644 index 000..b216f27 --- /dev/null +++ b/arch/arm/cpu/armv8/Makefile @@ -0,0 +1,38 @@ +# +# (C) Copyright 2000-2003 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(CPU).o + +START := start.o + +COBJS += cpu.o +COBJS += timer.o +COBJS += cache_v8.o + +SOBJS += exceptions.o +SOBJS += cache.o +SOBJS += tlb.o + +SRCS := $(START:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) +START := $(addprefix $(obj),$(START)) + +all: $(obj).depend $(START) $(LIB) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S new file mode 100644 index 000..419f169 --- /dev/null +++ b/arch/arm/cpu/armv8/cache.S @@ -0,0 +1,130 @@ +/* + * (C) Copyright 2013 + * David Feng feng...@phytium.com.cn + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm-offsets.h +#include config.h +#include version.h +#include asm/macro.h +#include linux/linkage.h + +/* + * void __asm_flush_dcache_level(level) + * + * clean and invalidate one level cache. + * + * x0: cache level + * x1~x9: clobbered + */
[U-Boot] [PATCH v2 2/2] mx6slevk: Add Ethernet support
From: Fabio Estevam fabio.este...@freescale.com
mx6slevk has a SMSC8720 connected in RMII mode.
Add support for it.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Based on FSL BSP, which uses U-boot 2013.04.
Changes since v1:
- Replace access via register + offset style with proper structure
- Fix checkpatch error
arch/arm/cpu/armv7/mx6/clock.c | 30 +
arch/arm/include/asm/arch-mx6/clock.h | 1 +
arch/arm/include/asm/arch-mx6/iomux.h | 5 +++
arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 12 ++
board/freescale/mx6slevk/mx6slevk.c| 68 ++
include/configs/mx6slevk.h | 14 ++
6 files changed, 130 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index 7efb0d2..cd2299d 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -282,6 +282,36 @@ static u32 get_mmdc_ch0_clk(void)
return freq / (podf + 1);
}
+
+int enable_fec_anatop_clock(void)
+{
+ u32 reg = 0;
+ s32 timeout = 10;
+
+ struct anatop_regs __iomem *anatop =
+ (struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
+
+ reg = readl(anatop-pll_enet);
+ if ((reg BM_ANADIG_PLL_ENET_POWERDOWN) ||
+ (!(reg BM_ANADIG_PLL_ENET_LOCK))) {
+ reg = ~BM_ANADIG_PLL_ENET_POWERDOWN;
+ writel(reg, anatop-pll_enet);
+ while (timeout--) {
+ if (readl(anatop-pll_enet) BM_ANADIG_PLL_ENET_LOCK)
+ break;
+ }
+ if (timeout 0)
+ return -ETIMEDOUT;
+ }
+
+ /* Enable FEC clock */
+ reg |= BM_ANADIG_PLL_ENET_ENABLE;
+ reg = ~BM_ANADIG_PLL_ENET_BYPASS;
+ writel(reg, anatop-pll_enet);
+
+ return 0;
+}
+
#else
static u32 get_mmdc_ch0_clk(void)
{
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index c493687..93f29a7 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -50,4 +50,5 @@ void enable_usboh3_clk(unsigned char enable);
int enable_sata_clock(void);
int enable_i2c_clk(unsigned char enable, unsigned i2c_num);
void enable_ipu_clock(void);
+int enable_fec_anatop_clock(void);
#endif /* __ASM_ARCH_CLOCK_H */
diff --git a/arch/arm/include/asm/arch-mx6/iomux.h
b/arch/arm/include/asm/arch-mx6/iomux.h
index f4cfd4f..ff13a1e 100644
--- a/arch/arm/include/asm/arch-mx6/iomux.h
+++ b/arch/arm/include/asm/arch-mx6/iomux.h
@@ -27,6 +27,11 @@
#define IOMUXC_GPR13_SATA_PHY_2_MASK (0x1f2)
#define IOMUXC_GPR13_SATA_PHY_1_MASK (30)
+#define IOMUX_GPR1_FEC_CLOCK_MUX1_SEL_MASK (0x3 17)
+#define IOMUX_GPR1_FEC_CLOCK_MUX2_SEL_MASK (0x1 14)
+#define IOMUX_GPR1_FEC_MASK(IOMUX_GPR1_FEC_CLOCK_MUX1_SEL_MASK \
+ | IOMUX_GPR1_FEC_CLOCK_MUX2_SEL_MASK)
+
#define IOMUXC_GPR13_SATA_PHY_8_RXEQ_0P5DB (024)
#define IOMUXC_GPR13_SATA_PHY_8_RXEQ_1P0DB (124)
#define IOMUXC_GPR13_SATA_PHY_8_RXEQ_1P5DB (224)
diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
index b39a354..5f9c90a 100644
--- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h
@@ -18,5 +18,17 @@ enum {
MX6_PAD_SD2_DAT3__USDHC2_DAT3 =
IOMUX_PAD(0x0570, 0x0268, 0, 0x, 0, 0),
MX6_PAD_UART1_RXD__UART1_RXD=
IOMUX_PAD(0x05A0, 0x0298, 0, 0x07FC, 0, 0),
MX6_PAD_UART1_TXD__UART1_TXD=
IOMUX_PAD(0x05A4, 0x029C, 0, 0x, 0, 0),
+
+ MX6_PAD_FEC_MDC__FEC_MDC=
IOMUX_PAD(0x41c, 0x12c, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_MDIO__FEC_MDIO =
IOMUX_PAD(0x420, 0x130, 0, 0x6f4, 1, 0),
+ MX6_PAD_FEC_CRS_DV__FEC_RX_DV =
IOMUX_PAD(0x418, 0x128, 0, 0x704, 1, 0),
+ MX6_PAD_FEC_RXD0__FEC_RX_DATA0 =
IOMUX_PAD(0x42c, 0x13c, 0, 0x6f8, 0, 0),
+ MX6_PAD_FEC_RXD1__FEC_RX_DATA1 =
IOMUX_PAD(0x430, 0x140, 0, 0x6fc, 1, 0),
+ MX6_PAD_FEC_TX_EN__FEC_TX_EN=
IOMUX_PAD(0x438, 0x148, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_TXD0__FEC_TX_DATA0 =
IOMUX_PAD(0x43c, 0x14c, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_TXD1__FEC_TX_DATA1 =
IOMUX_PAD(0x440, 0x150, 0, 0x000, 0, 0),
+ MX6_PAD_FEC_REF_CLK__FEC_REF_OUT=
IOMUX_PAD(0x424, 0x134, 0x10, 0x000, 0, 0),
+ MX6_PAD_FEC_RX_ER__GPIO_4_19=
IOMUX_PAD(0x0428, 0x0138, 5, 0x, 0, 0),
+ MX6_PAD_FEC_TX_CLK__GPIO_4_21 =
IOMUX_PAD(0x0434, 0x0144, 5, 0x, 0, 0),
};
#endif /* __ASM_ARCH_MX6_MX6SL_PINS_H__ */
diff --git
[U-Boot] [PATCH] boards.cfg: Fix the comment for invoking tools/reformat.py from vim
Add the missing bang (!) to execute external command, otherwise it does not work. Signed-off-by: Axel Lin axel@ingics.com --- boards.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boards.cfg b/boards.cfg index dbd8479..9fc77fb 100644 --- a/boards.cfg +++ b/boards.cfg @@ -38,7 +38,7 @@ # It can be used from a shell: # tools/reformat.py -i -d '-' -s 8 boards.cfg boards0.cfg mv boards0.cfg boards.cfg # It can directly be invoked from vim: -# :%tools/reformat.py -i -d '-' -s 8 +# :%!tools/reformat.py -i -d '-' -s 8 # # Status, Arch, CPU:SPLCPU, SoC, Vendor, Board name, Target, Options, Maintainers ### -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] net: fec_mxc: Add support for mx6 solo-lite
From: Fabio Estevam fabio.este...@freescale.com
Similarly as mx25 and mx53, mx6solo-lite needs to setup the MII gasket for RMII
mode.
Add support for mx6solo-lite.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Based on FSL BSP, which uses U-boot 2013.04.
Changes since v1:
- None
drivers/net/fec_mxc.c | 2 +-
drivers/net/fec_mxc.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index e14a359..f4a0c5d 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -453,7 +453,7 @@ static int fec_open(struct eth_device *edev)
*/
writel(readl(fec-eth-ecntrl) | FEC_ECNTRL_ETHER_EN,
fec-eth-ecntrl);
-#if defined(CONFIG_MX25) || defined(CONFIG_MX53)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX53) || defined(CONFIG_MX6SL)
udelay(100);
/*
* setup the MII gasket for RMII mode
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 4b4f8b7..0717cc6 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -135,7 +135,7 @@ struct ethernet_regs {
uint32_t res14[7]; /* MBAR_ETH + 0x2E4-2FC */
-#if defined(CONFIG_MX25) || defined(CONFIG_MX53)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX53) || defined(CONFIG_MX6SL)
uint16_t miigsk_cfgr; /* MBAR_ETH + 0x300 */
uint16_t res15[3]; /* MBAR_ETH + 0x302-306 */
uint16_t miigsk_enr;/* MBAR_ETH + 0x308 */
@@ -202,7 +202,7 @@ struct ethernet_regs {
#define FEC_X_DES_ACTIVE_TDAR 0x0100
#define FEC_R_DES_ACTIVE_RDAR 0x0100
-#if defined(CONFIG_MX25) || defined(CONFIG_MX53)
+#if defined(CONFIG_MX25) || defined(CONFIG_MX53) || defined(CONFIG_MX6SL)
/* defines for MIIGSK */
/* RMII frequency control: 0=50MHz, 1=5MHz */
#define MIIGSK_CFGR_FRCONT (1 6)
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6DL/S regression in mx6dl_pins.h
Hello Eric, Le 12/09/2013 23:56, Eric Nelson a écrit : Hi all, It seems to be all about displays and mux/pad registers for me these days. I just tracked down an issue related to commit 87d720e0c that causes improper display on our RGB displays. In particular, the pad settings for these two registers lost their drive-strength value: MX6_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2 MX6_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 You're right, it was a mistake for these two pads. I could make the case that things like pad drive strength are a board-level tuning function, and belong in board-specific files, but I think all RGB displays used with i.MX6 need these values (and they should probably match the 6DQ). Let me know if you'd like me to send a patch for this. I have some other notes regarding consolidation of 6DQ and 6DLS that I'll send separately. Regards, Eric Best regards Pierre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
