[U-Boot] [PATCH] powerpc/t4240rdb: Convert to use generic board code
Signed-off-by: Chunhe Lan chunhe@freescale.com --- include/configs/T4240RDB.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/T4240RDB.h b/include/configs/T4240RDB.h index 5ab1b47..eff1db9 100644 --- a/include/configs/T4240RDB.h +++ b/include/configs/T4240RDB.h @@ -12,6 +12,8 @@ #define CONFIG_T4240RDB #define CONFIG_PHYS_64BIT +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO #define CONFIG_FSL_SATA_V2 #define CONFIG_PCIE4 -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] kirkwood: ib62x0: add CONFIG_SYS_GENERIC_BOARD define
-Original Message- From: Luka Perkov [mailto:l...@openwrt.org] Sent: 30 November 2014 09:31 To: u-boot@lists.denx.de Cc: Luka Perkov; Prafulla Wadaskar; Stefan Roese Subject: [PATCH 1/6] kirkwood: ib62x0: add CONFIG_SYS_GENERIC_BOARD define Signed-off-by: Luka Perkov l...@openwrt.org CC: Prafulla Wadaskar prafu...@marvell.com CC: Stefan Roese s...@denx.de --- I will pull this patch series in this week. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] dm: i2c: Add a uclass for I2C
Hi Simon, On Thu, 27 Nov 2014 21:47:07 -0700 Simon Glass s...@chromium.org wrote: +Masahiro On Nov 24, 2014 11:58 AM, Simon Glass s...@chromium.org wrote: The uclass implements the same operations as the current I2C framework but makes some changes to make it fit driver model better: - Remove the chip address from API calls - Remove the address length from API calls - Remove concept of 'current' I2C bus - Drop all existing init functions Signed-off-by: Simon Glass s...@chromium.org I am reviewing v3 now. Hopefully, I will send some comments in a couple of days. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2015.01-rc2 released
Hello Guillaume, Guillaume Gardet wrote Le 25/11/2014 11:19, Lukasz Majewski a écrit : Hi Guillaume, Le 24/11/2014 23:13, Tom Rini a écrit : Hey all, I've pushed v2015.01-rc2 out to the repository and tarballs should exist soon. I'm tagging later in the day than I wanted to, but that's OK. There's a fair number of things that've gone in since -rc1, but I think that's OK. And there's a few things that still need to go in. For example, I just pushed the changes to allow bigger files to be read but that's broken MIPS+private libgcc and ARM+hf toolchain and others too. I posted a patch for this and tested it locally with a 32MB file but I'd like others to review too (Thanks Simon!) before pushing it in. As always, if anything else is broken please speak up. I guess this the ARM+hf problem you mentioned: LD u-boot ld.bfd: error: /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not ld.bfd: failed to merge target specific data of file /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/libgcc.a(bpabi.o) ld.bfd: error: /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not ld.bfd: failed to merge target specific data of file /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/libgcc.a(_divdi3.o) ld.bfd: error: /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not ld.bfd: failed to merge target specific data of file /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/libgcc.a(_udivdi3.o) I experience the same issue: Working toolchain: /opt/eldk-5.4/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi- Toolchain with errors: /home/DIGITAL/l.majewski/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/arm-linux-gnueabihf- Building smdk2410 board... /home/DIGITAL/l.majewski/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /home/DIGITAL/l.majewski/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not /home/DIGITAL/l.majewski/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /home/DIGITAL/l.majewski/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not /home/DIGITAL/l.majewski/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /home/DIGITAL/l.majewski/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not make: *** [u-boot] Error 1 Is there any pending patch to fix this one? +1 I got it compiling by removing -msoft-float flag: diff --git a/arch/arm/config.mk b/arch/arm/config.mk index c339e6d..cd41e48 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -16,7 +16,7 @@ endif LDFLAGS_FINAL += --gc-sections PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \ -fno-common -ffixed-r9 -PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \ +PLATFORM_RELFLAGS += \ $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) # Support generic board on ARM Is it an acceptable patch? If so, I can send it as a real patch. Guillaume I experimented the same issue while building u-boot for the mx6dlsabresd platform. Your patch doesn't solve the issue. The boot is compiling and linking but raise some hardware exception at runtime while loading files from fat filesystems. The patch http://patchwork.ozlabs.org/patch/415336/ solves the issue for the iMX6. Regards Pierre Aubert -- View this message in context: http://u-boot.10912.n7.nabble.com/ANN-U-Boot-v2015-01-rc2-released-tp197341p197861.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx53loco: Add raw initrd support
On 20/11/2014 08:38, Guillaume GARDET wrote: Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Stefano Babic sba...@denx.de Cc: Jason Liu r64...@freescale.com --- Applied to u-boot-imx, thanks ! 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 2/3] mxs_ocotp: check for errors from the OTP controller after writing
On 21/11/2014 17:54, Hector Palacios wrote:
The write operation may fail when trying to write to a locked area. In
this case the ERROR bit is set in the CTRL register. Check for that
condition and return an error.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/misc/mxs_ocotp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/mxs_ocotp.c b/drivers/misc/mxs_ocotp.c
index 09002814f2f0..1659ee6a5eec 100644
--- a/drivers/misc/mxs_ocotp.c
+++ b/drivers/misc/mxs_ocotp.c
@@ -221,6 +221,13 @@ static int mxs_ocotp_write_fuse(uint32_t addr, uint32_t
mask)
goto fail;
}
+ /* Check for errors */
+ if (readl(ocotp_regs-hw_ocotp_ctrl) OCOTP_CTRL_ERROR) {
+ puts(Failed writing fuses!\n);
+ ret = -EPERM;
+ goto fail;
+ }
+
fail:
mxs_ocotp_scale_vddio(0, vddio_val);
if (mxs_ocotp_scale_hclk(0, hclk_val))
Applied to u-boot-imx, thanks !
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 1/3] mxs_ocotp: prevent error path from returning success
On 21/11/2014 17:54, Hector Palacios wrote:
The code may goto 'fail' upon error with 'ret' variable set to an error
code, but this variable was being overwritten by a final preparation
function to restore the HCLK, so success was (in general) returned even
after an error was hit previously.
With this change, the function may now return success even if the final
preparation function fails, but it's probably enough to print a message
because (if successful) the real programming of the fuses has already
completed.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/misc/mxs_ocotp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/misc/mxs_ocotp.c b/drivers/misc/mxs_ocotp.c
index 545d3ebf520e..09002814f2f0 100644
--- a/drivers/misc/mxs_ocotp.c
+++ b/drivers/misc/mxs_ocotp.c
@@ -223,11 +223,8 @@ static int mxs_ocotp_write_fuse(uint32_t addr, uint32_t
mask)
fail:
mxs_ocotp_scale_vddio(0, vddio_val);
- ret = mxs_ocotp_scale_hclk(0, hclk_val);
- if (ret) {
+ if (mxs_ocotp_scale_hclk(0, hclk_val))
puts(Failed scaling up the HCLK!\n);
- return ret;
- }
return ret;
}
Applied to u-boot-imx, thanks !
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 3/3] mxs_ocotp: clear the error flag before initiating write operation
On 21/11/2014 17:54, Hector Palacios wrote:
A previous operation may have set the error flag, which must be cleared
before a new write operation can be issued.
Signed-off-by: Hector Palacios hector.palac...@digi.com
---
drivers/misc/mxs_ocotp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/mxs_ocotp.c b/drivers/misc/mxs_ocotp.c
index 1659ee6a5eec..6f0a1d3e6da8 100644
--- a/drivers/misc/mxs_ocotp.c
+++ b/drivers/misc/mxs_ocotp.c
@@ -187,6 +187,8 @@ static int mxs_ocotp_write_fuse(uint32_t addr, uint32_t
mask)
uint32_t hclk_val, vddio_val;
int ret;
+ mxs_ocotp_clear_error();
+
/* Make sure the banks are closed for reading. */
ret = mxs_ocotp_read_bank_open(0);
if (ret) {
Applied to u-boot-imx, thanks !
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] thermal: imx_thermal: Do not display calibration data
On 24/11/2014 15:24, Fabio Estevam wrote:
Printing the calibration data on every boot does not provide really useful
information:
U-Boot 2015.01-rc1-18266-ge7eb277 (Nov 24 2014 - 11:29:51)
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
CPU: Thermal calibration data: 0x5d85067d
CPU: Temperature 33 C
Reset cause: POR
Board: MX6-SabreSD
Do not display the calibration data in order to have a cleaner boot log.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/thermal/imx_thermal.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 1161585..0bd9cfd 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -156,8 +156,6 @@ static int imx_thermal_probe(struct udevice *dev)
if (fuse == 0 || fuse == ~0) {
printf(CPU: Thermal invalid data, fuse: 0x%x\n, fuse);
return -EPERM;
- } else {
- printf(CPU: Thermal calibration data: 0x%x\n, fuse);
}
*priv = fuse;
Applied to u-boot-imx, thanks !
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 2/2] mx6sxsabresd: Add thermal support
On 25/11/2014 16:11, Fabio Estevam wrote: Add thermal support so that the temperature of the chip can be displayed on boot: U-Boot 2015.01-rc1-18268-g1366c05-dirty (Nov 25 2014 - 13:02:42) CPU: Freescale i.MX6SX rev1.0 at 792 MHz CPU: Temperature 50 C Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx6sxsabresd.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h index d8ab291..5e0edab 100644 --- a/include/configs/mx6sxsabresd.h +++ b/include/configs/mx6sxsabresd.h @@ -208,6 +208,16 @@ #define CONFIG_PCIE_IMX_POWER_GPIO IMX_GPIO_NR(2, 1) #endif +#define CONFIG_DM +#define CONFIG_DM_THERMAL +#define CONFIG_SYS_MALLOC_F_LEN (1 10) +#define CONFIG_IMX6_THERMAL + +#define CONFIG_CMD_FUSE +#if defined(CONFIG_CMD_FUSE) || defined(CONFIG_IMX6_THERMAL) +#define CONFIG_MXC_OCOTP +#endif + /* FLASH and environment organization */ #define CONFIG_SYS_NO_FLASH Applied to u-boot-imx, thanks ! 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 1/2] mxc_ocotp: Do not disable the OCOTP clock after every access
On 25/11/2014 16:11, Fabio Estevam wrote:
Leave the OCOTP turned on, so that we subsequent access do not fail.
After enabling the thermal driver on a mx6sxsabresd board:
U-Boot 2015.01-rc1-18267-g99d4189-dirty (Nov 24 2014 - 12:59:01)
CPU: Freescale i.MX6SX rev1.0 at 792 MHz
CPU: Temperature 48 C
Reset cause: POR
Board: MX6SX SABRE SDB
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
00:01.0 - 16c3:abcd - Bridge device
01:00.0- 8086:08b1 - Network controller
In:serial
Out: serial
Err: serial
Net:
(hang)
As the thermal driver accesses the ocotp registers, its clock will be disabled
afterwards.
Then when the MAC address is read (also from ocotp registers) it will cause a
hang.
Do not disable the ocotp clock to prevent this problem.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/misc/mxc_ocotp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/misc/mxc_ocotp.c b/drivers/misc/mxc_ocotp.c
index 3de1245..67f9429 100644
--- a/drivers/misc/mxc_ocotp.c
+++ b/drivers/misc/mxc_ocotp.c
@@ -81,8 +81,6 @@ static int finish_access(struct ocotp_regs *regs, const
char *caller)
err = !!(readl(regs-ctrl) BM_CTRL_ERROR);
clear_error(regs);
- enable_ocotp_clk(0);
-
if (err) {
printf(mxc_ocotp %s(): Access protect error\n, caller);
return -EIO;
Applied to u-boot-imx, thanks !
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] tbs2910: fix lost characters on serial input
On 27/11/2014 21:21, Soeren Moch wrote: With enabled console_mux for serial input and usb keyboard sometimes characters get lost when typing too fast at the serial input (pasting strings in serial console window). Fix this by using INT_QUEUE for polling the usb keyboard. Signed-off-by: Soeren Moch sm...@web.de --- Cc: Stefano Babic sba...@denx.de --- include/configs/tbs2910.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/tbs2910.h b/include/configs/tbs2910.h index 6ab2184..c097b98 100644 --- a/include/configs/tbs2910.h +++ b/include/configs/tbs2910.h @@ -167,7 +167,7 @@ #define CONFIG_USB_STORAGE #define CONFIG_USB_KEYBOARD #ifdef CONFIG_USB_KEYBOARD -#define CONFIG_SYS_USB_EVENT_POLL +#define CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE #define CONFIG_SYS_STDIO_DEREGISTER #define CONFIG_PREBOOT if hdmidet; then usb start; fi #endif /* CONFIG_USB_KEYBOARD */ Applied to u-boot-imx, thanks ! 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] tbs2910: fix Kconfig
On 26/11/2014 12:39, Soeren Moch wrote: fix Kconfig for tbs2910 board to prevent crash on relocation Signed-off-by: Soeren Moch sm...@web.de --- Cc: Stefano Babic sba...@denx.de --- arch/arm/Kconfig | 1 + board/tbs/tbs2910/Kconfig | 8 2 files changed, 1 insertion(+), 8 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b9ac59e..be703af 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -650,6 +650,7 @@ config TARGET_KOSAGI_NOVENA config TARGET_TBS2910 bool Support tbs2910 + select CPU_V7 config TARGET_TQMA6 bool TQ Systems TQMa6 board diff --git a/board/tbs/tbs2910/Kconfig b/board/tbs/tbs2910/Kconfig index c514e24..84b243e 100644 --- a/board/tbs/tbs2910/Kconfig +++ b/board/tbs/tbs2910/Kconfig @@ -1,23 +1,15 @@ if TARGET_TBS2910 -config SYS_CPU - string - default armv7 - config SYS_BOARD - string default tbs2910 config SYS_VENDOR - string default tbs config SYS_SOC - string default mx6 config SYS_CONFIG_NAME - string default tbs2910 endif Applied to u-boot-imx, thanks ! 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] sata: fix reset_sata for dwc_ahsata
On 27/11/2014 10:11, Soeren Moch wrote:
- fix crash when sata device is not initialized
- remove disable_sata_clock() since it is not clear which clock for which
device should be disabled here
- call disable_sata_clock() for mx6 in preboot_os instead
Signed-off-by: Soeren Moch sm...@web.de
---
Changes in v2:
- fix type cast warning
Cc: Tom Rini tr...@ti.com
Cc: Nikita Kiryanov nik...@compulab.co.il
Cc: Simon Glass s...@chromium.org
Cc: guillaume.gar...@free.fr
Cc: Fabio Estevam feste...@gmail.com
Cc: Stefano Babic sba...@denx.de
---
arch/arm/imx-common/cpu.c | 3 +++
drivers/block/dwc_ahsata.c | 14 --
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index b58df7d..28ccd29 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -206,6 +206,9 @@ void arch_preboot_os(void)
{
#if defined(CONFIG_CMD_SATA)
sata_stop();
+#if defined(CONFIG_MX6)
+ disable_sata_clock();
+#endif
#endif
#if defined(CONFIG_VIDEO_IPUV3)
/* disable video before launching O/S */
diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index 9a2b547..01a4148 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -594,22 +594,24 @@ int init_sata(int dev)
int reset_sata(int dev)
{
- struct ahci_probe_ent *probe_ent =
- (struct ahci_probe_ent *)sata_dev_desc[dev].priv;
- struct sata_host_regs *host_mmio =
- (struct sata_host_regs *)probe_ent-mmio_base;
+ struct ahci_probe_ent *probe_ent;
+ struct sata_host_regs *host_mmio;
if (dev 0 || dev (CONFIG_SYS_SATA_MAX_DEVICE - 1)) {
printf(The sata index %d is out of ranges\n\r, dev);
return -1;
}
+ probe_ent = (struct ahci_probe_ent *)sata_dev_desc[dev].priv;
+ if (NULL == probe_ent)
+ /* not initialized, so nothing to reset */
+ return 0;
+
+ host_mmio = (struct sata_host_regs *)probe_ent-mmio_base;
setbits_le32(host_mmio-ghc, SATA_HOST_GHC_HR);
while (readl(host_mmio-ghc) SATA_HOST_GHC_HR)
udelay(100);
- disable_sata_clock();
-
return 0;
}
Applied to u-boot-imx, thanks !
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] arm: mx6: Change defines ENET_xxMHz to ENET_xxMHZ (no CamelCase)
On 27/11/2014 13:46, Stefan Roese wrote:
As checkpatch complaines about these camel-case defines, lets change
them to only use upper-case characters.
Signed-off-by: Stefan Roese s...@denx.de
Acked-by: Heiko Schocher h...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Jon Nettleton jon.nettle...@gmail.com
Cc: Stefano Babic sba...@denx.de
---
v2:
- Rebased on current master
arch/arm/cpu/armv7/mx6/clock.c | 2 +-
arch/arm/include/asm/arch-mx6/clock.h | 8
board/aristainetos/aristainetos.c | 2 +-
board/freescale/mx6slevk/mx6slevk.c | 2 +-
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 2 +-
board/solidrun/hummingboard/hummingboard.c | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index ab7ac3d..93a02ad 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -443,7 +443,7 @@ int enable_fec_anatop_clock(enum enet_freq freq)
struct anatop_regs __iomem *anatop =
(struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
- if (freq ENET_25MHz || freq ENET_125MHz)
+ if (freq ENET_25MHZ || freq ENET_125MHZ)
return -EINVAL;
reg = readl(anatop-pll_enet);
diff --git a/arch/arm/include/asm/arch-mx6/clock.h
b/arch/arm/include/asm/arch-mx6/clock.h
index 323805c..226a4cd 100644
--- a/arch/arm/include/asm/arch-mx6/clock.h
+++ b/arch/arm/include/asm/arch-mx6/clock.h
@@ -43,10 +43,10 @@ enum mxc_clock {
};
enum enet_freq {
- ENET_25MHz,
- ENET_50MHz,
- ENET_100MHz,
- ENET_125MHz,
+ ENET_25MHZ,
+ ENET_50MHZ,
+ ENET_100MHZ,
+ ENET_125MHZ,
};
u32 imx_get_uartclk(void);
diff --git a/board/aristainetos/aristainetos.c
b/board/aristainetos/aristainetos.c
index 06922c0..67ac260 100644
--- a/board/aristainetos/aristainetos.c
+++ b/board/aristainetos/aristainetos.c
@@ -301,7 +301,7 @@ int board_eth_init(bd_t *bis)
/* clear gpr1[14], gpr1[18:17] to select anatop clock */
clrsetbits_le32(iomuxc_regs-gpr[1], IOMUX_GPR1_FEC_MASK, 0);
- ret = enable_fec_anatop_clock(ENET_50MHz);
+ ret = enable_fec_anatop_clock(ENET_50MHZ);
if (ret)
return ret;
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index 8111edf..cac6d73 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -234,7 +234,7 @@ static int setup_fec(void)
/* clear gpr1[14], gpr1[18:17] to select anatop clock */
clrsetbits_le32(iomuxc_regs-gpr[1], IOMUX_GPR1_FEC_MASK, 0);
- return enable_fec_anatop_clock(ENET_50MHz);
+ return enable_fec_anatop_clock(ENET_50MHZ);
}
#endif
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 7aee074..8b959b9 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -168,7 +168,7 @@ static int setup_fec(void)
reg |= BM_ANADIG_PLL_ENET_REF_25M_ENABLE;
writel(reg, anatop-pll_enet);
- return enable_fec_anatop_clock(ENET_125MHz);
+ return enable_fec_anatop_clock(ENET_125MHZ);
}
int board_eth_init(bd_t *bis)
diff --git a/board/solidrun/hummingboard/hummingboard.c
b/board/solidrun/hummingboard/hummingboard.c
index 6d204b3..52c384b 100644
--- a/board/solidrun/hummingboard/hummingboard.c
+++ b/board/solidrun/hummingboard/hummingboard.c
@@ -146,7 +146,7 @@ int board_eth_init(bd_t *bis)
{
struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
- int ret = enable_fec_anatop_clock(ENET_25MHz);
+ int ret = enable_fec_anatop_clock(ENET_25MHZ);
if (ret)
return ret;
Applied to u-boot-imx, thanks !
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 1/2] config_fallbacks: Add a default entry for CONFIG_SYS_PBSIZE
On 27/11/2014 23:41, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Entering the maximum number of characters defined by CONFIG_SYS_CBSIZE into the console and hitting enter afterwards, causes a hang in the system because CONFIG_SYS_PBSIZE is not capable of storing the characters of the error message: Unknown command '' - try 'help'. Provide a default size for CONFIG_SYS_PBSIZE so that it can store the error message and allows the error message to be printed correctly with no hang. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/config_fallbacks.h | 4 1 file changed, 4 insertions(+) diff --git a/include/config_fallbacks.h b/include/config_fallbacks.h index 7d8daa2..508db56 100644 --- a/include/config_fallbacks.h +++ b/include/config_fallbacks.h @@ -79,6 +79,10 @@ #define CONFIG_SYS_PROMPT= #endif +#ifndef CONFIG_SYS_PBSIZE +#define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + 128) +#endif + #ifndef CONFIG_FIT_SIGNATURE #define CONFIG_IMAGE_FORMAT_LEGACY #endif Applied to u-boot-imx, thanks ! 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 2/2] mx6sabre_common: Use the default CONFIG_SYS_PBSIZE
On 27/11/2014 23:41, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Entering the maximum number of characters defined by CONFIG_SYS_CBSIZE into the console and hitting enter afterwards, causes a hang in the system because CONFIG_SYS_PBSIZE is not capable of storing the characters of the error message: Unknown command '' - try 'help'. Use the default CONFIG_SYS_PBSIZE definition from config_fallbacks.h to solve this problem. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx6sabre_common.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/configs/mx6sabre_common.h b/include/configs/mx6sabre_common.h index 9fdd841..f0f721e 100644 --- a/include/configs/mx6sabre_common.h +++ b/include/configs/mx6sabre_common.h @@ -220,9 +220,6 @@ #define CONFIG_SYS_PROMPT_HUSH_PS2 #define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_CBSIZE 256 - -/* Print Buffer Size */ -#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) #define CONFIG_SYS_MAXARGS 16 #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE Applied to u-boot-imx, thanks ! 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] arm: vf610: improve evaluation of reset source
On 27/11/2014 23:58, Stefan Agner wrote:
Improve the evaluation of the reset source. Bit description according
to latest reference manual rev. 7.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/cpu/armv7/vf610/generic.c | 21 +++--
arch/arm/include/asm/arch-vf610/imx-regs.h | 8
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/vf610/generic.c
b/arch/arm/cpu/armv7/vf610/generic.c
index a26d63e..92aaad9 100644
--- a/arch/arm/cpu/armv7/vf610/generic.c
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -265,20 +265,21 @@ static char *get_reset_cause(void)
cause = readl(src_regs-srsr);
writel(cause, src_regs-srsr);
- cause = 0xff;
- switch (cause) {
- case 0x08:
- return WDOG;
- case 0x20:
+ if (cause SRC_SRSR_POR_RST)
+ return POWER ON RESET;
+ else if (cause SRC_SRSR_WDOG_A5)
+ return WDOG A5;
+ else if (cause SRC_SRSR_WDOG_M4)
+ return WDOG M4;
+ else if (cause SRC_SRSR_JTAG_RST)
return JTAG HIGH-Z;
- case 0x80:
+ else if (cause SRC_SRSR_SW_RST)
+ return SW RESET;
+ else if (cause SRC_SRSR_RESETB)
return EXTERNAL RESET;
- case 0xfd:
- return POR;
- default:
+ else
return unknown reset;
- }
}
int print_cpuinfo(void)
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index 9d797db..6b10bdf 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -256,6 +256,14 @@
#define DDRMC_CR161_TODTH_RD(v) (((v) 0xf)
8)
#define DDRMC_CR161_TODTH_WR(v) ((v) 0xf)
+/* System Reset Controller (SRC) */
+#define SRC_SRSR_SW_RST (0x1 18)
+#define SRC_SRSR_RESETB (0x1 7)
+#define SRC_SRSR_JTAG_RST(0x1 5)
+#define SRC_SRSR_WDOG_M4 (0x1 4)
+#define SRC_SRSR_WDOG_A5 (0x1 3)
+#define SRC_SRSR_POR_RST (0x1 0)
+
#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
#include asm/types.h
Applied to u-boot-imx, thanks !
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 1/2 v2] Exynos5800: The Peach-Pi board does not have a Parade video bridge
Hey Simon, On Sun, 2014-11-30 at 11:56 -0700, Simon Glass wrote: On 27 November 2014 at 08:08, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the Pi. So drop it from device-tree Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes since v1: Only modify the DTB arch/arm/dts/exynos5800-peach-pi.dts | 5 - 1 file changed, 5 deletions(-) Acked-by: Simon Glass s...@chromium.org Tested on snow, pit, pi (display does not yet work on Pi). Just to be clear, in your testing does the display not work on Pi? It seems to be ok here (with u-boot starting chainloaded from one of the KERN partitions) -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] exynos5420: fix compilation without parade video
Hey Minkyu,
On Mon, 2014-12-01 at 14:24 +0900, Minkyu Kang wrote:
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -42,6 +42,10 @@ void set_system_display_ctrl(void);
int exynos_lcd_early_init(const void *blob);
/* Initialize the Parade dP-LVDS bridge if present */
+#ifdef CONFIG_VIDEO_PARADE
int parade_init(const void *blob);
+#else
+static inline int parade_init(const void *blob) { return -1; }
+#endif
Actually, it does not related with this patch..
and I know that you are not an author.
But.. I'd like ask you, why parade_init function is in exynos header file?
If you are agreed, could you please make new header file? (e.g:
include/parade.h)
I'm not sure why it's in the exynos header file, it being there
surprised me as well. I'm happy to move it around in a next version of
the patch though.
And I think you missed removing the CONFIG_VIDEO_PARADE at peach-pi.h
That's on purpose, in the discussion with Simon Glass it became clear
that the intention is to start minimizing peach-pi.h (and hopefully make
it unnecessary). So i left peach-pi.h untouched for now, in order for a
later patchset to clean up the configuration more.
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] dm: i2c: Add a uclass for I2C
Hi Simon,
My review is still under way,
but I have some comments below:
On Mon, 24 Nov 2014 11:57:15 -0700
Simon Glass s...@chromium.org wrote:
+static bool i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
+ uint8_t offset_buf[], struct i2c_msg *msg)
+{
+ if (!chip-offset_len)
+ return false;
+ msg-addr = chip-chip_addr;
+ msg-flags = chip-flags;
+ msg-len = chip-offset_len;
+ msg-buf = offset_buf;
You directly copy
from (struct dm_i2c_chip *)-flags
to (struct i2c_msg *)-flags.
But you define completely different flags for them:
DM_I2C_CHIP_10BIT is defined as 0x1.
I2C_M_TEN is defined as 0x10.
It would not work.
+
+static int i2c_read_bytewise(struct udevice *dev, uint offset,
+ const uint8_t *buffer, int len)
+{
+ struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+ struct udevice *bus = dev_get_parent(dev);
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct i2c_msg msg[1];
+ uint8_t buf[5];
+ int ret;
+ int i;
+
+ for (i = 0; i len; i++) {
+ i2c_setup_offset(chip, offset, buf, msg);
+ msg-len++;
+ buf[chip-offset_len] = buffer[i];
+
+ ret = ops-xfer(bus, msg, 1);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
I could not understand how this works.
It seems to send only write transactions.
+
+static int i2c_bind_driver(struct udevice *bus, uint chip_addr,
+struct udevice **devp)
+{
+ struct dm_i2c_chip *chip;
+ char name[30], *str;
+ struct udevice *dev;
+ int ret;
+
+ snprintf(name, sizeof(name), generic_%x, chip_addr);
+ str = strdup(name);
+ ret = device_bind_driver(bus, i2c_generic_drv, str, dev);
+ debug(%s: device_bind_driver: ret=%d\n, __func__, ret);
+ if (ret)
+ goto err_bind;
+
+ /* Tell the device what we know about it */
+ chip = calloc(1, sizeof(struct dm_i2c_chip));
+ if (!chip) {
+ ret = -ENOMEM;
+ goto err_mem;
+ }
+ chip-chip_addr = chip_addr;
+ chip-offset_len = 1; /* we assume */
+ ret = device_probe_child(dev, chip);
+ debug(%s: device_probe_child: ret=%d\n, __func__, ret);
+ free(chip);
Why do you need calloc() free() here?
I think you can use the stack area for struct dm_i2c_chip chip;
+
+UCLASS_DRIVER(i2c) = {
+ .id = UCLASS_I2C,
+ .name = i2c,
+ .per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
+ .post_bind = i2c_post_bind,
+ .post_probe = i2c_post_probe,
+};
+
+UCLASS_DRIVER(i2c_generic) = {
+ .id = UCLASS_I2C_GENERIC,
+ .name = i2c_generic,
+};
+
+U_BOOT_DRIVER(i2c_generic_drv) = {
Perhaps isn't i2c_generic_chip clearer than i2c_generic_drv?
+ .name = i2c_generic_drv,
+ .id = UCLASS_I2C_GENERIC,
+};
Can we move i2c_generic to a different file?
maybe, drivers/i2c/i2c-generic.c or drivers/i2c/i2c-generic-chip.c ?
UCLASS_DRIVER(i2c) is a bus, whereas UCLASS_DRIVER(i2c_generic) is a chip.
Mixing up a bus and a chip-device together in the same file
looks confusing to me.
/*
+ * For now there are essentially two parts to this file - driver model
+ * here at the top, and the older code below (with CONFIG_SYS_I2C being
+ * most recent). The plan is to migrate everything to driver model.
+ * The driver model structures and API are separate as they are different
+ * enough as to be incompatible for compilation purposes.
+ */
+
+#ifdef CONFIG_DM_I2C
+
+enum dm_i2c_chip_flags {
+ DM_I2C_CHIP_10BIT = 1 0, /* Use 10-bit addressing */
+ DM_I2C_CHIP_RE_ADDRESS = 1 1, /* Send address for every byte */
+};
As I mentioned above, you define DM_I2C_CHIP_10BIT as 0x1
whereas you define I2C_M_TEN as 0x0010.
These flags should be shared with struct i2c_msg.
+/*
+ * Not all of these flags are implemented in the U-Boot API
+ */
+enum dm_i2c_msg_flags {
+ I2C_M_TEN = 0x0010, /* ten-bit chip address */
+ I2C_M_RD= 0x0001, /* read data, from slave to master */
+ I2C_M_STOP = 0x8000, /* send stop after this message */
+ I2C_M_NOSTART = 0x4000, /* no start before this message */
+ I2C_M_REV_DIR_ADDR = 0x2000, /* invert polarity of R/W bit */
+ I2C_M_IGNORE_NAK= 0x1000, /* continue after NAK */
+ I2C_M_NO_RD_ACK = 0x0800, /* skip the Ack bit on reads */
+ I2C_M_RECV_LEN = 0x0400, /* length is first received byte */
+};
I think this enum usage is odd.
If you want to allocate specific values such as 0x8000, 0x4000, etc.
you should use #define instead of enum.
If you do not care which value is assigned, you can use enum.
arch/arm/include/asm/spl.h is a good
Re: [U-Boot] [PATCH v3 08/10] dm: Add a simple EEPROM driver
Hi Simon,
On Mon, 24 Nov 2014 11:57:22 -0700
Simon Glass s...@chromium.org wrote:
--- /dev/null
+++ b/drivers/misc/i2c_eeprom.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include i2c.h
+#include i2c_eeprom.h
+
+static int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf,
+int size)
+{
+ return -ENODEV;
+}
+
+static int i2c_eeprom_write(struct udevice *dev, int offset,
+ const uint8_t *buf, int size)
+{
+ return -ENODEV;
+}
Isn't there any possibility to reach i2c_eeprom_read/i2c_eeprom_write
handler?
Maybe, is it better to fallback to i2c_read()/i2c_write() like this?
static int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf,
int size)
{
return i2c_read(dev, offset, buf, size);
}
static int i2c_eeprom_write(struct udevice *dev, int offset, const uint8_t *buf,
int size)
{
return i2c_write(dev, offset, buf, size);
}
Moreover, can we read data from EEPROM
without knowing if its parent is I2C bus or SPI bus ?
My rough image is like this:
int eeprom_read(struct udevice *dev, int offset, uint8_t buf, int size)
{
struct udevice *bus = dev-parent;
struct generic_bus_operation *ops = bus-uclass-uc_drv-ops;
return ops-read(dev, bus, offset, buf, size);
}
I am not sure, but if this approach is possible,
we do not need to have both of i2c_eeprom uclass and spi_eeprom uclass.
struct generic_bus_operation is the operaton some uclasses have.
We can move i2c_read() and i2c_write()
to struct generic_bus_operation of i2c uclass.
Likewise, we can move spi_read() and spi_write()
to struct generic_bus_operation of spi uclass.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/10] dm: i2c: tegra: Convert to driver model
Hi Simon,
On Mon, 24 Nov 2014 11:57:24 -0700
Simon Glass s...@chromium.org wrote:
+
+U_BOOT_DRIVER(i2c_tegra) = {
+ .name = i2c_tegra,
+ .id = UCLASS_I2C,
+ .of_match = tegra_i2c_ids,
+ .ofdata_to_platdata = tegra_i2c_ofdata_to_platdata,
+ .probe = tegra_i2c_probe,
+ .per_child_auto_alloc_size = sizeof(struct dm_i2c_chip),
I guess every i2c driver is supposed to have
.per_child_auto_alloc_size = sizeof(struct dm_i2c_chip),
but it it unfortunate.
Can we have it in uclass too?
If U_BOOT_DRIVER does not have .per_child_auto_alloc_size
but UCLASS_DRIVER has it, use it.
If both U_BOOT_DRIVER and UCLASS_DRIVER have .per_child_auto_alloc_size,
the former takes precedence.
+ .child_pre_probe = tegra_i2c_child_pre_probe,
Ditto.
tegra_i2c_child_pre_probe() does not seem Tegra-specific code at all.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Odroid XU3 support additions
Hey Hyungwon, The following are some of the patches i had locally on top of your v9 Odroid. Feel free to merge them into your patchset (or squash them into your existing patches) if they look good to you. Sjoerd Simons (4): Odroid-XU3: Drop redundant fields Odroid-XU3: Add entry for DTS EHCI GPIO ODROID-XU3: Make odroid-xu3 an smdk5420 variant ODROID-XU3: drop overriding the boot environment arch/arm/cpu/armv7/exynos/Kconfig | 1 - arch/arm/dts/exynos5422-odroidxu3.dts | 16 ++--- board/samsung/odroid-xu3/Kconfig | 12 board/samsung/odroid-xu3/MAINTAINERS | 6 -- board/samsung/odroid-xu3/Makefile | 7 -- board/samsung/odroid-xu3/odroid-xu3.c | 122 -- board/samsung/odroid-xu3/setup.h | 95 -- board/samsung/smdk5420/Kconfig| 13 include/configs/odroid_xu3.h | 72 9 files changed, 17 insertions(+), 327 deletions(-) delete mode 100644 board/samsung/odroid-xu3/Kconfig delete mode 100644 board/samsung/odroid-xu3/MAINTAINERS delete mode 100644 board/samsung/odroid-xu3/Makefile delete mode 100644 board/samsung/odroid-xu3/odroid-xu3.c delete mode 100644 board/samsung/odroid-xu3/setup.h -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ODROID-XU3: Make odroid-xu3 an smdk5420 variant
The odroid-xu3 board file sets up clocks that should have are setup by
the SPL/BL2, so that code should be redundant. Drop it and make the XU3
an smdk5420 variant like e.g. Peach pit/pi, that way the only
differences in the boards u-boot binary are purely due to configuration
changes, not code differences.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/cpu/armv7/exynos/Kconfig | 1 -
board/samsung/odroid-xu3/Kconfig | 12
board/samsung/odroid-xu3/MAINTAINERS | 6 --
board/samsung/odroid-xu3/Makefile | 7 --
board/samsung/odroid-xu3/odroid-xu3.c | 122 --
board/samsung/odroid-xu3/setup.h | 95 --
board/samsung/smdk5420/Kconfig| 13
7 files changed, 13 insertions(+), 243 deletions(-)
delete mode 100644 board/samsung/odroid-xu3/Kconfig
delete mode 100644 board/samsung/odroid-xu3/MAINTAINERS
delete mode 100644 board/samsung/odroid-xu3/Makefile
delete mode 100644 board/samsung/odroid-xu3/odroid-xu3.c
delete mode 100644 board/samsung/odroid-xu3/setup.h
diff --git a/arch/arm/cpu/armv7/exynos/Kconfig
b/arch/arm/cpu/armv7/exynos/Kconfig
index 16c9a0e..88017c7 100644
--- a/arch/arm/cpu/armv7/exynos/Kconfig
+++ b/arch/arm/cpu/armv7/exynos/Kconfig
@@ -69,7 +69,6 @@ source board/samsung/universal_c210/Kconfig
source board/samsung/origen/Kconfig
source board/samsung/trats2/Kconfig
source board/samsung/odroid/Kconfig
-source board/samsung/odroid-xu3/Kconfig
source board/samsung/arndale/Kconfig
source board/samsung/smdk5250/Kconfig
source board/samsung/smdk5420/Kconfig
diff --git a/board/samsung/odroid-xu3/Kconfig b/board/samsung/odroid-xu3/Kconfig
deleted file mode 100644
index 6159692..000
--- a/board/samsung/odroid-xu3/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-if TARGET_ODROID_XU3
-
-config SYS_BOARD
- default odroid-xu3
-
-config SYS_VENDOR
- default samsung
-
-config SYS_CONFIG_NAME
- default odroid_xu3
-
-endif
diff --git a/board/samsung/odroid-xu3/MAINTAINERS
b/board/samsung/odroid-xu3/MAINTAINERS
deleted file mode 100644
index 50cf928..000
--- a/board/samsung/odroid-xu3/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-ODROID-XU3 BOARD
-M: Hyungwon Hwang human.hw...@samsung.com
-S: Maintained
-F: board/samsung/odroid-xu3/
-F: include/configs/odroid_xu3.h
-F: configs/odroid-xu3_defconfig
diff --git a/board/samsung/odroid-xu3/Makefile
b/board/samsung/odroid-xu3/Makefile
deleted file mode 100644
index 85ae5c5..000
--- a/board/samsung/odroid-xu3/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-#
-# Copyright (c) 2014 Samsung Electronics Co., Ltd. All rights reserved.
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y := odroid-xu3.o
diff --git a/board/samsung/odroid-xu3/odroid-xu3.c
b/board/samsung/odroid-xu3/odroid-xu3.c
deleted file mode 100644
index 8c54842..000
--- a/board/samsung/odroid-xu3/odroid-xu3.c
+++ /dev/null
@@ -1,122 +0,0 @@
-/*
- * Copyright (C) 2014 Samsung Electronics
- * Hyungwon Hwang human.hw...@samsung.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include asm/arch/clock.h
-#include setup.h
-
-DECLARE_GLOBAL_DATA_PTR;
-
-unsigned int get_board_rev(void)
-{
- return 0;
-}
-
-int exynos_init(void)
-{
- return 0;
-}
-
-#ifdef CONFIG_BOARD_EARLY_INIT_F
-static int board_clock_init(void)
-{
- unsigned int set, clr, clr_src_cpu, clr_pll_con0;
- struct exynos5420_clock *clk = (struct exynos5420_clock *)
- samsung_get_base_clock();
- /*
-* CMU_CPU clocks src to MPLL
-* Bit values: 0 ; 1
-* MUX_APLL_SEL:FIN_PLL ; FOUT_APLL
-* MUX_CORE_SEL:MOUT_APLL ; SCLK_MPLL
-* MUX_HPM_SEL: MOUT_APLL ; SCLK_MPLL_USER_C
-* MUX_MPLL_USER_SEL_C: FIN_PLL ; SCLK_MPLL
- */
-
- /* Set CMU_CPU clocks src to OSCCLK */
- clr_src_cpu = MUX_APLL_SEL(1) | MUX_CORE_SEL(1);
- set = MUX_APLL_SEL(0) | MUX_CORE_SEL(1);
-
- clrsetbits_le32(clk-src_cpu, clr_src_cpu, set);
-
- while (MUX_STAT_CPU_CHANGING(readl(clk-mux_stat_cpu)))
- continue;
-
- /* Set APLL to 1200MHz */
- clr_pll_con0 = SDIV(7) | PDIV(63) | MDIV(1023) | FSEL(1) |
- PLL_ENABLE(1);
- set = SDIV(0) | PDIV(2) | MDIV(100) | PLL_ENABLE(1);
-
- clrsetbits_le32(clk-apll_con0, clr_pll_con0, set);
-
- while (!(readl(clk-apll_con0) PLL_LOCKED_BIT))
- continue;
-
- /* Set CMU_CPU clocks src to APLL */
- set = MUX_APLL_SEL(1) | MUX_CORE_SEL(0);
- clrsetbits_le32(clk-src_cpu, clr_src_cpu, set);
-
- while (MUX_STAT_CPU_CHANGING(readl(clk-mux_stat_cpu)))
- continue;
-
- clr = ARM_RATIO(7) | CPUD_RATIO(7) | ATB_RATIO(7) |
- PCLK_DBG_RATIO(7) | APLL_RATIO(7) | ARM2_RATIO(7);
- set = ARM_RATIO(0) | CPUD_RATIO(2) | ATB_RATIO(5) |
-
[U-Boot] [PATCH 1/4] Odroid-XU3: Drop redundant fields
Drop MMC related fields from the DTS that are already setup by
exynos54xx.dtsi and correct the value of fifoth_val
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/dts/exynos5422-odroidxu3.dts | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
index 533d88e..bd88450 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -36,22 +36,11 @@
};
mmc@1220 {
- samsung,bus-width = 8;
- samsung,timing = 1 3 3;
- fifoth_val = 0x200f0020;
- };
-
- mmc@1221 {
- status = disabled;
+ fifoth_val = 0x201f0020;
};
mmc@1222 {
- samsung,bus-width = 4;
- samsung,timing = 1 2 3;
- fifoth_val = 0x200f0020;
+ fifoth_val = 0x201f0020;
};
- mmc@1223 {
- status = disabled;
- };
};
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] Odroid-XU3: Add entry for DTS EHCI GPIO
Add samsung,vbus-gpio information for the XU3. This allows the usage of
the EHCI controller on the XU3, which is connected to the SMSC LAN9514
chip (usb hub + network).
Note that this patch doesn't enable support for USB/USB networking in
the default config as makes the u-boot binary too big for the current odroid
setup.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
arch/arm/dts/exynos5422-odroidxu3.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
index bd88450..1cbb835 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -43,4 +43,7 @@
fifoth_val = 0x201f0020;
};
+ ehci@1211 {
+ samsung,vbus-gpio = gpio 0x316 0; /* X26 */
+ };
};
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] ODROID-XU3: drop overriding the boot environment
Remove the override of the boot environment, this causes the board to
use the distro_bootcmd setup for booting as included by exynos5-common.h.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
include/configs/odroid_xu3.h | 72
1 file changed, 72 deletions(-)
diff --git a/include/configs/odroid_xu3.h b/include/configs/odroid_xu3.h
index 1d53653..a60d4e5 100644
--- a/include/configs/odroid_xu3.h
+++ b/include/configs/odroid_xu3.h
@@ -45,80 +45,8 @@
#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100)
-#define CONFIG_BOOTCOMMAND run autoboot
#define CONFIG_DEFAULT_CONSOLE console=ttySAC2,115200n8\0
-/*
- * For details, refer the documentation: doc/README.odroid
-*/
-#ifdef CONFIG_EXTRA_ENV_SETTINGS
-#undef CONFIG_EXTRA_ENV_SETTINGS
-#endif
-#define CONFIG_EXTRA_ENV_SETTINGS \
- loadkernel=fatload mmc ${mmcbootdev}:${mmcbootpart} ${kerneladdr} \
- ${kernelname}\0 \
- loadinitrd=fatload mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr} \
- ${initrdname}\0 \
- loaddtb=fatload mmc ${mmcbootdev}:${mmcbootpart} ${fdtaddr} \
- ${fdtfile}\0 \
- check_ramdisk= \
- if run loadinitrd; then \
- setenv initrd_addr ${initrdaddr}; \
- else \
- setenv initrd_addr -; \
- fi;\0 \
- check_dtb= \
- if run loaddtb; then \
- setenv fdt_addr ${fdtaddr}; \
- else \
- setenv fdt_addr; \
- fi;\0 \
- kernel_args= \
- setenv bootargs root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} \
-rootwait ${console} ${opts}\0 \
- boot_fit= \
- setenv kerneladdr 0x4200; \
- setenv kernelname Image.itb; \
- run loadkernel; \
- run kernel_args; \
- bootm ${kerneladdr}#${boardname}\0 \
- boot_uimg= \
- setenv kerneladdr 0x40007FC0; \
- setenv kernelname uImage; \
- run check_dtb; \
- run check_ramdisk; \
- run loadkernel; \
- run kernel_args; \
- bootm ${kerneladdr} ${initrd_addr} ${fdt_addr};\0 \
- boot_zimg= \
- setenv kerneladdr 0x40007FC0; \
- setenv kernelname zImage; \
- run check_dtb; \
- run check_ramdisk; \
- run loadkernel; \
- run kernel_args; \
- bootz ${kerneladdr} ${initrd_addr} ${fdt_addr};\0 \
- autoboot= \
- if test -e mmc 0 Image.itb; then; \
- run boot_fit; \
- elif test -e mmc 0 zImage; then; \
- run boot_zimg; \
- elif test -e mmc 0 uImage; then; \
- run boot_uimg; \
- fi;\0 \
- console= CONFIG_DEFAULT_CONSOLE \
- mmcbootdev=0\0 \
- mmcbootpart=1\0 \
- mmcrootdev=0\0 \
- mmcrootpart=2\0 \
- bootdelay=0\0 \
- dfu_alt_info=Please reset the board\0 \
- consoleon=set console console=ttySAC2,115200n8; save; reset\0 \
- consoleoff=set console console=ram; save; reset\0 \
- initrdname=uInitrd\0 \
- initrdaddr=4200\0 \
- fdtaddr=4080\0
-
/* FIXME: MUST BE REMOVED AFTER TMU IS TURNED ON */
#undef CONFIG_EXYNOS_TMU
#undef CONFIG_TMU_CMD_DTT
--
2.1.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fdt: Fix regression in fdt_pack_reg()
On 28.11.2014 14:23, Hans de Goede wrote: After commit 933cdbb479: fdt: Try to use fdt_address_cells()/fdt_size_cells() I noticed that allwinner boards would no longer boot. Switching to fdt_address_cells / fdt_size_cells changes the result from bytes to 32 bit words, so when we increment pointers into the blob, we must do so by 32 bit words now. This commit makes allwinner boards boot again. Signed-off-by: Hans de Goede hdego...@redhat.com Even if I'm a bit late with this answer, this fixes a regression on Linux booting on one of my mx6 boards. So: Tested-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] mmc: Fix recognition and selection of Dual Data Rate mode
This set of commits fixes some problems and drawbacks in current implementation of MMC Dual Data Rate mode support. These changes were tested not with dw_mmc driver, but with DDR mode support implementation for fsl_esdhc driver, ported from Freescale's 2009.08 based version and not yet submitted to the community. Andrew Gabbasov (4): mmc: Fix handling of bus widths and DDR card capabilities mmc: Fix Dual Data Rate capability recognition mmc: Fix block length for DDR mode mmc: dw_mmc: Use active DDR mode flag common/cmd_mmc.c | 3 ++- drivers/mmc/dw_mmc.c | 2 +- drivers/mmc/mmc.c| 60 +--- include/mmc.h| 1 + 4 files changed, 42 insertions(+), 24 deletions(-) -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] mmc: Fix handling of bus widths and DDR card capabilities
If the MMC_MODE_DDR_52MHz flag is set in card capabilities bitmask,
it is never cleared, even if switching to DDR mode fails, and if
the controller driver uses this flag to check the DDR mode, it can
take incorrect actions.
Also, DDR related checks in mmc_startup() incorrectly handle the case
when the host controller does not support some bus widths (e.g. can't
support 8 bits), since the host_caps is checked for DDR bit, but not
bus width bits.
This fix clearly separates using of card_caps bitmask, having there
the flags for the capabilities, that the card can support, and actual
operation mode, described outside of card_caps (i.e. bus_width and
ddr_mode fields in mmc structure). Separate host controller drivers
may need to be updated to use the actual flags. Respectively,
the capabilities checks in mmc_startup are made more correct and clear.
Also, some clean up is made with errors handling and code syntax layout.
Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
common/cmd_mmc.c | 3 ++-
drivers/mmc/mmc.c | 52 +++-
include/mmc.h | 1 +
3 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 4286e26..96478e4 100644
--- a/common/cmd_mmc.c
+++ b/common/cmd_mmc.c
@@ -90,7 +90,8 @@ static void print_mmcinfo(struct mmc *mmc)
puts(Capacity: );
print_size(mmc-capacity, \n);
- printf(Bus Width: %d-bit\n, mmc-bus_width);
+ printf(Bus Width: %d-bit%s\n, mmc-bus_width,
+ mmc-ddr_mode ? DDR : );
}
static struct mmc *init_mmc_device(int dev, bool force_init)
{
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 44a4feb..4603a81 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -159,7 +159,7 @@ int mmc_set_blocklen(struct mmc *mmc, int len)
{
struct mmc_cmd cmd;
- if (mmc-card_caps MMC_MODE_DDR_52MHz)
+ if (mmc-ddr_mode)
return 0;
cmd.cmdidx = MMC_CMD_SET_BLOCKLEN;
@@ -486,7 +486,7 @@ static int mmc_change_freq(struct mmc *mmc)
char cardtype;
int err;
- mmc-card_caps = 0;
+ mmc-card_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
if (mmc_host_is_spi(mmc))
return 0;
@@ -1103,8 +1103,10 @@ static int mmc_startup(struct mmc *mmc)
/* An array to map CSD bus widths to host cap bits */
static unsigned ext_to_hostcaps[] = {
- [EXT_CSD_DDR_BUS_WIDTH_4] = MMC_MODE_DDR_52MHz,
- [EXT_CSD_DDR_BUS_WIDTH_8] = MMC_MODE_DDR_52MHz,
+ [EXT_CSD_DDR_BUS_WIDTH_4] =
+ MMC_MODE_DDR_52MHz | MMC_MODE_4BIT,
+ [EXT_CSD_DDR_BUS_WIDTH_8] =
+ MMC_MODE_DDR_52MHz | MMC_MODE_8BIT,
[EXT_CSD_BUS_WIDTH_4] = MMC_MODE_4BIT,
[EXT_CSD_BUS_WIDTH_8] = MMC_MODE_8BIT,
};
@@ -1116,13 +1118,13 @@ static int mmc_startup(struct mmc *mmc)
for (idx=0; idx ARRAY_SIZE(ext_csd_bits); idx++) {
unsigned int extw = ext_csd_bits[idx];
+ unsigned int caps = ext_to_hostcaps[extw];
/*
-* Check to make sure the controller supports
-* this bus width, if it's more than 1
+* Check to make sure the card and controller support
+* these capabilities
*/
- if (extw != EXT_CSD_BUS_WIDTH_1
- !(mmc-cfg-host_caps
ext_to_hostcaps[extw]))
+ if ((mmc-card_caps caps) != caps)
continue;
err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
@@ -1131,26 +1133,33 @@ static int mmc_startup(struct mmc *mmc)
if (err)
continue;
+ mmc-ddr_mode = (caps MMC_MODE_DDR_52MHz) ? 1 : 0;
mmc_set_bus_width(mmc, widths[idx]);
err = mmc_send_ext_csd(mmc, test_csd);
+
+ if (err)
+ continue;
+
/* Only compare read only fields */
- if (!err ext_csd[EXT_CSD_PARTITIONING_SUPPORT] \
- == test_csd[EXT_CSD_PARTITIONING_SUPPORT]
- ext_csd[EXT_CSD_HC_WP_GRP_SIZE] \
- == test_csd[EXT_CSD_HC_WP_GRP_SIZE] \
- ext_csd[EXT_CSD_REV] \
- == test_csd[EXT_CSD_REV]
- ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] \
- == test_csd[EXT_CSD_HC_ERASE_GRP_SIZE]
- memcmp(ext_csd[EXT_CSD_SEC_CNT], \
-
[U-Boot] [PATCH 2/4] mmc: Fix Dual Data Rate capability recognition
Since the driver doesn't work in 1.2V or 1.8V signaling level modes,
Dual Data Rate mode can be supported by the driver only if it is supported
by the card in regular 3.3V mode. So, check for a particular single
bit in card type field.
Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
drivers/mmc/mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 4603a81..d878c1e 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -519,7 +519,7 @@ static int mmc_change_freq(struct mmc *mmc)
/* High Speed is set, there are two types: 52MHz and 26MHz */
if (cardtype EXT_CSD_CARD_TYPE_52) {
- if (cardtype EXT_CSD_CARD_TYPE_DDR_52)
+ if (cardtype EXT_CSD_CARD_TYPE_DDR_1_8V)
mmc-card_caps |= MMC_MODE_DDR_52MHz;
mmc-card_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
} else {
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] mmc: dw_mmc: Use active DDR mode flag
The card_caps bit should denote the card capability to use DDR mode, but we need the flag indicating that the DDR mode is active. Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com --- drivers/mmc/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index 785eed5..b18c75d 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -318,7 +318,7 @@ static void dwmci_set_ios(struct mmc *mmc) dwmci_writel(host, DWMCI_CTYPE, ctype); regs = dwmci_readl(host, DWMCI_UHS_REG); - if (mmc-card_caps MMC_MODE_DDR_52MHz) + if (mmc-ddr_mode) regs |= DWMCI_DDR_MODE; else regs = DWMCI_DDR_MODE; -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] mmc: Fix block length for DDR mode
Block length for write and read commands is fixed to 512 bytes
when the card is in Dual Data Rate mode. If block length read from CSD
is different, make sure the driver will use correct length
in all further calculations and settings.
Signed-off-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
drivers/mmc/mmc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d878c1e..9918597 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1170,6 +1170,12 @@ static int mmc_startup(struct mmc *mmc)
mmc_set_clock(mmc, mmc-tran_speed);
+ /* Fix the block length for DDR mode */
+ if (mmc-ddr_mode) {
+ mmc-read_bl_len = MMC_MAX_BLOCK_LEN;
+ mmc-write_bl_len = MMC_MAX_BLOCK_LEN;
+ }
+
/* fill in device description */
mmc-block_dev.lun = 0;
mmc-block_dev.type = 0;
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB External Hub detection problem
Hi All, In EHCI Controller, external USB Hub is connected. We have 2 boards of same type. In Board1, external USB hub is detected properly and in board2, it is not detected properly. In board2, got the error as: usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 101 Change 1 port 1 connection change usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 101, change 1, 12 Mb/s usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 hub_port_reset: resetting port 0... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 Port Status Reg: 1801 reg=180B In port reset error code After Reset, Port Status: 180B USB Status: 8C usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 101, change 13, 12 Mb/s STAT_C_CONNECTION = 1 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 Here, the device is not enabled and connection status change bit is set and the register is port status and control registers. This status is after the port feature reset. In board1,the working log as: usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 101 Change 1 port 1 connection change usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 101, change 1, 12 Mb/s usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 hub_port_reset: resetting port 0... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 Port Status Reg: 1801 reg=8001205 In port reset error code After Reset, Port Status: 8001205 USB Status: 8C usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 503, change 10, 480 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 The U-Boot version is: U-Boot 2011.12 and the external Hub is: USB2514B-AEZC. Whether need to introduce the delay is some place or it is due to some other problem? How it works in one board and not works in another board. Please share the suggestions. -Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fdt: Fix regression in fdt_pack_reg()
Hi, On 11/28/2014 09:23 PM, Hans de Goede wrote: After commit 933cdbb479: fdt: Try to use fdt_address_cells()/fdt_size_cells() I noticed that allwinner boards would no longer boot. Switching to fdt_address_cells / fdt_size_cells changes the result from bytes to 32 bit words, so when we increment pointers into the blob, we must do so by 32 bit words now. This commit makes allwinner boards boot again. Signed-off-by: Hans de Goede hdego...@redhat.com --- Changes in v2: -Improved patch subject -s/_len/_cells/ to indicated that adress_cells and size_cells are in cells now --- I just hit this problem on jetson tk1 and tried the same fix. So Tested-by: Vince Hsu vin...@nvidia.com Thanks, Vince --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fdt.git
Hi Tom, On 29 November 2014 at 21:05, Simon Glass s...@chromium.org wrote: Hi Tom, This request includes an important fix. Please ignore this one - there are a few more test credits so I will re-issue. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-fdt.git (take 2)
Hi Tom, I just pulled this down from patchwork again, adding two more Tested-by: credits. The following changes since commit 85bafb6da4dddfffa78479aa49a72ae48578a4ce: Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq (2014-11-26 11:23:26 -0500) are available in the git repository at: git://git.denx.de/u-boot-fdt.git for you to fetch changes up to ffccb84c1a8e276fa7263ec4ca8186f06312305c: fdt: Fix regression in fdt_pack_reg() (2014-12-01 08:23:32 -0700) Hans de Goede (1): fdt: Fix regression in fdt_pack_reg() Masahiro Yamada (1): fdt: remove fdtdec_get_alias_node() function common/fdt_support.c | 12 ++-- drivers/serial/serial-uclass.c | 2 +- include/fdtdec.h | 11 --- lib/fdtdec.c | 15 --- 4 files changed, 7 insertions(+), 33 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods
Hi,
Tested on an iMX6 SabreSD board. Issue is fixed. There's just a warning
about trailing whitespaces at line 75 of the patch.
Tested-by: Pierre Aubert p.aub...@staubli.com
Thanks
Pierre
Tom Rini wrote
The changes to introduce loff_t into filesize means that we need to do
64bit math on 32bit platforms. Make sure we use the right wrappers for
these operations.
Cc: Daniel Schwierzeck lt;
daniel.schwierzeck@
gt;
Cc: Suriyan Ramasami lt;
suriyan.r@
gt;
Cc: Simon Glass lt;
sjg@
gt;
Signed-off-by: Tom Rini lt;
trini@
gt;
---
Changes in v3:
- Fix bug Simon pointed out in fs/fs.c
Changes in v2:
- Correct fs/fat/fat_write.c
---
fs/ext4/ext4fs.c | 11 ++-
fs/fat/fat_write.c | 10 ++
fs/fs.c|6 --
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 943b5bc..258b9379 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -25,6 +25,7 @@
#include
ext_common.h
#include
ext4fs.h
#include ext4_common.h
+#include
div64.h
int ext4fs_symlinknest;
struct ext_filesystem ext_fs;
@@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t
pos,
if (len filesize)
len = filesize;
- blockcnt = ((len + pos) + blocksize - 1) / blocksize;
+ blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);
- for (i = pos / blocksize; i blockcnt; i++) {
+ for (i = lldiv(pos, blocksize); i blockcnt; i++) {
lbaint_t blknr;
- int blockoff = pos % blocksize;
+ int blockoff = pos - (blocksize * i);
int blockend = blocksize;
int skipfirst = 0;
blknr = read_allocated_block((node-inode), i);
@@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t
pos,
/* Last block. */
if (i == blockcnt - 1) {
- blockend = (len + pos) % blocksize;
+ blockend = (len + pos) - (blocksize * i);
/* The last portion is exactly blocksize. */
if (!blockend)
@@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t
pos,
}
/* First block. */
- if (i == pos / blocksize) {
+ if (i == lldiv(pos, blocksize)) {
skipfirst = blockoff;
blockend -= skipfirst;
}
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 88dd495..473723b 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -13,6 +13,8 @@
#include lt;asm/byteorder.hgt;
#include
part.h
#include lt;linux/ctype.hgt;
+#include
div64.h
+#include lt;linux/math64.hgt;
#include fat.c
static void uppercase(char *str, int len)
@@ -770,7 +772,7 @@ static void fill_dentry(fsdata *mydata, dir_entry
*dentptr,
*/
static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
{
- __u32 startsect, sect_num;
+ __u32 startsect, sect_num, offset;
if (clustnum 0) {
startsect = mydata-data_begin +
@@ -779,13 +781,13 @@ static int check_overflow(fsdata *mydata, __u32
clustnum, loff_t size)
startsect = mydata-rootdir_sect;
}
- sect_num = size / mydata-sect_size;
- if (size % mydata-sect_size)
+ sect_num = div_u64_rem(size, mydata-sect_size, offset);
+
+ if (offset != 0)
sect_num++;
if (startsect + sect_num cur_part_info.start + total_sector)
return -1;
-
return 0;
}
diff --git a/fs/fs.c b/fs/fs.c
index 3da7860..ddd751c 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -23,6 +23,8 @@
#include
fs.h
#include
sandboxfs.h
#include lt;asm/io.hgt;
+#include
div64.h
+#include lt;linux/math64.hgt;
DECLARE_GLOBAL_DATA_PTR;
@@ -399,7 +401,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[],
printf(%llu bytes read in %lu ms, len_read, time);
if (time 0) {
puts( ();
- print_size(len_read / time * 1000, /s);
+ print_size(div_u64(len_read, time) * 1000, /s);
puts());
}
puts(\n);
@@ -469,7 +471,7 @@ int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[],
printf(%llu bytes written in %lu ms, len, time);
if (time 0) {
puts( ();
- print_size(len / time * 1000, /s);
+ print_size(div_u64(len, time) * 1000, /s);
puts());
}
puts(\n);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@.denx
http://lists.denx.de/mailman/listinfo/u-boot
--
View this message in context:
http://u-boot.10912.n7.nabble.com/PATCH-v3-fs-ext4-ext4fs-c-fs-fs-c-fs-fat-fat-write-c-Adjust-64bit-math-methods-tp197647p197896.html
Sent from the
Re: [U-Boot] [PATCH 2/2 v2] exynos5420: fix compilation without parade video
Hi,
On 1 December 2014 at 03:06, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
Hey Minkyu,
On Mon, 2014-12-01 at 14:24 +0900, Minkyu Kang wrote:
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -42,6 +42,10 @@ void set_system_display_ctrl(void);
int exynos_lcd_early_init(const void *blob);
/* Initialize the Parade dP-LVDS bridge if present */
+#ifdef CONFIG_VIDEO_PARADE
int parade_init(const void *blob);
+#else
+static inline int parade_init(const void *blob) { return -1; }
+#endif
Actually, it does not related with this patch..
and I know that you are not an author.
But.. I'd like ask you, why parade_init function is in exynos header file?
If you are agreed, could you please make new header file? (e.g:
include/parade.h)
I'm not sure why it's in the exynos header file, it being there
surprised me as well. I'm happy to move it around in a next version of
the patch though.
And I think you missed removing the CONFIG_VIDEO_PARADE at peach-pi.h
That's on purpose, in the discussion with Simon Glass it became clear
that the intention is to start minimizing peach-pi.h (and hopefully make
it unnecessary). So i left peach-pi.h untouched for now, in order for a
later patchset to clean up the configuration more.
I'll take a look at this next week. Particularly for Pit and Pi we
should be able to use the same config (SDRAM is the only barrier).
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING Could not get liodn of node /pcie@ffe240000: FDT_ERR_NOTFOUND
On 11/26/2014 04:34 AM, Laurentiu Tudor wrote: Hi Jocke, York, Sorry for the late reply. I didn't noticed the thread in time. You need this patch: https://patchwork.ozlabs.org/patch/411910/ Great, I guess this will hit upstream any day now? I'm thinking York will pick it up in one of the following pull requests. I am merging patches in the order of date received. We will get there eventually. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 1/2] Odroid-XU3: Add support for Odroid-XU3
Hi,
On 27 November 2014 at 06:21, Hyungwon Hwang human.hw...@samsung.com wrote:
This patch adds support for Odroid-XU3.
Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
---
Changes for v3:
- Remove unnecessary node from DT file
- Remove unnecessary features from config file
- Remove unnecessary macros from board-specific header file
- Fix some trivial typos in comments
Changes for v4:
- Add MMC FIFO buffer's configuration to DT file
- Make CONFIG_OF_CONTROL be set by the target information
- Add basic document to doc/README.odroid-xu3
- Add CONFIG_CMD_EXT4 to config file
- Add environment size and offset to config file
- Add extra default environment to make bootable without modification
- Remove unnecessary features from config file
Changes for v5:
- Convert /include/ to #include in DT file
Changes for v6:
- Separate out the documentation to new commit
- Remove unnecessary header file inclusions from the board-specific setup file
- Make the function board_clock_init be declared, only when
CONFIG_BOARD_EARLY_INIT_F is defined
Changes for v7:
- Remove OF_CONTROL dependency from !SPL_BUILD
Changes for v8:
- Remove unnecessary properties in DT mmc node
Changes for v9:
- Remove useless variables in the default environment
- Replace the detailed information to the reference to the documentation
Great to see this series. I wanted to test it earlier but had problems
with it not being reliable. I tracked this down to a uSD card (which
works fine on other boards but boots reliably only to SPL on XU3).
arch/arm/cpu/armv7/exynos/Kconfig | 5 ++
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/exynos5422-odroidxu3.dts | 57 +++
board/samsung/odroid-xu3/Kconfig | 12 +++
board/samsung/odroid-xu3/MAINTAINERS | 6 ++
board/samsung/odroid-xu3/Makefile | 7 ++
board/samsung/odroid-xu3/odroid-xu3.c | 122 +++
board/samsung/odroid-xu3/setup.h | 95
configs/odroid-xu3_defconfig | 4 +
include/configs/odroid.h | 5 --
include/configs/odroid_xu3.h | 133
++
11 files changed, 443 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/dts/exynos5422-odroidxu3.dts
create mode 100644 board/samsung/odroid-xu3/Kconfig
create mode 100644 board/samsung/odroid-xu3/MAINTAINERS
create mode 100644 board/samsung/odroid-xu3/Makefile
create mode 100644 board/samsung/odroid-xu3/odroid-xu3.c
create mode 100644 board/samsung/odroid-xu3/setup.h
create mode 100644 configs/odroid-xu3_defconfig
create mode 100644 include/configs/odroid_xu3.h
diff --git a/arch/arm/cpu/armv7/exynos/Kconfig
b/arch/arm/cpu/armv7/exynos/Kconfig
index 13dbd95..16c9a0e 100644
--- a/arch/arm/cpu/armv7/exynos/Kconfig
+++ b/arch/arm/cpu/armv7/exynos/Kconfig
@@ -24,6 +24,10 @@ config TARGET_TRATS2
config TARGET_ODROID
bool Exynos4412 Odroid board
+config TARGET_ODROID_XU3
+ bool Exynos5422 Odroid board
+ select OF_CONTROL
+
config TARGET_ARNDALE
bool Exynos5250 Arndale board
select SUPPORT_SPL
@@ -65,6 +69,7 @@ source board/samsung/universal_c210/Kconfig
source board/samsung/origen/Kconfig
source board/samsung/trats2/Kconfig
source board/samsung/odroid/Kconfig
+source board/samsung/odroid-xu3/Kconfig
source board/samsung/arndale/Kconfig
source board/samsung/smdk5250/Kconfig
source board/samsung/smdk5420/Kconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e5846ea..a811b1b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -13,7 +13,8 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5420-smdk5420.dtb \
exynos5420-peach-pit.dtb \
- exynos5800-peach-pi.dtb
+ exynos5800-peach-pi.dtb \
+ exynos5422-odroidxu3.dtb
Is it 5422 or 45800? Is there any difference really?
dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
new file mode 100644
index 000..533d88e
--- /dev/null
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -0,0 +1,57 @@
+/*
+ * Odroid XU3 device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include exynos54xx.dtsi
+
+/ {
+ model = Odroid XU3 based on EXYNOS5422;
+ compatible = samsung,odroidxu3, samsung,exynos5;
+
+ aliases {
+ serial0 = /serial@12C0;
+ console = /serial@12C2;
+ };
+
+
Re: [U-Boot] [PATCH 1/2] ARM: rpi: rename rpi_b to rpi
On 11/29/2014 08:56 PM, Simon Glass wrote:
Hi,
On 24 November 2014 at 08:52, Simon Glass s...@chromium.org wrote:
On 19 November 2014 at 20:41, Stephen Warren swar...@wwwdotorg.org wrote:
The U-Boot port runs on a variety of RPi models, not just the B. So,
rename the port to something slightly more generic.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
These two patches are based on ARM: rpi_b: detect board revision which
I sent recently.
---
arch/arm/Kconfig | 6 +++---
board/raspberrypi/{rpi_b = rpi}/Kconfig | 6 +++---
board/raspberrypi/rpi/MAINTAINERS | 6 ++
board/raspberrypi/{rpi_b = rpi}/Makefile | 2 +-
board/raspberrypi/{rpi_b/rpi_b.c = rpi/rpi.c} | 0
board/raspberrypi/rpi_b/MAINTAINERS| 6 --
common/lcd.c | 2 +-
configs/rpi_b_defconfig| 2 --
configs/rpi_defconfig | 2 ++
doc/README.clang | 4 ++--
include/configs/{rpi_b.h = rpi.h} | 0
11 files changed, 18 insertions(+), 18 deletions(-)
rename board/raspberrypi/{rpi_b = rpi}/Kconfig (71%)
create mode 100644 board/raspberrypi/rpi/MAINTAINERS
rename board/raspberrypi/{rpi_b = rpi}/Makefile (96%)
rename board/raspberrypi/{rpi_b/rpi_b.c = rpi/rpi.c} (100%)
delete mode 100644 board/raspberrypi/rpi_b/MAINTAINERS
delete mode 100644 configs/rpi_b_defconfig
create mode 100644 configs/rpi_defconfig
rename include/configs/{rpi_b.h = rpi.h} (100%)
Reviewed-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
I have a dependent driver model patch. Is this patch intended to go
through the ARM tree?
I would assume so, yes.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/3] ARM: tegra: Add support for nyan-big board
On 11/26/2014 01:46 PM, Simon Glass wrote:
From: Allen Martin amar...@nvidia.com
Nyan-big is a Tegra124 clamshell board that is very similar to venice2, but
it has a different panel, the sdcard cd and wp sense are flipped, and it has
a different revision of the AS3722 PMIC.
This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
Tegra K1, 2GB). The display is not currently supported, so it should
boot on other nyan-based Chromebooks also, but only the device tree for
nyan-big is provided here.
The device tree file is from Linux but with features removed which are
unlikely to be supported in U-Boot soon (regulators, pinmux). Also the
addresses are updated to 32-bit.
At a quick glance, the naming seems fine here, so I'm OK with the patch.
I'd like to see tegra-pinmux-scripts updated to suport this board, but
don't hold up this patch for that; just a nice to have when it can
happen. Perhaps Allen can also double-check that the pinmux data in this
patch exactly matches the NVIDIA syseng spreadsheet for this board.
I'd like Allen to explicitly comment on the reset GPIO difference and
why it occurred. I'd like to see that happen before the patch is merged,
so the pinmux data can be correct. Perhaps it's simply due to:
diff --git a/board/nvidia/nyan-big/nyan-big.c b/board/nvidia/nyan-big/nyan-big.c
+void pinmux_init(void)
+{
+ pinmux_set_tristate_input_clamping();
Apparently, we should explicitly not be doing that, even though I was
earlier told by our syseng team we explicitly should be doing that.
Removing that call (or explicitly reverting it) might make the
difference go away?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING Could not get liodn of node /pcie@ffe240000: FDT_ERR_NOTFOUND
York Sun york...@freescale.com wrote on 2014/12/01 18:26:21: On 11/26/2014 04:34 AM, Laurentiu Tudor wrote: Hi Jocke, York, Sorry for the late reply. I didn't noticed the thread in time. You need this patch: https://patchwork.ozlabs.org/patch/411910/ Great, I guess this will hit upstream any day now? I'm thinking York will pick it up in one of the following pull requests. I am merging patches in the order of date received. We will get there eventually. May I suggest bug fixes gets priority and are fast tracked? Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] tegra: config: Enable FIT and device tree for all boards
On 11/25/2014 10:44 AM, Simon Glass wrote:
Hi Stephen,
On 25 November 2014 at 09:23, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/24/2014 04:49 PM, Simon Glass wrote:
Hi Stephen,
On 24 November 2014 at 10:11, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/23/2014 09:12 AM, Simon Glass wrote:
Modern kernels require a device tree to boot.
True.
Enable FIT support to permit
booting these images, rather than just legacy images.
I don't understand this? Modern kernels boot perfectly well without FIT
support. U-Boot supports the kernel's standard separate DTB and zImage
file formats just fine.
To be honest, I'd strongly prefer not to enable support for non-universal
(bootloader-specific) formats such as FIT.
In U-Boot? FIT is U-Boot's standard format
That's rather my point: FIT is *U-Boot's* standard format, not a global
standard format.
I want to strongly guide anyone using Tegra towards globally standard
formats, not intimate that they should be using bootloader-specific formats.
zImage (without appended DTB) is a standard Linux format that all
booatloaders should support.
Raw DTB in a separate file (or perhaps provided by earlier firmware directly
in RAM/ROM) is a standard Linux format that all bootloaders should support.
extlinux.conf is something that all bootloaders should support.
Linux distros that install binaries or config files in those standard
formats should expect them to work with any bootloader, on any board. This
way, distros won't have to write explicit support for any board; they'll
just install standard files and everything will just work anywhere.
Just so I am clear, on ARM what is the list of bootloaders that you
are concerned with? FIT is actually not a difficult thing to add to a
boot loader. Presumably they all support libfdt, so it is just a case
of plumbing in the FIT access stuff.
I believe that Barebox supports extlinux.conf too.
I'm really not keen on this lowest-common-denominator approach, it's
just a sad situation. Also I don't see why extlinux.conf should
preclude people using FIT if they want to.
It doesn't. My point is that it's unlikely people will want FIT support
except in certain specific cases (such as ChromeOS compatibility), and
we shouldn't enable it except where there's a demonstrable use-case, so
we don't confuse people with non-standard options and accidentally lead
them down the wrong path.
...
Example /boot/extlinux.conf (for media-based booting) or
pxelinux.cfg/default (for network booting via syslinux command):
...
How does U-Boot select which device tree to pass to the kernel with
the scheme above? We shouldn't rely on the user, right? With FIT we
use CONFIG_FIT_BEST_MATCH.
extlinux.conf can specify a particular DTB filename if it wants.
Alternatively, it can specify a directory containing a set of DTBs, and
the bootloader must select which DTB to load.
If $fdtfile is set in U-Boot's environment, that file is used.
Otherwise, the U-Boot syslinux code uses some other environment
variables to calculate a default DTB filename; ${soc}-${board}.dtb.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] WARNING Could not get liodn of node /pcie@ffe240000: FDT_ERR_NOTFOUND
On 12/01/2014 10:31 AM, Joakim Tjernlund wrote: York Sun york...@freescale.com wrote on 2014/12/01 18:26:21: On 11/26/2014 04:34 AM, Laurentiu Tudor wrote: Hi Jocke, York, Sorry for the late reply. I didn't noticed the thread in time. You need this patch: https://patchwork.ozlabs.org/patch/411910/ Great, I guess this will hit upstream any day now? I'm thinking York will pick it up in one of the following pull requests. I am merging patches in the order of date received. We will get there eventually. May I suggest bug fixes gets priority and are fast tracked? Bug fix has priority. It is not about schedule, but about my capability to test each patch. Next release is schedule to be mid January. Before that you can apply the patch locally. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/8] common: spl: Add interactive DDR debugger support for SPL image
On 11/18/2014 09:07 AM, York Sun wrote: On 11/17/2014 11:02 PM, Albert ARIBAUD wrote: Hello York, On Mon, 17 Nov 2014 15:00:42 -0800, York Sun york...@freescale.com wrote: On 10/27/2014 06:48 PM, Wang Huan-B18965 wrote: Hello, Albert, snip --- Change log: v3: Gave more explaination in the commit. v2: No change. This does not apply cleanly. Could you rebase and resubmit? [Alison Wang] ok, I will rebase and resubmit the set. Thanks. Alison, Where are we on this patch? If you haven't sent an update, I can take this one and resolve the conflict. Albert, This set primarily deals with FSL specific boards. I can take them in if you don't see any issue with the patches (except the conflicts). Thanks York for the proposal, but I would prefer the patch to be rebased and resubmitted, as rebasing does require some changes which could be trivial, and thus be handled by the custodian, or not trivial, and thus require review; best, therefore, to rebase and repost. All right, then. Alison, please send a new set after you test it. I will mark this set change requested. Albert, I haven't seen a new version yet. I need this patch to apply other patches. I can fix the conflict in this patch. Do you mind if I take this v3 set? I think other patches in this set are OK. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] i2c: Fix deselection of muxes
Due to an uninitialised variable, when muxes were deselected, any value
could be written to the mux control register. On the PCA9548, this could
result in multiple channels being selected, thus enabling multiple
pull-up resistors, and much bus capacitance.
The fix is simply to initialise the written value to zero.
Signed-off-by: Mark Tomlinson mark.tomlin...@alliedtelesis.co.nz
---
drivers/i2c/i2c_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index d34b749..4539667 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -178,7 +178,7 @@ static int i2c_mux_disconnet_all(void)
{
struct i2c_bus_hose *i2c_bus_tmp = i2c_bus[I2C_BUS];
int i;
- uint8_t buf;
+ uint8_t buf = 0;
if (I2C_ADAP-init_done == 0)
return 0;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OpenQuestion] stdint.h and inttypes.h in U-Boot ?
Hi Masahiro, On 26 November 2014 at 00:45, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Tom, Simon, other developers, Since commit 0d296cc2d3b8 (Provide option to avoid defining a custom version of uintptr_t) and commit 4166ecb247a1 (Add some standard headers external code might need), I have been wondering if they were right decisions. As arch/arm/include/asm/types.h of Linux Kernel says, using 'stdint.h' is not feasible. --8- /* * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as * unambiguous on ARM as you would expect. For the types below, there is a * difference on ARM between GCC built for bare metal ARM, GCC built for glibc * and the kernel itself, which results in build errors if you try to build with * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h' * in order to use NEON intrinsics) * * As the typedefs for these types in 'stdint.h' are based on builtin defines * supplied by GCC, we can tweak these to align with the kernel's idea of those * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same * source file (provided that -ffreestanding is used). * *int32_t uint32_t uintptr_t * bare metal GCC longunsigned long unsigned int * glibc GCC int unsigned int unsigned int * kernel int unsigned int unsigned long */ --8 To me this doesn't matter. I feel that int32_t should probably be int on 32-bit ARM, but actually so long as it is consistent then it is fine if it is long. In fact so long as these types are defined consistently, everything works. Actually, the kernel never includes stdint.h except host programs. Commit 0d296cc2d3b8 introduced USE_STDINT, but it causes type conflicts depending on which GCC is used. With ARM bare metal GCC, yamada@beagle:~/workspace/u-boot$ make omap3_beagle_defconfig all CROSS_COMPILE=arm-none-eabi- USE_STDINT=1 # # configuration written to .config # # # configuration written to spl/.config # scripts/kconfig/conf --silentoldconfig Kconfig scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk CHK include/config/uboot.release CHK include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h CC lib/asm-offsets.s In file included from /opt/arm-2011.03/bin/../lib/gcc/arm-none-eabi/4.5.2/include/stdint.h:5:0, from include/compiler.h:117, from include/image.h:19, from include/common.h:85, from lib/asm-offsets.c:15: /opt/arm-2011.03/bin/../lib/gcc/arm-none-eabi/4.5.2/include/stdint-gcc.h:40:24: error: conflicting types for 'int32_t' include/linux/types.h:99:17: note: previous declaration of 'int32_t' was here /opt/arm-2011.03/bin/../lib/gcc/arm-none-eabi/4.5.2/include/stdint-gcc.h:52:25: error: conflicting types for 'uint32_t' include/linux/types.h:105:17: note: previous declaration of 'uint32_t' was here make[2]: *** [lib/asm-offsets.s] Error 1 make[1]: *** [prepare0] Error 2 make: *** [__build_one_by_one] Error 2 While toolchain is this? I don't see this problem - it seems broken. OK, we can fix int32_t and uint32_t, but it still seems strange to see that uint32_t is defined as unsigned long, whereas u32 is defined as unsigned int. If so, must we fix u32, s32, ... all the fixed-width typedefs ? I notice including linux/types.h in the U-Boot source tree and stdint.h provided by your compiler at the same time is a nightmare. If we lean toward stdint.h, we must ban linux/types.h, but stdint.h is not available all the time. For example, kernel.org tool-chains do not provide stdint.h. Maybe we can drastically re-write linux/types.h and friends to resolve the type conflicts, but I do not think we should not drift apart from the kernel because we have borrowed many source files from Linux. So far I don't see a big problem. I feel that, were stdint.h available earlier, then types.h might not have been written and we would just use stdint.h. Presumably stdint.h has been created to fix these sorts of problems, and in fact for new projects, they would not define their own types. IMO in time the kernel and U-Boot might move to stdint.h, and having it as an option at the moment helps us understand the issues. It does not break any builds. I could be wrong though, time will tell. We should keep an eye on it. Regards. Simon ___ U-Boot mailing list
[U-Boot] [PATCH 2/2] i2c: Correct spelling error
diconnect and disconnet should both be disconnect.
Signed-off-by: Mark Tomlinson mark.tomlin...@alliedtelesis.co.nz
---
drivers/i2c/i2c_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index 4539667..41cc3b8 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -174,7 +174,7 @@ static int i2c_mux_set_all(void)
return 0;
}
-static int i2c_mux_disconnet_all(void)
+static int i2c_mux_disconnect_all(void)
{
struct i2c_bus_hose *i2c_bus_tmp = i2c_bus[I2C_BUS];
int i;
@@ -197,7 +197,7 @@ static int i2c_mux_disconnet_all(void)
ret = I2C_ADAP-write(I2C_ADAP, chip, 0, 0, buf, 1);
if (ret != 0) {
- printf(i2c: mux diconnect error\n);
+ printf(i2c: mux disconnect error\n);
return ret;
}
} while (i 0);
@@ -293,7 +293,7 @@ int i2c_set_bus_num(unsigned int bus)
}
#ifndef CONFIG_SYS_I2C_DIRECT_BUS
- i2c_mux_disconnet_all();
+ i2c_mux_disconnect_all();
#endif
gd-cur_i2c_bus = bus;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] Exynos5800: The Peach-Pi board does not have a Parade video bridge
+Akshay Hi Sjoerd, On 1 December 2014 at 03:03, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Hey Simon, On Sun, 2014-11-30 at 11:56 -0700, Simon Glass wrote: On 27 November 2014 at 08:08, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the Pi. So drop it from device-tree Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes since v1: Only modify the DTB arch/arm/dts/exynos5800-peach-pi.dts | 5 - 1 file changed, 5 deletions(-) Acked-by: Simon Glass s...@chromium.org Tested on snow, pit, pi (display does not yet work on Pi). Just to be clear, in your testing does the display not work on Pi? It seems to be ok here (with u-boot starting chainloaded from one of the KERN partitions) That's right, not in U-Boot. I think this is because some GPIOs need to be enabled to turn on the backlight etc. Maybe you have an EC which turns these on automatically? If current mainline is supposed to make the display work on Pi then I need to do some debugging. Please let me know. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/3] ARM: tegra: Add support for nyan-big board
Hi Stephen,
On 1 December 2014 at 11:26, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/26/2014 01:46 PM, Simon Glass wrote:
From: Allen Martin amar...@nvidia.com
Nyan-big is a Tegra124 clamshell board that is very similar to venice2,
but
it has a different panel, the sdcard cd and wp sense are flipped, and it
has
a different revision of the AS3722 PMIC.
This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
Tegra K1, 2GB). The display is not currently supported, so it should
boot on other nyan-based Chromebooks also, but only the device tree for
nyan-big is provided here.
The device tree file is from Linux but with features removed which are
unlikely to be supported in U-Boot soon (regulators, pinmux). Also the
addresses are updated to 32-bit.
At a quick glance, the naming seems fine here, so I'm OK with the patch.
I'd like to see tegra-pinmux-scripts updated to suport this board, but don't
hold up this patch for that; just a nice to have when it can happen. Perhaps
Allen can also double-check that the pinmux data in this patch exactly
matches the NVIDIA syseng spreadsheet for this board.
I did send a patch to linux-tegra - sorry I may have forgotten to copy
anyone. I'll take another look.
I'd like Allen to explicitly comment on the reset GPIO difference and why it
occurred. I'd like to see that happen before the patch is merged, so the
pinmux data can be correct. Perhaps it's simply due to:
diff --git a/board/nvidia/nyan-big/nyan-big.c
b/board/nvidia/nyan-big/nyan-big.c
+void pinmux_init(void)
+{
+ pinmux_set_tristate_input_clamping();
Apparently, we should explicitly not be doing that, even though I was
earlier told by our syseng team we explicitly should be doing that. Removing
that call (or explicitly reverting it) might make the difference go away?
OK I will try taking it out and see what happens.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bare x86 support is merged to u-boot-x86
+Bin Hi Bruce, On 1 December 2014 at 12:33, bruce_leon...@selinc.com wrote: Hi Simon and Bin, u-boot-boun...@lists.denx.de wrote on 11/25/2014 01:51:06 PM: From: Simon Glass s...@chromium.org To: U-Boot Mailing List u-boot@lists.denx.de Cc: tr...@ti.com tr...@ti.com Date: 11/25/2014 01:52 PM Subject: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: u-boot-boun...@lists.denx.de Hi Bin (and others interested in U-Boot on x86), I've applied the remaining x86 patches to u-boot-x86. It runs on chromebook_link (Pixel) with support for most hardware relevant to a boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal 32GB SSD), SD card, LCD, UART, keyboard, EC. Bin this should be a good base for you to send patches for your Atom platform and I have no major work pending now so should not get in your way. Instructions on how to build and run are here: http://www.denx.de/wiki/U-Boot/X86 For this platform 4 binary blobs are needed. This is an unavoidable feature of the platform at present. The blobs cover flash descriptor, SDRAM init, video init and Management Engine. Instructions on how to get these are on the same page. Here is a list of some missing features: - README.x86 in the source (mostly the content from the Wiki page would be a good start) - MTRR support (for performance) - Audio - Chrome OS verified boot (only a rough rebase has been done, I'm not sure how to track mainline anyway) - SMI and ACPI support, to provide platform info and facilities to Linux This is awesome! Thanks so much for the work you two have done on this. We've been using u-boot on our PPC platforms for years and love it. We're considering moving to an Atom processor and wanted to continue to use u-boot, but were worried about getting it up and running with the FSL from Intel so we haven't made the jump yet. This is going to be a huge leg up in my argument for actually getting that project off the ground. If we do, I'll be sure to be pushing out any work we do that isn't in the mainline. Thanks again guys! Sounds good! What Atom are you using? It might be the same one as Bin. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] tegra: config: Enable FIT and device tree for all boards
Hi Stephen,
On 1 December 2014 at 11:41, Stephen Warren swar...@wwwdotorg.org wrote:
On 11/25/2014 10:44 AM, Simon Glass wrote:
Hi Stephen,
On 25 November 2014 at 09:23, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/24/2014 04:49 PM, Simon Glass wrote:
Hi Stephen,
On 24 November 2014 at 10:11, Stephen Warren swar...@wwwdotorg.org
wrote:
On 11/23/2014 09:12 AM, Simon Glass wrote:
Modern kernels require a device tree to boot.
True.
Enable FIT support to permit
booting these images, rather than just legacy images.
I don't understand this? Modern kernels boot perfectly well without FIT
support. U-Boot supports the kernel's standard separate DTB and zImage
file formats just fine.
To be honest, I'd strongly prefer not to enable support for
non-universal
(bootloader-specific) formats such as FIT.
In U-Boot? FIT is U-Boot's standard format
That's rather my point: FIT is *U-Boot's* standard format, not a global
standard format.
I want to strongly guide anyone using Tegra towards globally standard
formats, not intimate that they should be using bootloader-specific
formats.
zImage (without appended DTB) is a standard Linux format that all
booatloaders should support.
Raw DTB in a separate file (or perhaps provided by earlier firmware
directly
in RAM/ROM) is a standard Linux format that all bootloaders should
support.
extlinux.conf is something that all bootloaders should support.
Linux distros that install binaries or config files in those standard
formats should expect them to work with any bootloader, on any board.
This
way, distros won't have to write explicit support for any board; they'll
just install standard files and everything will just work anywhere.
Just so I am clear, on ARM what is the list of bootloaders that you
are concerned with? FIT is actually not a difficult thing to add to a
boot loader. Presumably they all support libfdt, so it is just a case
of plumbing in the FIT access stuff.
I believe that Barebox supports extlinux.conf too.
OK so I wonder if this problem would go away if Barebox supported FIT.
I haven't played with Barebox but could perhaps take a look.
I'm really not keen on this lowest-common-denominator approach, it's
just a sad situation. Also I don't see why extlinux.conf should
preclude people using FIT if they want to.
It doesn't. My point is that it's unlikely people will want FIT support
except in certain specific cases (such as ChromeOS compatibility), and we
shouldn't enable it except where there's a demonstrable use-case, so we
don't confuse people with non-standard options and accidentally lead them
down the wrong path.
My use case is to have one or more kernels, lots of device trees and
be able to boot on any arch. I think that is the same for you, but in
your case you rely on a filesystem to provide a large number of FDTs.
This means that we can't provide a kernel release as a single file,
nor can we support verified boot. With FIT we can support these.
...
Example /boot/extlinux.conf (for media-based booting) or
pxelinux.cfg/default (for network booting via syslinux command):
...
How does U-Boot select which device tree to pass to the kernel with
the scheme above? We shouldn't rely on the user, right? With FIT we
use CONFIG_FIT_BEST_MATCH.
extlinux.conf can specify a particular DTB filename if it wants.
Alternatively, it can specify a directory containing a set of DTBs, and the
bootloader must select which DTB to load.
If $fdtfile is set in U-Boot's environment, that file is used.
Otherwise, the U-Boot syslinux code uses some other environment variables to
calculate a default DTB filename; ${soc}-${board}.dtb.
OK I remember your patches now, sounds good.
Let me know if there is some other blocker (besides Barebox) to
supporting FIT more widely for kernel + device tree distribution.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-uniphier/master
On Fri, Nov 28, 2014 at 02:33:25AM +0900, Masahiro YAMADA wrote: Hi Tom, This series introduces Device Tree control support to Panasonic UniPhier platform. The following changes since commit 85bafb6da4dddfffa78479aa49a72ae48578a4ce: Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq (2014-11-26 11:23:26 -0500) are available in the git repository at: git://git.denx.de/u-boot-uniphier.git master for you to fetch changes up to 25e274e20208e047ea93afde04040e8c87430904: ARM: UniPhier: move CONFIG_CMD_* and CONFIG_FIT* defines to defconfig (2014-11-28 02:21:02 +0900) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods
On Wed, Nov 26, 2014 at 05:03:48PM -0500, Tom Rini wrote: The changes to introduce loff_t into filesize means that we need to do 64bit math on 32bit platforms. Make sure we use the right wrappers for these operations. Cc: Daniel Schwierzeck daniel.schwierz...@gmail.com Cc: Suriyan Ramasami suriya...@gmail.com Cc: Simon Glass s...@chromium.org Signed-off-by: Tom Rini tr...@ti.com Tested-by: Pierre Aubert p.aub...@staubli.com With the whitespace problem fixed, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] Exynos5800: The Peach-Pi board does not have a Parade video bridge
On Mon, 2014-12-01 at 13:09 -0700, Simon Glass wrote: +Akshay Hi Sjoerd, On 1 December 2014 at 03:03, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Hey Simon, On Sun, 2014-11-30 at 11:56 -0700, Simon Glass wrote: On 27 November 2014 at 08:08, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the Pi. So drop it from device-tree Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes since v1: Only modify the DTB arch/arm/dts/exynos5800-peach-pi.dts | 5 - 1 file changed, 5 deletions(-) Acked-by: Simon Glass s...@chromium.org Tested on snow, pit, pi (display does not yet work on Pi). Just to be clear, in your testing does the display not work on Pi? It seems to be ok here (with u-boot starting chainloaded from one of the KERN partitions) That's right, not in U-Boot. I think this is because some GPIOs need to be enabled to turn on the backlight etc. Maybe you have an EC which turns these on automatically? If current mainline is supposed to make the display work on Pi then I need to do some debugging. Please let me know. It does work on my machine, so i was wondering if it's a setup difference. I'm using the chained u-boot method (iotw the standard chromeos u-boot in flash starts main-line u-boot from mmc/SD), which might well mean that the GPIOs you're referring to are still turned on by the first u-boot (which it has to do to show me the unverified boot warning screen)? -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] Exynos5800: The Peach-Pi board does not have a Parade video bridge
Hi Sjoerd, On 1 December 2014 at 13:25, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: On Mon, 2014-12-01 at 13:09 -0700, Simon Glass wrote: +Akshay Hi Sjoerd, On 1 December 2014 at 03:03, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Hey Simon, On Sun, 2014-11-30 at 11:56 -0700, Simon Glass wrote: On 27 November 2014 at 08:08, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the Pi. So drop it from device-tree Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes since v1: Only modify the DTB arch/arm/dts/exynos5800-peach-pi.dts | 5 - 1 file changed, 5 deletions(-) Acked-by: Simon Glass s...@chromium.org Tested on snow, pit, pi (display does not yet work on Pi). Just to be clear, in your testing does the display not work on Pi? It seems to be ok here (with u-boot starting chainloaded from one of the KERN partitions) That's right, not in U-Boot. I think this is because some GPIOs need to be enabled to turn on the backlight etc. Maybe you have an EC which turns these on automatically? If current mainline is supposed to make the display work on Pi then I need to do some debugging. Please let me know. It does work on my machine, so i was wondering if it's a setup difference. I'm using the chained u-boot method (iotw the standard chromeos u-boot in flash starts main-line u-boot from mmc/SD), which might well mean that the GPIOs you're referring to are still turned on by the first u-boot (which it has to do to show me the unverified boot warning screen)? Yes that's right. Maybe Akshay / Ajay have ideas, or otherwise I can add this. I think it is two GPIOs, but it might be TPSCHROME also. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] dm: stv0991: Move serial to driver model
Signed-off-by: Vikas Manocha vikas.mano...@st.com
---
board/st/stv0991/stv0991.c | 13 +
include/configs/stv0991.h | 17 -
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/board/st/stv0991/stv0991.c b/board/st/stv0991/stv0991.c
index 989fb5e..f465699 100644
--- a/board/st/stv0991/stv0991.c
+++ b/board/st/stv0991/stv0991.c
@@ -13,12 +13,25 @@
#include asm/arch/gpio.h
#include netdev.h
#include asm/io.h
+#include dm/platdata.h
+#include dm/platform_data/serial_pl01x.h
DECLARE_GLOBAL_DATA_PTR;
struct gpio_regs *const gpioa_regs =
(struct gpio_regs *) GPIOA_BASE_ADDR;
+static const struct pl01x_serial_platdata serial_platdata = {
+ .base = 0x80406000,
+ .type = TYPE_PL011,
+ .clock = 2700 * 1000,
+};
+
+U_BOOT_DEVICE(stv09911_serials) = {
+ .name = serial_pl01x,
+ .platdata = serial_platdata,
+};
+
#ifdef CONFIG_SHOW_BOOT_PROGRESS
void show_boot_progress(int progress)
{
diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h
index 80652a8..fd9bd63 100644
--- a/include/configs/stv0991.h
+++ b/include/configs/stv0991.h
@@ -28,14 +28,21 @@
(PHYS_SDRAM_1_SIZE - CONFIG_ENV_SIZE)
#define CONFIG_SYS_MAXARGS 16
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 16 * 1024)
+#define CONFIG_SYS_MALLOC_F_LEN0x2000
+#define CONFIG_DM
/* serial port (PL011) configuration */
-#define CONFIG_SYS_SERIAL0 0x80406000
-#define CONFIG_PL011_SERIAL
-#define CONFIG_CONS_INDEX 0
#define CONFIG_BAUDRATE115200
-#define CONFIG_PL01x_PORTS {(void *)CONFIG_SYS_SERIAL0}
-#define CONFIG_PL011_CLOCK (2700 * 1000)
+#ifdef CONFIG_DM
+#define CONFIG_DM_SERIAL
+#define CONFIG_PL01X_SERIAL
+#else
+#define CONFIG_SYS_SERIAL0 0x80406000
+#define CONFIG_CONS_INDEX 0
+#define CONFIG_PL011_SERIAL
+#define CONFIG_PL01x_PORTS {(void *)CONFIG_SYS_SERIAL0}
+#define CONFIG_PL011_CLOCK (2700 * 1000)
+#endif
/* user interface */
#define CONFIG_SYS_PROMPT STV0991
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] stv0991: increase the initial ram size config
It is done to make space available for driver model memory. Signed-off-by: Vikas Manocha vikas.mano...@st.com --- include/configs/stv0991.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h index f95de06..80652a8 100644 --- a/include/configs/stv0991.h +++ b/include/configs/stv0991.h @@ -45,7 +45,7 @@ /* MISC */ #define CONFIG_SYS_LOAD_ADDR 0x -#define CONFIG_SYS_INIT_RAM_SIZE 0x2000 +#define CONFIG_SYS_INIT_RAM_SIZE 0x8000 #define CONFIG_SYS_INIT_RAM_ADDR 0x0019 #define CONFIG_SYS_INIT_SP_OFFSET \ (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) -- 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/2] stv0991: driver model support for pl01x
This patchset adds driver model support in stv0991 configures serial ip to driver model. Vikas Manocha (2): stv0991: increase the initial ram size config dm: stv0991: Move serial to driver model board/st/stv0991/stv0991.c | 13 + include/configs/stv0991.h | 19 +-- 2 files changed, 26 insertions(+), 6 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bare x86 support is merged to u-boot-x86
Simon, From: Simon Glass s...@chromium.org To: bruce_leon...@selinc.com Cc: tr...@ti.com tr...@ti.com, U-Boot Mailing List u- b...@lists.denx.de, u-boot-boun...@lists.denx.de, Bin Meng bmeng...@gmail.com Date: 12/01/2014 12:14 PM Subject: Re: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: s...@google.com +Bin Hi Bruce, On 1 December 2014 at 12:33, bruce_leon...@selinc.com wrote: Hi Simon and Bin, u-boot-boun...@lists.denx.de wrote on 11/25/2014 01:51:06 PM: From: Simon Glass s...@chromium.org To: U-Boot Mailing List u-boot@lists.denx.de Cc: tr...@ti.com tr...@ti.com Date: 11/25/2014 01:52 PM Subject: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: u-boot-boun...@lists.denx.de Hi Bin (and others interested in U-Boot on x86), I've applied the remaining x86 patches to u-boot-x86. It runs on chromebook_link (Pixel) with support for most hardware relevant to a boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal 32GB SSD), SD card, LCD, UART, keyboard, EC. Bin this should be a good base for you to send patches for your Atom platform and I have no major work pending now so should not get in your way. Instructions on how to build and run are here: http://www.denx.de/wiki/U-Boot/X86 For this platform 4 binary blobs are needed. This is an unavoidable feature of the platform at present. The blobs cover flash descriptor, SDRAM init, video init and Management Engine. Instructions on how to get these are on the same page. Here is a list of some missing features: - README.x86 in the source (mostly the content from the Wiki page would be a good start) - MTRR support (for performance) - Audio - Chrome OS verified boot (only a rough rebase has been done, I'm not sure how to track mainline anyway) - SMI and ACPI support, to provide platform info and facilities to Linux This is awesome! Thanks so much for the work you two have done on this. We've been using u-boot on our PPC platforms for years and love it. We're considering moving to an Atom processor and wanted to continue to use u-boot, but were worried about getting it up and running with the FSL from Intel so we haven't made the jump yet. This is going to be a hugeleg up in my argument for actually getting that project off the ground. If we do, I'll be sure to be pushing out any work we do that isn't in the mainline. Thanks again guys! Sounds good! What Atom are you using? It might be the same one as Bin. Not sure yet. We had originally settled on the first one Intel put out, but since we've waited so long and we're not locked in by design yet, we'll probably pick a newer generation. Our products tend to be in service for a long time (upwards of 20 years) so we like to get as cutting edge as we can without losing a finger :) Bruce Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] m68k: Build problems on some boards
Dear All, found this thread, i would have all coldfire boards correctly build here, so i am going to work on this. I just tried to build M52277EVB, and failing too with my actual toolchain. I'll try to find a toolchain that's able to build all coldfire boards and that is free to be downloaded. If any of you know some m68k-elf open toolchain please let me know. Regards, Angelo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3
Hi, On 28 November 2014 at 06:46, Lukasz Majewski l.majew...@majess.pl wrote: Hello Javier, Hello Lukasz, On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majew...@majess.pl wrote: I have yet to take him up on that offer though, but it sounds like a good way forward. The current layout really isn't practical. It indeed isn't very practical, but this is what you received from HardKernel when you buy XU3 board. Of course you can grab their sources, modify the layout, prepare u-boot's SPL and send it to them to be signed. However, it is not the way the normal user do things. He or she would like to replace standard (and outdated) HardKernel u-boot on their SD card and go forward with booting kernel. I agree with Sjoed that normal users don't replace the low-level components that are provided by the board vendor. After all you can boot a mainline kernel using the vendor u-boot, just append the DTB and create a uImage. The practical reason why someone would want to replace the vendor u-boot is to have more features but is very hard to do if there is a constraint in the maximum u-boot image size (even harder if the maximum is such small like in the XU3). I agree that 328 KiB size for u-boot is a constraint. I don't know HardKernel's justification for this. For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence we are obliged to have u-boot size smaller than 328 KiB. It is challenging but for sure doable. It is doable but I don't see why the default BL2 _must_ be used. For practical/pragmatic reasons: 1. It is difficult to have signed BL2 - each time we need to ask HardKernel for signing it. It is impractical and hampers usage of mainline SPL (BL2) with XU3. 2. All the documentation on the HardKernel wiki site refers to the default BL2. 3. We will have new BL2, which source code is based on 2012.07 mainline u-boot. 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner or latter. A user that wants to replace the kernel or u-boot is already tech-savy and can for sure replace the BL2 as well if it's publicly available. Sorry, but I'm a bit sceptical about updating such low level code. Bad things do happen. Maybe hardkernel folks can even make the modified BL2 available on their website and the link added in the comment explaining the layout? We would then require HardKernel to: 1. Provide updated BL2.img 2. Update their wiki to reflect the new BL2. Also, it is an artificial constraint after all and can be easily modified. In fact I think we should push hardkernel to change that layout by default and use a BL2/SPL that has more sensible size for the u-boot binary even if they don't need it for their vendor u-boot which seems to be quite small. I totally agree. I'd like to propose a following plan: 1. Accept Hyungwon's patches to have XU3 u-boot 328 KiB (with link to default BL2) to have XU3 support in place (and treat it as a starting point) 2. If u-boot's size less than 328 KiB is _really_ a problem to somebody then ask hardkernel to change BL2 or: - modify their sources to change the layout (I regard this as a quick hack solution) - with a lot of pain develop BL2/SPL (by whom?) which base on newest mainline (then for each test hardkernel must sign the binary). My 2p worth... The current Hardkernel BL1 looks broken to me - it is just too old. While it is shipped with the board if you get an eMMC, the main way people will get this is by downloading it from their site. So why not download something different? Re the plan, I think 1 is fine so long as it is protected by a big ugly hack CONFIG and we can turn it off soon and revert the code. For 2, the size issue is one problem, but the clock code in U-Boot is another IMO. We should try to get both resolved. Maybe it is possible to use the peach-pit BL2 and get hardkernel to test it and sign it? Then people will download that one instead. is there a contact at hardkernel on the mailing list? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86.git branch 'sandbox'
Hi Tom, A random collection of thnigs. Note the branch is 'sandbox'. The following changes since commit 85bafb6da4dddfffa78479aa49a72ae48578a4ce: Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq (2014-11-26 11:23:26 -0500) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 1d8104fe8897c5fec3e03b4165bc67c57eeeaa72: buildman: Don't default to -e when building current source (2014-11-26 20:25:40 -0700) Simon Glass (5): sandbox: Fix warnings due to 64-bit printf() strings sandbox: Fix warnings in cpu.c and os.c patman: Use the full commit hash for 'git checkout' buildman: Fix repeating board list with -l buildman: Don't default to -e when building current source Tom Rini (1): buildman: Save *.img files too arch/sandbox/cpu/os.c | 1 + arch/sandbox/cpu/start.c| 3 ++- common/cmd_mem.c| 6 -- common/fdt_support.c| 15 +++ disk/part_efi.c | 21 +++-- tools/buildman/README | 25 - tools/buildman/builder.py | 3 ++- tools/buildman/builderthread.py | 2 +- tools/buildman/control.py | 3 +-- tools/patman/patchstream.py | 3 +-- 10 files changed, 42 insertions(+), 40 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot
+Michael, U-Boot mailing list Hi, On 30 November 2014 at 19:26, Duxiaoqiang duxiaoqi...@huawei.com wrote: Hi Simon When I test verified boot with new version of U-boot and new version of mkimage, I encountered a alignment problem about RSA public key exponents. I tested verified boot successful few months ago with version of 2014.07-rc4, but failed with the same configuration and operations this time. Problem logs as below: I debug this problem and noticed that the problem was caused by pulic_exponent’s address: 0xff78a04c, this address was not aligned to 8 byte, but this address was pointed by a uint64 * type of pointer. Panic happened in function rsa_verify_with_keynode, just as below: By compared the u-boot.dtb file that signed with RSA public key, I noticed that there are differences about PUBLIC_EXPONENT. With the older version of mkimage, there’s no public exponent section. And this problem only happens when I use the new version of mkimage tool. I also checked uboot’s code, it seems that there’s lack of mechanism to guarantee the alignment about public exponent section. Can you give some suggestions about this problem. Appreciate your time. Copying Michael. Perhaps we need a safer version of fdt64_to_cpu()? But you might be the first to run this on aarch64. I have not tried it yet, but I do now have a platform. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] arm: rmobile: lager: Halt clock prior to booting kernel
Hi,
Thanks for your review.
2014-12-01 16:17 GMT+09:00 Wolfgang Denk w...@denx.de:
Dear Nobuhiro,
In message
1417417556-23946-4-git-send-email-nobuhiro.iwamatsu...@renesas.com you
wrote:
Before a kernel boots, GPIO, SYS-DMAC, QSPI and MSIOF clock
is halted.
Signed-off-by: Hisashi Nakamura hisashi.nakamura...@renesas.com
Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com
The data structures and the code are all repeated for this patch and
the following patches:
[PATCH 4/7] arm: rmobile: lager: Halt clock prior to booting kernel
[PATCH 5/7] arm: rmobile: koelsch: Halt clock prior to booting kernel
[U-Boot] [PATCH 6/7] arm: rmobile: alt: Halt clock prior to booting
kernel
[PATCH 7/7] arm: rmobile: gose: Halt clock prior to booting kernel
Can you please move the code to a common place so we have it only
once?
Yes. I will updates and resend patches.
+} mstptbl[] = {
+ [0] = { SMSTPCR0, 0x00640801, 0x0041,
+ RMSTPCR0, 0x00640801, 0x },
+ [1] = { SMSTPCR1, 0xDB6E9BDF, 0x,
+ RMSTPCR1, 0xDB6E9BDF, 0x },
+ [2] = { SMSTPCR2, 0x300DA1FC, 0x000CA120,
+ RMSTPCR2, 0x300DA1FC, 0x },
+ [3] = { SMSTPCR3, 0xF08CF831, 0x,
+ RMSTPCR3, 0xF08CF831, 0x },
+ [4] = { SMSTPCR4, 0x8184, 0x0180,
+ RMSTPCR4, 0x8184, 0x },
+ [5] = { SMSTPCR5, 0x44C00046, 0x,
+ RMSTPCR5, 0x44C00046, 0x },
+ [7] = { SMSTPCR7, 0x07F30718, 0x0020,
+ RMSTPCR7, 0x07F30718, 0x },
+ [8] = { SMSTPCR8, 0x01F0FF84, 0x,
+ RMSTPCR8, 0x01F0FF84, 0x },
+ [9] = { SMSTPCR9, 0xF5979FCF, 0x00021F80,
+ RMSTPCR9, 0xF5979FCF, 0x1F80 },
+ [10] = { SMSTPCR10, 0xFFFEFFE0, 0x,
+ RMSTPCR10, 0xFFFEFFE0, 0x },
+ [11] = { SMSTPCR11, 0x, 0x,
+ RMSTPCR11, 0x, 0x },
+};
Also, these data look pretty much the same to me, with only minor
differences in some bits. If we use some defines instead of the
magic numbers this could probably help to see the common part and the
differences in the data. We probably don't need board-specific data in
the code, and can move this to the configuration files?
Yes. I will move setting data to config files.
Thanks.
Best regards,
Wolfgang Denk
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bare x86 support is merged to u-boot-x86
Hi Simon and Bin, u-boot-boun...@lists.denx.de wrote on 11/25/2014 01:51:06 PM: From: Simon Glass s...@chromium.org To: U-Boot Mailing List u-boot@lists.denx.de Cc: tr...@ti.com tr...@ti.com Date: 11/25/2014 01:52 PM Subject: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: u-boot-boun...@lists.denx.de Hi Bin (and others interested in U-Boot on x86), I've applied the remaining x86 patches to u-boot-x86. It runs on chromebook_link (Pixel) with support for most hardware relevant to a boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal 32GB SSD), SD card, LCD, UART, keyboard, EC. Bin this should be a good base for you to send patches for your Atom platform and I have no major work pending now so should not get in your way. Instructions on how to build and run are here: http://www.denx.de/wiki/U-Boot/X86 For this platform 4 binary blobs are needed. This is an unavoidable feature of the platform at present. The blobs cover flash descriptor, SDRAM init, video init and Management Engine. Instructions on how to get these are on the same page. Here is a list of some missing features: - README.x86 in the source (mostly the content from the Wiki page would be a good start) - MTRR support (for performance) - Audio - Chrome OS verified boot (only a rough rebase has been done, I'm not sure how to track mainline anyway) - SMI and ACPI support, to provide platform info and facilities to Linux This is awesome! Thanks so much for the work you two have done on this. We've been using u-boot on our PPC platforms for years and love it. We're considering moving to an Atom processor and wanted to continue to use u-boot, but were worried about getting it up and running with the FSL from Intel so we haven't made the jump yet. This is going to be a huge leg up in my argument for actually getting that project off the ground. If we do, I'll be sure to be pushing out any work we do that isn't in the mainline. Thanks again guys! Bruce Regards, Simon ___ 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] m68k: Build problems on some boards
Hi, i was be able to compile all the m68k boards (if i grepp'ed well). In total 22 boards, and 36 defconfigs. astro_mcf5373l.h cobra5272.h eb_cpu5282.h gr_cpci_ax2000.h TASREG.h M5208EVBE.h M52277EVB.h M5235EVB.h M5249EVB.h M5253DEMO.h M5253EVBE.h M5272C3.h M5275EVB.h M5282EVB.h M53017EVB.h M5329EVB.h M5329AFEE_defconfig M5329BFEE_defconfig M5373EVB.h M54418TWR.h M54451EVB.h M54455EVB.h M5475EVB.h M5475AFE_defconfig M5475BFE_defconfig M5475CFE_defconfig M5475DFE_defconfig M5475EFE_defconfig M5475FFE_defconfig M5475GFE_defconfig M5485EVB.h M5485AFE_defconfig M5485BFE_defconfig M5485CFE_defconfig M5485DFE_defconfig M5485EFE_defconfig M5485FFE_defconfig M5485GFE_defconfig M5485HFE_defconfig The toolchain i used is: m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1 This toolchain was downloadable from Code Sourcery (Mentor) site some years ago, but actually seems not downloadable anymore. I would like to setup a wiki page and share it as downloadable but i am not sure this is legal. I am investigating. Regards, Angelo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/17] buildman: A few more features and improvements (Christmas edition)
Various people (on CC) have suggested improvements and reported bugs in buildman. I've done a pass through these and this series is the result. In summary the main changes are: - Flatten the output tree for 'current source builds' - Improve docs to talk about Python environment and ~/.buildman file - Toolchain path improvements and changes - Download and install a new toolchain automatically - Guess the upstream commit instead of requiring it to be set - Access to the full build output - Support for building an arbitrary range of commits Simon Glass (17): buildman: Add tests that check the correct output directory is used buildman: Put build in 'current', not 'current/current' buildman: Don't prune output space for 'current source' build buildman: Try to guess the upstream commit buildman: Add an option to flatten output directory trees buildman: Don't remove entire output directory when testing buildman: Allow specifying a range of commits to build buildman: Try to avoid hard-coded string parsing buildman: Put the toolchain path first instead of last in PATH buildman: Add an option to use the full tool chain path buildman: Add a note about Python pre-requisites buildman: Add documentation about the .buildman file buildman: Don't complain about missing sections in ~/.buildman buildman: Don't use the local settings when running tests buildman: Allow architecture to alias to multiple toolchains buildman: Add the option to download toolchains from kernel.org buildman: Add an option to write the full build output tools/buildman/README | 142 + tools/buildman/bsettings.py | 11 +- tools/buildman/builder.py | 21 +++- tools/buildman/builderthread.py | 7 +- tools/buildman/cmdline.py | 10 ++ tools/buildman/control.py | 58 +++-- tools/buildman/test.py | 75 ++- tools/buildman/toolchain.py | 270 +--- tools/patman/gitutil.py | 90 -- 9 files changed, 606 insertions(+), 78 deletions(-) -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/17] buildman: Don't prune output space for 'current source' build
This is not needed since we always do a full (non-incremental) build. Also it might be dangerous since it will try to delete everything below the base directory. Fix this potentially nasty bug. Signed-off-by: Simon Glass s...@chromium.org --- tools/buildman/builder.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py index 7002034..05ebfd2 100644 --- a/tools/buildman/builder.py +++ b/tools/buildman/builder.py @@ -1115,6 +1115,8 @@ class Builder: create. Having left over directories is confusing when the user wants to check the output manually. +if not self.commits: +return dir_list = [] for commit_upto in range(self.commit_count): dir_list.append(self._GetOutputDir(commit_upto)) -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/17] buildman: Put build in 'current', not 'current/current'
Buildman currently puts current-source builds in a current/current
subdirectory, but there is no need for the extra depth.
Suggested-by: Albert Aribaud albert.u.b...@aribaud.net
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/control.py | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 2c3ba8b..8b9a575 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -205,12 +205,11 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
if not gnu_make:
sys.exit('GNU Make not found')
-# Create a new builder with the selected options
+# Create a new builder with the selected options.
+output_dir = options.output_dir
if options.branch:
dirname = options.branch.replace('/', '_')
-else:
-dirname = 'current'
-output_dir = os.path.join(options.output_dir, dirname)
+output_dir = os.path.join(options.output_dir, dirname)
if clean_dir and os.path.exists(output_dir):
shutil.rmtree(output_dir)
builder = Builder(toolchains, output_dir, options.git_dir,
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/17] buildman: Allow specifying a range of commits to build
Adjust the -b flag to permit a range expression as well as a branch. Signed-off-by: Simon Glass s...@chromium.org Suggested-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- tools/buildman/README | 11 +++ tools/buildman/control.py | 19 +++ tools/patman/gitutil.py | 24 +++- 3 files changed, 45 insertions(+), 9 deletions(-) diff --git a/tools/buildman/README b/tools/buildman/README index db1ec68..0500ce5 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -699,6 +699,17 @@ build the selected boards and display build status as it runs (i.e. -v is enabled automatically). Use -e to see errors/warnings as well. +Building Ranges +=== + +You can build a range of commits by specifying a range instead of a branch +when using the -b flag. For example: + +upstream/master..us-buildman + +will build commits in us-buildman that are not in upstream/master. + + Other options = diff --git a/tools/buildman/control.py b/tools/buildman/control.py index 331b4f9..6a6743e 100644 --- a/tools/buildman/control.py +++ b/tools/buildman/control.py @@ -123,14 +123,22 @@ def DoBuildman(options, args, toolchains=None, make_func=None, boards=None, # problems introduced by the first commit on the branch. col = terminal.Color() count = options.count +has_range = options.branch and '..' in options.branch if count == -1: if not options.branch: count = 1 else: -count, msg = gitutil.CountCommitsInBranch(options.git_dir, - options.branch) +if has_range: +count, msg = gitutil.CountCommitsInRange(options.git_dir, + options.branch) +else: +count, msg = gitutil.CountCommitsInBranch(options.git_dir, + options.branch) if count is None: sys.exit(col.Color(col.RED, msg)) +elif count == 0: +sys.exit(col.Color(col.RED, Range '%s' has no commits % + options.branch)) if msg: print col.Color(col.YELLOW, msg) count += 1 # Build upstream commit also @@ -172,8 +180,11 @@ def DoBuildman(options, args, toolchains=None, make_func=None, boards=None, # to overwrite earlier ones by setting allow_overwrite=True if options.branch: if count == -1: -range_expr = gitutil.GetRangeInBranch(options.git_dir, - options.branch) +if has_range: +range_expr = options.branch +else: +range_expr = gitutil.GetRangeInBranch(options.git_dir, + options.branch) upstream_commit = gitutil.GetUpstream(options.git_dir, options.branch) series = patchstream.GetMetaDataForList(upstream_commit, diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py index 34c6b04..cc5a55a 100644 --- a/tools/patman/gitutil.py +++ b/tools/patman/gitutil.py @@ -154,6 +154,24 @@ def GetRangeInBranch(git_dir, branch, include_upstream=False): rstr = '%s%s..%s' % (upstream, '~' if include_upstream else '', branch) return rstr, msg +def CountCommitsInRange(git_dir, range_expr): +Returns the number of commits in the given range. + +Args: +git_dir: Directory containing git repo +range_expr: Range to check +Return: +Number of patches that exist in the supplied rangem or None if none +were found + +pipe = [LogCmd(range_expr, git_dir=git_dir, oneline=True)] +result = command.RunPipe(pipe, capture=True, capture_stderr=True, + raise_on_error=False) +if result.return_code: +return None, Range '%s' not found or is invalid % range_expr +patch_count = len(result.stdout.splitlines()) +return patch_count, None + def CountCommitsInBranch(git_dir, branch, include_upstream=False): Returns the number of commits in the given branch. @@ -167,11 +185,7 @@ def CountCommitsInBranch(git_dir, branch, include_upstream=False): range_expr, msg = GetRangeInBranch(git_dir, branch, include_upstream) if not range_expr: return None, msg -pipe = [LogCmd(range_expr, git_dir=git_dir, oneline=True), -['wc', '-l']] -result = command.RunPipe(pipe, capture=True, oneline=True) -patch_count = int(result.stdout) -return patch_count, msg +return CountCommitsInRange(git_dir, range_expr) def CountCommits(commit_range): Returns the number of commits in the given range. -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de
[U-Boot] [PATCH 01/17] buildman: Add tests that check the correct output directory is used
Add a few tests of the output directory logic.
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/test.py | 31 +++
1 file changed, 31 insertions(+)
diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index a2a85ac..f16d2fd 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.py
@@ -83,6 +83,8 @@ boards = [
['Active', 'sandbox', 'sandbox', '', 'Tester', 'Sandbox board', 'board4',
''],
]
+BASE_DIR = 'base'
+
class Options:
Class that holds build options
pass
@@ -341,6 +343,35 @@ class TestBuild(unittest.TestCase):
self.assertEqual(self.boards.SelectBoards(['sandbox sandbox',
'sandbox']),
{'all': 1, 'sandbox': 1})
+def CheckDirs(self, build, dirname):
+self.assertEqual('base%s' % dirname, build._GetOutputDir(1))
+self.assertEqual('base%s/fred' % dirname,
+ build.GetBuildDir(1, 'fred'))
+self.assertEqual('base%s/fred/done' % dirname,
+ build.GetDoneFile(1, 'fred'))
+self.assertEqual('base%s/fred/u-boot.sizes' % dirname,
+ build.GetFuncSizesFile(1, 'fred', 'u-boot'))
+self.assertEqual('base%s/fred/u-boot.objdump' % dirname,
+ build.GetObjdumpFile(1, 'fred', 'u-boot'))
+self.assertEqual('base%s/fred/err' % dirname,
+ build.GetErrFile(1, 'fred'))
+
+def testOutputDir(self):
+build = builder.Builder(self.toolchains, BASE_DIR, None, 1, 2,
+checkout=False, show_unknown=False)
+build.commits = self.commits
+build.commit_count = len(self.commits)
+subject = self.commits[1].subject.translate(builder.trans_valid_chars)
+dirname ='/%02d_of_%02d_g%s_%s' % (2, build.commit_count,
commits[1][0],
+ subject[:20])
+self.CheckDirs(build, dirname)
+
+def testOutputDirCurrent(self):
+build = builder.Builder(self.toolchains, BASE_DIR, None, 1, 2,
+checkout=False, show_unknown=False)
+build.commits = None
+build.commit_count = 0
+self.CheckDirs(build, '/current')
if __name__ == __main__:
unittest.main()
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/17] buildman: Don't remove entire output directory when testing
When running tests the output directory is often wiped. This is only safe if a branch is being built. The output directory may contain other things besides the buildman test output. Signed-off-by: Simon Glass s...@chromium.org --- tools/buildman/control.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/buildman/control.py b/tools/buildman/control.py index df24509..331b4f9 100644 --- a/tools/buildman/control.py +++ b/tools/buildman/control.py @@ -213,7 +213,8 @@ def DoBuildman(options, args, toolchains=None, make_func=None, boards=None, # output directory itself rather than any subdirectory. if not options.no_subdirs: output_dir = os.path.join(options.output_dir, dirname) -if clean_dir and os.path.exists(output_dir): +if (clean_dir and output_dir != options.output_dir and +os.path.exists(output_dir)): shutil.rmtree(output_dir) builder = Builder(toolchains, output_dir, options.git_dir, options.threads, options.jobs, gnu_make=gnu_make, checkout=True, -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/17] buildman: Add an option to use the full tool chain path
In some cases there may be multiple toolchains with the same name in the
path. Provide an option to use the full path in the CROSS_COMPILE
environment variable.
Note: Wolfgang mentioned that this is dangerous since in some cases there
may be other tools on the path that are needed. So this is set up as an
option, not the default. I will need test confirmation (i.e. that this
commit fixes a real problem) before merging it.
Signed-off-by: Simon Glass s...@chromium.org
Suggested-by: Steve Rae s...@broadcom.com
---
tools/buildman/builder.py | 7 ++-
tools/buildman/builderthread.py | 4 ++--
tools/buildman/cmdline.py | 2 ++
tools/buildman/control.py | 2 +-
tools/buildman/toolchain.py | 20 ++--
5 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index ca74c36..93d048b 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -175,7 +175,7 @@ class Builder:
def __init__(self, toolchains, base_dir, git_dir, num_threads, num_jobs,
gnu_make='make', checkout=True, show_unknown=True, step=1,
- no_subdirs=False):
+ no_subdirs=False, full_path=False):
Create a new Builder object
Args:
@@ -189,6 +189,10 @@ class Builder:
This is used for testing.
show_unknown: Show unknown boards (those not built) in summary
step: 1 to process every commit, n to process every nth commit
+no_subdirs: Don't create subdirectories when building current
+source for a single board
+full_path: Return the full path in CROSS_COMPILE and don't set
+PATH
self.toolchains = toolchains
self.base_dir = base_dir
@@ -215,6 +219,7 @@ class Builder:
self.in_tree = False
self._error_lines = 0
self.no_subdirs = no_subdirs
+self.full_path = full_path
self.col = terminal.Color()
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index bc4541c..a803481 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -177,7 +177,7 @@ class BuilderThread(threading.Thread):
commit = 'current'
# Set up the environment and command line
-env = self.toolchain.MakeEnvironment()
+env = self.toolchain.MakeEnvironment(self.builder.full_path)
Mkdir(out_dir)
args = []
cwd = work_dir
@@ -284,7 +284,7 @@ class BuilderThread(threading.Thread):
print fd, 'path', result.toolchain.path
# Write out the image and function size information and an objdump
-env = result.toolchain.MakeEnvironment()
+env = result.toolchain.MakeEnvironment(self.builder.full_path)
lines = []
for fname in ['u-boot', 'spl/u-boot-spl']:
cmd = ['%snm' % self.toolchain.cross, '--size-sort', fname]
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index 2b75653..6ad376d 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -62,6 +62,8 @@ def ParseArgs():
help='Directory where all builds happen and buildman has its
workspace (default is ../)')
parser.add_option('-Q', '--quick', action='store_true',
default=False, help='Do a rough build, with limited warning
resolution')
+parser.add_option('-p', '--full-path', action='store_true',
+ default=False, help=Use full toolchain path in CROSS_COMPILE)
parser.add_option('-s', '--summary', action='store_true',
default=False, help='Show a build summary')
parser.add_option('-S', '--show-sizes', action='store_true',
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 6a6743e..803e1d0 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -230,7 +230,7 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
builder = Builder(toolchains, output_dir, options.git_dir,
options.threads, options.jobs, gnu_make=gnu_make, checkout=True,
show_unknown=options.show_unknown, step=options.step,
-no_subdirs=options.no_subdirs)
+no_subdirs=options.no_subdirs, full_path=options.full_path)
builder.force_config_on_failure = not options.quick
if make_func:
builder.do_make = make_func
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index ab08193..cb693f4 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -41,7 +41,7 @@ class Toolchain:
pos = self.cross.find('-')
self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
-env = self.MakeEnvironment()
+env = self.MakeEnvironment(False)
# As a basic sanity check, run the C
[U-Boot] [PATCH 09/17] buildman: Put the toolchain path first instead of last in PATH
If:
1. Toolchains A and B have the same filename
2. Toolchain A is in the PATH
3. Toolchain B is given in ~/.buildman and buildman uses it to build
then buildman will add toolchain B to the end of its path but will not
necessarily use it since U-Boot will find toolchain A first in the PATH.
Try to fix this by putting the toolchain first in the path instead of
last.
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/toolchain.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index e2a851e..ab08193 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -89,7 +89,7 @@ class Toolchain:
env = dict(os.environ)
env['CROSS_COMPILE'] = self.cross
-env['PATH'] += (':' + self.path)
+env['PATH'] = self.path + ':' + env['PATH']
return env
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 15/17] buildman: Allow architecture to alias to multiple toolchains
Some archs have need than one alias, so support a list of alises in the
..buildman file.
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/README | 5 +++--
tools/buildman/test.py | 15 +++
tools/buildman/toolchain.py | 8 +---
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index affcb6c..093c177 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -701,8 +701,9 @@ a set of (tag, value) pairs.
This converts toolchain architecture names to U-Boot names. For example,
if an x86 toolchains is called i386-linux-gcc it will not normally be
-used for architecture 'x86'. Adding 'x86: i386' to this section will
-tell buildman that the i386 toolchain can be used for x86.
+used for architecture 'x86'. Adding 'x86: i386 x86_64' to this section
+will tell buildman that the i386 and x86_64 toolchains can be used for
+the x86 architecture.
'[make-flags]' section
diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index d19f6ea..25be43f 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.py
@@ -394,5 +394,20 @@ class TestBuild(unittest.TestCase):
build.commit_count = 0
self.CheckDirs(build, '')
+def testToolchainAliases(self):
+self.assertTrue(self.toolchains.Select('arm') != None)
+with self.assertRaises(ValueError):
+self.toolchains.Select('no-arch')
+with self.assertRaises(ValueError):
+self.toolchains.Select('x86')
+
+self.toolchains = toolchain.Toolchains()
+self.toolchains.Add('x86_64-linux-gcc', test=False)
+self.assertTrue(self.toolchains.Select('x86') != None)
+
+self.toolchains = toolchain.Toolchains()
+self.toolchains.Add('i386-linux-gcc', test=False)
+self.assertTrue(self.toolchains.Select('x86') != None)
+
if __name__ == __main__:
unittest.main()
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index cb693f4..ad4df8c 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -185,9 +185,11 @@ class Toolchains:
returns:
toolchain object, or None if none found
-for name, value in bsettings.GetItems('toolchain-alias'):
-if arch == name:
-arch = value
+for tag, value in bsettings.GetItems('toolchain-alias'):
+if arch == tag:
+for alias in value.split():
+if alias in self.toolchains:
+return self.toolchains[alias]
if not arch in self.toolchains:
raise ValueError, (No tool chain found for arch '%s' % arch)
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/17] buildman: Add documentation about the .buildman file
This file is only partially documented. Add some more details.
Signed-off-by: Simon Glass s...@chromium.org
Suggested-by: Wolfgang Denk w...@denx.de
---
tools/buildman/README | 73 +--
1 file changed, 53 insertions(+), 20 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index f3acf46..affcb6c 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -141,8 +141,8 @@ $ git clone git://git.denx.de/u-boot.git .
$ git checkout -b my-branch origin/master
$ # Add some commits to the branch, reading for testing
-2. Create ~/.buildman to tell buildman where to find tool chains. As an
-example:
+2. Create ~/.buildman to tell buildman where to find tool chains (see 'The
+.buildman file' later for details). As an example:
# Buildman settings file
@@ -675,28 +675,61 @@ It is common when refactoring code for the rodata to
decrease as the text size
increases, and vice versa.
-Providing 'make' flags
-==
+The .buildman file
+==
+
+The .buildman file provides information about the available toolchains and
+also allows build flags to be passed to 'make'. It consists of several
+sections, with the section name in square brackets. Within each section are
+a set of (tag, value) pairs.
+
+'[toolchain]' section
+
+This lists the available toolchains. The tag here doesn't matter, but
+make sure it is unique. The value is the path to the toolchain. Buildman
+will look in that path for a file ending in 'gcc'. It will then execute
+it to check that it is a C compiler, passing only the --version flag to
+it. If the return code is 0, buildman assumes that it is a valid C
+compiler. It uses the first part of the name as the architecture and
+strips off the last part when setting the CROSS_COMPILE environment
+variable (parts are delimited with a hyphen).
+
+For example powerpc-linux-gcc will be noted as a toolchain for 'powerpc'
+and CROSS_COMPILE will be set to powerpc-linux- when using it.
+
+'[toolchain-alias]' section
+
+This converts toolchain architecture names to U-Boot names. For example,
+if an x86 toolchains is called i386-linux-gcc it will not normally be
+used for architecture 'x86'. Adding 'x86: i386' to this section will
+tell buildman that the i386 toolchain can be used for x86.
+
+'[make-flags]' section
+
+U-Boot's build system supports a few flags (such as BUILD_TAG) which
+affect the build product. These flags can be specified in the buildman
+settings file. They can also be useful when building U-Boot against other
+open source software.
+
+[make-flags]
+at91-boards=ENABLE_AT91_TEST=1
+snapper9260=${at91-boards} BUILD_TAG=442
+snapper9g45=${at91-boards} BUILD_TAG=443
-U-Boot's build system supports a few flags (such as BUILD_TAG) which affect
-the build product. These flags can be specified in the buildman settings
-file. They can also be useful when building U-Boot against other open source
-software.
+This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260
+and 'make ENABLE_AT91_TEST=1 BUILD_TAG=443' for snapper9g45. A special
+variable ${target} is available to access the target name (snapper9260
+and snapper9g20 in this case). Variables are resolved recursively. Note
+that variables can only contain the characters A-Z, a-z, 0-9, hyphen (-)
+and underscore (_).
-[make-flags]
-at91-boards=ENABLE_AT91_TEST=1
-snapper9260=${at91-boards} BUILD_TAG=442
-snapper9g45=${at91-boards} BUILD_TAG=443
+It is expected that any variables added are dealt with in U-Boot's
+config.mk file and documented in the README.
-This will use 'make ENABLE_AT91_TEST=1 BUILD_TAG=442' for snapper9260
-and 'make ENABLE_AT91_TEST=1 BUILD_TAG=443' for snapper9g45. A special
-variable ${target} is available to access the target name (snapper9260 and
-snapper9g20 in this case). Variables are resolved recursively. Note that
-variables can only contain the characters A-Z, a-z, 0-9, hyphen (-) and
-underscore (_).
+Note that you can pass ad-hoc options to the build using environment
+variables, for example:
-It is expected that any variables added are dealt with in U-Boot's
-config.mk file and documented in the README.
+ SOME_OPTION=1234 ./tools/buildman/buildman my_board
Quick Sanity Check
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 16/17] buildman: Add the option to download toolchains from kernel.org
The site at https://www.kernel.org/pub/tools/crosstool/ is a convenient
repository of toolchains which can be used for U-Boot. Add a feature to
download and install a toolchain for a selected architecture automatically.
It isn't clear how long this site will stay in the current place and
format, but we should be able to rely on bug reports if it changes.
Suggested-by: Marek Vašut ma...@denx.de
Suggested-by: Fabio Estevam feste...@gmail.com
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/README | 47 -
tools/buildman/bsettings.py | 10 ++
tools/buildman/cmdline.py | 4 +
tools/buildman/control.py | 16 +++
tools/buildman/test.py | 6 ++
tools/buildman/toolchain.py | 233 ++--
6 files changed, 303 insertions(+), 13 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index 093c177..d4e8ce4 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -173,9 +173,9 @@ to build x86 commits.
3. Make sure you have the require Python pre-requisites
-Buildman uses multiprocessing, Queue, shutil, StringIO and ConfigParser.
-These should normally be available, but if you get an error like this then
-you will need to obtain those modules:
+Buildman uses multiprocessing, Queue, shutil, StringIO, ConfigParser and
+urllib2. These should normally be available, but if you get an error like
+this then you will need to obtain those modules:
ImportError: No module named multiprocessing
@@ -310,6 +310,47 @@ You can see that everything is covered, even some strange
ones that won't
be used (c88 and c99). This is a feature.
+5. Install new toolchains if needed
+
+You can download toolchains and update the [toolchain] section of the
+settings file to find them.
+
+To make this easier, buildman can automatically download and install
+toolchains from kernel.org. First list the available architectures:
+
+$ ./tools/buildman/buildman sandbox --fetch-arch list
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.2.4/
+Available architectures: alpha am33_2.0 arm avr32 bfin cris crisv32 frv h8300
+hppa hppa64 i386 ia64 m32r m68k mips mips64 or32 powerpc powerpc64 s390x sh4
+sparc sparc64 tilegx x86_64 xtensa
+
+Then pick one and download it:
+
+$ ./tools/buildman/buildman sandbox --fetch-arch or32
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.2/
+Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
+Downloading:
https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1//x86_64-gcc-4.5.1-nolibc_or32-linux.tar.xz
+Unpacking to: /home/sjg/.buildman-toolchains
+Testing
+ - looking in
'/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/.'
+ - looking in
'/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin'
+ - found
'/home/sjg/.buildman-toolchains/gcc-4.5.1-nolibc/or32-linux/bin/or32-linux-gcc'
+Tool chain test: OK
+
+Buildman should now be set up to use your new toolchain.
+
+At the time of writing, U-Boot has these architectures:
+
+ arc, arm, avr32, blackfin, m68k, microblaze, mips, nds32, nios2, openrisc
+ powerpc, sandbox, sh, sparc, x86
+
+Of these, only arc, microblaze and nds32 are not available at kernel.org..
+
+
How to run it
=
diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py
index 9eb9b2b..b361469 100644
--- a/tools/buildman/bsettings.py
+++ b/tools/buildman/bsettings.py
@@ -43,3 +43,13 @@ def GetItems(section):
return []
except:
raise
+
+def SetItem(section, tag, value):
+Set an item and write it back to the settings file
+global settings
+global config_fname
+
+settings.set(section, tag, value)
+if config_fname is not None:
+with open(config_fname, 'w') as fd:
+settings.write(fd)
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index 6ad376d..e884e19 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -36,6 +36,10 @@ def ParseArgs():
parser.add_option('-F', '--force-build-failures',
dest='force_build_failures',
action='store_true', default=False,
help='Force build of previously-failed build')
+parser.add_option('--fetch-arch', type='string',
+ help=Fetch a toolchain for architecture FETCH_ARCH ('list' to
list).
+ ' You can also fetch several toolchains separate by comma, or'
+ 'all' to download all)
parser.add_option('-g', '--git', type='string',
help='Git repo containing branch to build', default='.')
parser.add_option('-G',
[U-Boot] [PATCH 11/17] buildman: Add a note about Python pre-requisites
Since we need a few modules which might not be available in a bare-bones distribution, add a note about that to the README. Signed-off-by: Simon Glass s...@chromium.org Suggested-by: Wolfgang Denk w...@denx.de --- tools/buildman/README | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/tools/buildman/README b/tools/buildman/README index 0500ce5..f3acf46 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -171,7 +171,16 @@ The toolchain-alias section indicates that the i386 toolchain should be used to build x86 commits. -2. Check the available toolchains +3. Make sure you have the require Python pre-requisites + +Buildman uses multiprocessing, Queue, shutil, StringIO and ConfigParser. +These should normally be available, but if you get an error like this then +you will need to obtain those modules: + +ImportError: No module named multiprocessing + + +4. Check the available toolchains Run this check to make sure that you have a toolchain for every architecture. -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/17] buildman: Try to avoid hard-coded string parsing
The assumption that the compiler name will always end in gcc is incorrect
for clang and apparently on BSD.
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/toolchain.py | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index 27dc318..e2a851e 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -30,7 +30,14 @@ class Toolchain:
self.gcc = fname
self.path = os.path.dirname(fname)
-self.cross = os.path.basename(fname)[:-3]
+
+# Find the CROSS_COMPILE prefix to use for U-Boot. For example,
+# 'arm-linux-gnueabihf-gcc' turns into 'arm-linux-gnueabihf-'.
+basename = os.path.basename(fname)
+pos = basename.rfind('-')
+self.cross = basename[:pos + 1] if pos != -1 else ''
+
+# The architecture is the first part of the name
pos = self.cross.find('-')
self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/17] buildman: Don't complain about missing sections in ~/.buildman
Silently ignore this since it is valid to have missing sections. Signed-off-by: Simon Glass s...@chromium.org --- tools/buildman/bsettings.py | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py index fdd875b..9eb9b2b 100644 --- a/tools/buildman/bsettings.py +++ b/tools/buildman/bsettings.py @@ -40,7 +40,6 @@ def GetItems(section): try: return settings.items(section) except ConfigParser.NoSectionError as e: -print e return [] except: raise -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 14/17] buildman: Don't use the local settings when running tests
We should create a test setting file when running testes, not use whatever
happens to be on the local machine.
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/test.py | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index c085d2f..d19f6ea 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.py
@@ -24,6 +24,16 @@ import commit
import terminal
import toolchain
+settings_data = '''
+# Buildman settings file
+
+[toolchain]
+main: /usr/sbin
+
+[toolchain-alias]
+x86: i386 x86_64
+'''
+
errors = [
'''main.c: In function 'main_loop':
main.c:260:6: warning: unused variable 'joe' [-Wunused-variable]
@@ -113,8 +123,11 @@ class TestBuild(unittest.TestCase):
self.boards.AddBoard(board.Board(*brd))
self.boards.SelectBoards([])
+# Add some test settings
+bsettings.Setup(None)
+bsettings.AddFile(settings_data)
+
# Set up the toolchains
-bsettings.Setup()
self.toolchains = toolchain.Toolchains()
self.toolchains.Add('arm-linux-gcc', test=False)
self.toolchains.Add('sparc-linux-gcc', test=False)
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/17] buildman: Try to guess the upstream commit
Buildman normally obtains the upstream commit by asking git. Provided that
the branch was created with 'git checkout -b branch some_upstream' then
this normally works.
When there is no upstream, we can try to guess one, by looking up through
the commits until we find a branch. Add a function to try this and print
a warning if buildman ends up relying on it.
Also update the documentation to match.
Signed-off-by: Simon Glass s...@chromium.org
Suggested-by: Wolfgang Denk w...@denx.de
---
tools/buildman/README | 5 ++--
tools/buildman/control.py | 10 +++
tools/patman/gitutil.py | 68 ---
3 files changed, 67 insertions(+), 16 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index bfb2f18..db1ec68 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -310,8 +310,9 @@ branch with a valid upstream)
$ ./tools/buildman/buildman -b branch -n
If it can't detect the upstream branch, try checking out the branch, and
-doing something like 'git branch --set-upstream branch upstream/master'
-or something similar.
+doing something like 'git branch --set-upstream-to upstream/master'
+or something similar. Buildman will try to guess a suitable upstream branch
+if it can't find one (you will see a message like Guessing upstream as ...).
As an example:
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 8b9a575..663c4ce 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -127,12 +127,12 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
if not options.branch:
count = 1
else:
-count = gitutil.CountCommitsInBranch(options.git_dir,
- options.branch)
+count, msg = gitutil.CountCommitsInBranch(options.git_dir,
+ options.branch)
if count is None:
-str = (Branch '%s' not found or has no upstream %
- options.branch)
-sys.exit(col.Color(col.RED, str))
+sys.exit(col.Color(col.RED, msg))
+if msg:
+print col.Color(col.YELLOW, msg)
count += 1 # Build upstream commit also
if not count:
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index b68df5d..34c6b04 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -61,6 +61,52 @@ def CountCommitsToBranch():
patch_count = int(stdout)
return patch_count
+def NameRevision(commit_hash):
+Gets the revision name for a commit
+
+Args:
+commit_hash: Commit hash to look up
+
+Return:
+Name of revision, if any, else None
+
+pipe = ['git', 'name-rev', commit_hash]
+stdout = command.RunPipe([pipe], capture=True, oneline=True).stdout
+
+# We expect a commit, a space, then a revision name
+name = stdout.split(' ')[1].strip()
+return name
+
+def GuessUpstream(git_dir, branch):
+Tries to guess the upstream for a branch
+
+This lists out top commits on a branch and tries to find a suitable
+upstream. It does this by looking for the first commit where
+'git name-rev' returns a plain branch name, with no ! or ^ modifiers.
+
+Args:
+git_dir: Git directory containing repo
+branch: Name of branch
+
+Returns:
+Tuple:
+Name of upstream branch (e.g. 'upstream/master') or None if none
+Warning/error message, or None if none
+
+pipe = [LogCmd(branch, git_dir=git_dir, oneline=True, count=100)]
+result = command.RunPipe(pipe, capture=True, capture_stderr=True,
+ raise_on_error=False)
+if result.return_code:
+return None, Branch '%s' not found % branch
+for line in result.stdout.splitlines()[1:]:
+commit_hash = line.split(' ')[0]
+name = NameRevision(commit_hash)
+if '~' not in name and '^' not in name:
+if name.startswith('remotes/'):
+name = name[8:]
+return name, Guessing upstream as '%s' % name
+return None, Cannot find a suitable upstream for branch '%s' % branch
+
def GetUpstream(git_dir, branch):
Returns the name of the upstream for a branch
@@ -69,7 +115,9 @@ def GetUpstream(git_dir, branch):
branch: Name of branch
Returns:
-Name of upstream branch (e.g. 'upstream/master') or None if none
+Tuple:
+Name of upstream branch (e.g. 'upstream/master') or None if none
+Warning/error message, or None if none
try:
remote = command.OutputOneLine('git', '--git-dir', git_dir, 'config',
@@ -77,13 +125,14 @@ def GetUpstream(git_dir, branch):
merge = command.OutputOneLine('git', '--git-dir', git_dir, 'config',
'branch.%s.merge' % branch)
except:
-
[U-Boot] [PATCH 05/17] buildman: Add an option to flatten output directory trees
When building current source for a single board, buildman puts the output
in output_dir/current/current/board. Add an option to make it use
output_dir/board instead. This removes the unnecessary directories
in that case, controlled by the --no-subdirs/-N option.
Suggested-by: Tom Rini tr...@ti.com
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/builder.py | 12
tools/buildman/cmdline.py | 2 ++
tools/buildman/control.py | 8 ++--
tools/buildman/test.py| 8
4 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 05ebfd2..ca74c36 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -174,7 +174,8 @@ class Builder:
self.func_sizes = func_sizes
def __init__(self, toolchains, base_dir, git_dir, num_threads, num_jobs,
- gnu_make='make', checkout=True, show_unknown=True, step=1):
+ gnu_make='make', checkout=True, show_unknown=True, step=1,
+ no_subdirs=False):
Create a new Builder object
Args:
@@ -213,6 +214,7 @@ class Builder:
self._step = step
self.in_tree = False
self._error_lines = 0
+self.no_subdirs = no_subdirs
self.col = terminal.Color()
@@ -392,15 +394,17 @@ class Builder:
Args:
commit_upto: Commit number to use (0..self.count-1)
+commit_dir = None
if self.commits:
commit = self.commits[commit_upto]
subject = commit.subject.translate(trans_valid_chars)
commit_dir = ('%02d_of_%02d_g%s_%s' % (commit_upto + 1,
self.commit_count, commit.hash, subject[:20]))
-else:
+elif not self.no_subdirs:
commit_dir = 'current'
-output_dir = os.path.join(self.base_dir, commit_dir)
-return output_dir
+if not commit_dir:
+return self.base_dir
+return os.path.join(self.base_dir, commit_dir)
def GetBuildDir(self, commit_upto, target):
Get the name of the build directory for a commit number
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index 27d3c70..2b75653 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -55,6 +55,8 @@ def ParseArgs():
help='List available tool chains')
parser.add_option('-n', '--dry-run', action='store_true', dest='dry_run',
default=False, help=Do a dry run (describe actions, but do
nothing))
+parser.add_option('-N', '--no-subdirs', action='store_true',
dest='no_subdirs',
+ default=False, help=Don't create subdirectories when building
current source for a single board)
parser.add_option('-o', '--output-dir', type='string',
dest='output_dir', default='..',
help='Directory where all builds happen and buildman has its
workspace (default is ../)')
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 663c4ce..df24509 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -209,12 +209,16 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
output_dir = options.output_dir
if options.branch:
dirname = options.branch.replace('/', '_')
-output_dir = os.path.join(options.output_dir, dirname)
+# As a special case allow the board directory to be placed in the
+# output directory itself rather than any subdirectory.
+if not options.no_subdirs:
+output_dir = os.path.join(options.output_dir, dirname)
if clean_dir and os.path.exists(output_dir):
shutil.rmtree(output_dir)
builder = Builder(toolchains, output_dir, options.git_dir,
options.threads, options.jobs, gnu_make=gnu_make, checkout=True,
-show_unknown=options.show_unknown, step=options.step)
+show_unknown=options.show_unknown, step=options.step,
+no_subdirs=options.no_subdirs)
builder.force_config_on_failure = not options.quick
if make_func:
builder.do_make = make_func
diff --git a/tools/buildman/test.py b/tools/buildman/test.py
index f16d2fd..c085d2f 100644
--- a/tools/buildman/test.py
+++ b/tools/buildman/test.py
@@ -373,5 +373,13 @@ class TestBuild(unittest.TestCase):
build.commit_count = 0
self.CheckDirs(build, '/current')
+def testOutputDirNoSubdirs(self):
+build = builder.Builder(self.toolchains, BASE_DIR, None, 1, 2,
+checkout=False, show_unknown=False,
+no_subdirs=True)
+build.commits = None
+build.commit_count = 0
+self.CheckDirs(build, '')
+
if __name__ == __main__:
unittest.main()
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 17/17] buildman: Add an option to write the full build output
Normally buildman runs with 'make -s' meaning that only errors and warnings
appear in the log file. Add a -V option to run make in verbose mode, and
with V=1, causing a full build log to be created.
Signed-off-by: Simon Glass s...@chromium.org
---
tools/buildman/builder.py | 4 +++-
tools/buildman/builderthread.py | 3 ++-
tools/buildman/cmdline.py | 2 ++
tools/buildman/control.py | 3 ++-
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 93d048b..1b0ad99 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -175,7 +175,7 @@ class Builder:
def __init__(self, toolchains, base_dir, git_dir, num_threads, num_jobs,
gnu_make='make', checkout=True, show_unknown=True, step=1,
- no_subdirs=False, full_path=False):
+ no_subdirs=False, full_path=False, verbose_build=False):
Create a new Builder object
Args:
@@ -193,6 +193,7 @@ class Builder:
source for a single board
full_path: Return the full path in CROSS_COMPILE and don't set
PATH
+verbose_build: Run build with V=1 and don't use 'make -s'
self.toolchains = toolchains
self.base_dir = base_dir
@@ -220,6 +221,7 @@ class Builder:
self._error_lines = 0
self.no_subdirs = no_subdirs
self.full_path = full_path
+self.verbose_build = verbose_build
self.col = terminal.Color()
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index a803481..efb62f1 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -197,7 +197,8 @@ class BuilderThread(threading.Thread):
src_dir = os.getcwd()
else:
args.append('O=build')
-args.append('-s')
+if not self.builder.verbose_build:
+args.append('-s')
if self.builder.num_jobs is not None:
args.extend(['-j', str(self.builder.num_jobs)])
config_args = ['%s_defconfig' % brd.target]
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index e884e19..e8a6dad 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -82,6 +82,8 @@ def ParseArgs():
default=False, help='Show boards with unknown build result')
parser.add_option('-v', '--verbose', action='store_true',
default=False, help='Show build results while the build progresses')
+parser.add_option('-V', '--verbose-build', action='store_true',
+ default=False, help='Run make with V=1, showing all output')
parser.add_option('-x', '--exclude', dest='exclude',
type='string', action='append',
help='Specify a list of boards to exclude, separated by comma')
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 6fe53cb..5bbd87d 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -246,7 +246,8 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
builder = Builder(toolchains, output_dir, options.git_dir,
options.threads, options.jobs, gnu_make=gnu_make, checkout=True,
show_unknown=options.show_unknown, step=options.step,
-no_subdirs=options.no_subdirs, full_path=options.full_path)
+no_subdirs=options.no_subdirs, full_path=options.full_path,
+verbose_build=options.verbose_build)
builder.force_config_on_failure = not options.quick
if make_func:
builder.do_make = make_func
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/25] tegra: Add eDP support for nyan-big
This series adds eDP support for nyan-bg so that the display works.
Nyan-big is based on tegra124.
Some support is added for new clocks to make this work. The drm_dp_helper.h
file is brought in from Linux since many of the DisplayPort constants are
generic. A very simple uclass is added for DisplayPort, and the Tegra
driver makes use of that. The U-Boot EDID support is enhanced to read some
additional information (detailed timings).
There is existing video support for Tegra20, but I don't think it works for
Tegra30/114 (is this correct?). This series relies on detecting the display
at run-time as I cannot find a good device tree binding for things like
display depth. But if we could resolve that then it might be possible to
move Tegra20 over to use the same driver, etc. There is clearly a lot in
common with the display controllers - I have exploited this with the header
file but not with the C file.
HDMI is not supported at present. If this is easy and there is an existing
driver to follow along with then I might be able to incorporate it later.
This series is available at u-boot-dm/nyan-working
Simon Glass (25):
dm: tegra: config: Increase pre-reloc malloc() to 6KB
fdt: Add binding decode function for display-timings
tegra: Move the pww into tegra-common
tegra: pwm: Allow the clock rate to be left as is
tegra: Move checkboard() into the board code
tegra: Add a board ID function
power: Export register access functions from as3722
tegra: Provide a function to allow LCD PMIC setup
tegra: Add support for setting up a as3722 PMIC
tegra: nyan-big: Add LCD PMIC init and board ID
tegra124: dts: Add host1x node to provide display information
tegra: config: Use CONFIG_LCD to detect LCD presence
tegra: clock: Add checking for invalid clock IDs
tegra: clock: Split the clock source code into a separate function
tegra124: clock: Add display clocks and functions
tegra: Move display controller header into common
video: Add drm_dp_helper.h
edid: Add a function to read detailed monitor timings
dm: video: Add a uclass for display port
tegra: dts: nyan-big: Add definitions for eDP display
tegra: video: Support serial output resource (SOR) on tegra124
tegra: video: Add Embedded DisplayPort driver
tegra: video: support eDP displays on Tegra124 devices
tegra: config: nyan-big: Enable LCD
tegra124: video: Add full link training for eDP
arch/arm/cpu/armv7/tegra-common/Makefile |1 +
arch/arm/cpu/armv7/{tegra20 = tegra-common}/pwm.c |5 +-
arch/arm/cpu/armv7/tegra20/Makefile|1 -
arch/arm/cpu/armv7/tegra20/display.c |2 +-
arch/arm/cpu/tegra-common/board.c |8 -
arch/arm/cpu/tegra-common/clock.c | 83 +-
arch/arm/cpu/tegra124-common/clock.c | 141 +-
arch/arm/dts/tegra124-nyan-big.dts | 47 +
arch/arm/dts/tegra124.dtsi | 84 ++
arch/arm/include/asm/arch-tegra/clk_rst.h | 15 +-
arch/arm/include/asm/arch-tegra/clock.h| 14 +
.../include/asm/{arch-tegra20 = arch-tegra}/dc.h | 63 +-
arch/arm/include/asm/arch-tegra/pwm.h | 60 +
arch/arm/include/asm/arch-tegra/sys_proto.h| 19 +-
arch/arm/include/asm/arch-tegra124/clock-tables.h |3 +-
arch/arm/include/asm/arch-tegra124/clock.h | 21 +
arch/arm/include/asm/arch-tegra124/display.h | 58 +
arch/arm/include/asm/arch-tegra124/pwm.h | 14 +
arch/arm/include/asm/arch-tegra20/display.h|2 +-
arch/arm/include/asm/arch-tegra20/pwm.h| 54 +-
board/nvidia/common/board.c| 40 +-
board/nvidia/nyan-big/nyan-big.c | 34 +-
common/edid.c | 106 ++
configs/nyan-big_defconfig |2 +
.../gpu/nvidia,tegra20-host1x.txt | 372 +
doc/device-tree-bindings/video/display-timing.txt | 110 ++
drivers/power/as3722.c | 16 +-
drivers/video/Kconfig | 14 +
drivers/video/Makefile |6 +
drivers/video/dp-uclass.c | 34 +
drivers/video/tegra124/Makefile| 10 +
drivers/video/tegra124/display.c | 354 +
drivers/video/tegra124/displayport.h | 412 ++
drivers/video/tegra124/dp.c| 1500
drivers/video/tegra124/sor.c | 951 +
drivers/video/tegra124/sor.h | 913
drivers/video/tegra124/tegra124-lcd.c | 94 ++
include/configs/nyan-big.h | 13 +
include/configs/tegra-common-post.h|2 +-
include/configs/tegra-common.h |2 +-
include/displayport.h | 60 +
[U-Boot] [PATCH 18/25] edid: Add a function to read detailed monitor timings
For digital displays (such as EDP LCDs) we would like to read the EDID
information and use that to set display timings. Provide a function to do
this.
Signed-off-by: Simon Glass s...@chromium.org
---
common/edid.c | 106 +
include/edid.h | 19 +++
2 files changed, 125 insertions(+)
diff --git a/common/edid.c b/common/edid.c
index e66108f..c031eee 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -12,6 +12,8 @@
#include common.h
#include edid.h
+#include errno.h
+#include fdtdec.h
#include linux/ctype.h
#include linux/string.h
@@ -53,6 +55,110 @@ int edid_get_ranges(struct edid1_info *edid, unsigned int
*hmin,
return -1;
}
+/* Set all parts of a timing entry to the same value */
+static void set_entry(struct timing_entry *entry, u32 value)
+{
+ entry-min = value;
+ entry-typ = value;
+ entry-max = value;
+}
+
+/**
+ * decode_timing() - Decoding an 18-byte detailed timing record
+ *
+ * @buf: Pointer to EDID detailed timing record
+ * @timing:Place to put timing
+ */
+static void decode_timing(u8 *buf, struct display_timing *timing)
+{
+ uint x_mm, y_mm;
+ unsigned int ha, hbl, hso, hspw, hborder;
+ unsigned int va, vbl, vso, vspw, vborder;
+
+ /* Edid contains pixel clock in terms of 10KHz */
+ set_entry(timing-pixelclock, (buf[0] + (buf[1] 8)) * 1);
+ x_mm = (buf[12] + ((buf[14] 0xf0) 4));
+ y_mm = (buf[13] + ((buf[14] 0x0f) 8));
+ ha = (buf[2] + ((buf[4] 0xf0) 4));
+ hbl = (buf[3] + ((buf[4] 0x0f) 8));
+ hso = (buf[8] + ((buf[11] 0xc0) 2));
+ hspw = (buf[9] + ((buf[11] 0x30) 4));
+ hborder = buf[15];
+ va = (buf[5] + ((buf[7] 0xf0) 4));
+ vbl = (buf[6] + ((buf[7] 0x0f) 8));
+ vso = ((buf[10] 4) + ((buf[11] 0x0c) 2));
+ vspw = ((buf[10] 0x0f) + ((buf[11] 0x03) 4));
+ vborder = buf[16];
+
+ set_entry(timing-hactive, ha);
+ set_entry(timing-hfront_porch, hso);
+ set_entry(timing-hback_porch, hbl - hso - hspw);
+ set_entry(timing-hsync_len, hspw);
+
+ set_entry(timing-vactive, va);
+ set_entry(timing-vfront_porch, vso);
+ set_entry(timing-vback_porch, vbl - vso - vspw);
+ set_entry(timing-vsync_len, vspw);
+
+ debug(Detailed mode clock %u Hz, %d mm x %d mm\n
+%04x %04x %04x %04x hborder %x\n
+%04x %04x %04x %04x vborder %x\n,
+ timing-pixelclock.typ,
+ x_mm, y_mm,
+ ha, ha + hso, ha + hso + hspw,
+ ha + hbl, hborder,
+ va, va + vso, va + vso + vspw,
+ va + vbl, vborder);
+}
+
+int edid_get_timing(u8 *buf, int buf_size, struct display_timing *timing,
+ int *panel_bits_per_colourp)
+{
+ struct edid1_info *edid = (struct edid1_info *)buf;
+ bool timing_done;
+ int i;
+
+ if (buf_size sizeof(*edid) || edid_check_info(edid)) {
+ debug(%s: Invalid buffer\n, __func__);
+ return -EINVAL;
+ }
+
+ if (!EDID1_INFO_FEATURE_PREFERRED_TIMING_MODE(*edid)) {
+ debug(%s: No preferred timing\n, __func__);
+ return -ENOENT;
+ }
+
+ /* Look for detailed timing */
+ timing_done = false;
+ for (i = 0; i 4; i++) {
+ struct edid_monitor_descriptor *desc;
+
+ desc = edid-monitor_details.descriptor[i];
+ if (desc-zero_flag_1 != 0) {
+ decode_timing((u8 *)desc, timing);
+ timing_done = true;
+ break;
+ }
+ }
+ if (!timing_done)
+ return -EINVAL;
+
+ if (!EDID1_INFO_VIDEO_INPUT_DIGITAL(*edid)) {
+ debug(%s: Not a digital display\n, __func__);
+ return -ENOSYS;
+ }
+ if (edid-version != 1 || edid-revision 4) {
+ debug(%s: EDID version %d.%d does not have required info\n,
+ __func__, edid-version, edid-revision);
+ *panel_bits_per_colourp = -1;
+ } else {
+ *panel_bits_per_colourp =
+ ((edid-video_input_definition 0x70) 3) + 4;
+ }
+
+ return 0;
+}
+
/**
* Snip the tailing whitespace/return of a string.
*
diff --git a/include/edid.h b/include/edid.h
index 480a773..d331738 100644
--- a/include/edid.h
+++ b/include/edid.h
@@ -15,6 +15,9 @@
#include linux/types.h
+/* Size of the EDID data */
+#define EDID_SIZE 128
+
#define GET_BIT(_x, _pos) \
(((_x) (_pos)) 1)
#define GET_BITS(_x, _pos_msb, _pos_lsb) \
@@ -255,4 +258,20 @@ int edid_get_ranges(struct edid1_info *edid, unsigned int
*hmin,
unsigned int *hmax, unsigned int *vmin,
unsigned int *vmax);
+struct display_timing;
+
+/**
+ * edid_get_timing() - Get basic digital
[U-Boot] [PATCH 01/25] dm: tegra: config: Increase pre-reloc malloc() to 6KB
If we enable GPIOs as well as everything else, we need just over 4KB of space. Enlarge it a little. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/tegra-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index 3ce566c..7de4b1d 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -46,7 +46,7 @@ * Size of malloc() pool */ #define CONFIG_SYS_MALLOC_LEN (4 20) /* 4MB */ -#define CONFIG_SYS_MALLOC_F_LEN(4 10) +#define CONFIG_SYS_MALLOC_F_LEN(6 10) #ifdef CONFIG_SPL_BUILD #define CONFIG_SYS_MALLOC_SIMPLE #endif -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 17/25] video: Add drm_dp_helper.h
This file (from Linux 3.17) provides defines for display port. Use it so that our naming is consistent with Linux. Signed-off-by: Simon Glass s...@chromium.org --- include/linux/drm_dp_helper.h | 405 ++ 1 file changed, 405 insertions(+) create mode 100644 include/linux/drm_dp_helper.h diff --git a/include/linux/drm_dp_helper.h b/include/linux/drm_dp_helper.h new file mode 100644 index 000..86b06e1 --- /dev/null +++ b/include/linux/drm_dp_helper.h @@ -0,0 +1,405 @@ +/* + * Copyright © 2008 Keith Packard + * + * Permission to use, copy, modify, distribute, and sell this software and its + * documentation for any purpose is hereby granted without fee, provided that + * the above copyright notice appear in all copies and that both that copyright + * notice and this permission notice appear in supporting documentation, and + * that the name of the copyright holders not be used in advertising or + * publicity pertaining to distribution of the software without specific, + * written prior permission. The copyright holders make no representations + * about the suitability of this software for any purpose. It is provided as + * is without express or implied warranty. + * + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE + * OF THIS SOFTWARE. + */ + +#ifndef _DRM_DP_HELPER_H_ +#define _DRM_DP_HELPER_H_ + +/* + * Unless otherwise noted, all values are from the DP 1.1a spec. Note that + * DP and DPCD versions are independent. Differences from 1.0 are not noted, + * 1.0 devices basically don't exist in the wild. + * + * Abbreviations, in chronological order: + * + * eDP: Embedded DisplayPort version 1 + * DPI: DisplayPort Interoperability Guideline v1.1a + * 1.2: DisplayPort 1.2 + * MST: Multistream Transport - part of DP 1.2a + * + * 1.2 formally includes both eDP and DPI definitions. + */ + +#define DP_AUX_I2C_WRITE 0x0 +#define DP_AUX_I2C_READ0x1 +#define DP_AUX_I2C_STATUS 0x2 +#define DP_AUX_I2C_MOT 0x4 +#define DP_AUX_NATIVE_WRITE0x8 +#define DP_AUX_NATIVE_READ 0x9 + +#define DP_AUX_NATIVE_REPLY_ACK(0x0 0) +#define DP_AUX_NATIVE_REPLY_NACK (0x1 0) +#define DP_AUX_NATIVE_REPLY_DEFER (0x2 0) +#define DP_AUX_NATIVE_REPLY_MASK (0x3 0) + +#define DP_AUX_I2C_REPLY_ACK (0x0 2) +#define DP_AUX_I2C_REPLY_NACK (0x1 2) +#define DP_AUX_I2C_REPLY_DEFER (0x2 2) +#define DP_AUX_I2C_REPLY_MASK (0x3 2) + +/* AUX CH addresses */ +/* DPCD */ +#define DP_DPCD_REV 0x000 + +#define DP_MAX_LINK_RATE0x001 + +#define DP_MAX_LANE_COUNT 0x002 +# define DP_MAX_LANE_COUNT_MASK0x1f +# define DP_TPS3_SUPPORTED (1 6) /* 1.2 */ +# define DP_ENHANCED_FRAME_CAP (1 7) + +#define DP_MAX_DOWNSPREAD 0x003 +# define DP_NO_AUX_HANDSHAKE_LINK_TRAINING (1 6) + +#define DP_NORP 0x004 + +#define DP_DOWNSTREAMPORT_PRESENT 0x005 +# define DP_DWN_STRM_PORT_PRESENT (1 0) +# define DP_DWN_STRM_PORT_TYPE_MASK 0x06 +# define DP_DWN_STRM_PORT_TYPE_DP (0 1) +# define DP_DWN_STRM_PORT_TYPE_ANALOG (1 1) +# define DP_DWN_STRM_PORT_TYPE_TMDS (2 1) +# define DP_DWN_STRM_PORT_TYPE_OTHER(3 1) +# define DP_FORMAT_CONVERSION (1 3) +# define DP_DETAILED_CAP_INFO_AVAILABLE(1 4) /* DPI */ + +#define DP_MAIN_LINK_CHANNEL_CODING 0x006 + +#define DP_DOWN_STREAM_PORT_COUNT 0x007 +# define DP_PORT_COUNT_MASK0x0f +# define DP_MSA_TIMING_PAR_IGNORED (1 6) /* eDP */ +# define DP_OUI_SUPPORT(1 7) + +#define DP_I2C_SPEED_CAP 0x00c/* DPI */ +# define DP_I2C_SPEED_1K 0x01 +# define DP_I2C_SPEED_5K 0x02 +# define DP_I2C_SPEED_10K 0x04 +# define DP_I2C_SPEED_100K 0x08 +# define DP_I2C_SPEED_400K 0x10 +# define DP_I2C_SPEED_1M 0x20 + +#define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ + +/* Multiple stream transport */ +#define DP_FAUX_CAP0x020 /* 1.2 */ +# define DP_FAUX_CAP_1 (1 0) + +#define DP_MSTM_CAP0x021 /* 1.2 */ +# define DP_MST_CAP(1 0)
[U-Boot] [PATCH 08/25] tegra: Provide a function to allow LCD PMIC setup
Some LCDs require a PMIC to be set up - add a function for this.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/include/asm/arch-tegra/sys_proto.h | 8
board/nvidia/common/board.c | 10 ++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/include/asm/arch-tegra/sys_proto.h
b/arch/arm/include/asm/arch-tegra/sys_proto.h
index 914d8b9..83f9f47 100644
--- a/arch/arm/include/asm/arch-tegra/sys_proto.h
+++ b/arch/arm/include/asm/arch-tegra/sys_proto.h
@@ -17,4 +17,12 @@ void invalidate_dcache(void);
*/
int tegra_board_id(void);
+/**
+ * tegra_lcd_pmic_init() - Set up the PMIC for a board
+ *
+ * @board_id: Board ID which may be used to select LCD type
+ * @return 0 if OK, -ve on error
+ */
+int tegra_lcd_pmic_init(int board_id);
+
#endif
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 2ee9b6d..0a33bc5 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -99,6 +99,11 @@ int checkboard(void)
}
#endif /* CONFIG_DISPLAY_BOARDINFO */
+__weak int tegra_lcd_pmic_init(int board_it)
+{
+ return 0;
+}
+
/*
* Routine: board_init
* Description: Early hardware init.
@@ -106,6 +111,7 @@ int checkboard(void)
int board_init(void)
{
__maybe_unused int err;
+ __maybe_unused int board_id;
/* Do clocks and UART first so that printf() works */
clock_init();
@@ -146,6 +152,10 @@ int board_init(void)
#endif
#ifdef CONFIG_LCD
+ board_id = tegra_board_id();
+ err = tegra_lcd_pmic_init(board_id);
+ if (err)
+ return err;
tegra_lcd_check_next_stage(gd-fdt_blob, 0);
#endif
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/25] tegra: Add a board ID function
Add a way of displaying a numeric board ID on start-up.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/include/asm/arch-tegra/sys_proto.h | 11 ++-
board/nvidia/common/board.c | 12 +++-
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/sys_proto.h
b/arch/arm/include/asm/arch-tegra/sys_proto.h
index 8b3fbe1..914d8b9 100644
--- a/arch/arm/include/asm/arch-tegra/sys_proto.h
+++ b/arch/arm/include/asm/arch-tegra/sys_proto.h
@@ -8,12 +8,13 @@
#ifndef _SYS_PROTO_H_
#define _SYS_PROTO_H_
-struct tegra_sysinfo {
- char *board_string;
-};
-
void invalidate_dcache(void);
-extern const struct tegra_sysinfo sysinfo;
+/**
+ * tegra_board_id() - Get the board iD
+ *
+ * @return a board ID, or -ve on error
+ */
+int tegra_board_id(void);
#endif
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 128b5fb..2ee9b6d 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -80,10 +80,20 @@ static void power_det_init(void)
#endif
}
+__weak int tegra_board_id(void)
+{
+ return -1;
+}
+
#ifdef CONFIG_DISPLAY_BOARDINFO
int checkboard(void)
{
- printf(Board: %s\n, CONFIG_TEGRA_BOARD_STRING);
+ int board_id = tegra_board_id();
+
+ printf(Board: %s, CONFIG_TEGRA_BOARD_STRING);
+ if (board_id != -1)
+ printf(, ID: %d\n, board_id);
+ printf(\n);
return 0;
}
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/25] power: Export register access functions from as3722
With the full PMIC framework we may be able to avoid this. But for now
we need access to the PMIC.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/power/as3722.c | 16 +---
include/power/as3722.h | 3 +++
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/power/as3722.c b/drivers/power/as3722.c
index 1a6ebcc..7b82717 100644
--- a/drivers/power/as3722.c
+++ b/drivers/power/as3722.c
@@ -27,7 +27,7 @@
#define AS3722_DEVICE_ID 0x0c
#define AS3722_ASIC_ID2 0x91
-static int as3722_read(struct udevice *pmic, u8 reg, u8 *value)
+int as3722_read(struct udevice *pmic, u8 reg, u8 *value)
{
int err;
@@ -38,7 +38,7 @@ static int as3722_read(struct udevice *pmic, u8 reg, u8
*value)
return 0;
}
-static int as3722_write(struct udevice *pmic, u8 reg, u8 value)
+int as3722_write(struct udevice *pmic, u8 reg, u8 value)
{
int err;
@@ -234,6 +234,15 @@ int as3722_gpio_direction_output(struct udevice *pmic,
unsigned int gpio,
return 0;
}
+/* Temporary function until we get the pmic framework */
+int as3722_get(struct udevice **devp)
+{
+ int bus = 0;
+ int address = 0x40;
+
+ return i2c_get_chip_for_busnum(bus, address, devp);
+}
+
int as3722_init(struct udevice **devp)
{
struct udevice *pmic;
@@ -258,7 +267,8 @@ int as3722_init(struct udevice **devp)
debug(AS3722 revision %#x found on I2C bus %u, address %#x\n,
revision, bus, address);
- *devp = pmic;
+ if (devp)
+ *devp = pmic;
return 0;
}
diff --git a/include/power/as3722.h b/include/power/as3722.h
index aa966d2..0f22482 100644
--- a/include/power/as3722.h
+++ b/include/power/as3722.h
@@ -23,5 +23,8 @@ int as3722_gpio_configure(struct udevice *pmic, unsigned int
gpio,
unsigned long flags);
int as3722_gpio_direction_output(struct udevice *pmic, unsigned int gpio,
unsigned int level);
+int as3722_read(struct udevice *pmic, u8 reg, u8 *value);
+int as3722_write(struct udevice *pmic, u8 reg, u8 value);
+int as3722_get(struct udevice **devp);
#endif /* __POWER_AS3722_H__ */
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/25] tegra: Move the pww into tegra-common
This is needed for tegra124 also, so make it common and add a header file
for tegra124.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/tegra-common/Makefile | 1 +
arch/arm/cpu/armv7/{tegra20 = tegra-common}/pwm.c | 0
arch/arm/cpu/armv7/tegra20/Makefile| 1 -
arch/arm/include/asm/arch-tegra/pwm.h | 60 ++
arch/arm/include/asm/arch-tegra124/pwm.h | 14 +
arch/arm/include/asm/arch-tegra20/pwm.h| 54 ++-
6 files changed, 79 insertions(+), 51 deletions(-)
rename arch/arm/cpu/armv7/{tegra20 = tegra-common}/pwm.c (100%)
create mode 100644 arch/arm/include/asm/arch-tegra/pwm.h
create mode 100644 arch/arm/include/asm/arch-tegra124/pwm.h
diff --git a/arch/arm/cpu/armv7/tegra-common/Makefile
b/arch/arm/cpu/armv7/tegra-common/Makefile
index 463c260..91feb81 100644
--- a/arch/arm/cpu/armv7/tegra-common/Makefile
+++ b/arch/arm/cpu/armv7/tegra-common/Makefile
@@ -8,3 +8,4 @@
#
obj-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o
+obj-$(CONFIG_PWM_TEGRA) += pwm.o
diff --git a/arch/arm/cpu/armv7/tegra20/pwm.c
b/arch/arm/cpu/armv7/tegra-common/pwm.c
similarity index 100%
rename from arch/arm/cpu/armv7/tegra20/pwm.c
rename to arch/arm/cpu/armv7/tegra-common/pwm.c
diff --git a/arch/arm/cpu/armv7/tegra20/Makefile
b/arch/arm/cpu/armv7/tegra20/Makefile
index 9b4295c..56e54d0 100644
--- a/arch/arm/cpu/armv7/tegra20/Makefile
+++ b/arch/arm/cpu/armv7/tegra20/Makefile
@@ -7,5 +7,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-$(CONFIG_PWM_TEGRA) += pwm.o
obj-$(CONFIG_VIDEO_TEGRA) += display.o
diff --git a/arch/arm/include/asm/arch-tegra/pwm.h
b/arch/arm/include/asm/arch-tegra/pwm.h
new file mode 100644
index 000..8e7397d
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/pwm.h
@@ -0,0 +1,60 @@
+/*
+ * Tegra pulse width frequency modulator definitions
+ *
+ * Copyright (c) 2011 The Chromium OS Authors.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_TEGRA_PWM_H
+#define __ASM_ARCH_TEGRA_PWM_H
+
+/* This is a single PWM channel */
+struct pwm_ctlr {
+ uint control; /* Control register */
+ uint reserved[3]; /* Space space */
+};
+
+#define PWM_NUM_CHANNELS 4
+
+/* PWM_CONTROLLER_PWM_CSR_0/1/2/3_0 */
+#define PWM_ENABLE_SHIFT 31
+#define PWM_ENABLE_MASK(0x1 PWM_ENABLE_SHIFT)
+
+#define PWM_WIDTH_SHIFT16
+#define PWM_WIDTH_MASK (0x7FFF PWM_WIDTH_SHIFT)
+
+#define PWM_DIVIDER_SHIFT 0
+#define PWM_DIVIDER_MASK (0x1FFF PWM_DIVIDER_SHIFT)
+
+/**
+ * Program the PWM with the given parameters.
+ *
+ * @param channel PWM channel to update
+ * @param rate Clock rate to use for PWM
+ * @param pulse_width high pulse width: 0=always low, 1=1/256 pulse high,
+ * n = n/256 pulse high
+ * @param freq_divider frequency divider value (1 to use rate as is)
+ */
+void pwm_enable(unsigned channel, int rate, int pulse_width, int freq_divider);
+
+/**
+ * Request a pwm channel as referenced by a device tree node.
+ *
+ * This channel can then be passed to pwm_enable().
+ *
+ * @param blob Device tree blob
+ * @param node Node containing reference to pwm
+ * @param prop_nameProperty name of pwm reference
+ * @return channel number, if ok, else -1
+ */
+int pwm_request(const void *blob, int node, const char *prop_name);
+
+/**
+ * Set up the pwm controller, by looking it up in the fdt.
+ *
+ * @return 0 if ok, -1 if the device tree node was not found or invalid.
+ */
+int pwm_init(const void *blob);
+
+#endif /* __ASM_ARCH_TEGRA_PWM_H */
diff --git a/arch/arm/include/asm/arch-tegra124/pwm.h
b/arch/arm/include/asm/arch-tegra124/pwm.h
new file mode 100644
index 000..3d2c432
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra124/pwm.h
@@ -0,0 +1,14 @@
+/*
+ * Tegra pulse width frequency modulator definitions
+ *
+ * Copyright (c) 2011 The Chromium OS Authors.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_TEGRA124_PWM_H
+#define __ASM_ARCH_TEGRA124_PWM_H
+
+#include asm/arch-tegra/pwm.h
+
+#endif /* __ASM_ARCH_TEGRA124_PWM_H */
diff --git a/arch/arm/include/asm/arch-tegra20/pwm.h
b/arch/arm/include/asm/arch-tegra20/pwm.h
index 8e7397d..2207d9c 100644
--- a/arch/arm/include/asm/arch-tegra20/pwm.h
+++ b/arch/arm/include/asm/arch-tegra20/pwm.h
@@ -6,55 +6,9 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#ifndef __ASM_ARCH_TEGRA_PWM_H
-#define __ASM_ARCH_TEGRA_PWM_H
+#ifndef __ASM_ARCH_TEGRA20_PWM_H
+#define __ASM_ARCH_TEGRA20_PWM_H
-/* This is a single PWM channel */
-struct pwm_ctlr {
- uint control; /* Control register */
- uint reserved[3]; /* Space space */
-};
+#include asm/arch-tegra/pwm.h
-#define PWM_NUM_CHANNELS 4
-
-/* PWM_CONTROLLER_PWM_CSR_0/1/2/3_0 */
-#define PWM_ENABLE_SHIFT 31
-#define PWM_ENABLE_MASK(0x1 PWM_ENABLE_SHIFT)
-
-#define PWM_WIDTH_SHIFT16
[U-Boot] [PATCH 09/25] tegra: Add support for setting up a as3722 PMIC
Add support for this PMIC which is used on some Tegra124 boards. Signed-off-by: Simon Glass s...@chromium.org --- board/nvidia/common/board.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c index 0a33bc5..18e1709 100644 --- a/board/nvidia/common/board.c +++ b/board/nvidia/common/board.c @@ -7,6 +7,7 @@ #include common.h #include dm.h +#include errno.h #include ns16550.h #include linux/compiler.h #include asm/io.h @@ -39,6 +40,7 @@ #include asm/arch-tegra/mmc.h #endif #include asm/arch-tegra/xusb-padctl.h +#include power/as3722.h #include i2c.h #include spi.h #include emc.h @@ -144,6 +146,11 @@ int board_init(void) debug(Memory controller init failed: %d\n, err); # endif # endif /* CONFIG_TEGRA_PMU */ +#ifdef CONFIG_AS3722_POWER + err = as3722_init(NULL); + if (err err != -ENODEV) + return err; +#endif #endif /* CONFIG_SYS_I2C_TEGRA */ #ifdef CONFIG_USB_EHCI_TEGRA -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/25] tegra: Move checkboard() into the board code
This is only used by Nvidia boards, so move it into nvidia/common to
simplify things.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/tegra-common/board.c | 8
board/nvidia/common/board.c | 13 +
2 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/arm/cpu/tegra-common/board.c
b/arch/arm/cpu/tegra-common/board.c
index b6a84a5..67ee8c4 100644
--- a/arch/arm/cpu/tegra-common/board.c
+++ b/arch/arm/cpu/tegra-common/board.c
@@ -58,14 +58,6 @@ int dram_init(void)
return 0;
}
-#ifdef CONFIG_DISPLAY_BOARDINFO
-int checkboard(void)
-{
- printf(Board: %s\n, sysinfo.board_string);
- return 0;
-}
-#endif /* CONFIG_DISPLAY_BOARDINFO */
-
static int uart_configs[] = {
#if defined(CONFIG_TEGRA20)
#if defined(CONFIG_TEGRA_UARTA_UAA_UAB)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 80ef8fd..128b5fb 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -52,10 +52,6 @@ U_BOOT_DEVICE(tegra_gpios) = {
};
#endif
-const struct tegra_sysinfo sysinfo = {
- CONFIG_TEGRA_BOARD_STRING
-};
-
__weak void pinmux_init(void) {}
__weak void pin_mux_usb(void) {}
__weak void pin_mux_spi(void) {}
@@ -84,6 +80,15 @@ static void power_det_init(void)
#endif
}
+#ifdef CONFIG_DISPLAY_BOARDINFO
+int checkboard(void)
+{
+ printf(Board: %s\n, CONFIG_TEGRA_BOARD_STRING);
+
+ return 0;
+}
+#endif /* CONFIG_DISPLAY_BOARDINFO */
+
/*
* Routine: board_init
* Description: Early hardware init.
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/25] tegra: pwm: Allow the clock rate to be left as is
When enabling a PWM, allow the existing clock rate and source to stand
unchanged.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/tegra-common/pwm.c | 5 -
arch/arm/include/asm/arch-tegra/pwm.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra-common/pwm.c
b/arch/arm/cpu/armv7/tegra-common/pwm.c
index 5b88636..06a0f86 100644
--- a/arch/arm/cpu/armv7/tegra-common/pwm.c
+++ b/arch/arm/cpu/armv7/tegra-common/pwm.c
@@ -24,7 +24,10 @@ void pwm_enable(unsigned channel, int rate, int pulse_width,
int freq_divider)
assert(channel PWM_NUM_CHANNELS);
/* TODO: Can we use clock_adjust_periph_pll_div() here? */
- clock_start_periph_pll(PERIPH_ID_PWM, CLOCK_ID_SFROM32KHZ, rate);
+ if (rate) {
+ clock_start_periph_pll(PERIPH_ID_PWM, CLOCK_ID_SFROM32KHZ,
+ rate);
+ }
reg = PWM_ENABLE_MASK;
reg |= pulse_width PWM_WIDTH_SHIFT;
diff --git a/arch/arm/include/asm/arch-tegra/pwm.h
b/arch/arm/include/asm/arch-tegra/pwm.h
index 8e7397d..92dced4 100644
--- a/arch/arm/include/asm/arch-tegra/pwm.h
+++ b/arch/arm/include/asm/arch-tegra/pwm.h
@@ -31,7 +31,7 @@ struct pwm_ctlr {
* Program the PWM with the given parameters.
*
* @param channel PWM channel to update
- * @param rate Clock rate to use for PWM
+ * @param rate Clock rate to use for PWM, or 0 to leave alone
* @param pulse_width high pulse width: 0=always low, 1=1/256 pulse high,
* n = n/256 pulse high
* @param freq_divider frequency divider value (1 to use rate as is)
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/25] fdt: Add binding decode function for display-timings
This is useful for display parameters. Add a simple decode function to read
from this device tree node.
Signed-off-by: Simon Glass s...@chromium.org
---
doc/device-tree-bindings/video/display-timing.txt | 110 ++
include/fdtdec.h | 80
lib/fdtdec.c | 92 ++
3 files changed, 282 insertions(+)
create mode 100644 doc/device-tree-bindings/video/display-timing.txt
diff --git a/doc/device-tree-bindings/video/display-timing.txt
b/doc/device-tree-bindings/video/display-timing.txt
new file mode 100644
index 000..e1d4a0b
--- /dev/null
+++ b/doc/device-tree-bindings/video/display-timing.txt
@@ -0,0 +1,110 @@
+display-timing bindings
+===
+
+display-timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+ provided. When omitted, assume the first node is the native.
+
+timing subnode
+--
+
+required properties:
+ - hactive, vactive: display resolution
+ - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: vertical display timing parameters in
+ lines
+ - clock-frequency: display clock in Hz
+
+optional properties:
+ - hsync-active: hsync pulse is active low/high/ignored
+ - vsync-active: vsync pulse is active low/high/ignored
+ - de-active: data-enable pulse is active low/high/ignored
+ - pixelclk-active: with
+ - active high = drive pixel data on rising edge/
+ sample data on falling edge
+ - active low = drive pixel data on falling edge/
+ sample data on rising edge
+ - ignored = ignored
+ - interlaced (bool): boolean to enable interlaced mode
+ - doublescan (bool): boolean to enable doublescan mode
+ - doubleclk (bool): boolean to enable doubleclock mode
+
+All the optional properties that are not bool follow the following logic:
+1: high active
+0: low active
+omitted: not used on hardware
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+ +--+-+--+---+
+ | |↑| | |
+ | ||vback_porch | | |
+ | |↓| | |
+ +--###--+---+
+ | #↑# | |
+ | #|# | |
+ | hback #|# hfront | hsync |
+ | porch #| hactive # porch | len |
+ |#---+---#|-|
+ | #|# | |
+ | #|vactive # | |
+ | #|# | |
+ | #↓# | |
+ +--###--+---+
+ | |↑| | |
+ | ||vfront_porch| | |
+ | |↓| | |
+ +--+-+--+---+
+ | |↑| | |
+ | ||vsync_len | | |
+ | |↓| | |
+ +--+-+--+---+
+
+Example:
+
+ display-timings {
+ native-mode = timing0;
+ timing0: 1080p24 {
+ /* 1920x1080p24 */
+ clock-frequency = 5200;
+ hactive = 1920;
+ vactive = 1080;
+ hfront-porch = 25;
+ hback-porch = 25;
+ hsync-len = 25;
+ vback-porch = 2;
+ vfront-porch = 2;
+ vsync-len = 2;
+ hsync-active = 1;
+ };
+ };
+
+Every required property also supports the use of ranges, so the commonly used
+datasheet description with minimum, typical and maximum values can be used.
+
+Example:
+
+
