Re: [U-Boot] [PATCH] arm: socfpga: Add I2C support to SoCFPGA
Hello Marek, Am 20.10.2014 16:46, schrieb Marek Vasut: On Monday, October 20, 2014 at 08:45:48 AM, Stefan Roese wrote: Hi all, This patch adds I2C support for the SoCFPGA. Using the designware I2C controller driver. It supports all 4 I2C busses on the SoCFPGA. Signed-off-by: Stefan Roeses...@denx.de Cc: Marek Vasutma...@denx.de Cc: Vince Bridersvbrid...@altera.com Cc: Chin Liang Seecl...@altera.com Cc: Dinh Nguyendingu...@altera.com +CC Heiko, the I2C custodian. Thanks! As I am just not really find time to work, I do not look into the u-boot ML ... --- include/configs/socfpga_common.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 49504dc..ba1e072 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -157,6 +157,28 @@ #define CONFIG_BAUDRATE 115200 /* + * I2C support + */ +#define CONFIG_HARD_I2C No ... do not add this define please. +#define CONFIG_DW_I2C +#define CONFIG_I2C_MULTI_BUS I presume this should be converted to CONFIG_SYS_I2C framework instead of using this I2C multibus horror, no? ... Yes, please! Which i2c driver does socfpga use? If it is the drivers/i2c/designware_i2c.c driver, please convert it to the CONFIG_SYS_I2C framework. You may also take a look into Simons RFC patches, which introduce DM model: http://lists.denx.de/pipermail/u-boot/2014-October/191497.html bye, Heiko +#define CONFIG_SYS_I2C_BUS_MAX 4 +#define CONFIG_SYS_I2C_BASESOCFPGA_I2C0_ADDRESS +#define CONFIG_SYS_I2C_BASE1 SOCFPGA_I2C1_ADDRESS +#define CONFIG_SYS_I2C_BASE2 SOCFPGA_I2C2_ADDRESS +#define CONFIG_SYS_I2C_BASE3 SOCFPGA_I2C3_ADDRESS +/* using standard mode which the speed up to 100Kb/s */ +#define CONFIG_SYS_I2C_SPEED 10 +/* address of device when used as slave */ +#define CONFIG_SYS_I2C_SLAVE 0x02 +#ifndef __ASSEMBLY__ +/* clock supplied to I2C controller in unit of MHz */ +unsigned int cm_get_l4_sp_clk_hz(void); Include clock_manager.h instead maybe ? +#define IC_CLK (cm_get_l4_sp_clk_hz() / 100) +#endif +#define CONFIG_CMD_I2C + +/* * U-Boot environment */ #define CONFIG_SYS_CONSOLE_IS_IN_ENV Best regards, Marek Vasut -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: clear VENDOR variable to fix build error on tcsh
Thanks Masahiro, On 21-10-14 06:18, Masahiro Yamada wrote: Since the environment VENDOR is set in tcsh, it must be cleared in our makefile. Otherwise, boards without CONFIG_SYS_VENDOR fail to build: make CROSS_COMPILE=arm-linux-gnueabi- wandboard_quad_defconfig all [ snip ] AR arch/arm/lib/lib.a CC arch/arm/lib/eabi_compat.o scripts/Makefile.build:55: /home/foo/u-boot/board/unknown/wandboard/ \ Makefile: No such file or directory make[2]: *** No rule to make target `/home/foo/u-boot/board/unknown/ \ wandboard/Makefile'. Stop. make[1]: *** [board/unknown/wandboard] Error 2 make: *** [__build_one_by_one] Error 2 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reported-by: Tom Everett t...@khubla.com Reported-by: Jeroen Hofstee jer...@myspectrum.nl --- config.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.mk b/config.mk index 2157537..00805bd 100644 --- a/config.mk +++ b/config.mk @@ -18,6 +18,8 @@ PLATFORM_LDFLAGS := LDFLAGS := LDFLAGS_FINAL := OBJCOPYFLAGS := +# clear VENDOR for tcsh +VENDOR := # ARCH := $(CONFIG_SYS_ARCH:%=%) ah, understood now. Make does suck in the complete env as make variables but assignments will overwrite the value. make VENDOR=bla would ignore the assignment unless overridden. The ifneq below causes the VENDOR never to be assigned in some cases and hence the value from the original env is used. So Acked-by: Jeroen Hofstee jer...@myspectrum.nl Tested-by: Jeroen Hofstee jer...@myspectrum.nl Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fix get_ram_size memory corruption
base[0] is saved, but never restored.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
common/memsize.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/memsize.c b/common/memsize.c
index 589400d..8bda2ba 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -48,7 +48,9 @@ long get_ram_size(long *base, long maxsize)
*addr = 0;
sync ();
- if ((val = *addr) != 0) {
+ val = *addr;
+ *addr = save[i];
+ if ((val = 0) != 0) {
/* Restore the original data before leaving the function.
*/
sync ();
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM: prevent compiler warnings from bootm.c
Hi Eric, On 01/10/2014 00:40, Eric Nelson wrote: 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/4] ARM: i.MX: provide declaration for board_spi_cs_gpio
On 01/10/2014 00:40, Eric Nelson wrote: Provide a public declaration of the board_spi_cs_gpio() callback for i.MX SPI chip selects to prevent the warning Should it be static? when compiling with make C=1. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.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 4/4] ARM: i.MX video: declare displays and display_count publicly
On 01/10/2014 00:40, Eric Nelson wrote: Declare displays[] and display_count in imx-common/video.h to prevent Should it be static? messages when compiling board files with make C=1. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.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/4] ARM: i.MX6: include prototype for get_board_rev()
On 01/10/2014 00:40, Eric Nelson wrote: Include asm/bootm.h to see the prototype for get_board_rev() and prevent warning Should it be static? with make C=1. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.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
[U-Boot] [PATCH] ls1021aqds: add hwconfig setting to do pin mux
The Freescale LS1021AQDS share some pins, so Add the hwconfig option
that allows the user to choose which the function he wants.
The main pin mux IP is:
eSDHC, SAI, IIC2, RGMII, CAN, SAI.
Signed-off-by: Yuan Yao yao.y...@freescale.com
---
board/freescale/ls1021aqds/ls1021aqds.c | 67 -
include/configs/ls1021aqds.h| 1 +
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index 12e83f7..9229151 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -10,6 +10,7 @@
#include asm/arch/immap_ls102xa.h
#include asm/arch/clock.h
#include asm/arch/fsl_serdes.h
+#include hwconfig.h
#include mmc.h
#include fsl_esdhc.h
#include fsl_ifc.h
@@ -20,6 +21,11 @@
DECLARE_GLOBAL_DATA_PTR;
enum {
+ MUX_TYPE_CAN,
+ MUX_TYPE_IIC2,
+ MUX_TYPE_RGMII,
+ MUX_TYPE_SAI,
+ MUX_TYPE_SDHC,
MUX_TYPE_SD_PCI4,
MUX_TYPE_SD_PC_SA_SG_SG,
MUX_TYPE_SD_PC_SA_PC_SG,
@@ -157,11 +163,27 @@ int board_early_init_f(void)
int config_board_mux(int ctrl_type)
{
- u8 reg12;
+ u8 reg12, reg14;
reg12 = QIXIS_READ(brdcfg[12]);
+ reg14 = QIXIS_READ(brdcfg[14]);
switch (ctrl_type) {
+ case MUX_TYPE_CAN:
+ reg14 = (reg14 0xf0) | 0x03;
+ break;
+ case MUX_TYPE_IIC2:
+ reg14 = (reg14 0x0f) | 0xa0;
+ break;
+ case MUX_TYPE_RGMII:
+ reg14 = (reg14 0xf0) | 0x0;
+ break;
+ case MUX_TYPE_SAI:
+ reg14 = (reg14 0xf0) | 0x0c;
+ break;
+ case MUX_TYPE_SDHC:
+ reg14 = (reg14 0x0f) | 0x0;
+ break;
case MUX_TYPE_SD_PCI4:
reg12 = 0x38;
break;
@@ -180,6 +202,7 @@ int config_board_mux(int ctrl_type)
}
QIXIS_WRITE(brdcfg[12], reg12);
+ QIXIS_WRITE(brdcfg[14], reg14);
return 0;
}
@@ -213,6 +236,48 @@ int config_serdes_mux(void)
return 0;
}
+int misc_init_r(void)
+{
+ int conflict_flag;
+
+ /* some signals can not enable simultaneous*/
+ conflict_flag = 0;
+ if (hwconfig(sdhc))
+ conflict_flag++;
+ if (hwconfig(iic2))
+ conflict_flag++;
+ if (conflict_flag 1) {
+ printf(WARNING: pin conflict !\n);
+ return 0;
+ }
+
+ conflict_flag = 0;
+ if (hwconfig(rgmii))
+ conflict_flag++;
+ if (hwconfig(can))
+ conflict_flag++;
+ if (hwconfig(sai))
+ conflict_flag++;
+ if (conflict_flag 1) {
+ printf(WARNING: pin conflict !\n);
+ return 0;
+ }
+
+ if (hwconfig(can))
+ config_board_mux(MUX_TYPE_CAN);
+ else if (hwconfig(rgmii))
+ config_board_mux(MUX_TYPE_RGMII);
+ else if (hwconfig(sai))
+ config_board_mux(MUX_TYPE_SAI);
+
+ if (hwconfig(iic2))
+ config_board_mux(MUX_TYPE_IIC2);
+ else if (hwconfig(sdhc))
+ config_board_mux(MUX_TYPE_SDHC);
+
+ return 0;
+}
+
int board_init(void)
{
struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index bb47813..acb2aed 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -326,6 +326,7 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_CMDLINE_EDITING
#define CONFIG_CMD_IMLS
+#define CONFIG_MISC_INIT_R
#define CONFIG_HWCONFIG
#define HWCONFIG_BUFFER_SIZE 128
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/1] ls1021aqds: add hwconfig setting to do pin mux
Added in v1: - Add pin mux support for ls1021aqds. Test log: U-Boot 2014.07-01993-g052b512-dirty (Oct 20 2014 - 19:58:20) CPU: Freescale LayerScape LS1020E, Version: 1.0, (0x87081010) Clock Configuration: CPU0(ARMV7):1000 MHz, Bus:300 MHz, DDR:800 MHz (1600 MT/s data rate), Reset Configuration Word (RCW): : 0608000a 0010: 6000 00407900 e0025a00 21046000 0020: 00038000 0030: 001b7200 Board: LS1021AQDS vBank: 4 Sys ID:0x2b, Sys Ver: 0x11 FPGA: v13 (QIXIS_LS1021QDS_2014_08_27_1658), build 65386 I2C: ready DRAM: Initializing DDRusing SPD Detected UDIMM 18KSF51272AZ-1G6K1 2 GiB (DDR3, 32-bit, CL=11, ECC off) Using SERDES1 Protocol: 96 (0x60) Flash: 128 MiB NAND: 0 MiB MMC: FSL_SDHC: 0 In:serial Out: serial Err: serial Net: eTSEC1 is in sgmii mode eTSEC2 is in sgmii mode Phy not found PHY reset timed out Phy not found PHY reset timed out eTSEC1, eTSEC2, eTSEC3 [PRIME] = pri baudrate=115200 boot=dhcp 8200 r66431/ls1/uImage.ls1021a; tftp 8f00 r66431/ls1/ls1021a-qds.dtb; tftp 8800 r66431/ls1/fsl-image-x11-ls1021aqds-20140424073555.rootfs.ext2.gz.u-boot ; bootm 8200 8800 8f00 boot_bank0=i2c mw 0x66 0x50 0x40;i2c mw 0x66 0x10 0x20;i2c mw 0x66 0x10 0x21 boot_bank4=i2c mw 0x66 0x50 0x44;i2c mw 0x66 0x10 0x20;i2c mw 0x66 0x10 0x21 bootargs=root=/dev/ram0 rw console=ttyS0,115200 bootdelay=3 eth1addr=00:04:9f:03:2e:c5 eth2addr=00:04:9f:03:2e:c6 eth3addr=00:04:9f:03:2e:c7 eth4addr=00:04:9f:03:2e:c8 eth5addr=00:04:9f:03:2e:c9 eth6addr=00:04:9f:03:2e:ca ethact=eTSEC3 ethaddr=00:04:9f:03:2e:c4 ethprime=eTSEC3 fdt_high=0x hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=null,ecc=off initrd_high=0x ipaddr=192.168.1.121 loadaddr=0x8200 scsidevs=0 serverip=192.168.1.1 stderr=serial stdin=serial stdout=serial zhuoboot=tftp 8200 b46552/ls1021aqds/uImage.ls1021a; tftp 8f00 b46552/ls1021aqds/ls1021a-qds.dtb;tftp 8800 b46552/ls1021aqds/ramdisk.small;bootm 8200 8800 8f00 Environment size: 1117/8188 bytes = i2c md 0x66 0x5e 005e: 00 00 12 81 f7 ff ff ff ff ef e7 00 3f ff ff ff?... = set hwconfig fsl_ddr:ctlr_intlv=null,bank_intlv=null,ecc=off;sai = save Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... 987654321987654321done Protected 1 sectors = run boot_bank4 U-Boot 2014.07-01993-g052b512-dirty (Oct 20 2014 - 19:58:20) CPU: Freescale LayerScape LS1020E, Version: 1.0, (0x87081010) Clock Configuration: CPU0(ARMV7):1000 MHz, Bus:300 MHz, DDR:800 MHz (1600 MT/s data rate), Reset Configuration Word (RCW): : 0608000a 0010: 6000 00407900 e0025a00 21046000 0020: 00038000 0030: 001b7200 Board: LS1021AQDS vBank: 4 Sys ID:0x2b, Sys Ver: 0x11 FPGA: v13 (QIXIS_LS1021QDS_2014_08_27_1658), build 65386 I2C: ready DRAM: Initializing DDRusing SPD Detected UDIMM 18KSF51272AZ-1G6K1 2 GiB (DDR3, 32-bit, CL=11, ECC off) Using SERDES1 Protocol: 96 (0x60) Flash: 128 MiB NAND: 0 MiB MMC: FSL_SDHC: 0 In:serial Out: serial Err: serial Net: eTSEC1 is in sgmii mode eTSEC2 is in sgmii mode Phy not found PHY reset timed out Phy not found PHY reset timed out eTSEC1, eTSEC2, eTSEC3 [PRIME] = i2c md 0x66 0x5e 005e: 0c 00 12 81 f7 ff ff ff ff ef e7 00 3f ff ff ff?... = [b46683@rhuath ~]$ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix get_ram_size memory corruption
Dear Gerd,
In message 1413874945-16560-1-git-send-email-kra...@redhat.com you wrote:
base[0] is saved, but never restored.
Patches for this have been submitted before, but were rejected. You
may want to dig the archives for these.
What exactly is your test case where you see any memory corruption?
- if ((val = *addr) != 0) {
+ val = *addr;
+ *addr = save[i];
+ if ((val = 0) != 0) {
^^
This code looks pretty much wrong to me; the condition 0 != 0 can
never become true...
NAK.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Presidency: The greased pig in the field game of American politics.
- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: imx: i2c: Use gpio_request() to request GPIOs
Hi Simon, I'm sorry for that late reply, I've had email problems during the conference... Finally, I have the email working again and going through the stuff... I guess, it is better late than never.. On 10/14/14 10:25, Simon Glass wrote: Hi Stefan, On 3 October 2014 08:39, Igor Grinberg grinb...@compulab.co.il wrote: On 10/02/14 17:17, Nikita Kiryanov wrote: From: Simon Glass s...@chromium.org GPIOs should be requested before use. Without this, driver model will not permit the GPIO to be used. Cc: Igor Grinberg grinb...@compulab.co.il Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Nikita Kiryanov nik...@compulab.co.il I like the small functionality oriented changes much more. Acked-by: Igor Grinberg grinb...@compulab.co.il I plan to pull these two patches from Nikita into u-boot-dm along with my other IMX and DM patches. It needs to come after SPI and there are about 8 series in the line. Is that OK with you? Yep, this is fine. Thanks! -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] dm: Should U-Boot driver model abandon platform data?
Hi, On 10/14/14 07:50, Simon Glass wrote: Hi, This question came up at the U-Boot mini-summit yesterday and I was tasked with starting a thread on the mailing list. There seemed to be a strong feeling in the room that permitting platform data in driver model is a mistake. Reasons mentioned were: - device tree is how things are done in Linux at least for most platforms we support What about non-DT architectures? Also, what about boards that do not intend to use Linux? Should we force them to also use DT? - we can therefore import this directly in from Linux rather than writing new platform data What about corner cases where some driver gets added for U-Boot, but does not exist in Linux and that will have bindings problem as those could be problematic from Linux DT stable ABI POV. - platform data is considered 'legacy' and we should not support legacy features in a new framework - device tree permits fully abstracting the device data from the code, avoiding #ifdefs Yet there are cases where board specific code should run before/during/after driver initialization and that is something DT cannot provide. - it is easier to change settings in device tree than in platform data That statement, I actually, do not completely agree with. The main impact is that all boards would need at least some sort of device tree when they move to driver model. There is also the question of SPL, where we are sometimes space-constrained. If we go with this policy I wonder if we should permit an exception for things required by SPL for now? Typically in SPL for these space-constrained platforms we only need a few devices so we could provide platform data for SPL while still using device tree in U-Boot It would be possible to enable device tree in SPL for many platforms but that feels like something that should not block progress. So perhaps platform data in SPL should be a separate question. Once we have platform data in SPL, means that drivers should support both, so I don't really see any reason why not also support platform data in regular build. I think that it would be wise to keep the flexibility and let the driver/board maintainer to decide what would be a better choice. Also, since things are not that straight forward today, may be we can support both ways and see how things are (not)working out? and have the same discussion after we have worked/supported/maintained this (or is it a bad choice?). -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] vexpress: qemu can load the fdt to ram base
Check if the fdt is there (happens only when passed via -dtb cmd line
switch to qemu), then setup env accordingly. If present use it.
Otherwise try to load from disk.
Also tweak CONFIG_SYS_LOAD_ADDR and LINUX_BOOT_PARAM_ADDR a bit to
avoid them overriding the fdt.
---
board/armltd/vexpress/vexpress_common.c | 18 ++
include/configs/vexpress_common.h | 9 -
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/board/armltd/vexpress/vexpress_common.c
b/board/armltd/vexpress/vexpress_common.c
index cb2de2f..dafa4b2 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -20,6 +20,7 @@
#include malloc.h
#include errno.h
#include netdev.h
+#include libfdt.h
#include asm/io.h
#include asm/arch/systimer.h
#include asm/arch/sysctrl.h
@@ -60,6 +61,23 @@ int board_init(void)
return 0;
}
+int board_late_init(void)
+{
+ struct fdt_header *fdt = (void*)V2M_BASE;
+
+ if (fdt_magic(fdt) == FDT_MAGIC) {
+ setenv_addr(fdt_addr, (void*)(ulong)V2M_BASE);
+ printf(QEMU: fdt found at %s, using it.\n,
getenv(fdt_addr));
+ } else {
+ setenv_addr(fdt_addr_r, (void*)((ulong)V2M_BASE +
0x27f0));
+ setenv(fdtfile, CONFIG_DEFAULT_FDT_FILE);
+ printf(QEMU: will try to load %s from disk.\n,
+ getenv(fdtfile));
+ }
+
+ return 0;
+}
+
int board_eth_init(bd_t *bis)
{
int rc = 0;
diff --git a/include/configs/vexpress_common.h
b/include/configs/vexpress_common.h
index e378c10..e490804 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -184,8 +184,8 @@
/* Miscellaneous configurable options */
#undef CONFIG_SYS_CLKS_IN_HZ
-#define CONFIG_SYS_LOAD_ADDR (V2M_BASE + 0x8000)
-#define LINUX_BOOT_PARAM_ADDR (V2M_BASE + 0x2000)
+#define CONFIG_SYS_LOAD_ADDR (V2M_BASE + 0x10)
+#define LINUX_BOOT_PARAM_ADDR (V2M_BASE + 0x20)
/* Physical Memory Map */
#define CONFIG_NR_DRAM_BANKS 2
@@ -207,6 +207,8 @@
#include config_distro_defaults.h
#include config_distro_bootcmd.h
+#define CONFIG_BOARD_LATE_INIT
+
/* Basic environment settings */
#define CONFIG_BOOTCOMMAND run bootflash;
#ifdef CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
@@ -215,7 +217,6 @@
kernel_addr_r= 0x80008000\0 \
scriptaddr= 0x87d0\0 \
pxefile_addr_r= 0x87e0\0 \
- fdt_addr_r= 0x87f0\0 \
ramdisk_addr_r= 0x8800\0
#elif defined(CONFIG_VEXPRESS_EXTENDED_MEMORY_MAP)
#define CONFIG_PLATFORM_ENV_SETTINGS \
@@ -223,7 +224,6 @@
kernel_addr_r= 0xa0008000\0 \
scriptaddr= 0xa7d0\0 \
pxefile_addr_r= 0xa7e0\0 \
- fdt_addr_r= 0xa7f0\0 \
ramdisk_addr_r= 0xa800\0
#endif
@@ -235,7 +235,6 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
CONFIG_PLATFORM_ENV_SETTINGS \
console=ttyAMA0,115200n8\0 \
- fdtfile= CONFIG_DEFAULT_FDT_FILE \0 \
BOOTENV
/* FLASH and environment organization */
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README.kconfig: fix typo
Fix typo in defconfig file format description. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Cc: Masahiro Yamada yamad...@jp.panasonic.com --- doc/README.kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.kconfig b/doc/README.kconfig index 3aad5b4..69dc459 100644 --- a/doc/README.kconfig +++ b/doc/README.kconfig @@ -79,7 +79,7 @@ See below for how each configuration target works in U-Boot: ST: - the line is valid for SPL and TPL images +S: - the line is valid for Normal and SPL images +T: - the line is valid for Normal and TPL images - +ST: - the line is valid for Normal, SPL and SPL images + +ST: - the line is valid for Normal, SPL and TPL images So, if neither CONFIG_SPL nor CONFIG_TPL is defined, the defconfig file has no condition: part and therefore has the same form as in Linux. -- 2.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README.kconfig: fix typo
On Tue, 21 Oct 2014 13:27:45 +0300 Igor Grinberg grinb...@compulab.co.il wrote: Fix typo in defconfig file format description. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Cc: Masahiro Yamada yamad...@jp.panasonic.com --- doc/README.kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.kconfig b/doc/README.kconfig index 3aad5b4..69dc459 100644 --- a/doc/README.kconfig +++ b/doc/README.kconfig @@ -79,7 +79,7 @@ See below for how each configuration target works in U-Boot: ST: - the line is valid for SPL and TPL images +S: - the line is valid for Normal and SPL images +T: - the line is valid for Normal and TPL images - +ST: - the line is valid for Normal, SPL and SPL images + +ST: - the line is valid for Normal, SPL and TPL images So, if neither CONFIG_SPL nor CONFIG_TPL is defined, the defconfig file has no condition: part and therefore has the same form as in Linux. -- 2.0.4 Thanks for spotting this! Acked-by: Masahiro Yamada yamad...@jp.panasonic.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fix get_ram_size memory corruption
base[0] is saved, but never restored.
Test case: Start u-boot in qemu, using vexpress-a9 emulation.
qemu places the fdt at the start of ram, as a service for the
guest. Trying to pick it up there by setting fdt_addr
accordingly fails because the fdt magic cookie is gone (zeroed
out) after calling get_ram_size.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
common/memsize.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/memsize.c b/common/memsize.c
index 589400d..ad79ff1 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -48,7 +48,9 @@ long get_ram_size(long *base, long maxsize)
*addr = 0;
sync ();
- if ((val = *addr) != 0) {
+ val = *addr;
+ *addr = save[i];
+ if (val != 0) {
/* Restore the original data before leaving the function.
*/
sync ();
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] vexpress: qemu can load the fdt to ram base
On Di, 2014-10-21 at 12:05 +0200, Gerd Hoffmann wrote:
Check if the fdt is there (happens only when passed via -dtb cmd line
switch to qemu), then setup env accordingly. If present use it.
Otherwise try to load from disk.
Oops, wrong patch, correct one just send.
It shows what I'm doing though to automatically use the qemu fdt:
+int board_late_init(void)
+{
+ struct fdt_header *fdt = (void*)V2M_BASE;
+
+ if (fdt_magic(fdt) == FDT_MAGIC) {
+ setenv_addr(fdt_addr, (void*)(ulong)V2M_BASE);
+ printf(QEMU: fdt found at %s, using it.\n,
getenv(fdt_addr));
+ } else {
+ setenv_addr(fdt_addr_r, (void*)((ulong)V2M_BASE +
0x27f0));
+ setenv(fdtfile, CONFIG_DEFAULT_FDT_FILE);
+ printf(QEMU: will try to load %s from disk.\n,
+getenv(fdtfile));
+ }
+
+ return 0;
+}
[ This one depends on other non-upstream patches so no plans to submit
this upstream atm ]
cheers,
Gerd
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: mx6: add support for TBS2910 Matrix ARM miniPC
Hi Soeren,
On 18/10/2014 13:13, Soeren Moch wrote:
Add initial support for TBS2910 Matrix ARM miniPC.
Support includes MMC, Ethernet, UARTs, HDMI, USB, SATA, PCI, I2C, RTC.
Cc: Stefano Babic sba...@denx.de
Signed-off-by: Soeren Moch sm...@web.de
---
Just a couple of small questions:
arch/arm/Kconfig| 4 +
board/tbs/tbs2910/Kconfig | 23 +++
board/tbs/tbs2910/Makefile | 9 +
board/tbs/tbs2910/tbs2910.c | 420
configs/tbs2910_defconfig | 3 +
include/configs/tbs2910.h | 238 +
6 files changed, 697 insertions(+)
create mode 100644 board/tbs/tbs2910/Kconfig
create mode 100644 board/tbs/tbs2910/Makefile
create mode 100644 board/tbs/tbs2910/tbs2910.c
create mode 100644 configs/tbs2910_defconfig
create mode 100644 include/configs/tbs2910.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 72558b8..cb72381 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -414,6 +414,9 @@ config TARGET_GW_VENTANA
config TARGET_HUMMINGBOARD
bool Support hummingboard
+config TARGET_TBS2910
+ bool Support tbs2910
+
config TARGET_TQMA6
bool TQ Systems TQMa6 board
@@ -682,6 +685,7 @@ source board/sunxi/Kconfig
source board/syteco/jadecpu/Kconfig
source board/syteco/zmx25/Kconfig
source board/taskit/stamp9g20/Kconfig
+source board/tbs/tbs2910/Kconfig
source board/ti/am335x/Kconfig
source board/ti/am43xx/Kconfig
source board/ti/ti814x/Kconfig
diff --git a/board/tbs/tbs2910/Kconfig b/board/tbs/tbs2910/Kconfig
new file mode 100644
index 000..c514e24
--- /dev/null
+++ b/board/tbs/tbs2910/Kconfig
@@ -0,0 +1,23 @@
+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
diff --git a/board/tbs/tbs2910/Makefile b/board/tbs/tbs2910/Makefile
new file mode 100644
index 000..bf5f22b
--- /dev/null
+++ b/board/tbs/tbs2910/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2007, Guennadi Liakhovetski l...@denx.de
+#
+# (C) Copyright 2011 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := tbs2910.o
diff --git a/board/tbs/tbs2910/tbs2910.c b/board/tbs/tbs2910/tbs2910.c
new file mode 100644
index 000..34cfd84
--- /dev/null
+++ b/board/tbs/tbs2910/tbs2910.c
@@ -0,0 +1,420 @@
+/*
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ * Author: Fabio Estevam fabio.este...@freescale.com
+ *
+ * Copyright (C) 2014 Soeren Moch sm...@web.de
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include asm/arch/clock.h
+#include asm/arch/imx-regs.h
+#include asm/arch/iomux.h
+#include asm/arch/mx6-pins.h
+#include asm/errno.h
+#include asm/gpio.h
+#include asm/imx-common/mxc_i2c.h
+#include asm/imx-common/iomux-v3.h
+#include asm/imx-common/sata.h
+#include asm/imx-common/boot_mode.h
+#include asm/imx-common/video.h
+#include mmc.h
+#include fsl_esdhc.h
+#include miiphy.h
+#include netdev.h
+#include asm/arch/mxc_hdmi.h
+#include asm/arch/crm_regs.h
+#include asm/io.h
+#include asm/arch/sys_proto.h
+#include i2c.h
+DECLARE_GLOBAL_DATA_PTR;
+
+#define WEAK_PULLUP (PAD_CTL_PUS_47K_UP | \
+ PAD_CTL_SPEED_LOW | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_SRE_SLOW)
+
+#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP |\
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
+ PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+
+#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \
+ PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
+ PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+
+#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP |\
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
+#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE | PAD_CTL_SRE_FAST)
+
+#define I2C_PAD MUX_PAD_CTRL(I2C_PAD_CTRL)
+
+#ifdef CONFIG_SYS_I2C
+/* I2C1, SGTL5000 */
+static struct i2c_pads_info i2c_pad_info0 = {
+ .scl = {
+ .i2c_mode = MX6_PAD_CSI0_DAT9__I2C1_SCL | I2C_PAD,
+ .gpio_mode = MX6_PAD_CSI0_DAT9__GPIO5_IO27 | I2C_PAD,
+ .gp = IMX_GPIO_NR(5, 27)
+ },
+ .sda = {
+ .i2c_mode = MX6_PAD_CSI0_DAT8__I2C1_SDA | I2C_PAD,
+ .gpio_mode = MX6_PAD_CSI0_DAT8__GPIO5_IO26 | I2C_PAD,
+ .gp = IMX_GPIO_NR(5, 26)
+ }
+};
+
+/* I2C2 HDMI */
+static struct i2c_pads_info i2c_pad_info1 = {
+ .scl = {
+ .i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | I2C_PAD,
+ .gpio_mode = MX6_PAD_KEY_COL3__GPIO4_IO12 | I2C_PAD,
+ .gp =
Re: [U-Boot] [PATCH] arm: tegra: use architecture specific memcpy
On Mon, 2014-10-20 at 15:40 +, Tom Warren wrote: Sorry, Marcel. Must have missed it. I'll rebase u-boot-tegra/master against ARM master and apply this, and if no other Tegra patches are pending, I'll send a PR later this week. Thanks, Tom. According to my notes the following 10 patches are still pending: [PATCH] arm: tegra: use architecture specific memcpy Tested-by: Stephen Warren swar...@nvidia.com [PATCH v2] ARM: tegra: Use mem size from MC in combination with get_ram_size() Acked-by: Stephen Warren swar...@nvidia.com [PATCH] tegra: colibri_t30: clean-up spurious new line Acked-by: Simon Glass s...@chromium.org [PATCH] tegra: gpio: fix null label regression Acked-by: Simon Glass s...@chromium.org [PATCH] tegra: apalis_t30: master revamp [PATCH] tegra: dts: colibri_t30 add serial port details [PATCH] tegra: clean-up useless define Acked-by: Simon Glass s...@chromium.org [PATCH] gpio: header file comment spelling fixes Acked-by: Simon Glass s...@chromium.org [PATCH] tegra: colibri_t30: asix usb ethernet reset regression Acked-by: Simon Glass s...@chromium.org [PATCH] mmc: Tegra: Fix timeout issue seen on certain eMMC parts Are you OK with those or should I resend any of them? BTW: Maybe acknowledging patch emails with applied messages like some other maintainers do would ease the tracking of an individual patch's status. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] git bisect failed
Hi all. Finally I got basic board support for OT1200 into upstream, but the last released version fails to detect SPI flash (read only ff's). The good one is commit 39d0973300b83c08f3f5047245ebf1de883b31f2 and the bad one is c43fd23cf619856b0763a64a6a3bcf3663058c49 [christian@chgm-pc u-boot]$ git bisect good There are only 'skip'ped commits left to test. The first bad commit could be any of: 540d434aa420bc056326f0f02135bb17e46be5b1 783e6a72b8278d59854ced41a4696c9a14abbb0b 92c2dc0f64f3115c77577f110eac6753dada9b15 0a5051ce6ebd5f6fad58fd50d6922493d8447f14 f1ef2b62339526df3b921bcfefd174ce76d4c624 e3a4facdfc07179ebe017a07b8de6224a935a9f3 f494e0a1847d74e68c460c90253836ea21c431ac 2f665945b39a9972260cbcf60d5e7f2a60587f5e d660b409dc3658087ce15e7d50ed007f1cfa09e8 be16aba5ce8d04b8ca0ebd5ac95d878064e44bd8 c79cba37b3b42cf8fbd71babcd8998867f76fead 3eb3e72a3f66db140dabd66b553380c19b2035d4 87f13aa00d0279fcc96530404c3a104eb4cb1672 93d3232d9607669f33a34d3a552b24e1d727413b f9860cf081efdf32c8a01b9fc271fe55e2a79f8d 110bdee00f70ba2cae90a8db39e8d3e854141a56 97d5e9d149ca910e1bd20d06a13b9e9cceb0e502 5e74934d407d2aabe5c4283b4394969025c643e3 64147e564cf43bb33b68766053960002bc0784dd 1d5c20154f0797e9a79fd0b39a9ae8a8801f6a51 df3b23ae3a7bb0627d595e6139ea43655d5acaa4 248a0488bfbb2eb16dee408a976d5f4b5546bb51 726ac8e4c505f086c1decd5263068373254ee60a cccee18918a9bcc1b34ddcd33f219a4ed26fc690 ca05ee9d43297cef9bb9ec74973d58586a6e4321 dba1697057abed60bcb46ff724dad9f3e090c566 b0928da648d440778512ddd81e690717239b8f1f ed36323f6d217050f82a2200475959b8557a47e4 2c3dc792b6df16970077c0d64085e29f1f85d4c8 a03bdaa1408be4e8b6adfc8577a0ceac3ebc51e5 535aad29f2a0881f66a0efdb3d467d0910d5e41e e5a504eb3d8cbc33199dac61a07d16ddd3c1c7f9 5dff844d7ff1704534905db9beb888f5552adb84 129acd4c75f85bdb7f1267fe5f1187e0fc37d221 07b342783a11bc56c38207006b5ad9d70ca3c863 8969ea3e9f2db04a6b36758972b708837786a5a5 b84505210367d152a456a2adeba90e13626ad104 214b3f311f0c1ac4c8f68e45133fc3547c76d8d1 ab7cb4eefa33b79834f0a000bcb365e98c14c693 a4277200a2253fda49342aa65800d27e61276170 bdc7dc4595646da8774f53a2c4f5a7599b0a5f16 c7eae7fcb11bc7dab519fca8d8902f1fbc5c3c76 e5bf9878ea743564bcc7a15a79654fe06731a1e2 593cbd93f33c38ca3ee9db34b5657a15d2437902 f80d6472b47e73e35e4eaed6fc56ce5df2c82cdb 2c2277f15cbaa9533ef8aead7328c3f605251147 8aeb893a8ed97bac679149386cec53b275be3715 d1b5ed075311f143926dd916edb59436267eb396 8bfa301b0a30f57888d2117767b23f168760bc40 c0aebb3382133c99bc458d96b562703dae4ae928 039b77396abb0ed78af34dadbd0786dfaf0e6aa9 40f8dec54d7803975aed1c88327002c95ea99908 7172de33b0cc0a44713fd4fbbb61fd1fada17341 5273aa3834ec68616e173ceac91cdcf60dba2868 bf9b86dc47988a404964c97c74e541a129719f9c f43b4356a794be647011132f4f2dc970a29a9dd5 0299046e5b4eec6c79927324deab857db1689e92 08df4a21c7d580770cabd7ba62591da035d9a545 92f7fed4f738149121c779fe1dda857585bdeccf 07c4eea4846cde938c4b0d8c1ddee95d373693ed bb5783224b9b12eecf406761f82e3de2a2ca9dae be9f643ae6aa9044c60fe80e3a2c10be8371c692 c032174f8218496a7768e4a27d1eb25b7e6f7a4d 1de271b487d60c613568ad61fc005ff850f2ed71 4b0abf9f3c024225987ec92ea9ae9e8a1ac5950d 75f698e51c7e40048e4d96fdaaaebeaefc945538 d9c68b1444acb383684636eb856fd7e4cec04129 1d71efbb0345ff3a8ac45e62bef36813abe1703e 31969b8993ee00015b7ac0f979d601299158fc6e 38e0e15372f9f463ab8dd30d21a46cb477e80dd4 845034e6b217d5ff73de03213ede9b17646a91b1 7f368553fcada0b38e8a096fcba4fcd64e0d2020 88e34e5ff76bffa7d56b1d04e0bd2627ee5b584d e211c12e773881f6bef60143df4764402a56de34 e628c8f75de952031f7b9fb9ae465a2a99d4c7f8 155fa9af95ac5be857a7327e7a968a296e60d4c8 363fb32aca268701a0918d67099fb344194f1746 5894ca007d217a2fa845facfbb62c6512396a145 5b8388a827c002c6c5e8da76bd99b66f1f26e92c 01d2aaf61ba7d532dee7002a2049d2b972992122 1b35721f61207c5f3cdf924be3bb64e0ad12887c 66cba041fe8fe4cdc3d8252974021257e736572a d087e0e26293a34752a6279da85f94a97084686c 0fb63aa63c35888dface83b44c1401be097277eb 47d3debe1ab8315dc9ade22279e02f60eceda25b 6dd0e7c00bfa5ce861a72b8e4a3ef9e787306125 45e60c25b54f0443265ee49909c70af90d5cbad9 8ca21cbea2671bad315cc93ab636a95d95bac058 cae025aab3e8ea8ad455cce8b0e4647401cdd091 1e3d64031608d668509b6fe0825f7708bb6b6a0d 59990bf0eaa12b123759cb0485f38e156103e93c 692c223518023b47579fbf1142a8f639cbedb5b0 65ae9523d9a5868075be40ef2582c75190cee6af 91cbd792c46c916ef196c5b7cd16ff592d2f3632 983a2749e2fdc459b2f44e82241a5c314ddbcdf6 0f88a5a98eb9d8d5158b074a127a4bf8d4ce8610 1454ba8e56d88a8b95ac8050cde2c07c651cd0ae 7798e2285fda17aa2268cbe18498678cf857905f bf1a86fca0111067021f3d263242767d3709d7be 4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01 6b1978f8a14fc2f53715f65827e98d607cc21e63 c19a8bc5711ec63e905ef91f045a1489f0aa3cb0 e7b14e9ab0ceef3068722007e7396f89f4ede9c2 4b19b7448e63bab8af17abbb30acff00d8f0dc99 We cannot bisect more! I had to skip steps in the bisect run as the board support was not existing. Any hints? greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] powerpc: aria: convert to generic board
Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/aria.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/aria.h b/include/configs/aria.h index c36cf33..2f9677c 100644 --- a/include/configs/aria.h +++ b/include/configs/aria.h @@ -13,6 +13,9 @@ #define __CONFIG_H #define CONFIG_ARIA 1 +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD + /* * Memory map for the ARIA board: * -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] powerpc: mpc512x: fix boot breakage
Commit d6b11fd1 (powerpc: remove MBX and MBX860T boards support)
removed mbxbar field in struct sysconf512x by mistake and broke
booting on mpc5121 boards. Fix it.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
NOTE: ALL mpc512x boards are broken in releases v2014.07 and
v2014.10.
arch/powerpc/include/asm/immap_512x.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/immap_512x.h
b/arch/powerpc/include/asm/immap_512x.h
index 6086a73..bed80aa 100644
--- a/arch/powerpc/include/asm/immap_512x.h
+++ b/arch/powerpc/include/asm/immap_512x.h
@@ -59,6 +59,7 @@ typedef struct sysconf512x {
u8 res2[0x28];
law512x_t ddrlaw; /* DDR Local Access Window */
u8 res3[0x18];
+ u32 mbxbar; /* MBX Base Address */
u32 srambar;/* SRAM Base Address */
u32 nfcbar; /* NFC Base Address */
u8 res4[0x34];
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] powerpc: mpc5121ads: convert to generic board
Also enable CONFIG_DISPLAY_BOARDINFO to get checkboard() called. Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/mpc5121ads.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/mpc5121ads.h b/include/configs/mpc5121ads.h index 7de245b..41ae0a5 100644 --- a/include/configs/mpc5121ads.h +++ b/include/configs/mpc5121ads.h @@ -12,6 +12,9 @@ #define __CONFIG_H #define CONFIG_MPC5121ADS 1 +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD + /* * Memory map for the MPC5121ADS board: * -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] powerpc: pdm360ng: convert to generic board
Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/pdm360ng.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/pdm360ng.h b/include/configs/pdm360ng.h index 553eb8f..17d7bca 100644 --- a/include/configs/pdm360ng.h +++ b/include/configs/pdm360ng.h @@ -13,6 +13,8 @@ #define __CONFIG_H #define CONFIG_PDM360NG 1 +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD /* * Memory map for the PDM360NG board: -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] powerpc: ac14xx: convert to generic board
Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/ac14xx.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/ac14xx.h b/include/configs/ac14xx.h index f57820d..54b7028 100644 --- a/include/configs/ac14xx.h +++ b/include/configs/ac14xx.h @@ -13,6 +13,9 @@ #define __CONFIG_H #define CONFIG_AC14XX 1 +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD + /* * Memory map for the ifm AC14xx board: * -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] powerpc: digsy_mtc: convert to generic board
Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/digsy_mtc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/digsy_mtc.h b/include/configs/digsy_mtc.h index 2a8cb39..76ec168 100644 --- a/include/configs/digsy_mtc.h +++ b/include/configs/digsy_mtc.h @@ -22,6 +22,8 @@ #define CONFIG_MPC5200 1 /* This is an MPC5200 CPU */ #define CONFIG_DIGSY_MTC 1 /* ... on InterControl digsyMTC board */ +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD /* * Valid values for CONFIG_SYS_TEXT_BASE are: -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] powerpc: mecp5123: convert to generic board
Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: Reinhard Arlt reinhard.a...@esd-electronics.com --- include/configs/mecp5123.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/mecp5123.h b/include/configs/mecp5123.h index 6c19817..0b9cbae 100644 --- a/include/configs/mecp5123.h +++ b/include/configs/mecp5123.h @@ -15,6 +15,9 @@ #define __CONFIG_H #define CONFIG_MECP5123 1 +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD + /* * Memory map for the MECP5123 board: * -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ls1:config: Add USB support for ls1021atwr
Add USB EHCI/XHCI support for ls1021atwr platform and making xHCI as default mode Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com --- include/configs/ls1021atwr.h | 28 1 file changed, 28 insertions(+) diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 45b2272..109e58c 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -28,6 +28,34 @@ #define CONFIG_SYS_INIT_RAM_SIZE OCRAM_SIZE /* + * USB + */ +/*EHCI Support*/ +/*#define CONFIG_HAS_FSL_DR_USB*/ + +#ifdef CONFIG_HAS_FSL_DR_USB +#define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_FSL +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET +#endif + +/*XHCI Support*/ +#define CONFIG_HAS_FSL_XHCI_USB + +#ifdef CONFIG_HAS_FSL_XHCI_USB +#define CONFIG_USB_XHCI +#define CONFIG_USB_XHCI_FSL +#define CONFIG_USB_MAX_CONTROLLER_COUNT1 +#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 1 +#endif + +#if defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_XHCI_USB) +#define CONFIG_CMD_USB +#define CONFIG_USB_STORAGE +#define CONFIG_CMD_EXT2 +#endif + +/* * Generic Timer Definitions */ #define GENERIC_TIMER_CLK 1250 -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ls1:config: Add XHCI support for ls1021aqds
Add USB XHCI support for ls1021aqds platform and making this as default mode Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com --- include/configs/ls1021aqds.h | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index fd43a3e..c6f83b2 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -275,19 +275,30 @@ unsigned long get_board_ddr_clk(void); /* * USB */ -#define CONFIG_HAS_FSL_DR_USB +/*EHCI Support*/ +/*#define CONFIG_HAS_FSL_DR_USB*/ #ifdef CONFIG_HAS_FSL_DR_USB #define CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_FSL +#define CONFIG_EHCI_HCD_INIT_AFTER_RESET +#endif -#ifdef CONFIG_USB_EHCI +/*XHCI Support*/ +#define CONFIG_HAS_FSL_XHCI_USB + +#ifdef CONFIG_HAS_FSL_XHCI_USB +#define CONFIG_USB_XHCI +#define CONFIG_USB_XHCI_FSL +#define CONFIG_USB_MAX_CONTROLLER_COUNT1 +#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 1 +#endif + +#if defined(CONFIG_HAS_FSL_DR_USB) || defined(CONFIG_HAS_FSL_XHCI_USB) #define CONFIG_CMD_USB #define CONFIG_USB_STORAGE -#define CONFIG_USB_EHCI_FSL -#define CONFIG_EHCI_HCD_INIT_AFTER_RESET #define CONFIG_CMD_EXT2 #endif -#endif /* * eTSEC -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix get_ram_size memory corruption
Dear Gerd Hoffmann, In message 1413887467-18799-1-git-send-email-kra...@redhat.com you wrote: base[0] is saved, but never restored. Test case: Start u-boot in qemu, using vexpress-a9 emulation. qemu places the fdt at the start of ram, as a service for the guest. Trying to pick it up there by setting fdt_addr accordingly fails because the fdt magic cookie is gone (zeroed out) after calling get_ram_size. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- common/memsize.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) When submitting an updated version of the patch, you are supposed to mark it as such in the Subject, and to provide a change log; please see [1] for details. [1] http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions It seems I cannot reproduce the problem here. Test 1: Board = TQM5200S running U-Boot 2014.10-rc2-00274-gf9860cf = md 0 4 : bc193d2c 0783d3c7 18688dbf c3c7c30f..=,.h.. = mw 0 27051956 = reset ... = md 0 4 : 27051956 0783d3c7 18688dbf c3c7c30f'..V.h.. = mm 0 : 27051956 ? deadbeef 0004: 0783d3c7 ? affeaffe 0008: 18688dbf ? 27051956 000c: c3c7c30f ? deadc0de 0010: 3d6b3f3d ? . = md 0 4 : deadbeef affeaffe 27051956 deadc0de'..V = md 0 4 : deadbeef affeaffe 27051956 deadc0de'..V Test 2: Board = lite5200b running U-Boot 2011.09-00282-gd8fffa0 = md 0 4 : b75d351d 77fe2cf5 4ba0ebeb 896baaae.]5.w.,.Kk.. = mm 0 : b75d351d ? 12345678 0004: 77fe2cf5 ? 87654321 0008: 4ba0ebeb ? 24681357 000c: 896baaae ? 86427531 0010: 53e7f1fe ? . = md 0 4 : 12345678 87654321 24681357 86427531.4Vx.eC!$h.W.Bu1 = reset ... = md 0 4 : 12345678 87654321 24681357 86427531.4Vx.eC!$h.W.Bu1 I cannot see any memory corruption. If I understand you correctly, the contents of address 0x should be overwritten here? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/ If you can follow that, you can use it. - Randal L. Schwartz in ukpw67rhl3@julie.teleport.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git bisect failed
Hi Christian, On 21/10/2014 13:43, Christian Gmeiner wrote: Hi all. Finally I got basic board support for OT1200 into upstream, but the last released version fails to detect SPI flash (read only ff's). The good one is commit 39d0973300b83c08f3f5047245ebf1de883b31f2 and the bad one is c43fd23cf619856b0763a64a6a3bcf3663058c49 [christian@chgm-pc u-boot]$ git bisect good There are only 'skip'ped commits left to test. The first bad commit could be any of: 540d434aa420bc056326f0f02135bb17e46be5b1 783e6a72b8278d59854ced41a4696c9a14abbb0b Any hints? My suggestion is to check changes in drivers/spi/mxc_spi.c and drivers/mtd/spi/ that were merged after you test your board. If only ff's are read, maybe the chip select is not driven - have you checked it ? 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] ot1200: remove superfluous string tag
On 07/10/2014 10:58, Christian Gmeiner wrote: Signed-off-by: Christian Gmeiner christian.gmei...@gmail.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 1/2] mx6qsabreauto: Add HDMI support
On 22/09/2014 18:55, Fabio Estevam wrote: Let HDMI splash screen support work by default. Signed-off-by: Fabio Estevam fabio.este...@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/2] mx6sabre_common: Add HDMI config to common code
On 22/09/2014 18:55, Fabio Estevam wrote: HDMI config options can be placed into the common mx6sabre_common.h file to avoid duplication. Signed-off-by: Fabio Estevam fabio.este...@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
[U-Boot] [PATCH] powerpc: mpc5121ads: update board config info in README
The config targets described in README are not present any more, update the info to currently used targets. Signed-off-by: Anatolij Gustschin ag...@denx.de --- board/freescale/mpc5121ads/README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/freescale/mpc5121ads/README b/board/freescale/mpc5121ads/README index defcd6b..741bc40 100644 --- a/board/freescale/mpc5121ads/README +++ b/board/freescale/mpc5121ads/README @@ -1,7 +1,7 @@ To configure for the current (Rev 3.x) ADS5121 - make ads5121_config + make mpc5121ads_config This will automatically include PCI, the Real Time CLock, add backup flash ability and set the correct frequency and memory configuration. To configure for the older Rev 2 ADS5121 type (this will not have PCI) - make ads5121_rev2_config + make mpc5121ads_rev2_config -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] e1000: fix sw fw sync on igb i210/i211
I finally had a look at the datasheet and spotted an additional
register address difference between regular E1000 and i210/i211 chips.
This patch fixes this and now successfully works on programmed
i210/i211 as well as unprogrammed i211.
Signed-off-by: Marcel Ziswiler mar...@ziswiler.com
---
Please note that unprogrammed i210 seem to behave slightly different
and do not assert the CFG_DONE bit in the EEMNGCTL register upon PHY
reset. However if this error condition is ignored then successful data
transfer is possible. Due to the rather hacky nature thereof this is
not addressed by my patch.
BTW: What about my previous patch this one kind of bases on?
[PATCH] e1000: add i211 and unprogrammed i210/i211 support
drivers/net/e1000.c | 6 --
drivers/net/e1000.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index b092867..798c8aa 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -1112,7 +1112,10 @@ e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t
mask)
if (e1000_get_hw_eeprom_semaphore(hw))
return -E1000_ERR_SWFW_SYNC;
- swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
+ if (hw-mac_type == e1000_igb)
+ swfw_sync = E1000_READ_REG(hw, I210_SW_FW_SYNC);
+ else
+ swfw_sync = E1000_READ_REG(hw, SW_FW_SYNC);
if (!(swfw_sync (fwmask | swmask)))
break;
@@ -4429,7 +4432,6 @@ e1000_phy_hw_reset(struct e1000_hw *hw)
if (hw-mac_type = e1000_82571)
mdelay(10);
-
} else {
/* Read the Extended Device Control Register, assert the
PHY_RESET_DIR
* bit to put the PHY into reset. Then, take it out of reset.
diff --git a/drivers/net/e1000.h b/drivers/net/e1000.h
index b025ecc..6d110eb 100644
--- a/drivers/net/e1000.h
+++ b/drivers/net/e1000.h
@@ -2497,6 +2497,7 @@ struct e1000_hw {
#define ICH_GFPREG_BASE_MASK 0x1FFF
#define ICH_FLASH_LINEAR_ADDR_MASK 0x00FF
+#define E1000_I210_SW_FW_SYNC 0x5B50 /* Software-Firmware Synchronization - RW
*/
#define E1000_SW_FW_SYNC 0x05B5C /* Software-Firmware Synchronization - RW */
/* SPI EEPROM Status Register */
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix get_ram_size memory corruption
Hi, I cannot see any memory corruption. If I understand you correctly, the contents of address 0x should be overwritten here? Depends on the address space layout. vexpress-a9 has flash mapped at 0x. RAM starts at 0x6000, and four bytes at 0x6000 get corrupted. Possibly it also depends on whenever the board calls get_ram_size() in the first place. For the vexpress the calls are in board-specific code (board/armltd/vexpress/vexpress_common.c). cheers, Gerd ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] fix get_ram_size memory corruption
base[0] is saved, but only restored in case the ram test failed.
Test case: Start u-boot in qemu, using vexpress-a9 emulation.
qemu places the fdt at the start of ram, as a service for the
guest. Trying to pick it up there by setting fdt_addr
accordingly fails because the fdt magic cookie is gone (zeroed
out) after calling get_ram_size.
Cc: Wolfgang Denk w...@denx.de
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
common/memsize.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 589400d..dac1368 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -48,11 +48,12 @@ long get_ram_size(long *base, long maxsize)
*addr = 0;
sync ();
- if ((val = *addr) != 0) {
+ val = *addr;
+ *addr = save[i];
+ if (val != 0) {
/* Restore the original data before leaving the function.
*/
sync ();
- *addr = save[i];
for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt;
sync ();
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices
On Fri, 17 Oct 2014 14:12:18 -0600 Simon Glass s...@chromium.org wrote: I'm unsure about the 'defaults' commands, I would tend to see it at the eeprom level as it might be needed in various situations. However it must be provided by the device, not the eeprom driver itself. It might also make sense to drop the callback in favour of a simple data array as it would allow setting it from device tree. I'm not sure what this refers to sorry. It refer to the 'eth eeprom defaults' command from this patch. The USB device I wrote that for need a lot more in the EEPROM than just the MAC address. This command allow writing the factory defaults in the EEPROM. Somehow I have a feeling that such a command would make sense for a few other use-case than just USB ethernet devices. Alban signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: clear VENDOR variable to fix build error on tcsh
On Tue, Oct 21, 2014 at 01:18:32PM +0900, Masahiro Yamada wrote: Since the environment VENDOR is set in tcsh, it must be cleared in our makefile. Otherwise, boards without CONFIG_SYS_VENDOR fail to build: make CROSS_COMPILE=arm-linux-gnueabi- wandboard_quad_defconfig all [ snip ] AR arch/arm/lib/lib.a CC arch/arm/lib/eabi_compat.o scripts/Makefile.build:55: /home/foo/u-boot/board/unknown/wandboard/ \ Makefile: No such file or directory make[2]: *** No rule to make target `/home/foo/u-boot/board/unknown/ \ wandboard/Makefile'. Stop. make[1]: *** [board/unknown/wandboard] Error 2 make: *** [__build_one_by_one] Error 2 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reported-by: Tom Everett t...@khubla.com Reported-by: Jeroen Hofstee jer...@myspectrum.nl --- config.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/config.mk b/config.mk index 2157537..00805bd 100644 --- a/config.mk +++ b/config.mk @@ -18,6 +18,8 @@ PLATFORM_LDFLAGS := LDFLAGS := LDFLAGS_FINAL := OBJCOPYFLAGS := +# clear VENDOR for tcsh +VENDOR := # ARCH := $(CONFIG_SYS_ARCH:%=%) Are there other variables that might fit into this same category? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Minor cm-t35/cm-t3730 updates
This patch series makes minor adjustments to the cm-t35/cm-t3730 board code. Igor Grinberg (3): omap3: Kconfig: fix the cm-t35 board option prompt omap3: cm-t35: use define for mmc wp gpio omap3: cm-t35: remove enable_gpmc_cs_config() arch/arm/cpu/armv7/omap3/Kconfig | 2 +- board/compulab/cm_t35/cm_t35.c | 17 +++-- 2 files changed, 4 insertions(+), 15 deletions(-) -- 2.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] omap3: Kconfig: fix the cm-t35 board option prompt
The cm-t35 board support covers both cm-t3530 and cm-t3730 boards. Mention both boards in the Kconfig option prompt. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- arch/arm/cpu/armv7/omap3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/omap3/Kconfig b/arch/arm/cpu/armv7/omap3/Kconfig index 6fae1e5..4a48f84 100644 --- a/arch/arm/cpu/armv7/omap3/Kconfig +++ b/arch/arm/cpu/armv7/omap3/Kconfig @@ -16,7 +16,7 @@ config TARGET_OMAP3_BEAGLE bool TI OMAP3 BeagleBoard config TARGET_CM_T35 - bool CompuLab CM-T35 + bool CompuLab CM-T3530 and CM-T3730 boards config TARGET_DEVKIT8000 bool TimLL OMAP3 Devkit8000 -- 2.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] omap3: cm-t35: use define for mmc wp gpio
Switch to using define for MMC WP GPIO instead of a magic number.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
board/compulab/cm_t35/cm_t35.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index 0944903..6728ac1 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -457,6 +457,8 @@ void set_muxconf_regs(void)
}
#if defined(CONFIG_GENERIC_MMC) !defined(CONFIG_SPL_BUILD)
+#define SB_T35_WP_GPIO 59
+
int board_mmc_getcd(struct mmc *mmc)
{
u8 val;
@@ -469,7 +471,7 @@ int board_mmc_getcd(struct mmc *mmc)
int board_mmc_init(bd_t *bis)
{
- return omap_mmc_init(0, 0, 0, -1, 59);
+ return omap_mmc_init(0, 0, 0, -1, SB_T35_WP_GPIO);
}
#endif
--
2.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] omap3: cm-t35: remove enable_gpmc_cs_config()
The gpmc_init() function already calls enable_gpmc_cs_config() for chip
select 0. Although the bus width is configured for 16 bit, it gets
reconfigured correctly in the omap_gpmc driver later.
Remove the enable_gpmc_cs_config() function call and the associated
gpmc_nand_config[] array.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
board/compulab/cm_t35/cm_t35.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index 6728ac1..f8265e1 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -53,16 +53,6 @@ static u32 gpmc_net_config[GPMC_MAX_REG] = {
0
};
-static u32 gpmc_nand_config[GPMC_MAX_REG] = {
- M_NAND_GPMC_CONFIG1,
- M_NAND_GPMC_CONFIG2,
- M_NAND_GPMC_CONFIG3,
- M_NAND_GPMC_CONFIG4,
- M_NAND_GPMC_CONFIG5,
- M_NAND_GPMC_CONFIG6,
- 0,
-};
-
#ifdef CONFIG_LCD
#ifdef CONFIG_CMD_NAND
static int splash_load_from_nand(u32 bmp_load_addr)
@@ -148,9 +138,6 @@ int board_init(void)
{
gpmc_init(); /* in SRAM or SDRAM, finish GPMC */
- enable_gpmc_cs_config(gpmc_nand_config, gpmc_cfg-cs[0],
- CONFIG_SYS_NAND_BASE, GPMC_SIZE_16M);
-
/* board id for Linux */
if (get_cpu_family() == CPU_OMAP34XX)
gd-bd-bi_arch_number = MACH_TYPE_CM_T35;
--
2.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: clear VENDOR variable to fix build error on tcsh
Hi Tom, 2014-10-21 22:20 GMT+09:00 Tom Rini tr...@ti.com: diff --git a/config.mk b/config.mk index 2157537..00805bd 100644 --- a/config.mk +++ b/config.mk @@ -18,6 +18,8 @@ PLATFORM_LDFLAGS := LDFLAGS := LDFLAGS_FINAL := OBJCOPYFLAGS := +# clear VENDOR for tcsh +VENDOR := # ARCH := $(CONFIG_SYS_ARCH:%=%) Are there other variables that might fit into this same category? I am not sure but probably only this one. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] README.scrapyard: update commit IDs
Signed-off-by: Wolfgang Denk w...@denx.de --- doc/README.scrapyard | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/README.scrapyard b/doc/README.scrapyard index 1dcdcc7..1b6ae83 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -12,14 +12,14 @@ The list should be sorted in reverse chronological order. BoardArchCPUCommit Removed Last known maintainer/contact = -MVBC_P powerpc mpc5xxx- - Andre Schwarz andre.schw...@matrix-vision.de -MVSMRpowerpc mpc5xxx- - Andre Schwarz andre.schw...@matrix-vision.de -MERGERBOXpowerpc mpc83xx- - Andre Schwarz andre.schw...@matrix-vision.de -MVBLM7 powerpc mpc83xx- - Andre Schwarz andre.schw...@matrix-vision.de -bluestonepowerpc ppc4xx - - Tirumala Marri tma...@apm.com -CRAYL1 powerpc ppc4xx - - David Updegraff d...@cray.com -KAREFpowerpc ppc4xx - - Travis Sawyer travis.saw...@sandburst.com -METROBOX powerpc ppc4xx - - Travis Sawyer travis.saw...@sandburst.com +MVBC_P powerpc mpc5xxxaf55e352014-10-10 Andre Schwarz andre.schw...@matrix-vision.de +MVSMRpowerpc mpc5xxxaf55e352014-10-10 Andre Schwarz andre.schw...@matrix-vision.de +MERGERBOXpowerpc mpc83xxe7a56562014-10-10 Andre Schwarz andre.schw...@matrix-vision.de +MVBLM7 powerpc mpc83xxe7a56562014-10-10 Andre Schwarz andre.schw...@matrix-vision.de +bluestonepowerpc ppc4xx 9ed32462014-10-10 Tirumala Marri tma...@apm.com +CRAYL1 powerpc ppc4xx 1521cdc2014-10-10 David Updegraff d...@cray.com +KAREFpowerpc ppc4xx dc9617e2014-10-10 Travis Sawyer travis.saw...@sandburst.com +METROBOX powerpc ppc4xx dc9617e2014-10-10 Travis Sawyer travis.saw...@sandburst.com PK1C20 nios2 - 70fbc4612014-08-24 Scott McNutt smcn...@psyent.com PCI5441 nios2 - 70fbc4612014-08-24 Scott McNutt smcn...@psyent.com flagadm powerpc mpc8xx aec6f8c52014-08-22 Kári Davíðsson k...@flaga.is -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] PowerPC: drop some 74xx_7xx boards and related code
The file board/Marvell/include/mv_gen_reg.h is incompatible with the GPL (see for example the MARVELL RESERVES THE RIGHT AT ITS SOLE DISCRETION TO REQUEST THAT THIS CODE BE IMMEDIATELY RETURNED TO MARVELL clause). As this cannot be fixed, we remove the file and all code that depends on it. Fortunately this only affects some very old boards that have long reached EOL: CPCI750 DB64360 DB64460 p3m750 p3m7448 Signed-off-by: Wolfgang Denk w...@denx.de Cc: Reinhard Arlt reinhard.a...@esd-electronics.com Cc: Stefan Roese s...@denx.de Cc: Roger Meier r.me...@siemens.com --- arch/powerpc/cpu/74xx_7xx/Kconfig | 16 - arch/powerpc/cpu/74xx_7xx/start.S | 13 +- board/Marvell/common/flash.c | 1056 board/Marvell/common/i2c.c | 521 -- board/Marvell/common/intel_flash.c | 253 --- board/Marvell/common/misc.S| 235 --- board/Marvell/common/serial.c |8 - board/Marvell/db64360/64360.h | 36 - board/Marvell/db64360/Kconfig | 12 - board/Marvell/db64360/MAINTAINERS |6 - board/Marvell/db64360/Makefile | 13 - board/Marvell/db64360/README | 105 -- board/Marvell/db64360/db64360.c| 922 -- board/Marvell/db64360/eth.h| 28 - board/Marvell/db64360/mpsc.c | 1001 --- board/Marvell/db64360/mpsc.h | 140 -- board/Marvell/db64360/mv_eth.c | 3128 -- board/Marvell/db64360/mv_eth.h | 818 - board/Marvell/db64360/mv_regs.h| 1108 board/Marvell/db64360/pci.c| 923 -- board/Marvell/db64360/sdram_init.c | 1945 - board/Marvell/db64460/64460.h | 36 - board/Marvell/db64460/Kconfig | 12 - board/Marvell/db64460/MAINTAINERS |6 - board/Marvell/db64460/Makefile | 13 - board/Marvell/db64460/README | 105 -- board/Marvell/db64460/db64460.c| 922 -- board/Marvell/db64460/eth.h| 27 - board/Marvell/db64460/mpsc.c | 1001 --- board/Marvell/db64460/mpsc.h | 140 -- board/Marvell/db64460/mv_eth.c | 3127 -- board/Marvell/db64460/mv_eth.h | 815 - board/Marvell/db64460/mv_regs.h| 1108 board/Marvell/db64460/pci.c| 923 -- board/Marvell/db64460/sdram_init.c | 1950 - board/Marvell/include/core.h | 236 --- board/Marvell/include/mv_gen_reg.h | 2296 - board/esd/cpci750/64360.h | 37 - board/esd/cpci750/Kconfig | 12 - board/esd/cpci750/MAINTAINERS |6 - board/esd/cpci750/Makefile | 14 - board/esd/cpci750/cpci750.c| 1088 board/esd/cpci750/eth.h| 28 - board/esd/cpci750/i2c.c| 475 -- board/esd/cpci750/i2c.h| 16 - board/esd/cpci750/ide.c| 74 - board/esd/cpci750/local.h | 69 - board/esd/cpci750/misc.S | 245 --- board/esd/cpci750/mpsc.c | 1002 --- board/esd/cpci750/mpsc.h | 140 -- board/esd/cpci750/mv_eth.c | 3131 -- board/esd/cpci750/mv_eth.h | 819 - board/esd/cpci750/mv_regs.h| 1108 board/esd/cpci750/pci.c| 1028 --- board/esd/cpci750/sdram_init.c | 1702 --- board/esd/cpci750/serial.c | 106 -- board/prodrive/p3mx/64460.h| 36 - board/prodrive/p3mx/Kconfig| 12 - board/prodrive/p3mx/MAINTAINERS|7 - board/prodrive/p3mx/Makefile | 10 - board/prodrive/p3mx/eth.h | 28 - board/prodrive/p3mx/misc.S | 245 --- board/prodrive/p3mx/mpsc.c | 997 --- board/prodrive/p3mx/mpsc.h | 140 -- board/prodrive/p3mx/mv_eth.c | 3291 board/prodrive/p3mx/mv_eth.h | 815 - board/prodrive/p3mx/mv_regs.h | 1109 board/prodrive/p3mx/p3mx.c | 838 - board/prodrive/p3mx/p3mx.h | 17 - board/prodrive/p3mx/pci.c | 1003 --- board/prodrive/p3mx/sdram_init.c | 418 - board/prodrive/p3mx/serial.c | 106 -- configs/CPCI750_defconfig |3 - configs/DB64360_defconfig |3 - configs/DB64460_defconfig |3 - configs/p3m7448_defconfig |4 - configs/p3m750_defconfig |4 - doc/README.scrapyard |5 + drivers/net/eepro100.c |2 +- include/configs/CPCI750.h | 609 --- include/configs/DB64360.h | 579 --- include/configs/DB64460.h | 517 -- include/configs/p3mx.h | 434 - 83 files changed, 7 insertions(+), 47332 deletions(-) delete mode 100644 board/Marvell/common/flash.c delete mode 100644 board/Marvell/common/i2c.c delete mode 100644
Re: [U-Boot] [PATCH v2 2/3] arm: relocate the exception vectors
Hi Georges, On Mon, 20 Oct 2014 23:08:30 +0200, Georges Savoundararadj savou...@gmail.com wrote: Hi Albert, Le 15/10/2014 00:11, Albert ARIBAUD a écrit : Hi Georges, On Tue, 14 Oct 2014 22:02:00 +0200, Georges Savoundararadj savou...@gmail.com wrote: Hi Albert, Hi Masahiro, (putting Masahiro in Cc: just in case) As my issue is related to Kconfig, I would like you to give me your opinions. Le 11/10/2014 12:47, Albert ARIBAUD a écrit : Hi Georges, On Sat, 27 Sep 2014 21:48:10 +0200, Georges Savoundararadj savou...@gmail.com wrote: This commit relocates the exception vectors. As ARM1176 and ARMv7 have the security extensions, it uses VBAR. For the other ARM processors, it copies the relocated exception vectors to the correct address: 0x or 0x. Signed-off-by: Georges Savoundararadj savou...@gmail.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Tom Warren twar...@nvidia.com --- This patch needs some tests because it impacts many boards. I have tested it with my raspberry pi in the two cases: using VBAR and using the copied exception vectors. Changes in v2: - Relocate exception vectors also on processors which do not support security extensions - Reword the commit message arch/arm/cpu/armv7/start.S | 6 -- arch/arm/lib/relocate.S| 30 ++ 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index fedd7c8..fdc05b9 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -81,12 +81,6 @@ ENTRY(c_runtime_cpu_setup) mcr p15, 0, r0, c7, c10, 4 @ DSB mcr p15, 0, r0, c7, c5, 4 @ ISB #endif -/* - * Move vector table - */ -/* Set vector address in CP15 VBAR register */ -ldr r0, =_start -mcr p15, 0, r0, c12, c0, 0 @Set VBAR bx lr diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S index 8035251..88a478e 100644 --- a/arch/arm/lib/relocate.S +++ b/arch/arm/lib/relocate.S @@ -6,6 +6,8 @@ * SPDX-License-Identifier: GPL-2.0+ */ +#include asm-offsets.h +#include config.h #include linux/linkage.h /* @@ -52,6 +54,34 @@ fixnext: cmp r2, r3 blo fixloop +/* + * Relocate the exception vectors + */ +#if (defined(CONFIG_ARM1176) || defined(CONFIG_ARMV7)) I would prefer a single CONFIG_HAS_VBAR symbol defined through Kconfig. 1) Actually, there is no Kconfig entry such as config ARM1176 nor config ARMV7 in U-Boot, unlike in Linux (arch/arm/mm/Kconfig). If there were such entries, we would simply do like the following (in arch/arm/Kconfig): config HAS_VBAR bool config ARM1176 select HAS_VBAR config ARMV7 select HAS_VBAR Should we go in this direction? It is the cleanest way to use Kconfig but it requires some work in order to convert all #define CONFIG_cpu into Kconfig entries. 2) Otherwise, we can insert a select HAS_VBAR in all boards that have a ARM1176 or a ARMv7 processor in arch/arm/Kconfig. It is not logical but this is what has been done with the Kconfig entry ARM64. And, it does not require much change. 3) The last thing we can do is as follows: config HAS_VBAR bool depends on SYS_CPU = arm1176 || SYS_CPU = armv7 default y CONFIG_HAS_VBAR will be defined if SYS_CPU are arm1176 or armv7. It does not require much change as well but, I think, it is bad code. What do you think is the best way to introduce CONFIG_HAS_VBAR symbol? (1, 2 or 3) I believe you have already sorted the options in order of decreasing 'quality' -- 1 being the best option, and 3 being the worst... Indeed option 1 would be the best and cleanest, and it could possibly open the way for other per-CPU options. We could try and limit the effort to converting only ARM1176 and ARMV7 and leaving other CONFIG_cpu #define'd until some later point in the future, but experience shows that such half-hearted attempts are never completed. Amicalement, I am currently trying to implement solution 1. only for ARM1176 and ARMV7 but I wonder if this work worth the effort just for one CPU feature. Do you expect more CPU feature like HAS_VBAR coming in the future? I add the following lines in arch/arm/Kconfig: config HAS_VBAR bool config ARM1176 bool select HAS_VBAR config ARMV7 bool select HAS_VBAR config SYS_CPU default arm1176 if ARM1176 default armv7 if ARMV7 Then, in the same file, under each config TARGET_board, I add select ARM1176 or select ARMV7. Also, I delete the Kconfig entries config SYS_CPU in all Kconfig of *all* boards that use
Re: [U-Boot] [PATCH 2/2] PowerPC: drop some 74xx_7xx boards and related code
On 21.10.2014 15:42, Wolfgang Denk wrote: The file board/Marvell/include/mv_gen_reg.h is incompatible with the GPL (see for example the MARVELL RESERVES THE RIGHT AT ITS SOLE DISCRETION TO REQUEST THAT THIS CODE BE IMMEDIATELY RETURNED TO MARVELL clause). As this cannot be fixed, we remove the file and all code that depends on it. Fortunately this only affects some very old boards that have long reached EOL: CPCI750 DB64360 DB64460 p3m750 p3m7448 Signed-off-by: Wolfgang Denk w...@denx.de Cc: Reinhard Arlt reinhard.a...@esd-electronics.com Cc: Stefan Roese s...@denx.de Cc: Roger Meier r.me...@siemens.com For the Prodrive boards (p3m750 / p3m7448): Acked-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
Re: [U-Boot] [PATCH v3] fix get_ram_size memory corruption
Dear Gerd, In message 1413894504-26255-1-git-send-email-kra...@redhat.com you wrote: base[0] is saved, but only restored in case the ram test failed. When posting a new version of a patch please always make sure to add a change log! I'm afraid your patch breaks at least some boards; tested on TQM5200 board... Before (v2014.10): U-Boot 2014.10 (Oct 21 2014 - 15:59:47) CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: TQM5200S (TQ-Components GmbH) on a STK52xx carrier board I2C: 85 kHz, ready DRAM: 64 MiB Flash: 32 MiB In:serial Out: serial Err: serial Net: FEC IDE: Bus 0: OK ... With your patch: U-Boot 2014.10-1-g27030e7 (Oct 21 2014 - 15:45:12) CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: TQM5200S (TQ-Components GmbH) on a STK52xx carrier board I2C: 85 kHz, ready DRAM: 1 GiB [board hangs here] Note also the incorrect RAM size. Sorry, but this is not a correct fix. NAK. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It's when they say 2 + 2 = 5 that I begin to argue.- Eric Pepke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] arm: relocate the exception vectors
Hi Masahiro, On Tue, 21 Oct 2014 14:41:14 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: I have a question: You are covering only arm1176 and armv7. What about arm1136? I am not sure, but arm1136 and arm1176 both belong to ARMv6 generation? If so, does arm1136 have VBAR register, doesn't it? ARM1136 is ARMv6 but does not have VBAR. Its vectors can only be at 0x or 0x (see page 3-65 of the ARM1136 ARM r1p5, DDI0211K). Best Regards Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] dm: tegra: boot time regression
Migrating our BSPs towards mainline U-Boot I noticed it suddenly booting slower. With mainline Linux I noticed about a 1 to 2 second increase while booting downstream L4T takes 10 to 15 seconds longer! Git bisecting it revealed the following commit to be at odds: 858530a8c0a7ce7e573e513934804a00d6676813 dm: tegra: Enable driver model for serial Switching back to not using the DM driver for serial brings it back to booting much faster. However looking closely at the serial stuff and its accompanying settings I could not quite pinpoint why exactly any of this would make the Linux kernel suddenly boot slower. Has anybody noticed similar issues? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] omap3/am33xx: mux: fix several checkpatch issues
Fix the following checkpatch issues:
CHECK: No space is necessary after a cast
\#39: FILE: arch/arm/include/asm/arch-am33xx/mux.h:39:
+#define PAD_CTRL_BASE 0x800
+#define OFFSET(x) (unsigned int) (((struct pad_signals *) \
CHECK: Avoid CamelCase: CONTROL_PADCONF_JTAG_nTRST
\#284: FILE: arch/arm/include/asm/arch-omap3/mux.h:284:
+#define CONTROL_PADCONF_JTAG_nTRST 0x0A1C
ERROR: space required after that ',' (ctx:VxV)
\#446: FILE: arch/arm/include/asm/arch-omap3/mux.h:446:
+#define MUX_VAL(OFFSET,VALUE)\
^
Cc: Raphael Assenat r...@8d.com
Cc: Ilya Yanok ya...@emcraft.com
Cc: Vaibhav Hiremath hvaib...@ti.com
Cc: Peter Barada peter.bar...@logicpd.com
Cc: Grazvydas Ignotas nota...@gmail.com
Cc: Stefan Roese s...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Nagendra T S nagen...@mistralsolutions.com
Cc: Nishanth Menon n...@ti.com
Cc: Tom Rini tr...@ti.com
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
Build tested with
./MAKEALL -s omap3
./MAKEALL -s am33xx
Only tricorder and tricorder_flash (which is the same board,
but different configurations, I think) have failed with unrelated errors:
ld: u-boot-spl section `.data' will not fit in region `.sram'
ld: region `.sram' overflowed by 484 bytes
arch/arm/include/asm/arch-am33xx/mux.h | 2 +-
arch/arm/include/asm/arch-omap3/mux.h | 4 ++--
board/8dtech/eco5pk/eco5pk.h | 2 +-
board/compulab/cm_t35/cm_t35.c | 2 +-
board/htkw/mcx/mcx.h | 2 +-
board/logicpd/am3517evm/am3517evm.h| 2 +-
board/logicpd/omap3som/omap3logic.c| 2 +-
board/pandora/pandora.h| 2 +-
board/technexion/tao3530/tao3530.h | 2 +-
board/technexion/twister/twister.h | 2 +-
board/teejet/mt_ventoux/mt_ventoux.h | 2 +-
board/ti/am3517crane/am3517crane.h | 2 +-
board/ti/evm/evm.h | 2 +-
board/ti/sdp3430/sdp.h | 2 +-
14 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mux.h
b/arch/arm/include/asm/arch-am33xx/mux.h
index 3249437..d8bf872 100644
--- a/arch/arm/include/asm/arch-am33xx/mux.h
+++ b/arch/arm/include/asm/arch-am33xx/mux.h
@@ -36,7 +36,7 @@ struct module_pin_mux {
/* Pad control register offset */
#define PAD_CTRL_BASE 0x800
-#define OFFSET(x) (unsigned int) (((struct pad_signals *) \
+#define OFFSET(x) (unsigned int) (((struct pad_signals *)\
(PAD_CTRL_BASE))-x)
/*
diff --git a/arch/arm/include/asm/arch-omap3/mux.h
b/arch/arm/include/asm/arch-omap3/mux.h
index 2f83206..eba4a5c 100644
--- a/arch/arm/include/asm/arch-omap3/mux.h
+++ b/arch/arm/include/asm/arch-omap3/mux.h
@@ -281,7 +281,7 @@
#define CONTROL_PADCONF_SYS_OFF_MODE 0x0A18
#define CONTROL_PADCONF_SYS_CLKOUT10x0A1A
#define CONTROL_PADCONF_SYS_CLKOUT20x01E2
-#define CONTROL_PADCONF_JTAG_nTRST 0x0A1C
+#define CONTROL_PADCONF_JTAG_NTRST 0x0A1C
#define CONTROL_PADCONF_JTAG_TCK 0x0A1E
#define CONTROL_PADCONF_JTAG_TMS 0x0A20
#define CONTROL_PADCONF_JTAG_TDI 0x0A22
@@ -443,7 +443,7 @@
#define OMAP34XX_CTRL_WKUP_CTRL(OMAP34XX_CTRL_BASE + 0x0A5C)
#define OMAP34XX_CTRL_WKUP_CTRL_GPIO_IO_PWRDNZ (16)
-#define MUX_VAL(OFFSET,VALUE)\
+#define MUX_VAL(OFFSET, VALUE)\
writew((VALUE), OMAP34XX_CTRL_BASE + (OFFSET));
#defineCP(x) (CONTROL_PADCONF_##x)
diff --git a/board/8dtech/eco5pk/eco5pk.h b/board/8dtech/eco5pk/eco5pk.h
index a794764..acf2b80 100644
--- a/board/8dtech/eco5pk/eco5pk.h
+++ b/board/8dtech/eco5pk/eco5pk.h
@@ -332,7 +332,7 @@ const omap3_sysinfo sysinfo = {
MUX_VAL(CP(SYS_CLKOUT1),(IEN | PTD | DIS | M0)) \
MUX_VAL(CP(SYS_CLKOUT2),(IEN | PTU | EN | M0)) \
/* JTAG */\
- MUX_VAL(CP(JTAG_nTRST), (IEN | PTD | DIS | M0)) \
+ MUX_VAL(CP(JTAG_NTRST), (IEN | PTD | DIS | M0)) \
MUX_VAL(CP(JTAG_TCK), (IEN | PTD | DIS | M0)) \
MUX_VAL(CP(JTAG_TMS), (IEN | PTD | DIS | M0)) \
MUX_VAL(CP(JTAG_TDI), (IEN | PTD | DIS | M0)) \
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index 7f6d12e..9c73264 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -281,7 +281,7 @@ static void cm_t3x_set_common_muxconf(void)
MUX_VAL(CP(SYS_OFF_MODE), (IEN | PTD | DIS | M0)); /*OFF_MODE*/
MUX_VAL(CP(SYS_CLKOUT1),(IEN | PTD | DIS | M0)); /*CLKOUT1*/
MUX_VAL(CP(SYS_CLKOUT2),(IDIS | PTU | DIS | M4)); /*green LED*/
- MUX_VAL(CP(JTAG_nTRST), (IEN | PTD | DIS | M0)); /*JTAG_nTRST*/
+ MUX_VAL(CP(JTAG_NTRST), (IEN | PTD | DIS | M0)); /*JTAG_NTRST*/
MUX_VAL(CP(JTAG_TCK), (IEN | PTD | DIS | M0)); /*JTAG_TCK*/
MUX_VAL(CP(JTAG_TMS), (IEN | PTD | DIS | M0)); /*JTAG_TMS*/
MUX_VAL(CP(JTAG_TDI), (IEN | PTD | DIS | M0));
Re: [U-Boot] [PATCH] omap3/am33xx: mux: fix several checkpatch issues
On 21.10.2014 17:25, Igor Grinberg wrote: Fix the following checkpatch issues: CHECK: No space is necessary after a cast \#39: FILE: arch/arm/include/asm/arch-am33xx/mux.h:39: +#define PAD_CTRL_BASE 0x800 +#define OFFSET(x) (unsigned int) (((struct pad_signals *) \ CHECK: Avoid CamelCase: CONTROL_PADCONF_JTAG_nTRST \#284: FILE: arch/arm/include/asm/arch-omap3/mux.h:284: +#define CONTROL_PADCONF_JTAG_nTRST 0x0A1C ERROR: space required after that ',' (ctx:VxV) \#446: FILE: arch/arm/include/asm/arch-omap3/mux.h:446: +#define MUX_VAL(OFFSET,VALUE)\ ^ Cc: Raphael Assenat r...@8d.com Cc: Ilya Yanok ya...@emcraft.com Cc: Vaibhav Hiremath hvaib...@ti.com Cc: Peter Barada peter.bar...@logicpd.com Cc: Grazvydas Ignotas nota...@gmail.com Cc: Stefan Roese s...@denx.de Cc: Stefano Babic sba...@denx.de Cc: Nagendra T S nagen...@mistralsolutions.com Cc: Nishanth Menon n...@ti.com Cc: Tom Rini tr...@ti.com Signed-off-by: Igor Grinberg grinb...@compulab.co.il Looks good, so: Acked-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] doc: fix README.standalone
Since commit fe1378a961e5 (ARM: use r9 for gd), r9 register is used on ARM to hold global_data. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- doc/README.standalone | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.standalone b/doc/README.standalone index 2be5f27..e3000ef 100644 --- a/doc/README.standalone +++ b/doc/README.standalone @@ -21,7 +21,7 @@ Design Notes on Exporting U-Boot Functions to Standalone Applications: 2. The pointer to the jump table is passed to the application in a machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II architectures use a dedicated register to hold the pointer to the - 'global_data' structure: r2 on PowerPC, r8 on ARM, k0 on MIPS, + 'global_data' structure: r2 on PowerPC, r9 on ARM, k0 on MIPS, P3 on Blackfin and gp on Nios II. The x86 architecture does not use such a register; instead, the pointer to the 'global_data' structure is passed as 'argv[-1]' pointer. -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] doc: fix README.standalone
Hello Masahiro, On 21-10-14 17:41, Masahiro Yamada wrote: Since commit fe1378a961e5 (ARM: use r9 for gd), r9 register is used on ARM to hold global_data. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- doc/README.standalone | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.standalone b/doc/README.standalone index 2be5f27..e3000ef 100644 --- a/doc/README.standalone +++ b/doc/README.standalone @@ -21,7 +21,7 @@ Design Notes on Exporting U-Boot Functions to Standalone Applications: 2. The pointer to the jump table is passed to the application in a machine-dependent way. PowerPC, ARM, MIPS, Blackfin and Nios II architectures use a dedicated register to hold the pointer to the - 'global_data' structure: r2 on PowerPC, r8 on ARM, k0 on MIPS, + 'global_data' structure: r2 on PowerPC, r9 on ARM, k0 on MIPS, P3 on Blackfin and gp on Nios II. The x86 architecture does not use such a register; instead, the pointer to the 'global_data' structure is passed as 'argv[-1]' pointer. Acked-by: Jeroen Hofstee jer...@myspectrum.nl Thanks, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: clear VENDOR variable to fix build error on tcsh
On Tue, Oct 21, 2014 at 10:41:02PM +0900, Masahiro YAMADA wrote: Hi Tom, 2014-10-21 22:20 GMT+09:00 Tom Rini tr...@ti.com: diff --git a/config.mk b/config.mk index 2157537..00805bd 100644 --- a/config.mk +++ b/config.mk @@ -18,6 +18,8 @@ PLATFORM_LDFLAGS := LDFLAGS := LDFLAGS_FINAL := OBJCOPYFLAGS := +# clear VENDOR for tcsh +VENDOR := # ARCH := $(CONFIG_SYS_ARCH:%=%) Are there other variables that might fit into this same category? I am not sure but probably only this one. Nope, SOC is one too. I _think_ this might even somehow be related (or at least I hope it is!) to the hard to trigger on normal machines race condition multi-build problem. You can see SOC fail with am335x_evm. I'm going to play a bit more and post a v2 of this, 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] [RFC] dm: tegra: boot time regression
Hi Marcel, On 21 October 2014 08:37, Marcel Ziswiler mar...@ziswiler.com wrote: Migrating our BSPs towards mainline U-Boot I noticed it suddenly booting slower. With mainline Linux I noticed about a 1 to 2 second increase while booting downstream L4T takes 10 to 15 seconds longer! Git bisecting it revealed the following commit to be at odds: 858530a8c0a7ce7e573e513934804a00d6676813 dm: tegra: Enable driver model for serial Switching back to not using the DM driver for serial brings it back to booting much faster. However looking closely at the serial stuff and its accompanying settings I could not quite pinpoint why exactly any of this would make the Linux kernel suddenly boot slower. Has anybody noticed similar issues? No I haven't but I have not really tested it. I wonder how U-Boot is affecting Linux boot time? Do you have a trace of the kernel boot? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] net: Add a command to access the EEPROM from ethernet devices
Hi Alban, On 21 October 2014 06:51, Alban Bedel alban.be...@avionic-design.de wrote: On Fri, 17 Oct 2014 14:12:18 -0600 Simon Glass s...@chromium.org wrote: I'm unsure about the 'defaults' commands, I would tend to see it at the eeprom level as it might be needed in various situations. However it must be provided by the device, not the eeprom driver itself. It might also make sense to drop the callback in favour of a simple data array as it would allow setting it from device tree. I'm not sure what this refers to sorry. It refer to the 'eth eeprom defaults' command from this patch. The USB device I wrote that for need a lot more in the EEPROM than just the MAC address. This command allow writing the factory defaults in the EEPROM. Somehow I have a feeling that such a command would make sense for a few other use-case than just USB ethernet devices. Quite possibly, although one option is to cross that bridge when you come to it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hi Simon, There may exist a problem about FIT image signature verify , can you check this problem?
Hi Jason,
On 20 October 2014 20:52, Duxiaoqiang duxiaoqi...@huawei.com wrote:
Hi Simon All
These days I tested verified U-Boot on ARM Foundation. And I found a problem
when I tested like this:
1) Generate a FIT image and signature blob file like: mkimage –D “-I
dts –O dtb –p 2000” –F kernel.its –k keys –K fvp.dtb –r signed_image.fit
2) Compile the Uboot like :
Step1: Make distclean
Step2: Make DEVICE_TREE=foundation all. After this step, there generated a
u-boot-dtb.bin file, but public key was not contained in it.
Normally I should use the public key contained blob file fvp.dtb to compile
Uoobt like: make EXT_DTB=path/fvp.dtb.
In my test case, I omitted the last step, and just choose step2’s result to
test.
3) Package firmware together with uboot
4) Boot system on Foundation
For the signed_image.fit contains the signature information, but U-Boot has
no public key information contained, When U-boot load the image,
There occurred error information like “: No signature node found: , this
result was normal.
But the system wasn’t stopped after this error information, it keep going on
and boot the system success at last!
I checked the source code about UBoot, and found problem in function
fit_config_verify_required_sigs
Please note the red part.
int fit_config_verify_required_sigs(const void *fit, int conf_noffset,
const void *sig_blob)
{
int noffset;
int sig_node;
/* Work out what we need to verify */
sig_node = fdt_subnode_offset(sig_blob, 0, FIT_SIG_NODENAME);
if (sig_node 0) {
debug(%s: No signature node found: %s\n, __func__,
fdt_strerror(sig_node));
return 0; à Since mismatch exists between UBoot and images,
system should return a error code. Return 0 means the result was ok.
}
………
After I modified return0 to return -1, result seems ok.
Please check this problem, and confirm should I have to commit a patch or
someone else will modify it.
Well yes this is what happens. You have no keys, so you are not asking
for verification. The code seems correct to me. If you change it, then
it will not be possible to boot an image without a signature. Lots of
people use plain FITs with no signatures.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kbuild: clear VENDOR variable to fix build error on tcsh
On Tue, Oct 21, 2014 at 12:13:23PM -0400, Tom Rini wrote: On Tue, Oct 21, 2014 at 10:41:02PM +0900, Masahiro YAMADA wrote: Hi Tom, 2014-10-21 22:20 GMT+09:00 Tom Rini tr...@ti.com: diff --git a/config.mk b/config.mk index 2157537..00805bd 100644 --- a/config.mk +++ b/config.mk @@ -18,6 +18,8 @@ PLATFORM_LDFLAGS := LDFLAGS := LDFLAGS_FINAL := OBJCOPYFLAGS := +# clear VENDOR for tcsh +VENDOR := # ARCH := $(CONFIG_SYS_ARCH:%=%) Are there other variables that might fit into this same category? I am not sure but probably only this one. Nope, SOC is one too. I _think_ this might even somehow be related (or at least I hope it is!) to the hard to trigger on normal machines race condition multi-build problem. You can see SOC fail with am335x_evm. I'm going to play a bit more and post a v2 of this, thanks! I take it back, it was a problem with one of my wrapper scripts. -- 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] image: Fix Android boot image support
Hello, Mr. Glass On Tue, Oct 21, 2014 at 12:42 AM, Simon Glass s...@chromium.org wrote: Why have ANDR_BOOT_ARGS_SIZE? If you are going to malloc() anyway, you may as well avoid the limit. Something like: char *bootargs = getenv(bootargs); int len = 0; if (*hdr-cmdline) len += strlen(hdr-cmdline); if (bootargs) len += strlen(bootargs); malloc(len +1) bytes copy them in I wanted to make my modifications as little as possible, since the code might be addressing some corner case in the image making tool. I checked the code for the mkbootimg tool, and verified that there are no need for the extra checks. I'll send the second version of the patch soon. Regards, Ahmad Draidi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git bisect failed
On Tue, Oct 21, 2014 at 01:43:36PM +0200, Christian Gmeiner wrote: Hi all. Finally I got basic board support for OT1200 into upstream, but the last released version fails to detect SPI flash (read only ff's). [snip] I had to skip steps in the bisect run as the board support was not existing. Any hints? What I've done in the past is make a local patch that adds a given board so that instead of skipping I apply that local patch, build, test, un-patch and git bisect good/bad, and repeat. -- 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] git bisect failed
Hi Christian, On Tue, Oct 21, 2014 at 9:43 AM, Christian Gmeiner christian.gmei...@gmail.com wrote: Hi all. Finally I got basic board support for OT1200 into upstream, but the last released version fails to detect SPI flash (read only ff's). I can confirm that 2014.10 has a SPI probe issue on a mx6qsabresd as well: U-Boot 2014.10 (Oct 21 2014 - 14:45:04) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: MX6-SabreSD I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Display: HDMI (1024x768) In:serial Out: serial Err: serial PMIC: PFUZE100 ID=0x10 Net: FEC [PRIME] Hit any key to stop autoboot: 0 = sf probe SF: Unsupported flash IDs: manuf 00, jedec , ext_jedec Failed to initialize SPI flash at 0:0 = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] memsize: Fix for bug in memory sizing code
The original memory sizing code in get_ram_size clobbers the word
at the base address, but forgets to restore it.
Unlike the (reverted) commit b8496cced856ff411f1eb2e4eff20f5abe7080b0
we'll go save and restore the base address value at the start and then
end of the function. It needs to stay cleared until the detection is
done, otherwise we'll fail to detect the same piece of memory being
mapped multiple times into the address space.
Cc: Wolfgang Denk w...@denx.de
Cc: Iwo Mergler iwo.merg...@netcommwireless.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
common/memsize.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 589400d..72d0156 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -27,12 +27,15 @@ DECLARE_GLOBAL_DATA_PTR;
long get_ram_size(long *base, long maxsize)
{
volatile long *addr;
- long save[32];
+ long save[32], save_base;
long cnt;
long val;
long size;
inti = 0;
+ save_base = base[0];
+ sync ();
+
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
sync ();
@@ -43,8 +46,6 @@ long get_ram_size(long *base, long maxsize)
addr = base;
sync ();
- save[i] = *addr;
- sync ();
*addr = 0;
sync ();
@@ -52,12 +53,12 @@ long get_ram_size(long *base, long maxsize)
/* Restore the original data before leaving the function.
*/
sync ();
- *addr = save[i];
for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt;
sync ();
*addr = save[--i];
}
+ base[0] = save_base;
return (0);
}
@@ -73,10 +74,12 @@ long get_ram_size(long *base, long maxsize)
addr = base + cnt;
*addr = save[--i];
}
+ base[0] = save_base;
return (size);
}
}
+ base[0] = save_base;
return (maxsize);
}
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] image: Fix Android boot image support
This patch makes the following changes:
- Set kernel entry point correctly
- Append bootargs from image to global bootargs instead
of replacing them
- Return end address instead of size from android_image_get_end()
- Give correct parameter to genimg_get_format() in boot_get_ramdisk()
Signed-off-by: Ahmad Draidi ar200...@gmail.com
Cc: Tom Rini tr...@ti.com
---
Changes for v2:
- Cleanup bootargs copying code
- Coding Style cleanup
---
common/bootm.c | 4 ++--
common/image-android.c | 45 ++---
common/image.c | 3 ++-
3 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index ff81a27..c04a3b0 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -144,11 +144,11 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int
argc,
images.os.type = IH_TYPE_KERNEL;
images.os.comp = IH_COMP_NONE;
images.os.os = IH_OS_LINUX;
- images.ep = images.os.load;
- ep_found = true;
images.os.end = android_image_get_end(os_hdr);
images.os.load = android_image_get_kload(os_hdr);
+ images.ep = images.os.load;
+ ep_found = true;
break;
#endif
default:
diff --git a/common/image-android.c b/common/image-android.c
index 6ded7e2..673cbca 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -7,6 +7,7 @@
#include common.h
#include image.h
#include android_image.h
+#include malloc.h
static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE + 1];
@@ -25,12 +26,33 @@ int android_image_get_kernel(const struct andr_img_hdr
*hdr, int verify,
printf(Kernel load addr 0x%08x size %u KiB\n,
hdr-kernel_addr, DIV_ROUND_UP(hdr-kernel_size, 1024));
- strncpy(andr_tmp_str, hdr-cmdline, ANDR_BOOT_ARGS_SIZE);
- andr_tmp_str[ANDR_BOOT_ARGS_SIZE] = '\0';
- if (strlen(andr_tmp_str)) {
- printf(Kernel command line: %s\n, andr_tmp_str);
- setenv(bootargs, andr_tmp_str);
+
+ int len = 0;
+ if (*hdr-cmdline) {
+ printf(Kernel command line: %s\n, hdr-cmdline);
+ len += strlen(hdr-cmdline);
+ }
+
+ char *bootargs = getenv(bootargs);
+ if (bootargs)
+ len += strlen(bootargs);
+
+ char *newbootargs = malloc(len + 2);
+ if (!newbootargs) {
+ puts(Error: malloc in android_image_get_kernel failed!\n);
+ return -1;
}
+ *newbootargs = '\0';
+
+ if (bootargs) {
+ strcpy(newbootargs, bootargs);
+ strcat(newbootargs, );
+ }
+ if (*hdr-cmdline)
+ strcat(newbootargs, hdr-cmdline);
+
+ setenv(bootargs, newbootargs);
+
if (hdr-ramdisk_size)
printf(RAM disk load addr 0x%08x size %u KiB\n,
hdr-ramdisk_addr,
@@ -52,17 +74,18 @@ int android_image_check_header(const struct andr_img_hdr
*hdr)
ulong android_image_get_end(const struct andr_img_hdr *hdr)
{
- u32 size = 0;
+ ulong end;
/*
* The header takes a full page, the remaining components are aligned
* on page boundary
*/
- size += hdr-page_size;
- size += ALIGN(hdr-kernel_size, hdr-page_size);
- size += ALIGN(hdr-ramdisk_size, hdr-page_size);
- size += ALIGN(hdr-second_size, hdr-page_size);
+ end = (ulong)hdr;
+ end += hdr-page_size;
+ end += ALIGN(hdr-kernel_size, hdr-page_size);
+ end += ALIGN(hdr-ramdisk_size, hdr-page_size);
+ end += ALIGN(hdr-second_size, hdr-page_size);
- return size;
+ return end;
}
ulong android_image_get_kload(const struct andr_img_hdr *hdr)
diff --git a/common/image.c b/common/image.c
index 085771c..e21c848 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1009,7 +1009,8 @@ int boot_get_ramdisk(int argc, char * const argv[],
bootm_headers_t *images,
image_multi_getimg(images-legacy_hdr_os, 1, rd_data, rd_len);
}
#ifdef CONFIG_ANDROID_BOOT_IMAGE
- else if ((genimg_get_format(images) == IMAGE_FORMAT_ANDROID)
+ else if ((genimg_get_format((void *)images-os.start)
+ == IMAGE_FORMAT_ANDROID)
(!android_image_get_ramdisk((void *)images-os.start,
rd_data, rd_len))) {
/* empty */
--
2.1.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: mx6: add support for TBS2910 Matrix ARM miniPC
Hi Stefano,
Thanks for your review.
+static int mx6_rgmii_rework(struct phy_device *phydev)
+{
+ unsigned short val;
+
+ /* To enable AR8035 ouput a 125MHz clk from CLK_25M */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x7);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0xe, 0x8016);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
+
+ val = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
+ val = 0xffe3;
+ val |= 0x18;
+ phy_write(phydev, MDIO_DEVAD_NONE, 0xe, val);
+
+ /* introduce tx clock delay */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x5);
+ val = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
+ val |= 0x0100;
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, val);
+
+ return 0;
I miss the point - which is the difference with ar8035_config() in
drivers/net/phy/atheros.c and why cnnot you reuse it ? Can we avoid to
duplicate the code ?
OK, I will remove this code.
+static void setup_display(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ int reg;
+
+ enable_ipu_clock();
+ imx_setup_hdmi();
+
+ /* Turn on LDB0, LDB1, IPU,IPU DI0 clocks */
+ reg = readl(mxc_ccm-CCGR3);
+ reg |= MXC_CCM_CCGR3_LDB_DI0_MASK | MXC_CCM_CCGR3_LDB_DI1_MASK;
+ writel(reg, mxc_ccm-CCGR3);
+
+ /* set LDB0, LDB1 clk select to 011/011 */
+ reg = readl(mxc_ccm-cs2cdr);
+ reg = ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK
+| MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);
+ reg |= (3 MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)
+ | (3 MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);
+ writel(reg, mxc_ccm-cs2cdr);
+
+ reg = readl(mxc_ccm-cscmr2);
+ reg |= MXC_CCM_CSCMR2_LDB_DI0_IPU_DIV | MXC_CCM_CSCMR2_LDB_DI1_IPU_DIV;
+ writel(reg, mxc_ccm-cscmr2);
+
+ reg = readl(mxc_ccm-chsccdr);
+ reg |= (CHSCCDR_CLK_SEL_LDB_DI0
+MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET);
+ reg |= (CHSCCDR_CLK_SEL_LDB_DI0
+MXC_CCM_CHSCCDR_IPU1_DI1_CLK_SEL_OFFSET);
+ writel(reg, mxc_ccm-chsccdr);
+}
This is also copied from sabresd. Can we factorize in some way ?
I can, and probably should, simplify this code. But in fact this code
is wrong, and in the same way for many imx6q boards (e.g. sabresd,
wandboard, nitrogen6x,...).
This code configures the external video clock (LDB_DIx clock). This
clock is hardcoded to have 65MHz in drivers/video/ipu_common.c:ldb_clk.
But in fact the clock rate is configured to 75.42MHz (528MHz/7) on all
boards. So the display does not show 1024x768@60Hz as configured, but
something similar to 1024x768@70Hz (not VESA compliant), which much
monitors can handle, but on other monitors there are problems.
(one out of tree monitors works for me).
My intention was to get this initial support for tbs2910 merged with the
(wrong) code from sabresd used as template, and later to discuss how to
cleanup this code.
Do you prefer a simplified version of this code for the initial patch?
Or should we aim for a fixed video clock in the first place?
+#endif /* CONFIG_VIDEO_IPUV3 */
+
+int board_eth_init(bd_t *bis)
+{
+ setup_iomux_enet();
+ setup_pcie();
+
+ return cpu_eth_init(bis);
+}
+
+int board_early_init_f(void)
+{
+ setup_iomux_uart();
+#ifdef CONFIG_VIDEO_IPUV3
+ setup_display();
I do not understand why setup_display() should be called at this point.
Generally, board_early_init_f() is called to setup iomux for peripherals
needed before relocation, as uart, letting the rest of the setup in
board_init(). Why do you need here ?
In fact this was also copied from sabresd/wandboard/nitrogen6x.
My assumption was, that the clocks must be configured before the
ipu is initialized.
diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig
new file mode 100644
index 000..602d691
--- /dev/null
+++ b/configs/tbs2910_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q2g.cfg,MX6Q
Be aware that changes in the ddr-setup in that file will have a
consequence on your board.
Yes, I'm aware of that. But nitrogen6x is very well maintained. So I see no
need to
duplicate this config and reuse it in the same way as wandboard does.
Best regards,
Soeren Moch
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: tegra: handle error returned from bounce_buffer_start
Function bounce_buffer_start can return ENOMEM when memalign fails,
but the error code is never checked.
One such failure happens when state-len_aligned is larger than the
remaining free memory (set via CONFIG_SYS_MALLOC_LEN).
This leaves state-bounce_buffer as a NULL. If unchecked, the
tegra_mmc driver writes the entire block as a 0xFF and will continue
on its way.
Let's handle this error by printing that it happened, and then return
it up the chain.
This bug was discoverd during fastboot flashing of sparse images.
A pointer is moved through buffered data and often needs to be DMA
aligned prior to MMC write. These blocks are are often more than 4mb
which is the default Tegra setting for CONFIG_SYS_MALLOC_LEN.
Signed-off-by: Michael Scott michael.sc...@linaro.org
Cc: Tom Warren twar...@nvidia.com
Cc: Stephen Warren swar...@nvidia.com
---
drivers/mmc/tegra_mmc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
index ca9c4aa..5ecc2c9 100644
--- a/drivers/mmc/tegra_mmc.c
+++ b/drivers/mmc/tegra_mmc.c
@@ -332,7 +332,13 @@ static int tegra_mmc_send_cmd(struct mmc *mmc, struct
mmc_cmd *cmd,
}
len = data-blocks * data-blocksize;
- bounce_buffer_start(bbstate, buf, len, bbflags);
+ ret = bounce_buffer_start(bbstate, buf, len, bbflags);
+ if (ret) {
+ printf(%s: bounce_buffer_start failed with error %d
+ (buf = %p, len = %u, flags = %u)\n,
+ __func__, ret, buf, len, bbflags);
+ return ret;
+ }
}
ret = mmc_send_cmd_bounced(mmc, cmd, data, bbstate);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] MW rule and its period
Hello, The following is the notes of the open discussion sent by Detlev: The fact that a large set of patches for the SoCFPGAs was merged after -rc1 was questioned as it does not 100% comply with the rules. The patches constrained to SoCFPGA were no (big) problem, but one of those patches broke mkimage and as such had an impact on the whole project. The lesson should be - custodians should send out pull requests soon after the merge window opens up. Big chunks should not be pulled in after -rc1. The -next branch should be declared rebaseable and be used more. Once -rc1 is released, things can then be pulled into the next branch. Only bug fixes should go into the later -rc's. I think this statement means we should be more strict to the merge window rule. I think, basically, our (= developers') pain depends on the duration of the merge window being _closed_. (The duration of the merge window, if it is 2 weeks or 3 weeks, it is not a big deal.) The longer the merge window is closed, the more master and next branch diverge, i.e. more possible conflicts we get. In Linux, 2 weeks open 7 (sometimes 8) weeks closed In U-boot, released every 3months(=13 week) 3 weeks open 10 weeks closed Even Linux needs 7 weeks to be stabilized in spite of much more commits than U-Boot. Do we really need 10 weeks? If we make a decision to adopt a more strict merge window rule, shall we discuss how long it should be opened and closed? (although I still prefer the former loose MW rule...) (As Linus said in ELCE2014, if the release cycle is short, it does not matter even if you miss a merge window; just wait, next merge window comes soon. ) So two options here I'd like to suggest [1] Every 2 months release with 2 weeks MW MW open: 2 weeks MW closed: 6.5 weeks [2] Every 3 months release with 7 weeks MW MW open: 7 weeks MW closed: 6 weeks Comments? -- 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 3/3] ARM: sunxi: Fix reset command on sun6i/sun8i
On Sun, 2014-10-12 at 10:40 +0800, Chen-Yu Tsai wrote:
On Sat, Oct 11, 2014 at 11:33 PM, Ian Campbell i...@hellion.org.uk wrote:
On Sat, 2014-10-04 at 20:37 +0800, Chen-Yu Tsai wrote:
+#else /* CONFIG_SUN6I || CONFIG_SUN8I || .. */
+ static const struct sunxi_wdog *wdog =
+ ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)-wdog;
+
+ /* Set the watchdog for its shortest interval (.5s) and wait */
+ writel(WDT_CFG_RESET, wdog-cfg);
+ writel(WDT_MODE_EN, wdog-mode);
+ writel(WDT_CTRL_KEY | WDT_CTRL_RESTART, wdog-ctl);
That's annoyingly close to the 4/5/7i version, but not quite close
enough to allow any meaningful sharing :-/
I suppose it is possible to share using clrsetbits...
I think it probably isn't worth it.
+ while (1) {
+ /* sun5i sometimes gets stuck without this */
Is this not therefore unnecessary on 6i/8i?
The kernel restart driver uses this.
But Allwinner's original code does not.
Unless it is needed in practice lets just leave it out.
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH 6/9] ARM: sunxi: Add support for R_PIO gpio banks
On Fri, 2014-10-17 at 22:48 +0800, Chen-Yu Tsai wrote: Hi Ian, On Mon, Oct 13, 2014 at 8:57 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Sun, Oct 12, 2014 at 04:23:05PM +0800, Chen-Yu Tsai wrote: On Sun, Oct 12, 2014 at 12:05 AM, Ian Campbell i...@hellion.org.uk wrote: On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote: From: Hans de Goede hdego...@redhat.com The A31, A23 and later SoCs have an extra pin controller, called CPUs_PIO or R_PIO, which handles pin banks L and beyond. Does it also have enough space for 9 banks? Since you overlay a struct sunxi_gpio_reg on it which has a gpio_bank[SUNXI_GPIO_BANKS] over it. Yes it does, as seen in the latest A31 manuals released by Allwinner. SUNXI_GPIO_BANKS is now also confusingly named since it is really number of banks on the first/original GPIO controller. Eventually someone will use it as the actual total and be very sad. I think it might be best if we retcon some distinct name onto the original GPIO controller so we can have SUNXIO_GPIO_BLA_BANKS and SUNXI_GPIO_R_BANKS (or even just call them controller 0 and 1 and have SUNXI_GPIO0_BANKS and SUNXI_GPIO1_BANKS, if that's not too confusing) The latest manuals have CPUx-PORT and CPUs-PORT for the respective chapters. I'm guessing x is for 0~3 cores, and s is for standby or something. iirc, it was meant for special. I'd like to keep it as SUNXI_GPIO_BANKS if possible. The GPIO and R_GPIO prefixes match what we see in Allwinner's sources and what we use in the mainline kernel. OK, matching the mainline kernel is a sound plan. The comment section above it could be made clearer about it. Also that number would be bumped up for A80, which has pin bank J. I will change some of the R_PIO code to check/use the starting pin bank L number instead of checking against SUNXI_GPIO_BANKS. Wonder why I didn't do it before... Sounds good. Of course it's also confusing that Allwinner's sources use the R_ prefix for all hardware in that address range, while the datasheet lists the GPIO function names as s_something. We use the same pin convention than in the datasheet in mainline (but starting from PL for the special pins). And it's true that we do prefix all the functions by s_, once again, just like the datasheet does. The fact that it comes from a different controller is only expressed by where the pinctrl pins node is defined in the DT. I'm a bit undecided about how we should name the pin definitions. In the kernel, we named the function s_uart, but the pinconf node r_uart. In u-boot there isn't this separation. I'm wondering which would be easier to understand and relate to the underlying peripheral. At the moment I prefer R_UART. Either is fine for me. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] sunxi: Kconfig: Unify sunxi Kconfig code
On Sun, 2014-10-12 at 22:17 +0100, Ian Campbell wrote: -if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I + default sun4i if TARGET_SUN4I + default sun5i if TARGET_SUN5I + default sun6i if TARGET_SUN5I There is a typo here which is apparent with MAKEALL -s sunxi, since it causes Colombus_defconfig not to build. Patch is below but given the breakage is only in u-boot-sunxi.git#next right now I think it would be better to fold it into the original patch. Ian. 8 From 59d0b88a5025b2846227c0bde6ccdbb2e1bf916b Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Tue, 21 Oct 2014 20:00:28 +0100 Subject: [PATCH] sunxi: Fix build breakage for sun6i u-boot-sunxi.git#next currently fails with: In file included from /local/scratch/ijc/development/u-boot.git/include/common.h:18:0: include/config.h:5:22: fatal error: configs/.h: No such file or directory #include configs/.h ^ This is due to a typo in board/sunxi/Kconfig which causes CONFIG_SYS_CONFIG_NAME to be undefined for sun6i platforms. Signed-off-by: Ian Campbell i...@hellion.org.uk --- board/sunxi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 4ac562c..9892a34 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -4,7 +4,7 @@ config SYS_CONFIG_NAME string default sun4i if TARGET_SUN4I default sun5i if TARGET_SUN5I - default sun6i if TARGET_SUN5I + default sun6i if TARGET_SUN6I default sun7i if TARGET_SUN7I config SYS_CPU -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] MW rule and its period
On Tue, Oct 21, 2014 at 4:07 PM, Masahiro YAMADA yamad...@jp.panasonic.com wrote: ... So two options here I'd like to suggest [1] Every 2 months release with 2 weeks MW MW open: 2 weeks MW closed: 6.5 weeks I prefer this option however I also want to warn this will impose more active response from custodians. In case of the i.MX we had long delays in review and merges from Stefano from time to time and this would complicate a lot. So for i.MX specific case some patches got merged late and this complicates a lot testing. Mainly because sometimes one tree depends on changes in another and a lack of u-boot-next where all them are automatic merged complicates a full test of upcoming release. p.s: this is not a personal attack but something which is clearly happening. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] sunxi: Kconfig: Unify sunxi Kconfig code
On Tue, Oct 21, 2014 at 08:03:59PM +0100, Ian Campbell wrote: On Sun, 2014-10-12 at 22:17 +0100, Ian Campbell wrote: -if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I + default sun4i if TARGET_SUN4I + default sun5i if TARGET_SUN5I + default sun6i if TARGET_SUN5I There is a typo here which is apparent with MAKEALL -s sunxi, since it causes Colombus_defconfig not to build. Patch is below but given the breakage is only in u-boot-sunxi.git#next right now I think it would be better to fold it into the original patch. Yes, fold it in, 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] [RFC] MW rule and its period
Dear Masahiro, In message CAMhH57R2eBf26ONYD4fnLRWDQ=bjy_0crlm_yoprzgdmwoq...@mail.gmail.com you wrote: Even Linux needs 7 weeks to be stabilized in spite of much more commits than U-Boot. Do we really need 10 weeks? I think a fundamental difference between Linux and U-Boot is that in Linux the actual core is not changing so heavily, and the individual subsystems are much better isolated. In U-Boot, we have a large number commits with architecture-wide impact, not to mention system-wide ones like the Kconfig / Kbuild or DM restructuring. So a bug introduced in Linux will often affect only a relatively small group of developers, while the rest can continue working basically unaffected. In U-Boot it's easy to break all ARM, which will bring the majority of developers to a full stop. Also I think reducing the MW makes things indeed faster, which means more frequent release cycles, and I'm afraid in the end the custodians will not find their days easier, but more loaded. Just my $0.02. So two options here I'd like to suggest [1] Every 2 months release with 2 weeks MW MW open: 2 weeks MW closed: 6.5 weeks [2] Every 3 months release with 7 weeks MW MW open: 7 weeks MW closed: 6 weeks I think 2 (...3) weeks of MW work pretty well for U-Boot; we should not need more. Keeping the MW open too long just increases to efforts to make everything ready for release. So in my opinion it boild sown if we want to shorten the release cycle as such. I guess we whould have to try it out, but I fear it might easily backfire. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The flow chart is a most thoroughly oversold piece of program docu- mentation. -- Frederick Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git bisect failed
Hi Christian, On Tue, 21 Oct 2014 13:43:36 +0200 Christian Gmeiner christian.gmei...@gmail.com wrote: Hi all. Finally I got basic board support for OT1200 into upstream, but the last released version fails to detect SPI flash (read only ff's). The good one is commit 39d0973300b83c08f3f5047245ebf1de883b31f2 and the bad one is c43fd23cf619856b0763a64a6a3bcf3663058c49 $ git log 39d097330..c43fd23c drivers/spi/mxc_spi.c commit 155fa9af95ac5be857a7327e7a968a296e60d4c8 Author: Nikita Kiryanov nik...@compulab.co.il Date: Wed Aug 20 15:08:50 2014 +0300 spi: mxc: fix sf probe when using mxc_spi MXC SPI driver has a feature whereas a GPIO line can be used to force CS high across multiple transactions. This is set up by embedding the GPIO information in the CS value: cs = (cs | gpio 8) This merge of cs and gpio data into one value breaks the sf probe command: if the use of gpio is required, invoking sf probe cs will not work, because the CS argument doesn't have the GPIO information in it. Instead, the user must use sf probe cs | gpio 8. For example, if bank 2 gpio 30 is used to force cs high on cs 0, bus 0, then instead of typing sf probe 0 the user now must type sf probe 15872. This is inconsistent with the description of the sf probe command, and forces the user to be aware of implementaiton details. Fix this by introducing a new board function: board_spi_cs_gpio(), which will accept a naked CS value, and provide the driver with the relevant GPIO, if one is necessary. Cc: Eric Nelson eric.nel...@boundarydevices.com Cc: Eric Benard e...@eukrea.com Cc: Fabio Estevam fabio.este...@freescale.com Cc: Tim Harvey thar...@gateworks.com Cc: Stefano Babic sba...@denx.de Cc: Tom Rini tr...@ti.com Cc: Marek Vasut ma...@denx.de Reviewed-by: Marek Vasut ma...@denx.de Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Reviewed-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com Does it work if you revert 155fa9af ? Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-video/master
On Mon, Oct 20, 2014 at 11:15:15PM +0200, Anatolij Gustschin wrote: Hey Tom, The following changes since commit c43fd23cf619856b0763a64a6a3bcf3663058c49: Prepare v2014.10 (2014-10-14 04:47:15 -0400) are available in the git repository at: git://git.denx.de/u-boot-video.git master for you to fetch changes up to 3e780af127282e5e24fa737a5b56d7c4523a72c9: video: ipu_disp: remove pixclk fixup (2014-10-16 11:00:26 +0200) Jeroen Hofstee (2): video: ipu: fix debug and comment video: ipu_disp: remove pixclk fixup Simon Glass (1): lcd: Fix build error with CONFIG_LCD_BMP_RLE8 common/lcd.c |4 ++-- drivers/video/ipu_disp.c | 33 +++-- drivers/video/mxc_ipuv3_fb.c |7 +++ include/configs/sandbox.h|1 + 4 files changed, 13 insertions(+), 32 deletions(-) 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] Please pull u-boot-fsl-qoriq master
On Mon, Oct 20, 2014 at 02:29:00PM -0700, York Sun wrote: Tom, The following changes since commit c43fd23cf619856b0763a64a6a3bcf3663058c49: Prepare v2014.10 (2014-10-14 04:47:15 -0400) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git master for you to fetch changes up to ba4740205d22d31da289f5b6b2f8db7d27896f40: ls102x: Add support for secure boot and enable blob command (2014-10-16 14:21:26 -0700) Ruchika Gupta (10): powerpc/P1010RDB:Update RESET_VECTOR_ADDRESS for 768KB u-boot size fsl_sec : Move SEC CCSR definition to common include fsl_sec : Change accessor function to take care of endianness fsl_sec: Add hardware accelerated SHA256 and SHA1 mpc85xx: configs - Add hash command in freescale platforms ls102x: configs - Add hash command in freescale LS1 platforms powerpc/mpc85xx: SECURE BOOT - Bypass PAMU in case of secure boot crypto/fsl: Add command for encapsulating/decapsulating blobs mpc85xx: configs - Enable blob command in freescale platforms ls102x: Add support for secure boot and enable blob command README |6 + arch/arm/include/asm/arch-ls102xa/config.h |4 + arch/powerpc/cpu/mpc85xx/cpu_init.c | 18 +- arch/powerpc/cpu/mpc85xx/fdt.c |2 +- arch/powerpc/cpu/mpc85xx/liodn.c |4 +- arch/powerpc/cpu/mpc8xxx/fdt.c |4 +- arch/powerpc/include/asm/config_mpc85xx.h|1 + arch/powerpc/include/asm/immap_85xx.h| 73 +-- arch/powerpc/include/asm/types.h |4 + board/freescale/ls1021aqds/MAINTAINERS |1 + board/freescale/ls1021aqds/ls1021aqds.c | 10 + board/freescale/ls1021atwr/MAINTAINERS |1 + board/freescale/ls1021atwr/ls1021atwr.c | 10 + common/Makefile |2 + common/cmd_blob.c| 109 + configs/ls1021aqds_nor_SECURE_BOOT_defconfig |3 + configs/ls1021atwr_nor_SECURE_BOOT_defconfig |3 + drivers/crypto/Makefile |1 + drivers/crypto/fsl/Makefile | 10 + drivers/crypto/fsl/desc.h| 651 ++ drivers/crypto/fsl/desc_constr.h | 280 +++ drivers/crypto/fsl/error.c | 258 ++ drivers/crypto/fsl/fsl_blob.c| 61 +++ drivers/crypto/fsl/fsl_hash.c| 77 +++ drivers/crypto/fsl/jobdesc.c | 125 + drivers/crypto/fsl/jobdesc.h | 29 ++ drivers/crypto/fsl/jr.c | 462 ++ drivers/crypto/fsl/jr.h | 97 include/configs/B4860QDS.h | 11 + include/configs/BSC9131RDB.h |7 + include/configs/BSC9132QDS.h | 11 + include/configs/C29XPCIE.h |7 + include/configs/P1010RDB.h | 13 +- include/configs/P2041RDB.h | 11 + include/configs/T1040QDS.h |8 + include/configs/T104xRDB.h |8 + include/configs/T208xQDS.h |8 + include/configs/T208xRDB.h |8 + include/configs/T4240QDS.h | 11 + include/configs/T4240RDB.h |8 + include/configs/corenet_ds.h | 11 + include/configs/ls1021aqds.h | 11 + include/configs/ls1021atwr.h | 12 + include/fsl_sec.h| 181 +++ 44 files changed, 2558 insertions(+), 74 deletions(-) create mode 100644 common/cmd_blob.c create mode 100644 configs/ls1021aqds_nor_SECURE_BOOT_defconfig create mode 100644 configs/ls1021atwr_nor_SECURE_BOOT_defconfig create mode 100644 drivers/crypto/fsl/Makefile create mode 100644 drivers/crypto/fsl/desc.h create mode 100644 drivers/crypto/fsl/desc_constr.h create mode 100644 drivers/crypto/fsl/error.c create mode 100644 drivers/crypto/fsl/fsl_blob.c create mode 100644 drivers/crypto/fsl/fsl_hash.c create mode 100644 drivers/crypto/fsl/jobdesc.c create mode 100644 drivers/crypto/fsl/jobdesc.h create mode 100644 drivers/crypto/fsl/jr.c create mode 100644 drivers/crypto/fsl/jr.h create mode 100644 include/fsl_sec.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] common/memsize.c: Coding style cleanup
Prepare code to make later modifications checkpatch-clean.
Signed-off-by: Wolfgang Denk w...@denx.de
---
common/memsize.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 589400d..0fb9ba5 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -33,43 +33,46 @@ long get_ram_size(long *base, long maxsize)
long size;
inti = 0;
- for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
+ for (cnt = (maxsize / sizeof(long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
- sync ();
+ sync();
save[i++] = *addr;
- sync ();
+ sync();
*addr = ~cnt;
}
addr = base;
- sync ();
+ sync();
save[i] = *addr;
- sync ();
+ sync();
*addr = 0;
- sync ();
+ sync();
if ((val = *addr) != 0) {
- /* Restore the original data before leaving the function.
-*/
- sync ();
+ /* Restore the original data before leaving the function. */
+ sync();
*addr = save[i];
for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt;
- sync ();
+ sync();
*addr = save[--i];
}
return (0);
}
- for (cnt = 1; cnt maxsize / sizeof (long); cnt = 1) {
+ for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt; /* pointer arith! */
val = *addr;
*addr = save[--i];
if (val != ~cnt) {
- size = cnt * sizeof (long);
- /* Restore the original data before leaving the
function.
+ size = cnt * sizeof(long);
+ /*
+* Restore the original data
+* before leaving the function.
*/
- for (cnt = 1; cnt maxsize / sizeof (long); cnt =
1) {
+ for (cnt = 1;
+cnt maxsize / sizeof(long);
+cnt = 1) {
addr = base + cnt;
*addr = save[--i];
}
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] memsize: Fix for bug in memory sizing code
Dear Gerd Hoffmann,
In message 1413910153-5907-1-git-send-email-kra...@redhat.com you wrote:
The original memory sizing code in get_ram_size clobbers the word
at the base address, but forgets to restore it.
The funny thing is that it avtually works on some boards. Do you have
an explanation for that?
- long save[32];
+ long save[32], save_base;
Why do you need another variable? The original code stores the value
as last entry in save[] - what's wrong with that?
+ save_base = base[0];
+ sync ();
You add this code here, but...
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
sync ();
@@ -43,8 +46,6 @@ long get_ram_size(long *base, long maxsize)
addr = base;
sync ();
- save[i] = *addr;
- sync ();
...remove it's equivalent here. Why would your code be any better
than the existing one?
- *addr = save[i];
for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt;
sync ();
*addr = save[--i];
}
+ base[0] = save_base;
Same here - the line you removed above does the very same as the one
you add here. In which way is the new code supposed to be different
or even better?
@@ -73,10 +74,12 @@ long get_ram_size(long *base, long maxsize)
addr = base + cnt;
*addr = save[--i];
}
+ base[0] = save_base;
return (size);
}
}
+ base[0] = save_base;
return (maxsize);
Agreed here. These two make sense to me. I still wonder why it works
on the boards I used for testing, while it's failing on yours.
Which exit path are you taking? The one at the end of the function,
i. e. return (maxsize) ? What happens if you double the memory
size to be checked?
I'll resend a slightly reworked patch in a minute; could you please
test if this works for you, too?
Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Q: Why do mountain climbers rope themselves together?
A: To prevent the sensible ones from going home.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] common/memsize.c: correctly restore all modified memory loations
The original memory sizing code in get_ram_size clobbers the word
at the base address, but forgets to restore it.
Unlike the (reverted) commit b8496cced856ff411f1eb2e4eff20f5abe7080b0
we save and restore the base address value at the start resp. at the
end of the function. It needs to stay cleared until the detection is
done, otherwise it will fail to detect the same piece of memory being
mapped multiple times into the address space.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Iwo Mergler iwo.merg...@netcommwireless.com
---
common/memsize.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/common/memsize.c b/common/memsize.c
index 0fb9ba5..d5827dd 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2004
+ * (C) Copyright 2004-2014
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
*
* SPDX-License-Identifier:GPL-2.0+
@@ -31,7 +31,7 @@ long get_ram_size(long *base, long maxsize)
long cnt;
long val;
long size;
- inti = 0;
+ inti = 0, last;
for (cnt = (maxsize / sizeof(long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
@@ -44,6 +44,7 @@ long get_ram_size(long *base, long maxsize)
addr = base;
sync();
save[i] = *addr;
+ last = i;
sync();
*addr = 0;
@@ -51,7 +52,7 @@ long get_ram_size(long *base, long maxsize)
if ((val = *addr) != 0) {
/* Restore the original data before leaving the function. */
sync();
- *addr = save[i];
+ *addr = save[last];
for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt;
sync();
@@ -62,7 +63,9 @@ long get_ram_size(long *base, long maxsize)
for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt; /* pointer arith! */
+ sync();
val = *addr;
+ sync();
*addr = save[--i];
if (val != ~cnt) {
size = cnt * sizeof(long);
@@ -74,12 +77,19 @@ long get_ram_size(long *base, long maxsize)
cnt maxsize / sizeof(long);
cnt = 1) {
addr = base + cnt;
+ sync();
*addr = save[--i];
}
+ addr = base;
+ sync();
+ *addr = save[last];
return (size);
}
}
+ addr = base;
+ sync();
+ *addr = save[last];
return (maxsize);
}
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: TQM5200: convert to generic board
Signed-off-by: Wolfgang Denk w...@denx.de --- include/configs/TQM5200.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/configs/TQM5200.h b/include/configs/TQM5200.h index 69c0336..2c1c91f 100644 --- a/include/configs/TQM5200.h +++ b/include/configs/TQM5200.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2003-2005 + * (C) Copyright 2003-2014 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * (C) Copyright 2004-2006 @@ -20,6 +20,9 @@ #define CONFIG_TQM5200 1 /* ... on TQM5200 module */ #undef CONFIG_TQM5200_REV100 /* define for revision 100 modules */ +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD + /* * Valid values for CONFIG_SYS_TEXT_BASE are: * 0xFC00 boot low (standard configuration with room for -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] common/memsize.c: correctly restore all modified memory loations
Note: there is no patch 3/3 in his series. It was originally [PATCH] powerpc: TQM5200: convert to generic board but this is actually not related to these changes here, so I decided to post it independently. Sorry for the confusion. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I knew then (in 1970) that a 4-kbyte minicomputer would cost as much as a house. So I reasoned that after college, I'd have to live cheaply in an apartment and put all my money into owning a computer. - Apple co-founder Steve Wozniak, EE Times, June 6, 1988, pg 45 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Correct single misspelling of consitant in source tree.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h index 5d18a4b..1ecc0bb 100644 --- a/include/config_distro_defaults.h +++ b/include/config_distro_defaults.h @@ -10,7 +10,7 @@ /* * List of all commands and options that when defined enables support for * features required by distros to support boards in a standardised and - * consitant manner. + * consistent manner. */ #define CONFIG_BOOTP_BOOTPATH -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: o2dnt: convert to generic board
Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/o2dnt-common.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/o2dnt-common.h b/include/configs/o2dnt-common.h index 133dc6f..b716d05 100644 --- a/include/configs/o2dnt-common.h +++ b/include/configs/o2dnt-common.h @@ -17,6 +17,8 @@ * High Level Configuration Options */ #define CONFIG_MPC5200 +#define CONFIG_DISPLAY_BOARDINFO +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_SYS_MPC5XXX_CLKIN 3300 /* running at 33.00MHz */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Correct two non-functional misspellings overrided.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- given that the typoes occur in Kconfig help and a comment, the changes are effectively non-functional. diff --git a/dts/Kconfig b/dts/Kconfig index 83ba7a6..5fe63f8 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -49,7 +49,7 @@ config DEFAULT_DEVICE_TREE string Default Device Tree for DT control help This option specifies the default Device Tree used for DT control. - It can be overrided from the command line: + It can be overridden from the command line: $ make DEVICE_TREE=device-tree-name endmenu diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh index 81b0c61..efa4733 100755 --- a/scripts/kconfig/merge_config.sh +++ b/scripts/kconfig/merge_config.sh @@ -87,7 +87,7 @@ TMP_FILE=$(mktemp ./.tmp.config.XX) echo Using $INITFILE as base cat $INITFILE $TMP_FILE -# Merge files, printing warnings on overrided values +# Merge files, printing warnings on overridden values for MERGE_FILE in $MERGE_LIST ; do echo Merging $MERGE_FILE CFG_LIST=$(sed -n $SED_CONFIG_EXP $MERGE_FILE) -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert sunxi: dram: Use divisor P=1 for PLL5
On Thu, Oct 16, 2014 at 10:48:34AM +0200, Hans de Goede wrote: Hi, On 10/15/2014 12:34 PM, Siarhei Siamashka wrote: On Wed, 15 Oct 2014 12:12:11 +0200 Hans de Goede hdego...@redhat.com wrote: This change breaks various hardcoded assumptions in the linux-sunxi-3.4 kernels, causing a divide by 0 error in the linux-sunxi-3.4 nand driver, rendering 3.4 kernels unbootable. Besides this problem, it also breaks LCD output (on devices without nand). Fixes for these issues are being added to the linux-sunxi-3.4 kernel, but for now it seems better to revert this. This reverts commit 013f2d746955147439215a4939655c9ed6bdd866. As mentioned in the commit message https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg07884.html the hardcoded assumptions in the sunxi-3.4 kernel are still bad with or without this revert if somebody tries to use higher DRAM clock speeds. The patch in question just smokes out bugs, which are otherwise still there. Going forward, the mainline kernel needs the G2D driver and it needs to run at a decent clock speed to be provide reasonable performance. Low PLL5P clock speed is limiting our options. This revert does not do anyone any favour and only postpones the resolution of the problem. I agree that we need to fix the linux-sunxi-3.4 kernels to work properly with different pll5 settings, which is why I've actually send a fix for some pll5 issues to the linux-sunxi list and acked your patches which fix other bits. I can understand you want to have optimal settings for the G2D stuff, and I'm not against that. But getting the G2D stuff upstream is something which is still far in the future. I really want people to be able to start using upstream u-boot, starting today. And it will take some time for the sunxi-3.4 fixes to trickle down to users. We should be doing things right, in mainline. To bring up a different example, on TI OMAP4 parts at least for a long time in order to use mainline U-Boot on older kernels you had to manually add CONFIG_SOMETHING_OR_ANOTHER to enable additional clocks/mux that the old kernels had incorrectly relied on U-Boot to set. If we must do strange things to support old and incorrect but in the wild kernels we need to (a) make it opt-in (easier now with Kconfig!) and (b) schedule a removal of the hack all the same. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] make help talks about starred targets when nothing is starred
running make help concludes with the claim: Execute make or make all to build all targets marked with [*] but i see no make targets marked that way -- i suspect that was just a copy and paste from the kernel Makefile, yes? rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] spi: altera: Use struct-based register access
On Monday, October 20, 2014 at 07:19:33 PM, Jagan Teki wrote:
On 20 October 2014 20:40, Marek Vasut ma...@denx.de wrote:
On Monday, October 20, 2014 at 04:53:15 PM, Jagan Teki wrote:
[...]
-#define ALTERA_SPI_RXDATA 0
-#define ALTERA_SPI_TXDATA 4
-#define ALTERA_SPI_STATUS 8
-#define ALTERA_SPI_CONTROL 12
-#define ALTERA_SPI_SLAVE_SEL 20
+struct altera_spi_regs {
+ u32 rxdata;
+ u32 txdata;
+ u32 status;
+ u32 control;
+ u32 _reserved;
+ u32 slave_sel;
+};
Can you place this structure definition below of all macro defines, i
don't think the
next level patches does that, does they?
Does it make sense to you, to first define the bits in registers and then
the register layout ? It does not make sense to me, so I would prefer to
keep it like it is.
You're correct the way you replaced, usually the driver code will go like
this
-- includes
-- macros definitions
-- global or structure definitions
-- driver function calls.
We follow this [1] to make the driver more readable.
[1] http://patchwork.ozlabs.org/patch/265683/
I'm not sure what I am supposed to follow in the link above. Is it fine to
assume that this patch does not need any change then ?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] memsize: Fix for bug in memory sizing code
On Di, 2014-10-21 at 22:14 +0200, Wolfgang Denk wrote:
Dear Gerd Hoffmann,
In message 1413910153-5907-1-git-send-email-kra...@redhat.com you wrote:
The original memory sizing code in get_ram_size clobbers the word
at the base address, but forgets to restore it.
The funny thing is that it avtually works on some boards. Do you have
an explanation for that?
Sure. If the same piece of memory appears multiple times in the address
space the base address value is saved and restored multiple times too.
- long save[32];
+ long save[32], save_base;
Why do you need another variable? The original code stores the value
as last entry in save[] - what's wrong with that?
last entry index isn't known at the places where I save/restore the
value, so I did it this way. Alternative approach would be to use the
first index instead and shift all the other values by one. Matter of
taste, both will get the job done.
+ save_base = base[0];
+ sync ();
You add this code here, but...
for (cnt = (maxsize / sizeof (long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
sync ();
@@ -43,8 +46,6 @@ long get_ram_size(long *base, long maxsize)
addr = base;
sync ();
- save[i] = *addr;
- sync ();
...remove it's equivalent here. Why would your code be any better
than the existing one?
There can be multiple saves/restores for the base memory location (see
above). Therefore the ordering matters, restore must use the reverse
order of save. No exception for base[0], so when we restore it last we
must save it first.
- *addr = save[i];
for (cnt = 1; cnt maxsize / sizeof(long); cnt = 1) {
addr = base + cnt;
sync ();
*addr = save[--i];
}
+ base[0] = save_base;
Same here - the line you removed above does the very same as the one
you add here. In which way is the new code supposed to be different
or even better?
... and we must restore it last everywhere.
@@ -73,10 +74,12 @@ long get_ram_size(long *base, long maxsize)
addr = base + cnt;
*addr = save[--i];
}
+ base[0] = save_base;
return (size);
}
}
+ base[0] = save_base;
return (maxsize);
Agreed here. These two make sense to me. I still wonder why it works
on the boards I used for testing, while it's failing on yours.
Which exit path are you taking? The one at the end of the function,
i. e. return (maxsize) ? What happens if you double the memory
size to be checked?
Both cases can happen, depending on how much memory I configure for
qemu, and both are working correctly for me.
cheers,
Gerd
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] common/memsize.c: correctly restore all modified memory loations
Hi,
Signed-off-by: Gerd Hoffmann kra...@redhat.com
No, I didn't signed this patch off.
And I will not because it is broken.
for (cnt = (maxsize / sizeof(long)) 1; cnt 0; cnt = 1) {
addr = base + cnt; /* pointer arith! */
@@ -44,6 +44,7 @@ long get_ram_size(long *base, long maxsize)
addr = base;
sync();
save[i] = *addr;
base[0] might not be the original value any more at this point ...
+ addr = base;
+ sync();
+ *addr = save[last];
return (maxsize);
... so this may corrupt memory.
cheers,
Gerd
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sabresd: Add Seiko WVGA panel support
From: Fabio Estevam fabio.este...@freescale.com
Add support for the 4.3'' Seiko WVGA parallel display.
In order to direct the splash screen to the Seiko display:
= setenv panel SEIKO-WVGA
= save
= reset
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 81dcd6e..3d81fff 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -51,6 +51,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_PAD MUX_PAD_CTRL(I2C_PAD_CTRL)
+#define DISP0_PWR_EN IMX_GPIO_NR(1, 21)
+
int dram_init(void)
{
gd-ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
@@ -141,6 +143,45 @@ iomux_v3_cfg_t const ecspi1_pads[] = {
MX6_PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
+static iomux_v3_cfg_t const rgb_pads[] = {
+ MX6_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DI0_PIN15__IPU1_DI0_PIN15 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DI0_PIN2__IPU1_DI0_PIN02 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DI0_PIN3__IPU1_DI0_PIN03 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DI0_PIN4__IPU1_DI0_PIN04 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ MX6_PAD_SD1_DAT3__GPIO1_IO21 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static void enable_rgb(struct display_info_t const *dev)
+{
+ imx_iomux_v3_setup_multiple_pads(rgb_pads, ARRAY_SIZE(rgb_pads));
+ gpio_direction_output(DISP0_PWR_EN, 1);
+}
+
static struct i2c_pads_info i2c_pad_info1 = {
.scl = {
.i2c_mode = MX6_PAD_KEY_COL3__I2C2_SCL | I2C_PAD,
@@ -357,6 +398,26 @@ struct display_info_t const displays[] = {{
.vsync_len = 10,
.sync = FB_SYNC_EXT,
.vmode = FB_VMODE_NONINTERLACED
+} }, {
+ .bus= 0,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_RGB24,
+ .detect = NULL,
+ .enable = enable_rgb,
+ .mode = {
+ .name = SEIKO-WVGA,
+ .refresh= 60,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = 29850,
+ .left_margin= 89,
+ .right_margin = 164,
+ .upper_margin = 23,
+ .lower_margin = 10,
+ .hsync_len = 10,
+ .vsync_len = 10,
+ .sync = 0,
+ .vmode = FB_VMODE_NONINTERLACED
} } };
size_t display_count = ARRAY_SIZE(displays);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] git bisect failed
On Tue, Oct 21, 2014 at 2:47 PM, Fabio Estevam feste...@gmail.com wrote: Hi Christian, On Tue, Oct 21, 2014 at 9:43 AM, Christian Gmeiner christian.gmei...@gmail.com wrote: Hi all. Finally I got basic board support for OT1200 into upstream, but the last released version fails to detect SPI flash (read only ff's). I can confirm that 2014.10 has a SPI probe issue on a mx6qsabresd as well: Ops, I was testing on wrong board (one which has no SPI flash populated :-) Tested on another mx6qsabresd and it detectes the SPI correctly: = sf probe SF: Detected M25P32 with page size 256 Bytes, erase size 64 KiB, total 4 MiB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] dm: rpi: Move Raspberry Pi to use driver model
Hi Stephen, On 20 October 2014 20:23, Stephen Warren swar...@wwwdotorg.org wrote: On 10/19/2014 09:14 PM, Simon Glass wrote: Hi Stephen, On 17 October 2014 20:51, Stephen Warren swar...@wwwdotorg.org wrote: On 09/30/2014 07:41 PM, Stephen Warren wrote: On 09/22/2014 05:30 PM, Simon Glass wrote: This series adds driver model support to the GPIO and serial drivers used by Raspberry Pi, and moves Raspberry Pi over to driver model. This requires adding driver model support to the pl01x serial driver, and replacing the bcm2835 GPIO driver with a driver model version (since there are no longer clients that don't use driver model). See u-boot-dm.git branch rpi-working for the tree this is based on. The series, Tested-by: Stephen Warren swar...@wwwdotorg.org Hmm. I take that back. Patch 4 causes a problem, at least when applied on top of u-boot/master from today. Basic serial output works just fine, and I can interact with U-Boot without issue. However, when the boot scripts execute and load an extlinux.conf, U-Boot hangs. Up to patch 3, everything is fine. U-Boot 2014.10-4-g7830ed7 (Oct 17 2014 - 20:47:19) DRAM: 480 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In:serial Out: lcd Err: lcd reading /uEnv.txt 24 bytes read in 14 ms (1000 Bytes/s) Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf reading /extlinux/extlinux.conf (U-Boot hangs here) Can you please point me to where I can get an image to try this with? Also did you check with dm/next? There may be dependent patches, although the nature of the problem suggests not. I use (a pretty old version of, but I doubt that matters) RPi Foundation's Raspbian image, and compiled the kernel and U-Boot according to: http://elinux.org/index.php?title=RPi_Upstream_Kernel_Compilationoldid=351104 http://elinux.org/RPi_U-Boot I installed the Raspbian image but I don't get uImg.txt nor the same boot sequence. I am able to boot a kernel though. Do you have your settings or images uploaded somewhere? Also please confirm you used dm/next. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: asix: Add support for AX88772B
Hi Marek, I am still not seeing this patch in mainline ; maybe you will want to take it as you suggested? Thanks, Alex. On 10/10/2014 12:10 AM, Marek Vasut wrote: On Thursday, October 09, 2014 at 05:43:30 AM, Alexandre Courbot wrote: This USB device works as-is on this driver. Signed-off-by: Alexandre Courbot acour...@nvidia.com Acked-by: Marek Vasut ma...@denx.de It's a network device, but it's also USB. Joe, do you want to pick this up please? Alexandre, please keep an eye on the patch and if it doesn't get picked up for a week or so, poke me and I'll pick it through USB. I would be even OK if such a trivial thing made it into 2014.10, but I'm not in position to vouch on that right now. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
