Re: [U-Boot] [PATCH 2/2] phy: smsc: LAN8710/8720 are not Gbit PHYs
On 12/07/2013 07:06, Fabio Estevam wrote: > On Fri, Jul 12, 2013 at 2:00 AM, Joe Hershberger > wrote: > >> On second thought, it's delegated in patchwork to Stefano and it's >> marked rejected. Why is that Stefano? > > Ok, I think I understand the reason. I asked him to reject the 1/2 > patch of the series (it was a mx28evk related patch). > > This one (2/2) is fine. > > Sorry for the confusion. Yes, I confirm this - I rejected on Fabio's request. 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
Hi Marek, hi Albert, On 12/07/2013 07:57, Albert ARIBAUD wrote: > > This being a bugfix patch, and having been tested twice, I suggest that > it go in 2013.07, maybe with the commit message reduced to its first > paragraph above -- although of course I do appreciate the second one, > except it tends to minimize Marek's own contribution to the fix, which > is by far the most important. Well, a big thank to both of you ! I merge this into u-boot-imx and I will send soon my PR. 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
Afterthought: On Fri, 12 Jul 2013 07:57:18 +0200, Albert ARIBAUD wrote: > except it tends to minimize Marek's own contribution to the fix, which > is by far the most important. 'The most important' 'by far' being of course Marek's contribution, not minimizing it. :) Amicalement, -- Albert. ___ 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
Hi Marek, On Fri, 12 Jul 2013 01:03:04 +0200, Marek Vasut wrote: > The MX28 multi-layer AHB bus can be too slow and trigger the > FEC DMA too early, before all the data hit the DRAM. This patch > ensures the data are written in the RAM before the DMA starts. > Please see the comment in the patch for full details. > > This patch was produced with an amazing help from Albert Aribaud, > who pointed out it can possibly be such a bus synchronisation > issue. > > Signed-off-by: Marek Vasut > Cc: Albert ARIBAUD > Cc: Fabio Estevam > Cc: Stefano Babic > --- > drivers/net/fec_mxc.c | 22 ++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c > index 97bf8fe..ec5b9db 100644 > --- a/drivers/net/fec_mxc.c > +++ b/drivers/net/fec_mxc.c > @@ -737,6 +737,28 @@ static int fec_send(struct eth_device *dev, void > *packet, int length) > flush_dcache_range(addr, addr + size); > > /* > + * Below we read the DMA descriptor's last four bytes back from the > + * DRAM. This is important in order to make sure that all WRITE > + * operations on the bus that were triggered by previous cache FLUSH > + * have completed. > + * > + * Otherwise, on MX28, it is possible to observe a corruption of the > + * DMA descriptors. Please refer to schematic "Figure 1-2" in MX28RM > + * for the bus structure of MX28. The scenario is as follows: > + * > + * 1) ARM core triggers a series of WRITEs on the AHB_ARB2 bus going > + *to DRAM due to flush_dcache_range() > + * 2) ARM core writes the FEC registers via AHB_ARB2 > + * 3) FEC DMA starts reading/writing from/to DRAM via AHB_ARB3 > + * > + * Note that 2) does sometimes finish before 1) due to reordering of > + * WRITE accesses on the AHB bus, therefore triggering 3) before the > + * DMA descriptor is fully written into DRAM. This results in occasional > + * corruption of the DMA descriptor. > + */ > + readl(addr + size - 4); > + > + /* >* Enable SmartDMA transmit task >*/ > fec_tx_task_enable(fec); This being a bugfix patch, and having been tested twice, I suggest that it go in 2013.07, maybe with the commit message reduced to its first paragraph above -- although of course I do appreciate the second one, except it tends to minimize Marek's own contribution to the fix, which is by far the most important. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] phy: smsc: LAN8710/8720 are not Gbit PHYs
On Fri, Jul 12, 2013 at 12:06 AM, Fabio Estevam wrote: > On Fri, Jul 12, 2013 at 2:00 AM, Joe Hershberger > wrote: > >> On second thought, it's delegated in patchwork to Stefano and it's >> marked rejected. Why is that Stefano? > > Ok, I think I understand the reason. I asked him to reject the 1/2 > patch of the series (it was a mx28evk related patch). > > This one (2/2) is fine. > > Sorry for the confusion. OK. That sounds fine. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28evk: Convert to phylib framework
On Fri, Jul 12, 2013 at 1:58 AM, Marek Vasut wrote: > Dear Fabio Estevam, > >> On Fri, Jul 12, 2013 at 1:40 AM, Marek Vasut wrote: >> > Dear Fabio Estevam, >> > >> >> From: Fabio Estevam >> >> >> >> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework. >> >> >> >> One of the advantages of converting to phylib is that we no longer see a >> >> timeout prior to the first transfer in the 'tftp' command. >> >> >> >> Signed-off-by: Fabio Estevam >> >> --- >> >> After applying this patch I get: >> >> >> >> U-Boot 2013.04-11810-gd6d75ec-dirty (Jul 12 2013 - 01:15:03) >> >> >> >> CPU: Freescale i.MX28 rev1.2 at 454 MHz >> >> BOOT: SSP SD/MMC #0, 3V3 >> >> DRAM: 128 MiB >> >> MMC: MXS MMC: 0 >> >> Video: MXSFB: 'videomode' variable not set! >> >> In:serial >> >> Out: serial >> >> Err: serial >> >> Net: Phy not found >> >> >> >> I still get this 'Phy not found' message, but I think this is not >> >> related to the board code. >> > >> > This is because PHYlib doesn't know your PHY. You might need to add a >> > definition for it into drivers/net/phy/smsc.c >> >> mx28evk uses a LAN8270. >> >> drivers/net/phy/smsc.c has an entry for "SMSC LAN8710/LAN8720", so not >> sure why it fails to recognize it. >> I haven't debugged it yet. >> >> Which phy does sc_sps_1.h use? Is it also a 8720? Is the phy recognized on >> boot? > > I think it's 8720 , but it's recognised , yes. Are you sure the PHY addresses > are correct ? You can dig into phylib a bit and see what IDs does it report. I think Fabio needs to define CONFIG_PHY_SMSC and use PHY address 3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot timeout with KSZ8021 phy
On Fri, Jul 12, 2013 at 1:06 AM, Marek Vasut wrote: > Dear Alexandre Pereira da Silva, > >> On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote: >> > Dear Alexandre Pereira da Silva, >> > >> >> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote: >> > Make sure to check the direction too, it can go either from phy to fec or >> > the other way IIRC. >> >> Ok, it seems this was caused by a bad tftp server and not by the board >> itself. >> >> I can confirm KSZ8021 is functional, after defining CONFIG_PHYLIB to >> mx28evk.h > > OK, good to hear! Btw. the MX28EVK uses LAN8720 PHY, it is the M28EVK that > uses > the Micrel PHY. > > btw. I suspect you should really split away your platform into separate space > instead of hacking around various boards ;-) Yes, I will do that, but the first priority was to get it working :-) Thanks for your help solving this issue. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] omap3_beagle: remove JFFS2 support.
On Thu, Jul 11, 2013 at 10:49 PM, Nishanth Menon wrote: > On 21:49-20130711, Joel Fernandes wrote: >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote: >> > We do not use JFFS2 by default and it conflicts with >> > CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our >> > BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2 >> > >> > Signed-off-by: Nishanth Menon >> > --- >> > include/configs/omap3_beagle.h |8 >> > 1 file changed, 8 deletions(-) >> > >> > diff --git a/include/configs/omap3_beagle.h >> > b/include/configs/omap3_beagle.h >> > index 48ce4c0..9adf4a5 100644 >> > --- a/include/configs/omap3_beagle.h >> > +++ b/include/configs/omap3_beagle.h >> > @@ -150,7 +150,6 @@ >> > #define CONFIG_CMD_CACHE >> > #define CONFIG_CMD_EXT2/* EXT2 Support */ >> > #define CONFIG_CMD_FAT /* FAT support */ >> > -#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ >> > #define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */ >> > #define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ >> > #define MTDIDS_DEFAULT "nand0=nand" >> > @@ -203,13 +202,6 @@ >> > >> > #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of >> > NAND */ >> > /* devices */ >> > -#define CONFIG_JFFS2_NAND >> > -/* nand device jffs2 lives on */ >> > -#define CONFIG_JFFS2_DEV "nand0" >> > -/* start of jffs2 partition */ >> > -#define CONFIG_JFFS2_PART_OFFSET 0x68 >> > -#define CONFIG_JFFS2_PART_SIZE 0xf98 /* size of jffs2 */ >> > >> >> Minor nit, can we perhaps leave the JFFS configuration and only >> remove/comment >> CONFIG_CMD_JFFS. That way we wont lose these paritition offsets/size for >> folks >> who might need them. > then we have to drop the usage of FS_GENERIC. code wont build with both. No I meant drop CMD_JFFS but not the other JFFS. > There is no point in keeping something as an option if it cant be used. > dont you agree? Either way is OK with me, you have a point too. Thanks, -Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot timeout with KSZ8021 phy
On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote: > Dear Alexandre Pereira da Silva, > >> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote: > > Make sure to check the direction too, it can go either from phy to fec or the > other way IIRC. Ok, it seems this was caused by a bad tftp server and not by the board itself. I can confirm KSZ8021 is functional, after defining CONFIG_PHYLIB to mx28evk.h Thanks ___ 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 Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote: > On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote: >> The MX28 multi-layer AHB bus can be too slow and trigger the >> FEC DMA too early, before all the data hit the DRAM. This patch >> ensures the data are written in the RAM before the DMA starts. >> Please see the comment in the patch for full details. >> >> This patch was produced with an amazing help from Albert Aribaud, >> who pointed out it can possibly be such a bus synchronisation >> issue. >> >> Signed-off-by: Marek Vasut >> Cc: Albert ARIBAUD >> Cc: Fabio Estevam >> Cc: Stefano Babic > > Excellent, managed to transfer 90MB via TFTP on mx28evk without a > single timeout. > > Tested-by: Fabio Estevam It's working here too. Tested-by: Alexandre Pereira da Silva ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] phy: smsc: LAN8710/8720 are not Gbit PHYs
On Fri, Jul 12, 2013 at 2:00 AM, Joe Hershberger wrote: > On second thought, it's delegated in patchwork to Stefano and it's > marked rejected. Why is that Stefano? Ok, I think I understand the reason. I asked him to reject the 1/2 patch of the series (it was a mx28evk related patch). This one (2/2) is fine. Sorry for the confusion. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] phy: smsc: LAN8710/8720 are not Gbit PHYs
On Thu, Jul 11, 2013 at 11:57 PM, Joe Hershberger wrote: > On Thu, Jul 11, 2013 at 9:45 PM, Fabio Estevam wrote: >> Hi Joe, >> >> On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam wrote: >>> From: Fabio Estevam >>> >>> LAN8710/8720 are 10/100 Mbps PHYs, so fix the '.features' field. >>> >>> Cc: Joe Hershberger >>> Cc: Nobuhiro Iwamatsu >>> Signed-off-by: Fabio Estevam >> >> Any comments? > > > Seems pretty reasonable. I'll pick it up for next release. On second thought, it's delegated in patchwork to Stefano and it's marked rejected. Why is that Stefano? -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx28evk: Convert to phylib framework
Dear Fabio Estevam, > On Fri, Jul 12, 2013 at 1:40 AM, Marek Vasut wrote: > > Dear Fabio Estevam, > > > >> From: Fabio Estevam > >> > >> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework. > >> > >> One of the advantages of converting to phylib is that we no longer see a > >> timeout prior to the first transfer in the 'tftp' command. > >> > >> Signed-off-by: Fabio Estevam > >> --- > >> After applying this patch I get: > >> > >> U-Boot 2013.04-11810-gd6d75ec-dirty (Jul 12 2013 - 01:15:03) > >> > >> CPU: Freescale i.MX28 rev1.2 at 454 MHz > >> BOOT: SSP SD/MMC #0, 3V3 > >> DRAM: 128 MiB > >> MMC: MXS MMC: 0 > >> Video: MXSFB: 'videomode' variable not set! > >> In:serial > >> Out: serial > >> Err: serial > >> Net: Phy not found > >> > >> I still get this 'Phy not found' message, but I think this is not > >> related to the board code. > > > > This is because PHYlib doesn't know your PHY. You might need to add a > > definition for it into drivers/net/phy/smsc.c > > mx28evk uses a LAN8270. > > drivers/net/phy/smsc.c has an entry for "SMSC LAN8710/LAN8720", so not > sure why it fails to recognize it. > I haven't debugged it yet. > > Which phy does sc_sps_1.h use? Is it also a 8720? Is the phy recognized on > boot? I think it's 8720 , but it's recognised , yes. Are you sure the PHY addresses are correct ? You can dig into phylib a bit and see what IDs does it report. 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 2/2] phy: smsc: LAN8710/8720 are not Gbit PHYs
On Thu, Jul 11, 2013 at 9:45 PM, Fabio Estevam wrote: > Hi Joe, > > On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam wrote: >> From: Fabio Estevam >> >> LAN8710/8720 are 10/100 Mbps PHYs, so fix the '.features' field. >> >> Cc: Joe Hershberger >> Cc: Nobuhiro Iwamatsu >> Signed-off-by: Fabio Estevam > > Any comments? Seems pretty reasonable. I'll pick it up for next release. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx28evk: Convert to phylib framework
From: Fabio Estevam
mx28evk has a LAN8270 ethernet phy and we can use the phylib framework.
One of the advantages of converting to phylib is that we no longer see a timeout
prior to the first transfer in the 'tftp' command.
Signed-off-by: Fabio Estevam
---
After applying this patch I get:
U-Boot 2013.04-11810-gd6d75ec-dirty (Jul 12 2013 - 01:15:03)
CPU: Freescale i.MX28 rev1.2 at 454 MHz
BOOT: SSP SD/MMC #0, 3V3
DRAM: 128 MiB
MMC: MXS MMC: 0
Video: MXSFB: 'videomode' variable not set!
In:serial
Out: serial
Err: serial
Net: Phy not found
I still get this 'Phy not found' message, but I think this is not related to the
board code.
board/freescale/mx28evk/mx28evk.c | 15 +--
include/configs/mx28evk.h | 3 ++-
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/board/freescale/mx28evk/mx28evk.c
b/board/freescale/mx28evk/mx28evk.c
index 4edd9f4..cd81d58 100644
--- a/board/freescale/mx28evk/mx28evk.c
+++ b/board/freescale/mx28evk/mx28evk.c
@@ -110,7 +110,6 @@ int board_eth_init(bd_t *bis)
{
struct mxs_clkctrl_regs *clkctrl_regs =
(struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
- struct eth_device *dev;
int ret;
ret = cpu_eth_init(bis);
@@ -133,24 +132,12 @@ int board_eth_init(bd_t *bis)
return ret;
}
- ret = fecmxc_initialize_multi(bis, 1, 3, MXS_ENET1_BASE);
+ ret = fecmxc_initialize_multi(bis, 1, 1, MXS_ENET1_BASE);
if (ret) {
puts("FEC MXS: Unable to init FEC1\n");
return ret;
}
- dev = eth_get_dev_by_name("FEC0");
- if (!dev) {
- puts("FEC MXS: Unable to get FEC0 device entry\n");
- return -EINVAL;
- }
-
- dev = eth_get_dev_by_name("FEC1");
- if (!dev) {
- puts("FEC MXS: Unable to get FEC1 device entry\n");
- return -EINVAL;
- }
-
return ret;
}
diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index de69182..2431b83 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -170,12 +170,13 @@
/* Ethernet on SOC (FEC) */
#ifdef CONFIG_CMD_NET
-#define CONFIG_NET_MULTI
#define CONFIG_ETHPRIME"FEC0"
#define CONFIG_FEC_MXC
#define CONFIG_MII
#define CONFIG_FEC_XCV_TYPERMII
#define CONFIG_MX28_FEC_MAC_IN_OCOTP
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_SMSC
#endif
/* RTC */
--
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] mx28evk: Convert to phylib framework
On Fri, Jul 12, 2013 at 1:40 AM, Marek Vasut wrote: > Dear Fabio Estevam, > >> From: Fabio Estevam >> >> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework. >> >> One of the advantages of converting to phylib is that we no longer see a >> timeout prior to the first transfer in the 'tftp' command. >> >> Signed-off-by: Fabio Estevam >> --- >> After applying this patch I get: >> >> U-Boot 2013.04-11810-gd6d75ec-dirty (Jul 12 2013 - 01:15:03) >> >> CPU: Freescale i.MX28 rev1.2 at 454 MHz >> BOOT: SSP SD/MMC #0, 3V3 >> DRAM: 128 MiB >> MMC: MXS MMC: 0 >> Video: MXSFB: 'videomode' variable not set! >> In:serial >> Out: serial >> Err: serial >> Net: Phy not found >> >> I still get this 'Phy not found' message, but I think this is not related >> to the board code. > > This is because PHYlib doesn't know your PHY. You might need to add a > definition > for it into drivers/net/phy/smsc.c mx28evk uses a LAN8270. drivers/net/phy/smsc.c has an entry for "SMSC LAN8710/LAN8720", so not sure why it fails to recognize it. I haven't debugged it yet. Which phy does sc_sps_1.h use? Is it also a 8720? Is the phy recognized on boot? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot timeout with KSZ8021 phy
Dear Alexandre Pereira da Silva, > On Fri, Jul 12, 2013 at 1:06 AM, Marek Vasut wrote: > > Dear Alexandre Pereira da Silva, > > > >> On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote: > >> > Dear Alexandre Pereira da Silva, > >> > > >> >> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote: > >> > Make sure to check the direction too, it can go either from phy to fec > >> > or the other way IIRC. > >> > >> Ok, it seems this was caused by a bad tftp server and not by the board > >> itself. > >> > >> I can confirm KSZ8021 is functional, after defining CONFIG_PHYLIB to > >> mx28evk.h > > > > OK, good to hear! Btw. the MX28EVK uses LAN8720 PHY, it is the M28EVK > > that uses the Micrel PHY. > > > > btw. I suspect you should really split away your platform into separate > > space instead of hacking around various boards ;-) > > Yes, I will do that, but the first priority was to get it working :-) > > Thanks for your help solving this issue. No problem, nice to hear it works ;-) 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] mx28evk: Convert to phylib framework
Dear Fabio Estevam,
> From: Fabio Estevam
>
> mx28evk has a LAN8270 ethernet phy and we can use the phylib framework.
>
> One of the advantages of converting to phylib is that we no longer see a
> timeout prior to the first transfer in the 'tftp' command.
>
> Signed-off-by: Fabio Estevam
> ---
> After applying this patch I get:
>
> U-Boot 2013.04-11810-gd6d75ec-dirty (Jul 12 2013 - 01:15:03)
>
> CPU: Freescale i.MX28 rev1.2 at 454 MHz
> BOOT: SSP SD/MMC #0, 3V3
> DRAM: 128 MiB
> MMC: MXS MMC: 0
> Video: MXSFB: 'videomode' variable not set!
> In:serial
> Out: serial
> Err: serial
> Net: Phy not found
>
> I still get this 'Phy not found' message, but I think this is not related
> to the board code.
This is because PHYlib doesn't know your PHY. You might need to add a
definition
for it into drivers/net/phy/smsc.c
> board/freescale/mx28evk/mx28evk.c | 15 +--
> include/configs/mx28evk.h | 3 ++-
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/board/freescale/mx28evk/mx28evk.c
> b/board/freescale/mx28evk/mx28evk.c index 4edd9f4..cd81d58 100644
> --- a/board/freescale/mx28evk/mx28evk.c
> +++ b/board/freescale/mx28evk/mx28evk.c
> @@ -110,7 +110,6 @@ int board_eth_init(bd_t *bis)
> {
> struct mxs_clkctrl_regs *clkctrl_regs =
> (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
> - struct eth_device *dev;
> int ret;
>
> ret = cpu_eth_init(bis);
> @@ -133,24 +132,12 @@ int board_eth_init(bd_t *bis)
> return ret;
> }
>
> - ret = fecmxc_initialize_multi(bis, 1, 3, MXS_ENET1_BASE);
> + ret = fecmxc_initialize_multi(bis, 1, 1, MXS_ENET1_BASE);
Are you sure the PHY address on the MII bus for FEC1 is 0x01 ?
[..]
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 1/5] omap3_beagle: remove JFFS2 support.
On 23:25-20130711, Joel Fernandes wrote: > On Thu, Jul 11, 2013 at 10:49 PM, Nishanth Menon wrote: > > On 21:49-20130711, Joel Fernandes wrote: > >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote: > >> > We do not use JFFS2 by default and it conflicts with > >> > CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our > >> > BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2 > >> > > >> > Signed-off-by: Nishanth Menon > >> > --- > >> > include/configs/omap3_beagle.h |8 > >> > 1 file changed, 8 deletions(-) > >> > > >> > diff --git a/include/configs/omap3_beagle.h > >> > b/include/configs/omap3_beagle.h > >> > index 48ce4c0..9adf4a5 100644 > >> > --- a/include/configs/omap3_beagle.h > >> > +++ b/include/configs/omap3_beagle.h > >> > @@ -150,7 +150,6 @@ > >> > #define CONFIG_CMD_CACHE > >> > #define CONFIG_CMD_EXT2/* EXT2 Support > >> > */ > >> > #define CONFIG_CMD_FAT /* FAT support */ > >> > -#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ > >> > #define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */ > >> > #define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ > >> > #define MTDIDS_DEFAULT "nand0=nand" > >> > @@ -203,13 +202,6 @@ > >> > > >> > #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of > >> > NAND */ > >> > /* devices */ > >> > -#define CONFIG_JFFS2_NAND > >> > -/* nand device jffs2 lives on */ > >> > -#define CONFIG_JFFS2_DEV "nand0" > >> > -/* start of jffs2 partition */ > >> > -#define CONFIG_JFFS2_PART_OFFSET 0x68 > >> > -#define CONFIG_JFFS2_PART_SIZE 0xf98 /* size of jffs2 > >> > */ > >> > > >> > >> Minor nit, can we perhaps leave the JFFS configuration and only > >> remove/comment > >> CONFIG_CMD_JFFS. That way we wont lose these paritition offsets/size for > >> folks > >> who might need them. > > then we have to drop the usage of FS_GENERIC. code wont build with both. > > No I meant drop CMD_JFFS but not the other JFFS. Those wont come into play unless CMD_JFFS2 is enabled, and as stated, makes no sense to keep the second part around and trick some poor bloke into thinking CMD_JFFS2 was left out by mistake.. > > > There is no point in keeping something as an option if it cant be used. > > dont you agree? > > Either way is OK with me, you have a point too. OK, will take this to mean that you are ok with the patch as is. Thanks for the review. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot timeout with KSZ8021 phy
Dear Alexandre Pereira da Silva, > On Thu, Jul 11, 2013 at 5:36 PM, Marek Vasut wrote: > > Dear Alexandre Pereira da Silva, > > > >> On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote: > > Make sure to check the direction too, it can go either from phy to fec or > > the other way IIRC. > > Ok, it seems this was caused by a bad tftp server and not by the board > itself. > > I can confirm KSZ8021 is functional, after defining CONFIG_PHYLIB to > mx28evk.h OK, good to hear! Btw. the MX28EVK uses LAN8720 PHY, it is the M28EVK that uses the Micrel PHY. btw. I suspect you should really split away your platform into separate space instead of hacking around various boards ;-) 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 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On 18:17-20130711, Robert Nelson wrote:
> On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon wrote:
> > On 17:05-20130711, Robert Nelson wrote:
> >> On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
> >> > On 17:02-20130711, Robert Nelson wrote:
> >> >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> >> >> > For folks not using concatenated device tree with uImage, having
> >> >> > an handy function to find and load device tree is very handy.
> >> >> >
> >> >> > So introduce findfdt and loadfdt and run findfdt by default to make
> >> >> > it easier on user scripts.
> >> >> >
> >> >> > Signed-off-by: Nishanth Menon
> >> >> > ---
> >> >> > include/configs/omap3_beagle.h | 17 +
> >> >> > 1 file changed, 17 insertions(+)
> >> >> >
> >> >> > diff --git a/include/configs/omap3_beagle.h
> >> >> > b/include/configs/omap3_beagle.h
> >> >> > index bdeee17..7833208 100644
> >> >> > --- a/include/configs/omap3_beagle.h
> >> >> > +++ b/include/configs/omap3_beagle.h
> >> >> > @@ -210,6 +210,8 @@
> >> >> > #define CONFIG_EXTRA_ENV_SETTINGS \
> >> >> > "loadaddr=0x8020\0" \
> >> >> > "rdaddr=0x8100\0" \
> >> >> > + "fdt_high=0x\0" \
> >> >> > + "fdtaddr=0x80f8\0" \
> >> >> > "usbtty=cdc_acm\0" \
> >> >> > "bootfile=uImage\0" \
> >> >> > "ramdisk=ramdisk.gz\0" \
> >> >> > @@ -250,6 +252,19 @@
> >> >> > "omapdss.def_disp=${defaultdisplay} " \
> >> >> > "root=${nandroot} " \
> >> >> > "rootfstype=${nandrootfstype}\0" \
> >> >> > + "findfdt=" \
> >> >> > + "if test $beaglerev = AxBx; then " \
> >> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
> >> >> > + "if test $beaglerev = Cx; then " \
> >> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
> >> >> > + "if test $beaglerev = xMA; then " \
> >> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
> >> >> > + "if test $beaglerev = xMB; then " \
> >> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
> >> >>
> >> >> There is no need for the "xMB" variant, as the gpio pins used for
> >> >> identification where never changed from the xMA when the newer silcon
> >> >> was used for the xMB (i guess if we look at the omap's es revision, we
> >> >> could figure out which are xMB's, but right now that isn't done in
> >> >> u-boot)
> >> > I suppose then the following is ok to do as well?
> >> > diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
> >> > index c686f40..6094b0f 100644
> >> > --- a/board/ti/beagle/beagle.c
> >> > +++ b/board/ti/beagle/beagle.c
> >> > @@ -369,16 +369,6 @@ int misc_init_r(void)
> >> >
> >> > TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
> >> > TWL4030_PM_RECEIVER_DEV_GRP_P1);
> >> > break;
> >> > - case REVISION_XM_B:
> >> > - printf("Beagle xM Rev B\n");
> >> > - setenv("beaglerev", "xMB");
> >> > - MUX_BEAGLE_XM();
> >> > - /* Set VAUX2 to 1.8V for EHCI PHY */
> >> > -
> >> > twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
> >> > -
> >> > TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
> >> > -
> >> > TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
> >> > - TWL4030_PM_RECEIVER_DEV_GRP_P1);
> >> > - break;
> >> > case REVI
Re: [U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
Hi, > On Thu, Jul 11, 2013 at 8:18 PM, Fabio Estevam wrote: > > On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote: > >> The MX28 multi-layer AHB bus can be too slow and trigger the > >> FEC DMA too early, before all the data hit the DRAM. This patch > >> ensures the data are written in the RAM before the DMA starts. > >> Please see the comment in the patch for full details. > >> > >> This patch was produced with an amazing help from Albert Aribaud, > >> who pointed out it can possibly be such a bus synchronisation > >> issue. > >> > >> Signed-off-by: Marek Vasut > >> Cc: Albert ARIBAUD > >> Cc: Fabio Estevam > >> Cc: Stefano Babic > > > > Excellent, managed to transfer 90MB via TFTP on mx28evk without a > > single timeout. > > > > Tested-by: Fabio Estevam > > It's working here too. > > Tested-by: Alexandre Pereira da Silva Nice to hear, thank Albert for finding this. 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 1/5] omap3_beagle: remove JFFS2 support.
On 21:49-20130711, Joel Fernandes wrote: > On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote: > > We do not use JFFS2 by default and it conflicts with > > CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our > > BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2 > > > > Signed-off-by: Nishanth Menon > > --- > > include/configs/omap3_beagle.h |8 > > 1 file changed, 8 deletions(-) > > > > diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h > > index 48ce4c0..9adf4a5 100644 > > --- a/include/configs/omap3_beagle.h > > +++ b/include/configs/omap3_beagle.h > > @@ -150,7 +150,6 @@ > > #define CONFIG_CMD_CACHE > > #define CONFIG_CMD_EXT2/* EXT2 Support */ > > #define CONFIG_CMD_FAT /* FAT support */ > > -#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ > > #define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */ > > #define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ > > #define MTDIDS_DEFAULT "nand0=nand" > > @@ -203,13 +202,6 @@ > > > > #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of > > NAND */ > > /* devices */ > > -#define CONFIG_JFFS2_NAND > > -/* nand device jffs2 lives on */ > > -#define CONFIG_JFFS2_DEV "nand0" > > -/* start of jffs2 partition */ > > -#define CONFIG_JFFS2_PART_OFFSET 0x68 > > -#define CONFIG_JFFS2_PART_SIZE 0xf98 /* size of jffs2 */ > > > > Minor nit, can we perhaps leave the JFFS configuration and only remove/comment > CONFIG_CMD_JFFS. That way we wont lose these paritition offsets/size for folks > who might need them. then we have to drop the usage of FS_GENERIC. code wont build with both. There is no point in keeping something as an option if it cant be used. dont you agree? -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] omap3_beagle: remove JFFS2 support.
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote: > We do not use JFFS2 by default and it conflicts with > CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our > BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2 > > Signed-off-by: Nishanth Menon > --- > include/configs/omap3_beagle.h |8 > 1 file changed, 8 deletions(-) > > diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h > index 48ce4c0..9adf4a5 100644 > --- a/include/configs/omap3_beagle.h > +++ b/include/configs/omap3_beagle.h > @@ -150,7 +150,6 @@ > #define CONFIG_CMD_CACHE > #define CONFIG_CMD_EXT2/* EXT2 Support */ > #define CONFIG_CMD_FAT /* FAT support */ > -#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ > #define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */ > #define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ > #define MTDIDS_DEFAULT "nand0=nand" > @@ -203,13 +202,6 @@ > > #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND > */ > /* devices */ > -#define CONFIG_JFFS2_NAND > -/* nand device jffs2 lives on */ > -#define CONFIG_JFFS2_DEV "nand0" > -/* start of jffs2 partition */ > -#define CONFIG_JFFS2_PART_OFFSET 0x68 > -#define CONFIG_JFFS2_PART_SIZE 0xf98 /* size of jffs2 */ > Minor nit, can we perhaps leave the JFFS configuration and only remove/comment CONFIG_CMD_JFFS. That way we wont lose these paritition offsets/size for folks who might need them. Otherwise, Acked-by: Joel Fernandes Thanks, -Joel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] phy: smsc: LAN8710/8720 are not Gbit PHYs
Hi Joe, On Thu, Jun 6, 2013 at 9:04 PM, Fabio Estevam wrote: > From: Fabio Estevam > > LAN8710/8720 are 10/100 Mbps PHYs, so fix the '.features' field. > > Cc: Joe Hershberger > Cc: Nobuhiro Iwamatsu > Signed-off-by: Fabio Estevam Any comments? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nand_util: delete a useless variable
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/nand_util.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index 1d22b52..bf74fe8 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -73,7 +73,6 @@ int nand_erase_opts(nand_info_t *meminfo, const
nand_erase_options_t *opts)
struct jffs2_unknown_node cleanmarker;
erase_info_t erase;
unsigned long erase_length, erased_length; /* in blocks */
- int bbtest = 1;
int result;
int percent_complete = -1;
const char *mtd_device = meminfo->name;
@@ -124,7 +123,7 @@ int nand_erase_opts(nand_info_t *meminfo, const
nand_erase_options_t *opts)
puts("Size of erase exceeds limit\n");
return -EFBIG;
}
- if (!opts->scrub && bbtest) {
+ if (!opts->scrub) {
int ret = mtd_block_isbad(meminfo, erase.addr);
if (ret > 0) {
if (!opts->quiet)
--
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] net: fec: Avoid MX28 bus sync issue
On Thu, Jul 11, 2013 at 8:03 PM, Marek Vasut wrote: > The MX28 multi-layer AHB bus can be too slow and trigger the > FEC DMA too early, before all the data hit the DRAM. This patch > ensures the data are written in the RAM before the DMA starts. > Please see the comment in the patch for full details. > > This patch was produced with an amazing help from Albert Aribaud, > who pointed out it can possibly be such a bus synchronisation > issue. > > Signed-off-by: Marek Vasut > Cc: Albert ARIBAUD > Cc: Fabio Estevam > Cc: Stefano Babic Excellent, managed to transfer 90MB via TFTP on mx28evk without a single timeout. Tested-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 5:17 PM, Nishanth Menon wrote:
> On 17:05-20130711, Robert Nelson wrote:
>> On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
>> > On 17:02-20130711, Robert Nelson wrote:
>> >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
>> >> > For folks not using concatenated device tree with uImage, having
>> >> > an handy function to find and load device tree is very handy.
>> >> >
>> >> > So introduce findfdt and loadfdt and run findfdt by default to make
>> >> > it easier on user scripts.
>> >> >
>> >> > Signed-off-by: Nishanth Menon
>> >> > ---
>> >> > include/configs/omap3_beagle.h | 17 +
>> >> > 1 file changed, 17 insertions(+)
>> >> >
>> >> > diff --git a/include/configs/omap3_beagle.h
>> >> > b/include/configs/omap3_beagle.h
>> >> > index bdeee17..7833208 100644
>> >> > --- a/include/configs/omap3_beagle.h
>> >> > +++ b/include/configs/omap3_beagle.h
>> >> > @@ -210,6 +210,8 @@
>> >> > #define CONFIG_EXTRA_ENV_SETTINGS \
>> >> > "loadaddr=0x8020\0" \
>> >> > "rdaddr=0x8100\0" \
>> >> > + "fdt_high=0x\0" \
>> >> > + "fdtaddr=0x80f8\0" \
>> >> > "usbtty=cdc_acm\0" \
>> >> > "bootfile=uImage\0" \
>> >> > "ramdisk=ramdisk.gz\0" \
>> >> > @@ -250,6 +252,19 @@
>> >> > "omapdss.def_disp=${defaultdisplay} " \
>> >> > "root=${nandroot} " \
>> >> > "rootfstype=${nandrootfstype}\0" \
>> >> > + "findfdt=" \
>> >> > + "if test $beaglerev = AxBx; then " \
>> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
>> >> > + "if test $beaglerev = Cx; then " \
>> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
>> >> > + "if test $beaglerev = xMA; then " \
>> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
>> >> > + "if test $beaglerev = xMB; then " \
>> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
>> >>
>> >> There is no need for the "xMB" variant, as the gpio pins used for
>> >> identification where never changed from the xMA when the newer silcon
>> >> was used for the xMB (i guess if we look at the omap's es revision, we
>> >> could figure out which are xMB's, but right now that isn't done in
>> >> u-boot)
>> > I suppose then the following is ok to do as well?
>> > diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
>> > index c686f40..6094b0f 100644
>> > --- a/board/ti/beagle/beagle.c
>> > +++ b/board/ti/beagle/beagle.c
>> > @@ -369,16 +369,6 @@ int misc_init_r(void)
>> > TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>> > TWL4030_PM_RECEIVER_DEV_GRP_P1);
>> > break;
>> > - case REVISION_XM_B:
>> > - printf("Beagle xM Rev B\n");
>> > - setenv("beaglerev", "xMB");
>> > - MUX_BEAGLE_XM();
>> > - /* Set VAUX2 to 1.8V for EHCI PHY */
>> > -
>> > twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
>> > - TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
>> > - TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
>> > - TWL4030_PM_RECEIVER_DEV_GRP_P1);
>> > - break;
>> > case REVISION_XM_C:
>> > printf("Beagle xM Rev C\n");
>> > setenv("beaglerev", "xMC");
>>
>> Correct, as a cleanup we can nuke that xMB section..
>>
>> For some bike shed paining we could rename:
>>
>> Beagle xM Rev A -> Beagle xM Rev A/B
>>
>> Above that too. ;)
> OK - I suspect and am not sure how dvi_pup will get ha
[U-Boot] [PATCH] net: fec: Avoid MX28 bus sync issue
The MX28 multi-layer AHB bus can be too slow and trigger the FEC DMA too early, before all the data hit the DRAM. This patch ensures the data are written in the RAM before the DMA starts. Please see the comment in the patch for full details. This patch was produced with an amazing help from Albert Aribaud, who pointed out it can possibly be such a bus synchronisation issue. Signed-off-by: Marek Vasut Cc: Albert ARIBAUD Cc: Fabio Estevam Cc: Stefano Babic --- drivers/net/fec_mxc.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index 97bf8fe..ec5b9db 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -737,6 +737,28 @@ static int fec_send(struct eth_device *dev, void *packet, int length) flush_dcache_range(addr, addr + size); /* +* Below we read the DMA descriptor's last four bytes back from the +* DRAM. This is important in order to make sure that all WRITE +* operations on the bus that were triggered by previous cache FLUSH +* have completed. +* +* Otherwise, on MX28, it is possible to observe a corruption of the +* DMA descriptors. Please refer to schematic "Figure 1-2" in MX28RM +* for the bus structure of MX28. The scenario is as follows: +* +* 1) ARM core triggers a series of WRITEs on the AHB_ARB2 bus going +*to DRAM due to flush_dcache_range() +* 2) ARM core writes the FEC registers via AHB_ARB2 +* 3) FEC DMA starts reading/writing from/to DRAM via AHB_ARB3 +* +* Note that 2) does sometimes finish before 1) due to reordering of +* WRITE accesses on the AHB bus, therefore triggering 3) before the +* DMA descriptor is fully written into DRAM. This results in occasional +* corruption of the DMA descriptor. +*/ + readl(addr + size - 4); + + /* * Enable SmartDMA transmit task */ fec_tx_task_enable(fec); -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request for u-boot-tegra/master into ARM/master
Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is clean. The following changes since commit 630aacb0859c6e26b2b0311d8e245da5e5b8ac67: Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' (2013-07-10 20:4 0:47 +0200) are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to d035fcf9b6a5a0d7ce8d3d5f3ef960618deea47e: ARM: tegra: enable LCD panel on Ventana (2013-07-11 14:15:16 -0700) Jim Lin (3): ARM: Tegra: FDT: Add USB EHCI function for T30/T114 ARM: Tegra: USB: EHCI: Add support for Tegra30/Tegra114 Tegra: Config: Enable Tegra30/Tegra114 USB function Stephen Warren (2): ARM: tegra: enable LCD panel on Harmony ARM: tegra: enable LCD panel on Ventana arch/arm/dts/tegra114.dtsi| 27 +++ arch/arm/dts/tegra30.dtsi | 27 +++ arch/arm/include/asm/arch-tegra/clk_rst.h | 10 + arch/arm/include/asm/arch-tegra/usb.h | 182 +- arch/arm/include/asm/arch-tegra114/usb.h | 156 +++ arch/arm/include/asm/arch-tegra20/usb.h | 155 +++ arch/arm/include/asm/arch-tegra30/usb.h | 168 + board/nvidia/common/board.c | 1 + board/nvidia/dts/tegra114-dalmore.dts | 7 + board/nvidia/dts/tegra20-harmony.dts | 32 board/nvidia/dts/tegra20-ventana.dts | 32 board/nvidia/dts/tegra30-beaver.dts | 6 + board/nvidia/dts/tegra30-cardhu.dts | 6 + board/nvidia/harmony/harmony.c| 7 + drivers/usb/host/ehci-tegra.c | 304 ++ include/configs/beaver.h | 14 ++ include/configs/cardhu.h | 14 ++ include/configs/dalmore.h | 14 ++ include/configs/harmony.h | 9 + include/configs/tegra114-common.h | 3 + include/configs/tegra30-common.h | 3 + include/configs/ventana.h | 9 + include/fdtdec.h | 2 + lib/fdtdec.c | 2 + 24 files changed, 1015 insertions(+), 175 deletions(-) create mode 100644 arch/arm/include/asm/arch-tegra114/usb.h create mode 100644 arch/arm/include/asm/arch-tegra20/usb.h create mode 100644 arch/arm/include/asm/arch-tegra30/usb.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 5/6] omap3_beagle: support findfdt and loadfdt for devicetree support
On 07/11/2013 05:33 PM, Nishanth Menon wrote:
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index bdeee17..614ab9b 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8020\0" \
"rdaddr=0x8100\0" \
+ "fdt_high=0x\0" \
+ "fdtaddr=0x80f8\0" \
"usbtty=cdc_acm\0" \
"bootfile=uImage\0" \
"ramdisk=ramdisk.gz\0" \
@@ -250,6 +252,19 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${nandroot} " \
"rootfstype=${nandrootfstype}\0" \
+ "findfdt=" \
+ "if test $beaglerev = AxBx; then " \
+ "setenv fdtfile omap3-beagle.dtb; fi; " \
+ "if test $beaglerev = Cx; then " \
+ "setenv fdtfile omap3-beagle.dtb; fi; " \
+ "if test $beaglerev = xMAB; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
+ "if test $beaglerev = xMB; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
OK, this is embarrassing! I should have dropped this! Sigh..
will will wait for more comments and stop spamming list before a new rev.
[...]
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 6/6] omap3_beagle: support booting from zImage and device tree as last option
If no other bootoption works, try loading up device tree and zImage.
This is selected as the last option to allow backward compatibility as
well as support the recent trend in moving kernel boot to using zImage
and device tree.
NOTE: if uImage is present in bootpart, it will try this first and
will assume this is to be booted with bootm (so may be concatenated
image or plain vanilla ATAG MACHINE_ID based image)
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h |8
1 file changed, 8 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 614ab9b..f554de8 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -284,6 +284,9 @@
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr}\0" \
+ "mmcbootz=echo Booting with DT from mmc${mmcdev} ...; " \
+ "run mmcargs; " \
+ "bootz ${loadaddr} - ${fdtaddr}\0" \
"nandboot=echo Booting from nand ...; " \
"run nandargs; " \
"nand read ${loadaddr} 28 40; " \
@@ -318,6 +321,11 @@
"fi;" \
"fi;" \
"run nandboot;" \
+ "setenv bootfile zImage;" \
+ "if run loadimage; then " \
+ "run loadfdt;" \
+ "run mmcbootz; " \
+ "fi; " \
#define CONFIG_AUTO_COMPLETE 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 V2 5/6] omap3_beagle: support findfdt and loadfdt for devicetree support
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index bdeee17..614ab9b 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8020\0" \
"rdaddr=0x8100\0" \
+ "fdt_high=0x\0" \
+ "fdtaddr=0x80f8\0" \
"usbtty=cdc_acm\0" \
"bootfile=uImage\0" \
"ramdisk=ramdisk.gz\0" \
@@ -250,6 +252,19 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${nandroot} " \
"rootfstype=${nandrootfstype}\0" \
+ "findfdt=" \
+ "if test $beaglerev = AxBx; then " \
+ "setenv fdtfile omap3-beagle.dtb; fi; " \
+ "if test $beaglerev = Cx; then " \
+ "setenv fdtfile omap3-beagle.dtb; fi; " \
+ "if test $beaglerev = xMAB; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
+ "if test $beaglerev = xMB; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
+ "if test $beaglerev = xMC; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
+ "if test $fdtfile = undefined; then " \
+ "echo WARNING: Could not determine device tree to use;
fi; \0" \
"bootenv=uEnv.txt\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
@@ -265,6 +280,7 @@
"rootfstype=${ramrootfstype}\0" \
"loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0" \
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
+ "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr}\0" \
@@ -281,6 +297,7 @@
"userbutton_nonxm=gpio input 7;\0"
/* "run userbutton" will return 1 (false) if pressed and 0 (true) if not */
#define CONFIG_BOOTCOMMAND \
+ "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"if run userbutton; then " \
"setenv bootenv uEnv.txt;" \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 4/6] omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk
CMD_FS_GENERIC allows us to simplify where we load up our image from
either from ext2/fat etc. So, lets use that instead of cumbersome
options we currently use. Sticking with existing conventions,
defaults will be:
ramdisk=ramdisk.gz
bootpart=0:2 (second partition)
bootdir=/boot (/boot in second partition)
This matches with the default behavior, these can be overriden by
env files as needed.
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index e152d3c..bdeee17 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -150,6 +150,7 @@
#define CONFIG_CMD_CACHE
#define CONFIG_CMD_EXT2/* EXT2 Support */
#define CONFIG_CMD_FAT /* FAT support */
+#define CONFIG_CMD_FS_GENERIC /* Generic FS support */
#define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */
#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */
#define MTDIDS_DEFAULT "nand0=nand"
@@ -211,6 +212,9 @@
"rdaddr=0x8100\0" \
"usbtty=cdc_acm\0" \
"bootfile=uImage\0" \
+ "ramdisk=ramdisk.gz\0" \
+ "bootdir=/boot\0" \
+ "bootpart=0:2\0" \
"console=ttyO2,115200n8\0" \
"mpurate=auto\0" \
"buddy=none\0" \
@@ -259,9 +263,8 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${ramroot} " \
"rootfstype=${ramrootfstype}\0" \
- "loadramdisk=fatload mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
- "loaduimagefat=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
- "loaduimage=ext2load mmc ${mmcdev}:2 ${loadaddr} /boot/uImage\0" \
+ "loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0" \
+ "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr}\0" \
@@ -293,7 +296,7 @@
"echo Running uenvcmd ...;" \
"run uenvcmd;" \
"fi;" \
- "if run loaduimage; then " \
+ "if run loadimage; then " \
"run mmcboot;" \
"fi;" \
"fi;" \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/6] beagleboard: remove RevB support for BeagleBoard Xm
As reported in http://marc.info/?l=u-boot&m=137358037827735&w=2
There is no need for the "xMB" variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB, So rename XM A revision as AB revision
and report accordingly
Reported-by: Robert Nelson
Signed-off-by: Nishanth Menon
---
board/ti/beagle/beagle.c | 28 +++-
board/ti/beagle/beagle.h |3 +--
2 files changed, 8 insertions(+), 23 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..cc2a783 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -182,8 +182,7 @@ void get_board_mem_timings(struct board_sdrc_timings
*timings)
timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
break;
}
- case REVISION_XM_A:
- case REVISION_XM_B:
+ case REVISION_XM_AB:
case REVISION_XM_C:
if (pop_mfr == 0) {
/* 256MB DDR */
@@ -256,8 +255,7 @@ static void beagle_display_init(void)
case REVISION_C4:
omap3_dss_panel_config(&dvid_cfg);
break;
- case REVISION_XM_A:
- case REVISION_XM_B:
+ case REVISION_XM_AB:
case REVISION_XM_C:
default:
omap3_dss_panel_config(&dvid_cfg_xm);
@@ -276,12 +274,11 @@ static void beagle_dvi_pup(void)
case REVISION_AXBX:
case REVISION_CX:
case REVISION_C4:
- case REVISION_XM_A:
+ case REVISION_XM_AB:
gpio_request(170, "");
gpio_direction_output(170, 0);
gpio_set_value(170, 1);
break;
- case REVISION_XM_B:
case REVISION_XM_C:
default:
#define GPIODATADIR1 (TWL4030_BASEADD_GPIO+3)
@@ -359,19 +356,9 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_A:
- printf("Beagle xM Rev A\n");
- setenv("beaglerev", "xMA");
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
- twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
- TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
- TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
- case REVISION_XM_B:
- printf("Beagle xM Rev B\n");
- setenv("beaglerev", "xMB");
+ case REVISION_XM_AB:
+ printf("Beagle xM Rev A/B\n");
+ setenv("beaglerev", "xMAB");
MUX_BEAGLE_XM();
/* Set VAUX2 to 1.8V for EHCI PHY */
twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
@@ -484,8 +471,7 @@ int misc_init_r(void)
twl4030_power_init();
switch (get_board_revision()) {
- case REVISION_XM_A:
- case REVISION_XM_B:
+ case REVISION_XM_AB:
twl4030_led_init(TWL4030_LED_LEDEN_LEDBON);
break;
default:
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index 6d71bbc..27f8b12 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -39,8 +39,7 @@ const omap3_sysinfo sysinfo = {
#define REVISION_AXBX 0x7
#define REVISION_CX0x6
#define REVISION_C40x5
-#define REVISION_XM_A 0x0
-#define REVISION_XM_B 0x1
+#define REVISION_XM_AB 0x0
#define REVISION_XM_C 0x2
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/6] omap3_beagle: remove JFFS2 support.
We do not use JFFS2 by default and it conflicts with CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2 Signed-off-by: Nishanth Menon --- include/configs/omap3_beagle.h |8 1 file changed, 8 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 48ce4c0..9adf4a5 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -150,7 +150,6 @@ #define CONFIG_CMD_CACHE #define CONFIG_CMD_EXT2/* EXT2 Support */ #define CONFIG_CMD_FAT /* FAT support */ -#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ #define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */ #define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ #define MTDIDS_DEFAULT "nand0=nand" @@ -203,13 +202,6 @@ #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ -#define CONFIG_JFFS2_NAND -/* nand device jffs2 lives on */ -#define CONFIG_JFFS2_DEV "nand0" -/* start of jffs2 partition */ -#define CONFIG_JFFS2_PART_OFFSET 0x68 -#define CONFIG_JFFS2_PART_SIZE 0xf98 /* size of jffs2 */ - /* partition */ /* Environment information */ #define CONFIG_BOOTDELAY 3 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/6] omap3_beagle: configs: improve BOOT_CMD options
With the latest transition to device tree, there is a need to simplify the load of device tree depending on board type etc. While at it, simplify few other changes as well. Testing: with a uEnv.txt as: bootdir=/ bootpart=0:1 The following were the boot results: Beagle (rev C1D): http://pastebin.com/fMdsKkgr Beagle XM (rev C1): http://pastebin.com/p1zp9AhG Changes in V2 since v1: - removed xMB version support based on review comments. http://marc.info/?t=13735797054&r=1&w=2&n=5 V1: http://marc.info/?l=u-boot&m=137357963227510&w=2 Nishanth Menon (6): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage beagleboard: remove RevB support for BeagleBoard Xm omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option board/ti/beagle/beagle.c | 28 ++-- board/ti/beagle/beagle.h |3 +-- include/configs/omap3_beagle.h | 46 3 files changed, 41 insertions(+), 36 deletions(-) Regards, Nishanth Menon -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/6] omap3_beagle: replace uImage.beagle with generic uImage
e682930867f7dfc4a01784fe452fad9e962d65a (BeagleBoard: config: use uImage.beagle for tftp) Introduced uImage.beagle which does not happen to be default output file of Linux kernel build make uImage (output is uImage). So, replace uImage.beagle with uImage Signed-off-by: Nishanth Menon --- include/configs/omap3_beagle.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 9adf4a5..e152d3c 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -210,7 +210,7 @@ "loadaddr=0x8020\0" \ "rdaddr=0x8100\0" \ "usbtty=cdc_acm\0" \ - "bootfile=uImage.beagle\0" \ + "bootfile=uImage\0" \ "console=ttyO2,115200n8\0" \ "mpurate=auto\0" \ "buddy=none\0" \ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On 17:05-20130711, Robert Nelson wrote:
> On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
> > On 17:02-20130711, Robert Nelson wrote:
> >> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> >> > For folks not using concatenated device tree with uImage, having
> >> > an handy function to find and load device tree is very handy.
> >> >
> >> > So introduce findfdt and loadfdt and run findfdt by default to make
> >> > it easier on user scripts.
> >> >
> >> > Signed-off-by: Nishanth Menon
> >> > ---
> >> > include/configs/omap3_beagle.h | 17 +
> >> > 1 file changed, 17 insertions(+)
> >> >
> >> > diff --git a/include/configs/omap3_beagle.h
> >> > b/include/configs/omap3_beagle.h
> >> > index bdeee17..7833208 100644
> >> > --- a/include/configs/omap3_beagle.h
> >> > +++ b/include/configs/omap3_beagle.h
> >> > @@ -210,6 +210,8 @@
> >> > #define CONFIG_EXTRA_ENV_SETTINGS \
> >> > "loadaddr=0x8020\0" \
> >> > "rdaddr=0x8100\0" \
> >> > + "fdt_high=0x\0" \
> >> > + "fdtaddr=0x80f8\0" \
> >> > "usbtty=cdc_acm\0" \
> >> > "bootfile=uImage\0" \
> >> > "ramdisk=ramdisk.gz\0" \
> >> > @@ -250,6 +252,19 @@
> >> > "omapdss.def_disp=${defaultdisplay} " \
> >> > "root=${nandroot} " \
> >> > "rootfstype=${nandrootfstype}\0" \
> >> > + "findfdt=" \
> >> > + "if test $beaglerev = AxBx; then " \
> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
> >> > + "if test $beaglerev = Cx; then " \
> >> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
> >> > + "if test $beaglerev = xMA; then " \
> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
> >> > + "if test $beaglerev = xMB; then " \
> >> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
> >>
> >> There is no need for the "xMB" variant, as the gpio pins used for
> >> identification where never changed from the xMA when the newer silcon
> >> was used for the xMB (i guess if we look at the omap's es revision, we
> >> could figure out which are xMB's, but right now that isn't done in
> >> u-boot)
> > I suppose then the following is ok to do as well?
> > diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
> > index c686f40..6094b0f 100644
> > --- a/board/ti/beagle/beagle.c
> > +++ b/board/ti/beagle/beagle.c
> > @@ -369,16 +369,6 @@ int misc_init_r(void)
> > TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
> > TWL4030_PM_RECEIVER_DEV_GRP_P1);
> > break;
> > - case REVISION_XM_B:
> > - printf("Beagle xM Rev B\n");
> > - setenv("beaglerev", "xMB");
> > - MUX_BEAGLE_XM();
> > - /* Set VAUX2 to 1.8V for EHCI PHY */
> > - twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
> > - TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
> > - TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
> > - TWL4030_PM_RECEIVER_DEV_GRP_P1);
> > - break;
> > case REVISION_XM_C:
> > printf("Beagle xM Rev C\n");
> > setenv("beaglerev", "xMC");
>
> Correct, as a cleanup we can nuke that xMB section..
>
> For some bike shed paining we could rename:
>
> Beagle xM Rev A -> Beagle xM Rev A/B
>
> Above that too. ;)
OK - I suspect and am not sure how dvi_pup will get handled in the
resultant diff, What do folks think of the following?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..01d76a5 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -182,8 +182,7 @@ void get_board_mem_timings(struct board_sdrc_timings
*timings)
timings->rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200M
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 5:03 PM, Nishanth Menon wrote:
> On 17:02-20130711, Robert Nelson wrote:
>> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
>> > For folks not using concatenated device tree with uImage, having
>> > an handy function to find and load device tree is very handy.
>> >
>> > So introduce findfdt and loadfdt and run findfdt by default to make
>> > it easier on user scripts.
>> >
>> > Signed-off-by: Nishanth Menon
>> > ---
>> > include/configs/omap3_beagle.h | 17 +
>> > 1 file changed, 17 insertions(+)
>> >
>> > diff --git a/include/configs/omap3_beagle.h
>> > b/include/configs/omap3_beagle.h
>> > index bdeee17..7833208 100644
>> > --- a/include/configs/omap3_beagle.h
>> > +++ b/include/configs/omap3_beagle.h
>> > @@ -210,6 +210,8 @@
>> > #define CONFIG_EXTRA_ENV_SETTINGS \
>> > "loadaddr=0x8020\0" \
>> > "rdaddr=0x8100\0" \
>> > + "fdt_high=0x\0" \
>> > + "fdtaddr=0x80f8\0" \
>> > "usbtty=cdc_acm\0" \
>> > "bootfile=uImage\0" \
>> > "ramdisk=ramdisk.gz\0" \
>> > @@ -250,6 +252,19 @@
>> > "omapdss.def_disp=${defaultdisplay} " \
>> > "root=${nandroot} " \
>> > "rootfstype=${nandrootfstype}\0" \
>> > + "findfdt=" \
>> > + "if test $beaglerev = AxBx; then " \
>> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
>> > + "if test $beaglerev = Cx; then " \
>> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
>> > + "if test $beaglerev = xMA; then " \
>> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
>> > + "if test $beaglerev = xMB; then " \
>> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
>>
>> There is no need for the "xMB" variant, as the gpio pins used for
>> identification where never changed from the xMA when the newer silcon
>> was used for the xMB (i guess if we look at the omap's es revision, we
>> could figure out which are xMB's, but right now that isn't done in
>> u-boot)
> I suppose then the following is ok to do as well?
> diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
> index c686f40..6094b0f 100644
> --- a/board/ti/beagle/beagle.c
> +++ b/board/ti/beagle/beagle.c
> @@ -369,16 +369,6 @@ int misc_init_r(void)
> TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
> TWL4030_PM_RECEIVER_DEV_GRP_P1);
> break;
> - case REVISION_XM_B:
> - printf("Beagle xM Rev B\n");
> - setenv("beaglerev", "xMB");
> - MUX_BEAGLE_XM();
> - /* Set VAUX2 to 1.8V for EHCI PHY */
> - twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
> - TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
> - TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
> - TWL4030_PM_RECEIVER_DEV_GRP_P1);
> - break;
> case REVISION_XM_C:
> printf("Beagle xM Rev C\n");
> setenv("beaglerev", "xMC");
Correct, as a cleanup we can nuke that xMB section..
For some bike shed paining we could rename:
Beagle xM Rev A -> Beagle xM Rev A/B
Above that too. ;)
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On 17:02-20130711, Robert Nelson wrote:
> On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> > For folks not using concatenated device tree with uImage, having
> > an handy function to find and load device tree is very handy.
> >
> > So introduce findfdt and loadfdt and run findfdt by default to make
> > it easier on user scripts.
> >
> > Signed-off-by: Nishanth Menon
> > ---
> > include/configs/omap3_beagle.h | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> > index bdeee17..7833208 100644
> > --- a/include/configs/omap3_beagle.h
> > +++ b/include/configs/omap3_beagle.h
> > @@ -210,6 +210,8 @@
> > #define CONFIG_EXTRA_ENV_SETTINGS \
> > "loadaddr=0x8020\0" \
> > "rdaddr=0x8100\0" \
> > + "fdt_high=0x\0" \
> > + "fdtaddr=0x80f8\0" \
> > "usbtty=cdc_acm\0" \
> > "bootfile=uImage\0" \
> > "ramdisk=ramdisk.gz\0" \
> > @@ -250,6 +252,19 @@
> > "omapdss.def_disp=${defaultdisplay} " \
> > "root=${nandroot} " \
> > "rootfstype=${nandrootfstype}\0" \
> > + "findfdt=" \
> > + "if test $beaglerev = AxBx; then " \
> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
> > + "if test $beaglerev = Cx; then " \
> > + "setenv fdtfile omap3-beagle.dtb; fi; " \
> > + "if test $beaglerev = xMA; then " \
> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
> > + "if test $beaglerev = xMB; then " \
> > + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
>
> There is no need for the "xMB" variant, as the gpio pins used for
> identification where never changed from the xMA when the newer silcon
> was used for the xMB (i guess if we look at the omap's es revision, we
> could figure out which are xMB's, but right now that isn't done in
> u-boot)
I suppose then the following is ok to do as well?
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index c686f40..6094b0f 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -369,16 +369,6 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM_B:
- printf("Beagle xM Rev B\n");
- setenv("beaglerev", "xMB");
- MUX_BEAGLE_XM();
- /* Set VAUX2 to 1.8V for EHCI PHY */
- twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
- TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
- TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
- TWL4030_PM_RECEIVER_DEV_GRP_P1);
- break;
case REVISION_XM_C:
printf("Beagle xM Rev C\n");
setenv("beaglerev", "xMC");
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
On Thu, Jul 11, 2013 at 4:52 PM, Nishanth Menon wrote:
> For folks not using concatenated device tree with uImage, having
> an handy function to find and load device tree is very handy.
>
> So introduce findfdt and loadfdt and run findfdt by default to make
> it easier on user scripts.
>
> Signed-off-by: Nishanth Menon
> ---
> include/configs/omap3_beagle.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
> index bdeee17..7833208 100644
> --- a/include/configs/omap3_beagle.h
> +++ b/include/configs/omap3_beagle.h
> @@ -210,6 +210,8 @@
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "loadaddr=0x8020\0" \
> "rdaddr=0x8100\0" \
> + "fdt_high=0x\0" \
> + "fdtaddr=0x80f8\0" \
> "usbtty=cdc_acm\0" \
> "bootfile=uImage\0" \
> "ramdisk=ramdisk.gz\0" \
> @@ -250,6 +252,19 @@
> "omapdss.def_disp=${defaultdisplay} " \
> "root=${nandroot} " \
> "rootfstype=${nandrootfstype}\0" \
> + "findfdt=" \
> + "if test $beaglerev = AxBx; then " \
> + "setenv fdtfile omap3-beagle.dtb; fi; " \
> + "if test $beaglerev = Cx; then " \
> + "setenv fdtfile omap3-beagle.dtb; fi; " \
> + "if test $beaglerev = xMA; then " \
> + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
> + "if test $beaglerev = xMB; then " \
> + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
There is no need for the "xMB" variant, as the gpio pins used for
identification where never changed from the xMA when the newer silcon
was used for the xMB (i guess if we look at the omap's es revision, we
could figure out which are xMB's, but right now that isn't done in
u-boot)
> + "if test $beaglerev = xMC; then " \
> + "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
> + "if test $fdtfile = undefined; then " \
> + "echo WARNING: Could not determine device tree to
> use; fi; \0" \
> "bootenv=uEnv.txt\0" \
> "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
> "importbootenv=echo Importing environment from mmc ...; " \
> @@ -265,6 +280,7 @@
> "rootfstype=${ramrootfstype}\0" \
> "loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0" \
> "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0"
> \
> + "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
> "mmcboot=echo Booting from mmc ...; " \
> "run mmcargs; " \
> "bootm ${loadaddr}\0" \
> @@ -281,6 +297,7 @@
> "userbutton_nonxm=gpio input 7;\0"
> /* "run userbutton" will return 1 (false) if pressed and 0 (true) if not */
> #define CONFIG_BOOTCOMMAND \
> + "run findfdt; " \
> "mmc dev ${mmcdev}; if mmc rescan; then " \
> "if run userbutton; then " \
> "setenv bootenv uEnv.txt;" \
> --
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] omap3_beagle: remove JFFS2 support.
We do not use JFFS2 by default and it conflicts with CONFIG_CMD_FS_GENERIC (ls command is the same). Since most of our BOOTCMD can be simplified by using the FS_GENERIC, dropping JFFS2 Signed-off-by: Nishanth Menon --- include/configs/omap3_beagle.h |8 1 file changed, 8 deletions(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 48ce4c0..9adf4a5 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -150,7 +150,6 @@ #define CONFIG_CMD_CACHE #define CONFIG_CMD_EXT2/* EXT2 Support */ #define CONFIG_CMD_FAT /* FAT support */ -#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ #define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */ #define CONFIG_MTD_DEVICE /* needed for mtdparts commands */ #define MTDIDS_DEFAULT "nand0=nand" @@ -203,13 +202,6 @@ #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ -#define CONFIG_JFFS2_NAND -/* nand device jffs2 lives on */ -#define CONFIG_JFFS2_DEV "nand0" -/* start of jffs2 partition */ -#define CONFIG_JFFS2_PART_OFFSET 0x68 -#define CONFIG_JFFS2_PART_SIZE 0xf98 /* size of jffs2 */ - /* partition */ /* Environment information */ #define CONFIG_BOOTDELAY 3 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] omap3_beagle: support booting from zImage and device tree as last option
If no other bootoption works, try loading up device tree and zImage.
This is selected as the last option to allow backward compatibility as
well as support the recent trend in moving kernel boot to using zImage
and device tree.
NOTE: if uImage is present in bootpart, it will try this first and
will assume this is to be booted with bootm (so may be concatenated
image or plain vanilla ATAG MACHINE_ID based image)
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h |8
1 file changed, 8 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 7833208..3c0b059 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -284,6 +284,9 @@
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr}\0" \
+ "mmcbootz=echo Booting with DT from mmc${mmcdev} ...; " \
+ "run mmcargs; " \
+ "bootz ${loadaddr} - ${fdtaddr}\0" \
"nandboot=echo Booting from nand ...; " \
"run nandargs; " \
"nand read ${loadaddr} 28 40; " \
@@ -318,6 +321,11 @@
"fi;" \
"fi;" \
"run nandboot;" \
+ "setenv bootfile zImage;" \
+ "if run loadimage; then " \
+ "run loadfdt;" \
+ "run mmcbootz; " \
+ "fi; " \
#define CONFIG_AUTO_COMPLETE 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 2/5] omap3_beagle: replace uImage.beagle with generic uImage
e682930867f7dfc4a01784fe452fad9e962d65a (BeagleBoard: config: use uImage.beagle for tftp) Introduced uImage.beagle which does not happen to be default output file of Linux kernel build make uImage (output is uImage). So, replace uImage.beagle with uImage Signed-off-by: Nishanth Menon --- include/configs/omap3_beagle.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 9adf4a5..e152d3c 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -210,7 +210,7 @@ "loadaddr=0x8020\0" \ "rdaddr=0x8100\0" \ "usbtty=cdc_acm\0" \ - "bootfile=uImage.beagle\0" \ + "bootfile=uImage\0" \ "console=ttyO2,115200n8\0" \ "mpurate=auto\0" \ "buddy=none\0" \ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] omap3_beagle: configs: improve BOOT_CMD options
With the latest transition to device tree, there is a need to simplify the load of device tree depending on board type etc. While at it, simplify few other changes as well. Testing: with a uEnv.txt as: bootdir=/ bootpart=0:1 The following were the boot results: Beagle (rev C1D): http://pastebin.com/fMdsKkgr Beagle XM (rev C1): http://pastebin.com/p1zp9AhG Nishanth Menon (5): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option include/configs/omap3_beagle.h | 46 1 file changed, 33 insertions(+), 13 deletions(-) Regards, Nishanth Menon -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk
CMD_FS_GENERIC allows us to simplify where we load up our image from
either from ext2/fat etc. So, lets use that instead of cumbersome
options we currently use. Sticking with existing conventions,
defaults will be:
ramdisk=ramdisk.gz
bootpart=0:2 (second partition)
bootdir=/boot (/boot in second partition)
This matches with the default behavior, these can be overriden by
env files as needed.
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index e152d3c..bdeee17 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -150,6 +150,7 @@
#define CONFIG_CMD_CACHE
#define CONFIG_CMD_EXT2/* EXT2 Support */
#define CONFIG_CMD_FAT /* FAT support */
+#define CONFIG_CMD_FS_GENERIC /* Generic FS support */
#define CONFIG_CMD_MTDPARTS/* Enable MTD parts commands */
#define CONFIG_MTD_DEVICE /* needed for mtdparts commands */
#define MTDIDS_DEFAULT "nand0=nand"
@@ -211,6 +212,9 @@
"rdaddr=0x8100\0" \
"usbtty=cdc_acm\0" \
"bootfile=uImage\0" \
+ "ramdisk=ramdisk.gz\0" \
+ "bootdir=/boot\0" \
+ "bootpart=0:2\0" \
"console=ttyO2,115200n8\0" \
"mpurate=auto\0" \
"buddy=none\0" \
@@ -259,9 +263,8 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${ramroot} " \
"rootfstype=${ramrootfstype}\0" \
- "loadramdisk=fatload mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
- "loaduimagefat=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \
- "loaduimage=ext2load mmc ${mmcdev}:2 ${loadaddr} /boot/uImage\0" \
+ "loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0" \
+ "loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr}\0" \
@@ -293,7 +296,7 @@
"echo Running uenvcmd ...;" \
"run uenvcmd;" \
"fi;" \
- "if run loaduimage; then " \
+ "if run loadimage; then " \
"run mmcboot;" \
"fi;" \
"fi;" \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] omap3_beagle: support findfdt and loadfdt for devicetree support
For folks not using concatenated device tree with uImage, having
an handy function to find and load device tree is very handy.
So introduce findfdt and loadfdt and run findfdt by default to make
it easier on user scripts.
Signed-off-by: Nishanth Menon
---
include/configs/omap3_beagle.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index bdeee17..7833208 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -210,6 +210,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8020\0" \
"rdaddr=0x8100\0" \
+ "fdt_high=0x\0" \
+ "fdtaddr=0x80f8\0" \
"usbtty=cdc_acm\0" \
"bootfile=uImage\0" \
"ramdisk=ramdisk.gz\0" \
@@ -250,6 +252,19 @@
"omapdss.def_disp=${defaultdisplay} " \
"root=${nandroot} " \
"rootfstype=${nandrootfstype}\0" \
+ "findfdt=" \
+ "if test $beaglerev = AxBx; then " \
+ "setenv fdtfile omap3-beagle.dtb; fi; " \
+ "if test $beaglerev = Cx; then " \
+ "setenv fdtfile omap3-beagle.dtb; fi; " \
+ "if test $beaglerev = xMA; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
+ "if test $beaglerev = xMB; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
+ "if test $beaglerev = xMC; then " \
+ "setenv fdtfile omap3-beagle-xm.dtb; fi; " \
+ "if test $fdtfile = undefined; then " \
+ "echo WARNING: Could not determine device tree to use;
fi; \0" \
"bootenv=uEnv.txt\0" \
"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
@@ -265,6 +280,7 @@
"rootfstype=${ramrootfstype}\0" \
"loadramdisk=load mmc ${bootpart} ${rdaddr} ${bootdir}/${ramdisk}\0" \
"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
+ "loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"bootm ${loadaddr}\0" \
@@ -281,6 +297,7 @@
"userbutton_nonxm=gpio input 7;\0"
/* "run userbutton" will return 1 (false) if pressed and 0 (true) if not */
#define CONFIG_BOOTCOMMAND \
+ "run findfdt; " \
"mmc dev ${mmcdev}; if mmc rescan; then " \
"if run userbutton; then " \
"setenv bootenv uEnv.txt;" \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/7] The patchset fixes some issue in the generation of the imx image
Thanks Stefano, On 07/11/2013 06:06 AM, Stefano Babic wrote: (header for Freescale's i.MX processors) to allow the usage of Freescale's tools to sign the u-boot image and provide a secure boot. This has nothing to do with the Secure Boot extensions implemented by Simon Glass, that can be in any case used to boot later a secure image. Freescale's secure boot ensures that a signed bootloader is started only if it is verified with a key that is burned into the iMX fuses. Documentation about the Freescale's secure process can be read from the AN4591, available on the Freescale's Website. The patchset allows to add to the imx Header the CSF (command Sequence File) generated by the tools provided by Freescale. The CSF is then simply concatenated to the u-boot image, making a signed bootloader, that the processor can verify if the fuses for the keys are burned. The processor (i.MX53 / i.MX6x) will not start a bootloader that cannot be verified - further infos how to configure the SOC to verify the bootloader can be found in the User Manual of the specific SOC. Next step is to verify the kernel, that can be still done using Simon's patches for verified boot (CONFIG_OF_CONTROL must be set in the board configuarion file). I compile-tested the series against all of our boards (boundary/boundary/* and board/freescale/mx6qsabrelite). Run-time tests (without signing) against nitrogen6s (solo) and nitrogen6q (quad). Both ran without a hitch. Now we need to get configured for signing and burn some fuses! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image: Don't relocate ramdisk to highmem
Dear Thierry Reding, In message <20130711190849.ga17...@dhcp-172-17-186-34.nvidia.com> you wrote: > > > This depends a lot on a number of things. For example, you should be > > able to use a ramdisk in NOR flash directly, i. e. without loading it > > to RAM first - especially if it;s a comprtessed ramdis image, and the > > Kernel will copy/uncompress it anyway. Depending on your memory map > > the address range of the NOR flash may be way outside (and above) that > > of the system RAM. Are you sure your changes will not break any such > > usage? > > As far as I can tell, the only place where initrd_high is used is to > allocate an area from RAM that's used to relocate the ramdisk to. In > case where the ramdisk is directly in NOR and isn't supposed to be > copied anyway, this code should never be run. Agreed. I'm not sure this is what's happening currently, though. > So maybe one other alternative would be to check whether the current > location of the ramdisk is within the low memory area and only relocate > otherwise. Does that match your expectation? Appears to make sense, indeed. But I have to admit that I'm not deep enough into the details of this code at the moment to make a qualified statement. > > ...because default behaviour was do do nothing. Now you do something, > > so this should be documented. > > The default behaviour was to not restrict loading to high memory at all, > which is what the comment said: > > /* not set, no restrictions to load high */ > initrd_high = ~0; > > The patch that I posted changes the above to this: > > /* make sure to put ramdisk in low memory */ > initrd_high = getenv_bootm_low() + getenv_bootm_mapsize(); > > Doesn't that accurately describe the change? I think this shouldbe added to the function header (too). 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 'What shall we do?' said Twoflower. 'Panic?' said Rincewind hope- fully. He always held that panic was the best means of survival; back in the olden days, his theory went, people faced with hungry sabre- toothed tigers could be divided very simply in those who panicked and those who stood there saying 'What a magnificent brute!' or 'Here, pussy.' - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image: Don't relocate ramdisk to highmem
Dear Stephen Warren, In message <51df024c.2080...@wwwdotorg.org> you wrote: > > > This depends a lot on a number of things. For example, you should be > > able to use a ramdisk in NOR flash directly, i. e. without loading it > > to RAM first - especially if it;s a comprtessed ramdis image, and the > > Kernel will copy/uncompress it anyway. > > That would be nice, but I don't believe the kernel supports that (at > least not on ARM): You are right. RMK repeatedly rejected patches to allow this; but it has always been available on other architectures, like PPC. 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 As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot timeout with KSZ8021 phy
Dear Alexandre Pereira da Silva, > On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote: > > Dear Alexandre Pereira da Silva, > > > >> Hi, > >> > >> I am trying to make my ethernet work with u-boot on a custom IMX28 > >> board. > >> > >> This board uses the micrel KSZ8021 phy. > >> > >> The network works fine on linux but won't work properly on u-boot. > >> > >> Here is the output: > >> => dhcp > >> BOOTP broadcast 1 > >> DHCP client bound to address 192.168.1.103 > >> Using FEC device > >> TFTP from server 192.168.1.54; our IP address is 192.168.1.103 > >> Filename 'uImage'. > >> Load address: 0x4200 > >> Loading: T T T T > >> > >> I am using the apx4devkit board configuration > > > > Seems unmaintained :-( > > > >> as a base for my port, > >> but adapted the phy setting to the KSZ8021 needed value. If that phy > >> configuration value is wrong, it doesn't even get an IP address from > >> DHCP. > >> > >> Marek's patch about cache didn't help much in my case. > > > > Try "dcache off" on command line, do you have any luck then ? > > dcache off doesn't help either. > > > Also try copying the network section from M28EVK, as M28EVK uses KSZ8021 > > PHYs. I also noticed the M28EVK resets the PHYs, so maybe you need to > > handle that ? On M28EVK this is handled in board/denx/m28evk/m28evk.c > > By mistake, I forgot to add reset pin for the phy, so I am leaving the > phy always enabled. You really should reset it upon boot, it might be in some confused state. > I did try using M28EVK and MX28EVK board ports as well, but none worked so > far. Can you elaborate? > Do I have do anything special for the NC pins of IMX280? No, just make sure your ethernet pinmux is correct too. > > Moreover, check if your CLKCTRL ENET settings are correct, that's also > > handled in the same function as the PHY reset on M28EVK I think (or at > > least in the same section). > > That doesn't seem to be wrong. I see a clean 50MHZ clock on that pin. Make sure to check the direction too, it can go either from phy to fec or the other way IIRC. 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 0/5] Introducing SPDX-License-Identifiers
Dear Wolfgang Denk, > Like many other projects, U-Boot has a tradition of including big > blocks of License headers in all files. This not only blows up the > source code with mostly redundant information, but also makes it very > difficult to generate License Clearing Reports. An additional problem > is that even the same lincenses are referred to by a number of > slightly varying text blocks (full, abbreviated, different > indentation, line wrapping and/or white space, with obsolete address > information, ...) which makes automatic processing a nightmare. > > To make this easier, such license headers in the source files will be > replaced with a single line reference to Unique Lincense Identifiers > as defined by the Linux Foundation's SPDX project [1]. For example, > in a source file the full "GPL v2.0 or later" header text will be > replaced by a single line: I think we have a winner for this round of u-boot commit statistics ;-) For the MXS part and PXA part, series: Acked-by: Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot timeout with KSZ8021 phy
On Thu, Jul 11, 2013 at 4:55 PM, Marek Vasut wrote: > Dear Alexandre Pereira da Silva, > >> Hi, >> >> I am trying to make my ethernet work with u-boot on a custom IMX28 board. >> >> This board uses the micrel KSZ8021 phy. >> >> The network works fine on linux but won't work properly on u-boot. >> >> Here is the output: >> => dhcp >> BOOTP broadcast 1 >> DHCP client bound to address 192.168.1.103 >> Using FEC device >> TFTP from server 192.168.1.54; our IP address is 192.168.1.103 >> Filename 'uImage'. >> Load address: 0x4200 >> Loading: T T T T >> >> I am using the apx4devkit board configuration > > Seems unmaintained :-( > >> as a base for my port, >> but adapted the phy setting to the KSZ8021 needed value. If that phy >> configuration value is wrong, it doesn't even get an IP address from >> DHCP. >> >> Marek's patch about cache didn't help much in my case. > > Try "dcache off" on command line, do you have any luck then ? dcache off doesn't help either. > Also try copying the network section from M28EVK, as M28EVK uses KSZ8021 > PHYs. I > also noticed the M28EVK resets the PHYs, so maybe you need to handle that ? On > M28EVK this is handled in board/denx/m28evk/m28evk.c By mistake, I forgot to add reset pin for the phy, so I am leaving the phy always enabled. I did try using M28EVK and MX28EVK board ports as well, but none worked so far. Do I have do anything special for the NC pins of IMX280? > Moreover, check if your CLKCTRL ENET settings are correct, that's also handled > in the same function as the PHY reset on M28EVK I think (or at least in the > same > section). That doesn't seem to be wrong. I see a clean 50MHZ clock on that pin. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot timeout with KSZ8021 phy
Hi, I am trying to make my ethernet work with u-boot on a custom IMX28 board. This board uses the micrel KSZ8021 phy. The network works fine on linux but won't work properly on u-boot. Here is the output: => dhcp BOOTP broadcast 1 DHCP client bound to address 192.168.1.103 Using FEC device TFTP from server 192.168.1.54; our IP address is 192.168.1.103 Filename 'uImage'. Load address: 0x4200 Loading: T T T T I am using the apx4devkit board configuration as a base for my port, but adapted the phy setting to the KSZ8021 needed value. If that phy configuration value is wrong, it doesn't even get an IP address from DHCP. Marek's patch about cache didn't help much in my case. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot timeout with KSZ8021 phy
Dear Alexandre Pereira da Silva, > Hi, > > I am trying to make my ethernet work with u-boot on a custom IMX28 board. > > This board uses the micrel KSZ8021 phy. > > The network works fine on linux but won't work properly on u-boot. > > Here is the output: > => dhcp > BOOTP broadcast 1 > DHCP client bound to address 192.168.1.103 > Using FEC device > TFTP from server 192.168.1.54; our IP address is 192.168.1.103 > Filename 'uImage'. > Load address: 0x4200 > Loading: T T T T > > I am using the apx4devkit board configuration Seems unmaintained :-( > as a base for my port, > but adapted the phy setting to the KSZ8021 needed value. If that phy > configuration value is wrong, it doesn't even get an IP address from > DHCP. > > Marek's patch about cache didn't help much in my case. Try "dcache off" on command line, do you have any luck then ? Also try copying the network section from M28EVK, as M28EVK uses KSZ8021 PHYs. I also noticed the M28EVK resets the PHYs, so maybe you need to handle that ? On M28EVK this is handled in board/denx/m28evk/m28evk.c Moreover, check if your CLKCTRL ENET settings are correct, that's also handled in the same function as the PHY reset on M28EVK I think (or at least in the same section). 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] image: Don't relocate ramdisk to highmem
On Thu, Jul 11, 2013 at 08:21:17PM +0200, Wolfgang Denk wrote: > Dear Thierry Reding, > > In message <20130711150014.ga2...@dhcp-172-17-186-34.nvidia.com> you wrote: > > > > > I'm pretty sure it's all architectures, and this is a problem for device > > > trees as well. The tricks done to deal with highmem mean it's not > > > suitable for certain tasks, if I recall things right (it's been a > > > while). > > > > Yes, that's my understanding as well. The same changes were done for > > fdt_high a few months back and ramdisks aren't any different in this > > respect. I was a bit surprised that this hadn't been fixed yet, but > > maybe people just aren't using ramdisks anymore these days, or they > > worked around it by setting initrd_high explicitly. > > This depends a lot on a number of things. For example, you should be > able to use a ramdisk in NOR flash directly, i. e. without loading it > to RAM first - especially if it;s a comprtessed ramdis image, and the > Kernel will copy/uncompress it anyway. Depending on your memory map > the address range of the NOR flash may be way outside (and above) that > of the system RAM. Are you sure your changes will not break any such > usage? As far as I can tell, the only place where initrd_high is used is to allocate an area from RAM that's used to relocate the ramdisk to. In case where the ramdisk is directly in NOR and isn't supposed to be copied anyway, this code should never be run. > > Yeah, I wondered whether maybe not relocating the ramdisk (and the FDT) > > in the first place might even be a better default fallback. It makes the > > We want to avoid any copy of the ramdisk at all, if possible. Well, that's not what the current code does. It currently always relocates unless you happen to explicitly set initrd_high = 0x. So maybe one other alternative would be to check whether the current location of the ramdisk is within the low memory area and only relocate otherwise. Does that match your expectation? > > > > Also, when changing the behaviour, you should also update the > > > > comments. > > > > > > Agreed. > > > > I'm not sure which comments you are referring to. I updated the one > > immediately above the changed code and the one above the function > > doesn't contain anything relating to the default behaviour in case > > initrd_high is unset. > > ...because default behaviour was do do nothing. Now you do something, > so this should be documented. The default behaviour was to not restrict loading to high memory at all, which is what the comment said: /* not set, no restrictions to load high */ initrd_high = ~0; The patch that I posted changes the above to this: /* make sure to put ramdisk in low memory */ initrd_high = getenv_bootm_low() + getenv_bootm_mapsize(); Doesn't that accurately describe the change? Thierry 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] image: Don't relocate ramdisk to highmem
On 07/11/2013 12:21 PM, Wolfgang Denk wrote:
> Dear Thierry Reding,
>
> In message <20130711150014.ga2...@dhcp-172-17-186-34.nvidia.com> you wrote:
>>
>>> I'm pretty sure it's all architectures, and this is a problem for device
>>> trees as well. The tricks done to deal with highmem mean it's not
>>> suitable for certain tasks, if I recall things right (it's been a
>>> while).
>>
>> Yes, that's my understanding as well. The same changes were done for
>> fdt_high a few months back and ramdisks aren't any different in this
>> respect. I was a bit surprised that this hadn't been fixed yet, but
>> maybe people just aren't using ramdisks anymore these days, or they
>> worked around it by setting initrd_high explicitly.
>
> This depends a lot on a number of things. For example, you should be
> able to use a ramdisk in NOR flash directly, i. e. without loading it
> to RAM first - especially if it;s a comprtessed ramdis image, and the
> Kernel will copy/uncompress it anyway.
That would be nice, but I don't believe the kernel supports that (at
least not on ARM):
arch/arm/mm/init.c:arm_memblock_init():
> #ifdef CONFIG_BLK_DEV_INITRD
> if (phys_initrd_size &&
> !memblock_is_region_memory(phys_initrd_start, phys_initrd_size)) {
> pr_err("INITRD: 0x%08llx+0x%08lx is not a memory region -
> disabling initrd\n",
> (u64)phys_initrd_start, phys_initrd_size);
> phys_initrd_start = phys_initrd_size = 0;
> }
(where "memory" in this context is RAM specifically, IIUC).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 7/7] imx: add status reporting for HAB status
Dear Stefano Babic,
> Add functions to report the HAB (High Assurance Boot) status
> of e.g. i.MX6 CPUs.
>
> This is taken from
>
> git://git.freescale.com/imx/uboot-imx.git branch imx_v2009.08_3.0.35_4.0.0
> cpu/arm_cortexa8/mx6/generic.c
> include/asm-arm/arch-mx6/mx6_secure.h
>
> Signed-off-by: Stefano Babic
> ---
> arch/arm/cpu/armv7/mx6/Makefile |2 +-
> arch/arm/cpu/armv7/mx6/hab.c | 127
> ++ arch/arm/include/asm/arch-mx6/hab.h |
> 80 +++ arch/arm/include/asm/arch-mx6/imx-regs.h |8 +-
> 4 files changed, 215 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/cpu/armv7/mx6/hab.c
> create mode 100644 arch/arm/include/asm/arch-mx6/hab.h
>
> diff --git a/arch/arm/cpu/armv7/mx6/Makefile
> b/arch/arm/cpu/armv7/mx6/Makefile index 4f9ca68..7c18f43 100644
> --- a/arch/arm/cpu/armv7/mx6/Makefile
> +++ b/arch/arm/cpu/armv7/mx6/Makefile
> @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
>
> LIB = $(obj)lib$(SOC).o
>
> -COBJS= soc.o clock.o
> +COBJS= soc.o clock.o hab.o
>
> SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
> diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c
> new file mode 100644
> index 000..c3c273f
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/mx6/hab.c
> @@ -0,0 +1,127 @@
> +/*
> + * Copyright (C) 2010-2013 Freescale Semiconductor, Inc.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#if defined(CONFIG_SECURE_BOOT)
> +#include
> +
> +#ifdef CONFIG_SECURE_BOOT
> +/* start of HAB API updates */
> +#define hab_rvt_report_event ((hab_rvt_report_event_t
> *)HAB_RVT_REPORT_EVENT) +#define hab_rvt_report_status
> ((hab_rvt_report_status_t *)HAB_RVT_REPORT_STATUS) +#define
> hab_rvt_authenticate_image \
> + ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE)
> +#define hab_rvt_entry ((hab_rvt_entry_t *)HAB_RVT_ENTRY)
> +#define hab_rvt_exit ((hab_rvt_exit_t *)HAB_RVT_EXIT)
> +#define hab_rvt_clock_init HAB_RVT_CLOCK_INIT
> +
> +
> +bool is_hab_enabled(void)
> +{
> + struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
> + struct fuse_bank *bank = &ocotp->bank[0];
> + struct fuse_bank0_regs *fuse =
> + (struct fuse_bank0_regs *)bank->fuse_regs;
> + uint32_t reg = readl(&fuse->cfg5);
> +
> + return (reg & 0x2) == 0x2;
> +}
> +
> +
> +void display_event(uint8_t *event_data, size_t bytes)
> +{
> + uint32_t i;
> +
> + if ((event_data) && (bytes > 0)) {
if (!)
return;
> + for (i = 0; i < bytes; i++) {
> + if (i == 0)
> + printf("\t0x%02x", event_data[i]);
> + else if ((i % 8) == 0)
> + printf("\n\t0x%02x", event_data[i]);
> + else
> + printf(" 0x%02x", event_data[i]);
> + }
> + }
> +}
> +
> +int get_hab_status(void)
> +{
> + uint32_t index = 0; /* Loop index */
> + uint8_t event_data[128]; /* Event data buffer */
> + size_t bytes = sizeof(event_data); /* Event size in bytes */
> + hab_config_t config = 0;
> + hab_state_t state = 0;
> +
> + if (is_hab_enabled())
> + printf("\nSecure boot enabled\n");
> + else
> + printf("\nSecure boot disabled\n");
Use puts() instead of printf() with no args.
Otherwise very nice ;-)
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] image: Don't relocate ramdisk to highmem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/11/2013 02:21 PM, Wolfgang Denk wrote: > Dear Thierry Reding, [snip] Also, when changing the behaviour, you should also update the comments. >>> >>> Agreed. >> >> I'm not sure which comments you are referring to. I updated the >> one immediately above the changed code and the one above the >> function doesn't contain anything relating to the default >> behaviour in case initrd_high is unset. > > ...because default behaviour was do do nothing. Now you do > something, so this should be documented. Wait, the default behaviour is to relocate things to the top of memory, at least in the cases I've played with recently. This changes things to have a limit on how high up it can be placed. A change, yes. But not a change from nothing. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR3vl6AAoJENk4IS6UOR1W/mIQAIXWASuOgGa9+OHPEjC1oTAs Be2bO8aC5j3Hw3dw2QwVUekiIWPzHi+bz+B8WYdnZHlqBXZPerhi+JOEog6zwb4+ o5CrzY6w21RA0ZjDNGQyjKNA02a5ZkAwSfamLURJeIjsAJmt2exZQJZQsG+reMTo jphJbPMRQJOoLH9QoYUQWlb+6NrsqppsrTHQlyL5E1/+r2Wz2KVAru8AembRSCOW a5kanhiuPDNCn2WPxCHFQ0u9YtaVW8+W7APw+szsszqZ+fWeUDmtSU4gXGZ9kJjt LGHbwQDnTkS4fGAAU9mwuKhp/y5EhlZpOjvD1KJxQpxxdKGxO1xH7A7xWwb4wzee iVu+p6PNS6ssXP1ha+ZjwrvfN3hyWJL/JOmAVrnhr+3iq5yTrggXWMTeou0mxtzV +v5HfuKLqXqMIMSI++MAEPdvg7GTx/SlXzFlRbWyKC4v7guYl70g9GuPE6flnnVJ 4OPd4YWN0N1CDmddkwbBP9gIzbJxOoVwcW0WaRL1HE4W7wkrDjJFOjTP/ieydKH3 7Nuv+X1pXdRJv38A2Z7KuYzm7ewQdAZfh1n4vivcET0DH86doHwCDfestLTPsdjR mIQbrXjZyU2jq7GV/dEUTUI/aeAeB/9Bog2+gc/0ne5cSvAKD4cM0Kwqp6cvknCx utrwMmEazs+bpAkW5+CR =rguU -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/7] tools: dynamically allocate imx_header in imximage
Dear Stefano Babic,
> Change to dynamically allocate the imx_header to correctly
> allocate the IVT, Boot Data and DCD at correct locations
> depending on the boot media.
>
> Also check that the Image Vector Table Offset + IVT +
> Boot Data + DCD <= Initial Load Region Size.
>
> Previously struct imx_header was always 4096 bytes and was
> not dealing correctly with the Image Vector Table Offset.
>
> Now, the memory allocation looks for e.g. SD boot like this
>
> Storage u-boot.imx RAM
> Device
>
> 177ff000 <--
>
> 0400 d1 00 20 40 IVT.header 177ff400 <--- |
> 0404 0004 00 00 80 17 IVT.entry177ff404 --- |
> 0408 0008 00 00 00 00 IVT.reserved1177ff408| | |
> 040C 000C 2c f4 7f 17 IVT.dcd 177ff40C -- | | |
> 0410 0010 20 f4 7f 17 IVT.boot 177ff410 | | | |
> 0414 0014 00 f4 7f 17 IVT.self 177ff414 | |
> 0418 0018 00 00 00 00 IVT.csf 177ff418| || |
> 041C 001C 00 00 00 00 IVT.reserved2177ff41C| || |
> 0420 0020 00 f0 7f 17 BootData.start 177ff420 <--- || ---
> 0424 0024 00 60 03 00 BootData.length 177ff424 ||
> 0428 0028 00 00 00 00 BootData.plugin 177ff428 ||
> 042C 002C d2 03 30 40 DCD.header 177ff42C <-|
> ... |
> 1000 0c00 13 00 00 ea U-Boot Start 1780 <--
>
> While at it also remove the unused #define HEADER_OFFSET.
>
> Signed-off-by: Stefano Babic
> ---
> tools/imximage.c | 44 +---
> tools/imximage.h | 16 +---
> 2 files changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/tools/imximage.c b/tools/imximage.c
> index d87e94d..984cb9b 100644
> --- a/tools/imximage.c
> +++ b/tools/imximage.c
> @@ -47,7 +47,7 @@ static table_entry_t imximage_cmds[] = {
> * Supported Boot options for configuration file
> * this is needed to set the correct flash offset
> */
> -static table_entry_t imximage_bootops[] = {
> +static table_entry_t imximage_boot_offset[] = {
> {FLASH_OFFSET_ONENAND, "onenand", "OneNAND Flash",},
> {FLASH_OFFSET_NAND, "nand", "NAND Flash", },
> {FLASH_OFFSET_NOR, "nor", "NOR Flash",},
> @@ -58,6 +58,20 @@ static table_entry_t imximage_bootops[] = {
> };
>
> /*
> + * Supported Boot options for configuration file
> + * this is needed to determine the initial load size
> + */
> +static table_entry_t imximage_boot_loadsize[] = {
> + {FLASH_LOADSIZE_ONENAND,"onenand", "OneNAND Flash",},
> + {FLASH_LOADSIZE_NAND, "nand", "NAND Flash", },
> + {FLASH_LOADSIZE_NOR,"nor", "NOR Flash",},
> + {FLASH_LOADSIZE_SATA, "sata", "SATA Disk",},
> + {FLASH_LOADSIZE_SD, "sd", "SD Card", },
> + {FLASH_LOADSIZE_SPI,"spi", "SPI Flash",},
> + {-1,"", "Invalid", },
> +};
> +
> +/*
> * IMXIMAGE version definition for i.MX chips
> */
> static table_entry_t imximage_versions[] = {
> @@ -70,6 +84,8 @@ static struct imx_header imximage_header;
> static uint32_t imximage_version;
> /* Image Vector Table Offset */
> static uint32_t imximage_ivt_offset;
> +/* Initial Load Region Size */
> +static uint32_t imximage_init_loadsize;
>
> static set_dcd_val_t set_dcd_val;
> static set_dcd_rst_t set_dcd_rst;
> @@ -211,7 +227,9 @@ static void set_imx_hdr_v1(struct imx_header *imxhdr,
> uint32_t dcd_len, /* Set magic number */
> fhdr_v1->app_code_barker = APP_CODE_BARKER;
>
> - hdr_base = entry_point - sizeof(struct imx_header);
> + /* TODO: check i.MX image V1 handling, for now use 'old' style */
> + /* hdr_base = entry_point - imximage_init_loadsize + flash_offset; */
The above line should probably be removed.
[...]
> @@ -163,7 +173,7 @@ struct imx_header {
> imx_header_v1_t hdr_v1;
> imx_header_v2_t hdr_v2;
> } header;
> -} __attribute__((aligned(4096)));
> +};
What about the alignment, is it preserved?
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] image: Don't relocate ramdisk to highmem
Dear Thierry Reding, In message <20130711150014.ga2...@dhcp-172-17-186-34.nvidia.com> you wrote: > > > I'm pretty sure it's all architectures, and this is a problem for device > > trees as well. The tricks done to deal with highmem mean it's not > > suitable for certain tasks, if I recall things right (it's been a > > while). > > Yes, that's my understanding as well. The same changes were done for > fdt_high a few months back and ramdisks aren't any different in this > respect. I was a bit surprised that this hadn't been fixed yet, but > maybe people just aren't using ramdisks anymore these days, or they > worked around it by setting initrd_high explicitly. This depends a lot on a number of things. For example, you should be able to use a ramdisk in NOR flash directly, i. e. without loading it to RAM first - especially if it;s a comprtessed ramdis image, and the Kernel will copy/uncompress it anyway. Depending on your memory map the address range of the NOR flash may be way outside (and above) that of the system RAM. Are you sure your changes will not break any such usage? > Yeah, I wondered whether maybe not relocating the ramdisk (and the FDT) > in the first place might even be a better default fallback. It makes the We want to avoid any copy of the ramdisk at all, if possible. > That's *exactly* what happened to me, only that instead of just not > finding the ramdisk it would page fault and oops. The first thing I did > was indeed to just set initrd_high to 0x but then decided to try > and properly fix it in an attempt to save others the trouble. What is a fix for you may be a breakage elsewhere. > > > Also, when changing the behaviour, you should also update the > > > comments. > > > > Agreed. > > I'm not sure which comments you are referring to. I updated the one > immediately above the changed code and the one above the function > doesn't contain anything relating to the default behaviour in case > initrd_high is unset. ...because default behaviour was do do nothing. Now you do something, so this should be documented. 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 The only time the world beats a path to your door is when you are in the bathroom. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/7] The patchset fixes some issue in the generation of the imx image
On 07/11/2013 11:11 AM, Otavio Salvador wrote: On Thu, Jul 11, 2013 at 10:06 AM, Stefano Babic wrote: >> >> Next step is to verify the kernel, that can be still done using Simon's patches for verified boot (CONFIG_OF_CONTROL must be set in the board configuarion file). I didn't yet test or reviewed the patchset (will do) but I must to say a big Thank you :-) Awesome! +1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 6/7] tools: add support for setting the CSF into imximage
Dear Stefano Babic, In message <1373548001-19728-7-git-send-email-sba...@denx.de> you wrote: > Add support for setting the CSF (Command Sequence File) pointer > which is used for HAB (High Assurance Boot) in the imximage by > adding e.g. This patch throws a checkpatch error that needs to be fixed: WARNING: quoted string split across lines #265: FILE: tools/imximage.c:412: + fprintf(stderr, "Error: %s[%d] - " + "CSF only supported for IMAGE_VERSION 2(%s)\n", 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 "You're just jealous." "What, of an overgrown puppy with a single- figure IQ?" - Terry Pratchett, _Moving Pictures_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander
Configure the tca6424 gpio expander
This allows use of the debug and tri color LEDs.
Signed-off-by: Dan Murphy
---
v2 - Updated per comments - http://patchwork.ozlabs.org/patch/257603/
v3 - Updated documentation. No change to mux data the code is the
patch is required or I2C reads fail - http://patchwork.ozlabs.org/patch/257840/
board/ti/omap5_uevm/evm.c | 22 ++
board/ti/omap5_uevm/mux_data.h |2 ++
include/configs/omap5_uevm.h |5 +
3 files changed, 29 insertions(+)
diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
index 90046e8..c3581ee 100644
--- a/board/ti/omap5_uevm/evm.c
+++ b/board/ti/omap5_uevm/evm.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "mux_data.h"
@@ -36,6 +37,25 @@ const struct omap_sysinfo sysinfo = {
};
/**
+ * @brief tca642x_init - uEVM default values for the GPIO expander
+ * input reg, output reg, polarity reg, configuration reg
+ */
+struct tca642x_bank_info tca642x_init[] = {
+ { .input_reg = 0x00,
+ .output_reg = 0x04,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0x80 },
+ { .input_reg = 0x00,
+ .output_reg = 0x00,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0xff },
+ { .input_reg = 0x00,
+ .output_reg = 0x00,
+ .polarity_reg = 0x00,
+ .configuration_reg = 0x40 },
+};
+
+/**
* @brief board_init
*
* @return 0
@@ -46,6 +66,8 @@ int board_init(void)
gd->bd->bi_arch_number = MACH_TYPE_OMAP5_SEVM;
gd->bd->bi_boot_params = (0x8000 + 0x100); /* boot param addr */
+ tca642x_set_inital_state(CONFIG_SYS_I2C_TCA642X_ADDR, tca642x_init);
+
return 0;
}
diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
index a82795d..7e6415e 100644
--- a/board/ti/omap5_uevm/mux_data.h
+++ b/board/ti/omap5_uevm/mux_data.h
@@ -56,6 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
{USBD0_HS_DP, (IEN | M0)}, /* USBD0_HS_DP */
{USBD0_HS_DM, (IEN | M0)}, /* USBD0_HS_DM */
{USBD0_SS_RX, (IEN | M0)}, /* USBD0_SS_RX */
+ {I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
+ {I2C5_SDA, (IEN | M0)}, /* I2C5_SDA */
};
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 46dacc2..bee1278 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -53,6 +53,11 @@
#define CONFIG_PARTITION_UUIDS
#define CONFIG_CMD_PART
+#define CONFIG_TCA642X
+#define CONFIG_CMD_TCA642X
+#define CONFIG_SYS_I2C_TCA642X_BUS_NUM 4
+#define CONFIG_SYS_I2C_TCA642X_ADDR 0x22
+
#define CONFIG_SYS_PROMPT "OMAP5432 uEVM # "
#define CONSOLEDEV "ttyO2"
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/7] The patchset fixes some issue in the generation of the imx image
On Thu, Jul 11, 2013 at 10:06 AM, Stefano Babic wrote: > (header for Freescale's i.MX processors) to allow the usage of > Freescale's tools to sign the u-boot image and provide a secure boot. > > This has nothing to do with the Secure Boot extensions implemented by > Simon Glass, that can be in any case used to boot later a secure image. > Freescale's secure boot ensures that a signed bootloader > is started only if it is verified with a key that is burned into the iMX > fuses. > Documentation about the Freescale's secure process can be read from the > AN4591, available on the Freescale's Website. > > The patchset allows to add to the imx Header the CSF (command Sequence File) > generated by the tools provided by Freescale. The CSF is then simply > concatenated > to the u-boot image, making a signed bootloader, that the processor can verify > if the fuses for the keys are burned. The processor (i.MX53 / i.MX6x) will not > start a bootloader that cannot be verified - further infos how to configure > the SOC to verify the bootloader can be found in the User Manual of the > specific > SOC. > > Next step is to verify the kernel, that can be still done using Simon's > patches for > verified boot (CONFIG_OF_CONTROL must be set in the board configuarion file). I didn't yet test or reviewed the patchset (will do) but I must to say a big Thank you :-) Awesome! -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.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 v3 1/2] gpio: tca642x: Add the tca642x gpio expander driver
Add the tca642x gpio expander driver
Datasheet:
http://www.ti.com/product/tca6424a
Signed-off-by: Dan Murphy
---
v2 - Updated per comments - http://patchwork.ozlabs.org/patch/257602/
v3 - Fixed checkpatch issues - http://patchwork.ozlabs.org/patch/257841/
drivers/gpio/Makefile |1 +
drivers/gpio/tca642x.c | 333
include/tca642x.h | 69 ++
3 files changed, 403 insertions(+)
create mode 100644 drivers/gpio/tca642x.c
create mode 100644 include/tca642x.h
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f77c1ec..7e74dfe 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -49,6 +49,7 @@ COBJS-$(CONFIG_BCM2835_GPIO) += bcm2835_gpio.o
COBJS-$(CONFIG_S3C2440_GPIO) += s3c2440_gpio.o
COBJS-$(CONFIG_XILINX_GPIO)+= xilinx_gpio.o
COBJS-$(CONFIG_ADI_GPIO2) += adi_gpio2.o
+COBJS-$(CONFIG_TCA642X)+= tca642x.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/gpio/tca642x.c b/drivers/gpio/tca642x.c
new file mode 100644
index 000..6386835
--- /dev/null
+++ b/drivers/gpio/tca642x.c
@@ -0,0 +1,333 @@
+/*
+ * Copyright 2013 Texas Instruments, Inc.
+ * Author: Dan Murphy
+ *
+ * Derived work from the pca953x.c driver
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+/* tca642x register address definitions */
+struct tca642x_bank_info tca642x_regs[] = {
+ { .input_reg = 0x00,
+ .output_reg = 0x04,
+ .polarity_reg = 0x08,
+ .configuration_reg = 0x0c },
+ { .input_reg = 0x01,
+ .output_reg = 0x05,
+ .polarity_reg = 0x09,
+ .configuration_reg = 0x0d },
+ { .input_reg = 0x02,
+ .output_reg = 0x06,
+ .polarity_reg = 0x0a,
+ .configuration_reg = 0x0e },
+};
+
+/*
+ * Modify masked bits in register
+ */
+static int tca642x_reg_write(uchar chip, uint8_t addr,
+ uint8_t reg_bit, uint8_t data)
+{
+ uint8_t valw;
+ int org_bus_num;
+ int ret;
+
+ org_bus_num = i2c_get_bus_num();
+ i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+
+ if (i2c_read(chip, addr, 1, (uint8_t *)&valw, 1)) {
+ printf("Could not read before writing\n");
+ ret = -1;
+ goto error;
+ }
+ valw &= ~reg_bit;
+ valw |= data;
+
+ ret = i2c_write(chip, addr, 1, (u8 *)&valw, 1);
+
+error:
+ i2c_set_bus_num(org_bus_num);
+ return ret;
+}
+
+static int tca642x_reg_read(uchar chip, uint8_t addr, uint8_t *data)
+{
+ uint8_t valw;
+ int org_bus_num;
+ int ret = 0;
+
+ org_bus_num = i2c_get_bus_num();
+ i2c_set_bus_num(CONFIG_SYS_I2C_TCA642X_BUS_NUM);
+ if (i2c_read(chip, addr, 1, (u8 *)&valw, 1)) {
+ ret = -1;
+ goto error;
+ }
+
+ *data = valw;
+
+error:
+ i2c_set_bus_num(org_bus_num);
+ return ret;
+}
+
+/*
+ * Set output value of IO pins in 'reg_bit' to corresponding value in 'data'
+ * 0 = low, 1 = high
+ */
+int tca642x_set_val(uchar chip, uint8_t gpio_bank,
+ uint8_t reg_bit, uint8_t data)
+{
+ uint8_t out_reg = tca642x_regs[gpio_bank].output_reg;
+
+ return tca642x_reg_write(chip, out_reg, reg_bit, data);
+}
+
+/*
+ * Set read polarity of IO pins in 'reg_bit' to corresponding value in 'data'
+ * 0 = read pin value, 1 = read inverted pin value
+ */
+int tca642x_set_pol(uchar chip, uint8_t gpio_bank,
+ uint8_t reg_bit, uint8_t data)
+{
+ uint8_t pol_reg = tca642x_regs[gpio_bank].polarity_reg;
+
+ return tca642x_reg_write(chip, pol_reg, reg_bit, data);
+}
+
+/*
+ * Set direction of IO pins in 'reg_bit' to corresponding value in 'data'
+ * 0 = output, 1 = input
+ */
+int tca642x_set_dir(uchar chip, uint8_t gpio_bank,
+ uint8_t reg_bit, uint8_t data)
+{
+ uint8_t config_reg = tca642x_regs[gpio_bank].configuration_reg;
+
+ return tca642x_reg_write(chip, config_reg, reg_bit, data);
+}
+
+/*
+ * Read current logic level of all IO pins
+ */
+int tca642x_get_val(uchar chip, uint8_t gpio_bank)
+{
+ uint8_t val;
+ uint8_t in_reg = tca642x_regs[gpio_bank]
Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB
On Thu, Jul 11, 2013 at 07:40:28PM +0200, Albert ARIBAUD wrote: > Hi Tom, > > On Thu, 11 Jul 2013 12:15:50 -0400, Tom Rini wrote: > > > On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote: > > > Hi Sascha, > > > > > > On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe > > > wrote: > > > > > > > Hello Albert, hello Tom, > > > > > > > > Albert ARIBAUD writes: > > > > > > > > [Move environment to account for increase in U-Boot size] > > > > > This patch is for 2013.10, not 2013.07, but I prefer raising the issue > > > > > as early as possible. > > > > > > > > > > If there is no way to make things smoother, then I think the 2013.10 > > > > > release notes should contain a red, blinking, paragraph about this. I > > > > > would *hate* it if people were not warned and given a method to port > > > > > their current environment setting over. > > > > > > > > > > Possibly even, the 2013.07 could have a warning about the change to > > > > > come, so that people have a better chance yet to prepare for the > > > > > change. > > > > > > > > The situation has gotten better recently and U-Boot fits into the > > > > previous partition size of 384KiB again. So it isn't broken on OpenRD > > > > anymore and the above would seem like a good approach. > > > > > > How well does it fit again, and do you have any idea what caused the > > > increase in size, and what caused the decrease? > > > > I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections > > is what brought the size back down again. We've been adding a lot of > > kinda optional code, and to avoid having to ifdef the hell out of > > everything, we've been relying on growth not being a big problem or just > > ignoring it. > > ... Which in the end can bite back, see anonymous string issue. Are we > heading back to carefully selecting which files we build rather than > building then dropping? It depends on what we can get from the tools we have, cleanly. I've seen, for example, patches to kill all output from SPL, as that was required to get the required big features into a size constrained SPL. But I don't think it was clean enough for mainline. On the other hand, we've got some large files, and if splitting them up for logical uses also gets us working around string issues, good for us. -- 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 v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander
On Jul 11, 2013 10:55 AM, "Dan Murphy" wrote:
>
> On 07/10/2013 06:56 PM, Nishanth Menon wrote:
> > On 07/10/2013 03:06 PM, Dan Murphy wrote:
> >> Configure the tca6424 gpio expander
> >> This allows use of the debug and tri color LEDs.
> >>
> >> Signed-off-by: Dan Murphy
> >> ---
> >> board/ti/omap5_uevm/evm.c | 21 +
> >> board/ti/omap5_uevm/mux_data.h |2 ++
> >> include/configs/omap5_uevm.h |5 +
> >> 3 files changed, 28 insertions(+)
> >>
> >> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
> >> index 90046e8..0e9a559 100644
> >> --- a/board/ti/omap5_uevm/evm.c
> >> +++ b/board/ti/omap5_uevm/evm.c
> >> @@ -26,6 +26,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include "mux_data.h"
> >>
> >> @@ -35,6 +36,24 @@ const struct omap_sysinfo sysinfo = {
> >> "Board: OMAP5430 EVM\n"
> >> };
> >>
> >> +/* @brief tca642x_init - Initial states for the GPIO expander
> > documentation style?
> > /*
> > * @brief
> > ?
> >> + * input reg, output reg, polarity reg, configuration reg
> >> + */
> >> +struct tca642x_bank_info tca642x_init[] = {
> >> +{ .input_reg = 0x00,
> >> + .output_reg = 0x04,
> >> + .polarity_reg = 0x00,
> >> + .configuration_reg = 0x80 },
> >> +{ .input_reg = 0x00,
> >> + .output_reg = 0x00,
> >> + .polarity_reg = 0x00,
> >> + .configuration_reg = 0xff },
> >> +{ .input_reg = 0x00,
> >> + .output_reg = 0x00,
> >> + .polarity_reg = 0x00,
> >> + .configuration_reg = 0x40 },
> >> +};
> >> +
> >> /**
> >>* @brief board_init
> >>*
> >> @@ -46,6 +65,8 @@ int board_init(void)
> >> gd->bd->bi_arch_number = MACH_TYPE_OMAP5_SEVM;
> >> gd->bd->bi_boot_params = (0x8000 + 0x100); /* boot param
addr */
> >>
> >> +tca642x_set_inital_state(CONFIG_SYS_I2C_TCA642X_ADDR,
tca642x_init);
> >> +
> >> return 0;
> >> }
> >>
> >> diff --git a/board/ti/omap5_uevm/mux_data.h
b/board/ti/omap5_uevm/mux_data.h
> >> index a82795d..7e6415e 100644
> >> --- a/board/ti/omap5_uevm/mux_data.h
> >> +++ b/board/ti/omap5_uevm/mux_data.h
> >> @@ -56,6 +56,8 @@ const struct pad_conf_entry
core_padconf_array_essential[] = {
> >> {USBD0_HS_DP, (IEN | M0)},/* USBD0_HS_DP */
> >> {USBD0_HS_DM, (IEN | M0)},/* USBD0_HS_DM */
> >> {USBD0_SS_RX, (IEN | M0)},/* USBD0_SS_RX */
> >> +{I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
> > nit pick -> SCL (or i2c clk) is out put from master - always. IEN
enables full duplex, but anyways.. just a nitpick :)
> >
> OK I changed this and did a test and reads fail without the IEN set.
> This is to sync the client clocks.
Scl? I2c clock? Does not work without input- something is fishy no?
> >> +{I2C5_SDA, (IEN | M0)}, /* I2C5_SDA */
> >>
> >> };
> >>
> >> diff --git a/include/configs/omap5_uevm.h
b/include/configs/omap5_uevm.h
> >> index 46dacc2..bee1278 100644
> >> --- a/include/configs/omap5_uevm.h
> >> +++ b/include/configs/omap5_uevm.h
> >> @@ -53,6 +53,11 @@
> >> #define CONFIG_PARTITION_UUIDS
> >> #define CONFIG_CMD_PART
> >>
> >> +#define CONFIG_TCA642X
> >> +#define CONFIG_CMD_TCA642X
> >> +#define CONFIG_SYS_I2C_TCA642X_BUS_NUM 4
> >> +#define CONFIG_SYS_I2C_TCA642X_ADDR 0x22
> >> +
> >> #define CONFIG_SYS_PROMPT"OMAP5432 uEVM # "
> >>
> >> #define CONSOLEDEV"ttyO2"
> >>
> >
> > Else,
> > no further comments from me.
> > --
> > Regards,
> > Nishanth Menon
>
>
> --
> --
> Dan Murphy
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OpenRD: relocate environment to 640kB
Hi Tom, On Thu, 11 Jul 2013 12:15:50 -0400, Tom Rini wrote: > On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote: > > Hi Sascha, > > > > On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe > > wrote: > > > > > Hello Albert, hello Tom, > > > > > > Albert ARIBAUD writes: > > > > > > [Move environment to account for increase in U-Boot size] > > > > This patch is for 2013.10, not 2013.07, but I prefer raising the issue > > > > as early as possible. > > > > > > > > If there is no way to make things smoother, then I think the 2013.10 > > > > release notes should contain a red, blinking, paragraph about this. I > > > > would *hate* it if people were not warned and given a method to port > > > > their current environment setting over. > > > > > > > > Possibly even, the 2013.07 could have a warning about the change to > > > > come, so that people have a better chance yet to prepare for the > > > > change. > > > > > > The situation has gotten better recently and U-Boot fits into the > > > previous partition size of 384KiB again. So it isn't broken on OpenRD > > > anymore and the above would seem like a good approach. > > > > How well does it fit again, and do you have any idea what caused the > > increase in size, and what caused the decrease? > > I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections > is what brought the size back down again. We've been adding a lot of > kinda optional code, and to avoid having to ifdef the hell out of > everything, we've been relying on growth not being a big problem or just > ignoring it. ... Which in the end can bite back, see anonymous string issue. Are we heading back to carefully selecting which files we build rather than building then dropping? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL size issues on OMAP4
On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote:
> Greetings,
>
> I've been absent for a while and couldn't find a way to search the
> list archives so I apologize if this has already been discussed?
>
> I've been fighting the SPL binary growing too large on OMAP4 (using
> custom configs and features). It's annoying that too large just fails
> to run with no build or runtime notice. But that's a different issue.
What version are you using? When SPL is too large a build-time failure
is expected.
> My main issue is that in looking through the map for SPL I've repeatedly
> found code that I don't need and have a pretty good handle on that. My issue
> is that code that is compiled but eliminated because it's not called leaves
> behind all of its anonymous strings ("like this"). In my latest build I have
> the following sections that are all anonymous strings:
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to
have gotten little attention after initial triage. I guess I need to
find a little time to show it's still there.
[snip]
> Is there a work around I haven't thought of? I'm thinking along the
> lines of disabling all printfs in SPL in the hope that will take the
> strings away (since many are some sort of debug / progress message).
One option would be to add a "disable all output" option to SPL that
would get all of the strings dropped. I'm not sure how cleanly this can
be done, but I know it has been done.
Another option would be to do some careful splitting and #ifdef'ery of
files so that we can just never link in the stuff with strings we don't
need.
--
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 v1 7/7] imx: add status reporting for HAB status
Hi Stefano, On Thu, Jul 11, 2013 at 10:06 AM, Stefano Babic wrote: > --- a/arch/arm/cpu/armv7/mx6/Makefile > +++ b/arch/arm/cpu/armv7/mx6/Makefile > @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk > > LIB= $(obj)lib$(SOC).o Whole series looks good. Only a minor comment: > -COBJS = soc.o clock.o > +COBJS = soc.o clock.o hab.o What about: COBJS-y += soc.o clock.o COBJS-$(CONFIG_SECURE_BOOT) += hab.o > > SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) > OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) > diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c > new file mode 100644 > index 000..c3c273f > --- /dev/null > +++ b/arch/arm/cpu/armv7/mx6/hab.c > @@ -0,0 +1,127 @@ > +/* > + * Copyright (C) 2010-2013 Freescale Semiconductor, Inc. > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +#include > +#include > +#if defined(CONFIG_SECURE_BOOT) ,and then you remove this 'if defined' ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL size issues on OMAP4
Greetings,
I've been absent for a while and couldn't find a way to search the list
archives so I apologize if this has already been discussed…
I've been fighting the SPL binary growing too large on OMAP4 (using custom
configs and features). It's annoying that too large just fails to run with no
build or runtime notice. But that's a different issue.
My main issue is that in looking through the map for SPL I've repeatedly found
code that I don't need and have a pretty good handle on that. My issue is that
code that is compiled but eliminated because it's not called leaves behind all
of its anonymous strings ("like this"). In my latest build I have the following
sections that are all anonymous strings:
0x4030b638 0x232 arch/arm/cpu/armv7/omap-common/libomap-common.o
0x4030b8b5 0x19 arch/arm/cpu/armv7/omap4/libomap4.o
0x4030b9ad 0xbe common/spl/libspl.o
0x4030ba6b 0x57 drivers/gpio/libgpio.o
0x4030bac2 0x44c drivers/i2c/libi2c.o
0x4030bf0e 0x302 drivers/mmc/libmmc.o
0x4030c27e 0x15 drivers/serial/libserial.o
0x4030c293 0x145 drivers/spi/libspi.o
0x4030c4d8 0x53 lib/libgeneric.o
with more than half being unreferenced. This is a big deal when you only have
about 25K of SRAM for code and data.
In searching the web it seems that dead code and data are removed using
--gc-sections, -ffunction-sections and -fdata-sections which u-boot is using
correctly.
But it seems that gcc puts all anonymous strings into the same section (.rodata
or .rodata.str1.1 if string merging is on) which prevents them from
participating in the stripping process.
Interestingly, it puts its own __func__ strings into separate sections and they
are eliminated if the function go away. It just doesn't do this for plain ""
strings. Grrr.
I was shocked to find gcc posts asking about this more than 13 years ago with
barely any traction at all. Given that embarrassing history I'm not hopefully
that the gcc folks will ever address this.
Is there a work around I haven't thought of? I'm thinking along the lines of
disabling all printfs in SPL in the hope that will take the strings away (since
many are some sort of debug / progress message).
Any thoughts or guidance would be appreciated.
-Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting ehci-exynos.c to handle exynos4412 (odroid-u2)
Yes, the u-boot is based off of 2010.12: The source with the odroid-u2 (Exynos4412) mods are in https://github.com/hardkernel/u-boot You are right, the problem is in enabling USB. I do not seem ot find documentation as to the IO addresses and what values to poke/peek in them to initialize and power on the USB PHY. There is however a linux source tree which has support for this device, which works the USB quite well. I am trying to steal and grab the initialization steps from the linux kernel and pull it into u-boot. The files that I seem to need to modify are mainly in drivers/host/usb/ehci-exynos.c with some usb phy power code in system.c/power.c in arch/arm/cpu/armv7/exynos/ in u-boot. The linux src tree that I am trying to decipher is in arch/arm/mach-exynos/setup-usb-phy.c Thanks - Suriyan On Mon, Jul 8, 2013 at 12:47 PM, Lukasz Majewski wrote: > On Mon, 8 Jul 2013 11:03:05 -0700 > Suriyan Ramasami wrote: > > > Hello Lukasz, > >Thanks for your response. I guess I was not very clear with my > > question. > > > >u-boot code already exists for the odroid-u2 (that is what it > > uses). > > So I assume that the u-boot code was the part of the BSP? > The problem then seems to be with enabling and building the usb code? > > Another question is, how close your odroid's u-boot is to the mainline? > Which version of u-boot do you have? > > > Unfortunately, it does not have USB support. I am looking at > > just adding the EHCI and USB (uses a 3503A) part of the code. > > > >I checked the TRATS2 patch and it too does not have any code that > > touches the USB part of things. > > This is true. We aren't using EHCI (USB Host). Instead we are > supporting USB Device + Composite layer + Gadgets (like DFU + UMS). > Support for those devices is "almost" in mainline :-). > > Regards, > Lukasz Majewski > > > > > Thanks > > - Suriyan > > > > > > On Sun, Jul 7, 2013 at 11:56 PM, Lukasz Majewski > > wrote: > > > > > On Sun, 07 Jul 2013 02:15:17 -0700, Suriyan Ramasami wrote: > > > > > > Hi Suriyan, > > > > > > > Hi wonderful folks! > > > > > > > > I own an odroid-u2 and the u-boot that comes with it does not > > > > have usb support. Its configuration is smdk4412 and I do not find > > > > that in the u-boot sources. I see it in the arndale and harkernel > > > > branches. > > > > > > > >I do see that usb support was added to the arndale platform - > > > > which is exynos5 based. Is it easy to port it for exynos4412? > > > > > > Patches for Exynos4412 based board (TRATS2) were already sent on the > > > mailing list: > > > > > > > > > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/161578/match=introduce+samsung's+new+board+trats2 > > > > > > Please refer to them. It shall be relatively easy to add odroid-u2 > > > support based on TRATS2. > > > > > > > > > > >I did try it porting on my own accord and am listing it > > > > below... > > > > > > > >I seem to be hitting issues in drivers/usb/host/ehci-exynos.c > > > > -> function setup_usb_phy(struct exynos_usb_phy *usb). > > > > Would passing the correct address of usb for the exynos4412 do the > > > > trick? If so what should it be? > > > > In this same file ehci_hcd_init() uses gpio->x3 and gpio->d1. In > > > > exynos4 looks like x3 is from gpio_part2. Also, do the d1 and x3 > > > > translate to the same gpiod1 and gpiox3 in the exynos4412? > > > > > > > > Furthermore, ehci-exynos.c uses functions from > > > > arch/arm/cpu/armv7/exynos/system.c which for the most part are > > > > exynos5 oriented and do nothing for exynos4. > > > > > > > > Can someone guide me as to what I could do, or some pointers to > > > > helpful docs? I do have the Exynos 4412 user manual. > > > > > > > > Thanks > > > > - Suriyan > > > > > > > > > -- > > > Best regards, > > > > > > Lukasz Majewski > > > > > > Samsung R&D Institute Poland (SRPOL) | Linux Platform Group > > > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On Thu, Jul 11, 2013 at 06:14:11PM +0200, Albert ARIBAUD wrote: > On Thu, 11 Jul 2013 18:08:59 +0200, Albert ARIBAUD > wrote: > > > Hi Tom, > > > > On Thu, 11 Jul 2013 11:54:09 -0400, Tom Rini wrote: > > > > > The new in the patch > > > board/ti/am335x/u-boot.lds needed to be re-synced with > > > arch/arm/cpu/u-boot.lds again. > > > > Actually, I wonder why so many ARM .lds files need to exist at all, > > when arch/arm/cpu/u-boot[-spl].lds could be used most of the time. I > > suspect that the main reason for custom .lds files is ad hoc MEMORY > > declarations, which could easily be commonalized through adequate > > preprocessing. > > ... well here the only difference with arch/arm/cpu/u-boot.lds is the > addition of board/ti/am335x/libam335x.o right after start.o but this > should probably also be manageable in arch/arm/cpu/u-boot.lds. Right. And this is a hard requirement (rather than "lets try and optimize around flash sectors for least waste) for NOR to work. -- 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] OpenRD: relocate environment to 640kB
On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote: > Hi Sascha, > > On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe > wrote: > > > Hello Albert, hello Tom, > > > > Albert ARIBAUD writes: > > > > [Move environment to account for increase in U-Boot size] > > > This patch is for 2013.10, not 2013.07, but I prefer raising the issue > > > as early as possible. > > > > > > If there is no way to make things smoother, then I think the 2013.10 > > > release notes should contain a red, blinking, paragraph about this. I > > > would *hate* it if people were not warned and given a method to port > > > their current environment setting over. > > > > > > Possibly even, the 2013.07 could have a warning about the change to > > > come, so that people have a better chance yet to prepare for the > > > change. > > > > The situation has gotten better recently and U-Boot fits into the > > previous partition size of 384KiB again. So it isn't broken on OpenRD > > anymore and the above would seem like a good approach. > > How well does it fit again, and do you have any idea what caused the > increase in size, and what caused the decrease? I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections is what brought the size back down again. We've been adding a lot of kinda optional code, and to avoid having to ifdef the hell out of everything, we've been relying on growth not being a big problem or just ignoring it. -- 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 v2 7/7] am335x_evm: Add support to boot from NOR.
On Thu, 11 Jul 2013 18:08:59 +0200, Albert ARIBAUD wrote: > Hi Tom, > > On Thu, 11 Jul 2013 11:54:09 -0400, Tom Rini wrote: > > > The new in the patch > > board/ti/am335x/u-boot.lds needed to be re-synced with > > arch/arm/cpu/u-boot.lds again. > > Actually, I wonder why so many ARM .lds files need to exist at all, > when arch/arm/cpu/u-boot[-spl].lds could be used most of the time. I > suspect that the main reason for custom .lds files is ad hoc MEMORY > declarations, which could easily be commonalized through adequate > preprocessing. ... well here the only difference with arch/arm/cpu/u-boot.lds is the addition of board/ti/am335x/libam335x.o right after start.o but this should probably also be manageable in arch/arm/cpu/u-boot.lds. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
Hi Tom, On Thu, 11 Jul 2013 11:54:09 -0400, Tom Rini wrote: > The new in the patch > board/ti/am335x/u-boot.lds needed to be re-synced with > arch/arm/cpu/u-boot.lds again. Actually, I wonder why so many ARM .lds files need to exist at all, when arch/arm/cpu/u-boot[-spl].lds could be used most of the time. I suspect that the main reason for custom .lds files is ad hoc MEMORY declarations, which could easily be commonalized through adequate preprocessing. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AM335x: env_{flash,nowhere} compile conflict
I'm struggling to work out why I get the following compile error:-
arm-linux-ld.bfd -r -o /home/mpfj/uboot/u-boot/spl/common/libcommon.o
/home/mpfj/uboot/u-boot/spl/common/cmd_nvedit.o
/home/mpfj/uboot/u-boot/spl/common/console.o
/home/mpfj/uboot/u-boot/spl/common/dlmalloc.o
/home/mpfj/uboot/u-boot/spl/common/env_common.o
/home/mpfj/uboot/u-boot/spl/common/env_flash.o
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o
/home/mpfj/uboot/u-boot/spl/common/image-fdt.o
/home/mpfj/uboot/u-boot/spl/common/image.o
/home/mpfj/uboot/u-boot/spl/common/memsize.o
/home/mpfj/uboot/u-boot/spl/common/miiphyutil.o
/home/mpfj/uboot/u-boot/spl/common/stdio.o
/home/mpfj/uboot/u-boot/spl/common/xyzModem.o
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o: In function
`env_relocate_spec':
/home/mpfj/uboot/u-boot/common/env_nowhere.c:38: multiple definition of
`env_relocate_spec'
/home/mpfj/uboot/u-boot/spl/common/env_flash.o:/home/mpfj/uboot/u-boot/common/env_flash.c:321:
first defined here
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o: In function `env_init':
/home/mpfj/uboot/u-boot/common/env_nowhere.c:47: multiple definition of
`env_init'
/home/mpfj/uboot/u-boot/spl/common/env_flash.o:/home/mpfj/uboot/u-boot/common/env_flash.c:78:
first defined here
/home/mpfj/uboot/u-boot/spl/common/env_nowhere.o: In function
`env_relocate_spec':
/home/mpfj/uboot/u-boot/common/env_nowhere.c:38: multiple definition of
`env_ptr'
/home/mpfj/uboot/u-boot/spl/common/env_flash.o:(.data.env_ptr+0x0): first
defined here
make[3]: *** [/home/mpfj/uboot/u-boot/spl/common/libcommon.o] Error 1
make[3]: Leaving directory `/home/mpfj/uboot/u-boot/common'
make[2]: *** [/home/mpfj/uboot/u-boot/spl/common/libcommon.o] Error 2
make[2]: Leaving directory `/home/mpfj/uboot/u-boot/spl'
make[1]: *** [spl/u-boot-spl.bin] Error 2
make[1]: Leaving directory `/home/mpfj/uboot/u-boot'
make: *** [nanobone_sdboot] Error 2
I have 2 custom entries in the boards.cfg file:-
nanobone arm armv7 nanobone
newflowam33xx nanobone:NOR_BOOT
nanobone_sdboot arm armv7 nanobone
newflowam33xx nanobone:SD_BOOT
My nanobone.h file is attached.
I'd appreciate it is someone could tell me why env_nowhere.o is being compiled
in even though
CONFIG_ENV_IS_NOWHERE is not defined.
Cheers
Mark J.
/*
* nanobone.h
*
* Copyright (C) 2013 Newflow Ltd - http://www.newflow.co.uk/
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation version 2.
*
* This program is distributed "as is" WITHOUT ANY WARRANTY of any
* kind, whether express or implied; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#ifndef __CONFIG_NANOBONE_H
#define __CONFIG_NANOBONE_H
#define CONFIG_AM33XX
#define CONFIG_OMAP
#include
#define CONFIG_DMA_COHERENT
#define CONFIG_DMA_COHERENT_SIZE (1 << 20)
#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */
#define CONFIG_SYS_MALLOC_LEN (1024 << 10)
#define CONFIG_SYS_LONGHELP /* undef to save memory */
#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */
#define CONFIG_SYS_PROMPT "U-Boot# "
#define CONFIG_BOARD_LATE_INIT
#define MACH_TYPE_NANOBONE 4483
#define CONFIG_MACH_TYPE MACH_TYPE_NANOBONE
#define CONFIG_OF_LIBFDT
#define CONFIG_CMD_BOOTZ
#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
/* Custom script for NOR */
#define CONFIG_SYS_LDSCRIPT "board/newflow/nanobone/u-boot.lds"
#define CONFIG_SYS_CACHELINE_SIZE 64
/* commands to include */
#include
#define CONFIG_CMD_ASKENV
#define CONFIG_VERSION_VARIABLE
/* set to negative value for no autoboot */
#define CONFIG_BOOTDELAY 0
#define CONFIG_ZERO_BOOTDELAY_CHECK
#define CONFIG_ENV_VARS_UBOOT_CONFIG
#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
#ifndef CONFIG_SPL_BUILD
#ifdef CONFIG_SD_BOOT
#define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8020\0" \
"mmcdev=0\0" \
"bootenv=uEnv.txt\0" \
"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
"importbootenv=echo Importing environment from mmc ...; " \
"env import -t ${loadaddr} ${filesize}\0" \
#define CONFIG_BOOTCOMMAND \
"mtdparts default;" \
"if run loadbootenv; then " \
"echo Loaded environment from ${bootenv};" \
"run importbootenv;" \
"if test -n $uenvcmd; then " \
"echo Running uenvcmd ...;" \
"run uenvcmd;" \
"fi;" \
"fi;" \
#endif /* CONFIG_SD_BOOT */
#ifdef CONFIG_NOR_BOOT
#define CONFIG_EXTRA_ENV_SETTINGS \
"loadaddr=0x8020\0" \
"fdtaddr=0x80f8\0" \
"fdt_high=0x\0" \
"kerneladdr=0x0810\0"
#define CONFIG_BOOTARGS \
"console=ttyO0,115200n8 noinitrd ip=off " \
"mem=256M rootwait=1 ubi.mtd=7,2048 " \
"rootfstype=jffs2 root=/dev/mtdblock5"
#define C
Re: [U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices
Dear Roger Quadros,
> Hi Marek,
>
> On 07/11/2013 03:35 PM, Marek Vasut wrote:
> > Dear Roger Quadros,
> >
> >> On 07/11/2013 02:16 AM, Dan Murphy wrote:
> >>> On 07/10/2013 05:20 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
> > Add a __weak function that can be overridden to reset devices
> > attached to an ehci devices after the FEAT_POWER has been submitted
> >
> > Signed-off-by: Dan Murphy
> > ---
> >
> > drivers/usb/host/ehci-hcd.c |7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/usb/host/ehci-hcd.c
> > b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> > @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct
> > ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
> >
> > }
> >
> > +__weak void ehci_reset_attached_devices(int port)
> > +{
> > + return;
> > +}
> >>
> >> Does this function need to be ehci specific? Other USB controllers might
> >> also need such a function.
> >
> > You'd need to implement this for each of the xHCIs
>
> OK.
>
> > +
>
> Can the reset not happen elsewhere?
> >>>
> >>> I have tried to move this around and keep this out of this file
> >>> completely but nothing else seems to work.
> >>>
> >>> For port 2 where the USB3530 is we don't have the issue the 3530
> >>> enumerates properly.
> >>>
> >>> I did not see any information in the data sheet eluding to a timing
> >>> issue.
> >>
> >> This is the information I had received earlier from SMSC about USB3503A
> >> hub
> >>
> >> "You need the host up and running, and ready to go, THEN negate RESET_N.
> >> That is probably 95% of the issues."
> >>
> >> Please make sure the following sequence is done.
> >>
> >> - power up hub (RESET is active at this point).
> >> - start USB controller
> >> - wait a few ms
> >> - release hub RESET.
> >>
> >> giving a quick look at the u-boot code it seems you need to release the
> >> hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
> >
> > Then it would also work in usb_lowlevel_init() ?
>
> It should as long as we place the "release reset" after EHCI controller
> has started. Maybe safer to put it in the end of usb_lowlevel_init().
Can you maybe use any of the hooks efikamx uses ?
board/genesi/mx51_efikamx/efikamx-usb.c
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 v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander
On 07/10/2013 06:56 PM, Nishanth Menon wrote:
> On 07/10/2013 03:06 PM, Dan Murphy wrote:
>> Configure the tca6424 gpio expander
>> This allows use of the debug and tri color LEDs.
>>
>> Signed-off-by: Dan Murphy
>> ---
>> board/ti/omap5_uevm/evm.c | 21 +
>> board/ti/omap5_uevm/mux_data.h |2 ++
>> include/configs/omap5_uevm.h |5 +
>> 3 files changed, 28 insertions(+)
>>
>> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
>> index 90046e8..0e9a559 100644
>> --- a/board/ti/omap5_uevm/evm.c
>> +++ b/board/ti/omap5_uevm/evm.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "mux_data.h"
>>
>> @@ -35,6 +36,24 @@ const struct omap_sysinfo sysinfo = {
>> "Board: OMAP5430 EVM\n"
>> };
>>
>> +/* @brief tca642x_init - Initial states for the GPIO expander
> documentation style?
> /*
> * @brief
> ?
>> + * input reg, output reg, polarity reg, configuration reg
>> + */
>> +struct tca642x_bank_info tca642x_init[] = {
>> +{ .input_reg = 0x00,
>> + .output_reg = 0x04,
>> + .polarity_reg = 0x00,
>> + .configuration_reg = 0x80 },
>> +{ .input_reg = 0x00,
>> + .output_reg = 0x00,
>> + .polarity_reg = 0x00,
>> + .configuration_reg = 0xff },
>> +{ .input_reg = 0x00,
>> + .output_reg = 0x00,
>> + .polarity_reg = 0x00,
>> + .configuration_reg = 0x40 },
>> +};
>> +
>> /**
>>* @brief board_init
>>*
>> @@ -46,6 +65,8 @@ int board_init(void)
>> gd->bd->bi_arch_number = MACH_TYPE_OMAP5_SEVM;
>> gd->bd->bi_boot_params = (0x8000 + 0x100); /* boot param addr */
>>
>> +tca642x_set_inital_state(CONFIG_SYS_I2C_TCA642X_ADDR, tca642x_init);
>> +
>> return 0;
>> }
>>
>> diff --git a/board/ti/omap5_uevm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
>> index a82795d..7e6415e 100644
>> --- a/board/ti/omap5_uevm/mux_data.h
>> +++ b/board/ti/omap5_uevm/mux_data.h
>> @@ -56,6 +56,8 @@ const struct pad_conf_entry core_padconf_array_essential[]
>> = {
>> {USBD0_HS_DP, (IEN | M0)},/* USBD0_HS_DP */
>> {USBD0_HS_DM, (IEN | M0)},/* USBD0_HS_DM */
>> {USBD0_SS_RX, (IEN | M0)},/* USBD0_SS_RX */
>> +{I2C5_SCL, (IEN | M0)}, /* I2C5_SCL */
> nit pick -> SCL (or i2c clk) is out put from master - always. IEN enables
> full duplex, but anyways.. just a nitpick :)
>
OK I changed this and did a test and reads fail without the IEN set.
This is to sync the client clocks.
>> +{I2C5_SDA, (IEN | M0)}, /* I2C5_SDA */
>>
>> };
>>
>> diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
>> index 46dacc2..bee1278 100644
>> --- a/include/configs/omap5_uevm.h
>> +++ b/include/configs/omap5_uevm.h
>> @@ -53,6 +53,11 @@
>> #define CONFIG_PARTITION_UUIDS
>> #define CONFIG_CMD_PART
>>
>> +#define CONFIG_TCA642X
>> +#define CONFIG_CMD_TCA642X
>> +#define CONFIG_SYS_I2C_TCA642X_BUS_NUM 4
>> +#define CONFIG_SYS_I2C_TCA642X_ADDR 0x22
>> +
>> #define CONFIG_SYS_PROMPT"OMAP5432 uEVM # "
>>
>> #define CONSOLEDEV"ttyO2"
>>
>
> Else,
> no further comments from me.
> --
> Regards,
> Nishanth Menon
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] am335x_evm: Add support to boot from NOR.
On Thu, Jul 11, 2013 at 04:34:18PM +0200, Albert ARIBAUD wrote: > Hi Mark, > > On Thu, 11 Jul 2013 14:45:08 +0100, Mark Jackson > wrote: > > > On 11/07/13 14:28, Tom Rini wrote: > > > On Thu, Jul 11, 2013 at 02:06:26PM +0100, Mark Jackson wrote: > > >> On 18/06/13 13:11, Mark Jackson wrote: > > >>> On 17/06/13 15:43, Mark Jackson wrote: > > >> > > >> Okay ... I've now got NOR booting rebased to master using the patch set > > >> below. > > >> This doesn't include my board code as that's of no interest until NOR > > >> booting > > >> is added to the mainline code. > > >> > > >> Sorry, Tom, I'm no git expert, so I'm not sure how to compare this to > > >> your > > >> previous patches ... I hope this is useful in some way ?? > > > > > > I'm just starting to cycle back to the NOR patches again myself and > > > fixup the few remaining comments. But in your series: > > > > > >> diff --git a/arch/arm/config.mk b/arch/arm/config.mk > > >> index e80e1ed..ba310cb 100644 > > >> --- a/arch/arm/config.mk > > >> +++ b/arch/arm/config.mk > > >> @@ -111,6 +111,6 @@ endif > > >> endif > > >> > > >> # check that only R_ARM_RELATIVE relocations are generated > > >> -ifneq ($(CONFIG_SPL_BUILD),y) > > >> +ifneq ($(CONFIG_SPL_BUILD)$(CONFIG_NOR_BOOT),y) > > >> ALL-y += checkarmreloc > > >> endif > > > > > > What toolchain are you using? This seems worrying at best. > > > > Generated via Buildroot ... here's the (rather copious) version info ... > > > > mpfj@mpfj-nanobone:~/uboot/u-boot$ arm-linux-gcc --version -v > > Using built-in specs. > > COLLECT_GCC=arm-linux-gcc > > COLLECT_LTO_WRAPPER=/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper > > arm-linux-gcc (Buildroot 2013.02-dirty) 4.6.3 > > Copyright (C) 2011 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > > > Target: arm-buildroot-linux-uclibcgnueabi > > Configured with: /home/mpfj/buildroot/output/toolchain/gcc-4.6.3/configure > > --prefix=/home/mpfj/buildroot/output/host/usr > > --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu > > --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c,c++ > > --with-sysroot=/home/mpfj/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot > > > > --with-build-time-tools=/home/mpfj/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/bin > > --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath > > --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib > > --enable-tls --enable-shared > > --with-gmp=/home/mpfj/buildroot/output/host/usr > > --with-mpfr=/home/mpfj/buildroot/output/host/usr > > --with-mpc=/home/mpfj/buildroot/output/host/usr --disable-nls > > --enable-threads --disable-decimal-float --with-abi=aapcs-linux > > --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile > > --with-pkgversion='Buildroot 2013.02-dirty' > > --with-bugurl=http://bugs.buildroot.net/ --wi > th > > -fpu=vfpv > > 3 --with-float=hard > > Thread model: posix > > gcc version 4.6.3 (Buildroot 2013.02-dirty) > > COLLECT_GCC_OPTIONS='--version' '-v' '-march=armv7-a' '-mtune=cortex-a8' > > '-mfloat-abi=hard' '-mfpu=vfpv3' '-mabi=aapcs-linux' > > > > /home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/cc1 > > -quiet -v help-dummy -quiet -dumpbase help-dummy -march=armv7-a > > -mtune=cortex-a8 -mfloat-abi=hard -mfpu=vfpv3 -mabi=aapcs-linux -auxbase > > help-dummy -version --version -o /tmp/cczFlXPw.s > > GNU C (Buildroot 2013.02-dirty) version 4.6.3 > > (arm-buildroot-linux-uclibcgnueabi) > > compiled by GNU C version 4.6.3, GMP version 5.1.0, MPFR version > > 3.1.1-p2, MPC version 1.0.1 > > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > > COLLECT_GCC_OPTIONS='--version' '-v' '-march=armv7-a' '-mtune=cortex-a8' > > '-mfloat-abi=hard' '-mfpu=vfpv3' '-mabi=aapcs-linux' > > > > /home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/as > > -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3 -meabi=5 --version -o > > /tmp/ccgLl9x8.o /tmp/cczFlXPw.s > > GNU assembler (GNU Binutils) 2.21.1 > > Copyright 2011 Free Software Foundation, Inc. > > This program is free software; you may redistribute it under the terms of > > the GNU General Public License version 3 or later. > > This program has absolutely no warranty. > > This assembler was configured for a target of > > `arm-buildroot-linux-uclibcgnueabi'. > > COMPILER_PATH=/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/:/home/mpfj/buildroot/out
Re: [U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices
Roger
On 07/11/2013 09:23 AM, Roger Quadros wrote:
> Hi Marek,
>
> On 07/11/2013 03:35 PM, Marek Vasut wrote:
>> Dear Roger Quadros,
>>
>>> On 07/11/2013 02:16 AM, Dan Murphy wrote:
On 07/10/2013 05:20 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Add a __weak function that can be overridden to reset devices
>> attached to an ehci devices after the FEAT_POWER has been submitted
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> drivers/usb/host/ehci-hcd.c |7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
>> index 706cf0c..fdd3994 100644
>> --- a/drivers/usb/host/ehci-hcd.c
>> +++ b/drivers/usb/host/ehci-hcd.c
>> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct
>> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port];
>>
>> }
>>
>> +__weak void ehci_reset_attached_devices(int port)
>> +{
>> +return;
>> +}
>>> Does this function need to be ehci specific? Other USB controllers might
>>> also need such a function.
>> You'd need to implement this for each of the xHCIs
> OK.
I can move the API to the usb-hub to call this after the FEAT_POWER is completed
>> +
> Can the reset not happen elsewhere?
I have tried to move this around and keep this out of this file
completely but nothing else seems to work.
For port 2 where the USB3530 is we don't have the issue the 3530
enumerates properly.
I did not see any information in the data sheet eluding to a timing
issue.
>>> This is the information I had received earlier from SMSC about USB3503A hub
This has nothing to do with the 3503A this is the LAN9730. The 3503 works just
fine
without the additional reset.
>>>
>>> "You need the host up and running, and ready to go, THEN negate RESET_N.
>>> That is probably 95% of the issues."
>>>
>>> Please make sure the following sequence is done.
>>>
>>> - power up hub (RESET is active at this point).
>>> - start USB controller
>>> - wait a few ms
>>> - release hub RESET.
>>>
>>> giving a quick look at the u-boot code it seems you need to release the hub
>>> reset after usb_lowlevel_init() _OR_ usb_init() returns.
>> Then it would also work in usb_lowlevel_init() ?
> It should as long as we place the "release reset" after EHCI controller
> has started. Maybe safer to put it in the end of usb_lowlevel_init().
>
> cheers,
> -roger
I moved the reset to the usb_lowlevel_init and it did not work.
I tried holding the 9730 in reset until after ehci hcd init is complete and
pulled it out of
reset once the hcd is initialized but still no enumeration.
Dan
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: fec: Remove bogus flush_dcache_range() call
Remove incorrectly called and duplicate flush_dcache_range() call from fec_mxc driver. The call is not needed, since the caches are already flushed in fec_tbd_init(), moreover the second argument should be the ending address, not size. Signed-off-by: Marek Vasut Reported-by: Albert Aribaud Cc: Stefano Babic Cc: Tom Rini --- drivers/net/fec_mxc.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index da95e28..97bf8fe 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -560,7 +560,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd) } memset(fec->tbd_base, 0, size); fec_tbd_init(fec); - flush_dcache_range((unsigned)fec->tbd_base, size); } /* -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] ARM: AM43xx: Add config file
Add config file
Signed-off-by: Lokesh Vutla
---
boards.cfg |1 +
include/configs/am43xx_evm.h | 143 ++
2 files changed, 144 insertions(+)
create mode 100644 include/configs/am43xx_evm.h
diff --git a/boards.cfg b/boards.cfg
index c0c4282..067df4d 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -249,6 +249,7 @@ am335x_evm_uart3 arm armv7 am335x
ti
am335x_evm_uart4 arm armv7 am335x ti
am33xx am335x_evm:SERIAL5,CONS_INDEX=5
am335x_evm_uart5 arm armv7 am335x ti
am33xx am335x_evm:SERIAL6,CONS_INDEX=6
am335x_evm_usbsplarm armv7 am335x ti
am33xx am335x_evm:SERIAL1,CONS_INDEX=1,SPL_USBETH_SUPPORT
+am43xx_evm arm armv7 am43xx ti
am33xx am43xx_evm:SERIAL1,CONS_INDEX=1
ti814x_evm arm armv7 ti814x ti
am33xx
pcm051 arm armv7 pcm051
phytec am33xx pcm051
sama5d3xek_mmc arm armv7 sama5d3xek atmel
at91sama5d3xek:SAMA5D3,SYS_USE_MMC
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
new file mode 100644
index 000..602d3e7
--- /dev/null
+++ b/include/configs/am43xx_evm.h
@@ -0,0 +1,143 @@
+/*
+ * am43xx_evm.h
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __CONFIG_AM43XX_EVM_H
+#define __CONFIG_AM43XX_EVM_H
+
+#define CONFIG_AM43XX
+#define CONFIG_OMAP
+#define CONFIG_OMAP_COMMON
+
+#include
+
+#define CONFIG_DMA_COHERENT
+#define CONFIG_DMA_COHERENT_SIZE (1 << 20)
+
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB */
+#define CONFIG_SYS_MALLOC_LEN (1024 << 10)
+#define CONFIG_SYS_LONGHELP/* undef to save memory */
+#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */
+#define CONFIG_SYS_PROMPT "U-Boot# "
+#define CONFIG_SYS_NO_FLASH
+
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_INITRD_TAG
+
+/* commands to include */
+#include
+
+#define CONFIG_CMD_ASKENV
+#define CONFIG_VERSION_VARIABLE
+
+/* set to negative value for no autoboot */
+#define CONFIG_BOOTDELAY 1
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+
+/* Clock Defines */
+#define V_OSCK 2400 /* Clock output from T2 */
+#define V_SCLK (V_OSCK)
+
+#define CONFIG_CMD_ECHO
+
+/* max number of command args */
+#define CONFIG_SYS_MAXARGS 64
+
+/* Console I/O Buffer Size */
+#define CONFIG_SYS_CBSIZE 512
+
+/* Print Buffer Size */
+#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE \
+ + sizeof(CONFIG_SYS_PROMPT) + 16)
+
+/* Boot Argument Buffer Size */
+#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
+
+ /* Physical Memory Map */
+#define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */
+#define PHYS_DRAM_10x8000 /* DRAM Bank #1 */
+#define CONFIG_MAX_RAM_BANK_SIZE (1024 << 20)/* 1GB */
+
+#define CONFIG_SYS_SDRAM_BASE PHYS_DRAM_1
+#define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \
+ GENERATED_GBL_DATA_SIZE)
+/* Platform/Board specific defs */
+#define CONFIG_SYS_LOAD_ADDR 0x8100 /* Default load address */
+
+#define CONFIG_SYS_TIMERBASE 0x4804 /* Use Timer2 */
+#define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) => 8 */
+#define CONFIG_SYS_HZ 1000
+
+/* NS16550 Configuration */
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_REG_SIZE(-4)
+#define CONFIG_SYS_NS16550_CLK (4800)
+#define CONFIG_SYS_NS16550_COM10x44e09000 /* Base EVM has
UART0 */
+
+#define CONFIG_BAUDRATE115200
+#define CONFIG_SYS_BAUDRATE_TABLE { 110, 300, 600, 1200, 2400, \
+4800, 9600, 14400, 1920
[U-Boot] [PATCH 5/6] ARM: AM43xx: Add build support
Add AM43xx support in the required places
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/Makefile |2 +-
arch/arm/cpu/armv7/omap-common/boot-common.c |3 ++-
drivers/serial/ns16550.c |5 +++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 7a8c2d0..17fa4e2 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -32,7 +32,7 @@ COBJS += cache_v7.o
COBJS += cpu.o
COBJS += syslib.o
-ifneq
($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI814X),)
+ifneq
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI814X),)
SOBJS += lowlevel_init.o
endif
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 76ae1b6..a6e4481 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -48,7 +48,8 @@ void save_omap_boot_params(void)
if ((boot_device >= MMC_BOOT_DEVICES_START) &&
(boot_device <= MMC_BOOT_DEVICES_END)) {
-#if !defined(CONFIG_AM33XX) && !defined(CONFIG_TI81XX)
+#if !defined(CONFIG_AM33XX) && !defined(CONFIG_TI81XX) && \
+ !defined(CONFIG_AM43XX)
if ((omap_hw_init_context() ==
OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
gd->arch.omap_boot_params.omap_bootmode =
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index d77c25f..bc976ba 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -57,7 +57,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(CONFIG_SYS_NS16550_IER, &com_port->ier);
#if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
- defined(CONFIG_AM33XX) || defined(CONFIG_TI814X)
+ defined(CONFIG_AM33XX) || defined(CONFIG_TI814X) || \
+ defined(CONFIG_AM43XX)
serial_out(0x7, &com_port->mdr1); /* mode select reset TL16C750*/
#endif
serial_out(UART_LCR_BKSE | UART_LCRVAL, &com_port->lcr);
@@ -72,7 +73,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(UART_LCRVAL, &com_port->lcr);
#if (defined(CONFIG_OMAP) && !defined(CONFIG_OMAP3_ZOOM2)) || \
defined(CONFIG_AM33XX) || defined(CONFIG_SOC_DA8XX) || \
- defined(CONFIG_TI814X)
+ defined(CONFIG_TI814X) || defined(CONFIG_AM43XX)
/* /16 is proper to hit 115200 with 48MHz */
serial_out(0, &com_port->mdr1);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/6] ARM: AM43xx: clocks: Add dpll and clock data
Add dpll and clock data for AM43xx
Signed-off-by: Lokesh Vutla
---
arch/arm/cpu/armv7/am33xx/Makefile |7 +-
arch/arm/cpu/armv7/am33xx/clock_am43xx.c | 120 ++
2 files changed, 126 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/clock_am43xx.c
diff --git a/arch/arm/cpu/armv7/am33xx/Makefile
b/arch/arm/cpu/armv7/am33xx/Makefile
index f4ccd2a..89d9104 100644
--- a/arch/arm/cpu/armv7/am33xx/Makefile
+++ b/arch/arm/cpu/armv7/am33xx/Makefile
@@ -18,7 +18,12 @@ LIB = $(obj)lib$(SOC).o
COBJS-$(CONFIG_AM33XX) += clock_am33xx.o
COBJS-$(CONFIG_TI814X) += clock_ti814x.o
-COBJS-$(CONFIG_AM33XX) += clock.o
+COBJS-$(CONFIG_AM43XX) += clock_am43xx.o
+
+ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX),)
+COBJS += clock.o
+endif
+
COBJS += sys_info.o
COBJS += mem.o
COBJS += ddr.o
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
new file mode 100644
index 000..c9842b6
--- /dev/null
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -0,0 +1,120 @@
+/*
+ * clock_am43xx.c
+ *
+ * clocks for AM43XX based boards
+ * Derived from AM33XX based boards
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cm_perpll *const cmper = (struct cm_perpll *)CM_PER;
+struct cm_wkuppll *const cmwkup = (struct cm_wkuppll *)CM_WKUP;
+
+const struct dpll_regs dpll_mpu_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x560,
+ .cm_idlest_dpll = CM_WKUP + 0x564,
+ .cm_clksel_dpll = CM_WKUP + 0x56c,
+ .cm_div_m2_dpll = CM_WKUP + 0x570,
+};
+
+const struct dpll_regs dpll_core_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x520,
+ .cm_idlest_dpll = CM_WKUP + 0x524,
+ .cm_clksel_dpll = CM_WKUP + 0x52C,
+ .cm_div_m4_dpll = CM_WKUP + 0x538,
+ .cm_div_m5_dpll = CM_WKUP + 0x53C,
+ .cm_div_m6_dpll = CM_WKUP + 0x540,
+};
+
+const struct dpll_regs dpll_per_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x5E0,
+ .cm_idlest_dpll = CM_WKUP + 0x5E4,
+ .cm_clksel_dpll = CM_WKUP + 0x5EC,
+ .cm_div_m2_dpll = CM_WKUP + 0x5F0,
+};
+
+const struct dpll_regs dpll_ddr_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x5A0,
+ .cm_idlest_dpll = CM_WKUP + 0x5A4,
+ .cm_clksel_dpll = CM_WKUP + 0x5AC,
+ .cm_div_m2_dpll = CM_WKUP + 0x5B0,
+};
+
+const struct dpll_params dpll_mpu = {
+ -1, -1, -1, -1, -1, -1, -1};
+const struct dpll_params dpll_core = {
+ -1, -1, -1, -1, -1, -1, -1};
+const struct dpll_params dpll_per = {
+ -1, -1, -1, -1, -1, -1, -1};
+const struct dpll_params dpll_ddr = {
+ -1, -1, -1, -1, -1, -1, -1};
+
+void setup_clocks_for_console(void)
+{
+ /* Do not add any spl_debug prints in this function */
+ clrsetbits_le32(&cmwkup->wkclkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
+ CD_CLKCTRL_CLKTRCTRL_SW_WKUP <<
+ CD_CLKCTRL_CLKTRCTRL_SHIFT);
+
+ /* Enable UART0 */
+ clrsetbits_le32(&cmwkup->wkup_uart0ctrl,
+ MODULE_CLKCTRL_MODULEMODE_MASK,
+ MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN <<
+ MODULE_CLKCTRL_MODULEMODE_SHIFT);
+}
+
+void enable_basic_clocks(void)
+{
+ u32 *const clk_domains[] = {
+ &cmper->l3clkstctrl,
+ &cmper->l3sclkstctrl,
+ &cmper->l4lsclkstctrl,
+ &cmwkup->wkclkstctrl,
+ &cmper->emifclkstctrl,
+ 0
+ };
+
+ u32 *const clk_modules_explicit_en[] = {
+ &cmper->l3clkctrl,
+ &cmper->l4lsclkctrl,
+ &cmper->l4fwclkctrl,
+ &cmwkup->wkl4wkclkctrl,
+ &cmper->l3instrclkctrl,
+ &cmper->l4hsclkctrl,
+ &cmwkup->wkgpio0clkctrl,
+ &cmwkup->wkctrlclkctrl,
+ &cmper->timer2clkctrl,
+ &cmper->gpmcclkctrl,
+ &cmper->elmclkctrl,
+ &cmper->mmc0clkctrl,
+ &cmper->mmc1clkctrl,
+ &cmwkup->wkup_i2c0ctrl,
+ &cmper->gpio1clkctrl,
+ &cmper->gpio2clkctrl,
+ &cmper->gpio3clkctrl,
+ &cmper->i2c1clkctrl,
+
[U-Boot] [PATCH 0/6] ARM: AM43xx: Add Support for AM43xx Soc's
AM43xx is a low cost Cortex-A9 based application processor
targets higher performance applications and new specific end
equipments like Point of Sale requiring stringent security requirements.
This series add support for AM43xx Soc's.
Data for the following is not added:
-> SDRAM
-> DPLL Dividers and post dividers
-> Pin mux data(only uart data added).
Once this data is available Ill add them.
Config file is kept minimal for now, ll add the corresponding configs when
they are validated.
This is based on top of u-boot mainline + my recent am33xx cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-0-4-ARM-AM33xx-Cleanup-clocks-and-hwinit-tt157703.html
Testing:
Tested on pre-silicon platform
verified ./MAKEALL --cpu=armv7
./MAKEALL -s omap/am33xx
Lokesh Vutla (6):
ARM: AM43xx: Add Board files
ARM: AM43xx: Add header files
ARM: AM43xx: clocks: Add dpll and clock data
ARM: OMAP: Add CONFIG_OMAP_COMMON
ARM: AM43xx: Add build support
ARM: AM43xx: Add config file
Makefile |2 +-
arch/arm/config.mk |2 +-
arch/arm/cpu/armv7/Makefile|2 +-
arch/arm/cpu/armv7/am33xx/Makefile |7 +-
arch/arm/cpu/armv7/am33xx/clock_am43xx.c | 120 ++
arch/arm/cpu/armv7/omap-common/Makefile|2 +-
arch/arm/cpu/armv7/omap-common/boot-common.c |3 +-
arch/arm/include/asm/arch-am33xx/cpu.h | 164 +++-
arch/arm/include/asm/arch-am33xx/hardware.h|8 +-
arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |9 ++
.../{hardware_am33xx.h => hardware_am43xx.h} | 18 ++-
arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |9 ++
arch/arm/include/asm/arch-am33xx/mux.h |2 +
arch/arm/include/asm/arch-am33xx/mux_am43xx.h | 151 ++
arch/arm/include/asm/arch-am33xx/omap.h|9 +-
arch/arm/include/asm/arch-am33xx/spl.h |4 +-
.../cpu/armv7/am33xx => board/ti/am43xx}/Makefile | 35 ++---
board/ti/am43xx/board.c| 55 +++
board/ti/am43xx/board.h| 25 +++
board/ti/am43xx/mux.c | 35 +
boards.cfg |1 +
drivers/serial/ns16550.c |5 +-
include/configs/am335x_evm.h |1 +
include/configs/am3517_crane.h |1 +
include/configs/am3517_evm.h |1 +
include/configs/am43xx_evm.h | 143 +
include/configs/cm_t35.h |1 +
include/configs/devkit8000.h |1 +
include/configs/dig297.h |1 +
include/configs/igep0033.h |1 +
include/configs/igep00x0.h |1 +
include/configs/mcx.h |1 +
include/configs/nokia_rx51.h |1 +
include/configs/omap3_beagle.h |1 +
include/configs/omap3_evm_common.h |1 +
include/configs/omap3_logic.h |1 +
include/configs/omap3_mvblx.h |1 +
include/configs/omap3_overo.h |1 +
include/configs/omap3_pandora.h|1 +
include/configs/omap3_sdp3430.h|1 +
include/configs/omap3_zoom1.h |1 +
include/configs/omap3_zoom2.h |1 +
include/configs/omap4_common.h |1 +
include/configs/omap5_common.h |1 +
include/configs/pcm051.h |1 +
include/configs/tam3517-common.h |1 +
include/configs/ti814x_evm.h |1 +
include/configs/tricorder.h|1 +
spl/Makefile |2 +-
49 files changed, 783 insertions(+), 55 deletions(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/clock_am43xx.c
copy arch/arm/include/asm/arch-am33xx/{hardware_am33xx.h => hardware_am43xx.h}
(78%)
create mode 100644 arch/arm/include/asm/arch-am33xx/mux_am43xx.h
copy {arch/arm/cpu/armv7/am33xx => board/ti/am43xx}/Makefile (55%)
create mode 100644 board/ti/am43xx/board.c
create mode 100644 board/ti/am43xx/board.h
create mode 100644 board/ti/am43xx/mux.c
create mode 100644 include/configs/am43xx_evm.h
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/6] ARM: AM43xx: Add header files
Adding the following data:
-> Prcm structure
-> Base addresses
-> Pin mux structure.
Signed-off-by: Lokesh Vutla
---
arch/arm/include/asm/arch-am33xx/cpu.h | 164 +++-
arch/arm/include/asm/arch-am33xx/hardware.h|8 +-
arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |9 ++
.../{hardware_am33xx.h => hardware_am43xx.h} | 18 ++-
arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |9 ++
arch/arm/include/asm/arch-am33xx/mux.h |2 +
arch/arm/include/asm/arch-am33xx/mux_am43xx.h | 151 ++
arch/arm/include/asm/arch-am33xx/omap.h|9 +-
arch/arm/include/asm/arch-am33xx/spl.h |4 +-
9 files changed, 348 insertions(+), 26 deletions(-)
copy arch/arm/include/asm/arch-am33xx/{hardware_am33xx.h => hardware_am43xx.h}
(78%)
create mode 100644 arch/arm/include/asm/arch-am33xx/mux_am43xx.h
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index 3d3a7c8..a216bc8 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -51,13 +51,6 @@
#define SYSBOOT_MASK (BIT(0) | BIT(1) | BIT(2)\
| BIT(3) | BIT(4))
-/* Reset control */
-#ifdef CONFIG_AM33XX
-#define PRM_RSTCTRL(PRCM_BASE + 0x0F00)
-#elif defined(CONFIG_TI814X)
-#define PRM_RSTCTRL(PRCM_BASE + 0x00A0)
-#endif
-#define PRM_RSTST (PRM_RSTCTRL + 8)
#define PRM_RSTCTRL_RESET 0x01
#define PRM_RSTST_WARM_RESET_MASK 0x232
@@ -116,6 +109,7 @@ struct gpmc {
/* Used for board specific gpmc initialization */
extern struct gpmc *gpmc_cfg;
+#ifndef CONFIG_AM43XX
/* Encapsulating core pll registers */
struct cm_wkuppll {
unsigned int wkclkstctrl; /* offset 0x00 */
@@ -219,6 +213,162 @@ struct cm_perpll {
unsigned int resv10[8];
unsigned int cpswclkstctrl; /* offset 0x144 */
};
+#else
+/* Encapsulating core pll registers */
+struct cm_wkuppll {
+ unsigned int resv0[136];
+ unsigned int wkl4wkclkctrl; /* offset 0x220 */
+ unsigned int resv1[55];
+ unsigned int wkclkstctrl; /* offset 0x300 */
+ unsigned int resv2[15];
+ unsigned int wkup_i2c0ctrl; /* offset 0x340 */
+ unsigned int resv3;
+ unsigned int wkup_uart0ctrl;/* offset 0x348 */
+ unsigned int resv4[5];
+ unsigned int wkctrlclkctrl; /* offset 0x360 */
+ unsigned int resv5;
+ unsigned int wkgpio0clkctrl;/* offset 0x368 */
+
+ unsigned int resv6[109];
+ unsigned int clkmoddpllcore;/* offset 0x520 */
+ unsigned int idlestdpllcore;/* offset 0x524 */
+ unsigned int resv61;
+ unsigned int clkseldpllcore;/* offset 0x52C */
+ unsigned int resv7[2];
+ unsigned int divm4dpllcore; /* offset 0x538 */
+ unsigned int divm5dpllcore; /* offset 0x53C */
+ unsigned int divm6dpllcore; /* offset 0x540 */
+
+ unsigned int resv8[7];
+ unsigned int clkmoddpllmpu; /* offset 0x560 */
+ unsigned int idlestdpllmpu; /* offset 0x564 */
+ unsigned int resv9;
+ unsigned int clkseldpllmpu; /* offset 0x56c */
+ unsigned int divm2dpllmpu; /* offset 0x570 */
+
+ unsigned int resv10[11];
+ unsigned int clkmoddpllddr; /* offset 0x5A0 */
+ unsigned int idlestdpllddr; /* offset 0x5A4 */
+ unsigned int resv11;
+ unsigned int clkseldpllddr; /* offset 0x5AC */
+ unsigned int divm2dpllddr; /* offset 0x5B0 */
+
+ unsigned int resv12[11];
+ unsigned int clkmoddpllper; /* offset 0x5E0 */
+ unsigned int idlestdpllper; /* offset 0x5E4 */
+ unsigned int resv13;
+ unsigned int clkseldpllper; /* offset 0x5EC */
+ unsigned int divm2dpllper; /* offset 0x5F0 */
+ unsigned int resv14[8];
+ unsigned int clkdcoldodpllper; /* offset 0x614 */
+
+ unsigned int resv15[2];
+ unsigned int clkmoddplldisp;/* offset 0x620 */
+ unsigned int resv16[2];
+ unsigned int clkseldplldisp;/* offset 0x62C */
+ unsigned int divm2dplldisp; /* offset 0x630 */
+};
+
+/*
+ * Encapsulating peripheral functional clocks
+ * pll registers
+ */
+struct cm_perpll {
+ unsigned int l3clkstctrl; /* offset 0x00 */
+ unsigned int resv0[7];
+ unsigned int l3clkctrl; /* Offset 0x20 */
+ unsigned int resv1[7];
+ unsigned int l3instrclkctrl;/* offset 0x40 */
+ unsigned int resv2[3];
+ unsigned int ocmcramclkctrl;/* offset 0x50 */
+ unsigned int resv3[9];
+ unsigned int tpccclkctrl; /* offset 0x78 */
+ unsigned int resv4;
+ unsigned int tptc0clkctrl; /* offset 0x80 */
+
+ unsigned int resv5[7];
+ unsigned int l4hsclkctrl; /* offset 0
[U-Boot] [PATCH 1/6] ARM: AM43xx: Add Board files
Add board specific information for AM43xx.
Signed-off-by: Lokesh Vutla
---
board/ti/am43xx/Makefile | 46 ++
board/ti/am43xx/board.c | 55 ++
board/ti/am43xx/board.h | 25 +
board/ti/am43xx/mux.c| 35 +
4 files changed, 161 insertions(+)
create mode 100644 board/ti/am43xx/Makefile
create mode 100644 board/ti/am43xx/board.c
create mode 100644 board/ti/am43xx/board.h
create mode 100644 board/ti/am43xx/mux.c
diff --git a/board/ti/am43xx/Makefile b/board/ti/am43xx/Makefile
new file mode 100644
index 000..b1301c8
--- /dev/null
+++ b/board/ti/am43xx/Makefile
@@ -0,0 +1,46 @@
+#
+# Makefile
+#
+# Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed "as is" WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifdef CONFIG_SPL_BUILD
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
new file mode 100644
index 000..f65347f
--- /dev/null
+++ b/board/ti/am43xx/board.c
@@ -0,0 +1,55 @@
+/*
+ * board.c
+ *
+ * Board functions for TI AM43XX based boards
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include "board.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_SPL_BUILD
+void set_uart_mux_conf(void)
+{
+ enable_uart0_pin_mux();
+}
+
+void set_mux_conf_regs(void)
+{
+ enable_board_pin_mux();
+}
+
+void sdram_init(void)
+{
+}
+#endif
+
+int board_init(void)
+{
+ gd->bd->bi_boot_params = PHYS_DRAM_1 + 0x100;
+
+ return 0;
+}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ return 0;
+}
+#endif
diff --git a/board/ti/am43xx/board.h b/board/ti/am43xx/board.h
new file mode 100644
index 000..f6b31d3
--- /dev/null
+++ b/board/ti/am43xx/board.h
@@ -0,0 +1,25 @@
+/*
+ * board.h
+ *
+ * TI AM437x boards information header
+ * Derived from AM335x board.
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR /PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _BOARD_H_
+#define _BOARD_H_
+
+void enable_uart0_pin_mux(void);
+void enable_board_pin_mux(void);
+#endif
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
new file mode 100644
index 000..432ddb4
--- /dev/null
+++ b/board/ti/am43xx/mux.c
@@ -0,0 +1,35 @@
+/*
+ * mux.c
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+
[U-Boot] [PATCH 4/6] ARM: OMAP: Add CONFIG_OMAP_COMMON
Adding a new CONFIG_OMAP_COMMON which is included by all boards that needs to build cpu/armv7/omap-common folder. Signed-off-by: Lokesh Vutla --- Makefile|2 +- arch/arm/config.mk |2 +- arch/arm/cpu/armv7/omap-common/Makefile |2 +- include/configs/am335x_evm.h|1 + include/configs/am3517_crane.h |1 + include/configs/am3517_evm.h|1 + include/configs/cm_t35.h|1 + include/configs/devkit8000.h|1 + include/configs/dig297.h|1 + include/configs/igep0033.h |1 + include/configs/igep00x0.h |1 + include/configs/mcx.h |1 + include/configs/nokia_rx51.h|1 + include/configs/omap3_beagle.h |1 + include/configs/omap3_evm_common.h |1 + include/configs/omap3_logic.h |1 + include/configs/omap3_mvblx.h |1 + include/configs/omap3_overo.h |1 + include/configs/omap3_pandora.h |1 + include/configs/omap3_sdp3430.h |1 + include/configs/omap3_zoom1.h |1 + include/configs/omap3_zoom2.h |1 + include/configs/omap4_common.h |1 + include/configs/omap5_common.h |1 + include/configs/pcm051.h|1 + include/configs/tam3517-common.h|1 + include/configs/ti814x_evm.h|1 + include/configs/tricorder.h |1 + spl/Makefile|2 +- 29 files changed, 29 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index fdaddb9..32b6c17 100644 --- a/Makefile +++ b/Makefile @@ -337,7 +337,7 @@ LIBS-y += api/libapi.o LIBS-y += post/libpost.o LIBS-y += test/libtest.o -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifneq ($(CONFIG_OMAP_COMMON),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif diff --git a/arch/arm/config.mk b/arch/arm/config.mk index e80e1ed..f0c15b4 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -24,7 +24,7 @@ CROSS_COMPILE ?= arm-linux- ifndef CONFIG_STANDALONE_LOAD_ADDR -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifneq ($(CONFIG_OMAP_COMMON),) CONFIG_STANDALONE_LOAD_ADDR = 0x8030 else CONFIG_STANDALONE_LOAD_ADDR = 0xc10 diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index c4b9809..8c95253 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -37,7 +37,7 @@ COBJS += vc.o COBJS += abb.o endif -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifeq ($(CONFIG_OMAP34XX),) COBJS += boot-common.o SOBJS += lowlevel_init.o endif diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 9c3c2cd..8b2e38f 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -18,6 +18,7 @@ #define CONFIG_AM33XX #define CONFIG_OMAP +#define CONFIG_OMAP_COMMON #include diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index bf9d63e..6abb190 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -31,6 +31,7 @@ #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */ +#define CONFIG_OMAP_COMMON #define CONFIG_EMIF4 /* The chip has EMIF4 controller */ diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 17fe88d..df9d476 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -31,6 +31,7 @@ #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */ +#define CONFIG_OMAP_COMMON #define CONFIG_EMIF4 /* The chip has EMIF4 controller */ diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index c6e357a..e442af7 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -39,6 +39,7 @@ #define CONFIG_OMAP34XX/* which is a 34XX */ #define CONFIG_OMAP_GPIO #define CONFIG_CM_T3X /* working with CM-T35 and CM-T3730 */ +#define CONFIG_OMAP_COMMON #define CONFIG_SYS_TEXT_BASE 0x80008000 diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 3b74d7c..c6ce192 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -37,6 +37,7 @@ #define CONFIG_OMAP3_DEVKIT80001 /* working with DevKit8000 */ #define CONFIG_MACH_TYPE MACH_TYPE_DEVKIT8000 #define CONFIG_OMAP_GPIO +#define CONFIG_OMAP_COMMON /* * 1MB into the SDRAM to allow for SPL's
Re: [U-Boot] [[PATCH v3 1/2] gpio: tca642x: Add the tca642x gpio expander driver
On 07/11/2013 09:31 AM, Tom Rini wrote: > On Wed, Jul 10, 2013 at 03:06:02PM -0500, Dan Murphy wrote: > >> Add the tca642x gpio expander driver >> >> Datasheet: >> http://www.ti.com/product/tca6424a >> >> Signed-off-by: Dan Murphy >> --- >> drivers/gpio/Makefile |1 + >> drivers/gpio/tca642x.c | 322 >> >> include/tca642x.h | 66 ++ >> 3 files changed, 389 insertions(+) >> create mode 100644 drivers/gpio/tca642x.c >> create mode 100644 include/tca642x.h > Generally fine, but running checkpatch.pl: > total: 0 errors, 12 warnings, 2 checks, 395 lines checked > > NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX > MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE > USLEEP_RANGE > > /tmp/gpio1.mbox has style problems, please review. > > If any of these errors are false positives, please report > them to the maintainer, see CHECKPATCH in MAINTAINERS. > > So, please address those. > Yeah I ran cp on this file and when I looked @ it fixing the LTLs would have made the code look messy IMHO. But I will fix it anyway and re-submit. -- -- Dan Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v3 2/2] gpio: omap5-uevm: Configure the tca6424 gpio expander
On 07/11/2013 09:30 AM, Tom Rini wrote:
> On Wed, Jul 10, 2013 at 06:56:15PM -0500, Nishanth Menon wrote:
>> On 07/10/2013 03:06 PM, Dan Murphy wrote:
>>> Configure the tca6424 gpio expander
>>> This allows use of the debug and tri color LEDs.
>>>
>>> Signed-off-by: Dan Murphy
>>> ---
>>> board/ti/omap5_uevm/evm.c | 21 +
>>> board/ti/omap5_uevm/mux_data.h |2 ++
>>> include/configs/omap5_uevm.h |5 +
>>> 3 files changed, 28 insertions(+)
>>>
>>> diff --git a/board/ti/omap5_uevm/evm.c b/board/ti/omap5_uevm/evm.c
>>> index 90046e8..0e9a559 100644
>>> --- a/board/ti/omap5_uevm/evm.c
>>> +++ b/board/ti/omap5_uevm/evm.c
>>> @@ -26,6 +26,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "mux_data.h"
>>>
>>> @@ -35,6 +36,24 @@ const struct omap_sysinfo sysinfo = {
>>> "Board: OMAP5430 EVM\n"
>>> };
>>>
>>> +/* @brief tca642x_init - Initial states for the GPIO expander
>> documentation style?
>> /*
>> * @brief
>> ?
> /**
> * @brief
>
> even :)
>
> And, no other comments.
>
Got it will fix it
--
--
Dan Murphy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image: Don't relocate ramdisk to highmem
On Thu, Jul 11, 2013 at 08:39:28AM -0400, Tom Rini wrote: > On Thu, Jul 11, 2013 at 11:46:19AM +0200, Wolfgang Denk wrote: > > Dear Thierry Reding, > > > > In message <1373500071-6476-1-git-send-email-thierry.red...@gmail.com> you > > wrote: > > > > > > The Linux kernel cannot unpack a ramdisk that's stored in high memory. > > > > Can you please be a bit more explicit? Which exact architecture are > > you talking about? Can you show a specific example of an error case > > for such a system? > > I'm pretty sure it's all architectures, and this is a problem for device > trees as well. The tricks done to deal with highmem mean it's not > suitable for certain tasks, if I recall things right (it's been a > while). Yes, that's my understanding as well. The same changes were done for fdt_high a few months back and ramdisks aren't any different in this respect. I was a bit surprised that this hadn't been fixed yet, but maybe people just aren't using ramdisks anymore these days, or they worked around it by setting initrd_high explicitly. > > > - /* not set, no restrictions to load high */ > > > - initrd_high = ~0; > > > + /* make sure to put ramdisk in low memory */ > > > + initrd_high = getenv_bootm_low() + getenv_bootm_mapsize(); > > > > I don't like to have such a patch (which affects ALL systems) added > > unless we understand exactly why we should do that. > > > > Why do you not simply set initrd_high as needed? > > The problem is that setting initrd_high (and fdt_high) becomes one of > those things you have to on every new port, and you start to go "why do > I have to do this again?". Relocating to the top of memory is probably the wrong thing to do for a lot of boards these days. I know I've been using the old code without a problem on a number of boards, but more recent hardware tends to come equipped with 1 GiB or more RAM, which should always trigger this error. > In fact, a related problem is that folks set initrd_high/fdt_high to > 0x to just stop relocation Yeah, I wondered whether maybe not relocating the ramdisk (and the FDT) in the first place might even be a better default fallback. It makes the boot process slightly more brittle because it can go equally wrong if people load files to weird locations. It seems, though, that most boards use sensible default locations that are somewhere below the first 256 MiB of RAM. > (which may or may not be a time saver too) after hitting the sequence > of: > - Loaded ramdisk somewhere "good" in memory > - Tried booting the kernel, ramdisk not found > - Spend non-zero time cursing and debugging why the ramdisk wasn't seen > - Realize that U-Boot shoves it up to the top of memory and the kernel > doesn't like that. > - Curse U-Boot for moving things around on you. That's *exactly* what happened to me, only that instead of just not finding the ramdisk it would page fault and oops. The first thing I did was indeed to just set initrd_high to 0x but then decided to try and properly fix it in an attempt to save others the trouble. > > Also, when changing the behaviour, you should also update the > > comments. > > Agreed. I'm not sure which comments you are referring to. I updated the one immediately above the changed code and the one above the function doesn't contain anything relating to the default behaviour in case initrd_high is unset. Thierry 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] ERROR: new format image overwritten ? must reset the board to recover
On Wed, Jul 10, 2013 at 10:08:13PM -0400, David Lee wrote: > Hi. > > We had U-Boot booting Linux just fine. Then after some minor cleanup, we > rebuild the images. > > Thereafter, we are now seeing U-Boot reporting the error below: > > *"ERROR: new format image overwritten ?** must reset the board to recover"* > > We tried reverting the minor cleanup we had done and then rebuild the > images. But we are still still getting the same U-Boot error message with > the board reset after the Linux image was decompressed. We are at a loss > at what the problem is. > > Any thoughts or guidance would be much appreciated. Well, using 'git grep' I see this means you have an overlap between where the contents were loaded into memory and where they want to execute in memory. Changing where you load into memory and where you execute so that they do not overlap is probably the easiest fix. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ERROR: new format image overwritten – must reset the board to recover
Hi. We had U-Boot booting Linux just fine. Then after some minor cleanup, we rebuild the images. Thereafter, we are now seeing U-Boot reporting the error below: *"ERROR: new format image overwritten –** must reset the board to recover"* We tried reverting the minor cleanup we had done and then rebuild the images. But we are still still getting the same U-Boot error message with the board reset after the Linux image was decompressed. We are at a loss at what the problem is. Any thoughts or guidance would be much appreciated. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v2 6/6] ARM: OMAP5-uevm: Add USB ehci support for the uEVM
On Wed, Jul 10, 2013 at 03:05:09PM -0500, Dan Murphy wrote: > Add the USB ehci support for the OMAP5 uEVM. > > Configure the uEVM mux data > Add the flags to build the appropriate modules > Add the usb call backs to initialize the EHCI controller > > Signed-off-by: Dan Murphy [snip] > diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h > index b87ee42..32f053d 100644 > --- a/include/configs/omap5_common.h > +++ b/include/configs/omap5_common.h > @@ -113,8 +113,6 @@ > #define CONFIG_CMD_MMC /* MMC support */ > > /* Disabled commands */ > -#undef CONFIG_CMD_NET > -#undef CONFIG_CMD_NFS > #undef CONFIG_CMD_FPGA /* FPGA configuration Support */ > #undef CONFIG_CMD_IMLS /* List all found images*/ Leave this, since O5 doesn't have networking in the SoC. > diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h > index 46dacc2..b79ea59 100644 > --- a/include/configs/omap5_uevm.h > +++ b/include/configs/omap5_uevm.h > @@ -53,6 +53,30 @@ > #define CONFIG_PARTITION_UUIDS > #define CONFIG_CMD_PART > > +/* USB UHH support options */ > +#define CONFIG_CMD_USB > +#define CONFIG_USB_HOST > +#define CONFIG_USB_EHCI > +#define CONFIG_USB_EHCI_OMAP > +#define CONFIG_USB_STORAGE > +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 > +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET > + > +#define CONFIG_OMAP_EHCI_PHY1_RESET_GPIO 79 > +#define CONFIG_OMAP_EHCI_PHY2_RESET_GPIO 80 > + > +#define CONFIG_PALMAS_USBPWR > + > +/* Enabled commands */ > +#define CONFIG_NET_MULTI > +#define CONFIG_CMD_DHCP /* DHCP Support */ > +#define CONFIG_CMD_NET /* bootp, tftpboot, rarpboot*/ > +#define CONFIG_CMD_NFS /* NFS support */ > + > +/* USB Networking options */ > +#define CONFIG_USB_HOST_ETHER > +#define CONFIG_USB_ETHER_SMSC95XX > + > #define CONFIG_SYS_PROMPT"OMAP5432 uEVM # " > > #define CONSOLEDEV "ttyO2" And then this hunk is fine. -- 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]mx6qsabresd: Add splash screen support via HDMI
Hi Stefano,
Sure, I can try this on my side. I will let you know about this shortly.
Thank you very much for giving your input.
Thanks & Regards,
Pardeep Singla
-Original Message-
From: Stefano Babic [mailto:sba...@denx.de]
Sent: Wednesday, July 10, 2013 8:25 AM
To: Kumar Singla Pardeep-B45784
Cc: sba...@denx.de; Estevam Fabio-R49496; u-boot@lists.denx.de
Subject: Re: [PATCH]mx6qsabresd: Add splash screen support via HDMI
Hi Pardeep,
On 09/07/2013 23:58, Pardeep Kumar Singla wrote:
> Signed-off-by: Pardeep Kumar Singla
> ---
> board/freescale/mx6qsabresd/mx6qsabresd.c | 92
> -
> include/configs/mx6qsabre_common.h|3 +-
> include/configs/mx6qsabresd.h | 13
> 3 files changed, 106 insertions(+), 2 deletions(-)
>
Your patch shares a lot of code with mx6qsabrelite. Can we factorize the common
code ?
> diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c
> b/board/freescale/mx6qsabresd/mx6qsabresd.c
> index 2529826..301fd1b 100644
> --- a/board/freescale/mx6qsabresd/mx6qsabresd.c
> +++ b/board/freescale/mx6qsabresd/mx6qsabresd.c
> @@ -31,6 +31,11 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -133,6 +138,80 @@ static void setup_iomux_uart(void)
> imx_iomux_v3_setup_multiple_pads(uart1_pads,
> ARRAY_SIZE(uart1_pads)); }
>
> +#if defined(CONFIG_VIDEO_IPUV3)
> +static void enable_hdmi(void)
> +{
> + struct hdmi_regs *hdmi = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
> + u8 reg;
> + reg = readb(&hdmi->phy_conf0);
> + reg |= HDMI_PHY_CONF0_PDZ_MASK;
> + writeb(reg, &hdmi->phy_conf0);
> + udelay(3000);
> + reg |= HDMI_PHY_CONF0_ENTMDS_MASK;
> + writeb(reg, &hdmi->phy_conf0);
> + udelay(3000);
> + reg |= HDMI_PHY_CONF0_GEN2_TXPWRON_MASK;
> + writeb(reg, &hdmi->phy_conf0);
> + writeb(HDMI_MC_PHYRSTZ_ASSERT, &hdmi->mc_phyrstz); }
> +
For example, enable:hdmi is really identical to the same function of the
sabrelite.
> +static struct fb_videomode const hdmi = {
> + .name = "HDMI",
> + .refresh= 60,
> + .xres = 1024,
> + .yres = 768,
> + .pixclock = 15385,
> + .left_margin= 220,
> + .right_margin = 40,
> + .upper_margin = 21,
> + .lower_margin = 7,
> + .hsync_len = 60,
> + .vsync_len = 10,
> + .sync = FB_SYNC_EXT,
> + .vmode = FB_VMODE_NONINTERLACED
> +};
> +
> +int board_video_skip(void)
> +{
> + int ret;
> + ret = ipuv3_fb_init(&hdmi, 0, IPU_PIX_FMT_RGB24);
> + if (ret)
> + printf("HDMI cannot be configured: %d\n", ret);
> + enable_hdmi();
> + return ret;
> +}
> +
> +static void setup_display(void)
> +{
> + struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> + struct hdmi_regs *hdmi = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
> + int reg;
> +
> + /* Turn on IPU clock */
> + reg = readl(&mxc_ccm->CCGR3);
> + reg |= MXC_CCM_CCGR3_IPU1_IPU_DI0_OFFSET;
> + writel(reg, &mxc_ccm->CCGR3);
> + /* Turn on HDMI PHY clock */
> + reg = readl(&mxc_ccm->CCGR2);
> + reg |= MXC_CCM_CCGR2_HDMI_TX_IAHBCLK_MASK|
> + MXC_CCM_CCGR2_HDMI_TX_ISFRCLK_MASK;
> + writel(reg, &mxc_ccm->CCGR2);
> + /* clear HDMI PHY reset */
> + writeb(HDMI_MC_PHYRSTZ_DEASSERT, &hdmi->mc_phyrstz);
> + reg = readl(&mxc_ccm->chsccdr);
> + reg &= ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK|
> + MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK|
> + MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
> + reg |= (CHSCCDR_CLK_SEL_LDB_DI0
> + << MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET)|
> + (CHSCCDR_PODF_DIVIDE_BY_3
> + << MXC_CCM_CHSCCDR_IPU1_DI0_PODF_OFFSET)
> + | (CHSCCDR_IPU_PRE_CLK_540M_PFD
> + << MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_OFFSET);
> + writel(reg, &mxc_ccm->chsccdr);
> +}
> +#endif /* CONFIG_VIDEO_IPUV3 */
setup_display has also some common parts with the same function for sabrelite.
Any way to factorize code ?
Best regards,
Stefano Babic
--
=
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 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information
On Thu, Jul 11, 2013 at 11:55:59AM +0300, Roger Quadros wrote: > On 07/11/2013 11:35 AM, Sricharan R wrote: > > On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote: > >> On 07/11/2013 06:51 AM, Lokesh Vutla wrote: > >>> On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote: > * Enable the OMAP5 EHCI host clocks > * Add OMAP5 EHCI register definitions > * Add OMAP5 ES2 host revision > > Signed-off-by: Dan Murphy > --- > arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++ > arch/arm/include/asm/arch-omap5/clock.h |6 + > arch/arm/include/asm/arch-omap5/ehci.h | 43 > +++ > arch/arm/include/asm/ehci-omap.h|1 + > drivers/usb/host/ehci-omap.c|2 +- > 5 files changed, 64 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h > > diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c > b/arch/arm/cpu/armv7/omap5/hw_data.c > index 56cf1f8..055f058 100644 > --- a/arch/arm/cpu/armv7/omap5/hw_data.c > +++ b/arch/arm/cpu/armv7/omap5/hw_data.c > @@ -412,6 +412,8 @@ void enable_basic_clocks(void) > (*prcm)->cm_l4per_gpio4_clkctrl, > (*prcm)->cm_l4per_gpio5_clkctrl, > (*prcm)->cm_l4per_gpio6_clkctrl, > +(*prcm)->cm_clksel_usb_60mhz, > +(*prcm)->cm_l3init_hsusbtll_clkctrl, > >>> guard this with CONFIG_USB_EHCI please or it ll > >>> throw an error for DRA7xx boards. > >> why is DRA7xx using omap5/hw_data.c? > >> > >> doesn't it qualify for its own SoC directory? > > We tried to keep common things for OMAP5/DRA intact and > > added the difference. The above clocks list was same for both. > > In fact there is no armv7/dra directory at all. > > If there is no directory, it could be created I suppose. > IMHO it would become ugly soon if it doesn't have its own hw_data. Lets wait and see how it goes, and if we can't use some of the other tools in our toolbox to clean things up or at least avoid the duplication. -- 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 v2 7/7] am335x_evm: Add support to boot from NOR.
Hi Mark, On Thu, 11 Jul 2013 14:45:08 +0100, Mark Jackson wrote: > On 11/07/13 14:28, Tom Rini wrote: > > On Thu, Jul 11, 2013 at 02:06:26PM +0100, Mark Jackson wrote: > >> On 18/06/13 13:11, Mark Jackson wrote: > >>> On 17/06/13 15:43, Mark Jackson wrote: > >> > >> Okay ... I've now got NOR booting rebased to master using the patch set > >> below. > >> This doesn't include my board code as that's of no interest until NOR > >> booting > >> is added to the mainline code. > >> > >> Sorry, Tom, I'm no git expert, so I'm not sure how to compare this to your > >> previous patches ... I hope this is useful in some way ?? > > > > I'm just starting to cycle back to the NOR patches again myself and > > fixup the few remaining comments. But in your series: > > > >> diff --git a/arch/arm/config.mk b/arch/arm/config.mk > >> index e80e1ed..ba310cb 100644 > >> --- a/arch/arm/config.mk > >> +++ b/arch/arm/config.mk > >> @@ -111,6 +111,6 @@ endif > >> endif > >> > >> # check that only R_ARM_RELATIVE relocations are generated > >> -ifneq ($(CONFIG_SPL_BUILD),y) > >> +ifneq ($(CONFIG_SPL_BUILD)$(CONFIG_NOR_BOOT),y) > >> ALL-y += checkarmreloc > >> endif > > > > What toolchain are you using? This seems worrying at best. > > Generated via Buildroot ... here's the (rather copious) version info ... > > mpfj@mpfj-nanobone:~/uboot/u-boot$ arm-linux-gcc --version -v > Using built-in specs. > COLLECT_GCC=arm-linux-gcc > COLLECT_LTO_WRAPPER=/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/lto-wrapper > arm-linux-gcc (Buildroot 2013.02-dirty) 4.6.3 > Copyright (C) 2011 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > Target: arm-buildroot-linux-uclibcgnueabi > Configured with: /home/mpfj/buildroot/output/toolchain/gcc-4.6.3/configure > --prefix=/home/mpfj/buildroot/output/host/usr > --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu > --target=arm-buildroot-linux-uclibcgnueabi --enable-languages=c,c++ > --with-sysroot=/home/mpfj/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot > > --with-build-time-tools=/home/mpfj/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/bin > --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath > --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib > --enable-tls --enable-shared --with-gmp=/home/mpfj/buildroot/output/host/usr > --with-mpfr=/home/mpfj/buildroot/output/host/usr > --with-mpc=/home/mpfj/buildroot/output/host/usr --disable-nls > --enable-threads --disable-decimal-float --with-abi=aapcs-linux > --with-arch=armv7-a --with-tune=cortex-a8 --disable-largefile > --with-pkgversion='Buildroot 2013.02-dirty' > --with-bugurl=http://bugs.buildroot.net/ --wi th > -fpu=vfpv > 3 --with-float=hard > Thread model: posix > gcc version 4.6.3 (Buildroot 2013.02-dirty) > COLLECT_GCC_OPTIONS='--version' '-v' '-march=armv7-a' '-mtune=cortex-a8' > '-mfloat-abi=hard' '-mfpu=vfpv3' '-mabi=aapcs-linux' > > /home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/cc1 > -quiet -v help-dummy -quiet -dumpbase help-dummy -march=armv7-a > -mtune=cortex-a8 -mfloat-abi=hard -mfpu=vfpv3 -mabi=aapcs-linux -auxbase > help-dummy -version --version -o /tmp/cczFlXPw.s > GNU C (Buildroot 2013.02-dirty) version 4.6.3 > (arm-buildroot-linux-uclibcgnueabi) > compiled by GNU C version 4.6.3, GMP version 5.1.0, MPFR version > 3.1.1-p2, MPC version 1.0.1 > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > COLLECT_GCC_OPTIONS='--version' '-v' '-march=armv7-a' '-mtune=cortex-a8' > '-mfloat-abi=hard' '-mfpu=vfpv3' '-mabi=aapcs-linux' > > /home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgnueabi/bin/as > -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3 -meabi=5 --version -o > /tmp/ccgLl9x8.o /tmp/cczFlXPw.s > GNU assembler (GNU Binutils) 2.21.1 > Copyright 2011 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or later. > This program has absolutely no warranty. > This assembler was configured for a target of > `arm-buildroot-linux-uclibcgnueabi'. > COMPILER_PATH=/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/libexec/gcc/arm-buildroot-linux-uclibcgnueabi/:/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/:/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/:/home/mpfj/buildroot/output/host/usr/lib/gcc/arm-buildroot-linux-uclibcgnueabi/4.6.3/../../../../arm-buildroot-linux-uclibcgn
