Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
Hello Marek,
Am 18.03.2014 01:21, schrieb Marek Vasut:
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocherh...@denx.de
Cc: Lukasz Majewskil.majew...@samsung.com
Cc: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Marek Vasutma...@denx.de
Cc: Pantelis Antonioupa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int
size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
-
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened brace (see 'if
(size == 0) {' I can fix this up when applying.
Argh... you are right patch 2/3 of this series deletes the
complete if ... I can send a new version, but if you want to fix
it that would be great!
Do you want this in 2014.04 or in -next ?
Hmm.. 2014.04 would be nice, but I think this is Lukasz decision,
because I changed the dfu state machine, and maybe he want to see
more tests?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] _POST_WORD_ADDR for ARM
Hi, How can we define _POST_WORD_ADDR for ARM.In case enabling post for arm on post.h how can i define _POST_WORD_ADDR. how it is defined in other platform.please tell me the logic behind _POST_WORD_ADDR. regards, shobin.b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fsl/diu: ch7301 encoder split off from t1040qds/diu.c
From: Wang Dongsheng dongsheng.w...@freescale.com
The ch7301 encoder not only used in t1040qds platform, so we split
it for t1042rdb and LSx platform.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index f6a0879..cd4b33b 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_DIU_CH7301) += diu_ch7301.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/diu_ch7301.c
b/board/freescale/common/diu_ch7301.c
new file mode 100644
index 000..497fa1b
--- /dev/null
+++ b/board/freescale/common/diu_ch7301.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ * Authors: Priyanka Jain priyanka.j...@freescale.com
+ * Wang Dongsheng dongsheng.w...@freescale.com
+ *
+ * This file is copied and modified from the original t1040qds/diu.c.
+ * Encoder can be used in T104x and LSx Platform.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include stdio_dev.h
+#include i2c.h
+
+#define I2C_DVI_INPUT_DATA_FORMAT_REG 0x1F
+#define I2C_DVI_PLL_CHARGE_CNTL_REG0x33
+#define I2C_DVI_PLL_DIVIDER_REG0x34
+#define I2C_DVI_PLL_SUPPLY_CNTL_REG0x35
+#define I2C_DVI_PLL_FILTER_REG 0x36
+#define I2C_DVI_TEST_PATTERN_REG 0x48
+#define I2C_DVI_POWER_MGMT_REG 0x49
+#define I2C_DVI_LOCK_STATE_REG 0x4D
+#define I2C_DVI_SYNC_POLARITY_REG 0x56
+
+/*
+ * Set VSYNC/HSYNC to active high. This is polarity of sync signals
+ * from DIU-DVI. The DIU default is active igh, so DVI is set to
+ * active high.
+ */
+#define I2C_DVI_INPUT_DATA_FORMAT_VAL 0x98
+
+#define I2C_DVI_PLL_CHARGE_CNTL_HIGH_SPEED_VAL 0x06
+#define I2C_DVI_PLL_DIVIDER_HIGH_SPEED_VAL 0x26
+#define I2C_DVI_PLL_FILTER_HIGH_SPEED_VAL 0xA0
+#define I2C_DVI_PLL_CHARGE_CNTL_LOW_SPEED_VAL 0x08
+#define I2C_DVI_PLL_DIVIDER_LOW_SPEED_VAL 0x16
+#define I2C_DVI_PLL_FILTER_LOW_SPEED_VAL 0x60
+
+/* Clear test pattern */
+#define I2C_DVI_TEST_PATTERN_VAL 0x18
+/* Exit Power-down mode */
+#define I2C_DVI_POWER_MGMT_VAL 0xC0
+
+/* Monitor polarity is handled via DVI Sync Polarity Register */
+#define I2C_DVI_SYNC_POLARITY_VAL 0x00
+
+/* Programming of HDMI Chrontel CH7301 connector */
+int diu_set_dvi_encoder(unsigned int pixclock)
+{
+ int ret;
+ u8 temp;
+
+ temp = I2C_DVI_TEST_PATTERN_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_TEST_PATTERN_REG, 1,
+ temp, 1);
+ if (ret) {
+ puts(I2C: failed to select proper dvi test pattern\n);
+ return ret;
+ }
+ temp = I2C_DVI_INPUT_DATA_FORMAT_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_INPUT_DATA_FORMAT_REG,
+ 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi input data format\n);
+ return ret;
+ }
+
+ /* Set Sync polarity register */
+ temp = I2C_DVI_SYNC_POLARITY_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_SYNC_POLARITY_REG, 1,
+ temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi syc polarity\n);
+ return ret;
+ }
+
+ /* Set PLL registers based on pixel clock rate*/
+ if (pixclock 6500) {
+ temp = I2C_DVI_PLL_CHARGE_CNTL_HIGH_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_CHARGE_CNTL_REG, 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi pll charge_cntl\n);
+ return ret;
+ }
+ temp = I2C_DVI_PLL_DIVIDER_HIGH_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_DIVIDER_REG, 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi pll divider\n);
+ return ret;
+ }
+ temp = I2C_DVI_PLL_FILTER_HIGH_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_FILTER_REG, 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi pll filter\n);
+ return ret;
+ }
+ } else {
+ temp = I2C_DVI_PLL_CHARGE_CNTL_LOW_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_CHARGE_CNTL_REG, 1, temp, 1);
+ if (ret) {
+
[U-Boot] [PATCH 2/2] powerpc/t1042RDB: Add Video - HDMI support
From: Jason Jin jason@freescale.com
T1042 has internal display interface unit (DIU) for driving video.
T1042RDB supports video mode via
-LCD using TI enconder
-HDMI type interface via HDMI encoder
Chrontel, CH7301C encoder which is I2C programmable is used
as HDMI connector on T1042RDB.
This patch add support to
-enable Video interface for T1042RDB
-route qixis multiplexing to enable DIU-HDMI interface on board
-program DIU pixel clock gerenartor for T1042
-program HDMI encoder via I2C on board
This patch refer to the upstream diu patch
(337b0c52b3296f371d04aef71a833e09110e0e6b) for T1040qds.
Signed-off-by: Jason Jin jason@freescale.com
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
This patch depends on CPLD.
Ozlab link: http://patchwork.ozlabs.org/patch/328180/
diff --git a/board/freescale/t104xrdb/Makefile
b/board/freescale/t104xrdb/Makefile
index af38d9f..f15a633 100644
--- a/board/freescale/t104xrdb/Makefile
+++ b/board/freescale/t104xrdb/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_PCI) += pci.o
obj-y += law.o
obj-y += tlb.o
obj-y += cpld.o
+obj-$(CONFIG_FSL_DIU_FB) += diu.o
diff --git a/board/freescale/t104xrdb/diu.c b/board/freescale/t104xrdb/diu.c
new file mode 100644
index 000..a4f378c
--- /dev/null
+++ b/board/freescale/t104xrdb/diu.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ * Author: Priyanka Jain priyanka.j...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm/io.h
+#include common.h
+#include command.h
+#include fsl_diu_fb.h
+#include linux/ctype.h
+#include video_fb.h
+
+#include ../common/diu_ch7301.h
+
+#include cpld.h
+#include t104xrdb.h
+
+/*
+ * DIU Area Descriptor
+ *
+ * Note that we need to byte-swap the value before it's written to the AD
+ * register. So even though the registers don't look like they're in the same
+ * bit positions as they are on the MPC8610, the same value is written to the
+ * AD register on the MPC8610 and on the P1022.
+ */
+#define AD_BYTE_F 0x1000
+#define AD_ALPHA_C_SHIFT 25
+#define AD_BLUE_C_SHIFT23
+#define AD_GREEN_C_SHIFT 21
+#define AD_RED_C_SHIFT 19
+#define AD_PIXEL_S_SHIFT 16
+#define AD_COMP_3_SHIFT12
+#define AD_COMP_2_SHIFT8
+#define AD_COMP_1_SHIFT4
+#define AD_COMP_0_SHIFT0
+
+void diu_set_pixel_clock(unsigned int pixclock)
+{
+ unsigned long speed_ccb, temp;
+ u32 pixval;
+ int ret;
+ speed_ccb = get_bus_freq(0);
+ temp = 10 / pixclock;
+ temp *= 1000;
+ pixval = speed_ccb / temp;
+
+ /* Program HDMI encoder */
+ ret = diu_set_dvi_encoder(temp);
+ if (ret) {
+ puts(Failed to set DVI encoder\n);
+ return;
+ }
+
+ /* Program pixel clock */
+ out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR,
+((pixval PXCK_BITS_START) PXCK_MASK));
+ /* enable clock*/
+ out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR, PXCKEN_MASK |
+((pixval PXCK_BITS_START) PXCK_MASK));
+}
+
+int platform_diu_init(unsigned int xres, unsigned int yres, const char *port)
+{
+ u32 pixel_format;
+ u8 sw;
+
+ /*Configure Display ouput port as HDMI*/
+ sw = CPLD_READ(sfp_ctl_status);
+ CPLD_WRITE(sfp_ctl_status , sw ~(CPLD_DIU_SEL_DFP));
+
+ pixel_format = cpu_to_le32(AD_BYTE_F | (3 AD_ALPHA_C_SHIFT) |
+ (0 AD_BLUE_C_SHIFT) | (1 AD_GREEN_C_SHIFT) |
+ (2 AD_RED_C_SHIFT) | (8 AD_COMP_3_SHIFT) |
+ (8 AD_COMP_2_SHIFT) | (8 AD_COMP_1_SHIFT) |
+ (8 AD_COMP_0_SHIFT) | (3 AD_PIXEL_S_SHIFT));
+
+ printf(DIU: Switching to monitor DVI @ %ux%u\n, xres, yres);
+
+ return fsl_diu_init(xres, yres, pixel_format, 0);
+}
diff --git a/include/configs/T1042RDB_PI.h b/include/configs/T1042RDB_PI.h
index 8a8a2ff..0d0f1cd 100644
--- a/include/configs/T1042RDB_PI.h
+++ b/include/configs/T1042RDB_PI.h
@@ -203,6 +203,7 @@
#define CPLD_LBMAP_DFLTBANK0x40 /* BANK OR | BANK0 */
#define CPLD_LBMAP_RESET 0xFF
#define CPLD_LBMAP_SHIFT 0x03
+#define CPLD_DIU_SEL_DFP 0x80
#define CONFIG_SYS_CPLD_BASE 0xffdf
#define CONFIG_SYS_CPLD_BASE_PHYS (0xfull | CONFIG_SYS_CPLD_BASE)
@@ -332,7 +333,8 @@
#define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET
#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
-#define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024)
+/*When DIU is enabled, more malloc memory needed for fb*/
+#define CONFIG_SYS_MALLOC_LEN (10 * 1024 * 1024)
/* Serial Port - controlled on board with jumper J8
* open - index 2
@@ -352,12 +354,27 @@
#define CONFIG_SYS_NS16550_COM3(CONFIG_SYS_CCSRBAR+0x11D500)
#define CONFIG_SYS_NS16550_COM4(CONFIG_SYS_CCSRBAR+0x11D600)
#define
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
Hi Marek,
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void
*buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
-
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened brace
(see 'if (size == 0) {' I can fix this up when applying.
I was prepared to pull those patches to u-boot-dfu repo today and test
them :-).
Afterwards, I would send PR to Tom.
Are you OK with this?
Do you want this in 2014.04 or in -next ?
After testing I would go for 2014.04, if Tom doesn't mind. All in all
it fixes the DFU state machine - by adding missing states. Up till
now we had short cut in the DFU state machine.
[...]
Best regards,
Marek Vasut
--
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] fpga: zynqpl: Fixed bug in alignment routine
Hi Eli,
On Sun, Mar 16, 2014 at 2:10 AM, Eli Billauer eli.billa...@gmail.comwrote:
The aligned buffer is always with a higher address, so copying should run
from the end of the buffer to the beginning, and not the other way around.
Signed-off-by: Eli Billauer eli.billa...@gmail.com
---
drivers/fpga/zynqpl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index 160abc7..2888131 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -173,7 +173,8 @@ int zynq_load(Xilinx_desc *desc, const void *buf,
size_t bsize)
{
unsigned long ts; /* Timestamp */
u32 partialbit = 0;
- u32 i, control, isr_status, status, swap, diff;
+ u32 control, isr_status, status, swap, diff;
+ int i;
u32 *buf_start;
/* Detect if we are going working with partial or full bitstream */
@@ -206,7 +207,7 @@ int zynq_load(Xilinx_desc *desc, const void *buf,
size_t bsize)
printf(%s: Align buffer at %x to %x(swap %d)\n, __func__,
(u32)buf_start, (u32)new_buf, swap);
- for (i = 0; i (bsize/4); i++)
+ for (i = (bsize/4)-1; i = 0 ; i--)
new_buf[i] = load_word(buf_start[i], swap);
This looks like not correct because if you look at the code above this, it
always ensuring that the new aligned buffer start is in front of the actual
buffer. That is for example if actual buff start is at 0x6C, then it
provides new buf aligned at 0x00 and copying word by word from 0x6C to 0x00.
But here if you do copy word by word from the end, it will end up in
corrupting the actual data.(For example if our buff len is some 0x100 the
you are trying to copy from 0x16c to 0x100 which will corrupt the actual
data at 0x100).
Regards,
DP
swap = SWAP_DONE;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
Hi Heiko,
Hello Marek,
Am 18.03.2014 01:21, schrieb Marek Vasut:
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocherh...@denx.de
Cc: Lukasz Majewskil.majew...@samsung.com
Cc: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Marek Vasutma...@denx.de
Cc: Pantelis Antonioupa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void
*buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n,
dfu-crc); -
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened
brace (see 'if (size == 0) {' I can fix this up when applying.
Argh... you are right patch 2/3 of this series deletes the
complete if ... I can send a new version, but if you want to fix
it that would be great!
In this case, please prepare v3.
Do you want this in 2014.04 or in -next ?
Hmm.. 2014.04 would be nice, but I think this is Lukasz decision,
because I changed the dfu state machine, and maybe he want to see
more tests?
When you send the v3, I will test it for regression and then I will
prepare pull request to Tom for v2014.04.
Those patches will be added to u-boot-dfu repository.
bye,
Heiko
--
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] _POST_WORD_ADDR for ARM
Hi, How can we define _POST_WORD_ADDR for ARM.In case enabling post for arm on post.h how can i define _POST_WORD_ADDR. how it is defined in other platform.please tell me the logic behind _POST_WORD_ADDR. I remember Denk has said : _POST_WORD_ADDR should point to a non-volatile region. Such as : You could let it point to some scratch registers in your SOC. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/t1042RDB: Add Video - HDMI support
Dear Dongsheng Wang,
In message 1395123347-15025-2-git-send-email-dongsheng.w...@freescale.com you
wrote:
From: Jason Jin jason@freescale.com
...
+void diu_set_pixel_clock(unsigned int pixclock)
+{
+ unsigned long speed_ccb, temp;
+ u32 pixval;
+ int ret;
+ speed_ccb = get_bus_freq(0);
+ temp = 10 / pixclock;
+ temp *= 1000;
+ pixval = speed_ccb / temp;
Please always separate declarations and code by a blank line.
#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
-#define CONFIG_SYS_MALLOC_LEN(4 * 1024 * 1024)
+/*When DIU is enabled, more malloc memory needed for fb*/
+#define CONFIG_SYS_MALLOC_LEN(10 * 1024 * 1024)
This looks wrong to me. The FB should not be allocated using
malloc(). Instead, it is supposed to be located at the end of the
RAM - search for reserve memory for LCD display in
arch/arm/lib/board.c. Yes, I am aware that you don;t use a LCD
here, but the appraoch should be the same in any case.
@@ -352,12 +354,27 @@
#define CONFIG_SYS_NS16550_COM3 (CONFIG_SYS_CCSRBAR+0x11D500)
#define CONFIG_SYS_NS16550_COM4 (CONFIG_SYS_CCSRBAR+0x11D600)
#define CONFIG_SERIAL_MULTI /* Enable both serial ports */
-#define CONFIG_SYS_CONSOLE_IS_IN_ENV /* determine from environment */
This appears to be an unrelated change?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The net result is a system that is not only binary compatible with
4.3 BSD, but is even bug for bug compatible in almost all features.
- Avadit Tevanian, Jr., Architecture-Independent Virtual Memory
Management for Parallel and Distributed Environments: The Mach
Approach
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/3] usb: dfu: introduce dfuMANIFEST state
on nand flash using ubi, after the download of the new image into
the flash, the rest of the nand sectors get erased while flushing
the medium. With current u-boot version dfu-util may show:
Starting download: [##]
finished!
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU status
as dfu_get_status is not answered while erasing sectors, if erasing
needs some time.
So do the following changes to prevent this:
- introduce dfuManifest state
According to dfu specification [1] section 7:
the device enters the dfuMANIFEST-SYNC state and awaits the solicitation
of the status report by the host. Upon receipt of the anticipated
DFU_GETSTATUS, the device enters the dfuMANIFEST state, where it
completes its reprogramming operations.
- when stepping into dfuManifest state, sending a PollTimeout
DFU_MANIFEST_POLL_TIMEOUT in ms, to the host, so the host
(dfu-util) waits the PollTimeout before sending a get_status again.
Patch 0002-usb-dfu-introduce-dfuMANIFEST-state.patch shows
following checkpatch errors, but I think they are OK, as the
hole file uses CamelCase for the statenames as this in sync
with [1]
CHECK: Avoid CamelCase: DFU_STATE_dfuMANIFEST
#103: FILE: drivers/usb/gadget/f_dfu.c:190:
+ f_dfu-dfu_state = DFU_STATE_dfuMANIFEST;
CHECK: Avoid CamelCase: DFU_STATE_dfuIDLE
#156: FILE: drivers/usb/gadget/f_dfu.c:491:
+ f_dfu-dfu_state = DFU_STATE_dfuIDLE;
CHECK: Avoid CamelCase: DFU_STATE_dfuERROR
#166: FILE: drivers/usb/gadget/f_dfu.c:501:
+ f_dfu-dfu_state = DFU_STATE_dfuERROR;
total: 0 errors, 0 warnings, 3 checks, 133 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE USLEEP_RANGE
[1]:
http://www.usb.org/developers/devclass_docs/usbdfu10.pdf
- changes for v3:
- remove { after if as Marek Vasut suggested
- changes for v2:
- add Pantelis Antoniou to Cc
- add comment from Marek Vasut
- move comment and if back to dfu_write()
- add comment from Lukasz Majewski:
- remove unneccessary comment end?
- add Readme entry for DFU_DEFAULT_POLL_TIMEOUT
- remove unneeded flag setpolltimeout
- ToDo:
- look if it is possible to get rid of the constant DFU_MANIFEST_POLL_TIMEOUT
for all dfu entities. Maybe as Lukasz suggested:
Add a callback - called e.g. (*poll_timeout) to the struct
[mmc|nand]_internal_data.
Then some helper functions would be defined at dfu_[mmc|nand].c and used
at f_dfu.c
so we can decide on a per medium/partition base, how long a PollTimeout
would be for a dfu entity ... This can be done in a seperate
step.
Heiko Schocher (3):
usb, dfu: extract flush code into seperate function
usb: dfu: introduce dfuMANIFEST state
am335x, dfu: add DFU_MANIFEST_POLL_TIMEOUT to the siemens boards
README | 10 +++
drivers/dfu/dfu.c | 42 +++--
drivers/usb/gadget/f_dfu.c | 48 +-
include/configs/siemens-am33x-common.h | 1 +
include/dfu.h | 4 +++
5 files changed, 79 insertions(+), 26 deletions(-)
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] usb: dfu: introduce dfuMANIFEST state
on nand flash using ubi, after the download of the new image into
the flash, the rest of the nand sectors get erased while flushing
the medium. With current u-boot version dfu-util may show:
Starting download: [##]
finished!
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU status
as get_status is not answered while erasing sectors, if erasing
needs some time.
So do the following changes to prevent this:
- introduce dfuManifest state
According to dfu specification
( http://www.usb.org/developers/devclass_docs/usbdfu10.pdf ) section 7:
the device enters the dfuMANIFEST-SYNC state and awaits the solicitation
of the status report by the host. Upon receipt of the anticipated
DFU_GETSTATUS, the device enters the dfuMANIFEST state, where it
completes its reprogramming operations.
- when stepping into dfuManifest state, sending a PollTimeout
DFU_MANIFEST_POLL_TIMEOUT in ms, to the host, so the host
(dfu-util) waits the PollTimeout before sending a get_status again.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
---
- changes for v3:
Fixed patch, as patch 1/3 changed
- changes for v2:
- reworked as patch 01 of this series changed as Marek Vasut commented
- setting req-length = 0 before calling dfu_flush() not necessary
- add comment from Lukasz Majewski:
- add Pantelis to Cc
- add Readme entry for DFU_DEFAULT_POLL_TIMEOUT
- remove unneeded flag setpolltimeout
---
README | 10 ++
drivers/dfu/dfu.c | 4
drivers/usb/gadget/f_dfu.c | 48 --
include/dfu.h | 3 +++
4 files changed, 55 insertions(+), 10 deletions(-)
diff --git a/README b/README
index 216f0c7..7cb7c4f 100644
--- a/README
+++ b/README
@@ -1525,6 +1525,16 @@ The following options need to be configured:
this to the maximum filesize (in bytes) for the buffer.
Default is 4 MiB if undefined.
+ DFU_DEFAULT_POLL_TIMEOUT
+ Poll timeout [ms], is the timeout a device can send to the
+ host. The host must wait for this timeout before sending
+ a subsequent DFU_GET_STATUS request to the device.
+
+ DFU_MANIFEST_POLL_TIMEOUT
+ Poll timeout [ms], which the device sends to the host when
+ entering dfuMANIFEST state. Host waits this timeout, before
+ sending again an USB request to the device.
+
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE,
CONFIG_JFFS2_NAND_DEV
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 5232986..8a09aaf 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -219,10 +219,6 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
ret = tret;
}
- /* end? */
- if (size == 0)
- ret = dfu_flush(dfu, buf, size, blk_seq_num);
-
return ret = 0 ? size : ret;
}
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index a045864..de75ff1 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -164,9 +164,14 @@ static void dnload_request_complete(struct usb_ep *ep,
struct usb_request *req)
dfu_write(dfu_get_entity(f_dfu-altsetting), req-buf,
req-length, f_dfu-blk_seq_num);
+}
- if (req-length == 0)
- puts(DOWNLOAD ... OK\nCtrl+C to exit ...\n);
+static void dnload_request_flush(struct usb_ep *ep, struct usb_request *req)
+{
+ struct f_dfu *f_dfu = req-context;
+
+ dfu_flush(dfu_get_entity(f_dfu-altsetting), req-buf,
+ req-length, f_dfu-blk_seq_num);
}
static void handle_getstatus(struct usb_request *req)
@@ -174,19 +179,22 @@ static void handle_getstatus(struct usb_request *req)
struct dfu_status *dstat = (struct dfu_status *)req-buf;
struct f_dfu *f_dfu = req-context;
+ dfu_set_poll_timeout(dstat, 0);
+
switch (f_dfu-dfu_state) {
case DFU_STATE_dfuDNLOAD_SYNC:
case DFU_STATE_dfuDNBUSY:
f_dfu-dfu_state = DFU_STATE_dfuDNLOAD_IDLE;
break;
case DFU_STATE_dfuMANIFEST_SYNC:
+ f_dfu-dfu_state = DFU_STATE_dfuMANIFEST;
break;
+ case DFU_STATE_dfuMANIFEST:
+ dfu_set_poll_timeout(dstat, DFU_MANIFEST_POLL_TIMEOUT);
default:
break;
}
- dfu_set_poll_timeout(dstat, 0);
-
if (f_dfu-poll_timeout)
if (!(f_dfu-blk_seq_num %
(dfu_get_buf_size() / DFU_USB_BUFSIZ)))
@@ -446,10 +454,11 @@ static int
[U-Boot] [PATCH v3 1/3] usb, dfu: extract flush code into seperate function
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
---
- changes for v3:
- remove { after if as Marek Vasut suggested
- changes for v2
- add comment from Marek Vasut
- move comment and if back to dfu_write()
- add comment from Lukasz Majewski:
- remove unneccessary comment
- add Pantelis to Cc
Signed-off-by: Heiko Schocher h...@denx.de
---
drivers/dfu/dfu.c | 42 --
include/dfu.h | 1 +
2 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 56e69fd..5232986 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -127,6 +127,28 @@ static int dfu_write_buffer_drain(struct dfu_entity *dfu)
return ret;
}
+int dfu_flush(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)
+{
+ int ret = 0;
+
+ if (dfu-flush_medium)
+ ret = dfu-flush_medium(dfu);
+
+ printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
+
+ /* clear everything */
+ dfu_free_buf();
+ dfu-crc = 0;
+ dfu-offset = 0;
+ dfu-i_blk_seq_num = 0;
+ dfu-i_buf_start = dfu_buf;
+ dfu-i_buf_end = dfu_buf;
+ dfu-i_buf = dfu-i_buf_start;
+ dfu-inited = 0;
+
+ return ret;
+}
+
int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)
{
int ret = 0;
@@ -198,24 +220,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
}
/* end? */
- if (size == 0) {
- /* Now try and flush to the medium if needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
-
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ if (size == 0)
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
return ret = 0 ? size : ret;
}
diff --git a/include/dfu.h b/include/dfu.h
index f973426..272a245 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -138,6 +138,7 @@ unsigned long dfu_get_buf_size(void);
int dfu_read(struct dfu_entity *de, void *buf, int size, int blk_seq_num);
int dfu_write(struct dfu_entity *de, void *buf, int size, int blk_seq_num);
+int dfu_flush(struct dfu_entity *de, void *buf, int size, int blk_seq_num);
/* Device specific */
#ifdef CONFIG_DFU_MMC
extern int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *s);
--
1.8.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] am335x, dfu: add DFU_MANIFEST_POLL_TIMEOUT to the siemens boards
as the siemens boards use dfu for updating a nand ubi partition add DFU_MANIFEST_POLL_TIMEOUT to them, so dfu host waits after complete transfer of the new image for DFU_MANIFEST_POLL_TIMEOUT ms before sending again an usb request. So the board have enough time to erase rest of the nand sectors. Signed-off-by: Heiko Schocher h...@denx.de Reviewed-by: Lukasz Majewski l.majew...@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com Cc: Pantelis Antoniou pa...@antoniou-consulting.com --- - no changes for v3 - changes for v2: - add Reviewed-by from Lukasz Majewski - add Pantelis Antoniou to Cc --- include/configs/siemens-am33x-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/siemens-am33x-common.h b/include/configs/siemens-am33x-common.h index 98b6e72..721c4e6 100644 --- a/include/configs/siemens-am33x-common.h +++ b/include/configs/siemens-am33x-common.h @@ -265,6 +265,7 @@ #define CONFIG_DFU_NAND #define CONFIG_CMD_DFU #define CONFIG_SYS_DFU_DATA_BUF_SIZE (1 20) +#define DFU_MANIFEST_POLL_TIMEOUT 25000 #endif /* CONFIG_SPL_BUILD */ -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] kbuild: move asm-offsets.c from SoC directory to arch/$(ARCH)/lib
U-Boot has supported two kinds of asm-offsets.h.
One is generic for all architectures and its source is located at
./lib/asm-offsets.c.
The other is SoC specific and its source is under SoC directory.
The problem here is that only boards with SoC directory can use
the asm-offsets infrastructure.
Putting asm-offsets.c right under CPU directory does not work.
Now a new demand is coming. PowerPC folks want to use asm-offsets.
But no PowerPC boards have SoC directory.
It seems inconsistent that some boards add asm-offsets.c to SoC
directoreis and some to CPU directories.
It looks more reasonable to put asm-offsets.c under arch/$(ARCH)/lib.
This commit merges asm-offsets.c under SoC directories into
arch/$(ARCH)/lib/asm-offsets.c.
By the way, I doubt the necessity of some entries in asm-offsets.c.
I am leaving refactoring to the board maintainers.
Please check TODO in the comment blocks in
arch/{arm,nds32}/lib/asm-offsets.c.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Yuantian Tang yuantian.t...@freescale.com
---
Kbuild | 8 +-
arch/arm/cpu/arm1136/mx35/asm-offsets.c | 71
arch/arm/cpu/arm926ejs/mb86r0x/asm-offsets.c | 62 ---
arch/arm/cpu/arm926ejs/mx25/asm-offsets.c| 57 --
arch/arm/cpu/arm926ejs/mx27/asm-offsets.c| 47 -
arch/arm/cpu/armv7/mx5/asm-offsets.c | 73
arch/arm/lib/asm-offsets.c | 248 +++
arch/nds32/cpu/n1213/ag101/asm-offsets.c | 44 -
arch/nds32/cpu/n1213/ag102/asm-offsets.c | 54 --
arch/nds32/lib/asm-offsets.c | 82 +
arch/x86/cpu/coreboot/asm-offsets.c | 22 ---
arch/x86/lib/asm-offsets.c | 22 +++
12 files changed, 356 insertions(+), 434 deletions(-)
delete mode 100644 arch/arm/cpu/arm1136/mx35/asm-offsets.c
delete mode 100644 arch/arm/cpu/arm926ejs/mb86r0x/asm-offsets.c
delete mode 100644 arch/arm/cpu/arm926ejs/mx25/asm-offsets.c
delete mode 100644 arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
delete mode 100644 arch/arm/cpu/armv7/mx5/asm-offsets.c
create mode 100644 arch/arm/lib/asm-offsets.c
delete mode 100644 arch/nds32/cpu/n1213/ag101/asm-offsets.c
delete mode 100644 arch/nds32/cpu/n1213/ag102/asm-offsets.c
create mode 100644 arch/nds32/lib/asm-offsets.c
delete mode 100644 arch/x86/cpu/coreboot/asm-offsets.c
create mode 100644 arch/x86/lib/asm-offsets.c
diff --git a/Kbuild b/Kbuild
index 1d89761..6e1698c 100644
--- a/Kbuild
+++ b/Kbuild
@@ -42,13 +42,13 @@ $(obj)/$(generic-offsets-file): lib/asm-offsets.s Kbuild
# 2) Generate asm-offsets.h
#
-ifneq ($(wildcard $(srctree)/$(CPUDIR)/$(SOC)/asm-offsets.c),)
+ifneq ($(wildcard $(srctree)/arch/$(ARCH)/lib/asm-offsets.c),)
offsets-file := include/generated/asm-offsets.h
endif
always += $(offsets-file)
targets += $(offsets-file)
-targets += $(CPUDIR)/$(SOC)/asm-offsets.s
+targets += arch/$(ARCH)/lib/asm-offsets.s
# Default sed regexp - multiline due to syntax constraints
@@ -79,9 +79,9 @@ define cmd_offsets
endef
# We use internal kbuild rules to avoid the is up to date message from make
-$(CPUDIR)/$(SOC)/asm-offsets.s: $(CPUDIR)/$(SOC)/asm-offsets.c FORCE
+arch/$(ARCH)/lib/asm-offsets.s: arch/$(ARCH)/lib/asm-offsets.c FORCE
$(Q)mkdir -p $(dir $@)
$(call if_changed_dep,cc_s_c)
-$(obj)/$(offsets-file): $(CPUDIR)/$(SOC)/asm-offsets.s
+$(obj)/$(offsets-file): arch/$(ARCH)/lib/asm-offsets.s Kbuild
$(call cmd,offsets)
diff --git a/arch/arm/cpu/arm1136/mx35/asm-offsets.c
b/arch/arm/cpu/arm1136/mx35/asm-offsets.c
deleted file mode 100644
index ebd7575..000
--- a/arch/arm/cpu/arm1136/mx35/asm-offsets.c
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * Adapted from Linux v2.6.36 kernel: arch/powerpc/kernel/asm-offsets.c
- *
- * This program is used to generate definitions needed by
- * assembly language modules.
- *
- * We use the technique used in the OSF Mach kernel code:
- * generate asm statements containing #defines,
- * compile this file to assembler, and then extract the
- * #defines from the assembly-language output.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include common.h
-#include asm/arch/imx-regs.h
-
-#include linux/kbuild.h
-
-int main(void)
-{
- /* Round up to make sure size gives nice stack alignment */
- DEFINE(CLKCTL_CCMR, offsetof(struct ccm_regs, ccmr));
- DEFINE(CLKCTL_PDR0, offsetof(struct ccm_regs, pdr0));
- DEFINE(CLKCTL_PDR1, offsetof(struct ccm_regs, pdr1));
- DEFINE(CLKCTL_PDR2, offsetof(struct ccm_regs, pdr2));
- DEFINE(CLKCTL_PDR3, offsetof(struct ccm_regs, pdr3));
- DEFINE(CLKCTL_PDR4, offsetof(struct ccm_regs, pdr4));
- DEFINE(CLKCTL_RCSR, offsetof(struct ccm_regs, rcsr));
- DEFINE(CLKCTL_MPCTL, offsetof(struct ccm_regs, mpctl));
- DEFINE(CLKCTL_PPCTL, offsetof(struct ccm_regs, ppctl));
- DEFINE(CLKCTL_ACMR, offsetof(struct ccm_regs, acmr));
-
Re: [U-Boot] [PATCH u-boot sunxi 07/12] sunxi: Add i2c support
Hello Hans,
Am 18.03.2014 00:00, schrieb Hans de Goede:
From: Henrik Nordstromhen...@henriknordstrom.net
Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in
ldscripts vs v2014.01.
As well as the following signed-off-by the sunxi branch shows commits to
the sunxi_i2c.c file by:
Stefan Roeses...@denx.de
Signed-off-by: Henrik Nordstromhen...@henriknordstrom.net
Signed-off-by: Oliver Schinagloli...@schinagl.nl
Signed-off-by: Hans de Goedehdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/board.c | 6 +
arch/arm/include/asm/arch-sunxi/i2c.h | 169 ++
drivers/i2c/Makefile | 1 +
drivers/i2c/sunxi_i2c.c | 260 ++
include/configs/sunxi-common.h| 8 ++
5 files changed, 444 insertions(+)
create mode 100644 arch/arm/include/asm/arch-sunxi/i2c.h
create mode 100644 drivers/i2c/sunxi_i2c.c
[...]
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index fa3a875..2a44db4 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o
obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
obj-$(CONFIG_U8500_I2C) += u8500_i2c.o
obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
+obj-$(CONFIG_SUNXI_I2C) += sunxi_i2c.o
please use:
CONFIG_SYS_I2C_SUNXI
obj-$(CONFIG_SYS_I2C) += i2c_core.o
obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
obj-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o
diff --git a/drivers/i2c/sunxi_i2c.c b/drivers/i2c/sunxi_i2c.c
new file mode 100644
index 000..9a542f6
--- /dev/null
+++ b/drivers/i2c/sunxi_i2c.c
@@ -0,0 +1,260 @@
+/*
+ * (C) Copyright 2012 Henrik Nordstromhen...@henriknordstrom.net
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#includecommon.h
+#includei2c.h
+#includeasm/io.h
+#includeasm/arch/clock.h
+#includeasm/arch/cpu.h
+#includeasm/arch/gpio.h
+#includeasm/arch/i2c.h
+
+static struct i2c __attribute__ ((section(.data))) *i2c_base =
+ (struct i2c *)0x1c2ac00;
Please no magic numbers, use a define instead.
+void i2c_init(int speed, int slaveaddr)
[...]
+int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len)
+{
+ int rc = i2c_do_write(chip, addr, alen, buffer, len);
+
+ i2c_stop();
+
+ return rc;
+}
Please update to the new i2c multibus/multiadpater framework
Dummy question, there is another twi driver in drivers/i2c
bfin-twi_i2c.c
are they compatible?
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index fe41b89..1f2bcb5 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -176,6 +176,14 @@
#undef CONFIG_CMD_NET
#undef CONFIG_CMD_NFS
+/* I2C */
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SYS_I2C_SPEED 40
+#define CONFIG_HARD_I2C
NACK, please use no longer HARD_I2C, switch instead to
CONFIG_SYS_I2C
+#define CONFIG_SUNXI_I2C
+#define CONFIG_SYS_I2C_SLAVE 0x7f
+#define CONFIG_CMD_I2C
+
#ifndef CONFIG_CONS_INDEX
#define CONFIG_CONS_INDEX 1 /* UART0 */
#endif
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH v1 8/9] sunxi: non-FEL SPL boot support for sun7i
On Mon, Mar 17, 2014 at 03:33:19PM -0400, Tom Rini wrote: On Sun, Mar 16, 2014 at 03:19:40PM +, Ian Campbell wrote: On Fri, 2014-03-14 at 15:03 -0400, Tom Rini wrote: On 03/14/2014 02:50 PM, Hans de Goede wrote: Hi, On 03/14/2014 03:17 PM, Tom Rini wrote: On Fri, Mar 14, 2014 at 10:33:50AM +, Ian Campbell wrote: Based linux-sunxi#sunxi commit d854c4de2f57 arm: Handle .gnu.hash section in ldscripts vs v2014.01. [snip] +/* Flat Device Tree (FDT/DT) support */ +#define CONFIG_OF_LIBFDT +#define CONFIG_SYS_BOOTMAPSZ (16 20) This seems pretty small. This is to keep things from being relocated into highmem right? Hmm, this reminds me that we currently need to do a env set fdt_high in our boot scripts to get ftd to work at all. Would be nice to fix this for upstream. I'm afraid I'm clueless as to why we (sunxi) need it, but we do. You want to be setting bootm_low (even for bootz, it's about the underlying boot mechanics that bootz and bootelf and ... hook into) to the amount of lowmem the kernel will have. We do this because we do want to make sure that the device tree isn't overwritten by the kernel BSS or similar. Everyone with more DDR than kernel lowmem needs to be doing something along these lines. So, I'm confused about what to do here ;-) And I've not made things clearer with a mis-recollection of things. I don't know why I keep saying bootm_low when I mean bootm_size like I've done in later patches (and thankfully, when poking people on G+). There's three ways to say Please ensure that the FDT and if passed initrd do not relocate above a certain location. 1) In the environment, set bootm_size to kernel lowmem. This means that boot_start_lmb restricts the pool used by both fdt and initrd to that value at the top. 2) In the environment, set fdt_high (and if using initrd, initrd_high) to the top of lowmem. This means that we'll make sure they don't get relocated above that value. 3) In the environment set initrd_high to top of lowmem and set bootm_mapsize to lowmem. In all of the above, lowmem can be replaced with any valid size that's also smaller than lowmem, such as 256MB. Another option, in the environment, is to set initrd_high and fdt_high to 0x and then relocation is disabled. I would _not_ recommend this in the general case as one of the points of relocation is to ensure we don't get overwritten by the kernel BSS. IIRC, we added it not to make sure that it was in lowmem, but because we had issues with large enough kernels (multi_v7_defconfig + embedded initramfs) that would overwrite the relocated DTB whenever it was decompressing itself. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com 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 2/2] powerpc/t1042RDB: Add Video - HDMI support
Dear dongsheng.w...@freescale.com, In message 0439833dfb0d4822adb75892e8d16...@bn1pr03mb188.namprd03.prod.outlook.com you wrote: @@ -352,12 +354,27 @@ #define CONFIG_SYS_NS16550_COM3 (CONFIG_SYS_CCSRBAR+0x11D500) #define CONFIG_SYS_NS16550_COM4 (CONFIG_SYS_CCSRBAR+0x11D600) #define CONFIG_SERIAL_MULTI /* Enable both serial ports */ -#define CONFIG_SYS_CONSOLE_IS_IN_ENV /* determine from environment */ This appears to be an unrelated change? If we get this MARCO, the console will not display on VIDEO. So we need to remove this MARCO. Removing this macros has actually other effects, too. Please read the doc in the README. Of course we can also through the environment variable to change. I think you actually only want to change your environment settings, but leave this macro in place. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Antw: Re: U-Boot doesn't silent the output
CONFIG_BOOTCOMMAND is not the build-in environment. See CONFIG_EXTRA_ENV_SETTINGS. Now that I'll have in the board header file the lines #define CONFIG_EXTRA_ENV_SETTINGS \ silent=1\0 and it works :) I really feel happy about this, thanks for your help! The output is disabled during U-Boot sequence, but returns when the kernel starts. I didn't expected that Linux is not influenced by this, but it's alright ATM. Anyway I wonder why the setenv verify n worked with the BOOTCOMMAND but the silent didn't. Should I shift all the commands from CONFIG_BOOTCOMMAND to CONFIG_EXTRA_ENV_SETTINGS to be sure all the commands are really executed? Do you see that in the Linux command line on boot? Yes the kernel command line is shown during boot, including the console= or console=null. Maybe the kernel version 2.6.39 is just too old for that feature. I doubt it - that feature has been there forever. I really don't know the reason why Linux keeps talking during boot when using console=, whereas quiet and changing the loglevel is working. I already asked in some forums about this, but it was as strange to them as it is to me - strange because it's a vanilla kernel I'm using, so the only thing that came to my mind is that this function is just not included into v. 2.6.3.9. Thanks again for your help! Kind Regards Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antw: Re: U-Boot doesn't silent the output
Dear Frank, In message 532816e002460004b...@gwia2.rz.hs-offenburg.de you wrote: Anyway I wonder why the setenv verify n worked with the BOOTCOMMAND but the silent didn't. Should I shift all the commands from CONFIG_BOOTCOMMAND to CONFIG_EXTRA_ENV_SETTINGS to be sure all the commands are really executed? I think you should try to get a deeper understanding of what is what. first, it is important to remember that there are two different sets of environment variables. With all the CONFIG_ settings you define only the _default_ environment, which gets used as a default (hence the name) only when the normale environment does not exist or is not valid (like corrupted checksum). So as long as you have a valid environment stored somewhere on your system, installing a new U-Boot with different settings of the default environment will have zero effect. Second, CONFIG_BOOTCOMMAND defines exactly one environment variable, bootcmd. As documented, the values of this variable is apssed to the Linux kernel as boot argument - and this is the only function of this variable. You can add random things to it, even U-Boot commands, but this will never have any effect on the operation of U-Boot - it might only consfuse the Linux kernel. I really don't know the reason why Linux keeps talking during boot when using console=, whereas quiet and changing the loglevel is working. I already asked in some forums about this, but it was as What exactly did you pass in the kernel command line - just console=, i. e. without a value? Did you try passing a valid device name instead, like console=null? Also, are you sure early debug output is disabled in your kernel configuration? Otherwise this will get printed even before the Linux kernel's console driver has been started. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de As of 1992, they're called European Economic Community fries. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] mmc:eSDHC: Workaround for data timeout issue on Txxx SoC
1. The Data timeout counter value in eSDHC_SYSCTL register is not working as it should be, so add quirks to enable this workaround to fix it to the max value 0xE. 2. For eSDHC the Block Count size each transmission should not exceed 0x blocks, Fix b_max to 0x to limit the transfer size for read and write command. 3. Add CONFIG_SYS_FSL_ERRATUM_ESDHC111 to enable its workaround. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- changes for V2 - Rewrite the comments. arch/powerpc/include/asm/config_mpc85xx.h | 5 + drivers/mmc/fsl_esdhc.c | 5 - 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 9a20b97..df44451 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -734,6 +734,8 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022) #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY #define CONFIG_SYS_FSL_ERRATUM_A006261 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111 +#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE #elif defined(CONFIG_PPC_T2080) || defined(CONFIG_PPC_T2081) #define CONFIG_E6500 @@ -778,6 +780,9 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022) #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 #define CONFIG_SYS_FSL_SFP_VER_3_0 #define CONFIG_SYS_FSL_ISBC_VER2 +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111 +#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE + #elif defined(CONFIG_PPC_C29X) #define CONFIG_MAX_CPUS1 diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 7b146a3..e888079 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -244,6 +244,9 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data) timeout++; #endif +#ifdef ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE + timeout = 0xE; +#endif esdhc_clrsetbits32(regs-sysctl, SYSCTL_TIMEOUT_MASK, timeout 16); return 0; @@ -604,7 +607,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg) mmc-f_min = 40; mmc-f_max = MIN(gd-arch.sdhc_clk, 5200); - mmc-b_max = 0; + mmc-b_max = 0x; mmc_register(mmc); return 0; -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Antw: Re: U-Boot doesn't silent the output
Wolfgang Denk 18.03.14 10.05 Uhr Dear Frank, In message 532816e002460004b...@gwia2.rz.hs-offenburg.de you wrote: Anyway I wonder why the setenv verify n worked with the BOOTCOMMAND but the silent didn't. Should I shift all the commands from CONFIG_BOOTCOMMAND to CONFIG_EXTRA_ENV_SETTINGS to be sure all the commands are really executed? I think you should try to get a deeper understanding of what is what. first, it is important to remember that there are two different sets of environment variables. With all the CONFIG_ settings you define only the _default_ environment, which gets used as a default (hence the name) only when the normale environment does not exist or is not valid (like corrupted checksum). So as long as you have a valid environment stored somewhere on your system, installing a new U-Boot with different settings of the default environment will have zero effect. Thanks for the advise, I'll have a closer look ASAP. The way I got into this U-Boot 2010.06 was: I used an already existing board header file (that was not a standard U-Boot board header file) and that's how it was implemented there. Second, CONFIG_BOOTCOMMAND defines exactly one environment variable, bootcmd. As documented, the values of this variable is apssed to the Linux kernel as boot argument - and this is the only function of this variable. You can add random things to it, even U-Boot commands, but this will never have any effect on the operation of U-Boot - it might only consfuse the Linux kernel. Well the variables I pass to the kernel command line are stored not in the CONFIG_BOOTCOMMAND, but in the CONFIG_BOOTARGS. When checking the kernel command line during boot, it is the same like the one defined in the BOOTARGS. In that mentioned header file, with what I started U-Boot, there are commands in the CONFIG_BOOTCOMMAND like nand write, tftp, setenv ipaddr etc. - since those are the commands from the U-Boot menu on target, I thought enqueuing the BOOTCOMMAND with silent, or verify would work too, though verify worked this way (a recognizable boot time was decreased). I really don't know the reason why Linux keeps talking during boot when using console=, whereas quiet and changing the loglevel is working. I already asked in some forums about this, but it was as What exactly did you pass in the kernel command line - just console=, i. e. without a value? Did you try passing a valid device name instead, like console=null? Yes I tried with console= and console=null. Also, are you sure early debug output is disabled in your kernel configuration? Otherwise this will get printed even before the Linux kernel's console driver has been started. If you mean the early printk then yes, otherwise I need more information what is meant by early debug output. Kind Regards, Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antw: Re: U-Boot doesn't silent the output
Dear Frank, In message 53281fb102460004b...@gwia2.rz.hs-offenburg.de you wrote: Second, CONFIG_BOOTCOMMAND defines exactly one environment variable, bootcmd. As documented, the values of this variable is apssed to the Linux kernel as boot argument - and this is the only function of this variable. You can add random things to it, even U-Boot commands, but this will never have any effect on the operation of U-Boot - it might only consfuse the Linux kernel. Well the variables I pass to the kernel command line are stored not in the CONFIG_BOOTCOMMAND, but in the CONFIG_BOOTARGS. When checking the kernel command line during boot, it is the same like the one defined in the BOOTARGS. oops. Sorry, of course you are right - I confused this. Guess I need more tea... In that mentioned header file, with what I started U-Boot, there are commands in the CONFIG_BOOTCOMMAND like nand write, tftp, setenv ipaddr etc. - since those are the commands from the U-Boot menu on target, I thought enqueuing the BOOTCOMMAND with silent, or verify would work too, though verify worked this way (a recognizable boot time was decreased). Again - CONFIG_BOOTCOMMAND affects only the default environment, it does not change the setting of the bootcmd variable in your normal environment. Also, are you sure early debug output is disabled in your kernel configuration? Otherwise this will get printed even before the Linux kernel's console driver has been started. If you mean the early printk then yes, otherwise I need more information what is meant by early debug output. Yes. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The price of success is hard work, dedication to the job at hand, and the determination that whether we win or lose, we have applied the best of ourselves to the task at hand. - Vince Lombardi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antw: Re: U-Boot doesn't silent the output
Hi Wolfgang, On 18 March 2014 09:03, Wolfgang Denk w...@denx.de wrote: What exactly did you pass in the kernel command line - just console=, i. e. without a value? Did you try passing a valid device name instead, like console=null? Apologies for hijacking this thread. If I remember, fixup_silent_linux ensures that 'console=' is present in the kernel arguments (i.e. it will replace console=/dev/ttyS0 (or similar) with console=). I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it? Thanks, Andrew Murray ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Antw: Re: U-Boot doesn't silent the output
I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it? Thanks, Andrew Murray Well let me tell you about the circumstances: I use these Images for an embedded system without any console at all, but of a serial debug port (for developing). So if the development phase is finished then I really need absolutely no output in any boot sequence or anytime later, since nobody will read it at all. Because, the actual aim: I want to have my system booting as fast as any possible, that means excluding all unused features (here: it's the output). Now, if you think the patch you mentioned could help me, by disabling all output but keep everything else in the same way as it was, then I would really appreciate that if you could share it. Thank you ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot sunxi 01/12] sunxi: Implement reset_cpu
On Tue, 2014-03-18 at 00:00 +0100, Hans de Goede wrote:
There is no way to reset the cpu, so use the watchdog for this.
Did you see
https://www.mail-archive.com/u-boot@lists.denx.de/msg134259.html ?
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/cpu/armv7/sunxi/board.c| 7 +++
arch/arm/include/asm/arch-sunxi/timer.h | 4
2 files changed, 11 insertions(+)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index e95f4e5..4fd5bcc 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -54,6 +54,13 @@ int gpio_init(void)
void reset_cpu(ulong addr)
{
+ static const struct sunxi_wdog *wdog =
+ ((struct sunxi_timer_reg *)SUNXI_TIMER_BASE)-wdog;
+
+ /* Set the watchdog for its shortest interval (.5s) and wait */
+ writel(WDT_MODE_RESET_EN | WDT_MODE_EN, wdog-mode);
+ writel(WDT_CTRL_RESTART, wdog-ctl);
+ while (1);
}
/* do some early init */
diff --git a/arch/arm/include/asm/arch-sunxi/timer.h
b/arch/arm/include/asm/arch-sunxi/timer.h
index 6aacfd7..c29d3a0 100644
--- a/arch/arm/include/asm/arch-sunxi/timer.h
+++ b/arch/arm/include/asm/arch-sunxi/timer.h
@@ -11,6 +11,10 @@
#ifndef _SUNXI_TIMER_H_
#define _SUNXI_TIMER_H_
+#define WDT_CTRL_RESTART(0x1 0)
+#define WDT_MODE_EN (0x1 0)
+#define WDT_MODE_RESET_EN (0x1 1)
+
#ifndef __ASSEMBLY__
#include linux/types.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fpga: zynqpl: Fixed bug in alignment routine
On 18/03/14 08:11, S Durga Prasad Paladugu wrote: This looks like not correct because if you look at the code above this, it always ensuring that the new aligned buffer start is in front of the actual buffer Maybe it should, but it doesn't. In the boot log it says: zynq_load: Align buffer at 10006f to 100080(swap 1) In fact, it makes sense to align upwards. Copying the buffer downwards would destroy the data in the beginning of the buffer. Not that it probably matters either way. Regards, Eli ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0
Hi, I am working on a board (AMOS820 from Via) based on the mx6qsabrelite. The BSP provided by the manufacturer is quite old. I managed to port it from Freescale uboot-imx rel_imx_3.0.35_4.1.0 to u-boot mainline, and basically the latest issue I have is the cpu frequency. The kernel I use is the rel_imx_3.0.35_4.1.0 as well (same tag name) With the old u-boot, it runs at 1Ghz because the BSP explicitly has a call to clk_config(CONFIG_REF_CLK_FREQ, 1000, CPU_CLK); With the new u-boot, it runs at default freq which is 800Mhz (at least, what I guess from the Bogomips because no other log says it) I have attempted to pass arm_freq=1000 to the boot args but that does not change anything. My concern is that clk_config does not seem to be available anymore, there is get_mcu_main_clk but no set routine. I wonder if it is intentional, I could write a set routine but I wonder if it could be accepted as a patch. What it your advice about it ? Regards Thierry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antw: Re: U-Boot doesn't silent the output
Dear Andrew, In message capcvp5fnjo9y3mkhudgar1jx0tfhkexu06bbtg5nccsq3wb...@mail.gmail.com you wrote: If I remember, fixup_silent_linux ensures that 'console=' is present in the kernel arguments (i.e. it will replace console=/dev/ttyS0 (or similar) with console=). I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it? I have to admit that I don't know if this is a good idea. I do know that some users use this feature to make sure the console port is completely free, and no characters ever are sent to it, for example because they use it for application specific purposes. Of course one might ask if this is a good idea (IMO a separate console port is a very useful feature), but you know how some companies design their hardware... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Is there a way to determine Yesterday's date using Unix utilities? echo what is yesterday's date? | /bin/mail root -- Randal L. Schwartz in ukbuh2y982@julie.teleport.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?
Hello again, I recently wrote an E-Mail about silenting the output during the U-Boot sequence, but I thougt it's better to open up a new thread. BTW this is not a problem, I just want to know. I realized a behavior of U-Boot, which isn't quiet clear to me. I have an ARM9 SAM9G25, that has this boot sequence: AT91Bootstrap - U-Boot 2010.06 - Linux 2.6.39. With that system I did 4 Test series about silencing the U-Boot output: - An image with U-Boot output, without network support in U-Boot - takes about 10.6 s to boot. - An image like above, but without U-Boot output - takes about 10.4 s to boot. -- 200 ms gained - An image with U-Boot output, with network support in U-Boot- takes 12.30 s - An image without U-Boot output, but with network support in U-Boot takes 12.30 s too. -- 0 ms gained Now why is it, when I disable the output, the time stays the same with network support, but around 200 ms are saved without the network? One thing that comes to my mind U-Boot doing its jobs in parallel, is that true? Since there's a waiting when initializing the network there's enough time to do the output ? Kind Regards Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?
Dear Frank, In message 53283ca402460004b...@gwia2.rz.hs-offenburg.de you wrote: I realized a behavior of U-Boot, which isn't quiet clear to me. I have an ARM9 SAM9G25, that has this boot sequence: AT91Bootstrap - U-Boot 2010.06 - Linux 2.6.39. With that system I did 4 Test series about silencing the U-Boot output: Q1: why are you using so old software? Q2: Do you actually have a plan for your optimizations, or are you just poking around at random? - An image with U-Boot output, without network support in U-Boot - takes about 10.6 s to boot. - An image like above, but without U-Boot output - takes about 10.4 s to boot. -- 200 ms gained I think it makes little sense to optimize the small parts - like some 200 ms here - when you appear to ignore the big chunks: a total of 10 seconds appears to be way too much. Did you a profiling of the boot process, so you can really focus on the big fish? Now why is it, when I disable the output, the time stays the same with network support, but around 200 ms are saved without the network? One thing that comes to my mind U-Boot doing its jobs in parallel, is that true? Since there's a waiting when initializing the network there's enough time to do the output ? We cannot comment on this, as we have no idea what your tests actually are, and what exactly you mean by with or without network support. the general rule is that U-Boot is strictly single-tasking, i. e. there are no actions running in parallel. If you are interested in short boot times you should look into using the SPL with Falcon mode instead. Heiko Schocher has some patches in the works to do this for the AT91SAM9G20 - here we do not need any Atmel code any more; we boot directly into SPL. So you could use Falcon mode and load Linux directly from the SPL. But of course none of this is present with an ancient v2010.06 U-Boot... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Science makes godlike -- it is all over with priests and gods when man becomes scientific. Moral: science is the forbidden as such -- it alone is forbidden. Science is the *first* sin, the *original* sin. *This alone is morality.* ``Thou shalt not know'' -- the rest follows. - Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
On Tuesday, March 18, 2014 at 07:55:04 AM, Lukasz Majewski wrote:
Hi Heiko,
Hello Marek,
Am 18.03.2014 01:21, schrieb Marek Vasut:
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocherh...@denx.de
Cc: Lukasz Majewskil.majew...@samsung.com
Cc: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Marek Vasutma...@denx.de
Cc: Pantelis Antonioupa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void
*buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
-/* Now try and flush to the medium if needed. */
-if (dfu-flush_medium)
-ret = dfu-flush_medium(dfu);
-printf(\nDFU complete CRC32: 0x%08x\n,
dfu-crc); -
-/* clear everything */
-dfu_free_buf();
-dfu-crc = 0;
-dfu-offset = 0;
-dfu-i_blk_seq_num = 0;
-dfu-i_buf_start = dfu_buf;
-dfu-i_buf_end = dfu_buf;
-dfu-i_buf = dfu-i_buf_start;
-
-dfu-inited = 0;
-
-}
+ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened
brace (see 'if (size == 0) {' I can fix this up when applying.
Argh... you are right patch 2/3 of this series deletes the
complete if ... I can send a new version, but if you want to fix
it that would be great!
In this case, please prepare v3.
Do you want this in 2014.04 or in -next ?
Hmm.. 2014.04 would be nice, but I think this is Lukasz decision,
because I changed the dfu state machine, and maybe he want to see
more tests?
When you send the v3, I will test it for regression and then I will
prepare pull request to Tom for v2014.04.
Those patches will be added to u-boot-dfu repository.
Feel free to test u-boot-usb/master please.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
On Tuesday, March 18, 2014 at 07:02:59 AM, Heiko Schocher wrote:
Hello Marek,
Am 18.03.2014 01:21, schrieb Marek Vasut:
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocherh...@denx.de
Cc: Lukasz Majewskil.majew...@samsung.com
Cc: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Marek Vasutma...@denx.de
Cc: Pantelis Antonioupa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
-
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened brace
(see 'if (size == 0) {' I can fix this up when applying.
Argh... you are right patch 2/3 of this series deletes the
complete if ... I can send a new version, but if you want to fix
it that would be great!
OK, fixed up.
Do you want this in 2014.04 or in -next ?
Hmm.. 2014.04 would be nice, but I think this is Lukasz decision,
because I changed the dfu state machine, and maybe he want to see
more tests?
OK, let's see.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
On Tuesday, March 18, 2014 at 07:51:05 AM, Lukasz Majewski wrote:
Hi Marek,
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void
*buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n, dfu-crc);
-
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened brace
(see 'if (size == 0) {' I can fix this up when applying.
I was prepared to pull those patches to u-boot-dfu repo today and test
them :-).
Afterwards, I would send PR to Tom.
Are you OK with this?
Doesn't -dfu go through -usb ? ;-) Or do you want to send to Tom directly ?
Either way WFM. Nonetheless, I picked the patches via -usb, they're in master
now.
Do you want this in 2014.04 or in -next ?
After testing I would go for 2014.04, if Tom doesn't mind. All in all
it fixes the DFU state machine - by adding missing states. Up till
now we had short cut in the DFU state machine.
OK
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fpga: zynqpl: Fixed bug in alignment routine
On 03/18/2014 11:20 AM, Eli Billauer wrote:
On 18/03/14 08:11, S Durga Prasad Paladugu wrote:
This looks like not correct because if you look at the code above this, it
always ensuring that the new aligned buffer start is in front of the actual
buffer
Maybe it should, but it doesn't. In the boot log it says:
zynq_load: Align buffer at 10006f to 100080(swap 1)
I have checked this and there is bug in code.
I have tested it by:
+ int i;
+
+ for (i = 0; i 100; i++) {
+ printf(%x: align %x\n, i, ALIGN((u32)i, ARCH_DMA_MINALIGN));
+ }
Does this work for you? If yes, I will send this as regular patch.
diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index 3572bc9..49eef0f 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -289,10 +289,11 @@ static int zynq_dma_xfer_init(u32 partialbit)
static u32 *zynq_align_dma_buffer(u32 *buf, u32 len, u32 swap)
{
u32 *new_buf;
- u32 i;
+ u32 i, align;
- if ((u32)buf != ALIGN((u32)buf, ARCH_DMA_MINALIGN)) {
- new_buf = (u32 *)ALIGN((u32)buf, ARCH_DMA_MINALIGN);
+ align = ALIGN((u32)(buf - ARCH_DMA_MINALIGN + 1), ARCH_DMA_MINALIGN);
+ if ((u32)buf != align) {
+ new_buf = (u32 *)align;
/*
* This might be dangerous but permits to flash if
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?
In message 53283ca402460004b...@gwia2.rz.hs-offenburg.de you wrote: I realized a behavior of U-Boot, which isn't quiet clear to me. I have an ARM9 SAM9G25, that has this boot sequence: AT91Bootstrap - U-Boot 2010.06 - Linux 2.6.39. With that system I did 4 Test series about silencing the U-Boot output: Q1: why are you using so old software? Because of some patches it's a big job to switch to a newer one. Q2: Do you actually have a plan for your optimizations, or are you just poking around at random? It's not poking around, the aim is to see what effects do some options really (atomically) have. I'm doing many measurements and always compared with a Buildroot defconfig that takes time around 10.6 s time from Bootloader to Userland. - An image with U-Boot output, without network support in U-Boot - takes about 10.6 s to boot. - An image like above, but without U-Boot output - takes about 10.4 s to boot. -- 200 ms gained I think it makes little sense to optimize the small parts - like some 200 ms here - when you appear to ignore the big chunks: a total of 10 seconds appears to be way too much. Did you a profiling of the boot process, so you can really focus on the big fish? As mentioned above this is just one options of many I've tried, I already managed to boot the system in about 3-4 s (which now should be even less after I removed some further options). I know the silent option is more like out of a option group that gains the last 10 % of speed. Now why is it, when I disable the output, the time stays the same with network support, but around 200 ms are saved without the network? One thing that comes to my mind U-Boot doing its jobs in parallel, is that true? Since there's a waiting when initializing the network there's enough time to do the output ? We cannot comment on this, as we have no idea what your tests actually are, and what exactly you mean by with or without network support. the general rule is that U-Boot is strictly single-tasking, i. e. there are no actions running in parallel. I understand, well this is not a problem, I just like to explain the behavior. In case of interest here is how the network is enabled with the following commands #define CONFIG_MACB1 #define CONFIG_RMII1 #define CONFIG_NET_MULTI1 #define CONFIG_NET_RETRY_COUNT20 #define CONFIG_RESET_PHY_R1 and is disabled with removing the lines above and setting #undef CONFIG_CMD_NET If you are interested in short boot times you should look into using the SPL with Falcon mode instead. Heiko Schocher has some patches in the works to do this for the AT91SAM9G20 - here we do not need any Atmel code any more; we boot directly into SPL. So you could use Falcon mode and load Linux directly from the SPL. That sounds interesting, I'll search the Internet about this, thanks for the advice. But of course none of this is present with an ancient v2010.06 U-Boot... Yes, then it would be another reason to double up the almost 4 years of U-Boot development. Kind Regards Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0
Hi Thierry, On 18/03/2014 12:28, tbul...@free.fr wrote: Hi, I am working on a board (AMOS820 from Via) based on the mx6qsabrelite. The BSP provided by the manufacturer is quite old. I managed to port it from Freescale uboot-imx rel_imx_3.0.35_4.1.0 to u-boot mainline, and basically the latest issue I have is the cpu frequency. The kernel I use is the rel_imx_3.0.35_4.1.0 as well (same tag name) With the old u-boot, it runs at 1Ghz because the BSP explicitly has a call to clk_config(CONFIG_REF_CLK_FREQ, 1000, CPU_CLK); With the new u-boot, it runs at default freq which is 800Mhz (at least, what I guess from the Bogomips because no other log says it) It is can taken as reference, but checking the BogoMIPS is not the right way to proof it. You should take a look at the CCM registers when Linux is running ( CCM_ANALOG_PLL_ARM). I have attempted to pass arm_freq=1000 to the boot args but that does not change anything. Well, this is a kernel issue, and related to an ancient version. My concern is that clk_config does not seem to be available anymore, there is get_mcu_main_clk but no set routine. It was never available in mainline. I wonder if it is intentional, I could write a set routine but I wonder if it could be accepted as a patch. Why not ? All patches are discussed here and if it makes sense to merge it, it will be merged. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
Hi Marek,
On Tuesday, March 18, 2014 at 07:51:05 AM, Lukasz Majewski wrote:
Hi Marek,
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void
*buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if needed.
*/
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n,
dfu-crc); -
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened
brace (see 'if (size == 0) {' I can fix this up when
applying.
I was prepared to pull those patches to u-boot-dfu repo today and
test them :-).
Afterwards, I would send PR to Tom.
Are you OK with this?
Doesn't -dfu go through -usb ? ;-)
As fair as I remember the dfu code from ./drivers/dfu/* shall go via
u-boot-dfu tree directly to Tom.
Or do you want to send to Tom
directly ? Either way WFM.
After writing the other message you waited for a response less than one
minute :-).
Nonetheless, I picked the patches via
-usb, they're in master now.
I've just tested them and they doesn't cause any regression.
Would you be so kind and apply one more patch, which was supposed to
go with u-boot-dfu PR (this patch waits for submission from 21.02.2014)?
http://patchwork.ozlabs.org/patch/322450/
It is solely drivers/dfu/dfu_mmc.c related.
And I don't want to send PR to Tom with only one patch included.
Do you want this in 2014.04 or in -next ?
After testing I would go for 2014.04, if Tom doesn't mind. All in
all it fixes the DFU state machine - by adding missing states. Up
till now we had short cut in the DFU state machine.
OK
Best regards,
Marek Vasut
--
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
[U-Boot] [PATCH 1/4][v7] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
Changes:
1. L2 cache is being invalidated by Boot ROM code for e6500 core.
So removing the invalidation from start.S
2. Clear the LAW and corresponding configuration for CPC. Boot ROM
code uses it as hosekeeping area.
3. For Secure boot, CPC is configured as SRAM and used as house
keeping area. This configuration is to be disabled once in uboot.
Earlier this disabling of CPC as SRAM was happening in cpu_init_r.
As a result cache invalidation function was getting skipped in
case CPC is configured as SRAM.This was causing random crashes.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
---
README | 4
arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++-
arch/powerpc/cpu/mpc85xx/start.S | 3 ++-
arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++
boards.cfg | 1 +
5 files changed, 35 insertions(+), 6 deletions(-)
Changes in v7:
Created a patch set
diff --git a/README b/README
index 216f0c7..e574d68 100644
--- a/README
+++ b/README
@@ -427,6 +427,10 @@ The following options need to be configured:
In this mode, a single differential clock is used to supply
clocks to the sysclock, ddrclock and usbclock.
+ CONFIG_SYS_CPC_REINIT_F
+ This CONFIG is defined when the CPC is configured as SRAM at the
+ time of U-boot entry and is required to be re-initialized.
+
- Generic CPU options:
CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 81aeadd..570965f 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -173,17 +173,14 @@ void config_8560_ioports (volatile ccsr_cpm_t * cpm)
#endif
#ifdef CONFIG_SYS_FSL_CPC
-static void enable_cpc(void)
+#if defined(CONFIG_RAMBOOT_PBL) || defined(CONFIG_SYS_CPC_REINIT_F)
+static void disable_cpc_sram(void)
{
int i;
- u32 size = 0;
cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
for (i = 0; i CONFIG_SYS_NUM_CPC; i++, cpc++) {
- u32 cpccfg0 = in_be32(cpc-cpccfg0);
- size += CPC_CFG0_SZ_K(cpccfg0);
-#ifdef CONFIG_RAMBOOT_PBL
if (in_be32(cpc-cpcsrcr0) CPC_SRCR0_SRAMEN) {
/* find and disable LAW of SRAM */
struct law_entry law =
find_law(CONFIG_SYS_INIT_L3_ADDR);
@@ -198,8 +195,21 @@ static void enable_cpc(void)
out_be32(cpc-cpccsr0, 0);
out_be32(cpc-cpcsrcr0, 0);
}
+ }
+}
#endif
+static void enable_cpc(void)
+{
+ int i;
+ u32 size = 0;
+
+ cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
+
+ for (i = 0; i CONFIG_SYS_NUM_CPC; i++, cpc++) {
+ u32 cpccfg0 = in_be32(cpc-cpccfg0);
+ size += CPC_CFG0_SZ_K(cpccfg0);
+
#ifdef CONFIG_SYS_FSL_ERRATUM_CPC_A002
setbits_be32(cpc-cpchdbcr0, CPC_HDBCR0_TAG_ECC_SCRUB_DIS);
#endif
@@ -298,6 +308,10 @@ void cpu_init_f (void)
law = find_law(CONFIG_SYS_PBI_FLASH_BASE);
if (law.index != -1)
disable_law(law.index);
+
+#if defined(CONFIG_SYS_CPC_REINIT_F)
+ disable_cpc_sram();
+#endif
#endif
#ifdef CONFIG_CPM2
@@ -598,6 +612,9 @@ skip_l2:
puts(disabled\n);
#endif
+#if defined(CONFIG_RAMBOOT_PBL)
+ disable_cpc_sram();
+#endif
enable_cpc();
#ifndef CONFIG_SYS_FSL_NO_SERDES
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index dbbd8e5..4ef0985 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -115,7 +115,8 @@ _start_e500:
#endif
-#if defined(CONFIG_SECURE_BOOT) defined(CONFIG_E500MC)
+#if defined(CONFIG_SECURE_BOOT) defined(CONFIG_E500MC) \
+ !defined(CONFIG_E6500)
/* ISBC uses L2 as stack.
* Disable L2 cache here so that u-boot can enable it later
* as part of it's normal flow
diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h
b/arch/powerpc/include/asm/fsl_secure_boot.h
index 4c7f0b1..8f5bf10 100644
--- a/arch/powerpc/include/asm/fsl_secure_boot.h
+++ b/arch/powerpc/include/asm/fsl_secure_boot.h
@@ -15,5 +15,11 @@
#endif
#define CONFIG_SYS_PBI_FLASH_WINDOW0xcff8
+#if defined(CONFIG_B4860QDS)
+#define CONFIG_SYS_CPC_REINIT_F
+#undef CONFIG_SYS_INIT_L3_ADDR
+#define CONFIG_SYS_INIT_L3_ADDR0xbff0
+#endif
+
#endif
#endif
diff --git a/boards.cfg b/boards.cfg
index 69c8936..b2907fe 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -743,6 +743,7 @@ Active powerpc mpc85xx- freescale
b4860qds
Active powerpc mpc85xx- freescale b4860qds
B4420QDS_NAND
[U-Boot] [PATCH 2/4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for T4240QDS and T4160QDS
Secure Boot Target is added for T4240QDS and T4160QDS Changes: For Secure boot, CPC is configured as SRAM and used as house keeping area which needs to be disabled. So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T4240QDS. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- arch/powerpc/include/asm/fsl_secure_boot.h | 2 +- boards.cfg | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index 8f5bf10..ea1e7b9 100644 --- a/arch/powerpc/include/asm/fsl_secure_boot.h +++ b/arch/powerpc/include/asm/fsl_secure_boot.h @@ -15,7 +15,7 @@ #endif #define CONFIG_SYS_PBI_FLASH_WINDOW0xcff8 -#if defined(CONFIG_B4860QDS) +#if defined(CONFIG_B4860QDS) || defined(CONFIG_T4240QDS) #define CONFIG_SYS_CPC_REINIT_F #undef CONFIG_SYS_INIT_L3_ADDR #define CONFIG_SYS_INIT_L3_ADDR0xbff0 diff --git a/boards.cfg b/boards.cfg index b2907fe..a35eac1 100644 --- a/boards.cfg +++ b/boards.cfg @@ -951,10 +951,12 @@ Active powerpc mpc85xx- freescale t208xrdb Active powerpc mpc85xx- freescale t208xrdb T2080RDB_SPIFLASH T208xRDB:PPC_T2080,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t208xrdb T2080RDB_SRIO_PCIE_BOOT T208xRDB:PPC_T2080,SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t4qds T4160QDS T4240QDS:PPC_T4160 - +Active powerpc mpc85xx- freescale t4qds T4160QDS_SECURE_BOOT T4240QDS:PPC_T4160,SECURE_BOOT Aneesh Bansal aneesh.ban...@freescale.com Active powerpc mpc85xx- freescale t4qds T4160QDS_SDCARD T4240QDS:PPC_T4160,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t4qds T4160QDS_SPIFLASH T4240QDS:PPC_T4160,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t4qds T4240EMU T4240EMU:PPC_T4240 York Sun york...@freescale.com Active powerpc mpc85xx- freescale t4qds T4240QDS T4240QDS:PPC_T4240 - +Active powerpc mpc85xx- freescale t4qds T4240QDS_SECURE_BOOT T4240QDS:PPC_T4240,SECURE_BOOT Aneesh Bansal aneesh.ban...@freescale.com Active powerpc mpc85xx- freescale t4qds T4240QDS_NAND T4240QDS:PPC_T4240,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t4qds T4240QDS_SDCARD T4240QDS:PPC_T4240,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t4qds T4240QDS_SPIFLASH T4240QDS:PPC_T4240,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF4 - -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for T2080QDS
Secure Boot Target is added for T2080QDS Changes: For Secure boot, CPC is configured as SRAM and used as house keeping area which needs to be disabled. So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T2080QDS. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- arch/powerpc/include/asm/fsl_secure_boot.h | 4 +++- boards.cfg | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index ea1e7b9..e91d36b 100644 --- a/arch/powerpc/include/asm/fsl_secure_boot.h +++ b/arch/powerpc/include/asm/fsl_secure_boot.h @@ -15,7 +15,9 @@ #endif #define CONFIG_SYS_PBI_FLASH_WINDOW0xcff8 -#if defined(CONFIG_B4860QDS) || defined(CONFIG_T4240QDS) +#if defined(CONFIG_B4860QDS) || \ + defined(CONFIG_T4240QDS) || \ + defined(CONFIG_T2080QDS) #define CONFIG_SYS_CPC_REINIT_F #undef CONFIG_SYS_INIT_L3_ADDR #define CONFIG_SYS_INIT_L3_ADDR0xbff0 diff --git a/boards.cfg b/boards.cfg index a35eac1..62c0b58 100644 --- a/boards.cfg +++ b/boards.cfg @@ -936,6 +936,7 @@ Active powerpc mpc85xx- freescale t1040qds Active powerpc mpc85xx- freescale t104xrdb T1040RDB T1040RDB:PPC_T1040 Poonam Aggrwal poonam.aggr...@freescale.com Active powerpc mpc85xx- freescale t104xrdb T1042RDB_PI T1042RDB_PI:PPC_T1042 Poonam Aggrwal poonam.aggr...@freescale.com Active powerpc mpc85xx- freescale t208xqds T2080QDS T208xQDS:PPC_T2080 - +Active powerpc mpc85xx- freescale t208xqds T2080QDS_SECURE_BOOT T208xQDS:PPC_T2080,SECURE_BOOT Aneesh Bansal aneesh.ban...@freescale.com Active powerpc mpc85xx- freescale t208xqds T2080QDS_NAND T208xQDS:PPC_T2080,RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t208xqds T2080QDS_SDCARD T208xQDS:PPC_T2080,RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t208xqds T2080QDS_SPIFLASH T208xQDS:PPC_T2080,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF4 - -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antw: Re: U-Boot doesn't silent the output
On 18 March 2014 11:30, Wolfgang Denk w...@denx.de wrote: Dear Andrew, In message capcvp5fnjo9y3mkhudgar1jx0tfhkexu06bbtg5nccsq3wb...@mail.gmail.com you wrote: If I remember, fixup_silent_linux ensures that 'console=' is present in the kernel arguments (i.e. it will replace console=/dev/ttyS0 (or similar) with console=). I think preferred behavior for this may be to instead leave any 'console' arguments as they are and instead ensure that 'quiet' or 'loglevel=1' is present instead. There are two motivations for doing this - the first is that when using a lower loglevel you still get suppressed kernel output - but you also get any errors. Thus if something goes wrong you'll see why rather than wonder if U-Boot even started the kernel. The second is that I've seen a few times in the past where setting console to nothing (console=) results in strange behavior (it once increased boot time). After all we want a console we just don't want to use it as much. I can provide a patch for this if you think you may take it? I have to admit that I don't know if this is a good idea. I do know that some users use this feature to make sure the console port is completely free, and no characters ever are sent to it, for example because they use it for application specific purposes. Of course one might ask if this is a good idea (IMO a separate console port is a very useful feature), but you know how some companies design their hardware... Yes I can understand why they would want to do that. However I would argue that using the 'silent' feature isn't the correct way to achieve it. If a user depends on having a console completely free then they probably shouldn't add a 'console=xyz' to their boot args in the first place. Thanks, Andrew Murray ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for T1040QDS and T1040RDB
Secure Boot Target is added for T1040QDS and T1040RDB Changes: For Secure boot, CPC is configured as SRAM and used as house keeping area which needs to be disabled. So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T1040QDS and CONFIG_T1040RDB Signed-off-by: Gaurav Rana gaurav.r...@freescale.com Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- arch/powerpc/include/asm/fsl_secure_boot.h | 4 +++- boards.cfg | 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h b/arch/powerpc/include/asm/fsl_secure_boot.h index e91d36b..179bcff 100644 --- a/arch/powerpc/include/asm/fsl_secure_boot.h +++ b/arch/powerpc/include/asm/fsl_secure_boot.h @@ -17,7 +17,9 @@ #if defined(CONFIG_B4860QDS) || \ defined(CONFIG_T4240QDS) || \ - defined(CONFIG_T2080QDS) + defined(CONFIG_T2080QDS) || \ + defined(CONFIG_T1040QDS) || \ + defined(CONFIG_T1040RDB) #define CONFIG_SYS_CPC_REINIT_F #undef CONFIG_SYS_INIT_L3_ADDR #define CONFIG_SYS_INIT_L3_ADDR0xbff0 diff --git a/boards.cfg b/boards.cfg index 62c0b58..8938167 100644 --- a/boards.cfg +++ b/boards.cfg @@ -933,7 +933,9 @@ Active powerpc mpc85xx- freescale p2041rdb Active powerpc mpc85xx- freescale p2041rdb P2041RDB_SPIFLASH P2041RDB:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale p2041rdb P2041RDB_SRIO_PCIE_BOOT P2041RDB:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF4 - Active powerpc mpc85xx- freescale t1040qds T1040QDS T1040QDS:PPC_T1040 Poonam Aggrwal poonam.aggr...@freescale.com +Active powerpc mpc85xx- freescale t1040qds T1040QDS_SECURE_BOOT T1040QDS:PPC_T1040,SECURE_BOOT Aneesh Bansal aneesh.ban...@freescale.com Active powerpc mpc85xx- freescale t104xrdb T1040RDB T1040RDB:PPC_T1040 Poonam Aggrwal poonam.aggr...@freescale.com +Active powerpc mpc85xx- freescale t104xrdb T1040RDB_SECURE_BOOT T1040RDB:PPC_T1040,SECURE_BOOT Aneesh Bansal aneesh.ban...@freescale.com Active powerpc mpc85xx- freescale t104xrdb T1042RDB_PI T1042RDB_PI:PPC_T1042 Poonam Aggrwal poonam.aggr...@freescale.com Active powerpc mpc85xx- freescale t208xqds T2080QDS T208xQDS:PPC_T2080 - Active powerpc mpc85xx- freescale t208xqds T2080QDS_SECURE_BOOT T208xQDS:PPC_T2080,SECURE_BOOT Aneesh Bansal aneesh.ban...@freescale.com -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?
Dear Frank, In message 5328485c02460004b...@gwia2.rz.hs-offenburg.de you wrote: Q1: why are you using so old software? Because of some patches it's a big job to switch to a newer one. Well, you cut yourself off from all nice features present in more recent versions... Q2: Do you actually have a plan for your optimizations, or are you just poking around at random? It's not poking around, the aim is to see what effects do some options really (atomically) have. I'm doing many measurements and always compared with a Buildroot defconfig that takes time around 10.6 s time from Bootloader to Userland. I'm sorry, but I do call this poking around. When doing optimizations, you should always start with measuring the current state first. Only when you klnow exactly hoiw long each step of the boot process takes you can determine where it makes sense to spend efforts on the optimization. Saving 50% of the time sounds great, but it means nothing if it's for a step that contributes only 1% to the total boot time. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nobody trips over mountains. It is the small pebble that causes you to stumble. Pass all the pebbles in your path and you will find you have crossed the mountain. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antw: Re: U-Boot doesn't silent the output
Dear Andrew, In message capcvp5ekxdb_y16sym7x2cln67hbg4jt8jkos7n8+fsd8dr...@mail.gmail.com you wrote: However I would argue that using the 'silent' feature isn't the correct way to achieve it. If a user depends on having a console completely free then they probably shouldn't add a 'console=xyz' to their boot args in the first place. Even if it is console=null ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de NOTE: The Most Fundamental Particles in This Product Are Held Together by a Gluing Force About Which Little is Currently Known and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Antw: Re: U-Boot doesn't silent the output
On 18 March 2014 14:17, Wolfgang Denk w...@denx.de wrote: Dear Andrew, In message capcvp5ekxdb_y16sym7x2cln67hbg4jt8jkos7n8+fsd8dr...@mail.gmail.com you wrote: However I would argue that using the 'silent' feature isn't the correct way to achieve it. If a user depends on having a console completely free then they probably shouldn't add a 'console=xyz' to their boot args in the first place. Even if it is console=null ? If it is 'console=null' (which as you point out would be sensible), then the existing 'silent' feature will change that to 'console=' (which shouldn't ought to make a difference anyway). Where a user has 'console=null' in their bootargs, then my console would turn that into 'console=null loglevel=1' rather that the present which would be 'console='. Thanks, Andrew Murray ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] _POST_WORD_ADDR for ARM
Hi, On 18 March 2014 00:21, shobin b shobin...@gmail.com wrote: Hi, How can we define _POST_WORD_ADDR for ARM.In case enabling post for arm on post.h how can i define _POST_WORD_ADDR. how it is defined in other platform.please tell me the logic behind _POST_WORD_ADDR. From the README: - CONFIG_SYS_CPM_POST_WORD_ADDR: (MPC8xx, MPC8260 only) Offset of the bootmode word in DPRAM used by post (Power On Self Tests). This definition overrides #define'd default value in commproc.h resp. cpm_8260.h. I think you asked this question before. You should explain what you want this feature to do, what board you are using, where you have already looked for information, etc. People are much more likely to respond if you provide a bit of context. Also I think I did already reply and point to the bootstage feature and show_boot_progress()? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] During boot is U-Boot doing its jobs sequentially or in parallel?
Dear Frank Ihle, On 18.03.14 13:21, Frank Ihle wrote: In message 53283ca402460004b...@gwia2.rz.hs-offenburg.de you wrote: I realized a behavior of U-Boot, which isn't quiet clear to me. I have an ARM9 SAM9G25, that has this boot sequence: AT91Bootstrap - U-Boot 2010.06 - Linux 2.6.39. With that system I did 4 Test series about silencing the U-Boot output: Q1: why are you using so old software? Because of some patches it's a big job to switch to a newer one. you should really consider updating your patches to current TOT and maybe bring them mainline to avoid further efforts in future. I recently attended Markus Hubig bringing Taskit's stamp9g20 mainline which was also based on some ancient U-Boot version. This was within his final paper where he also had to work on some other tasks I do not know of. He started somewhere in July 2012 by reading U-boot code and understand the concepts and brought his first patch beginning of August 2012 which where in mainline some days later then. Q2: Do you actually have a plan for your optimizations, or are you just poking around at random? It's not poking around, the aim is to see what effects do some options really (atomically) have. I'm doing many measurements and always compared with a Buildroot defconfig that takes time around 10.6 s time from Bootloader to Userland. - An image with U-Boot output, without network support in U-Boot - takes about 10.6 s to boot. - An image like above, but without U-Boot output - takes about 10.4 s to boot. -- 200 ms gained I think it makes little sense to optimize the small parts - like some 200 ms here - when you appear to ignore the big chunks: a total of 10 seconds appears to be way too much. Did you a profiling of the boot process, so you can really focus on the big fish? As mentioned above this is just one options of many I've tried, I already managed to boot the system in about 3-4 s (which now should be even less after I removed some further options). I know the silent option is more like out of a option group that gains the last 10 % of speed. Now why is it, when I disable the output, the time stays the same with network support, but around 200 ms are saved without the network? One thing that comes to my mind U-Boot doing its jobs in parallel, is that true? Since there's a waiting when initializing the network there's enough time to do the output ? We cannot comment on this, as we have no idea what your tests actually are, and what exactly you mean by with or without network support. the general rule is that U-Boot is strictly single-tasking, i. e. there are no actions running in parallel. I understand, well this is not a problem, I just like to explain the behavior. In case of interest here is how the network is enabled with the following commands #define CONFIG_MACB1 #define CONFIG_RMII1 #define CONFIG_NET_MULTI1 #define CONFIG_NET_RETRY_COUNT20 #define CONFIG_RESET_PHY_R1 Most Atmel boards implement PHY reset by pulling the N_RST line for 200 to 500 ms. That could be your 200 ms boot-time saving without network support. I personally think the implemented PHY reset isn't necessary in most cases. The POR should be sufficient if the required I/O lines have the correct level at that time to configure the PHY correctly. However the software controlled PHY reset afterwards is required for some specific boards with weak pull-up/-down which are still in the field (some rev A eval boards). The mechanism is copied to some boards which may not need it then. and is disabled with removing the lines above and setting #undef CONFIG_CMD_NET I believe this specific change is not required for saving the mentioned 200ms. If you are interested in short boot times you should look into using the SPL with Falcon mode instead. Heiko Schocher has some patches in the works to do this for the AT91SAM9G20 - here we do not need any Atmel code any more; we boot directly into SPL. So you could use Falcon mode and load Linux directly from the SPL. That sounds interesting, I'll search the Internet about this, thanks for the advice. Heiko hasn't sent his patches publicly yet AFAIK. I have some pre-version here, but they will not apply on current TOT and never on 2010.06. 2014.04 will be the first version with full SPL support for the first Atmel device (sama5d3xek). 2014.01 had support for MMC boot on that board, 2014.04 will add support for NAND and dataflash boot. Adding SPL for the other at91 is on my list, I still failed to get some time for that since last Christmas :( But there are some other boards using Atmel SoC mainlined these days (especially the siemens boards finished by Heiko), so I think we'll get basic SPL support for the at91sam9g SoC's soon. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
On Tuesday, March 18, 2014 at 01:35:47 PM, Lukasz Majewski wrote:
Hi Marek,
On Tuesday, March 18, 2014 at 07:51:05 AM, Lukasz Majewski wrote:
Hi Marek,
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu, void
*buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if needed.
*/
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n,
dfu-crc); -
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size, blk_seq_num);
This seems broken, at least because you didn't close the opened
brace (see 'if (size == 0) {' I can fix this up when
applying.
I was prepared to pull those patches to u-boot-dfu repo today and
test them :-).
Afterwards, I would send PR to Tom.
Are you OK with this?
Doesn't -dfu go through -usb ? ;-)
As fair as I remember the dfu code from ./drivers/dfu/* shall go via
u-boot-dfu tree directly to Tom.
Or do you want to send to Tom
directly ? Either way WFM.
After writing the other message you waited for a response less than one
minute :-).
Nonetheless, I picked the patches via
-usb, they're in master now.
I've just tested them and they doesn't cause any regression.
Would you be so kind and apply one more patch, which was supposed to
go with u-boot-dfu PR (this patch waits for submission from 21.02.2014)?
http://patchwork.ozlabs.org/patch/322450/
OK, picked and pushed. I think panto picked it up as well tho, but maybe I
unleashed too much mental terror unto him with my OvisLink WL-1100SD that he is
paralyzed by it ;-) Panto, I will pick this patch, OK ?
As for the DFU, what do we do about the PRs ? DFU is part of USB, so I shall
logically pick the PRs from you and move them to trini, but if you're unhappy
about this, we need to talk about that. Tom, Lukasz ... thoughts ?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] build:arm: Remove setting of CROSS_COMPILE environment variable
After Kbuild introduction, the CROSS_COMPILE environment variable has been set to some default value (prefix arm-linux-). This shall be removed since it breaks building u-boot for native arm target (like qemu ARM). Moreover not all compilers have arm-linux- prefix. Additionally the u-boot cross compiles with CROSS_COMPILE= set explicitly- e.g.: CROSS_COMPILE=/ /arm-v7a-linux-gnueabi- make Signed-off-by: Lukasz Majewski l.majew...@samsung.com Cc: Masahiro Yamada yamad...@jp.panasonic.com --- arch/arm/config.mk |4 1 file changed, 4 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f4c2d81..178a59a 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -5,10 +5,6 @@ # SPDX-License-Identifier: GPL-2.0+ # -ifeq ($(CROSS_COMPILE),) -CROSS_COMPILE := arm-linux- -endif - ifndef CONFIG_STANDALONE_LOAD_ADDR ifneq ($(CONFIG_OMAP_COMMON),) CONFIG_STANDALONE_LOAD_ADDR = 0x8030 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] _POST_WORD_ADDR for ARM
Dear Simon, In message CAPnjgZ0HpWCBDJeaebXj=RwvQPBXoPe1sL=pej8gtyehmjd...@mail.gmail.com you wrote: I think you asked this question before. You should explain what you want this feature to do, what board you are using, where you have already looked for information, etc. People are much more likely to respond if you provide a bit of context. Also I think I did already reply and point to the bootstage feature and show_boot_progress()? Several people (including you [1x], Christoffer Dall [1x], Michael Trimarchi [2x], and myself [6x, plus off-list]) tried to help, with absolutely no progress through all the iterations. I recommend we just stop feeding the troll. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The right word may be effective, but no word was ever as effective as a rightly timed pause. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
Hi Marek,
On Tuesday, March 18, 2014 at 01:35:47 PM, Lukasz Majewski wrote:
Hi Marek,
On Tuesday, March 18, 2014 at 07:51:05 AM, Lukasz Majewski wrote:
Hi Marek,
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher
wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu,
void *buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if
needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n,
dfu-crc); -
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size,
blk_seq_num);
This seems broken, at least because you didn't close the
opened brace (see 'if (size == 0) {' I can fix this up
when applying.
I was prepared to pull those patches to u-boot-dfu repo today
and test them :-).
Afterwards, I would send PR to Tom.
Are you OK with this?
Doesn't -dfu go through -usb ? ;-)
As fair as I remember the dfu code from ./drivers/dfu/* shall go via
u-boot-dfu tree directly to Tom.
Or do you want to send to Tom
directly ? Either way WFM.
After writing the other message you waited for a response less than
one minute :-).
Nonetheless, I picked the patches via
-usb, they're in master now.
I've just tested them and they doesn't cause any regression.
Would you be so kind and apply one more patch, which was supposed to
go with u-boot-dfu PR (this patch waits for submission from
21.02.2014)?
http://patchwork.ozlabs.org/patch/322450/
OK, picked and pushed. I think panto picked it up as well tho, but
maybe I unleashed too much mental terror unto him with my OvisLink
WL-1100SD that he is paralyzed by it ;-) Panto, I will pick this
patch, OK ?
This patch looks like a little orphan :-). I'm glad that someone pull
it finally.
As for the DFU, what do we do about the PRs ? DFU is part of USB, so
I shall logically pick the PRs from you and move them to trini, but
if you're unhappy about this, we need to talk about that. Tom,
Lukasz ... thoughts ?
I'm fine with sending PRs to you.
--
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] build:arm: Remove setting of CROSS_COMPILE environment variable
On Tue, Mar 18, 2014 at 04:46:48PM +0100, Lukasz Majewski wrote: After Kbuild introduction, the CROSS_COMPILE environment variable has been set to some default value (prefix arm-linux-). Note that this is quite a long-standing thing. Perhaps we're now not detecting a native build when we used to? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fwd: SPL problems on u-boot
Hi, I'am studying on u-boot, and i am trying to port it on s5pv210. I setup cross-compile on ubuntu12.10. After I complete the build environment. I try: *make distclean* *make smdkc100_config* *make all* and it works okay. But when i want to build the SPL, problem occurs. I hope you can help me to solve it, thanks! problem see below. 1. first try... Insert file smdkc100.h at Line 25 *#define CONFIG_SPL* and then *make distclean* *make smdkc100_config* *make all* error: */u-boot-2014.01/arch/arm/lib/crt0.S:74: undefined reference to `board_init_f'* 2. second try... Insert file smdkc100.h at Line 25 *#define CONFIG_SPL* *#define CONFIG_SPL_FRAMEWORK * and then *make distclean* *make smdkc100_config* *make all* error: */u-boot-2014.01/arch/arm/include/asm/spl.h:11:26: fatal error: asm/arch/spl.h: No such file or directory* ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot sunxi 00/12] sun4i (v2) + sun5i + pmic + emac support
On Tue, 2014-03-18 at 00:00 +0100, Hans de Goede wrote: There are 3 FIXUP patches in here which are intended to be squashed into Ian's work. Ian, can you please pick these up ? Consensus seems to be that including these useless ifdefs in the initial sun7i series makes future series to add other sun?i, so sure. I'm hoping to rebase to current sunxi+the cleanups I just sent out towards the end of the week and send out a v2 based on that, hopefully we can do the merge up to v2014.04-rc2 in time for a v3. I've got a small amount of WIP mmc cleanup going on, but that's looking like the biggest issue so far. I'm doing OK at removing magic numbers using existing comments and the Linux driver etc but some of the timing loops I'm not all that confident in changing -- so at least that bit will likely miss v2. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Added 64-bit MMIO accessors for ARMv8
On 02/13/2014 06:13 AM, Albert ARIBAUD wrote: Hi J., On Mon, 3 Feb 2014 17:59:26 -0600, J. German Rivera german.riv...@freescale.com wrote: From: J. German Rivera german.riv...@freescale.com This is needed for accessing peripherals with 64-bit MMIO registers, from ARMv8 processors. Change-Id: I685b96f708fa07e9098547f8e594ded084a044cb Signed-off-by: J. German Rivera german.riv...@freescale.com --- arch/arm/include/asm/io.h |8 1 file changed, 8 insertions(+) This is dead code right now. Please resubmit along with code which requires it. I am going to use this patch. When I post my patch set, I will include this one. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fpga: zynqpl: Fixed bug in alignment routine
Hello,
We're completely out of sync with our git repositories, but I changed
the relevant parts in my zynqpl.c (with the patch of this thread not
applied), and it worked well. The alignment went downwards as expected.
Regards,
Eli
On 18/03/14 14:17, Michal Simek wrote:
Does this work for you? If yes, I will send this as regular patch.
diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index 3572bc9..49eef0f 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -289,10 +289,11 @@ static int zynq_dma_xfer_init(u32 partialbit)
static u32 *zynq_align_dma_buffer(u32 *buf, u32 len, u32 swap)
{
u32 *new_buf;
- u32 i;
+ u32 i, align;
- if ((u32)buf != ALIGN((u32)buf, ARCH_DMA_MINALIGN)) {
- new_buf = (u32 *)ALIGN((u32)buf, ARCH_DMA_MINALIGN);
+ align = ALIGN((u32)(buf - ARCH_DMA_MINALIGN + 1), ARCH_DMA_MINALIGN);
+ if ((u32)buf != align) {
+ new_buf = (u32 *)align;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] build:arm: Remove setting of CROSS_COMPILE environment variable
Hi Tom, On Tue, Mar 18, 2014 at 04:46:48PM +0100, Lukasz Majewski wrote: After Kbuild introduction, the CROSS_COMPILE environment variable has been set to some default value (prefix arm-linux-). Note that this is quite a long-standing thing. Perhaps we're now not detecting a native build when we used to? My point is that we are relying on assigning default prefix (i.e. arm-linux-) For example OSELAS toolchains can have an arbitrary prefix (e.g. arm-linux-gnueabi-). When I cross compile I set explicitly CROSS_COMPILE=toolchain make and it works as it should (with or without this patch). Such approach seems natural for me. However, I don't know what is the exact rationale for seting this arm-linux- prefix to CROSS_COMPILE. I can only guess, that it is connected with situation when one just type make on x86_64 host and expect u-boot to be CROSS_COMPILE'd out of the box. Unfortunately this doesn't work with ARM host emulated with qemu (like OBS). Here when I type make I expect that native gcc for arm will run without even touching CROSS_COMPILE environment variable. Any idea how to fix this is more than welcome. Best regards, Lukasz Majewski signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] usb, dfu: extract flush code into seperate function
On Tuesday, March 18, 2014 at 04:53:30 PM, Lukasz Majewski wrote:
Hi Marek,
On Tuesday, March 18, 2014 at 01:35:47 PM, Lukasz Majewski wrote:
Hi Marek,
On Tuesday, March 18, 2014 at 07:51:05 AM, Lukasz Majewski wrote:
Hi Marek,
On Monday, March 17, 2014 at 11:56:16 AM, Heiko Schocher
wrote:
move the flushing code into an extra function dfu_flush(),
so it can be used from other code.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
[...]
@@ -199,23 +221,7 @@ int dfu_write(struct dfu_entity *dfu,
void *buf, int size, int blk_seq_num)
/* end? */
if (size == 0) {
- /* Now try and flush to the medium if
needed. */
- if (dfu-flush_medium)
- ret = dfu-flush_medium(dfu);
- printf(\nDFU complete CRC32: 0x%08x\n,
dfu-crc); -
- /* clear everything */
- dfu_free_buf();
- dfu-crc = 0;
- dfu-offset = 0;
- dfu-i_blk_seq_num = 0;
- dfu-i_buf_start = dfu_buf;
- dfu-i_buf_end = dfu_buf;
- dfu-i_buf = dfu-i_buf_start;
-
- dfu-inited = 0;
-
- }
+ ret = dfu_flush(dfu, buf, size,
blk_seq_num);
This seems broken, at least because you didn't close the
opened brace (see 'if (size == 0) {' I can fix this up
when applying.
I was prepared to pull those patches to u-boot-dfu repo today
and test them :-).
Afterwards, I would send PR to Tom.
Are you OK with this?
Doesn't -dfu go through -usb ? ;-)
As fair as I remember the dfu code from ./drivers/dfu/* shall go via
u-boot-dfu tree directly to Tom.
Or do you want to send to Tom
directly ? Either way WFM.
After writing the other message you waited for a response less than
one minute :-).
Nonetheless, I picked the patches via
-usb, they're in master now.
I've just tested them and they doesn't cause any regression.
Would you be so kind and apply one more patch, which was supposed to
go with u-boot-dfu PR (this patch waits for submission from
21.02.2014)?
http://patchwork.ozlabs.org/patch/322450/
OK, picked and pushed. I think panto picked it up as well tho, but
maybe I unleashed too much mental terror unto him with my OvisLink
WL-1100SD that he is paralyzed by it ;-) Panto, I will pick this
patch, OK ?
This patch looks like a little orphan :-). I'm glad that someone pull
it finally.
OK.
As for the DFU, what do we do about the PRs ? DFU is part of USB, so
I shall logically pick the PRs from you and move them to trini, but
if you're unhappy about this, we need to talk about that. Tom,
Lukasz ... thoughts ?
I'm fine with sending PRs to you.
PR will go out once I do builds.
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] spl: Fix guardian macros in spl.h
Fix the macros guarding the spl.h header for various platforms. Due to a typo and a propagation of it, the macros went out-of-sync with their ifdef check, so fix this. Signed-off-by: Marek Vasut ma...@denx.de Cc: Tom Rini tr...@ti.com --- arch/arm/include/asm/arch-am33xx/spl.h | 2 +- arch/arm/include/asm/arch-davinci/spl.h | 2 +- arch/arm/include/asm/arch-mx35/spl.h| 2 +- arch/arm/include/asm/arch-omap3/spl.h | 2 +- arch/arm/include/asm/arch-omap4/spl.h | 2 +- arch/arm/include/asm/arch-omap5/spl.h | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) I build-tested this with: MAKEALL -s mx35 MAKEALL -v ti All pass. diff --git a/arch/arm/include/asm/arch-am33xx/spl.h b/arch/arm/include/asm/arch-am33xx/spl.h index 2df4114..8543f43 100644 --- a/arch/arm/include/asm/arch-am33xx/spl.h +++ b/arch/arm/include/asm/arch-am33xx/spl.h @@ -5,7 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef_ASM_ARCH_SPL_H_ -#define_ASM_SPL_H_ +#define_ASM_ARCH_SPL_H_ #if defined(CONFIG_TI816X) #define BOOT_DEVICE_XIP2 diff --git a/arch/arm/include/asm/arch-davinci/spl.h b/arch/arm/include/asm/arch-davinci/spl.h index 5aa5d2d..5afe0d4 100644 --- a/arch/arm/include/asm/arch-davinci/spl.h +++ b/arch/arm/include/asm/arch-davinci/spl.h @@ -5,7 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef_ASM_ARCH_SPL_H_ -#define_ASM_SPL_H_ +#define_ASM_ARCH_SPL_H_ #define BOOT_DEVICE_NAND 1 #define BOOT_DEVICE_SPI2 diff --git a/arch/arm/include/asm/arch-mx35/spl.h b/arch/arm/include/asm/arch-mx35/spl.h index f87c137..d0efec2 100644 --- a/arch/arm/include/asm/arch-mx35/spl.h +++ b/arch/arm/include/asm/arch-mx35/spl.h @@ -5,7 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef_ASM_ARCH_SPL_H_ -#define_ASM_SPL_H_ +#define_ASM_ARCH_SPL_H_ #define BOOT_DEVICE_NONE 0 #define BOOT_DEVICE_XIP1 diff --git a/arch/arm/include/asm/arch-omap3/spl.h b/arch/arm/include/asm/arch-omap3/spl.h index 2ec319c..8350532 100644 --- a/arch/arm/include/asm/arch-omap3/spl.h +++ b/arch/arm/include/asm/arch-omap3/spl.h @@ -5,7 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef_ASM_ARCH_SPL_H_ -#define_ASM_SPL_H_ +#define_ASM_ARCH_SPL_H_ #define BOOT_DEVICE_NONE 0 #define BOOT_DEVICE_XIP1 diff --git a/arch/arm/include/asm/arch-omap4/spl.h b/arch/arm/include/asm/arch-omap4/spl.h index 551b27d..fb842a2 100644 --- a/arch/arm/include/asm/arch-omap4/spl.h +++ b/arch/arm/include/asm/arch-omap4/spl.h @@ -5,7 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef_ASM_ARCH_SPL_H_ -#define_ASM_SPL_H_ +#define_ASM_ARCH_SPL_H_ #define BOOT_DEVICE_NONE 0 #define BOOT_DEVICE_XIP1 diff --git a/arch/arm/include/asm/arch-omap5/spl.h b/arch/arm/include/asm/arch-omap5/spl.h index 4a279cf..f707998 100644 --- a/arch/arm/include/asm/arch-omap5/spl.h +++ b/arch/arm/include/asm/arch-omap5/spl.h @@ -5,7 +5,7 @@ * SPDX-License-Identifier:GPL-2.0+ */ #ifndef_ASM_ARCH_SPL_H_ -#define_ASM_SPL_H_ +#define_ASM_ARCH_SPL_H_ #define BOOT_DEVICE_NONE0 #define BOOT_DEVICE_XIP 1 -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: mxs: Add serial console support into SPL
Add support for serial console into the i.MX23/i.MX28 SPL. A full,
uncrippled serial console support comes very helpful when debugging
various spectacular hardware bringup issues early in the process.
Because we do not use SPL framework, but have our own minimalistic
SPL, which is compatible with the i.MX23/i.MX28 BootROM, we do not
use preloader_console_init(), but instead use a similar function to
start the console. Nonetheless, to avoid blowing up the size of the
SPL binary, this support is enabled only if CONFIG_SPL_SERIAL_SUPPORT
is defined, which is disabled by default.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 87b63c1..58ff8db 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -18,7 +18,8 @@
#include mxs_init.h
DECLARE_GLOBAL_DATA_PTR;
-gd_t gdata __section(.data);
+static gd_t gdata __section(.data);
+static bd_t bdata __section(.data);
/*
* This delay function is intended to be used only in early stage of boot,
where
@@ -106,6 +107,16 @@ static uint8_t mxs_get_bootmode_index(void)
return i;
}
+static void mxs_spl_console_init(void)
+{
+#ifdef CONFIG_SPL_SERIAL_SUPPORT
+ gd-bd = bdata;
+ gd-baudrate = CONFIG_BAUDRATE;
+ serial_init();
+ gd-have_console = 1;
+#endif
+}
+
void mxs_common_spl_init(const uint32_t arg, const uint32_t *resptr,
const iomux_cfg_t *iomux_setup,
const unsigned int iomux_size)
@@ -116,6 +127,9 @@ void mxs_common_spl_init(const uint32_t arg, const uint32_t
*resptr,
gd = gdata;
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
+
+ mxs_spl_console_init();
+
mxs_power_init();
mxs_mem_init();
--
1.8.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm: mxs: Properly set GD pointer in SPL
Set the GD pointer in the SPL to a defined symbol so various functions from U-Boot can be used without adverse side effects. Signed-off-by: Marek Vasut ma...@denx.de Cc: Stefano Babic sba...@denx.de --- arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c index 68c30af..87b63c1 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c @@ -13,9 +13,13 @@ #include asm/arch/imx-regs.h #include asm/arch/sys_proto.h #include asm/gpio.h +#include linux/compiler.h #include mxs_init.h +DECLARE_GLOBAL_DATA_PTR; +gd_t gdata __section(.data); + /* * This delay function is intended to be used only in early stage of boot, where * clock are not set up yet. The timer used here is reset on every boot and @@ -109,6 +113,7 @@ void mxs_common_spl_init(const uint32_t arg, const uint32_t *resptr, struct mxs_spl_data *data = (struct mxs_spl_data *) ((CONFIG_SYS_TEXT_BASE - sizeof(struct mxs_spl_data)) ~0xf); uint8_t bootmode = mxs_get_bootmode_index(); + gd = gdata; mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size); mxs_power_init(); -- 1.8.5.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] powerpc/t1042RDB: Add Video - HDMI support
From: Jason Jin jason@freescale.com
T1042 has internal display interface unit (DIU) for driving video.
T1042RDB supports video mode via
-LCD using TI enconder
-HDMI type interface via HDMI encoder
Chrontel, CH7301C encoder which is I2C programmable is used
as HDMI connector on T1042RDB.
This patch add support to
-enable Video interface for T1042RDB
-route qixis multiplexing to enable DIU-HDMI interface on board
-program DIU pixel clock gerenartor for T1042
-program HDMI encoder via I2C on board
This patch refer to the upstream diu patch
(337b0c52b3296f371d04aef71a833e09110e0e6b) for T1040qds.
Signed-off-by: Jason Jin jason@freescale.com
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
V2:
- Restore CONFIG_SYS_CONSOLE_IS_IN_ENV macors.
- Restore CONFIG_SYS_MALLOC_LEN macors, this macors not effect FB.
- Add a blank line between declarations and code.
diff --git a/board/freescale/t104xrdb/Makefile
b/board/freescale/t104xrdb/Makefile
index af38d9f..f15a633 100644
--- a/board/freescale/t104xrdb/Makefile
+++ b/board/freescale/t104xrdb/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_PCI) += pci.o
obj-y += law.o
obj-y += tlb.o
obj-y += cpld.o
+obj-$(CONFIG_FSL_DIU_FB) += diu.o
diff --git a/board/freescale/t104xrdb/diu.c b/board/freescale/t104xrdb/diu.c
new file mode 100644
index 000..3285bef
--- /dev/null
+++ b/board/freescale/t104xrdb/diu.c
@@ -0,0 +1,84 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ * Author: Priyanka Jain priyanka.j...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm/io.h
+#include common.h
+#include command.h
+#include fsl_diu_fb.h
+#include linux/ctype.h
+#include video_fb.h
+
+#include ../common/diu_ch7301.h
+
+#include cpld.h
+#include t104xrdb.h
+
+/*
+ * DIU Area Descriptor
+ *
+ * Note that we need to byte-swap the value before it's written to the AD
+ * register. So even though the registers don't look like they're in the same
+ * bit positions as they are on the MPC8610, the same value is written to the
+ * AD register on the MPC8610 and on the P1022.
+ */
+#define AD_BYTE_F 0x1000
+#define AD_ALPHA_C_SHIFT 25
+#define AD_BLUE_C_SHIFT23
+#define AD_GREEN_C_SHIFT 21
+#define AD_RED_C_SHIFT 19
+#define AD_PIXEL_S_SHIFT 16
+#define AD_COMP_3_SHIFT12
+#define AD_COMP_2_SHIFT8
+#define AD_COMP_1_SHIFT4
+#define AD_COMP_0_SHIFT0
+
+void diu_set_pixel_clock(unsigned int pixclock)
+{
+ unsigned long speed_ccb, temp;
+ u32 pixval;
+ int ret;
+
+ speed_ccb = get_bus_freq(0);
+ temp = 10 / pixclock;
+ temp *= 1000;
+ pixval = speed_ccb / temp;
+
+ /* Program HDMI encoder */
+ ret = diu_set_dvi_encoder(temp);
+ if (ret) {
+ puts(Failed to set DVI encoder\n);
+ return;
+ }
+
+ /* Program pixel clock */
+ out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR,
+((pixval PXCK_BITS_START) PXCK_MASK));
+
+ /* enable clock*/
+ out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR, PXCKEN_MASK |
+((pixval PXCK_BITS_START) PXCK_MASK));
+}
+
+int platform_diu_init(unsigned int xres, unsigned int yres, const char *port)
+{
+ u32 pixel_format;
+ u8 sw;
+
+ /*Configure Display ouput port as HDMI*/
+ sw = CPLD_READ(sfp_ctl_status);
+ CPLD_WRITE(sfp_ctl_status , sw ~(CPLD_DIU_SEL_DFP));
+
+ pixel_format = cpu_to_le32(AD_BYTE_F | (3 AD_ALPHA_C_SHIFT) |
+ (0 AD_BLUE_C_SHIFT) | (1 AD_GREEN_C_SHIFT) |
+ (2 AD_RED_C_SHIFT) | (8 AD_COMP_3_SHIFT) |
+ (8 AD_COMP_2_SHIFT) | (8 AD_COMP_1_SHIFT) |
+ (8 AD_COMP_0_SHIFT) | (3 AD_PIXEL_S_SHIFT));
+
+ printf(DIU: Switching to monitor DVI @ %ux%u\n, xres, yres);
+
+ return fsl_diu_init(xres, yres, pixel_format, 0);
+}
diff --git a/include/configs/T1042RDB_PI.h b/include/configs/T1042RDB_PI.h
index 8a8a2ff..6d3822d 100644
--- a/include/configs/T1042RDB_PI.h
+++ b/include/configs/T1042RDB_PI.h
@@ -203,6 +203,7 @@
#define CPLD_LBMAP_DFLTBANK0x40 /* BANK OR | BANK0 */
#define CPLD_LBMAP_RESET 0xFF
#define CPLD_LBMAP_SHIFT 0x03
+#define CPLD_DIU_SEL_DFP 0x80
#define CONFIG_SYS_CPLD_BASE 0xffdf
#define CONFIG_SYS_CPLD_BASE_PHYS (0xfull | CONFIG_SYS_CPLD_BASE)
@@ -358,6 +359,22 @@
#define CONFIG_SYS_HUSH_PARSER
#define CONFIG_SYS_PROMPT_HUSH_PS2
+/* Video */
+#define CONFIG_FSL_DIU_FB
+
+#ifdef CONFIG_FSL_DIU_FB
+#define CONFIG_FSL_DIU_CH7301
+#define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x18)
+#define CONFIG_VIDEO
+#define CONFIG_CMD_BMP
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_CFB_CONSOLE_ANSI
+#define CONFIG_VIDEO_SW_CURSOR
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_VIDEO_LOGO
+#define
Re: [U-Boot] [PATCH] build:arm: Remove setting of CROSS_COMPILE environment variable
Hi Lukasz, Tom, Hi Tom, On Tue, Mar 18, 2014 at 04:46:48PM +0100, Lukasz Majewski wrote: After Kbuild introduction, the CROSS_COMPILE environment variable has been set to some default value (prefix arm-linux-). Note that this is quite a long-standing thing. Perhaps we're now not detecting a native build when we used to? My point is that we are relying on assigning default prefix (i.e. arm-linux-) For example OSELAS toolchains can have an arbitrary prefix (e.g. arm-linux-gnueabi-). When I cross compile I set explicitly CROSS_COMPILE=toolchain make and it works as it should (with or without this patch). Such approach seems natural for me. However, I don't know what is the exact rationale for seting this arm-linux- prefix to CROSS_COMPILE. I can only guess, that it is connected with situation when one just type make on x86_64 host and expect u-boot to be CROSS_COMPILE'd out of the box. Agree. It is useful only for people using arm-linux-gcc on x86 host. I usually use arm-linux-gnueabi-gcc. Someone else may be using other prefixes. I think there is no rationale more sophisticated than that it just has been there since long time before. So, I agree with this patch except a little misleading commit description I commented below. Acked-by: Masahiro Yamada yamad...@jp.panasonic.com Unfortunately this doesn't work with ARM host emulated with qemu (like OBS). Here when I type make I expect that native gcc for arm will run without even touching CROSS_COMPILE environment variable. I believe it is the same as prior to Kbuild. So, I am not convined with this part of your commit description: After Kbuild introduction, the CROSS_COMPILE environment variable has been set to some default value (prefix arm-linux-). Any idea how to fix this is more than welcome. If you are searching some other choices, [1] ifneq ($(origin CROSS_COMPILE), command line) ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := arm-linux- endif endif For native build on ARM, you can explicitely set CROSS_COMPILE as empty:make CROSS_COMPILE= In this case, CROSS_COMPILE will not be overwritten in arch/arm/config.mk. [2] ifneq ($(HOSTARCH),$(ARCH)) ifeq ($(CROSS_COMPILE),) CROSS_COMPILE := arm-linux- endif endif For native build on ARM, both $(HOSTARCH) and $(ARCH) are arm, so CROSS_COMPILE will not be set. But, I think deleting CROSS_COMPILE setting is the simplest and the best. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] fsl/diu: ch7301 encoder split off from t1040qds/diu.c
From: Wang Dongsheng dongsheng.w...@freescale.com
The ch7301 encoder not only used in t1040qds platform, so we split
it for t1042rdb and LSx platform.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
V2: No Change
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index f6a0879..cd4b33b 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_DIU_CH7301) += diu_ch7301.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/diu_ch7301.c
b/board/freescale/common/diu_ch7301.c
new file mode 100644
index 000..497fa1b
--- /dev/null
+++ b/board/freescale/common/diu_ch7301.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ * Authors: Priyanka Jain priyanka.j...@freescale.com
+ * Wang Dongsheng dongsheng.w...@freescale.com
+ *
+ * This file is copied and modified from the original t1040qds/diu.c.
+ * Encoder can be used in T104x and LSx Platform.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include stdio_dev.h
+#include i2c.h
+
+#define I2C_DVI_INPUT_DATA_FORMAT_REG 0x1F
+#define I2C_DVI_PLL_CHARGE_CNTL_REG0x33
+#define I2C_DVI_PLL_DIVIDER_REG0x34
+#define I2C_DVI_PLL_SUPPLY_CNTL_REG0x35
+#define I2C_DVI_PLL_FILTER_REG 0x36
+#define I2C_DVI_TEST_PATTERN_REG 0x48
+#define I2C_DVI_POWER_MGMT_REG 0x49
+#define I2C_DVI_LOCK_STATE_REG 0x4D
+#define I2C_DVI_SYNC_POLARITY_REG 0x56
+
+/*
+ * Set VSYNC/HSYNC to active high. This is polarity of sync signals
+ * from DIU-DVI. The DIU default is active igh, so DVI is set to
+ * active high.
+ */
+#define I2C_DVI_INPUT_DATA_FORMAT_VAL 0x98
+
+#define I2C_DVI_PLL_CHARGE_CNTL_HIGH_SPEED_VAL 0x06
+#define I2C_DVI_PLL_DIVIDER_HIGH_SPEED_VAL 0x26
+#define I2C_DVI_PLL_FILTER_HIGH_SPEED_VAL 0xA0
+#define I2C_DVI_PLL_CHARGE_CNTL_LOW_SPEED_VAL 0x08
+#define I2C_DVI_PLL_DIVIDER_LOW_SPEED_VAL 0x16
+#define I2C_DVI_PLL_FILTER_LOW_SPEED_VAL 0x60
+
+/* Clear test pattern */
+#define I2C_DVI_TEST_PATTERN_VAL 0x18
+/* Exit Power-down mode */
+#define I2C_DVI_POWER_MGMT_VAL 0xC0
+
+/* Monitor polarity is handled via DVI Sync Polarity Register */
+#define I2C_DVI_SYNC_POLARITY_VAL 0x00
+
+/* Programming of HDMI Chrontel CH7301 connector */
+int diu_set_dvi_encoder(unsigned int pixclock)
+{
+ int ret;
+ u8 temp;
+
+ temp = I2C_DVI_TEST_PATTERN_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_TEST_PATTERN_REG, 1,
+ temp, 1);
+ if (ret) {
+ puts(I2C: failed to select proper dvi test pattern\n);
+ return ret;
+ }
+ temp = I2C_DVI_INPUT_DATA_FORMAT_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_INPUT_DATA_FORMAT_REG,
+ 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi input data format\n);
+ return ret;
+ }
+
+ /* Set Sync polarity register */
+ temp = I2C_DVI_SYNC_POLARITY_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR, I2C_DVI_SYNC_POLARITY_REG, 1,
+ temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi syc polarity\n);
+ return ret;
+ }
+
+ /* Set PLL registers based on pixel clock rate*/
+ if (pixclock 6500) {
+ temp = I2C_DVI_PLL_CHARGE_CNTL_HIGH_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_CHARGE_CNTL_REG, 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi pll charge_cntl\n);
+ return ret;
+ }
+ temp = I2C_DVI_PLL_DIVIDER_HIGH_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_DIVIDER_REG, 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi pll divider\n);
+ return ret;
+ }
+ temp = I2C_DVI_PLL_FILTER_HIGH_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_FILTER_REG, 1, temp, 1);
+ if (ret) {
+ puts(I2C: failed to select dvi pll filter\n);
+ return ret;
+ }
+ } else {
+ temp = I2C_DVI_PLL_CHARGE_CNTL_LOW_SPEED_VAL;
+ ret = i2c_write(CONFIG_SYS_I2C_DVI_ADDR,
+ I2C_DVI_PLL_CHARGE_CNTL_REG, 1, temp, 1);
+
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Stephen, diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig new file mode 100644 index 000..fbf00f3 --- /dev/null +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I am following that concept. That's why I added maintainers information to defconfig files rather than keeping it in a seperated file. Anyway, this item is for open discussion. Do you have any idea instead of this? Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... This is really really Tegra-specific matter. You can send a follow-up patch to add arch/arm/cpu/armv7/tegra/Kconfig and desecribe them by yourself if you believe it is necessary. (although I doubt it.) Please do not get me wrong. This series provides the basic infrastructure. Expecting SoC-specific issues to this series is not fair. Tegra is not everything. BTW, tegra30 cannot automatically select SYS_VENDOR. It might be nvidia, or avionic-design. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
On 03/18/2014 09:16 PM, Masahiro Yamada wrote: Hi Stephen, diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig new file mode 100644 index 000..fbf00f3 --- /dev/null +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work. I am following that concept. That's why I added maintainers information to defconfig files rather than keeping it in a seperated file. Anyway, this item is for open discussion. Do you have any idea instead of this? I don't think there's any need at all for a defconfig file here. Perhaps the solution is to simply name these files something other than defconfig, but rather something else that reflects what the content really is. Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... This is really really Tegra-specific matter. Absolutely not at all. Any board contains a specific SoC. Each specific SoC is a particular CPU architecture and type, etc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 04/17] kconfig: add defconfig files for all boards
Hi Stephen, diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig new file mode 100644 index 000..fbf00f3 --- /dev/null +++ b/configs/beaver_defconfig @@ -0,0 +1,10 @@ +CONFIG_SPL=y +CONFIG_ARM=y +CONFIG_SYS_CPU=armv7 +CONFIG_SOC_DIR=y +CONFIG_SYS_SOC=tegra30 +CONFIG_SYS_BOARD=beaver +CONFIG_VENDOR_DIR=y +CONFIG_SYS_VENDOR=nvidia +CONFIG_SYS_CONFIG_NAME=beaver +CONFIG_BOARD_MAINTAINER=Tom Warren twar...@nvidia.com:Stephen Warren swar...@nvidia.com This is odd; defconfig in the Linux kernel is for defining values for user-editable configuration options. However, at least CONFIG_BOARD_MAINTAINERS is a property of the board port, not something the a user should be editing. In U-Boot, each board and its maintainer are tightly coupled. So, Albert chose to merge boards.cfg and MAINTAINERS in commit 27af930e9a. I think you're completely missing my point. None of the information contained in the defconfig files you posted is even *remotely* related to what a defconfig file is. defconfig is for user-configurable configuration of the software, not for core values that must be set up in a certain way for the code to compile or work. Right. None of settings in Kconfig in this series is not user-editable. make randconfig or make allyesconfig will not work at all. I am following that concept. That's why I added maintainers information to defconfig files rather than keeping it in a seperated file. Anyway, this item is for open discussion. Do you have any idea instead of this? I don't think there's any need at all for a defconfig file here. Perhaps the solution is to simply name these files something other than defconfig, but rather something else that reflects what the content really is. There is a plan to move user-editable macros to Kconfig. For example, CONFIG_BAUDRATE. Or someone might to disable CONFIG_CMD_* to reduce the binary size. We definitely need defconfig. Renaming it to something else will break the Kconfig infrastructure. I believe the right way to reuse the Linux's Kconfig with minimum modification. Other values in this file feel very odd too. For example, I would expect selecting SYS_SOC=tegra30 it automatically select SYS_VENDOR, SYS_CPU, ARM, SPL, ... This is really really Tegra-specific matter. Absolutely not at all. Any board contains a specific SoC. Each specific SoC is a particular CPU architecture and type, etc. In that case, all boards must have board/*/Kconfig to automatically select correct CONFIG_SYS_VENDOR, CONFIG_SYS_SOC, etc. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] problem on SPL build
Hi, I'am studying on u-boot, and i am trying to port it on smdkc100. I setup cross-compile on ubuntu12.04 and build the u-boot, it works okay. But i have a problem on SPL build. I hope you can help me to solve it, thanks! problem: insert file smdkc100.h at Line 25 #define CONFIG_SPL and then make distclean make smdkc100_config make all but get error: /u-boot-2014.01/arch/arm/lib/crt0.S:74: undefined reference to `board_init_f' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fpga: zynqpl: Fixed bug in alignment routine
Hi, On 03/18/2014 10:14 PM, Eli Billauer wrote: Hello, We're completely out of sync with our git repositories, but I changed the relevant parts in my zynqpl.c (with the patch of this thread not applied), and it worked well. The alignment went downwards as expected. That's interesting. Anyway we will look at my proposed patch because from my test from yesterday ALIGN is ALIGN_UP but we need ALIGN_DOWN. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
