Re: [U-Boot] [PATCH v3 04/18] net: mdio: Add private MDIO read/write function
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alison Wang Sent: Thursday, August 14, 2014 10:45 AM To: Sun York-R58495; u-boot@lists.denx.de Subject: [U-Boot] [PATCH v3 04/18] net: mdio: Add private MDIO read/write function As extra FPGA settings is needed for MDIO read/write on LS1021AQDS, private MDIO read/write functions are created. [S.H] There are examples of how to handle MDIO bus read/write with FPGA settings, check board/freescale/corenet_ds/eth_hydra.c board/freescale/corenet_ds/eth_p4080.c not necessary to add private stuff here. Best Regards, Shaohui Xie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] thor integration with ci_udc
Hi S, Hi Stephen, Thanks for your reply. I used your patches after 2014.07 and able to test the DFU successfully using ci_udc,but not thor it looks like that it needs some patches to work for thor. I can only add that thor shares code with dfu to perform correct operation. At least on the s3c_hsotg UDC driver I didn't need any extra modifications. Regards, DP On Wed, Aug 13, 2014 at 9:38 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/13/2014 04:58 AM, S Durga Prasad Paladugu wrote: Hi, Does anyone tested by integrating thor functionality with the ci_udc driver instead of samsung s3c_udc_otg? I am trying to do the same on my zynq board then the enumeration was successful but not able to download the file using lthor. Any other inputs on this would be fine. I haven't used the Thor protocol, but I have used both USB mass storage (UMS) and Device Firmware Upgrade (DFU) with success on an NVIDIA Tegra system. DFU at least required some patches that have been merged after v2014.07, but I think that was all to the DFU stack, not ci_udc itself. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mtd: nand: add Freescale NFC driver
On 13 Aug 2014, scottw...@freescale.com wrote: On Tue, 2014-08-12 at 18:58 -0400, Bill Pringlemeir wrote: On 12 Aug 2014, scottw...@freescale.com wrote: On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote: Am 2014-08-12 00:33, schrieb Scott Wood: You should always be using raw I/O accessors. If the intent is to bypass I/O ordering for certain registers, the raw accessors should already be skipping that. Ok, will do. Sorry, the above should say always be using I/O accesors, not always raw ones. This is probably because of me. There are lines like this for configuration, /* Set configuration register. */ nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT); nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BUFNO_AUTO_INCR_BIT); nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BOOT_MODE_BIT); nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_DMA_REQ_BIT); nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_FAST_FLASH_BIT); If you use some sort of 'volatile', you are saying to the compiler that these lines are *not*, ldr r0, [r1, #CONFIG]# read previous value ldr r2, =~MASK orr r0, #FAST_FLASH_BIT # set one bit. and r0, r2 # clear all bits at once. str r0, [r1, #CONFIG]# write it back. Instead it will change into five different load/modify/stores. The memory itself is just like SRAM except a few registers that are actually volatile; ie changed via the hardware. If this is performance-critical then it would be best to modify the code to explicitly do one read from I/O (if you can't know in advance what the existing value will be), clear all the bits you're going to clear, then have one explicit write back to the I/O device -- rather than treating it as ordinary memory for the compiler to optimize accesses to. If nothing else, it makes the code clearer to make I/O accesses explicit, and reduces the likelihood that people see I/O accesses without accessors and go on to do the same in some other less safe circumstance. Yes, absolutely. The issue is that the 'nfc_clear()', etc seems more programmer friendly to me. It was from an original driver. I believe this is what Stefan means by 'optimized' and not 'raw_readl/raw_writel' versus 'readl/writel'. I believe that this is smaller/faster in all cases; not just hot paths as the code should be smaller. I tried to modify the accessor to leave the original code as is. The registers are a bunch of bit fields. It is clear to read them each as being set/cleared on a different lines? However, the whole group can be set at once at the machine level. Sometimes the bit fields aren't so related. So, if you are trying to write the code about what is happening to the NAND flash (Ie cycles to run) then ganging the NFC controller registers together can make things a little more obscure. Maybe this is a small price to pay if the register ordering is more of an issue to people. The accesses are generally all order independent *when idle*. There is one bit of the NFC_FLASH_CMD2 register as bit0 or START_BIT in the code. When it is toggled, the NFC controller starts it's business and then only a few register can be polled or an interrupt generated. In this phase, no register changes should take place or at least care should be taken. I have only compiler barriers in the driver I submitted to the Linux MTD. It is possible that the PowerPC or other multi-issue CPUs might need the iowmb() or otherwise when the 'START_BIT' is toggled. I had thought of this in the mean time, so thank-you for bringing it up. Allowing the compiler to re-order the settings of the registers when idle can let it decide to do all the zeroing at once, etc depending on what is optimal. The 'read/modify many/write' is a happy medium for me. Minimizing accesses to the registers is important as these often involve a slow bus interface and also generate a lot of code for load/store CPUs. Regarding can't know in advance, I think that some of the register values maybe set by the boot rom. This might make more sense for Linux than U-Boot. However, after the initial configuration, many do need the 'read/modify/write' as there are many bit fields with different functionality. Thanks, Bill Pringlemeir. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 16/18] arm: mx6: cm_fx6: add i2c support
On 08/10/14 20:12, Nikita Kiryanov wrote: Add support for all 3 I2C busses on Compulab CM-FX6 CoM. Cc: Igor Grinberg grinb...@compulab.co.il Cc: Stefano Babic sba...@denx.de Cc: Tom Rini tr...@ti.com Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] samsung: dfu: Provide correct Vendor and Product IDs for UMS gadget
Hi Minkyu,
It is necessary to provide the same Vendor and Product IDs as the one
in the original Linux kernel code.
Without this change the USB mass storage gadget is not working with
Windows7.
Do you have any comments to this patch?
Would you consider taking this patch to u-boot-samsung tree or should I
take it to u-boot-dfu since it fixes things related to UMS gadget?
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
board/samsung/common/Makefile | 2 +-
board/samsung/common/gadget.c | 24
board/samsung/common/thor.c | 21 -
include/configs/exynos4-dt.h | 2 ++
4 files changed, 27 insertions(+), 22 deletions(-)
create mode 100644 board/samsung/common/gadget.c
delete mode 100644 board/samsung/common/thor.c
diff --git a/board/samsung/common/Makefile
b/board/samsung/common/Makefile index 41d0cc3..93347ef 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -6,7 +6,7 @@
#
obj-$(CONFIG_SOFT_I2C_MULTI_BUS) += multi_i2c.o
-obj-$(CONFIG_THOR_FUNCTION) += thor.o
+obj-$(CONFIG_USBDOWNLOAD_GADGET) += gadget.o
obj-$(CONFIG_MISC_COMMON) += misc.o
ifndef CONFIG_SPL_BUILD
diff --git a/board/samsung/common/gadget.c
b/board/samsung/common/gadget.c new file mode 100644
index 000..6a1e57f
--- /dev/null
+++ b/board/samsung/common/gadget.c
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ * Lukasz Majewski l.majew...@samsung.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include common.h
+#include linux/usb/ch9.h
+
+int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char
*name) +{
+ if (!strcmp(name, usb_dnl_thor)) {
+ put_unaligned(CONFIG_G_DNL_THOR_VENDOR_NUM,
dev-idVendor);
+ put_unaligned(CONFIG_G_DNL_THOR_PRODUCT_NUM,
dev-idProduct);
+ } else if (!strcmp(name, usb_dnl_ums)) {
+ put_unaligned(CONFIG_G_DNL_UMS_VENDOR_NUM,
dev-idVendor);
+ put_unaligned(CONFIG_G_DNL_UMS_PRODUCT_NUM,
dev-idProduct);
+ } else {
+ put_unaligned(CONFIG_G_DNL_VENDOR_NUM,
dev-idVendor);
+ put_unaligned(CONFIG_G_DNL_PRODUCT_NUM,
dev-idProduct);
+ }
+ return 0;
+}
diff --git a/board/samsung/common/thor.c b/board/samsung/common/thor.c
deleted file mode 100644
index 1c7630d..000
--- a/board/samsung/common/thor.c
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Copyright (C) 2013 Samsung Electronics
- * Lukasz Majewski l.majew...@samsung.com
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#include common.h
-#include linux/usb/ch9.h
-
-int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char
*name) -{
- if (!strcmp(name, usb_dnl_thor)) {
- put_unaligned(CONFIG_G_DNL_THOR_VENDOR_NUM,
dev-idVendor);
- put_unaligned(CONFIG_G_DNL_THOR_PRODUCT_NUM,
dev-idProduct);
- } else {
- put_unaligned(CONFIG_G_DNL_VENDOR_NUM,
dev-idVendor);
- put_unaligned(CONFIG_G_DNL_PRODUCT_NUM,
dev-idProduct);
- }
- return 0;
-}
diff --git a/include/configs/exynos4-dt.h
b/include/configs/exynos4-dt.h index 44e6ab4..7dac1a3 100644
--- a/include/configs/exynos4-dt.h
+++ b/include/configs/exynos4-dt.h
@@ -105,6 +105,8 @@
#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
#define CONFIG_G_DNL_THOR_VENDOR_NUM CONFIG_G_DNL_VENDOR_NUM
#define CONFIG_G_DNL_THOR_PRODUCT_NUM 0x685D
+#define CONFIG_G_DNL_UMS_VENDOR_NUM 0x0525
+#define CONFIG_G_DNL_UMS_PRODUCT_NUM 0xA4A5
#define CONFIG_G_DNL_MANUFACTURER Samsung
/* Miscellaneous configurable options */
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 17/18] arm: mx6: cm_fx6: use eeprom
On 08/10/14 20:12, Nikita Kiryanov wrote:
Use Compulab eeprom module to obtain revision number, serial number, and
mac address from the EEPROM.
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
Changes in V2:
- No changes
board/compulab/cm_fx6/cm_fx6.c | 26 +-
include/configs/cm_fx6.h | 2 ++
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index 1b967e5..76d7430 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
[...]
@@ -348,5 +372,5 @@ int dram_init(void)
u32 get_board_rev(void)
{
- return 100;
+ return cl_eeprom_get_board_rev();
}
I would expect this function to be introduced here and
not before this patch - along with I2C support and CONFIG_REVISION_TAG.
diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
index 0aa88fd..adfd55e 100644
--- a/include/configs/cm_fx6.h
+++ b/include/configs/cm_fx6.h
@@ -236,6 +236,8 @@
#define CONFIG_SYS_BOOTMAPSZ (8 20)
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
+#define CONFIG_REVISION_TAG
+#define CONFIG_SERIAL_TAG
/* misc */
#define CONFIG_SYS_GENERIC_BOARD
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 18/18] arm: mx6: cm_fx6: add sata support
Hi Nikita,
On 08/10/14 20:13, Nikita Kiryanov wrote:
Add support for SATA.
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
Changes in V2:
- No changes
board/compulab/cm_fx6/cm_fx6.c | 90
++
board/compulab/cm_fx6/common.h | 13 ++
include/configs/cm_fx6.h | 36 -
3 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
index 76d7430..8a48f9d 100644
--- a/board/compulab/cm_fx6/cm_fx6.c
+++ b/board/compulab/cm_fx6/cm_fx6.c
[...]
@@ -23,6 +25,94 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_DWC_AHSATA
+static int cm_fx6_issd_gpios[] = {
+ /* The order of the GPIOs in the array is important! */
+ CM_FX6_SATA_PHY_SLP,
+ CM_FX6_SATA_NRSTDLY,
+ CM_FX6_SATA_PWREN,
+ CM_FX6_SATA_NSTANDBY1,
+ CM_FX6_SATA_NSTANDBY2,
+ CM_FX6_SATA_LDO_EN,
+};
+
+static void cm_fx6_sata_power(int on)
Will it be/look better to use bool here?
+{
+ int i;
+
+ if (!on) { /* tell the iSSD that the power will be removed */
+ gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 1);
+ mdelay(10);
+ }
+
+ for (i = 0; i ARRAY_SIZE(cm_fx6_issd_gpios); i++) {
+ gpio_direction_output(cm_fx6_issd_gpios[i], on);
+ udelay(100);
+ }
+
+ if (!on) /* for compatibility lower the power loss interrupt */
+ gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
+}
[...]
+static void cm_fx6_setup_issd(void)
+{
+ SETUP_IOMUX_PADS(sata_pads);
+ /* Make sure this gpio has logical 0 value */
+ gpio_direction_output(CM_FX6_SATA_PWLOSS_INT, 0);
+ udelay(100);
+
+ cm_fx6_sata_power(0);
+ mdelay(250);
+ cm_fx6_sata_power(1);
+}
+
+#define CM_FX6_SATA_INIT_RETRIES 10
+int sata_initialize(void)
+{
+ int err, i;
+
+ cm_fx6_setup_issd();
+ for (i = 0; i CM_FX6_SATA_INIT_RETRIES; i++) {
+ err = setup_sata();
+ if (err) {
+ printf(SATA setup failed: %d\n, err);
+ return err;
+ }
+
+ udelay(100);
+
+ err = __sata_initialize();
+ if (!err)
+ break;
+
+ /* There is no device on the SATA port */
+ if (sata_port_status(0, 0) == 0)
+ break;
+
+ /* There's a device, but link not established. Retry */
+ }
+
+ return err;
+}
+#else
+static void cm_fx6_setup_issd(void) {}
Why do you need this one?
It is only called from sata_initialize(), which is inside
#ifdef CONFIG_DWC_AHSATA
and is not available otherwise.
+#endif
+
#ifdef CONFIG_SYS_I2C_MXC
#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
[...]
diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h
index adfd55e..88925cd 100644
--- a/include/configs/cm_fx6.h
+++ b/include/configs/cm_fx6.h
@@ -132,6 +132,19 @@
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
run doboot\0 \
+ satadev=0\0 \
+ sataroot=/dev/sda2 rw rootwait\0 \
+ sataargs=setenv bootargs console=${console} \
+ root=${sataroot} \
+ ${video}\0 \
+ loadsatabootscript=fatload sata ${satadev} ${loadaddr} ${bootscr}\0 \
+ satabootscript=echo Running bootscript from sata ...; \
+ source ${loadaddr}\0 \
+ sataloadkernel=fatload sata ${satadev} ${loadaddr} ${kernel}\0 \
+ sataloadfdt=fatload sata ${satadev} ${fdtaddr} ${fdtfile}\0 \
Can we switch to use load instead of explicit fatload?
[...]
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 12/18] arm: mx6: add support for Compulab cm-fx6 CoM
On 08/13/14 15:55, Igor Grinberg wrote:
Hi Nikita,
Several comments below in addition to Simon's.
On 08/11/14 19:22, Nikita Kiryanov wrote:
Add initial support for Compulab CM-FX6 CoM.
Support includes MMC, SPI flash, and SPL with dynamic DRAM detection.
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Stefano Babic sba...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Marek Vasut ma...@denx.de
Acked-by: Marek Vasut ma...@denx.de
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
---
[...]
+#define CONFIG_EXTRA_ENV_SETTINGS \
+kernel=uImage-cm-fx6\0 \
+autoload=no\0 \
+loadaddr=0x1080\0 \
+fdtaddr=0x1100\0 \
+console=ttymxc3,115200\0 \
+ethprime=FEC0\0 \
+bootscr=boot.scr\0 \
+bootm_low=1800\0 \
+video_hdmi=mxcfb0:dev=hdmi,1920x1080M-32@50,if=RGB32\0 \
+video_dvi=mxcfb0:dev=dvi,1280x800M-32@50,if=RGB32\0 \
+fdtfile=cm-fx6.dtb\0 \
+doboot=bootm ${loadaddr}\0 \
+loadfdt=false\0 \
+setboottypez=setenv kernel zImage-cm-fx6; \
+setenv doboot bootz ${loadaddr} - ${fdtaddr}; \
+setenv loadfdt true;\0 \
+setboottypem=setenv kernel uImage-cm-fx6; \
+setenv doboot bootm ${loadaddr}; \
+setenv loadfdt false;\0\
+run_eboot=echo Starting EBOOT ...; \
+mmc dev ${mmcdev} \
+mmc rescan mmc read 10042000 a 400 go 10042000\0 \
+mmcdev=2\0 \
+mmcroot=/dev/mmcblk0p2 rw rootwait\0 \
+loadmmcbootscript=fatload mmc ${mmcdev} ${loadaddr} ${bootscr}\0 \
Can we switch to use load instead of fatload?
+mmcbootscript=echo Running bootscript from mmc ...; \
+source ${loadaddr}\0 \
+mmcargs=setenv bootargs console=${console} \
+root=${mmcroot} \
+${video}\0 \
+mmcloadkernel=fatload mmc ${mmcdev} ${loadaddr} ${kernel}\0 \
+mmcloadfdt=fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0 \
+mmcboot=echo Booting from mmc ...; \
+run mmcargs; \
+run doboot\0 \
+nandroot=/dev/mtdblock4 rw\0 \
+nandrootfstype=ubifs\0 \
+nandargs=setenv bootargs console=${console} \
+root=${nandroot} \
+rootfstype=${nandrootfstype} \
+${video}\0 \
+nandloadfdt=nand read ${fdtaddr} 78 8;\0 \
+nandboot=echo Booting from nand ...; \
+run nandargs; \
+nand read ${loadaddr} 0 78; \
+if ${loadfdt}; then \
+run nandloadfdt; \
+fi; \
+run doboot\0 \
I think, if we add NAND support in a separate patch, then probably
it will be better also to add nand boot related environment stuff
along with the NAND support.
+boot=mmc dev ${mmcdev}; \
+if mmc rescan; then \
+if run loadmmcbootscript; then \
+run mmcbootscript; \
+else \
+if run mmcloadkernel; then \
+if ${loadfdt}; then \
+run mmcloadfdt; \
+fi; \
+run mmcboot; \
+fi; \
+fi; \
+fi;
Also, you add NAND boot commands neither here, nor in the NAND
support patch. Can we have them too? Please?
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 02/18] ls102xa: i2c: Add i2c support for LS102xA
This patch is to add I2C 1,2,3 support for LS102xA.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: Add commit messages.
v3: Add I2C 3 support.
v2: No change.
drivers/i2c/mxc_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index c14797c..83a9ffa 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -423,7 +423,7 @@ static void * const i2c_bases[] = {
(void *)IMX_I2C2_BASE
#elif defined(CONFIG_MX31) || defined(CONFIG_MX35) || \
defined(CONFIG_MX51) || defined(CONFIG_MX53) || \
- defined(CONFIG_MX6)
+ defined(CONFIG_MX6) || defined(CONFIG_LS102xA)
(void *)I2C1_BASE_ADDR,
(void *)I2C2_BASE_ADDR,
(void *)I2C3_BASE_ADDR
@@ -545,7 +545,7 @@ U_BOOT_I2C_ADAP_COMPLETE(mxc1, mxc_i2c_init, mxc_i2c_probe,
CONFIG_SYS_MXC_I2C2_SLAVE, 1)
#if defined(CONFIG_MX31) || defined(CONFIG_MX35) ||\
defined(CONFIG_MX51) || defined(CONFIG_MX53) ||\
- defined(CONFIG_MX6)
+ defined(CONFIG_MX6) || defined(CONFIG_LS102xA)
U_BOOT_I2C_ADAP_COMPLETE(mxc2, mxc_i2c_init, mxc_i2c_probe,
mxc_i2c_read, mxc_i2c_write,
mxc_i2c_set_bus_speed,
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 03/18] net: Merge asm/fsl_enet.h into fsl_mdio.h
From: Claudiu Manoil claudiu.man...@freescale.com
fsl_enet.h defines the mapping of the usual MII management
registers, which are included in the MDIO register block
common to Freescale ethernet controllers. So it shouldn't
depend on the CPU architecture but it should be actually
part of the arch independent fsl_mdio.h.
To remove the arch dependency, merge the content of
asm/fsl_enet.h into fsl_mdio.h.
Some files (like fm_eth.h) were simply including fsl_enet.h
only for phy.h. These were updated to include phy.h instead.
Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com
---
Change log:
v4: No change.
v3: No change.
v2: No change.
arch/powerpc/include/asm/fsl_enet.h | 24
board/freescale/mpc8360emds/mpc8360emds.c | 2 +-
board/freescale/mpc837xemds/mpc837xemds.c | 1 -
drivers/net/fm/dtsec.c| 1 -
drivers/net/fm/fm.h | 2 +-
drivers/net/fm/init.c | 1 +
drivers/net/fm/memac.c| 1 -
drivers/net/fm/tgec.c | 1 -
drivers/net/fsl_mdio.c| 1 -
drivers/qe/uec.h | 1 -
include/fm_eth.h | 2 +-
include/fsl_mdio.h| 13 -
include/tsec.h| 2 +-
13 files changed, 17 insertions(+), 35 deletions(-)
delete mode 100644 arch/powerpc/include/asm/fsl_enet.h
diff --git a/arch/powerpc/include/asm/fsl_enet.h
b/arch/powerpc/include/asm/fsl_enet.h
deleted file mode 100644
index 96146b6..000
--- a/arch/powerpc/include/asm/fsl_enet.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Copyright 2010 Freescale Semiconductor, Inc.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __ASM_PPC_FSL_ENET_H
-#define __ASM_PPC_FSL_ENET_H
-
-#include phy.h
-
-struct tsec_mii_mng {
- u32 miimcfg;/* MII management configuration reg */
- u32 miimcom;/* MII management command reg */
- u32 miimadd;/* MII management address reg */
- u32 miimcon;/* MII management control reg */
- u32 miimstat; /* MII management status reg */
- u32 miimind;/* MII management indication reg */
- u32 ifstat; /* Interface Status Register */
-} __attribute__ ((packed));
-
-int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc);
-
-#endif /* __ASM_PPC_FSL_ENET_H */
diff --git a/board/freescale/mpc8360emds/mpc8360emds.c
b/board/freescale/mpc8360emds/mpc8360emds.c
index ac96163..5ff9dff 100644
--- a/board/freescale/mpc8360emds/mpc8360emds.c
+++ b/board/freescale/mpc8360emds/mpc8360emds.c
@@ -11,13 +11,13 @@
#include i2c.h
#include miiphy.h
#include phy.h
+#include fsl_mdio.h
#if defined(CONFIG_PCI)
#include pci.h
#endif
#include spd_sdram.h
#include asm/mmu.h
#include asm/io.h
-#include asm/fsl_enet.h
#include asm/mmu.h
#if defined(CONFIG_OF_LIBFDT)
#include libfdt.h
diff --git a/board/freescale/mpc837xemds/mpc837xemds.c
b/board/freescale/mpc837xemds/mpc837xemds.c
index 0a3c972..c749e55 100644
--- a/board/freescale/mpc837xemds/mpc837xemds.c
+++ b/board/freescale/mpc837xemds/mpc837xemds.c
@@ -10,7 +10,6 @@
#include i2c.h
#include asm/io.h
#include asm/fsl_mpc83xx_serdes.h
-#include asm/fsl_enet.h
#include spd_sdram.h
#include tsec.h
#include libfdt.h
diff --git a/drivers/net/fm/dtsec.c b/drivers/net/fm/dtsec.c
index 78bbd43..8d3dc0e 100644
--- a/drivers/net/fm/dtsec.c
+++ b/drivers/net/fm/dtsec.c
@@ -7,7 +7,6 @@
#include common.h
#include asm/types.h
#include asm/io.h
-#include asm/fsl_enet.h
#include asm/fsl_dtsec.h
#include fsl_mdio.h
#include phy.h
diff --git a/drivers/net/fm/fm.h b/drivers/net/fm/fm.h
index 316e06e..a9691c6 100644
--- a/drivers/net/fm/fm.h
+++ b/drivers/net/fm/fm.h
@@ -8,8 +8,8 @@
#define __FM_H__
#include common.h
+#include phy.h
#include fm_eth.h
-#include asm/fsl_enet.h
#include asm/fsl_fman.h
/* Port ID */
diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index ff04695..6cf21c6 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -6,6 +6,7 @@
#include common.h
#include asm/io.h
#include asm/fsl_serdes.h
+#include fsl_mdio.h
#include fm.h
diff --git a/drivers/net/fm/memac.c b/drivers/net/fm/memac.c
index 592a67f..9499290 100644
--- a/drivers/net/fm/memac.c
+++ b/drivers/net/fm/memac.c
@@ -12,7 +12,6 @@
#include phy.h
#include asm/types.h
#include asm/io.h
-#include asm/fsl_enet.h
#include asm/fsl_memac.h
#include fm.h
diff --git a/drivers/net/fm/tgec.c b/drivers/net/fm/tgec.c
index f450f80..5017123 100644
--- a/drivers/net/fm/tgec.c
+++ b/drivers/net/fm/tgec.c
@@ -12,7 +12,6 @@
#include phy.h
#include asm/types.h
#include asm/io.h
-#include asm/fsl_enet.h
#include asm/fsl_tgec.h
#include fm.h
diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 1d88e65..8d09f5d 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
[U-Boot] [PATCH v4 05/18] net: mdio: Use mb() to be compatible for both ARM and PowerPC
Use mb() instead of sync assembly instruction to be compatible for both ARM and PowerPC. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: No change. v3: Use mb() to be compatible for both ARM and PowerPC. Split from the 0004-arm-ls102xa-Add-etsec-support-for-LS102xA patch. v2: Add private mdio read and write support. drivers/net/fsl_mdio.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c index 6eae78f..2657c44 100644 --- a/drivers/net/fsl_mdio.c +++ b/drivers/net/fsl_mdio.c @@ -19,7 +19,7 @@ void tsec_local_mdio_write(struct tsec_mii_mng __iomem *phyregs, int port_addr, out_be32(phyregs-miimadd, (port_addr 8) | (regnum 0x1f)); out_be32(phyregs-miimcon, value); - asm(sync); + mb(); while ((in_be32(phyregs-miimind) MIIMIND_BUSY) timeout--) ; @@ -37,11 +37,11 @@ int tsec_local_mdio_read(struct tsec_mii_mng __iomem *phyregs, int port_addr, /* Clear the command register, and wait */ out_be32(phyregs-miimcom, 0); - asm(sync); + mb(); /* Initiate a read command, and wait */ out_be32(phyregs-miimcom, MIIMCOM_READ_CYCLE); - asm(sync); + mb(); /* Wait for the the indication that the read is done */ while ((in_be32(phyregs-miimind) (MIIMIND_NOTVALID | MIIMIND_BUSY)) -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 07/18] ls102xa: esdhc: Add esdhc support for LS102xA
For LS102xA, the platform is little endian, while esdhc IP is
big endian. So two macros are added, CONFIG_SYS_FSL_ESDHC_LE
and CONFIG_SYS_FSL_ESDHC_BE, to determine the registers'
reading/writing in big or little endian format.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: No change.
v3: Add commit messages.
v2: No change.
drivers/mmc/fsl_esdhc.c | 4 ++--
include/fsl_esdhc.h | 14 +-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 5541613..aec459f 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -96,7 +96,7 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct
mmc_data *data)
else if (cmd-resp_type MMC_RSP_PRESENT)
xfertyp |= XFERTYP_RSPTYP_48;
-#if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240)
+#if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240) ||
defined(CONFIG_LS102xA)
if (cmd-cmdidx == MMC_CMD_STOP_TRANSMISSION)
xfertyp |= XFERTYP_CMDTYP_ABORT;
#endif
@@ -561,7 +561,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
memset(cfg-cfg, 0, sizeof(cfg-cfg));
voltage_caps = 0;
- caps = regs-hostcapblt;
+ caps = esdhc_read32(regs-hostcapblt);
#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC135
caps = caps ~(ESDHC_HOSTCAPBLT_SRS |
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index 9814964..c1b6648 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -162,7 +162,19 @@ struct fsl_esdhc_cfg {
};
/* Select the correct accessors depending on endianess */
-#if __BYTE_ORDER == __LITTLE_ENDIAN
+#if defined CONFIG_SYS_FSL_ESDHC_LE
+#define esdhc_read32 in_le32
+#define esdhc_write32 out_le32
+#define esdhc_clrsetbits32 clrsetbits_le32
+#define esdhc_clrbits32clrbits_le32
+#define esdhc_setbits32setbits_le32
+#elif defined(CONFIG_SYS_FSL_ESDHC_BE)
+#define esdhc_read32in_be32
+#define esdhc_write32 out_be32
+#define esdhc_clrsetbits32 clrsetbits_be32
+#define esdhc_clrbits32 clrbits_be32
+#define esdhc_setbits32 setbits_be32
+#elif __BYTE_ORDER == __LITTLE_ENDIAN
#define esdhc_read32 in_le32
#define esdhc_write32 out_le32
#define esdhc_clrsetbits32 clrsetbits_le32
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 01/18] arm: ls102xa: Add Freescale LS102xA SoC support
From: Wang Huan b18...@freescale.com
The QorIQ LS1 family is built on Layerscape architecture,
the industry's first software-aware, core-agnostic networking
architecture to offer unprecedented efficiency and scale.
Freescale LS102xA is a set of SoCs combines two ARM
Cortex-A7 cores that have been optimized for high
reliability and pack the highest level of integration
available for sub-3 W embedded communications processors
with Layerscape architecture and with a comprehensive
enablement model focused on ease of programmability.
Signed-off-by: Alison Wang alison.w...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
Signed-off-by: Jingchang Lu jingchang...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Change log:
v4: No change.
v3: Fix checkpatch errors.
v2: Add serdes support.
Update DDR frequency and data rate information.
Fix overflow condition error for the timer.
arch/arm/cpu/armv7/ls102xa/Makefile | 12 +
arch/arm/cpu/armv7/ls102xa/clock.c| 130 ++
arch/arm/cpu/armv7/ls102xa/cpu.c | 103 +
arch/arm/cpu/armv7/ls102xa/fdt.c | 128 ++
arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c | 119 ++
arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.h | 12 +
arch/arm/cpu/armv7/ls102xa/ls102xa_serdes.c | 41 ++
arch/arm/cpu/armv7/ls102xa/timer.c| 127 ++
arch/arm/include/asm/arch-ls102xa/clock.h | 23 ++
arch/arm/include/asm/arch-ls102xa/config.h| 71
arch/arm/include/asm/arch-ls102xa/fsl_serdes.h| 33 ++
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 461 ++
arch/arm/include/asm/arch-ls102xa/imx-regs.h | 53 +++
arch/arm/include/asm/config.h | 4 +
arch/arm/include/asm/io.h | 8 +-
drivers/watchdog/Makefile | 2 +-
16 files changed, 1325 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/cpu/armv7/ls102xa/Makefile
create mode 100644 arch/arm/cpu/armv7/ls102xa/clock.c
create mode 100644 arch/arm/cpu/armv7/ls102xa/cpu.c
create mode 100644 arch/arm/cpu/armv7/ls102xa/fdt.c
create mode 100644 arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c
create mode 100644 arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.h
create mode 100644 arch/arm/cpu/armv7/ls102xa/ls102xa_serdes.c
create mode 100644 arch/arm/cpu/armv7/ls102xa/timer.c
create mode 100644 arch/arm/include/asm/arch-ls102xa/clock.h
create mode 100644 arch/arm/include/asm/arch-ls102xa/config.h
create mode 100644 arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
create mode 100644 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
create mode 100644 arch/arm/include/asm/arch-ls102xa/imx-regs.h
diff --git a/arch/arm/cpu/armv7/ls102xa/Makefile
b/arch/arm/cpu/armv7/ls102xa/Makefile
new file mode 100644
index 000..d82ce8d
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/Makefile
@@ -0,0 +1,12 @@
+#
+# Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += cpu.o
+obj-y += clock.o
+obj-y += timer.o
+
+obj-$(CONFIG_OF_LIBFDT) += fdt.o
+obj-$(CONFIG_SYS_HAS_SERDES) += fsl_ls1_serdes.o ls102xa_serdes.o
diff --git a/arch/arm/cpu/armv7/ls102xa/clock.c
b/arch/arm/cpu/armv7/ls102xa/clock.c
new file mode 100644
index 000..8f80c61
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/clock.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/arch/immap_ls102xa.h
+#include asm/arch/clock.h
+#include fsl_ifc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_SYS_FSL_NUM_CC_PLLS
+#define CONFIG_SYS_FSL_NUM_CC_PLLS 2
+#endif
+
+void get_sys_info(struct sys_info *sys_info)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+#ifdef CONFIG_FSL_IFC
+ struct fsl_ifc *ifc_regs = (void *)CONFIG_SYS_IFC_ADDR;
+ u32 ccr;
+#endif
+ struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_LS1_CLK_ADDR);
+ unsigned int cpu;
+ const u8 core_cplx_pll[6] = {
+ [0] = 0,/* CC1 PPL / 1 */
+ [1] = 0,/* CC1 PPL / 2 */
+ [4] = 1,/* CC2 PPL / 1 */
+ [5] = 1,/* CC2 PPL / 2 */
+ };
+
+ const u8 core_cplx_pll_div[6] = {
+ [0] = 1,/* CC1 PPL / 1 */
+ [1] = 2,/* CC1 PPL / 2 */
+ [4] = 1,/* CC2 PPL / 1 */
+ [5] = 2,/* CC2 PPL / 2 */
+ };
+
+ uint i;
+ uint freq_c_pll[CONFIG_SYS_FSL_NUM_CC_PLLS];
+ uint ratio[CONFIG_SYS_FSL_NUM_CC_PLLS];
+ unsigned long sysclk = CONFIG_SYS_CLK_FREQ;
+
+ sys_info-freq_systembus = sysclk;
+#ifdef CONFIG_DDR_CLK_FREQ
+ sys_info-freq_ddrbus = CONFIG_DDR_CLK_FREQ;
+#else
+ sys_info-freq_ddrbus = sysclk;
+#endif
+
+
[U-Boot] [PATCH v4 0/18] arm: ls102xa: Add Freescale LS102xA SoC and LS1021AQDS/TWR board support
This series contain the support for Freescale LS102xA SoC and LS1021AQDS/TWR board. The QorIQ LS1 family is built on Layerscape architecture, the industry's first software-aware, core-agnostic networking architecture to offer unprecedented efficiency and scale. Freescale LS102xA is a set of SoCs combines two ARM Cortex-A7 cores that have been optimized for high reliability and pack the highest level of integration available for sub-3 W embedded communications processors with Layerscape architecture and with a comprehensive enablement model focused on ease of programmability. For the detail information about LS1021AQDS/TWR board, please refer to README in the patch. Changes in v4: - Add commit messages. Changes in v3: - Fix checkpatch errors. - Add I2C 3 support. - Split arm: ls102xa: Add etsec support for LS102xA into 3 patches. The 3 patches: net: mdio: Add private MDIO read/write function, net: mdio: Use mb() to be compatible for both ARM and PowerPC, ls102xa: etsec: Add etsec support for LS102xA. - Use mb() to be compatible for both ARM and PowerPC. - Update to Kconfig. - Add new patches: net: tsec: Remove tx snooping support from LS1 serial: lpuart: add 32-bit registers lpuart support arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board video: dcu: Add Sii9022A HDMI Transmitter support video: dcu: Add DCU driver support ls102xa: dcu: Add platform support for DCU on LS1021ATWR board Changes in v2: - Add serdes support. - Update DDR frequency and data rate information. - Fix overflow condition error for the timer. - Add private mdio read and write support. - Remove ethaddr/ipaddr setting. - Add board maintainer. - Add serdes and multiple ethernet controllers support. - Add new patch: arm: ls102xa: Add basic support for LS1021ATWR board ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 09/18] driver/ddr/freescale: Fix DDR3 driver for ARM
From: York Sun york...@freescale.com Reading DDR register should use ddr_in32() for proper endianess. This patch fixes incorrect waiting time for ARM platforms. Signed-off-by: York Sun york...@freescale.com --- Change log: v4: No change. v3: No change. v2: No change. drivers/ddr/fsl/arm_ddr_gen3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/fsl/arm_ddr_gen3.c b/drivers/ddr/fsl/arm_ddr_gen3.c index d4ed9ae..59f2fd6 100644 --- a/drivers/ddr/fsl/arm_ddr_gen3.c +++ b/drivers/ddr/fsl/arm_ddr_gen3.c @@ -194,7 +194,7 @@ step2: * For example, 2GB on 666MT/s 64-bit bus takes about 402ms * Let's wait for 800ms */ - bus_width = 3 - ((ddr-sdram_cfg SDRAM_CFG_DBW_MASK) + bus_width = 3 - ((ddr_in32(ddr-sdram_cfg) SDRAM_CFG_DBW_MASK) SDRAM_CFG_DBW_SHIFT); timeout = ((total_gb_size_per_controller (6 - bus_width)) * 100 / (get_ddr_freq(0) 20)) 1; -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 06/18] ls102xa: etsec: Add etsec support for LS102xA
For LS102xA, RxBDs and TxBDs are interpreted with little-endian
bytes ordering. The offset for each of eTSECs and MDIOs is
256K bytes.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: No change.
v3: No change.
v2: Add private mdio read and write support.
drivers/net/tsec.c | 7 +++
include/tsec.h | 7 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index e9138f0..a220221 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -20,6 +20,7 @@
#include fsl_mdio.h
#include asm/errno.h
#include asm/processor.h
+#include asm/io.h
DECLARE_GLOBAL_DATA_PTR;
@@ -270,6 +271,9 @@ void redundant_init(struct eth_device *dev)
out_be32(regs-tstat, TSTAT_CLEAR_THALT);
out_be32(regs-rstat, RSTAT_CLEAR_RHALT);
clrbits_be32(regs-dmactrl, DMACTRL_GRS | DMACTRL_GTS);
+#ifdef CONFIG_LS102xA
+ setbits_be32(regs-dmactrl, DMACTRL_LE);
+#endif
do {
uint16_t status;
@@ -366,6 +370,9 @@ static void startup_tsec(struct eth_device *dev)
out_be32(regs-tstat, TSTAT_CLEAR_THALT);
out_be32(regs-rstat, RSTAT_CLEAR_RHALT);
clrbits_be32(regs-dmactrl, DMACTRL_GRS | DMACTRL_GTS);
+#ifdef CONFIG_LS102xA
+ setbits_be32(regs-dmactrl, DMACTRL_LE);
+#endif
}
/* This returns the status bits of the device. The return value
diff --git a/include/tsec.h b/include/tsec.h
index 2054715..5b74f67 100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -20,10 +20,14 @@
#include net.h
#include config.h
#include phy.h
-#include fsl_mdio.h
+#ifdef CONFIG_LS102xA
+#define TSEC_SIZE 0x4
+#define TSEC_MDIO_OFFSET 0x4
+#else
#define TSEC_SIZE 0x01000
#define TSEC_MDIO_OFFSET 0x01000
+#endif
#define CONFIG_SYS_MDIO_BASE_ADDR (MDIO_BASE_ADDR + 0x520)
@@ -128,6 +132,7 @@
#define DMACTRL_INIT_SETTINGS 0x00c3
#define DMACTRL_GRS0x0010
#define DMACTRL_GTS0x0008
+#define DMACTRL_LE 0x8000
#define TSTAT_CLEAR_THALT 0x8000
#define RSTAT_CLEAR_RHALT 0x0080
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 08/18] driver/ddr/freescale: Add support of accumulate ECC
From: York Sun york...@freescale.com If less than 8 ECC pins are used for DDR data bus width smaller than 64 bits, the 8-bit ECC code will be transmitted/received across several beats, and it will be used to check 64-bits of data once 8-bits of ECC are accumulated. Signed-off-by: York Sun york...@freescale.com --- Change log: v4: No change. v3: No change. v2: No change. drivers/ddr/fsl/ctrl_regs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c index 04e4178..5e0ee77 100644 --- a/drivers/ddr/fsl/ctrl_regs.c +++ b/drivers/ddr/fsl/ctrl_regs.c @@ -693,6 +693,7 @@ static void set_ddr_sdram_cfg(fsl_ddr_cfg_regs_t *ddr, unsigned int x32_en = 0;/* x32 enable */ unsigned int pchb8 = 0; /* precharge bit 8 enable */ unsigned int hse; /* Global half strength override */ + unsigned int acc_ecc_en = 0;/* Accumulated ECC enable */ unsigned int mem_halt = 0; /* memory controller halt */ unsigned int bi = 0;/* Bypass initialization */ @@ -736,6 +737,9 @@ static void set_ddr_sdram_cfg(fsl_ddr_cfg_regs_t *ddr, ba_intlv_ctl = popts-ba_intlv_ctl; hse = popts-half_strength_driver_enable; + /* set when ddr bus width 64 */ + acc_ecc_en = (dbw != 0 ecc_en == 1) ? 1 : 0; + ddr-ddr_sdram_cfg = (0 | ((mem_en 0x1) 31) | ((sren 0x1) 30) @@ -752,6 +756,7 @@ static void set_ddr_sdram_cfg(fsl_ddr_cfg_regs_t *ddr, | ((x32_en 0x1) 5) | ((pchb8 0x1) 4) | ((hse 0x1) 3) + | ((acc_ecc_en 0x1) 2) | ((mem_halt 0x1) 1) | ((bi 0x1) 0) ); -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 10/18] driver/ddr/fsl: Add support of overriding chip select write leveling
From: York Sun york...@freescale.com
JEDEC spec allows DRAM vendors to use prime DQ for write leveling. This
is not an issue unless some DQ pins are not connected. If a platform uses
regular DIMMs but with reduced DDR ECC pins, the prime DQ may end up on
those floating pins for the second rank. The workaround is to use a known
good chip select for this purpose.
Signed-off-by: York Sun york...@freescale.com
---
Change log:
v4: No change.
v3: No change.
v2: No change.
drivers/ddr/fsl/ctrl_regs.c | 3 +++
drivers/ddr/fsl/interactive.c | 2 ++
include/fsl_ddr_sdram.h | 2 ++
3 files changed, 7 insertions(+)
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 5e0ee77..d9cac22 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -2276,6 +2276,9 @@ compute_fsl_memctl_config_regs(const memctl_options_t
*popts,
if (ip_rev 0x40400)
unq_mrs_en = 1;
+ if (ip_rev 0x40700)
+ ddr-debug[18] = popts-cswl_override;
+
set_ddr_sdram_cfg_2(ddr, popts, unq_mrs_en);
set_ddr_sdram_mode(ddr, popts, common_dimm,
cas_latency, additive_latency, unq_mrs_en);
diff --git a/drivers/ddr/fsl/interactive.c b/drivers/ddr/fsl/interactive.c
index 7fb4187..6aa16b2 100644
--- a/drivers/ddr/fsl/interactive.c
+++ b/drivers/ddr/fsl/interactive.c
@@ -511,6 +511,7 @@ static void fsl_ddr_options_edit(fsl_ddr_info_t *pinfo,
CTRL_OPTIONS(wrlvl_override),
CTRL_OPTIONS(wrlvl_sample),
CTRL_OPTIONS(wrlvl_start),
+ CTRL_OPTIONS(cswl_override),
CTRL_OPTIONS(rcw_override),
CTRL_OPTIONS(rcw_1),
CTRL_OPTIONS(rcw_2),
@@ -801,6 +802,7 @@ static void print_memctl_options(const memctl_options_t
*popts)
CTRL_OPTIONS(wrlvl_override),
CTRL_OPTIONS(wrlvl_sample),
CTRL_OPTIONS(wrlvl_start),
+ CTRL_OPTIONS_HEX(cswl_override),
CTRL_OPTIONS(rcw_override),
CTRL_OPTIONS(rcw_1),
CTRL_OPTIONS(rcw_2),
diff --git a/include/fsl_ddr_sdram.h b/include/fsl_ddr_sdram.h
index e8a2db9..987119b 100644
--- a/include/fsl_ddr_sdram.h
+++ b/include/fsl_ddr_sdram.h
@@ -281,6 +281,7 @@ typedef struct memctl_options_partial_s {
#define DDR_DATA_BUS_WIDTH_64 0
#define DDR_DATA_BUS_WIDTH_32 1
#define DDR_DATA_BUS_WIDTH_16 2
+#define DDR_CSWL_CS0 0x0401
/*
* Generalized parameters for memory controller configuration,
* might be a little specific to the FSL memory controller
@@ -340,6 +341,7 @@ typedef struct memctl_options_s {
unsigned int cpo_override;
unsigned int write_data_delay; /* DQS adjust */
+ unsigned int cswl_override;
unsigned int wrlvl_override;
unsigned int wrlvl_sample; /* Write leveling */
unsigned int wrlvl_start;
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 14/18] serial: lpuart: add 32-bit registers lpuart support
From: Jingchang Lu jingchang...@freescale.com
On vybrid, lpuart's registers are 8-bit. On LS102xA, lpuart's registers
are 32-bit. This patch adds the support for 32-bit registers on
LS102xA.
Signed-off-by: Jingchang Lu jingchang...@freescale.com
Signed-off-by: Yuan Yao yao.y...@freescale.com
---
Change log:
v4: Add commit messages.
v3: New file.
drivers/serial/serial_lpuart.c | 122 +
1 file changed, 122 insertions(+)
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index da5f9a2..6e639b7 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -17,10 +17,34 @@
#define UC2_TE (1 3)
#define UC2_RE (1 2)
+#define STAT_LBKDIF(1 31)
+#define STAT_RXEDGIF (1 30)
+#define STAT_TDRE (1 23)
+#define STAT_RDRF (1 21)
+#define STAT_IDLE (1 20)
+#define STAT_OR(1 19)
+#define STAT_NF(1 18)
+#define STAT_FE(1 17)
+#define STAT_PF(1 16)
+#define STAT_MA1F (1 15)
+#define STAT_MA2F (1 14)
+#define STAT_FLAGS (STAT_LBKDIF | STAT_RXEDGIF | STAT_IDLE | STAT_OR | \
+ STAT_NF | STAT_FE | STAT_PF | STAT_MA1F | STAT_MA2F)
+
+#define CTRL_TE(1 19)
+#define CTRL_RE(1 18)
+
+#define FIFO_TXFE 0x80
+#define FIFO_RXFE 0x40
+
+#define WATER_TXWATER_OFF 1
+#define WATER_RXWATER_OFF 16
+
DECLARE_GLOBAL_DATA_PTR;
struct lpuart_fsl *base = (struct lpuart_fsl *)LPUART_BASE;
+#ifndef CONFIG_LPUART_32B_REG
static void lpuart_serial_setbrg(void)
{
u32 clk = mxc_get_clock(MXC_UART_CLK);
@@ -107,13 +131,111 @@ static struct serial_device lpuart_serial_drv = {
.getc = lpuart_serial_getc,
.tstc = lpuart_serial_tstc,
};
+#else
+static void lpuart32_serial_setbrg(void)
+{
+ u32 clk = CONFIG_SYS_CLK_FREQ;
+ u32 sbr;
+
+ if (!gd-baudrate)
+ gd-baudrate = CONFIG_BAUDRATE;
+
+ sbr = (clk / (16 * gd-baudrate));
+ /* place adjustment later - n/32 BRFA */
+
+ out_be32(base-baud, sbr);
+}
+
+static int lpuart32_serial_getc(void)
+{
+ u32 stat;
+
+ while (((stat = in_be32(base-stat)) STAT_RDRF) == 0) {
+ out_be32(base-stat, STAT_FLAGS);
+ WATCHDOG_RESET();
+ }
+
+ return in_be32(base-data) 0x3ff;
+}
+
+static void lpuart32_serial_putc(const char c)
+{
+ if (c == '\n')
+ serial_putc('\r');
+
+ while (!(in_be32(base-stat) STAT_TDRE))
+ WATCHDOG_RESET();
+
+ out_be32(base-data, c);
+}
+
+/*
+ * Test whether a character is in the RX buffer
+ */
+static int lpuart32_serial_tstc(void)
+{
+ if ((in_be32(base-water) 24) == 0)
+ return 0;
+
+ return 1;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int lpuart32_serial_init(void)
+{
+ u8 ctrl;
+
+ ctrl = in_be32(base-ctrl);
+ ctrl = ~CTRL_RE;
+ ctrl = ~CTRL_TE;
+ out_be32(base-ctrl, ctrl);
+
+ out_be32(base-modir, 0);
+ out_be32(base-fifo, ~(FIFO_TXFE | FIFO_RXFE));
+
+ out_be32(base-match, 0);
+ /* provide data bits, parity, stop bit, etc */
+
+ serial_setbrg();
+
+ out_be32(base-ctrl, CTRL_RE | CTRL_TE);
+
+ return 0;
+}
+
+static struct serial_device lpuart32_serial_drv = {
+ .name = lpuart32_serial,
+ .start = lpuart32_serial_init,
+ .stop = NULL,
+ .setbrg = lpuart32_serial_setbrg,
+ .putc = lpuart32_serial_putc,
+ .puts = default_serial_puts,
+ .getc = lpuart32_serial_getc,
+ .tstc = lpuart32_serial_tstc,
+};
+#endif
+void lpuart32_serial_initialize(void)
+{
+ serial_register(lpuart32_serial_drv);
+}
void lpuart_serial_initialize(void)
{
+#ifdef CONFIG_LPUART_32B_REG
+ serial_register(lpuart32_serial_drv);
+#else
serial_register(lpuart_serial_drv);
+#endif
}
__weak struct serial_device *default_serial_console(void)
{
+#ifdef CONFIG_LPUART_32B_REG
+ return lpuart32_serial_drv;
+#else
return lpuart_serial_drv;
+#endif
}
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 13/18] net: tsec: Remove tx snooping support from LS1
From: Claudiu Manoil claudiu.man...@freescale.com Remove the DMCTRL Tx snooping bits (TDSEN and TBDSEN) as a workaround for LS1. It has been observed that currently the Tx stops functioning after a fair amount of Tx traffic with these settings on. These bits are sticky and once set they cannot be reset from Linux, for instance. Signed-off-by: Claudiu Manoil claudiu.man...@freescale.com --- Change log: v4: No change. v3: New file. include/tsec.h | 4 1 file changed, 4 insertions(+) diff --git a/include/tsec.h b/include/tsec.h index 5b74f67..1f0c233 100644 --- a/include/tsec.h +++ b/include/tsec.h @@ -129,7 +129,11 @@ #define MINFLR_INIT_SETTINGS 0x0040 +#ifdef CONFIG_LS102xA +#define DMACTRL_INIT_SETTINGS 0x0003 +#else #define DMACTRL_INIT_SETTINGS 0x00c3 +#endif #define DMACTRL_GRS0x0010 #define DMACTRL_GTS0x0008 #define DMACTRL_LE 0x8000 -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 16/18] video: dcu: Add Sii9022A HDMI Transmitter support
On LS1021ATWR, Silicon's Sii9022A HDMI Transmitter
is used. This patch adds the common setting for this
chip.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: Add commit messages.
v3: New file.
board/freescale/common/Makefile | 2 +
board/freescale/common/dcu_sii9022a.c | 153 ++
board/freescale/common/dcu_sii9022a.h | 13 +++
3 files changed, 168 insertions(+)
create mode 100644 board/freescale/common/dcu_sii9022a.c
create mode 100644 board/freescale/common/dcu_sii9022a.h
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 22b57cc..808ddd0 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -34,6 +34,8 @@ ifndef CONFIG_RAMBOOT_PBL
obj-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o
endif
+obj-$(CONFIG_FSL_DCU_SII9022A)+= dcu_sii9022a.o
+
obj-$(CONFIG_MPC8541CDS) += cds_pci_ft.o
obj-$(CONFIG_MPC8548CDS) += cds_pci_ft.o
obj-$(CONFIG_MPC8555CDS) += cds_pci_ft.o
diff --git a/board/freescale/common/dcu_sii9022a.c
b/board/freescale/common/dcu_sii9022a.c
new file mode 100644
index 000..2da627e
--- /dev/null
+++ b/board/freescale/common/dcu_sii9022a.c
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm/io.h
+#include common.h
+#include fsl_dcu_fb.h
+#include i2c.h
+#include linux/fb.h
+
+#define PIXEL_CLK_LSB_REG 0x00
+#define PIXEL_CLK_MSB_REG 0x01
+#define VERT_FREQ_LSB_REG 0x02
+#define VERT_FREQ_MSB_REG 0x03
+#define TOTAL_PIXELS_LSB_REG 0x04
+#define TOTAL_PIXELS_MSB_REG 0x05
+#define TOTAL_LINES_LSB_REG0x06
+#define TOTAL_LINES_MSB_REG0x07
+#define TPI_INBUS_FMT_REG 0x08
+#define TPI_INPUT_FMT_REG 0x09
+#define TPI_OUTPUT_FMT_REG 0x0A
+#define TPI_SYS_CTRL_REG 0x1A
+#define TPI_PWR_STAT_REG 0x1E
+#define TPI_AUDIO_HANDING_REG 0x25
+#define TPI_AUDIO_INTF_REG 0x26
+#define TPI_AUDIO_FREQ_REG 0x27
+#define TPI_SET_PAGE_REG 0xBC
+#define TPI_SET_OFFSET_REG 0xBD
+#define TPI_RW_ACCESS_REG 0xBE
+#define TPI_TRANS_MODE_REG 0xC7
+
+#define TPI_INBUS_CLOCK_RATIO_1(1 6)
+#define TPI_INBUS_FULL_PIXEL_WIDE (1 5)
+#define TPI_INBUS_RISING_EDGE (1 4)
+#define TPI_INPUT_CLR_DEPTH_8BIT (0 6)
+#define TPI_INPUT_VRANGE_EXPAN_AUTO(0 2)
+#define TPI_INPUT_CLR_RGB (0 0)
+#define TPI_OUTPUT_CLR_DEPTH_8BIT (0 6)
+#define TPI_OUTPUT_VRANGE_COMPRE_AUTO (0 2)
+#define TPI_OUTPUT_CLR_HDMI_RGB(0 0)
+#define TPI_SYS_TMDS_OUTPUT(0 4)
+#define TPI_SYS_AV_NORAML (0 3)
+#define TPI_SYS_AV_MUTE(1 3)
+#define TPI_SYS_DVI_MODE (0 0)
+#define TPI_SYS_HDMI_MODE (1 0)
+#define TPI_PWR_STAT_MASK (3 0)
+#define TPI_PWR_STAT_D0(0 0)
+#define TPI_AUDIO_PASS_BASIC (0 0)
+#define TPI_AUDIO_INTF_I2S (2 6)
+#define TPI_AUDIO_INTF_NORMAL (0 4)
+#define TPI_AUDIO_TYPE_PCM (1 0)
+#define TPI_AUDIO_SAMP_SIZE_16BIT (1 6)
+#define TPI_AUDIO_SAMP_FREQ_44K(2 3)
+#define TPI_SET_PAGE_SII9022A 0x01
+#define TPI_SET_OFFSET_SII9022A0x82
+#define TPI_RW_EN_SRC_TERMIN (1 0)
+#define TPI_TRANS_MODE_ENABLE (0 7)
+
+/* Programming of Silicon SIi9022a HDMI Transmitter */
+int dcu_set_dvi_encoder(struct fb_videomode *videomode)
+{
+ u8 temp;
+ u16 temp1, temp2;
+ u32 temp3;
+
+ i2c_set_bus_num(CONFIG_SYS_I2C_DVI_BUS_NUM);
+
+ /* Enable TPI transmitter mode */
+ temp = TPI_TRANS_MODE_ENABLE;
+ i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_TRANS_MODE_REG, 1, temp, 1);
+
+ /* Enter into D0 state, full operation */
+ i2c_read(CONFIG_SYS_I2C_DVI_ADDR, TPI_PWR_STAT_REG, 1, temp, 1);
+ temp = ~TPI_PWR_STAT_MASK;
+ temp |= TPI_PWR_STAT_D0;
+ i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_PWR_STAT_REG, 1, temp, 1);
+
+ /* Enable source termination */
+ temp = TPI_SET_PAGE_SII9022A;
+ i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_SET_PAGE_REG, 1, temp, 1);
+ temp = TPI_SET_OFFSET_SII9022A;
+ i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_SET_OFFSET_REG, 1, temp, 1);
+
+ i2c_read(CONFIG_SYS_I2C_DVI_ADDR, TPI_RW_ACCESS_REG, 1, temp, 1);
+ temp |= TPI_RW_EN_SRC_TERMIN;
+ i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_RW_ACCESS_REG, 1, temp, 1);
+
+ /* Set TPI system control */
+ temp = TPI_SYS_TMDS_OUTPUT | TPI_SYS_AV_NORAML | TPI_SYS_DVI_MODE;
+ i2c_write(CONFIG_SYS_I2C_DVI_ADDR, TPI_SYS_CTRL_REG, 1, temp, 1);
+
+ /* Set pixel clock */
+ temp1 =
[U-Boot] [PATCH v4 11/18] arm: ls102xa: Add basic support for LS1021AQDS board
From: Wang Huan b18...@freescale.com LS102xA is an ARMv7 implementation. This patch is to add basic support for LS1021AQDS board. One DDR controller DUART1 is used as the console For the detail board information, please refer to README. Signed-off-by: Alison Wang alison.w...@freescale.com Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: York Sun york...@freescale.com Signed-off-by: Yuan Yao yao.y...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Change log: v4: Add more commit messages. v3: Fix checkpatch error. Update to Kconfig. v2: Remove ethaddr/ipaddr setting. Add board maintainer. Add serdes and multiple ethernet controllers support. arch/arm/Kconfig | 4 + board/freescale/ls1021aqds/Kconfig| 23 ++ board/freescale/ls1021aqds/MAINTAINERS| 6 + board/freescale/ls1021aqds/Makefile | 9 + board/freescale/ls1021aqds/README | 112 +++ board/freescale/ls1021aqds/ddr.c | 166 ++ board/freescale/ls1021aqds/ddr.h | 64 board/freescale/ls1021aqds/eth.c | 129 board/freescale/ls1021aqds/ls1021aqds.c | 248 +++ board/freescale/ls1021aqds/ls1021aqds_qixis.h | 35 +++ configs/ls1021aqds_nor_defconfig | 2 + include/configs/ls1021aqds.h | 424 ++ 12 files changed, 1222 insertions(+) create mode 100644 board/freescale/ls1021aqds/Kconfig create mode 100644 board/freescale/ls1021aqds/MAINTAINERS create mode 100644 board/freescale/ls1021aqds/Makefile create mode 100644 board/freescale/ls1021aqds/README create mode 100644 board/freescale/ls1021aqds/ddr.c create mode 100644 board/freescale/ls1021aqds/ddr.h create mode 100644 board/freescale/ls1021aqds/eth.c create mode 100644 board/freescale/ls1021aqds/ls1021aqds.c create mode 100644 board/freescale/ls1021aqds/ls1021aqds_qixis.h create mode 100644 configs/ls1021aqds_nor_defconfig create mode 100644 include/configs/ls1021aqds.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e385eda..62b3cc8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -731,6 +731,9 @@ config TARGET_LS2085A_EMU config TARGET_LS2085A_SIMU bool Support ls2085a_simu +config TARGET_LS1021AQDS + bool Support ls1021aqds_nor + config TARGET_BALLOON3 bool Support balloon3 @@ -865,6 +868,7 @@ source board/eukrea/cpu9260/Kconfig source board/eukrea/cpuat91/Kconfig source board/faraday/a320evb/Kconfig source board/freescale/ls2085a/Kconfig +source board/freescale/ls1021aqds/Kconfig source board/freescale/mx23evk/Kconfig source board/freescale/mx25pdk/Kconfig source board/freescale/mx28evk/Kconfig diff --git a/board/freescale/ls1021aqds/Kconfig b/board/freescale/ls1021aqds/Kconfig new file mode 100644 index 000..c28bd2b --- /dev/null +++ b/board/freescale/ls1021aqds/Kconfig @@ -0,0 +1,23 @@ +if TARGET_LS1021AQDS + +config SYS_CPU + string + default armv7 + +config SYS_BOARD + string + default ls1021aqds + +config SYS_VENDOR + string + default freescale + +config SYS_SOC + string + default ls102xa + +config SYS_CONFIG_NAME + string + default ls1021aqds + +endif diff --git a/board/freescale/ls1021aqds/MAINTAINERS b/board/freescale/ls1021aqds/MAINTAINERS new file mode 100644 index 000..021d82b --- /dev/null +++ b/board/freescale/ls1021aqds/MAINTAINERS @@ -0,0 +1,6 @@ +LS1021AQDS BOARD +M: Alison Wang alison.w...@freescale.com +S: Maintained +F: board/freescale/ls1021aqds/ +F: include/configs/ls1021aqds.h +F: configs/ls1021aqds_nor_defconfig diff --git a/board/freescale/ls1021aqds/Makefile b/board/freescale/ls1021aqds/Makefile new file mode 100644 index 000..3b6903c --- /dev/null +++ b/board/freescale/ls1021aqds/Makefile @@ -0,0 +1,9 @@ +# +# Copyright 2014 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += ls1021aqds.o +obj-y += ddr.o +obj-y += eth.o diff --git a/board/freescale/ls1021aqds/README b/board/freescale/ls1021aqds/README new file mode 100644 index 000..c561776 --- /dev/null +++ b/board/freescale/ls1021aqds/README @@ -0,0 +1,112 @@ +Overview + +The LS1021AQDS is a Freescale reference board that hosts the LS1021A SoC. + +LS1021A SoC Overview +-- +The QorIQ LS1 family, which includes the LS1021A communications processor, +is built on Layerscape architecture, the industry's first software-aware, +core-agnostic networking architecture to offer unprecedented efficiency +and scale. + +A member of the value-performance tier, the QorIQ LS1021A processor provides +extensive integration and power efficiency for fanless, small form factor +enterprise networking applications. Incorporating dual ARM Cortex-A7 cores +running up to 1.0 GHz, the LS1021A processor delivers pre-silicon CoreMark +performance of over
[U-Boot] [PATCH v4 17/18] video: dcu: Add DCU driver support
From: Wang Huan b18...@freescale.com This patch is to add DCU driver support. DCU also named 2D-ACE(Two Dimensional Animation and Compositing Engine) is a system master that fetches graphics stored in internal or external memory and displays them on a TFT LCD panel. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: No change. v3: New file. arch/arm/include/asm/arch-ls102xa/config.h | 4 + drivers/video/Makefile | 1 + drivers/video/fsl_dcu_fb.c | 365 + include/fsl_dcu_fb.h | 16 ++ 4 files changed, 386 insertions(+) create mode 100644 drivers/video/fsl_dcu_fb.c create mode 100644 include/fsl_dcu_fb.h diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index ddc747f..dfc5668 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -21,6 +21,7 @@ #define CONFIG_SYS_FSL_LS1_CLK_ADDR(CONFIG_SYS_IMMR + 0x00ee1000) #define CONFIG_SYS_NS16550_COM1(CONFIG_SYS_IMMR + 0x011c0500) #define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_IMMR + 0x011d0500) +#define CONFIG_SYS_DCU_ADDR(CONFIG_SYS_IMMR + 0x01ce) #define CONFIG_SYS_TSEC1_OFFSET0x01d1 #define CONFIG_SYS_TSEC2_OFFSET0x01d5 @@ -57,6 +58,9 @@ #define CONFIG_SYS_FSL_WDOG_BE #define CONFIG_SYS_FSL_DSPI_BE #define CONFIG_SYS_FSL_QSPI_BE +#define CONFIG_SYS_FSL_DCU_BE + +#define DCU_LAYER_MAX_NUM 16 #define CONFIG_SYS_FSL_SRDS_1 diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 945f35d..3dafef3 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_EXYNOS_MIPI_DSIM) += exynos_mipi_dsi.o exynos_mipi_dsi_common.o \ exynos_mipi_dsi_lowlevel.o obj-$(CONFIG_EXYNOS_PWM_BL) += exynos_pwm_bl.o obj-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o videomodes.o +obj-$(CONFIG_FSL_DCU_FB) += fsl_dcu_fb.o videomodes.o obj-$(CONFIG_L5F31188) += l5f31188.o obj-$(CONFIG_MPC8XX_LCD) += mpc8xx_lcd.o obj-$(CONFIG_PXA_LCD) += pxa_lcd.o diff --git a/drivers/video/fsl_dcu_fb.c b/drivers/video/fsl_dcu_fb.c new file mode 100644 index 000..36c1566 --- /dev/null +++ b/drivers/video/fsl_dcu_fb.c @@ -0,0 +1,365 @@ +/* + * Copyright 2014 Freescale Semiconductor, Inc. + * + * FSL DCU Framebuffer driver + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include asm/io.h +#include common.h +#include fsl_dcu_fb.h +#include linux/fb.h +#include malloc.h +#include video_fb.h +#include videomodes.h + +/* Convert the X,Y resolution pair into a single number */ +#define RESOLUTION(x, y) (((u32)(x) 16) | (y)) + +#ifdef CONFIG_SYS_FSL_DCU_LE +#definedcu_read32 in_le32 +#definedcu_write32 out_le32 +#elif defined(CONFIG_SYS_FSL_DCU_BE) +#definedcu_read32 in_be32 +#definedcu_write32 out_be32 +#endif + +#define DCU_MODE_BLEND_ITER(x) ((x) 20) +#define DCU_MODE_RASTER_EN (1 14) +#define DCU_MODE_NORMAL1 +#define DCU_MODE_COLORBAR 3 +#define DCU_BGND_R(x) ((x) 16) +#define DCU_BGND_G(x) ((x) 8) +#define DCU_BGND_B(x) (x) +#define DCU_DISP_SIZE_DELTA_Y(x) ((x) 16) +#define DCU_DISP_SIZE_DELTA_X(x) (x) +#define DCU_HSYN_PARA_BP(x)((x) 22) +#define DCU_HSYN_PARA_PW(x)((x) 11) +#define DCU_HSYN_PARA_FP(x)(x) +#define DCU_VSYN_PARA_BP(x)((x) 22) +#define DCU_VSYN_PARA_PW(x)((x) 11) +#define DCU_VSYN_PARA_FP(x)(x) +#define DCU_SYN_POL_INV_PXCK_FALL (0 6) +#define DCU_SYN_POL_NEG_REMAIN (0 5) +#define DCU_SYN_POL_INV_VS_LOW (1 1) +#define DCU_SYN_POL_INV_HS_LOW (1) +#define DCU_THRESHOLD_LS_BF_VS(x) ((x) 16) +#define DCU_THRESHOLD_OUT_BUF_HIGH(x) ((x) 8) +#define DCU_THRESHOLD_OUT_BUF_LOW(x) (x) +#define DCU_UPDATE_MODE_MODE(1 31) +#define DCU_UPDATE_MODE_READREG (1 30) + +#define DCU_CTRLDESCLN_1_HEIGHT(x) ((x) 16) +#define DCU_CTRLDESCLN_1_WIDTH(x) (x) +#define DCU_CTRLDESCLN_2_POSY(x) ((x) 16) +#define DCU_CTRLDESCLN_2_POSX(x) (x) +#define DCU_CTRLDESCLN_4_EN(1 31) +#define DCU_CTRLDESCLN_4_TILE_EN (1 30) +#define DCU_CTRLDESCLN_4_DATA_SEL_CLUT (1 29) +#define DCU_CTRLDESCLN_4_SAFETY_EN (1 28) +#define DCU_CTRLDESCLN_4_TRANS(x) ((x) 20) +#define DCU_CTRLDESCLN_4_BPP(x)((x) 16) +#define DCU_CTRLDESCLN_4_RLE_EN(1 15) +#define DCU_CTRLDESCLN_4_LUOFFS(x) ((x) 4) +#define DCU_CTRLDESCLN_4_BB_ON (1 2) +#define DCU_CTRLDESCLN_4_AB(x) (x) +#define DCU_CTRLDESCLN_5_CKMAX_R(x)((x) 16) +#define DCU_CTRLDESCLN_5_CKMAX_G(x)
[U-Boot] [PATCH v4 12/18] arm: ls102xa: Add basic support for LS1021ATWR board
From: Wang Huan b18...@freescale.com LS102xA is an ARMv7 implementation. This patch is to add basic support for LS1021ATWR board. One DDR controller DUART1 is used as the console For the detail board information, please refer to README. Signed-off-by: Chen Lu chen...@freescale.com Signed-off-by: Yuan Yao yao.y...@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: Add more commit messages. v3: Fix checkpatch error. Update to Kconfig. v2: New file. arch/arm/Kconfig| 4 + board/freescale/ls1021atwr/Kconfig | 23 ++ board/freescale/ls1021atwr/MAINTAINERS | 6 + board/freescale/ls1021atwr/Makefile | 7 + board/freescale/ls1021atwr/README | 109 +++ board/freescale/ls1021atwr/ls1021atwr.c | 494 configs/ls1021atwr_nor_defconfig| 2 + include/configs/ls1021atwr.h| 284 ++ 8 files changed, 929 insertions(+) create mode 100644 board/freescale/ls1021atwr/Kconfig create mode 100644 board/freescale/ls1021atwr/MAINTAINERS create mode 100644 board/freescale/ls1021atwr/Makefile create mode 100644 board/freescale/ls1021atwr/README create mode 100644 board/freescale/ls1021atwr/ls1021atwr.c create mode 100644 configs/ls1021atwr_nor_defconfig create mode 100644 include/configs/ls1021atwr.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 62b3cc8..d207db7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -734,6 +734,9 @@ config TARGET_LS2085A_SIMU config TARGET_LS1021AQDS bool Support ls1021aqds_nor +config TARGET_LS1021ATWR + bool Support ls1021atwr_nor + config TARGET_BALLOON3 bool Support balloon3 @@ -869,6 +872,7 @@ source board/eukrea/cpuat91/Kconfig source board/faraday/a320evb/Kconfig source board/freescale/ls2085a/Kconfig source board/freescale/ls1021aqds/Kconfig +source board/freescale/ls1021atwr/Kconfig source board/freescale/mx23evk/Kconfig source board/freescale/mx25pdk/Kconfig source board/freescale/mx28evk/Kconfig diff --git a/board/freescale/ls1021atwr/Kconfig b/board/freescale/ls1021atwr/Kconfig new file mode 100644 index 000..057808d --- /dev/null +++ b/board/freescale/ls1021atwr/Kconfig @@ -0,0 +1,23 @@ +if TARGET_LS1021ATWR + +config SYS_CPU + string + default armv7 + +config SYS_BOARD + string + default ls1021atwr + +config SYS_VENDOR + string + default freescale + +config SYS_SOC + string + default ls102xa + +config SYS_CONFIG_NAME + string + default ls1021atwr + +endif diff --git a/board/freescale/ls1021atwr/MAINTAINERS b/board/freescale/ls1021atwr/MAINTAINERS new file mode 100644 index 000..4e5bc15 --- /dev/null +++ b/board/freescale/ls1021atwr/MAINTAINERS @@ -0,0 +1,6 @@ +LS1021ATWR BOARD +M: Alison Wang alison.w...@freescale.com +S: Maintained +F: board/freescale/ls1021atwr/ +F: include/configs/ls1021atwr.h +F: configs/ls1021atwr_nor_defconfig diff --git a/board/freescale/ls1021atwr/Makefile b/board/freescale/ls1021atwr/Makefile new file mode 100644 index 000..b5df668 --- /dev/null +++ b/board/freescale/ls1021atwr/Makefile @@ -0,0 +1,7 @@ +# +# Copyright 2014 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += ls1021atwr.o diff --git a/board/freescale/ls1021atwr/README b/board/freescale/ls1021atwr/README new file mode 100644 index 000..d2821cb --- /dev/null +++ b/board/freescale/ls1021atwr/README @@ -0,0 +1,109 @@ +Overview + +The LS1021ATWR is a Freescale reference board that hosts the LS1021A SoC. + +LS1021A SoC Overview +-- +The QorIQ LS1 family, which includes the LS1021A communications processor, +is built on Layerscape architecture, the industry's first software-aware, +core-agnostic networking architecture to offer unprecedented efficiency +and scale. + +A member of the value-performance tier, the QorIQ LS1021A processor provides +extensive integration and power efficiency for fanless, small form factor +enterprise networking applications. Incorporating dual ARM Cortex-A7 cores +running up to 1.0 GHz, the LS1021A processor delivers pre-silicon CoreMark +performance of over 6,000, as well as virtualization support, advanced +security features and the broadest array of high-speed interconnects and +optimized peripheral features ever offered in a sub-3 W processor. + +The QorIQ LS1021A processor features an integrated LCD controller, +CAN controller for implementing industrial protocols, DDR3L/4 running +up to 1600 MHz, integrated security engine and QUICC Engine, and ECC +protection on both L1 and L2 caches. The LS1021A processor is pin- and +software-compatible with the QorIQ LS1020A and LS1022A processors. + +The LS1021A SoC includes the following function and features: + + - ARM Cortex-A7 MPCore compliant with ARMv7-A architecture + - Dual high-preformance ARM Cortex-A7 cores, each core includes: + - 32
[U-Boot] [PATCH v4 04/18] net: mdio: Add private MDIO read/write function
As extra FPGA settings is needed for MDIO read/write
on LS1021AQDS, private MDIO read/write functions are
created.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: No change.
v3: Split from the 0004-arm-ls102xa-Add-etsec-support-for-LS102xA patch.
v2: Add private mdio read and write support.
drivers/net/fsl_mdio.c | 9 +++--
include/fsl_mdio.h | 4
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 8d09f5d..6eae78f 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
@@ -98,8 +98,13 @@ int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info
*info)
return -1;
}
- bus-read = tsec_phy_read;
- bus-write = tsec_phy_write;
+ if (info-priv_mdio_read) {
+ bus-read = info-priv_mdio_read;
+ bus-write = info-priv_mdio_write;
+ } else {
+ bus-read = tsec_phy_read;
+ bus-write = tsec_phy_write;
+ }
bus-reset = fsl_pq_mdio_reset;
sprintf(bus-name, info-name);
diff --git a/include/fsl_mdio.h b/include/fsl_mdio.h
index a531edf..633123c 100644
--- a/include/fsl_mdio.h
+++ b/include/fsl_mdio.h
@@ -57,6 +57,10 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, int
dev_addr,
struct fsl_pq_mdio_info {
struct tsec_mii_mng __iomem *regs;
char *name;
+ int (*priv_mdio_read)(struct mii_dev *bus, int addr,
+ int devad, int reg);
+ int (*priv_mdio_write)(struct mii_dev *bus, int addr, int devad,
+ int reg, u16 val);
};
int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info *info);
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 15/18] arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board
From: Wang Huan b18...@freescale.com This patch is to add LETECH support for LS1021AQDS/TWR board. For LETECH, lpuart is used as console. Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: Yuan Yao yao.y...@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: No change. v3: New file. board/freescale/ls1021aqds/MAINTAINERS | 1 + board/freescale/ls1021atwr/MAINTAINERS | 1 + configs/ls1021aqds_letech_defconfig| 3 +++ configs/ls1021atwr_letech_defconfig| 3 +++ include/configs/ls1021aqds.h | 13 + include/configs/ls1021atwr.h | 12 6 files changed, 33 insertions(+) create mode 100644 configs/ls1021aqds_letech_defconfig create mode 100644 configs/ls1021atwr_letech_defconfig diff --git a/board/freescale/ls1021aqds/MAINTAINERS b/board/freescale/ls1021aqds/MAINTAINERS index 021d82b..590b89b 100644 --- a/board/freescale/ls1021aqds/MAINTAINERS +++ b/board/freescale/ls1021aqds/MAINTAINERS @@ -4,3 +4,4 @@ S: Maintained F: board/freescale/ls1021aqds/ F: include/configs/ls1021aqds.h F: configs/ls1021aqds_nor_defconfig +F: configs/ls1021aqds_letech_defconfig diff --git a/board/freescale/ls1021atwr/MAINTAINERS b/board/freescale/ls1021atwr/MAINTAINERS index 4e5bc15..14a7441 100644 --- a/board/freescale/ls1021atwr/MAINTAINERS +++ b/board/freescale/ls1021atwr/MAINTAINERS @@ -4,3 +4,4 @@ S: Maintained F: board/freescale/ls1021atwr/ F: include/configs/ls1021atwr.h F: configs/ls1021atwr_nor_defconfig +F: configs/ls1021atwr_letech_defconfig diff --git a/configs/ls1021aqds_letech_defconfig b/configs/ls1021aqds_letech_defconfig new file mode 100644 index 000..b70971e --- /dev/null +++ b/configs/ls1021aqds_letech_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_EXTRA_OPTIONS=LETECH ++S:CONFIG_ARM=y ++S:CONFIG_TARGET_LS1021AQDS=y diff --git a/configs/ls1021atwr_letech_defconfig b/configs/ls1021atwr_letech_defconfig new file mode 100644 index 000..4b187b3 --- /dev/null +++ b/configs/ls1021atwr_letech_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_EXTRA_OPTIONS=LETECH ++S:CONFIG_ARM=y ++S:CONFIG_TARGET_LS1021ATWR=y diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 856fdfc..5a8bf21 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -279,11 +279,16 @@ unsigned long get_board_ddr_clk(void); /* * Serial Port */ +#ifdef CONFIG_LETECH +#define CONFIG_FSL_LPUART +#define CONFIG_LPUART_32B_REG +#else #define CONFIG_CONS_INDEX 1 #define CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL #define CONFIG_SYS_NS16550_REG_SIZE1 #define CONFIG_SYS_NS16550_CLK get_serial_clock() +#endif #define CONFIG_BAUDRATE115200 @@ -367,11 +372,19 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_BOOTDELAY 3 +#ifdef CONFIG_LETECH +#define CONFIG_EXTRA_ENV_SETTINGS \ + bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0 \ + fdt_high=0xcfff\0 \ + initrd_high=0xcfff\0 \ + hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=null\0 +#else #define CONFIG_EXTRA_ENV_SETTINGS \ bootargs=root=/dev/ram0 rw console=ttyS0,115200\0 \ fdt_high=0xcfff\0 \ initrd_high=0xcfff\0 \ hwconfig=fsl_ddr:ctlr_intlv=null,bank_intlv=null\0 +#endif /* * Miscellaneous configurable options diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index f8cbe32..b268a70 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -147,11 +147,16 @@ unsigned long get_board_ddr_clk(void); /* * Serial Port */ +#ifdef CONFIG_LETECH +#define CONFIG_FSL_LPUART +#define CONFIG_LPUART_32B_REG +#else #define CONFIG_CONS_INDEX 1 #define CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL #define CONFIG_SYS_NS16550_REG_SIZE1 #define CONFIG_SYS_NS16550_CLK get_serial_clock() +#endif #define CONFIG_BAUDRATE115200 @@ -228,10 +233,17 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_BOOTDELAY 3 +#ifdef CONFIG_LETECH +#define CONFIG_EXTRA_ENV_SETTINGS \ + bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0 \ + initrd_high=0xcfff\0 \ + fdt_high=0xcfff\0 +#else #define CONFIG_EXTRA_ENV_SETTINGS \ bootargs=root=/dev/ram0 rw console=ttyS0,115200\0 \ initrd_high=0xcfff\0 \ fdt_high=0xcfff\0 +#endif /* * Miscellaneous configurable options -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 18/18] ls102xa: dcu: Add platform support for DCU on LS1021ATWR board
From: Wang Huan b18...@freescale.com
This patch adds the TWR_LCD_RGB card/HDMI options and the common
configuration for DCU on LS1021ATWR board.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: Add commit messages.
v3: New file.
board/freescale/ls1021atwr/Makefile | 1 +
board/freescale/ls1021atwr/dcu.c| 47 +
board/freescale/ls1021atwr/ls1021atwr.c | 6 +
include/configs/ls1021atwr.h| 18 +
4 files changed, 72 insertions(+)
create mode 100644 board/freescale/ls1021atwr/dcu.c
diff --git a/board/freescale/ls1021atwr/Makefile
b/board/freescale/ls1021atwr/Makefile
index b5df668..01296c0 100644
--- a/board/freescale/ls1021atwr/Makefile
+++ b/board/freescale/ls1021atwr/Makefile
@@ -5,3 +5,4 @@
#
obj-y += ls1021atwr.o
+obj-$(CONFIG_FSL_DCU_FB) += dcu.o
diff --git a/board/freescale/ls1021atwr/dcu.c b/board/freescale/ls1021atwr/dcu.c
new file mode 100644
index 000..8fe4ccb
--- /dev/null
+++ b/board/freescale/ls1021atwr/dcu.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * FSL DCU Framebuffer driver
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include fsl_dcu_fb.h
+#include div64.h
+#include ../common/dcu_sii9022a.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+unsigned int dcu_set_pixel_clock(unsigned int pixclock)
+{
+ unsigned long long div;
+
+ div = (unsigned long long)(gd-bus_clk / 1000);
+ div *= (unsigned long long)pixclock;
+ do_div(div, 10);
+
+ return div;
+}
+
+int platform_dcu_init(unsigned int xres, unsigned int yres,
+ const char *port,
+ struct fb_videomode *dcu_fb_videomode)
+{
+ const char *name;
+ unsigned int pixel_format;
+
+ if (strncmp(port, twr_lcd, 4) == 0) {
+ name = TWR_LCD_RGB card;
+ } else {
+ name = HDMI;
+ dcu_set_dvi_encoder(dcu_fb_videomode);
+ }
+
+ printf(DCU: Switching to %s monitor @ %ux%u\n, name, xres, yres);
+
+ pixel_format = 32;
+ fsl_dcu_init(xres, yres, pixel_format);
+
+ return 0;
+}
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
b/board/freescale/ls1021atwr/ls1021atwr.c
index 7fdcbcd..e4364dd 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -264,6 +264,12 @@ int board_early_init_f(void)
init_early_memctl_regs();
#endif
+#ifdef CONFIG_FSL_DCU_FB
+ out_be32(scfg-scfgrevcr, 0x);
+ out_be32(scfg-pixclkcr, 0x8000);
+ out_be32(scfg-scfgrevcr, 0x);
+#endif
+
out_le32(cci-ctrl_ord, 0x0008);
return 0;
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index b268a70..fb2cf08 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -182,6 +182,24 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_GENERIC_MMC
/*
+ * Video
+ */
+#define CONFIG_FSL_DCU_FB
+
+#ifdef CONFIG_FSL_DCU_FB
+#define CONFIG_VIDEO
+#define CONFIG_CMD_BMP
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_VIDEO_BMP_LOGO
+
+#define CONFIG_FSL_DCU_SII9022A
+#define CONFIG_SYS_I2C_DVI_BUS_NUM 1
+#define CONFIG_SYS_I2C_DVI_ADDR0x39
+#endif
+
+/*
* eTSEC
*/
#define CONFIG_TSEC_ENET
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Passing bootargs to arm64 kernel
On 08/14/2014 08:04 AM, Youngmin Nam wrote: Thank you for reply Tom, Let me ask you some questions. Can we set kernel's bootargs without re-compiling device tree on arm64 kernel by u-boot? I mean, I want to set kernel's bootargs by u-boot without re-compiling device tree. Is it possible? This is done anyway, whatever is defined in CONFIG_BOOTARGS will be stored in the U-Boot environment variable bootargs and passed as bootargs to the kernel via the chosen node. See fdt_chosen in common/fdt-support.c. So if you want the change the bootargs passed to the kernel, just do set bootargs 'whatever you want in bootargs' at the u-boot prompt and the boot the kernel. Thanks Arnab 2014. 8. 13. 오후 7:39에 Tom Rini tr...@ti.com님이 작성: On Wed, Aug 13, 2014 at 11:21:32AM +0900, Youngmin Nam wrote: Hello. I'm trying to find a way how to pass bootargs to arm64 kernel. In arm32 kernel, we can pass bootargs with atag from u-boot to kernel. So, we can overwrite kernel's bootargs with u-boot's bootargs. But from arm64 kernel, the dtb is the only argument that should be passed from bootloader which is mandatory. you can find this contents in kernel documentation.(Documentation/arm64/Booting.txt) So, is there any way how to set bootargs by u-boot? Yes, within the device tree, like we do today. There's a few issues we have today, but I need to re-post the booti command support patches, given what's coming in 3.17 in the kernel. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools, fit_info: increase buffer for command name
On Mon, 11 Aug 2014 11:17:08 +0200 Heiko Schocher h...@denx.de wrote: currently the buffer for command name is 50 bytes only. If using fit_info with long absolute paths, this is not enough, so raise it to 256 (as it is in fit_check_sign) Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org --- tools/fit_info.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) applied to u-boot-staging/ag...@denx.de. thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: fix typo in tools/image-host.c
On Mon, 11 Aug 2014 11:02:17 +0200 Heiko Schocher h...@denx.de wrote: fix a typo in error printf. If FIT_CONFS_PATH is not found print FIT_CONFS_PATH not FIT_IMAGES_PATH. Signed-off-by: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org --- tools/image-host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) applied to u-boot-staging/ag...@denx.de. thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Fix ECSPI typo in soc_boot_modes
On Sun, 10 Aug 2014 20:03:07 +0300 picmas...@mail.bg wrote: From: Nikolay Dimitrov picmas...@mail.bg Signed-off-by: Nikolay Dimitrov picmas...@mail.bg Cc: Stefano Babic sba...@denx.de --- arch/arm/cpu/armv7/mx6/soc.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Acked-by: Anatolij Gustschin ag...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: fix overflow in __pci_hose_bus_to_phys w/ large RAM
On Mon, 11 Aug 2014 16:09:28 -0600 Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com If a 32-bit system has 2GB of RAM, and the base address of that RAM is 2GB, then start+size will overflow a 32-bit value (to a value of 0). To avoid such an overflow, convert __pci_hose_bus_to_phys() to calculate the offset of a bus address into a PCI region, rather than comparing a bus address against the end of a PCI region. Signed-off-by: Stephen Warren swar...@nvidia.com --- drivers/pci/pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) applied to u-boot-staging/ag...@denx.de. thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Makefile: Use Kbuild style for system_map.o generation step
The command generating the common/system_map.o file was always shown
during the build making the output messy. Now it is called using the
Kbuild cmd macro, so that the full command is shown only when
building in verbose mode.
Signed-off-by: Vasili Galka vvv...@gmail.com
---
Makefile | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index b5d5e01..7c0352c 100644
--- a/Makefile
+++ b/Makefile
@@ -1006,13 +1006,17 @@ quiet_cmd_u-boot__ ?= LD $@
--start-group $(u-boot-main) --end-group \
$(PLATFORM_LIBS) -Map u-boot.map
-u-boot:$(u-boot-init) $(u-boot-main) u-boot.lds
- $(call if_changed,u-boot__)
-ifeq ($(CONFIG_KALLSYMS),y)
+quiet_cmd_smap = GEN common/system_map.o
+cmd_smap = \
smap=`$(call SYSTEM_MAP,u-boot) | \
awk '$$2 ~ /[tTwW]/ {printf $$1 $$3 000}'` ; \
$(CC) $(c_flags) -DSYSTEM_MAP=\$${smap}\ \
-c $(srctree)/common/system_map.c -o common/system_map.o
+
+u-boot:$(u-boot-init) $(u-boot-main) u-boot.lds
+ $(call if_changed,u-boot__)
+ifeq ($(CONFIG_KALLSYMS),y)
+ $(call cmd,smap)
$(call cmd,u-boot__) common/system_map.o
endif
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] bfin: Use optimization for size instead of speed on two boards
The build of bf533-stamp and bf538f-ezkit boards is broken. The code does not fit into the available RAM. This fixes the build by favoring size optimization over speed optimization for the code in lib directory. Signed-off-by: Vasili Galka vvv...@gmail.com Cc: Sonic Zhang sonic@gmail.com --- include/configs/bf533-stamp.h |1 - include/configs/bf538f-ezkit.h |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/configs/bf533-stamp.h b/include/configs/bf533-stamp.h index d82c5b2..f5b9658 100644 --- a/include/configs/bf533-stamp.h +++ b/include/configs/bf533-stamp.h @@ -185,7 +185,6 @@ */ #define CONFIG_RTC_BFIN #define CONFIG_UART_CONSOLE0 -#define CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED /* FLASH/ETHERNET uses the same async bank */ #define SHARED_RESOURCES 1 diff --git a/include/configs/bf538f-ezkit.h b/include/configs/bf538f-ezkit.h index 742c299..2837cf8 100644 --- a/include/configs/bf538f-ezkit.h +++ b/include/configs/bf538f-ezkit.h @@ -134,7 +134,6 @@ */ #define CONFIG_RTC_BFIN #define CONFIG_UART_CONSOLE0 -#define CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED /* * Pull in common ADI header for remaining command/environment setup -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mkimage: fix compilation issues on OpenBSD
On Sat, 9 Aug 2014 18:17:47 +0200 Luka Perkov l...@openwrt.org wrote: Signed-off-by: Luka Perkov l...@openwrt.org --- tools/mkimage.c | 2 ++ 1 file changed, 2 insertions(+) applied to u-boot-staging/ag...@denx.de. thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build broken for bf538f-ezkit board - not enough ram
Hi Simon, On Thu, Aug 14, 2014 at 7:20 AM, Simon Glass s...@chromium.org wrote: Hi, On 12 August 2014 10:12, Vasili Galka vvv...@gmail.com wrote: On Sun, Jun 29, 2014 at 6:01 PM, Vasili Galka vvv...@gmail.com wrote: Hi, Some of the recent commits on u-boot/master have broken the build of bf538f-ezkit board. The build was fine for v2014.07-rc3. However, now there is the following error: bfin-elf-ld.bfd: u-boot section `.bss' will not fit in region `ram' bfin-elf-ld.bfd: region `ram' overflowed by 40 bytes I did not pin-point exactly what has increased the image size, and if the growth is in the .text or .bss section. Maybe some of the features shall be dropped from the board config to decrease the size. Also, may be related: http://lists.denx.de/pipermail/u-boot/2014-April/177928.html Best, Vasili This is still broken and now the bf533-stamp board seems to have the same error. Best, Vasili Can you fix it? Regards, Simon The only way I see to fix it is dropping some features from there boards to reduce the image size. As I'm not a user of these boards, I don't know what can be dropped. However, I can suggest sacrificing performance instead of features. Proposed patch: http://patchwork.ozlabs.org/patch/379886/ Best regards, Vasili ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] vexpress_aemv8a.h: Enable CONFIG_CMD_BOOTI and CONFIG_CMD_UNZIP
Add support for booting Images and for unzipping Image.gz files. Signed-off-by: Tom Rini tr...@ti.com --- include/configs/vexpress_aemv8a.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 6f31fcf..0897932 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -154,6 +154,8 @@ /*#define CONFIG_MENU_SHOW*/ #define CONFIG_CMD_CACHE #define CONFIG_CMD_BDI +#define CONFIG_CMD_BOOTI +#define CONFIG_CMD_UNZIP #define CONFIG_CMD_DHCP #define CONFIG_CMD_PXE #define CONFIG_CMD_ENV -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] vexpress_aemv8a.h: Clean up the config
- Drop DEBUG - Drop defines we can use the default of. - Provide a larger malloc pool. - Correct default locations for kernel / initrd / device tree Signed-off-by: Tom Rini tr...@ti.com --- Changes in v1: - Don't drop GIC portions, per Rob Herring's recommendation --- include/configs/vexpress_aemv8a.h | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 1905d13..6f31fcf 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -8,8 +8,6 @@ #ifndef __VEXPRESS_AEMV8A_H #define __VEXPRESS_AEMV8A_H -#define DEBUG - #ifdef CONFIG_BASE_FVP #ifndef CONFIG_SEMIHOSTING #error CONFIG_BASE_FVP requires CONFIG_SEMIHOSTING @@ -134,7 +132,7 @@ #define CONFIG_SYS_MEMTEST_END (V2M_BASE + 0x8000) /* Size of malloc() pool */ -#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 128 * 1024) +#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (8 20)) /* SMSC91C111 Ethernet Configuration */ #define CONFIG_SMC91 @@ -215,10 +213,9 @@ #else #define CONFIG_EXTRA_ENV_SETTINGS \ - kernel_addr_r=0x20\0 \ - initrd_addr_r=0xa0\0 \ - initrd_size=0x200\0 \ - fdt_addr_r=0x10\0 \ + kernel_addr_r=0x8000\0\ + initrd_addr_r=0x8800\0\ + fdt_addr_r=0x8300\0 \ fdt_high=0xa000\0 #define CONFIG_BOOTARGSconsole=ttyAMA0 root=/dev/ram0 @@ -239,7 +236,7 @@ #define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE #define CONFIG_SYS_LONGHELP -#define CONFIG_CMDLINE_EDITING 1 +#define CONFIG_CMDLINE_EDITING #define CONFIG_SYS_MAXARGS 64 /* max command args */ #endif /* __VEXPRESS_AEMV8A_H */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] arm64: Correct passing of Linux kernel args
The Documentation/arm64/booting.txt document says that pass in x1/x2/x3
as 0 as they are reserved for future use.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/lib/bootm.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 178e8fb..39fe7a1 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -239,10 +239,12 @@ static void boot_prep_linux(bootm_headers_t *images)
static void boot_jump_linux(bootm_headers_t *images, int flag)
{
#ifdef CONFIG_ARM64
- void (*kernel_entry)(void *fdt_addr);
+ void (*kernel_entry)(void *fdt_addr, void *res0, void *res1,
+ void *res2);
int fake = (flag BOOTM_STATE_OS_FAKE_GO);
- kernel_entry = (void (*)(void *fdt_addr))images-ep;
+ kernel_entry = (void (*)(void *fdt_addr, void *res0, void *res1,
+ void *res2))images-ep;
debug(## Transferring control to Linux (at address %lx)...\n,
(ulong) kernel_entry);
@@ -252,7 +254,7 @@ static void boot_jump_linux(bootm_headers_t *images, int
flag)
if (!fake) {
do_nonsec_virt_switch();
- kernel_entry(images-ft_addr);
+ kernel_entry(images-ft_addr, NULL, NULL, NULL);
}
#else
unsigned long machid = gd-bd-bi_arch_number;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images
The default format for arm64 Linux kernels is the Image format,
described in Documentation/arm64/booting.txt. This, along with an
optional gzip compression on top is all that is generated by default.
The Image format has a magic number within the header for verification,
a text_offset where the Image must be run from, an image_size that
includes the BSS and reserved fields.
This does not support automatic detection of a gzip compressed image.
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v1:
- Adopt to Mark Rutland's changes now in mainline kernel wrt text_offset
/ image_size
---
README |1 +
common/cmd_bootm.c | 140
include/bootm.h|2 +-
3 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/README b/README
index 1d71359..b9af7ac 100644
--- a/README
+++ b/README
@@ -959,6 +959,7 @@ The following options need to be configured:
CONFIG_CMD_BMP * BMP support
CONFIG_CMD_BSP * Board specific commands
CONFIG_CMD_BOOTD bootd
+ CONFIG_CMD_BOOTI* ARM64 Linux kernel Image support
CONFIG_CMD_CACHE* icache, dcache
CONFIG_CMD_CLK * clock command support
CONFIG_CMD_CONSOLEconinfo
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8b897c8d..843ec6e 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -627,3 +627,143 @@ U_BOOT_CMD(
boot Linux zImage image from memory, bootz_help_text
);
#endif /* CONFIG_CMD_BOOTZ */
+
+#ifdef CONFIG_CMD_BOOTI
+/* See Documentation/arm64/booting.txt in the Linux kernel */
+struct Image_header {
+ uint32_tcode0; /* Executable code */
+ uint32_tcode1; /* Executable code */
+ uint64_ttext_offset;/* Image load offset, LE */
+ uint64_timage_size; /* Effective Image size, LE */
+ uint64_tres1; /* reserved */
+ uint64_tres2; /* reserved */
+ uint64_tres3; /* reserved */
+ uint64_tres4; /* reserved */
+ uint32_tmagic; /* Magic number */
+ uint32_tres5;
+};
+
+#define LINUX_ARM64_IMAGE_MAGIC0x644d5241
+
+static int booti_setup(bootm_headers_t *images)
+{
+ struct Image_header *ih;
+ uint64_t dst;
+
+ ih = (struct Image_header *)map_sysmem(images-ep, 0);
+
+ if (ih-magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
+ puts(Bad Linux ARM64 Image magic!\n);
+ return 1;
+ }
+
+ if (ih-image_size == 0) {
+ puts(Image lacks image_size field, assuming 16MiB\n);
+ ih-image_size = (16 20);
+ }
+
+ /*
+* If we are not at the correct run-time location, set the new
+* correct location and then move the image there.
+*/
+ dst = gd-bd-bi_dram[0].start + le32_to_cpu(ih-text_offset);
+ if (images-ep != dst) {
+ void *src;
+
+ debug(Moving Image from 0x%lx to 0x%llx\n, images-ep, dst);
+
+ src = (void *)images-ep;
+ images-ep = dst;
+ memmove((void *)dst, src, le32_to_cpu(ih-image_size));
+ }
+
+ return 0;
+}
+
+/*
+ * Image booting support
+ */
+static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[], bootm_headers_t *images)
+{
+ int ret;
+ struct Image_header *ih;
+
+ ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
+ images, 1);
+
+ /* Setup Linux kernel Image entry point */
+ if (!argc) {
+ images-ep = load_addr;
+ debug(* kernel: default image load address = 0x%08lx\n,
+ load_addr);
+ } else {
+ images-ep = simple_strtoul(argv[0], NULL, 16);
+ debug(* kernel: cmdline image address = 0x%08lx\n,
+ images-ep);
+ }
+
+ ret = booti_setup(images);
+ if (ret != 0)
+ return 1;
+
+ ih = (struct Image_header *)map_sysmem(images-ep, 0);
+
+ lmb_reserve(images-lmb, images-ep, le32_to_cpu(ih-image_size));
+
+ /*
+* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
+* have a header that provide this informaiton.
+*/
+ if (bootm_find_ramdisk_fdt(flag, argc, argv))
+ return 1;
+
+ return 0;
+}
+
+int do_booti(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ int ret;
+
+ /* Consume 'booti' */
+ argc--; argv++;
+
+ if (booti_start(cmdtp, flag, argc, argv, images))
+ return 1;
+
+ /*
+* We are doing the BOOTM_STATE_LOADOS state ourselves, so must
+* disable interrupts
[U-Boot] [PATCH v2 0/3] test: Extending USB gadget tests infrastructure
New test for UMS regressions catching has been added. Moreover some DFU enhancements have been included as well. Lukasz Majewski (3): test: dfu: Extend dfu_gadget_test_init.sh to accept sizes of test files test: dfu: cosmetic: Add missing license information to DFU test scripts test: ums: Add script for testing UMS gadget operation test/dfu/dfu_gadget_test.sh | 10 +++ test/dfu/dfu_gadget_test_init.sh | 16 +++- test/ums/README | 26 ++ test/ums/ums_gadget_test.sh | 169 +++ 4 files changed, 220 insertions(+), 1 deletion(-) create mode 100644 test/ums/README create mode 100755 test/ums/ums_gadget_test.sh -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] test: dfu: cosmetic: Add missing license information to DFU test scripts
By mistake I've forgotten to add the SPDX license tags for the DFU testing scripts. This commit fixes that and also provides some other relevant information. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Acked-by: Stephen Warren swar...@nvidia.com --- Changes for v2: - None --- test/dfu/dfu_gadget_test.sh | 10 ++ test/dfu/dfu_gadget_test_init.sh | 10 ++ 2 files changed, 20 insertions(+) diff --git a/test/dfu/dfu_gadget_test.sh b/test/dfu/dfu_gadget_test.sh index 4133155..2f5b7db 100755 --- a/test/dfu/dfu_gadget_test.sh +++ b/test/dfu/dfu_gadget_test.sh @@ -1,5 +1,15 @@ #! /bin/bash +# Copyright (C) 2014 Samsung Electronics +# Lukasz Majewski l.majew...@samsung.com +# +# Script fixes, enhancements and testing: +# Stephen Warren swar...@nvidia.com +# +# DFU operation test script +# +# SPDX-License-Identifier: GPL-2.0+ + set -e # any command return if not equal to zero clear diff --git a/test/dfu/dfu_gadget_test_init.sh b/test/dfu/dfu_gadget_test_init.sh index 0d5c6c0..640628e 100755 --- a/test/dfu/dfu_gadget_test_init.sh +++ b/test/dfu/dfu_gadget_test_init.sh @@ -1,5 +1,15 @@ #! /bin/bash +# Copyright (C) 2014 Samsung Electronics +# Lukasz Majewski l.majew...@samsung.com +# +# Script fixes, enhancements and testing: +# Stephen Warren swar...@nvidia.com +# +# Script for test files generation +# +# SPDX-License-Identifier: GPL-2.0+ + set -e # any command return if not equal to zero clear -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] test: dfu: Extend dfu_gadget_test_init.sh to accept sizes of test files
It is now possible to pass to the dfu_gadget_test_init.sh script the sizes of files to be generated. This feature is required by UMS tests which reuse this code. Signed-off-by: Lukasz Majewski l.majew...@samsung.com Acked-by: Stephen Warren swar...@nvidia.com --- Changes for v2: - None --- test/dfu/dfu_gadget_test_init.sh | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/test/dfu/dfu_gadget_test_init.sh b/test/dfu/dfu_gadget_test_init.sh index 2163a68..0d5c6c0 100755 --- a/test/dfu/dfu_gadget_test_init.sh +++ b/test/dfu/dfu_gadget_test_init.sh @@ -9,7 +9,11 @@ COLOUR_DEFAULT=\33[0m LOG_DIR=./log -TEST_FILES_SIZES=63 64 65 127 128 129 4095 4096 4097 959 960 961 1048575 1048576 8M +if [ $# -eq 0 ]; then +TEST_FILES_SIZES=63 64 65 127 128 129 4095 4096 4097 959 960 961 1048575 1048576 8M +else +TEST_FILES_SIZES=$@ +fi printf Init script for generating data necessary for DFU test script -- 2.0.0.rc2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] test: ums: Add script for testing UMS gadget operation
This commit adds new test for UMS USB gadget to u-boot mainline tree.
It is similar in operation to the one already available in test/dfu
directory.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Add -f switch for optional FS creation on target UMS partition
- Remove need for passing FS type to script
- Remove syncs
- Use named variables instead of $1, $2, $3 ... etc
- Create temporary mount directory at /mnt/tmp-ums-test/
- Use target device's VID/PID to find exact mount device (/dev/sdX)
- Add support for Ctrl+C tap
- Rewrite README entry
---
test/ums/README | 26 +++
test/ums/ums_gadget_test.sh | 169
2 files changed, 195 insertions(+)
create mode 100644 test/ums/README
create mode 100755 test/ums/ums_gadget_test.sh
diff --git a/test/ums/README b/test/ums/README
new file mode 100644
index 000..84906be
--- /dev/null
+++ b/test/ums/README
@@ -0,0 +1,26 @@
+UMS test script.
+
+ums_gadget_test.sh
+==
+
+Example usage:
+1. On the target:
+ create UMS exportable partitions (with e.g. gpt write)
+ ums 0 mmc 0
+2. On the host:
+ sudo test/ums/ums_gadget_test.sh VID PID PART_NUM [-f FILE_SYSTEM]
[test_file]
+ e.g. sudo test/ums/ums_gadget_test.sh 04e8 6601 6 -f vfat ./dat_14M.img
+
+... where:
+VID - UMS device USB Vendor ID
+PID - UMS device USB Product ID
+PART_NUM - is the partition number on which UMS operates
+
+Information about available partitions on the target one can read with using
+the 'mmc part' or 'part list' commands.
+
+The [-f FILE_SYSTEM] optional switch allows for formatting target partition to
+FILE_SYSTEM.
+
+The last, optional [test_file] parameter is for specifying the exact test file
+to use.
diff --git a/test/ums/ums_gadget_test.sh b/test/ums/ums_gadget_test.sh
new file mode 100755
index 000..2cfa208
--- /dev/null
+++ b/test/ums/ums_gadget_test.sh
@@ -0,0 +1,169 @@
+#! /bin/bash
+
+# Copyright (C) 2014 Samsung Electronics
+# Lukasz Majewski l.majew...@samsung.com
+#
+# UMS operation test script
+#
+# SPDX-License-Identifier: GPL-2.0+
+
+clear
+
+COLOUR_RED=\33[31m
+COLOUR_GREEN=\33[32m
+COLOUR_DEFAULT=\33[0m
+
+DIR=./
+SUFFIX=img
+RCV_DIR=rcv/
+LOG_FILE=./log/log-`date +%d-%m-%Y_%H-%M-%S`
+
+cd `dirname $0`
+../dfu/dfu_gadget_test_init.sh 33M 97M
+
+cleanup () {
+rm -rf $RCV_DIR $MNT_DIR
+}
+
+control_c()
+# run if user hits control-c
+{
+ echo -en \n*** CTRL+C ***\n
+ umount $MNT_DIR
+ cleanup
+ exit 0
+}
+
+# trap keyboard interrupt (control-c)
+trap control_c SIGINT
+
+die () {
+printf$COLOUR_RED FAILED $COLOUR_DEFAULT \n
+cleanup
+exit 1
+}
+
+calculate_md5sum () {
+MD5SUM=`md5sum $1`
+MD5SUM=`echo $MD5SUM | cut -d ' ' -f1`
+echo md5sum:$MD5SUM
+}
+
+ums_test_file () {
+printf
$COLOUR_GREEN=
$COLOUR_DEFAULT\n
+printf File:$COLOUR_GREEN %s $COLOUR_DEFAULT\n $1
+
+mount /dev/$MEM_DEV $MNT_DIR
+if [ -f $MNT_DIR/dat_* ]; then
+ rm $MNT_DIR/dat_*
+fi
+
+cp ./$1 $MNT_DIR
+umount $MNT_DIR
+
+
+echo -n TX:
+calculate_md5sum $1
+
+MD5_TX=$MD5SUM
+sleep 1
+N_FILE=$DIR$RCV_DIR${1:2}_rcv
+
+mount /dev/$MEM_DEV $MNT_DIR
+cp $MNT_DIR/$1 $N_FILE || die $?
+rm $MNT_DIR/$1
+umount $MNT_DIR
+
+echo -n RX:
+calculate_md5sum $N_FILE
+MD5_RX=$MD5SUM
+
+if [ $MD5_TX == $MD5_RX ]; then
+ printf$COLOUR_GREEN --- OK $COLOUR_DEFAULT \n
+else
+ printf$COLOUR_RED --- FAILED $COLOUR_DEFAULT \n
+ cleanup
+ exit 1
+fi
+}
+
+printf
$COLOUR_GREEN=
$COLOUR_DEFAULT\n
+echo U-boot UMS test program
+
+if [ $EUID -ne 0 ]; then
+ echo You must be root to do this. 12
+ exit 100
+fi
+
+if [ $# -lt 3 ]; then
+echo Wrong number of arguments
+echo Example:
+echo sudo ./ums_gadget_test.sh VID PID PART_NUM [-f ext4] [test_file]
+die
+fi
+
+MNT_DIR=/mnt/tmp-ums-test
+
+VID=$1; shift
+PID=$1; shift
+PART_NUM=$1; shift
+
+if [ $1 == -f ]; then
+shift
+FS_TO_FORMAT=$1; shift
+fi
+
+TEST_FILE=$1
+
+idVendor=`find /sys -type f -name idVendor -exec grep -w $VID {} \;`
+idProduct=`find /sys -type f -name idProduct -exec grep -w $PID {} \;`
+if [ -z $idVendor ] || [ -z $idProduct ]; then
+echo Device $VID:$PID not connected!
+exit 0
+fi
+
+USB_DEV=`find /sys -type f -name idProduct -exec grep -l $PID {} \;`
+USB_DEV=`dirname $USB_DEV`
+
+MEM_DEV=`find $USB_DEV -name sd[a-z] | awk -F/ '{print $(NF)}' -`
+if [ -z $MEM_DEV ]; then
+echo Connect target
+echo e.g. ums 0 mmc 0
+die
+fi
+
+mkdir -p $RCV_DIR
+if [ ! -d $MNT_DIR ]; then
+mkdir -p $MNT_DIR
+fi
+
+MEM_DEV=$MEM_DEV$PART_NUM
+
+if [ -n $FS_TO_FORMAT ]; then
+echo -n Formatting partition /dev/$MEM_DEV to $FS_TO_FORMAT
+
Re: [U-Boot] [PATCH 1/3] README: document CONFIG_BOARD_SIZE_LIMIT
On Sun, 11 Aug 2013 16:40:43 +0200 Sascha Silbe t-ub...@infra-silbe.de wrote: CONFIG_BOARD_SIZE_LIMIT was introduced by f3a14d37 [Makefile: allow boards to check file size limits] and is in use by several boards, but never got documented. Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de --- README | 5 + 1 file changed, 5 insertions(+) applied to u-boot-staging/ag...@denx.de. thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] openrd: fail build if U-Boot would overlap with environment in flash
On Sun, 11 Aug 2013 16:40:45 +0200 Sascha Silbe t-ub...@infra-silbe.de wrote: Set CONFIG_BOARD_SIZE_LIMIT so we'll notice at build time if U-Boot has grown so large that it would overlap with the environment area in flash, rather than bricking the device at run-time on first saveenv. Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de --- include/configs/openrd.h | 5 + 1 file changed, 5 insertions(+) applied to u-boot-staging/ag...@denx.de. thanks! Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Makefile: check native boot image sizes against CONFIG_BOARD_SIZE_LIMIT
On Sun, 11 Aug 2013 16:40:44 +0200 Sascha Silbe t-ub...@infra-silbe.de wrote: The purpose of CONFIG_BOARD_SIZE_LIMIT is to make sure that U-Boot fits into the space reserved for it in some permanent storage. This includes any overhead incurred by native boot image formats, so check the final image against the size limit, too. Signed-off-by: Sascha Silbe t-ub...@infra-silbe.de --- Makefile | 3 +++ 1 file changed, 3 insertions(+) this patch doesn't apply any more. Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mtd: nand: add Freescale NFC driver
On 13 Aug 2014, scottw...@freescale.com wrote: On Wed, 2014-08-13 at 17:44 -0400, Bill Pringlemeir wrote: Regarding can't know in advance, I think that some of the register values maybe set by the boot rom. This might make more sense for Linux than U-Boot. However, after the initial configuration, many do need the 'read/modify/write' as there are many bit fields with different functionality. If the register is only modified by software, and not asynchronously by hardware, then you could read the value once when the driver starts, and cache its value to avoid a reportedly expensive I/O access every time you need to modify it. Yes, that is a good point. The regmap interface could be used in the Linux kernel. I don't see any infrastructure like that in U-Boot? It is fairly simple to re-invent as this driver only needs the flat structure. Regards, Bill Pringlemeir. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] nios2: Fix printf size_t format related warnings (again...)
When compiling the current code on GCC 4.8.3, the following warnings appear: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat=] There were many mails about such warnings on different architectures. This patch limits itself to the nios2 architecture. The problem is that for the size_t (%zu, %zd, ...) arguments of printf GCC does not verify the type match to size_t type. It verifies the type match to the compiler-defined __SIZE_TYPE__ type. Thus, if size_t is defined different from __SIZE_TYPE__ - warnings inevitably appear. There is a comment by Thomas Chou to the (rejected) patch: http://patchwork.ozlabs.org/patch/272102/ which explains that the older GCC toolchains (gcc-3.4.6 and gcc-4.1.2) expect size_t to be unsigned long and the newer expect it to be unsigned int. Thus, no matter how we define size_t - either way warnings appear when using some GCC version. By rejecting that patch, a choice was made to prefer older GCC versions and leave the warnings when building with the newer toolchains. Personally, I disagree with this choice... In any case, this patch proposes a way to fix the warnings for any GCC version. Just define size_t using the __SIZE_TYPE__ compiler-defined type and the type verification will pass. I tested that this fixes the warning on GCC 4.8.3. I don't have an older toolchain to test with, but __SIZE_TYPE__ was definitely defined in GCC 3.4.6, so it should work there too. Signed-off-by: Vasili Galka vvv...@gmail.com Cc: Thomas Chou tho...@wytron.com.tw --- arch/nios2/include/asm/posix_types.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/nios2/include/asm/posix_types.h b/arch/nios2/include/asm/posix_types.h index 6733640..6b6c39b 100644 --- a/arch/nios2/include/asm/posix_types.h +++ b/arch/nios2/include/asm/posix_types.h @@ -16,7 +16,11 @@ typedef int __kernel_pid_t; typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; +#ifdef __GNUC__ +typedef __SIZE_TYPE__ __kernel_size_t; +#else typedef unsigned long __kernel_size_t; +#endif typedef long __kernel_ssize_t; typedef int__kernel_ptrdiff_t; typedef long __kernel_time_t; -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sbc8548: enable and test CONFIG_SYS_GENERIC_BOARD
Tested on the following baseline (note dirty since I enabled ALT_BOOT in the config in order to use the alternate boot bank.) Everything seems to work fine with no additional changes. The banner warning message is now gone. --- U-Boot 2014.10-rc1-00075-ge49f14af1349-dirty (Aug 14 2014 - 10:26:15) CPU: 8548E, Version: 2.1, (0x80390021) Core: e500, Version: 2.2, (0x80210022) Clock Configuration: CPU0:990 MHz, CCB:396 MHz, DDR:198 MHz (396 MT/s data rate), LBC:99 MHz L1:D-cache 32 KiB enabled I-cache 32 KiB enabled I2C: ready DRAM: Detected UDIMM SDRAM: 128 MiB 256 MiB (DDR2, 64-bit, CL=3, ECC off) Flash: 72 MiB L2:512 KiB enabled *** Warning - bad CRC, using default environment PCI: Host, 64 bit, 66 MHz, sync, arbiter 00:01.0 - 8086:1026 - Network controller PCI1: Bus 00 - 00 PCIe1: Root Complex, x1 gen1, regs @ 0xe000a000 02:00.0 - 1148:9e00 - Network controller PCIe1: Bus 01 - 02 In:serial Out: serial Err: serial Net: eTSEC0 [PRIME], eTSEC1 Hit any key to stop autoboot: 0 = ver U-Boot 2014.10-rc1-00075-ge49f14af1349-dirty (Aug 14 2014 - 10:26:15) powerpc-linux-gcc (GCC) 4.5.2 GNU ld (GNU Binutils) 2.21 = --- Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- include/configs/sbc8548.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/sbc8548.h b/include/configs/sbc8548.h index f28f350fcc86..aee0d9e27309 100644 --- a/include/configs/sbc8548.h +++ b/include/configs/sbc8548.h @@ -13,6 +13,8 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD + /* * Top level Makefile configuration choices */ -- 1.9.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images
Hi Tom,
On Thu, Aug 14, 2014 at 11:42:36AM +0100, Tom Rini wrote:
The default format for arm64 Linux kernels is the Image format,
described in Documentation/arm64/booting.txt. This, along with an
optional gzip compression on top is all that is generated by default.
The Image format has a magic number within the header for verification,
a text_offset where the Image must be run from, an image_size that
includes the BSS and reserved fields.
This does not support automatic detection of a gzip compressed image.
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v1:
- Adopt to Mark Rutland's changes now in mainline kernel wrt text_offset
/ image_size
---
README |1 +
common/cmd_bootm.c | 140
include/bootm.h|2 +-
3 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/README b/README
index 1d71359..b9af7ac 100644
--- a/README
+++ b/README
@@ -959,6 +959,7 @@ The following options need to be configured:
CONFIG_CMD_BMP * BMP support
CONFIG_CMD_BSP * Board specific commands
CONFIG_CMD_BOOTD bootd
+ CONFIG_CMD_BOOTI* ARM64 Linux kernel Image support
CONFIG_CMD_CACHE* icache, dcache
CONFIG_CMD_CLK * clock command support
CONFIG_CMD_CONSOLEconinfo
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8b897c8d..843ec6e 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -627,3 +627,143 @@ U_BOOT_CMD(
boot Linux zImage image from memory, bootz_help_text
);
#endif /* CONFIG_CMD_BOOTZ */
+
+#ifdef CONFIG_CMD_BOOTI
+/* See Documentation/arm64/booting.txt in the Linux kernel */
+struct Image_header {
+ uint32_tcode0; /* Executable code */
+ uint32_tcode1; /* Executable code */
+ uint64_ttext_offset;/* Image load offset, LE */
+ uint64_timage_size; /* Effective Image size, LE */
+ uint64_tres1; /* reserved */
+ uint64_tres2; /* reserved */
+ uint64_tres3; /* reserved */
+ uint64_tres4; /* reserved */
+ uint32_tmagic; /* Magic number */
+ uint32_tres5;
+};
+
+#define LINUX_ARM64_IMAGE_MAGIC 0x644d5241
+
+static int booti_setup(bootm_headers_t *images)
+{
+ struct Image_header *ih;
+ uint64_t dst;
+
+ ih = (struct Image_header *)map_sysmem(images-ep, 0);
+
+ if (ih-magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
+ puts(Bad Linux ARM64 Image magic!\n);
+ return 1;
+ }
+
+ if (ih-image_size == 0) {
+ puts(Image lacks image_size field, assuming 16MiB\n);
+ ih-image_size = (16 20);
+ }
This should work for a defconfig, but it might be possible to build a
larger kernel. From experiments with an allyesconfig, I can build a
~60MB kernel with ~20MB of uninitialised data after the end of the
Image.
Modifying the Image feels a little dodgy, but I can't think of anything
this would break.
+
+ /*
+ * If we are not at the correct run-time location, set the new
+ * correct location and then move the image there.
+ */
+ dst = gd-bd-bi_dram[0].start + le32_to_cpu(ih-text_offset);
This should be le64_to_cpu(ih-text_offset) to be strictly correct.
I wouldn't imagine we'd ever have a text_offset larger than 4GB, but it
would be nice to keep things consistent with the documentation and
kernel code.
+ if (images-ep != dst) {
+ void *src;
+
+ debug(Moving Image from 0x%lx to 0x%llx\n, images-ep, dst);
+
+ src = (void *)images-ep;
+ images-ep = dst;
+ memmove((void *)dst, src, le32_to_cpu(ih-image_size));
Likewise.
+ }
+
+ return 0;
+}
+
+/*
+ * Image booting support
+ */
+static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[], bootm_headers_t *images)
+{
+ int ret;
+ struct Image_header *ih;
+
+ ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
+ images, 1);
+
+ /* Setup Linux kernel Image entry point */
+ if (!argc) {
+ images-ep = load_addr;
+ debug(* kernel: default image load address = 0x%08lx\n,
+ load_addr);
+ } else {
+ images-ep = simple_strtoul(argv[0], NULL, 16);
+ debug(* kernel: cmdline image address = 0x%08lx\n,
+ images-ep);
+ }
+
+ ret = booti_setup(images);
+ if (ret != 0)
+ return 1;
+
+ ih = (struct Image_header *)map_sysmem(images-ep, 0);
+
+ lmb_reserve(images-lmb, images-ep, le32_to_cpu(ih-image_size));
Re: [U-Boot] [PATCH 02/11] imx: ventana: added cputype env var
On 08/08/2014 07:35, Tim Harvey wrote: There are many similarities between the IMX6QUAD/IMX6DUAL and there are many similarities between the IMX6SOLO/IMX6DUALITE. Add a 'soctype' env variable that tells you which type you have. Signed-off-by: Tim Harvey thar...@gateworks.com --- board/gateworks/gw_ventana/gw_ventana.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/gateworks/gw_ventana/gw_ventana.c b/board/gateworks/gw_ventana/gw_ventana.c index a8fcb5d..de2336e 100644 --- a/board/gateworks/gw_ventana/gw_ventana.c +++ b/board/gateworks/gw_ventana/gw_ventana.c @@ -1264,6 +1264,7 @@ int misc_init_r(void) else if (is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO)) cputype = imx6dl; + setenv(soctype, cputype); So you have soc=mx6 and soctype=value of cputype, if CONFIG_SYS_SOC is set. Is it important to have both or you can simply redefine the variable soc ? 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/4] Add option -r to env import to allow import of text files with CRLF as line endings
On 08/14/2014 02:25 AM, Alexander Holler wrote: Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] arm: vf610: add NFC clock support
Add NFC (NAND Flash Controller) clock support and enable them
at board initialization time.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/include/asm/arch-vf610/crm_regs.h | 14 ++
arch/arm/include/asm/arch-vf610/imx-regs.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 5256624..724682c 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -156,14 +156,27 @@ struct anadig_reg {
#define CCM_CSCMR1_ESDHC1_CLK_SEL_OFFSET 18
#define CCM_CSCMR1_ESDHC1_CLK_SEL_MASK (0x3 18)
#define CCM_CSCMR1_ESDHC1_CLK_SEL(v) (((v) 0x3) 18)
+#define CCM_CSCMR1_NFC_CLK_SEL_OFFSET 12
+#define CCM_CSCMR1_NFC_CLK_SEL_MASK(0x3 12)
+#define CCM_CSCMR1_NFC_CLK_SEL(v) (((v) 0x3) 12)
#define CCM_CSCDR1_RMII_CLK_EN (1 24)
+#define CCM_CSCDR2_NFC_EN (1 9)
+#define CCM_CSCDR2_NFC_FRAC_DIV_EN (1 13)
+#define CCM_CSCDR2_NFC_CLK_INV (1 14)
+#define CCM_CSCDR2_NFC_FRAC_DIV_OFFSET 4
+#define CCM_CSCDR2_NFC_FRAC_DIV_MASK (0xf 4)
+#define CCM_CSCDR2_NFC_FRAC_DIV(v) (((v) 0xf) 4)
+
#define CCM_CSCDR2_ESDHC1_EN (1 29)
#define CCM_CSCDR2_ESDHC1_CLK_DIV_OFFSET 20
#define CCM_CSCDR2_ESDHC1_CLK_DIV_MASK (0xf 20)
#define CCM_CSCDR2_ESDHC1_CLK_DIV(v) (((v) 0xf) 20)
+#define CCM_CSCDR3_NFC_PRE_DIV_OFFSET 13
+#define CCM_CSCDR3_NFC_PRE_DIV_MASK(0x7 13)
+#define CCM_CSCDR3_NFC_PRE_DIV(v) (((v) 0x7) 13)
#define CCM_CSCDR3_QSPI0_EN(1 4)
#define CCM_CSCDR3_QSPI0_DIV(v)((v) 3)
#define CCM_CSCDR3_QSPI0_X2_DIV(v) ((v) 2)
@@ -195,6 +208,7 @@ struct anadig_reg {
#define CCM_CCGR7_SDHC1_CTRL_MASK (0x3 4)
#define CCM_CCGR9_FEC0_CTRL_MASK 0x3
#define CCM_CCGR9_FEC1_CTRL_MASK (0x3 2)
+#define CCM_CCGR10_NFC_CTRL_MASK 0x3
#define ANADIG_PLL5_CTRL_BYPASS (1 16)
#define ANADIG_PLL5_CTRL_ENABLE (1 13)
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index bd6f680..bb00217 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -86,6 +86,7 @@
#define ESDHC1_BASE_ADDR (AIPS1_BASE_ADDR + 0x00032000)
#define ENET_BASE_ADDR (AIPS1_BASE_ADDR + 0x0005)
#define ENET1_BASE_ADDR(AIPS1_BASE_ADDR + 0x00051000)
+#define NFC_BASE_ADDR (AIPS1_BASE_ADDR + 0x0006)
#define QSPI0_AMBA_BASE0x2000
--
2.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] arm: vf610: add NAND support for vf610twr
This adds NAND Flash Controller (NFC) support for the Vybrid tower
system (TWR-VF65GS10). Full 16-Bit bus width is supported. Also an
aditional config vf610twr_nand is introduced which gets the
environment from NAND. However, booting U-Boot from NAND is not
yet possible due to missing boot configuration block (BCB).
Signed-off-by: Stefan Agner ste...@agner.ch
---
board/freescale/vf610twr/vf610twr.c | 47 ++---
configs/vf610twr_defconfig | 2 +-
configs/vf610twr_nand_defconfig | 3 +++
include/configs/vf610twr.h | 46 +++-
4 files changed, 93 insertions(+), 5 deletions(-)
create mode 100644 configs/vf610twr_nand_defconfig
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 54a9f2c..4d09796 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -278,6 +278,39 @@ static void setup_iomux_i2c(void)
imx_iomux_v3_setup_multiple_pads(i2c0_pads, ARRAY_SIZE(i2c0_pads));
}
+#ifdef CONFIG_NAND_VF610_NFC
+static void setup_iomux_nfc(void)
+{
+ static const iomux_v3_cfg_t nfc_pads[] = {
+ VF610_PAD_PTD31__NF_IO15,
+ VF610_PAD_PTD30__NF_IO14,
+ VF610_PAD_PTD29__NF_IO13,
+ VF610_PAD_PTD28__NF_IO12,
+ VF610_PAD_PTD27__NF_IO11,
+ VF610_PAD_PTD26__NF_IO10,
+ VF610_PAD_PTD25__NF_IO9,
+ VF610_PAD_PTD24__NF_IO8,
+ VF610_PAD_PTD23__NF_IO7,
+ VF610_PAD_PTD22__NF_IO6,
+ VF610_PAD_PTD21__NF_IO5,
+ VF610_PAD_PTD20__NF_IO4,
+ VF610_PAD_PTD19__NF_IO3,
+ VF610_PAD_PTD18__NF_IO2,
+ VF610_PAD_PTD17__NF_IO1,
+ VF610_PAD_PTD16__NF_IO0,
+ VF610_PAD_PTB24__NF_WE_B,
+ VF610_PAD_PTB25__NF_CE0_B,
+ VF610_PAD_PTB27__NF_RE_B,
+ VF610_PAD_PTC26__NF_RB_B,
+ VF610_PAD_PTC27__NF_ALE,
+ VF610_PAD_PTC28__NF_CLE
+ };
+
+ imx_iomux_v3_setup_multiple_pads(nfc_pads, ARRAY_SIZE(nfc_pads));
+}
+#endif
+
+
static void setup_iomux_qspi(void)
{
static const iomux_v3_cfg_t qspi0_pads[] = {
@@ -354,6 +387,8 @@ static void clock_init(void)
CCM_CCGR7_SDHC1_CTRL_MASK);
clrsetbits_le32(ccm-ccgr9, CCM_REG_CTRL_MASK,
CCM_CCGR9_FEC0_CTRL_MASK | CCM_CCGR9_FEC1_CTRL_MASK);
+ clrsetbits_le32(ccm-ccgr10, CCM_REG_CTRL_MASK,
+ CCM_CCGR10_NFC_CTRL_MASK);
clrsetbits_le32(anadig-pll2_ctrl, ANADIG_PLL2_CTRL_POWERDOWN,
ANADIG_PLL2_CTRL_ENABLE | ANADIG_PLL2_CTRL_DIV_SELECT);
@@ -373,14 +408,17 @@ static void clock_init(void)
CCM_CACRR_IPG_CLK_DIV(1) | CCM_CACRR_BUS_CLK_DIV(2) |
CCM_CACRR_ARM_CLK_DIV(0));
clrsetbits_le32(ccm-cscmr1, CCM_REG_CTRL_MASK,
- CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3));
+ CCM_CSCMR1_ESDHC1_CLK_SEL(3) | CCM_CSCMR1_QSPI0_CLK_SEL(3) |
+ CCM_CSCMR1_NFC_CLK_SEL(0));
clrsetbits_le32(ccm-cscdr1, CCM_REG_CTRL_MASK,
CCM_CSCDR1_RMII_CLK_EN);
clrsetbits_le32(ccm-cscdr2, CCM_REG_CTRL_MASK,
- CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0));
+ CCM_CSCDR2_ESDHC1_EN | CCM_CSCDR2_ESDHC1_CLK_DIV(0) |
+ CCM_CSCDR2_NFC_EN);
clrsetbits_le32(ccm-cscdr3, CCM_REG_CTRL_MASK,
CCM_CSCDR3_QSPI0_EN | CCM_CSCDR3_QSPI0_DIV(1) |
- CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3));
+ CCM_CSCDR3_QSPI0_X2_DIV(1) | CCM_CSCDR3_QSPI0_X4_DIV(3) |
+ CCM_CSCDR3_NFC_PRE_DIV(5));
clrsetbits_le32(ccm-cscmr2, CCM_REG_CTRL_MASK,
CCM_CSCMR2_RMII_CLK_SEL(0));
}
@@ -411,6 +449,9 @@ int board_early_init_f(void)
setup_iomux_enet();
setup_iomux_i2c();
setup_iomux_qspi();
+#ifdef CONFIG_NAND_VF610_NFC
+ setup_iomux_nfc();
+#endif
return 0;
}
diff --git a/configs/vf610twr_defconfig b/configs/vf610twr_defconfig
index 10e6432..7de374a 100644
--- a/configs/vf610twr_defconfig
+++ b/configs/vf610twr_defconfig
@@ -1,3 +1,3 @@
-CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_MMC
CONFIG_ARM=y
CONFIG_TARGET_VF610TWR=y
diff --git a/configs/vf610twr_nand_defconfig b/configs/vf610twr_nand_defconfig
new file mode 100644
index 000..e78db26
--- /dev/null
+++ b/configs/vf610twr_nand_defconfig
@@ -0,0 +1,3 @@
+CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/vf610twr/imximage.cfg,ENV_IS_IN_NAND
+CONFIG_ARM=y
+CONFIG_TARGET_VF610TWR=y
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 0342550..6fd0b17 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/vf610twr.h
@@
[U-Boot] [PATCH v2 0/4] arm: vf610: add NAND flash support
This patch set adds NAND Flash Controller (NFC) support for Freescale Vybrid ARM SoCs (vf610). The driver is based on Bill Pringlemeirs prelineary patch sent in January 2014 to the MTD mailing list: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226623.html Changes in v2: - Renamed the driver from fsl_nfc to vf610_nfc - Use writel/readl in register access functions - Optimized some register accesses by read/write value only once in code - Use CONFIG_SYS_NAND_SELF_INIT and fix board_nand_init implementation - Removed uncommented code/fixed comments - Add CONFIG_USE_ARCH_MEMCPY for improved NAND performance - Use hweight32 for improved count_written_bits performance - Implement page_read/page_write rather than reuse MTD stacks version Due to the duplicated initialization (missing SELF_INIT), page size was actually set to 0 which lead count_written_bits to not count the amount of written bits at all. Performance numbers: V1 = optimized count_written_bits Read empty pages: 0.8MiB/s = 1.4MiB/s V1 = optimized memcpy = optimized page_read/page_write Read full pages: 3.6MiB/s = 7MiB/s = 10.3MiB/s Stefan Agner (4): arm: vf610: add NFC pin mux arm: vf610: add NFC clock support mtd: nand: add Freescale NFC driver arm: vf610: add NAND support for vf610twr arch/arm/include/asm/arch-vf610/crm_regs.h| 14 + arch/arm/include/asm/arch-vf610/imx-regs.h| 1 + arch/arm/include/asm/arch-vf610/iomux-vf610.h | 34 ++ arch/arm/include/asm/imx-common/iomux-v3.h| 4 + board/freescale/vf610twr/vf610twr.c | 47 +- configs/vf610twr_defconfig| 2 +- configs/vf610twr_nand_defconfig | 3 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/vf610_nfc.c | 706 ++ include/configs/vf610twr.h| 46 +- 10 files changed, 853 insertions(+), 5 deletions(-) create mode 100644 configs/vf610twr_nand_defconfig create mode 100644 drivers/mtd/nand/vf610_nfc.c -- 2.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] arm: vf610: add NFC pin mux
Add pin mux for NAND Flash Controller (NFC). NAND can be connected
using 8 or 16 data lines, this patch adds pin mux entries for all
16 data lines.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 34 +++
arch/arm/include/asm/imx-common/iomux-v3.h| 4
2 files changed, 38 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index a965641..7464da8 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -19,6 +19,13 @@
#define VF610_DDR_PAD_CTRL PAD_CTL_DSE_25ohm
#define VF610_I2C_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_50ohm | \
PAD_CTL_SPEED_HIGH | PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_NFC_IO_PAD_CTRL (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+ PAD_CTL_DSE_50ohm | PAD_CTL_PUS_47K_UP | \
+ PAD_CTL_OBE_IBE_ENABLE)
+#define VF610_NFC_CN_PAD_CTRL (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+ PAD_CTL_DSE_25ohm | PAD_CTL_OBE_ENABLE)
+#define VF610_NFC_RB_PAD_CTRL (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
+ PAD_CTL_PUS_22K_UP | PAD_CTL_IBE_ENABLE)
#define VF610_QSPI_PAD_CTRL(PAD_CTL_SPEED_HIGH | PAD_CTL_DSE_150ohm | \
PAD_CTL_PUS_22K_UP | PAD_CTL_OBE_IBE_ENABLE)
@@ -56,6 +63,15 @@ enum {
VF610_PAD_PTA29__ESDHC1_DAT3= IOMUX_PAD(0x004c, 0x004c, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTB14__I2C0_SCL = IOMUX_PAD(0x0090, 0x0090, 2,
0x033c, 1, VF610_I2C_PAD_CTRL),
VF610_PAD_PTB15__I2C0_SDA = IOMUX_PAD(0x0094, 0x0094, 2,
0x0340, 1, VF610_I2C_PAD_CTRL),
+ VF610_PAD_PTD31__NF_IO15= IOMUX_PAD(0x00fc, 0x00fc, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD30__NF_IO14= IOMUX_PAD(0x0100, 0x0100, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD29__NF_IO13= IOMUX_PAD(0x0104, 0x0104, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD28__NF_IO12= IOMUX_PAD(0x0108, 0x0108, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD27__NF_IO11= IOMUX_PAD(0x010c, 0x010c, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD26__NF_IO10= IOMUX_PAD(0x0110, 0x0110, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD25__NF_IO9 = IOMUX_PAD(0x0114, 0x0114, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD24__NF_IO8 = IOMUX_PAD(0x0118, 0x0118, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD23__NF_IO7 = IOMUX_PAD(0x011c, 0x011c, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD0__QSPI0_A_QSCK= IOMUX_PAD(0x013c, 0x013c, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD1__QSPI0_A_CS0 = IOMUX_PAD(0x0140, 0x0140, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD2__QSPI0_A_DATA3 = IOMUX_PAD(0x0144, 0x0144, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
@@ -68,6 +84,24 @@ enum {
VF610_PAD_PTD10__QSPI0_B_DATA2 = IOMUX_PAD(0x0164, 0x0164, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD11__QSPI0_B_DATA1 = IOMUX_PAD(0x0168, 0x0168, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD12__QSPI0_B_DATA0 = IOMUX_PAD(0x016c, 0x016c, 1,
__NA_, 0, VF610_QSPI_PAD_CTRL),
+ VF610_PAD_PTD22__NF_IO6 = IOMUX_PAD(0x0120, 0x0120, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD21__NF_IO5 = IOMUX_PAD(0x0124, 0x0124, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD20__NF_IO4 = IOMUX_PAD(0x0128, 0x0128, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD19__NF_IO3 = IOMUX_PAD(0x012c, 0x012c, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD18__NF_IO2 = IOMUX_PAD(0x0130, 0x0130, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD17__NF_IO1 = IOMUX_PAD(0x0134, 0x0134, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD16__NF_IO0 = IOMUX_PAD(0x0138, 0x0138, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTB24__NF_WE_B= IOMUX_PAD(0x0178, 0x0178, 5,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+ VF610_PAD_PTB25__NF_CE0_B = IOMUX_PAD(0x017c, 0x017c, 5,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+ VF610_PAD_PTB27__NF_RE_B= IOMUX_PAD(0x0184, 0x0184, 6,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+ VF610_PAD_PTC26__NF_RB_B= IOMUX_PAD(0x018C, 0x018C, 5,
__NA_, 0, VF610_NFC_RB_PAD_CTRL),
+
+ VF610_PAD_PTC27__NF_ALE = IOMUX_PAD(0x0190, 0x0190, 6,
__NA_, 0, VF610_NFC_CN_PAD_CTRL),
+
+ VF610_PAD_PTC28__NF_CLE =
[U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver
This adds initial support for Freescale NFC (NAND Flash Controller) found in ARM Vybrid SoC's, Power Architecture MPC5125 and others. However, this driver is only tested on Vybrid. Signed-off-by: Stefan Agner ste...@agner.ch --- drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 706 +++ 2 files changed, 707 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..eef86d1 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_NAND_MXC) += mxc_nand.o obj-$(CONFIG_NAND_MXS) += mxs_nand.o obj-$(CONFIG_NAND_NDFC) += ndfc.o diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..3150ac1 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,706 @@ +/* + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Ported to U-Boot by Stefan Agner + * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir + * Jason ported to M54418TWR and MVFA5. + * Authors: Stefan Agner stefan.ag...@toradex.com + * Bill Pringlemeir bpringlem...@nbsps.com + * Shaohui Xie b21...@freescale.com + * Jason Jin jason@freescale.com + * + * Based on original driver mpc5121_nfc.c. + * + * This is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + * - Only 2K page w. 64+OOB and hardware ECC. + */ + +#include common.h +#include malloc.h + +#include linux/mtd/mtd.h +#include linux/mtd/nand.h +#include linux/mtd/partitions.h + +#include nand.h +#include errno.h +#include asm/io.h +#include asm/processor.h + +#defineDRV_NAMEfsl_nfc + +/* Register Offsets */ +#define NFC_FLASH_CMD1 0x3F00 +#define NFC_FLASH_CMD2 0x3F04 +#define NFC_COL_ADDR 0x3F08 +#define NFC_ROW_ADDR 0x3F0c +#define NFC_ROW_ADDR_INC 0x3F14 +#define NFC_FLASH_STATUS1 0x3F18 +#define NFC_FLASH_STATUS2 0x3F1c +#define NFC_CACHE_SWAP 0x3F28 +#define NFC_SECTOR_SIZE0x3F2c +#define NFC_FLASH_CONFIG 0x3F30 +#define NFC_IRQ_STATUS 0x3F38 + +/* Addresses for NFC MAIN RAM BUFFER areas */ +#define NFC_MAIN_AREA(n) ((n) * 0x1000) + +#define PAGE_2K0x0800 +#define OOB_64 0x0040 + +/* + * NFC_CMD2[CODE] values. See section: + * - 31.4.7 Flash Command Code Description, Vybrid manual + * - 23.8.6 Flash Command Sequencer, MPC5125 manual + * + * Briefly these are bitmasks of controller cycles. + */ +#define READ_PAGE_CMD_CODE 0x7EE0 +#define PROGRAM_PAGE_CMD_CODE 0x7FC0 +#define ERASE_CMD_CODE 0x4EC0 +#define READ_ID_CMD_CODE 0x4804 +#define RESET_CMD_CODE 0x4040 +#define STATUS_READ_CMD_CODE 0x4068 + +/* NFC ECC mode define */ +#define ECC_BYPASS 0 +#define ECC_45_BYTE6 + +/*** Register Mask and bit definitions */ + +/* NFC_FLASH_CMD1 Field */ +#define CMD_BYTE2_MASK 0xFF00 +#define CMD_BYTE2_SHIFT24 + +/* NFC_FLASH_CM2 Field */ +#define CMD_BYTE1_MASK 0xFF00 +#define CMD_BYTE1_SHIFT24 +#define CMD_CODE_MASK 0x0000 +#define CMD_CODE_SHIFT 8 +#define BUFNO_MASK 0x0006 +#define BUFNO_SHIFT1 +#define START_BIT (10) + +/* NFC_COL_ADDR Field */ +#define COL_ADDR_MASK 0x +#define COL_ADDR_SHIFT 0 + +/* NFC_ROW_ADDR Field */ +#define ROW_ADDR_MASK 0x00FF +#define ROW_ADDR_SHIFT 0 +#define ROW_ADDR_CHIP_SEL_RB_MASK 0xF000 +#define ROW_ADDR_CHIP_SEL_RB_SHIFT 28 +#define ROW_ADDR_CHIP_SEL_MASK 0x0F00 +#define ROW_ADDR_CHIP_SEL_SHIFT24 + +/* NFC_FLASH_STATUS2 Field */ +#define STATUS_BYTE1_MASK 0x00FF + +/* NFC_FLASH_CONFIG Field */ +#define CONFIG_ECC_SRAM_ADDR_MASK
[U-Boot] uboot halts when stdio configured for netconsole and network cable disconnected
Hi, I found an old reference (http://lists.denx.de/pipermail/u-boot/2012-January/114850.html) to a problem that I am currently experiencing when configuring my target for netconsole startup. Everything works fine when the network cable is connected, boot count expires and the kernel is loaded, but when the network cable is disconnected uboot halts and boot count does not expire. As soon as the network cable is re-connected then the boot count counts down and expires and the kernel is loaded. For my application I want the system to boot and load the kernel regardless of whether the network cable is connected or not. I was wondering whether a patch was ever produced to address this behaviour? Regards, Les Loveridge. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 04/18] net: mdio: Add private MDIO read/write function
On 08/13/2014 11:44 PM, Alison Wang wrote:
As extra FPGA settings is needed for MDIO read/write
on LS1021AQDS, private MDIO read/write functions are
created.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: No change.
v3: Split from the 0004-arm-ls102xa-Add-etsec-support-for-LS102xA patch.
v2: Add private mdio read and write support.
drivers/net/fsl_mdio.c | 9 +++--
include/fsl_mdio.h | 4
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 8d09f5d..6eae78f 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
@@ -98,8 +98,13 @@ int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info
*info)
return -1;
}
- bus-read = tsec_phy_read;
- bus-write = tsec_phy_write;
+ if (info-priv_mdio_read) {
+ bus-read = info-priv_mdio_read;
+ bus-write = info-priv_mdio_write;
+ } else {
+ bus-read = tsec_phy_read;
+ bus-write = tsec_phy_write;
+ }
bus-reset = fsl_pq_mdio_reset;
sprintf(bus-name, info-name);
diff --git a/include/fsl_mdio.h b/include/fsl_mdio.h
index a531edf..633123c 100644
--- a/include/fsl_mdio.h
+++ b/include/fsl_mdio.h
@@ -57,6 +57,10 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr,
int dev_addr,
struct fsl_pq_mdio_info {
struct tsec_mii_mng __iomem *regs;
char *name;
+ int (*priv_mdio_read)(struct mii_dev *bus, int addr,
+ int devad, int reg);
+ int (*priv_mdio_write)(struct mii_dev *bus, int addr, int devad,
+int reg, u16 val);
};
int fsl_pq_mdio_init(bd_t *bis, struct fsl_pq_mdio_info *info);
Alison,
Please check if Shaohui's comment on your v3 patch is valid. He suggested you
don't need to add a new private functions.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 02/18] ls102xa: i2c: Add i2c support for LS102xA
On 08/13/2014 11:44 PM, Alison Wang wrote: This patch is to add I2C 1,2,3 support for LS102xA. I think the commit message should say which existing I2C driver is compatible with the controller of LS201x. From the change, you are using the same driver for i.MX. But it is not clear if you are using the 8-bit driver or the 32-bit driver. I can tell from your patch 01/18 that you enabled I2C_QUIRK_REG to use 8-bit driver. This should go into the commit message to help other follow the suit if another SoC is added the same way. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 16/18] video: dcu: Add Sii9022A HDMI Transmitter support
On 08/13/2014 11:45 PM, Alison Wang wrote: On LS1021ATWR, Silicon's Sii9022A HDMI Transmitter is used. This patch adds the common setting for this chip. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: Add commit messages. v3: New file. board/freescale/common/Makefile | 2 + board/freescale/common/dcu_sii9022a.c | 153 ++ board/freescale/common/dcu_sii9022a.h | 13 +++ 3 files changed, 168 insertions(+) create mode 100644 board/freescale/common/dcu_sii9022a.c create mode 100644 board/freescale/common/dcu_sii9022a.h Shouldn't this driver stay under driver/video? It is for the HDMI transmitter, not Freescale board specific, is it? diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile index 22b57cc..808ddd0 100644 --- a/board/freescale/common/Makefile +++ b/board/freescale/common/Makefile @@ -34,6 +34,8 @@ ifndef CONFIG_RAMBOOT_PBL obj-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o endif +obj-$(CONFIG_FSL_DCU_SII9022A)+= dcu_sii9022a.o + obj-$(CONFIG_MPC8541CDS) += cds_pci_ft.o obj-$(CONFIG_MPC8548CDS) += cds_pci_ft.o obj-$(CONFIG_MPC8555CDS) += cds_pci_ft.o diff --git a/board/freescale/common/dcu_sii9022a.c b/board/freescale/common/dcu_sii9022a.c new file mode 100644 index 000..2da627e --- /dev/null +++ b/board/freescale/common/dcu_sii9022a.c @@ -0,0 +1,153 @@ +/* + * Copyright 2014 Freescale Semiconductor, Inc. + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include asm/io.h +#include common.h +#include fsl_dcu_fb.h I think you put the patches in wrong order. DCU driver has not been added before this patch. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 15/18] arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board
On 08/13/2014 11:45 PM, Alison Wang wrote: From: Wang Huan b18...@freescale.com This patch is to add LETECH support for LS1021AQDS/TWR board. For LETECH, lpuart is used as console. Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: Yuan Yao yao.y...@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: No change. v3: New file. board/freescale/ls1021aqds/MAINTAINERS | 1 + board/freescale/ls1021atwr/MAINTAINERS | 1 + configs/ls1021aqds_letech_defconfig| 3 +++ configs/ls1021atwr_letech_defconfig| 3 +++ include/configs/ls1021aqds.h | 13 + include/configs/ls1021atwr.h | 12 6 files changed, 33 insertions(+) create mode 100644 configs/ls1021aqds_letech_defconfig create mode 100644 configs/ls1021atwr_letech_defconfig I suggest you update README to add some information about this LETECH. I have no idea what it is until I dig into some internal documents. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver
On 14 Aug 2014, ste...@agner.ch wrote:
This adds initial support for Freescale NFC (NAND Flash Controller)
found in ARM Vybrid SoC's, Power Architecture MPC5125 and others.
However, this driver is only tested on Vybrid.
Signed-off-by: Stefan Agner ste...@agner.ch
---
drivers/mtd/nand/Makefile| 1 +
drivers/mtd/nand/vf610_nfc.c | 706
++ +
2 files changed, 707 insertions(+)
create mode 100644 drivers/mtd/nand/vf610_nfc.c
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..3150ac1
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,706 @@
+/*
+ * Copyright 2009-2014 Freescale Semiconductor, Inc. and others
+ *
[snip]
+/* Count the number of 0's in buff upto max_bits */
+static inline int count_written_bits(uint8_t *buff, int size, int max_bits)
+{
+ uint32_t *buff32 = (uint32_t *)buff;
+ int k, written_bits = 0;
+
+ for (k = 0; k (size / 4); k++) {
+ written_bits += hweight32(~buff32[k]);
+ if (written_bits max_bits)
+ break;
+ }
+
+ return written_bits;
+}
That is a nice change.
+static inline int vf610_nfc_correct_data(struct mtd_info *mtd, u_char *dat)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+ u8 ecc_status;
+ u8 ecc_count;
+ int flip;
+
+ ecc_status = __raw_readb(nfc-regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
+ ecc_count = ecc_status ECC_ERR_COUNT;
+ if (!(ecc_status ECC_STATUS_MASK))
+ return ecc_count;
+
+ /* If 'ecc_count' zero or less then buffer is all 0xff or erased. */
+ flip = count_written_bits(dat, nfc-chip.ecc.size, ecc_count);
+
+ /* ECC failed. */
+ if (flip ecc_count)
+ return -1;
Sorry, I missed this in version one of the patch. The original had,
if (flip ecc_count) {
nfc-page = -1;
---
if (flip ecc_count)
522d508
}
I can see why you removed this (nfc-page = -1). However, I think that
higher layers may want to re-read on an error in case of un-stable bits?
It is very little code to ensure a re-read in case of ECC failure. The
2nd physical read may pass whereas the first failed. This path is rare,
but maybe important? A higher layer may migrate the data in this case;
just as with a corrected bits. But maybe U-Boot will never do this?
+
+ /* Erased page. */
+ memset(dat, 0xff, nfc-chip.ecc.size);
+ return 0;
+}
Regards,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/14/2014 02:25 AM, Alexander Holler wrote: Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. The check for if uenvcmd is set then run uenvcmd syntax, should really be pushed into the distro default stuff. As that syntax is used by default for a lot of different targets in u-boot. Most users who deal with u-boot (even if they don't want to) seem to understand it. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] cmd_bootm.c: Add 'booti' for ARM64 Linux kernel Images
On Thu, Aug 14, 2014 at 04:16:50PM +0100, Mark Rutland wrote:
Hi Tom,
On Thu, Aug 14, 2014 at 11:42:36AM +0100, Tom Rini wrote:
The default format for arm64 Linux kernels is the Image format,
described in Documentation/arm64/booting.txt. This, along with an
optional gzip compression on top is all that is generated by default.
The Image format has a magic number within the header for verification,
a text_offset where the Image must be run from, an image_size that
includes the BSS and reserved fields.
This does not support automatic detection of a gzip compressed image.
Signed-off-by: Tom Rini tr...@ti.com
---
Changes in v1:
- Adopt to Mark Rutland's changes now in mainline kernel wrt text_offset
/ image_size
---
README |1 +
common/cmd_bootm.c | 140
include/bootm.h|2 +-
3 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/README b/README
index 1d71359..b9af7ac 100644
--- a/README
+++ b/README
@@ -959,6 +959,7 @@ The following options need to be configured:
CONFIG_CMD_BMP * BMP support
CONFIG_CMD_BSP * Board specific commands
CONFIG_CMD_BOOTD bootd
+ CONFIG_CMD_BOOTI* ARM64 Linux kernel Image support
CONFIG_CMD_CACHE* icache, dcache
CONFIG_CMD_CLK * clock command support
CONFIG_CMD_CONSOLEconinfo
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8b897c8d..843ec6e 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -627,3 +627,143 @@ U_BOOT_CMD(
boot Linux zImage image from memory, bootz_help_text
);
#endif /* CONFIG_CMD_BOOTZ */
+
+#ifdef CONFIG_CMD_BOOTI
+/* See Documentation/arm64/booting.txt in the Linux kernel */
+struct Image_header {
+ uint32_tcode0; /* Executable code */
+ uint32_tcode1; /* Executable code */
+ uint64_ttext_offset;/* Image load offset, LE */
+ uint64_timage_size; /* Effective Image size, LE */
+ uint64_tres1; /* reserved */
+ uint64_tres2; /* reserved */
+ uint64_tres3; /* reserved */
+ uint64_tres4; /* reserved */
+ uint32_tmagic; /* Magic number */
+ uint32_tres5;
+};
+
+#define LINUX_ARM64_IMAGE_MAGIC0x644d5241
+
+static int booti_setup(bootm_headers_t *images)
+{
+ struct Image_header *ih;
+ uint64_t dst;
+
+ ih = (struct Image_header *)map_sysmem(images-ep, 0);
+
+ if (ih-magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
+ puts(Bad Linux ARM64 Image magic!\n);
+ return 1;
+ }
+
+ if (ih-image_size == 0) {
+ puts(Image lacks image_size field, assuming 16MiB\n);
+ ih-image_size = (16 20);
+ }
This should work for a defconfig, but it might be possible to build a
larger kernel. From experiments with an allyesconfig, I can build a
~60MB kernel with ~20MB of uninitialised data after the end of the
Image.
Part of me just wants to error out in this case. Today people are
wrapping vmlinux up with a legacy header and making uImages. My hope is
that with this and 3.17 we can encourage Image/Image.*/FIT Image usage
instead. We could just as easily whack in 128MB, all the same.
Modifying the Image feels a little dodgy, but I can't think of anything
this would break.
Yeah. In my mind, an Image without this information is the corner case,
not the normal case. Doing it this way (a fixup to the data) means we
don't have to error check this twice or play some other games.
+ /*
+* If we are not at the correct run-time location, set the new
+* correct location and then move the image there.
+*/
+ dst = gd-bd-bi_dram[0].start + le32_to_cpu(ih-text_offset);
This should be le64_to_cpu(ih-text_offset) to be strictly correct.
I wouldn't imagine we'd ever have a text_offset larger than 4GB, but it
would be nice to keep things consistent with the documentation and
kernel code.
Oh that's right, sixty-four bits is what we have...
+#ifdef CONFIG_SYS_LONGHELP
+static char booti_help_text[] =
+ [addr [initrd[:size]] [fdt]]\n
+ - boot Linux Image stored in memory\n
+ \tThe argument 'initrd' is optional and specifies the address\n
+ \tof the initrd in memory. The optional argument ':size' allows\n
+ \tspecifying the size of RAW initrd.\n
+#if defined(CONFIG_OF_LIBFDT)
+ \tSince booting a Linux kernelrequires a flat device-tree\n
Nit: space between kernel and requires
Thanks.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On Thu, Aug 14, 2014 at 01:41:16PM -0500, Robert Nelson wrote: On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/14/2014 02:25 AM, Alexander Holler wrote: Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. The check for if uenvcmd is set then run uenvcmd syntax, should really be pushed into the distro default stuff. As that syntax is used by default for a lot of different targets in u-boot. Most users who deal with u-boot (even if they don't want to) seem to understand it. Right. The intention was to provide a just do what I want you to do hook to the end user. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). And as it now seems to be possible to write the environment back to disk too, one should be make sure that uenvcmd will be cleared before writing the environment back to disk. Personally I prefer to not let the bootloader write to any (real) filesystem, but just in case someone does so ... Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver
On Thu, 2014-08-14 at 18:30 +0200, Stefan Agner wrote: +#define DRV_NAMEfsl_nfc DRV_NAME doesn't match filename (neither does the patch title), and it doesn't seem all that useful anyway -- the one place that uses it would be better off using __func__. +static int vf610_nfc_nand_init(int devnum, u8 *addr) Why u8? Either use void or u32. Also should have __iomem. ...OK, I see you copied that from the examples I pointed out. I have no idea why those use u8 either. :-( + chip-IO_ADDR_R = chip-IO_ADDR_W = nfc-regs = (void __iomem *)addr; Don't set IO_ADDR_R/IO_ADDR_W if they're not going to be used. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On 08/14/2014 12:41 PM, Robert Nelson wrote: On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/14/2014 02:25 AM, Alexander Holler wrote: Am 31.07.2014 21:57, schrieb Stephen Warren: Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise. As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. The check for if uenvcmd is set then run uenvcmd syntax, should really be pushed into the distro default stuff. As that syntax is used by default for a lot of different targets in u-boot. Most users who deal with u-boot (even if they don't want to) seem to understand it. I don't think this is anything to do with distro defaults. Distro defaults are intended to provide a single common interface between the bootloader and Linux/... distro. As such, locating and loading extlinux.conf fits the bill there. The whole idea is that distros/OSs wouldn't have to know anything about the bootloader at all; command script formats, etc. uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since saveenv to flash works there. So, perhaps I could see providing include/common_bootenv.h to make the definition you wrote above common between boards, but I certainly would not expect that opting in to distro defaults automatically added support for uEnv.txt. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On 08/14/2014 01:38 PM, Alexander Holler wrote: Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). For such presumably non-standard things, why can't the user simply edit $bootcmd, and pre-pend whatever they want? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 21:51, schrieb Stephen Warren: On 08/14/2014 01:38 PM, Alexander Holler wrote: Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). For such presumably non-standard things, why can't the user simply edit $bootcmd, and pre-pend whatever they want? Depends on when the bootcmd will be constructed. Usually that is done after having read uEnv.txt to include variables defined in uEnv.txt in bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be overwritten. Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On 08/14/2014 01:59 PM, Alexander Holler wrote: Am 14.08.2014 21:51, schrieb Stephen Warren: On 08/14/2014 01:38 PM, Alexander Holler wrote: Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). For such presumably non-standard things, why can't the user simply edit $bootcmd, and pre-pend whatever they want? Depends on when the bootcmd will be constructed. Usually that is done after having read uEnv.txt to include variables defined in uEnv.txt in bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be overwritten. What would over-write bootcmd? None of the boards I've looked at auto-generates bootcmd. bootargs perhaps (which is a string passed to the kernel) but not bootargs (which is a U-Boot command sequence that U-Boot executes automatically at boot). If some board does auto-generate bootcmd, I'd suggest that it not. The static bootcmd could execute some kind of user-(or uenv-)set variable and/or the auto-generation of bootcmd could happen before uenv.txt was pulled in, so that whatever was in uenv.txt would have ultimate power. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Magically determining the correct root
Hello,
Over the years I've seen many error message from beginners because root=
wasn't set or was set wrong. Often they call the cryptic message from
the Linux kernel memory error or something similiar (because they just
look at the stuff after the init not found).
One of the reason they run into that is because they use a different
partition layout than which is enforced by the board-config.
So here are my 2¢ to give people some more freedom in regard to the
partition layout:
-
...
find_root= \
setenv stdout nulldev; \
for i in 0 1 2; do \
setexpr rootpart $part + $i; \
if ls $hw $dev:$rootpart dev; then \
setenv stderr serial; \
setenv stdout serial; \
exit; \
fi; \
done; \
setenv stdout serial; \
setenv rootpart\0 \
linuxmmc=mmcblk0p\0 \
set_root= \
run find_root; \
if test -z \$rootpart\; then \
echo \NO ROOT FOUND! (no partition with
directory /dev)\; \
setexpr rootpart $part + 1; \
fi; \
if test $hw = mmc; then \
setenv root /dev/${linuxmmc}${rootpart}; \
else \
setenv root /dev/sda${rootpart}; \
fi; \
echo \root is $root\\0 \
...
-
What it does is the following:
It uses the variable $hw, $dev, $part and $linuxmmc as input and
$root as output.
- $hw might be mmc, usb or sata (or whatever ls does understand
- $dev is the device number (usually 0)
- $part is the partition number where the kernel is loaded from (most of
the time 1 for the first partition)
- $linuxmmc is the linux-name of the mmc-device (e.g. mmcblk0p).
It then searches the partition from which the kernel was loaded from and
the following two partitions for a /dev and assumes that will be the
correct root partition.
So, assuming /dev does only exist on the root partition that little
magic supports parition layouts like the following:
- boot (with kernel), root, something else
- root (with kernel), something else
- swap, boot (with kernel), root, something else
- boot (with kernel), swap, root, something else
...
Maybe someone does find usefull.
Regards,
Alexander Holler
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 22:08, schrieb Stephen Warren: On 08/14/2014 01:59 PM, Alexander Holler wrote: Am 14.08.2014 21:51, schrieb Stephen Warren: On 08/14/2014 01:38 PM, Alexander Holler wrote: Am 14.08.2014 17:49, schrieb Stephen Warren: On 08/14/2014 02:25 AM, Alexander Holler wrote: As I've just remembered where I did see your name before, the config for the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to execute commands when using uEnv.txt. It's easily done with something like the following: env import -t -r $loadaddr $filesize; \ if test -n \$uenvcmd\; then \ echo \Running uenvcmd ...\; \ run uenvcmd; \ fi; \ My intention was that uEnv.txt be used to set up environment variables, not to allow its use for custom scripts. Sure. In most cases changing the predefined available variables is enough. But it's a very hand option if someone wants or needs to do stuff which can't be done by just changing some environment variables (one never knows what ideas people will have). For such presumably non-standard things, why can't the user simply edit $bootcmd, and pre-pend whatever they want? Depends on when the bootcmd will be constructed. Usually that is done after having read uEnv.txt to include variables defined in uEnv.txt in bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be overwritten. What would over-write bootcmd? None of the boards I've looked at auto-generates bootcmd. bootargs perhaps (which is a string passed to the kernel) but not bootargs (which is a U-Boot command sequence that U-Boot executes automatically at boot). If some board does auto-generate bootcmd, I'd suggest that it not. The static bootcmd could execute some kind of user-(or uenv-)set variable and/or the auto-generation of bootcmd could happen before uenv.txt was pulled in, so that whatever was in uenv.txt would have ultimate power. Ah, yes. Sorry, I confused bootcmd with bootargs (I don't live in u-boot and just fiddle once a year or such with it). But overwriting bootcmd needs to read uEnv.txt in PREBOOT (or how it is named). I originally have read uEnv.txt in the bootcmd itself, so overwriting it didn't work. But I don't want to dive too deep into that discussion, as I think it's up to the board-maintainers to write the config however they want and seem to fit for there users. I've just mentioned the uenvcmd, because it was the first, I've added to my u-boot for the rpi (to have the same interface I use with my other boards). ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote: [snip] uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since saveenv to flash works there. Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the environment (fw_setenv/printenv should be adaptable easily enough I would hope, but aren't today). uEnv.txt is the way for a user to pop the SD card into their PC, tweak the env as needed (or fiddle some bits), eject the card and boot their target. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 22:53, schrieb Tom Rini: On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote: [snip] uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since saveenv to flash works there. Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the environment (fw_setenv/printenv should be adaptable easily enough I would hope, but aren't today). uEnv.txt is the way for a user to pop the SD card into their PC, tweak the env as needed (or fiddle some bits), eject the card and boot their target. Yes, many developers today (those which do buy development boards) are having problems to use a serial which most of the time is needed to access the u-boot command line. The reasons are various, most devices people do use don't have a serial anymore, the voltage of the serial changes every few years (12, 5, 3.3 and now 1.8 Volt), sometimes a nullmodem (just 3 wires) is needed, ... Whatever the reason is, sometimes it can be very hard to access the u-boot command line. But most are able to modifying or create a file on disk. ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] vf610twr: Tune DDR initialization settings
Am 2014-07-22 00:42, schrieb Stefan Agner: Am 2014-05-14 23:29, schrieb Anthony Felice: Removed settings in unsupported register fields. They didn’t do anything, and in most cases, were not documented in the reference manual. Changed register settings to comply with JEDEC required values. Changed timing parameters because they included full clock periods that were doing nothing. Signed-off-by: Anthony Felice tony.fel...@timesys.com --- arch/arm/include/asm/arch-vf610/imx-regs.h| 50 +++--- arch/arm/include/asm/arch-vf610/iomux-vf610.h | 44 +++-- arch/arm/include/asm/imx-common/iomux-v3.h| 2 + board/freescale/vf610twr/vf610twr.c | 93 +-- 4 files changed, 128 insertions(+), 61 deletions(-) diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h b/arch/arm/include/asm/arch-vf610/imx-regs.h index c2f9761..a11b419 100644 --- a/arch/arm/include/asm/arch-vf610/imx-regs.h +++ b/arch/arm/include/asm/arch-vf610/imx-regs.h @@ -100,9 +100,11 @@ /* DDRMC */ #define DDRMC_PHY_DQ_TIMING 0x2613 #define DDRMC_PHY_DQS_TIMING0x2615 -#define DDRMC_PHY_CTRL 0x01210080 +#define DDRMC_PHY_CTRL 0x0021 #define DDRMC_PHY_MASTER_CTRL 0x0001012a -#define DDRMC_PHY_SLAVE_CTRL0x00012020 +#define DDRMC_PHY_SLAVE_CTRL0x2000 +#define DDRMC_PHY_OFF 0x +#define DDRMC_PHY_PROC_PAD_ODT 0x00010101 #define DDRMC_PHY50_DDR3_MODE (1 12) #define DDRMC_PHY50_EN_SW_HALF_CYCLE(1 8) @@ -135,7 +137,7 @@ #define DDRMC_CR21_CCMAP_EN 1 #define DDRMC_CR22_TDAL(v) (((v) 0x3f) 16) #define DDRMC_CR23_BSTLEN(v)(((v) 0x7) 24) -#define DDRMC_CR23_TDLL(v) ((v) 0xff) +#define DDRMC_CR23_TDLL(v) ((v) 0x) #define DDRMC_CR24_TRP_AB(v)((v) 0x1f) #define DDRMC_CR25_TREF_EN (1 16) #define DDRMC_CR26_TREF(v) (((v) 0x) 16) @@ -148,7 +150,7 @@ #define DDRMC_CR33_EN_QK_SREF (1 16) #define DDRMC_CR34_CKSRX(v) (((v) 0xf) 16) #define DDRMC_CR34_CKSRE(v) (((v) 0xf) 8) -#define DDRMC_CR38_FREQ_CHG_EN (1 8) +#define DDRMC_CR38_FREQ_CHG_EN(v) (((v) 0x1) 8) #define DDRMC_CR39_PHY_INI_COM(v) (((v) 0x) 16) #define DDRMC_CR39_PHY_INI_STA(v) (((v) 0xff) 8) #define DDRMC_CR39_FRQ_CH_DLLOFF(v) ((v) 0x3) @@ -160,7 +162,7 @@ #define DDRMC_CR67_ZQCS(v) ((v) 0xfff) #define DDRMC_CR69_ZQ_ON_SREF_EX(v) (((v) 0xf) 8) #define DDRMC_CR70_REF_PER_ZQ(v)(v) -#define DDRMC_CR72_ZQCS_ROTATE (1 24) +#define DDRMC_CR72_ZQCS_ROTATE(v) (((v) 0x1) 24) #define DDRMC_CR73_APREBIT(v) (((v) 0xf) 24) #define DDRMC_CR73_COL_DIFF(v) (((v) 0x7) 16) #define DDRMC_CR73_ROW_DIFF(v) (((v) 0x3) 8) @@ -179,9 +181,10 @@ #define DDRMC_CR77_CS_MAP (1 24) #define DDRMC_CR77_DI_RD_INTLEAVE (1 8) #define DDRMC_CR77_SWAP_EN 1 +#define DDRMC_CR78_Q_FULLNESS(v)(((v) 0x7) 24) #define DDRMC_CR78_BUR_ON_FLY_BIT(v)((v) 0xf) -#define DDRMC_CR79_CTLUPD_AREF (1 24) -#define DDRMC_CR82_INT_MASK 0x1fff +#define DDRMC_CR79_CTLUPD_AREF(v) (((v) 0x1) 24) +#define DDRMC_CR82_INT_MASK 0x1000 #define DDRMC_CR87_ODT_WR_MAPCS0(1 24) #define DDRMC_CR87_ODT_RD_MAPCS0(1 16) #define DDRMC_CR88_TODTL_CMD(v) (((v) 0x1f) 16) @@ -189,9 +192,17 @@ #define DDRMC_CR91_R2W_SMCSDL(v)(((v) 0x7) 16) #define DDRMC_CR96_WLMRD(v) (((v) 0x3f) 8) #define DDRMC_CR96_WLDQSEN(v) ((v) 0x3f) +#define DDRMC_CR97_WRLVL_EN (1 24) +#define DDRMC_CR98_WRLVL_DL_0 (0) +#define DDRMC_CR99_WRLVL_DL_1 (0) +#define DDRMC_CR102_RDLVL_GT_REGEN (1 16) +#define DDRMC_CR102_RDLVL_REG_EN(1 8) #define
Re: [U-Boot] [PATCH v2 3/4] mtd: nand: add Freescale NFC driver
On 14 Aug 2014, ste...@agner.ch wrote:
This adds initial support for Freescale NFC (NAND Flash Controller)
found in ARM Vybrid SoC's, Power Architecture MPC5125 and others.
However, this driver is only tested on Vybrid.
This is only to expand on the nand controller register and SRAM use.
[snip]
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..3150ac1
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
[snip]
+static inline u32 vf610_nfc_read(struct mtd_info *mtd, uint reg)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+
+ return readl(nfc-regs + reg);
+}
+
+static inline void vf610_nfc_write(struct mtd_info *mtd, uint reg, u32 val)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+
+ writel(val, nfc-regs + reg);
+}
Ok, we always use readl/writel. This is fine, but a little slower and
bigger. I may try a register cache if I resubmit to the Linux MTD as
per Scott's suggestion. Especially, this version is good for an
incremental patch.
I think these are in 'arch/arm/include/asm/io.h' of U-Boot.
#define dmb() __asm__ __volatile__ ( : : : memory)
#define __iormb() dmb()
#define __iowmb() dmb()
#define readl(c)({ u32 __v = __arch_getl(c); __iormb(); __v; })
#define writel(v,c) ({ u32 __v = v; __iowmb(); __arch_putl(__v,c); __v; })
Currently, these look like compiler barriers to me. Fine so far.
+
+static inline void vf610_nfc_set(struct mtd_info *mtd, uint reg, u32 bits)
+{
+ vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) | bits);
+}
+
+static inline void vf610_nfc_clear(struct mtd_info *mtd, uint reg, u32 bits)
+{
+ vf610_nfc_write(mtd, reg, vf610_nfc_read(mtd, reg) ~bits);
+}
+
+static inline void vf610_nfc_set_field(struct mtd_info *mtd, u32 reg,
+u32 mask, u32 shift, u32 val)
+{
+ vf610_nfc_write(mtd, reg,
+ (vf610_nfc_read(mtd, reg) (~mask)) | val shift);
+}
+
+/* Clear flags for upcoming command */
+static inline void vf610_nfc_clear_status(struct mtd_info *mtd)
+{
+ u32 tmp = vf610_nfc_read(mtd, NFC_IRQ_STATUS);
+ tmp |= CMD_DONE_CLEAR_BIT | IDLE_CLEAR_BIT;
+ vf610_nfc_write(mtd, NFC_IRQ_STATUS, tmp);
+}
+
+/* Wait for complete operation */
+static inline void vf610_nfc_done(struct mtd_info *mtd)
+{
+ uint start;
+
+ vf610_nfc_set(mtd, NFC_FLASH_CMD2, START_BIT);
+ barrier();
This barrier() is not needed then. The vf610_nfc_set() should have
done it twice already, plus everything is volatile.
[snip]
+static inline void vf610_nfc_read_spare(struct mtd_info *mtd, void *buf,
+ int len)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+
+ len = min(mtd-oobsize, (uint)len);
+ if (len 0)
+ memcpy(buf, nfc-regs + mtd-writesize, len);
Notice the 'memcpy(.. nfc-regs);'...
+}
+
+/* Read data from NFC buffers */
+static void vf610_nfc_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+ uint c = nfc-column;
+ uint l;
+
+ /* Handle main area */
+ if (!nfc-spareonly) {
+
+ l = min((uint)len, mtd-writesize - c);
+ nfc-column += l;
+
+ if (!nfc-alt_buf)
+ memcpy(buf, nfc-regs + NFC_MAIN_AREA(0) + c, l);
Another 'memcpy(.. nfc-regs);'...
+ else
+ if (nfc-alt_buf ALT_BUF_ID)
+ *buf = vf610_nfc_get_id(mtd, c);
+ else
+ *buf = vf610_nfc_get_status(mtd);
+
+ buf += l;
+ len -= l;
+ }
+
+ /* Handle spare area access */
+ if (len) {
+ nfc-column += len;
+ vf610_nfc_read_spare(mtd, buf, len);
+ }
+}
+
+/* Write data to NFC buffers */
+static void vf610_nfc_write_buf(struct mtd_info *mtd, const u_char *buf,
+ int len)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+ uint c = nfc-column;
+ uint l;
+
+ l = min((uint)len, mtd-writesize + mtd-oobsize - c);
+ nfc-column += l;
+ memcpy(nfc-regs + NFC_MAIN_AREA(0) + c, buf, l);
Another 'memcpy(.. nfc-regs);'...
[snip]
These memcpy's are the same 'bus' interface as the registers. We should
be just as worried about this SRAM buffer memory as the memory mapped
registers, shouldn't we? Is a barrier() before reading and a barrier()
after writing fine for U-Boot? Personally, I think they are safe as
only the 'vf610_nfc_set(mtd, NFC_FLASH_CMD2, START_BIT)' needs some
care. Maybe a comment is fine? It seems the Vybrid is safe for
different access sizes, but it is possible that some other CPU might not
be able to access this memory via 32/16/8 bit accesses and 'memcpy()'
may not be appropriate. It seems that 'natural' size of the NFC
controller itself
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
On 08/14/2014 02:53 PM, Tom Rini wrote: On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote: [snip] uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since saveenv to flash works there. Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the environment (fw_setenv/printenv should be adaptable easily enough I would hope, but aren't today). uEnv.txt is the way for a user to pop the SD card into their PC, tweak the env as needed (or fiddle some bits), eject the card and boot their target. What, you don't link binary-editing the file to fix the CRC? :-P ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to read the buildman report
Simon, I need some help to understand the report of buildman. Use this example, when I build all arm and powerpc boards, $ tools/buildman/buildman -b working_qoriq arm powerpc -s Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvision 02: video: dcu: Add DCU driver support 03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm:vf610twr 07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letech 09: driver/ddr/fsl: Add support of overriding chip select write leveling arm: + ls1021aqds_nor ls1021aqds_letech 10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available First, is the build supposed to be top down or bottom up? It looks like buildman starts to build from the last commit and works it way down. What I don't understand is the new board. Under patch 08 and 09, I see two boards failed. But these two boards don't exist until a later commit. Should I use --force-reconfig switch? Second, when I see a failed board under a commit, is this commit causing the failure? It is not the case in my example. I see vf610twr failed under 01, but the actual failure is caused by commit 05. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings
Am 14.08.2014 23:35, schrieb Stephen Warren: On 08/14/2014 02:53 PM, Tom Rini wrote: On Thu, Aug 14, 2014 at 01:50:31PM -0600, Stephen Warren wrote: [snip] uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since saveenv to flash works there. Even with ENV_IS_IN_FAT you need to be in U-Boot to modify the environment (fw_setenv/printenv should be adaptable easily enough I would hope, but aren't today). uEnv.txt is the way for a user to pop the SD card into their PC, tweak the env as needed (or fiddle some bits), eject the card and boot their target. What, you don't link binary-editing the file to fix the CRC? :-P That reminds me that I thought about adding uEnv.sha1 (and CMD_SHA1) to have the same protection (or even better through sha1) as boot.cmd for environments where it makes sense. So in regard to untrustworthy sd-cards most boards. ;) Regards, Alexander Holler ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to read the buildman report
Hi York, On 14 August 2014 15:36, York Sun york...@freescale.com wrote: Simon, I need some help to understand the report of buildman. Use this example, when I build all arm and powerpc boards, I assume you've checked out the README. $ tools/buildman/buildman -b working_qoriq arm powerpc -s Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvision This means that in commit 01 these boards fail to build. 02: video: dcu: Add DCU driver support 03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm:vf610twr This board got fixed by this commit. 07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letech This commit causes these board to fail, in addition to the previous ones. 09: driver/ddr/fsl: Add support of overriding chip select write leveling arm: + ls1021aqds_nor ls1021aqds_letech 10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available First, is the build supposed to be top down or bottom up? It looks like buildman starts to build from the last commit and works it way down. What I don't understand is the new board. Under patch 08 and 09, I see two boards failed. But these two boards don't exist until a later commit. Should I use --force-reconfig switch? It builds from the oldest commit to the newest, and shows in that order. buildman does not understand boards that are created during a series. This is a limitation. So you will get failures for commits that don't have the board. Second, when I see a failed board under a commit, is this commit causing the failure? It is not the case in my example. I see vf610twr failed under 01, but the actual failure is caused by commit 05. It seems that there is a problem for commit 01 also - perhaps just a warning? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 15/15] dm: tegra: Enable driver model for serial
Hi Stephen, On 11 August 2014 09:27, Simon Glass s...@chromium.org wrote: Use driver model for serial ports (for test and comment only). dm: tegra: Use V_NS16550_CLK only in SPL builds Since Tegra now uses driver model for serial, adjust the definition of V_NS16550_CLK so that it is clear that this is only used for SPL. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Add a separate Tegra serial driver to deal with the clock issue - Add new CONFIG_TEGRA_SERIAL option to enable dm driver - Use hard-coded UART clock from Tegra configuration Just checking in to see if this patch looks good? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to read the buildman report
On 08/14/2014 03:17 PM, Simon Glass wrote: Hi York, On 14 August 2014 15:36, York Sun york...@freescale.com mailto:york...@freescale.com wrote: Simon, I need some help to understand the report of buildman. Use this example, when I build all arm and powerpc boards, I assume you've checked out the README. Yes, but not the latest one merged. $ tools/buildman/buildman -b working_qoriq arm powerpc -s Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvision This means that in commit 01 these boards fail to build. 02: video: dcu: Add DCU driver support 03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm:vf610twr This board got fixed by this commit. 07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letech This commit causes these board to fail, in addition to the previous ones. 09: driver/ddr/fsl: Add support of overriding chip select write leveling arm: + ls1021aqds_nor ls1021aqds_letech 10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available First, is the build supposed to be top down or bottom up? It looks like buildman starts to build from the last commit and works it way down. What I don't understand is the new board. Under patch 08 and 09, I see two boards failed. But these two boards don't exist until a later commit. Should I use --force-reconfig switch? It builds from the oldest commit to the newest, and shows in that order. Doesn't looks so. The 19 is the oldest. The 18 is the first commit I am testing. The 01 is the newest. buildman does not understand boards that are created during a series. This is a limitation. So you will get failures for commits that don't have the board. That explains it. Second, when I see a failed board under a commit, is this commit causing the failure? It is not the case in my example. I see vf610twr failed under 01, but the actual failure is caused by commit 05. It seems that there is a problem for commit 01 also - perhaps just a warning? I think the build order is backward now. Before the latest merge, it did build from the oldest to the newest. I confirmed that by checking out v2014.10-rc1. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] how to read the buildman report
Hi York, On 14 August 2014 16:33, York Sun york...@freescale.com wrote: On 08/14/2014 03:17 PM, Simon Glass wrote: Hi York, On 14 August 2014 15:36, York Sun york...@freescale.com mailto:york...@freescale.com wrote: Simon, I need some help to understand the report of buildman. Use this example, when I build all arm and powerpc boards, I assume you've checked out the README. Yes, but not the latest one merged. $ tools/buildman/buildman -b working_qoriq arm powerpc -s Summary of 19 commits for 1023 boards (24 threads, 1 job per thread) 01: ls102xa: dcu: Add platform support for DCU on LS1021ATWR board arm: + tricorder_flash vf610twr tricorder powerpc: + taishan dlvision This means that in commit 01 these boards fail to build. 02: video: dcu: Add DCU driver support 03: video: dcu: Add Sii9022A HDMI Transmitter support 04: arm: ls102xa: Add LETECH support for LS1021AQDS/TWR board 05: serial: lpuart: add 32-bit registers lpuart support 06: net: tsec: Remove tx snooping support from LS1 arm:vf610twr This board got fixed by this commit. 07: arm: ls102xa: Add basic support for LS1021ATWR board 08: arm: ls102xa: Add basic support for LS1021AQDS board arm: + ls1021atwr_nor ls1021atwr_letech This commit causes these board to fail, in addition to the previous ones. 09: driver/ddr/fsl: Add support of overriding chip select write leveling arm: + ls1021aqds_nor ls1021aqds_letech 10: driver/ddr/freescale: Fix DDR3 driver for ARM 11: driver/ddr/freescale: Add support of accumulate ECC 12: ls102xa: esdhc: Add esdhc support for LS102xA 13: ls102xa: etsec: Add etsec support for LS102xA 14: net: mdio: Use mb() to be compatible for both ARM and PowerPC 15: net: mdio: Add private MDIO read/write function 16: net: Merge asm/fsl_enet.h into fsl_mdio.h 17: ls102xa: i2c: Add i2c support for LS102xA 18: arm: ls102xa: Add Freescale LS102xA SoC support 19: patman: Only use git's --no-decorate when available First, is the build supposed to be top down or bottom up? It looks like buildman starts to build from the last commit and works it way down. What I don't understand is the new board. Under patch 08 and 09, I see two boards failed. But these two boards don't exist until a later commit. Should I use --force-reconfig switch? It builds from the oldest commit to the newest, and shows in that order. Doesn't looks so. The 19 is the oldest. The 18 is the first commit I am testing. The 01 is the newest. Well you have found a bug! buildman does not understand boards that are created during a series. This is a limitation. So you will get failures for commits that don't have the board. That explains it. Second, when I see a failed board under a commit, is this commit causing the failure? It is not the case in my example. I see vf610twr failed under 01, but the actual failure is caused by commit 05. It seems that there is a problem for commit 01 also - perhaps just a warning? I think the build order is backward now. Before the latest merge, it did build from the oldest to the newest. I confirmed that by checking out v2014.10-rc1. Ah, yes I changed something during the 'git log' refactoring. I'll submit a fix as that would be very confusing. Thanks for testing this. I should have left those last two patches out until I heard from you. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 2/5] patman: Fix indentation in terminal.py
This code came from a different project with 2-character indentation. Fix it for U-Boot. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v7: None Changes in v6: - Add new patch to fix indentation in teminal.py Changes in v5: None tools/patman/terminal.py | 108 --- 1 file changed, 55 insertions(+), 53 deletions(-) diff --git a/tools/patman/terminal.py b/tools/patman/terminal.py index 597d526..11f80d8 100644 --- a/tools/patman/terminal.py +++ b/tools/patman/terminal.py @@ -15,66 +15,68 @@ import sys COLOR_IF_TERMINAL, COLOR_ALWAYS, COLOR_NEVER = range(3) class Color(object): - Conditionally wraps text in ANSI color escape sequences. - BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, WHITE = range(8) - BOLD = -1 - BRIGHT_START = '\033[1;%dm' - NORMAL_START = '\033[22;%dm' - BOLD_START = '\033[1m' - RESET = '\033[0m' +Conditionally wraps text in ANSI color escape sequences. +BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, WHITE = range(8) +BOLD = -1 +BRIGHT_START = '\033[1;%dm' +NORMAL_START = '\033[22;%dm' +BOLD_START = '\033[1m' +RESET = '\033[0m' - def __init__(self, colored=COLOR_IF_TERMINAL): -Create a new Color object, optionally disabling color output. +def __init__(self, colored=COLOR_IF_TERMINAL): +Create a new Color object, optionally disabling color output. -Args: - enabled: True if color output should be enabled. If False then this -class will not add color codes at all. - -self._enabled = (colored == COLOR_ALWAYS or -(colored == COLOR_IF_TERMINAL and os.isatty(sys.stdout.fileno( +Args: + enabled: True if color output should be enabled. If False then this +class will not add color codes at all. + +self._enabled = (colored == COLOR_ALWAYS or +(colored == COLOR_IF_TERMINAL and os.isatty(sys.stdout.fileno( - def Start(self, color, bright=True): -Returns a start color code. +def Start(self, color, bright=True): +Returns a start color code. -Args: - color: Color to use, .e.g BLACK, RED, etc. +Args: + color: Color to use, .e.g BLACK, RED, etc. -Returns: - If color is enabled, returns an ANSI sequence to start the given color, - otherwise returns empty string - -if self._enabled: -base = self.BRIGHT_START if bright else self.NORMAL_START -return base % (color + 30) -return '' +Returns: + If color is enabled, returns an ANSI sequence to start the given + color, otherwise returns empty string + +if self._enabled: +base = self.BRIGHT_START if bright else self.NORMAL_START +return base % (color + 30) +return '' - def Stop(self): -Retruns a stop color code. +def Stop(self): +Retruns a stop color code. -Returns: - If color is enabled, returns an ANSI color reset sequence, otherwise - returns empty string - -if self._enabled: -return self.RESET -return '' +Returns: + If color is enabled, returns an ANSI color reset sequence, + otherwise returns empty string + +if self._enabled: +return self.RESET +return '' - def Color(self, color, text, bright=True): -Returns text with conditionally added color escape sequences. +def Color(self, color, text, bright=True): +Returns text with conditionally added color escape sequences. -Keyword arguments: - color: Text color -- one of the color constants defined in this class. - text: The text to color. +Keyword arguments: + color: Text color -- one of the color constants defined in this + class. + text: The text to color. -Returns: - If self._enabled is False, returns the original text. If it's True, - returns text with color escape sequences based on the value of color. - -if not self._enabled: -return text -if color == self.BOLD: -start = self.BOLD_START -else: -base = self.BRIGHT_START if bright else self.NORMAL_START -start = base % (color + 30) -return start + text + self.RESET +Returns: + If self._enabled is False, returns the original text. If it's True, + returns text with color escape sequences based on the value of + color. + +if not self._enabled: +return text +if color == self.BOLD: +start = self.BOLD_START +else: +base = self.BRIGHT_START if bright else self.NORMAL_START +start = base % (color + 30) +return start + text + self.RESET -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 1/5] patman: Support the 'reverse' option for 'git log'
This option is currently not supported, but needs to be, for buildman to
operate as expected.
Reported-by: York Sun york...@freescale.com
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v7:
- Add new patch to fix the 'reverse' bug
Changes in v6: None
Changes in v5: None
tools/patman/gitutil.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 735c8dd..e2b4959 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -38,6 +38,8 @@ def LogCmd(commit_range, git_dir=None, oneline=False,
reverse=False,
cmd.append('--oneline')
if use_no_decorate:
cmd.append('--no-decorate')
+if reverse:
+cmd.append('--reverse')
if count is not None:
cmd.append('-n%d' % count)
if commit_range:
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 0/5] Add some missing buildman features and deprecate MAKEALL
Buildman has been around for a little over a year and is used by a fair number of U-Boot developers. However quite a few people still use MAKEALL. Buildman was intended to replace MAKEALL, so perhaps now is a good time to start that process. The reasons to deprecate MAKEALL are: - We don't want to maintain two build systems - Buildman is typically faster - Buildman has a lot more features This series adds a few features to buildman to fill some gaps, adds some information into the README on how to migrate from MAKEALL, and adds a deprecation message to MAKEALL. Changes in v7: - Add new patch to fix the 'reverse' bug - Remove already-applied patches from the series - Add the deprecation message at the end of the build also - Drop the 'colour' patch sadly Changes in v6: - Add new patch to fix indentation in teminal.py - Add new patch to fix patman unit tests - Add new patch to remove patman's -a option Changes in v5: - Drop patch to search for *cc instead of *gcc for the compiler Simon Glass (5): patman: Support the 'reverse' option for 'git log' patman: Fix indentation in terminal.py patman: Correct unit tests to run correctly patman: Remove the -a option RFC: Deprecate MAKEALL MAKEALL | 10 tools/patman/gitutil.py | 98 +++--- tools/patman/patchstream.py | 7 ++- tools/patman/patman.py | 7 --- tools/patman/terminal.py| 112 +++- tools/patman/test.py| 13 ++--- 6 files changed, 87 insertions(+), 160 deletions(-) -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 3/5] patman: Correct unit tests to run correctly
It seems that doctest behaves differently now, and some of the unit tests
do not run. Adjust the tests to work correctly.
./tools/patman/patman --test
unittest.result.TestResult run=10 errors=0 failures=0
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v7: None
Changes in v6:
- Add new patch to fix patman unit tests
Changes in v5: None
tools/patman/gitutil.py | 8
tools/patman/patchstream.py | 7 +--
tools/patman/terminal.py| 8 ++--
tools/patman/test.py| 13 +++--
4 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index e2b4959..29e6fdd 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -478,13 +478,13 @@ def LookupEmail(lookup_name, alias=None,
raise_on_error=True, level=0):
...
OSError: Recursive email alias at 'other'
LookupEmail('odd', alias, raise_on_error=False)
-\033[1;31mAlias 'odd' not found\033[0m
+Alias 'odd' not found
[]
# In this case the loop part will effectively be ignored.
LookupEmail('loop', alias, raise_on_error=False)
-\033[1;31mRecursive email alias at 'other'\033[0m
-\033[1;31mRecursive email alias at 'john'\033[0m
-\033[1;31mRecursive email alias at 'mary'\033[0m
+Recursive email alias at 'other'
+Recursive email alias at 'john'
+Recursive email alias at 'mary'
['j.blo...@napier.co.nz', 'm.popp...@cloud.net']
if not alias:
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 0040468..322374c 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -275,7 +275,7 @@ class PatchStream:
# Suppress duplicate signoffs
elif signoff_match:
-if (self.is_log or
+if (self.is_log or not self.commit or
self.commit.CheckDuplicateSignoff(signoff_match.group(1))):
out = [line]
@@ -312,7 +312,10 @@ class PatchStream:
out = []
log = self.series.MakeChangeLog(self.commit)
out += self.FormatTags(self.tags)
-out += [line] + self.commit.notes + [''] + log
+out += [line]
+if self.commit:
+out += self.commit.notes
+out += [''] + log
elif self.found_test:
if not re_allowed_after_test.match(line):
self.lines_after_test += 1
diff --git a/tools/patman/terminal.py b/tools/patman/terminal.py
index 11f80d8..963f2f8 100644
--- a/tools/patman/terminal.py
+++ b/tools/patman/terminal.py
@@ -30,8 +30,12 @@ class Color(object):
enabled: True if color output should be enabled. If False then this
class will not add color codes at all.
-self._enabled = (colored == COLOR_ALWAYS or
-(colored == COLOR_IF_TERMINAL and os.isatty(sys.stdout.fileno(
+try:
+self._enabled = (colored == COLOR_ALWAYS or
+(colored == COLOR_IF_TERMINAL and
+ os.isatty(sys.stdout.fileno(
+except:
+self._enabled = False
def Start(self, color, bright=True):
Returns a start color code.
diff --git a/tools/patman/test.py b/tools/patman/test.py
index 8fcfe53..e8f7472 100644
--- a/tools/patman/test.py
+++ b/tools/patman/test.py
@@ -55,6 +55,7 @@ This adds functions to enable/disable clocks and reset to
on-chip peripherals.
Signed-off-by: Simon Glass s...@chromium.org
---
+
arch/arm/cpu/armv7/tegra2/Makefile |2 +-
arch/arm/cpu/armv7/tegra2/ap20.c | 57 ++
arch/arm/cpu/armv7/tegra2/clock.c | 163 +
@@ -200,7 +201,7 @@ index 000..2234c87
self.assertEqual(result.errors, 0)
self.assertEqual(result.warnings, 0)
self.assertEqual(result.checks, 0)
-self.assertEqual(result.lines, 67)
+self.assertEqual(result.lines, 56)
os.remove(inf)
def testNoSignoff(self):
@@ -211,18 +212,18 @@ index 000..2234c87
self.assertEqual(result.errors, 1)
self.assertEqual(result.warnings, 0)
self.assertEqual(result.checks, 0)
-self.assertEqual(result.lines, 67)
+self.assertEqual(result.lines, 56)
os.remove(inf)
def testSpaces(self):
inf = self.SetupData('spaces')
result = checkpatch.CheckPatch(inf)
self.assertEqual(result.ok, False)
-self.assertEqual(len(result.problems), 1)
+self.assertEqual(len(result.problems), 2)
self.assertEqual(result.errors, 0)
-self.assertEqual(result.warnings, 1)
+self.assertEqual(result.warnings, 2)
self.assertEqual(result.checks, 0)
-self.assertEqual(result.lines, 67)
+self.assertEqual(result.lines, 56)
os.remove(inf)
def testIndent(self):
@@ -233,7 +234,7 @@ index 000..2234c87
[U-Boot] [PATCH v7 4/5] patman: Remove the -a option
It seems that this is no longer needed, since checkpatch.pl will catch
whitespace problems in patches. Also the option is not widely used, so
it seems safe to just remove it.
Suggested-by: Masahiro Yamada yamad...@jp.panasonic.com
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v7: None
Changes in v6:
- Add new patch to remove patman's -a option
Changes in v5: None
tools/patman/gitutil.py | 88 -
tools/patman/patman.py | 7
2 files changed, 95 deletions(-)
diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
index 29e6fdd..45276e6 100644
--- a/tools/patman/gitutil.py
+++ b/tools/patman/gitutil.py
@@ -215,94 +215,6 @@ def CreatePatches(start, count, series):
else:
return None, files
-def ApplyPatch(verbose, fname):
-Apply a patch with git am to test it
-
-TODO: Convert these to use command, with stderr option
-
-Args:
-fname: filename of patch file to apply
-
-col = terminal.Color()
-cmd = ['git', 'am', fname]
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE,
-stderr=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-re_error = re.compile('^error: patch failed: (.+):(\d+)')
-for line in stderr.splitlines():
-if verbose:
-print line
-match = re_error.match(line)
-if match:
-print checkpatch.GetWarningMsg(col, 'warning', match.group(1),
- int(match.group(2)), 'Patch failed')
-return pipe.returncode == 0, stdout
-
-def ApplyPatches(verbose, args, start_point):
-Apply the patches with git am to make sure all is well
-
-Args:
-verbose: Print out 'git am' output verbatim
-args: List of patch files to apply
-start_point: Number of commits back from HEAD to start applying.
-Normally this is len(args), but it can be larger if a start
-offset was given.
-
-error_count = 0
-col = terminal.Color()
-
-# Figure out our current position
-cmd = ['git', 'name-rev', 'HEAD', '--name-only']
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode:
-str = 'Could not find current commit name'
-print col.Color(col.RED, str)
-print stdout
-return False
-old_head = stdout.splitlines()[0]
-if old_head == 'undefined':
-str = Invalid HEAD '%s' % stdout.strip()
-print col.Color(col.RED, str)
-return False
-
-# Checkout the required start point
-cmd = ['git', 'checkout', 'HEAD~%d' % start_point]
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE,
-stderr=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode:
-str = 'Could not move to commit before patch series'
-print col.Color(col.RED, str)
-print stdout, stderr
-return False
-
-# Apply all the patches
-for fname in args:
-ok, stdout = ApplyPatch(verbose, fname)
-if not ok:
-print col.Color(col.RED, 'git am returned errors for %s: will '
-'skip this patch' % fname)
-if verbose:
-print stdout
-error_count += 1
-cmd = ['git', 'am', '--skip']
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode != 0:
-print col.Color(col.RED, 'Unable to skip patch! Aborting...')
-print stdout
-break
-
-# Return to our previous position
-cmd = ['git', 'checkout', old_head]
-pipe = subprocess.Popen(cmd, stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
-stdout, stderr = pipe.communicate()
-if pipe.returncode:
-print col.Color(col.RED, 'Could not move back to head commit')
-print stdout, stderr
-return error_count == 0
-
def BuildEmailList(in_list, tag=None, alias=None, raise_on_error=True):
Build a list of email addresses based on an input list.
diff --git a/tools/patman/patman.py b/tools/patman/patman.py
index c60aa5a..902fb36 100755
--- a/tools/patman/patman.py
+++ b/tools/patman/patman.py
@@ -25,9 +25,6 @@ import test
parser = OptionParser()
-parser.add_option('-a', '--no-apply', action='store_false',
- dest='apply_patches', default=True,
- help=Don't test-apply patches with git am)
parser.add_option('-H', '--full-help', action='store_true', dest='full_help',
default=False, help='Display the README file')
parser.add_option('-c', '--count', dest='count', type='int',
@@ -144,10 +141,6 @@ else:
ok = checkpatch.CheckPatches(options.verbose, args)
else:
ok = True
-if options.apply_patches:
-if not gitutil.ApplyPatches(options.verbose, args,
-options.count +
[U-Boot] [PATCH v7 5/5] RFC: Deprecate MAKEALL
Since buildman now includes most of the features of MAKEALL it is probably
time to talk about deprecating MAKEALL.
Comments welcome.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v7:
- Remove already-applied patches from the series
- Add the deprecation message at the end of the build also
- Drop the 'colour' patch sadly
Changes in v6: None
Changes in v5:
- Drop patch to search for *cc instead of *gcc for the compiler
MAKEALL | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAKEALL b/MAKEALL
index 929fe88..e412336 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -60,6 +60,14 @@ usage()
exit ${ret}
}
+deprecation() {
+ echo ** Note: MAKEALL is deprecated - please use buildman instead
+ echo ** See tools/buildman/README for details
+ echo
+}
+
+deprecation
+
SHORT_OPTS=ha:c:v:s:b:lmMCnr
LONG_OPTS=help,arch:,cpu:,vendor:,soc:,board:,list,maintainers,mails,check,continue,rebuild-errors
@@ -849,6 +857,8 @@ print_stats() {
kill_children
fi
+ deprecation
+
exit $RC
}
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sxsabresd: Convert to the new Kconfig style
From: Fabio Estevam fabio.este...@freescale.com mx6sxsabresd was not in the master branch when the conversion to the new Kconfig style happened, so convert it now so that it can build again. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- arch/arm/Kconfig | 4 board/freescale/mx6sxsabresd/Kconfig | 23 +++ board/freescale/mx6sxsabresd/MAINTAINERS | 6 ++ configs/mx6sxsabresd_defconfig | 3 +++ 4 files changed, 36 insertions(+) create mode 100644 board/freescale/mx6sxsabresd/Kconfig create mode 100644 board/freescale/mx6sxsabresd/MAINTAINERS create mode 100644 configs/mx6sxsabresd_defconfig diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e385eda..c041e8a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -524,6 +524,9 @@ config TARGET_MX6SABRESD config TARGET_MX6SLEVK bool Support mx6slevk +config TARGET_MX6SXSABRESD + bool Support mx6sxsabresd + config TARGET_GW_VENTANA bool Support gw_ventana @@ -880,6 +883,7 @@ source board/freescale/mx6qarm2/Kconfig source board/freescale/mx6qsabreauto/Kconfig source board/freescale/mx6sabresd/Kconfig source board/freescale/mx6slevk/Kconfig +source board/freescale/mx6sxsabresd/Kconfig source board/freescale/vf610twr/Kconfig source board/gateworks/gw_ventana/Kconfig source board/genesi/mx51_efikamx/Kconfig diff --git a/board/freescale/mx6sxsabresd/Kconfig b/board/freescale/mx6sxsabresd/Kconfig new file mode 100644 index 000..ee8f4a6 --- /dev/null +++ b/board/freescale/mx6sxsabresd/Kconfig @@ -0,0 +1,23 @@ +if TARGET_MX6SXSABRESD + +config SYS_CPU + string + default armv7 + +config SYS_BOARD + string + default mx6sxsabresd + +config SYS_VENDOR + string + default freescale + +config SYS_SOC + string + default mx6 + +config SYS_CONFIG_NAME + string + default mx6sxsabresd + +endif diff --git a/board/freescale/mx6sxsabresd/MAINTAINERS b/board/freescale/mx6sxsabresd/MAINTAINERS new file mode 100644 index 000..f52f300 --- /dev/null +++ b/board/freescale/mx6sxsabresd/MAINTAINERS @@ -0,0 +1,6 @@ +MX6SXSABRESD BOARD +M: Fabio Estevam fabio.este...@freescale.com +S: Maintained +F: board/freescale/mx6sxsabresd/ +F: include/configs/mx6sxsabresd.h +F: configs/mx6sxsabresd_defconfig diff --git a/configs/mx6sxsabresd_defconfig b/configs/mx6sxsabresd_defconfig new file mode 100644 index 000..f23d48f --- /dev/null +++ b/configs/mx6sxsabresd_defconfig @@ -0,0 +1,3 @@ +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6sxsabresd/imximage.cfg,MX6SX +CONFIG_ARM=y +CONFIG_TARGET_MX6SXSABRESD=y -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mtd, nand: move common functions from cmd_nand.c to common place
On Mon, 2014-08-11 at 10:40 +0200, Heiko Schocher wrote:
Hello Scott,
Am 30.07.2014 02:29, schrieb Scott Wood:
On Mon, 2014-07-14 at 09:39 +0200, Heiko Schocher wrote:
move common functions from cmd_nand.c (for calculating offset
and size from cmdline paramter) to common place, so they could
used from other commands which use mtd partitions.
For onenand the arg_off_size() is left in common/cmd_onenand.c.
It should use now the common arg_off() function, but as I could
not test onenand I let it there ...
Signed-off-by: Heiko Schocherh...@denx.de
Cc: Scott Woodscottw...@freescale.com
Cc: Tom Rinitr...@ti.com
---
common/cmd_nand.c | 140
+---
common/cmd_onenand.c| 19 +++
drivers/mtd/Makefile| 4 +-
drivers/mtd/mtd_uboot.c | 114 +++
include/linux/mtd/mtd.h | 7 +++
5 files changed, 154 insertions(+), 130 deletions(-)
create mode 100644 drivers/mtd/mtd_uboot.c
ACK the concept, some nits below.
Have you given any more thought to formally taking over the
custodianship? If not, Tom, are you expecting another pull request from
me or were you going to apply Heiko's patches directly?
I thinking about it, yes, but I am really busy ... but it seems
nobody else want to volunteer ... I discussed with Wolfgang, if
it would make sense to create a mtd branch ... so, if you could not
longer maintain the nand branch, we can set it to orphaned (in the
hope, someone will volunteer ...) and I can also handle the nand
patches ... but Wolfgang is currently on vacation, so this step
maybe take a while ...
OK. I can still review things now and then, but it's getting hard to be
responsive to the extent expected of a custodian.
diff --git a/drivers/mtd/mtd_uboot.c b/drivers/mtd/mtd_uboot.c
new file mode 100644
index 000..66e49c3
--- /dev/null
+++ b/drivers/mtd/mtd_uboot.c
@@ -0,0 +1,114 @@
+/*
+ * (C) Copyright 2014
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#includecommon.h
+#includelinux/mtd/mtd.h
+#includejffs2/jffs2.h
What do you use from the jffs2 header?
Yes, good question ... because missing common mtd defines, like:
struct mtd_device {
found in include/jffs2/load_kernel.h
used in common/cmd_nand.c for example ... its really time to
cleanup the mtd subsystem!
Where to move this common defines? include/linux/mtd/mtd.h ?
But before the mtd/ubi/ubifs sync patches are not in mainline, I do
not want change this ... maybe it is okay to do this in a second step?
Sure.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()
On 08/04/2014 05:43 PM, Bryan Wu wrote: Use the new API which is originally taken out from boot_get_kernel of bootm.c Signed-off-by: Bryan Wu pe...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com --- common/bootm.c | 25 + 1 file changed, 5 insertions(+), 20 deletions(-) diff --git a/common/bootm.c b/common/bootm.c index 7ec2ed8..621bff2 100644 --- a/common/bootm.c +++ b/common/bootm.c snip bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC); @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, #endif #if defined(CONFIG_FIT) case IMAGE_FORMAT_FIT: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); os_noffset = fit_image_load(images, img_addr, fit_uname_kernel, fit_uname_config, IH_ARCH_DEFAULT, IH_TYPE_KERNEL, Did anyone test this addition? It breaks my booting. The variable img_addr get changed for calling fit_parse_conf(). If I don't use load_addr variable and run bootm addr with a FIT image, this will fail. It took me hours to figure out. Why is this change needed? What does it fix? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()
On Thu, Aug 14, 2014 at 6:00 PM, York Sun york...@freescale.com wrote: On 08/04/2014 05:43 PM, Bryan Wu wrote: Use the new API which is originally taken out from boot_get_kernel of bootm.c Signed-off-by: Bryan Wu pe...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com --- common/bootm.c | 25 + 1 file changed, 5 insertions(+), 20 deletions(-) diff --git a/common/bootm.c b/common/bootm.c index 7ec2ed8..621bff2 100644 --- a/common/bootm.c +++ b/common/bootm.c snip bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC); @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, #endif #if defined(CONFIG_FIT) case IMAGE_FORMAT_FIT: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); os_noffset = fit_image_load(images, img_addr, fit_uname_kernel, fit_uname_config, IH_ARCH_DEFAULT, IH_TYPE_KERNEL, Did anyone test this addition? It breaks my booting. The variable img_addr get changed for calling fit_parse_conf(). If I don't use load_addr variable and run bootm addr with a FIT image, this will fail. It took me hours to figure out. Why is this change needed? What does it fix? York I think Tom merged one with the fixing: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); Can you try that? -Bryan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()
Sorry for top posting from my phone. I tested with the latest code merged, not your original patch. York From: Bryan Wu Sent: Thu, 14/08/2014 18:05 To: Sun York-R58495 york...@freescale.com CC: Tom Rini tr...@ti.com; Stephen Warren swar...@wwwdotorg.org; u-boot@lists.denx.de; simon Glass s...@chromium.org; Basu Arnab-B45036 arnab.b...@freescale.com Subject: Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr() On Thu, Aug 14, 2014 at 6:00 PM, York Sun york...@freescale.com wrote: On 08/04/2014 05:43 PM, Bryan Wu wrote: Use the new API which is originally taken out from boot_get_kernel of bootm.c Signed-off-by: Bryan Wu pe...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com --- common/bootm.c | 25 + 1 file changed, 5 insertions(+), 20 deletions(-) diff --git a/common/bootm.c b/common/bootm.c index 7ec2ed8..621bff2 100644 --- a/common/bootm.c +++ b/common/bootm.c snip bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC); @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, #endif #if defined(CONFIG_FIT) case IMAGE_FORMAT_FIT: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); os_noffset = fit_image_load(images, img_addr, fit_uname_kernel, fit_uname_config, IH_ARCH_DEFAULT, IH_TYPE_KERNEL, Did anyone test this addition? It breaks my booting. The variable img_addr get changed for calling fit_parse_conf(). If I don't use load_addr variable and run bootm addr with a FIT image, this will fail. It took me hours to figure out. Why is this change needed? What does it fix? York I think Tom merged one with the fixing: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); Can you try that? -Bryan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()
On Thu, Aug 14, 2014 at 06:00:31PM -0700, York Sun wrote: On 08/04/2014 05:43 PM, Bryan Wu wrote: Use the new API which is originally taken out from boot_get_kernel of bootm.c Signed-off-by: Bryan Wu pe...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com --- common/bootm.c | 25 + 1 file changed, 5 insertions(+), 20 deletions(-) diff --git a/common/bootm.c b/common/bootm.c index 7ec2ed8..621bff2 100644 --- a/common/bootm.c +++ b/common/bootm.c snip bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC); @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, #endif #if defined(CONFIG_FIT) case IMAGE_FORMAT_FIT: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); os_noffset = fit_image_load(images, img_addr, fit_uname_kernel, fit_uname_config, IH_ARCH_DEFAULT, IH_TYPE_KERNEL, Did anyone test this addition? It breaks my booting. The variable img_addr get changed for calling fit_parse_conf(). If I don't use load_addr variable and run bootm addr with a FIT image, this will fail. It took me hours to figure out. How exactly are you booting? I tested a fit with bootm addr#conf@1 or so. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr()
Tom, I tested with bootm 806f. My FIT image is loaded there. I don't have load_addr variable. My default load_addr (from CONFIG macro) is different from this address. York From: Tom Rini Sent: Thu, 14/08/2014 18:38 To: Sun York-R58495 york...@freescale.com CC: Bryan Wu coolo...@gmail.com; s...@chromium.org; swar...@wwwdotorg.org; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2 3/3] bootm: use genimg_get_kernel_addr() On Thu, Aug 14, 2014 at 06:00:31PM -0700, York Sun wrote: On 08/04/2014 05:43 PM, Bryan Wu wrote: Use the new API which is originally taken out from boot_get_kernel of bootm.c Signed-off-by: Bryan Wu pe...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com --- common/bootm.c | 25 + 1 file changed, 5 insertions(+), 20 deletions(-) diff --git a/common/bootm.c b/common/bootm.c index 7ec2ed8..621bff2 100644 --- a/common/bootm.c +++ b/common/bootm.c snip bootstage_mark(BOOTSTAGE_ID_CHECK_MAGIC); @@ -807,6 +788,10 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, #endif #if defined(CONFIG_FIT) case IMAGE_FORMAT_FIT: + if (!fit_parse_conf(argv[0], load_addr, img_addr, + fit_uname_config)) + fit_parse_subimage(argv[0], load_addr, img_addr, + fit_uname_kernel); os_noffset = fit_image_load(images, img_addr, fit_uname_kernel, fit_uname_config, IH_ARCH_DEFAULT, IH_TYPE_KERNEL, Did anyone test this addition? It breaks my booting. The variable img_addr get changed for calling fit_parse_conf(). If I don't use load_addr variable and run bootm addr with a FIT image, this will fail. It took me hours to figure out. How exactly are you booting? I tested a fit with bootm addr#conf@1 or so. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
