Re: [U-Boot] [PATCH 00/10] USB: Gadget DFU related fixes
Hi Marek, On Nov 29, 2012, at 8:32 AM, Marek Vasut wrote: Dear Pantelis Antoniou, Various bugfixes, g_dnl DFU updates. Pantelis Antoniou (10): usb: Remove obsolete header file usb: Fix bug when both DFU ETHER are defined g_dnl: Issue connect/disconnect as appropriate g_dnl: Properly terminate string list. dfu: Only perform DFU board_usb_init() for TRATS dfu: Fix crash when wrong number of arguments given dfu: Send correct DFU response from composite_setup dfu: Properly zero out timeout value dfu: Add a partition type target dfu: Support larger than memory transfers. [...] So this is a V2 patchset? Anyway, can you please rebase on top of u-boot- usb/master and repost? I rebased it on top of u-boot/master and pushed. Yeah, it's V2. I've rebased, and the patch series applies without any conflicts or fudges. Best regards, Marek Vasut Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] EXYNOS: Add L2 Cache Support.
This patch set adds L2 Cache Support to EXYNOS.
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/cpu/armv7/exynos/soc.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/soc.c b/arch/arm/cpu/armv7/exynos/soc.c
index ab65b8d..a45bbfb 100644
--- a/arch/arm/cpu/armv7/exynos/soc.c
+++ b/arch/arm/cpu/armv7/exynos/soc.c
@@ -23,6 +23,14 @@
#include common.h
#include asm/io.h
+#include asm/system.h
+
+enum l2_cache_params {
+ CACHE_TAG_RAM_SETUP = (19),
+ CACHE_DATA_RAM_SETUP = (15),
+ CACHE_TAG_RAM_LATENCY = (26),
+ CACHE_DATA_RAM_LATENCY = (20)
+};
void reset_cpu(ulong addr)
{
@@ -36,3 +44,31 @@ void enable_caches(void)
dcache_enable();
}
#endif
+
+#ifndef CONFIG_SYS_L2CACHE_OFF
+/*
+ * Set L2 cache parameters
+ */
+static void exynos5_set_l2cache_params(void)
+{
+ unsigned int val = 0;
+
+ asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r(val));
+
+ val |= CACHE_TAG_RAM_SETUP |
+ CACHE_DATA_RAM_SETUP |
+ CACHE_TAG_RAM_LATENCY |
+ CACHE_DATA_RAM_LATENCY;
+
+ asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val));
+}
+
+/*
+ * Sets L2 cache related parameters before enabling data cache
+ */
+void v7_outer_cache_enable(void)
+{
+ exynos5_set_l2cache_params();
+}
+#endif
+
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver
On Thu, Nov 29, 2012 at 8:53 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2012-11-29 klockan 07:27 +0100 skrev Marek Vasut: Dear yegorsli...@googlemail.com, From: Yegor Yefremov yegorsli...@googlemail.com The driver code was taken from Linux kernel source: drivers/net/phy/icplus.c Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com [...] Is there any user for this PHY please? I don't have one, but know at least one user having one in an A10 based netbook. http://linux-sunxi.org/File:H6-netbook-mainboard.jpg I found these boards in kernel: arch/mips/configs/malta_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/bcm47xx_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/ip27_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/sead3_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/83xx/mpc832x_rdb_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc83xx_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ICPLUS_PHY=m Yegor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] usb: Remove obsolete header file
Hi Lukasz, I did found out the problem with large transfers, and there is a patch that fixes it. I'm pretty sure that the transfers are correct. Perhaps some other problem with your board? Can you use the updated patch series and try with that, with debugging enabled? Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] usb: Remove obsolete header file
Hi Pantelis, Hi Lukasz, On Nov 28, 2012, at 7:46 PM, Lukasz Majewski wrote: Hi Pantelis, Hi Lukasz, On Nov 28, 2012, at 6:01 PM, Lukasz Majewski wrote: Hi Tom, Hi Pantelis, usbdescriptors.h conflicts with linux/usb/ch9.h Remove it. After rebasing on u-boot-usb/next below comment apply: After applying this patch, I cannot build trats target anymore. With u-boot-usb/master I can compile the u-boot for trats board with no warnings and errors. Unfortunately after flashing with dfu, the u-boot is _NOT_ working properly anymore. It seems, that some parts of the binary weren't correct. Are you writing to a file in a filesystem? I.e. FAT? I'm in the middle of doing more extensive tests, but file write to an FS might have problems. I am using the raw mmc interface. I've written u-boot to RAW eMMC (based on the LBA addressing). Moreover I was also able to write data to FAT and EXT4 fs (which uses standard fat/ext4 load commands). I see. Note that ext4 writes won't work; there is no offset to the write file command. You will have to have use a large enough buffer to handle the file's worst case. The 4 MiB buffer size was my wrong simplification. It shall be done as you proposed (with transfered data chopped to smaller chunks). The ext4write command will write data from DRAM buffer (e.g. 0x4400) to partition formatted with ext4 fs. (one just needs to remember that file size is given with hex number). I've posted some fixes for ext4 recently to ML. There could be something there that it's missed. I'm in the middle of doing more extensive tests. It writes u-boot.bin, but in a way that the board is bricked after flashing. I need some time to perform the thorough review of core DFU patches (patches 7/10, 09/10, 10/10). OK. BTW: 1. What is your target device? What is the output of dfu mmc 0 list command on your device? I'm on am335x_evm target, actual board is a beaglebone. On trats it is: DFU alt settings list: dev: eMMC alt: 0 name: u-boot layout: RAW_ADDR dev: eMMC alt: 1 name: uImage layout: FAT # setenv dfu_alt_info 'test part 0 3' # mmc part U-Boot# mmc part Partition Map for MMC device 0 -- Partition Type: DOS PartStart SectorNum Sectors UUIDType 1 63 112392 7a348599-01 0c Boot 2 112455 7501331 7a348599-02 83 3 7613786 12966 7a348599-03 83 # dfu mmc 0 list DFU alt settings list: dev: eMMC alt: 0 name: test layout: RAW_ADDR Off topic: It would be nice to have all partitions listed with dfu mmc 0 list :-) and then have access to it via dfu-util tool (as a separate alt settings). But this is a task for the future :-). Are you downloading u-boot.bin to the raw nand? I.e. there's no boot partition? Yes, there isn't any partition for u-boot. I write to raw eMMC address. All my tests have been downloading a small ext3 image to the mmc. I'm in the middle of doing more extensive tests but those takes a huge amount of time... :( This is because of very low DFU transmission speed (It uses only EP0 with EPS=64B , so it is meant to transfer really small files). Updating rootfs via DFU would take much time. It is OK, to transfer u-boot, uImage, some log data. We have customers that do want to use DFU for all of their initial programming. Ok, I see. The limitations are known, but the fact is that they find it very convenient for their use. And it's not like you're limited by the USB interface, most of the time is spent writing to the medium. So in my opinion there would be nice to have some kind of caching of received data before writing to memory. Then we could write memory asynchronously, when we collect e.g. 1 MiB data in a buffer (and in meantime collect next data). BTW, I've just confirmed that larger transfers get corrupted... :( Working on a fix now... Ok. 2. Please look into the TRATS board (especially the CONFIG_DFU_ALT constant) for reference. Already looked there. 3. What is yours dfu-util version? (Mine is 0.1+svnexported) Compiled from source git://gitorious.org/dfu-util/dfu-util.git Current master. Regards -- Pantelis Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/usb/gadget/f_dfu.c | 1 - include/g_dnl.h| 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c index 3ec4c65..10547e3 100644 --- a/drivers/usb/gadget/f_dfu.c +++ b/drivers/usb/gadget/f_dfu.c @@ -25,7 +25,6 @@ #include malloc.h #include linux/usb/ch9.h -#include usbdescriptors.h #include linux/usb/gadget.h #include linux/usb/composite.h diff --git a/include/g_dnl.h b/include/g_dnl.h
Re: [U-Boot] [PATCH 0/6 V4] EXYNOS5: FDT Support for I2C
Hi All, This patch set is based on following patch sets Add DT based ethernet driver for SMDK5250 Add TMU support for Exynos5250 based SMDK5250 Regards, Rajeshwari Shinde On Thu, Nov 29, 2012 at 12:39 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch set adds FDT support for I2C driver and API's to acess the bus number using the fdt node and also reset the port. Changes in V2: - Baord i2c init moved to I2C driver in case of FDT. - Added Periph id to device node. - Modified i2c_get_bus_num_fdt api to compare using node. Changes in V3: - Peripheral id removed from dtsi file and decoded based on interrupts. - API for fdtdec_lookup removed as it is already present as fd_dec_lookup. Changes in V4: - renamed decode_peripheral_id to pinmux_decode_peripheral_id. - added comments in periph.h as suggested by Simon Glass. Rajeshwari Shinde (6): EXYNOS5: FDT: Add I2C device node data EXYNOS5 : FDT: Add Aliases for I2C device EXYNOS5: FDT: Add compatible string for I2C EXYNOS5: FDT : Decode peripheral id I2C: Driver changes for FDT support SMDK5250: Initialise I2C using FDT arch/arm/cpu/armv7/exynos/pinmux.c| 28 ++ arch/arm/dts/exynos5250.dtsi | 64 ++ arch/arm/include/asm/arch-exynos/periph.h | 31 ++- arch/arm/include/asm/arch-exynos/pinmux.h |8 +++ board/samsung/dts/exynos5250-smdk5250.dts | 11 board/samsung/smdk5250/smdk5250.c | 20 +--- drivers/i2c/s3c24x0_i2c.c | 83 - drivers/i2c/s3c24x0_i2c.h |8 +++ include/fdtdec.h |1 + include/i2c.h | 26 + lib/fdtdec.c |1 + 11 files changed, 248 insertions(+), 33 deletions(-) -- 1.7.4.4 ___ 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 01/10] usb: Remove obsolete header file
Hi Lukasz, On Nov 29, 2012, at 10:13 AM, Lukasz Majewski wrote: Hi Pantelis, Hi Lukasz, On Nov 28, 2012, at 7:46 PM, Lukasz Majewski wrote: Hi Pantelis, Hi Lukasz, On Nov 28, 2012, at 6:01 PM, Lukasz Majewski wrote: Hi Tom, Hi Pantelis, usbdescriptors.h conflicts with linux/usb/ch9.h Remove it. After rebasing on u-boot-usb/next below comment apply: After applying this patch, I cannot build trats target anymore. With u-boot-usb/master I can compile the u-boot for trats board with no warnings and errors. Unfortunately after flashing with dfu, the u-boot is _NOT_ working properly anymore. It seems, that some parts of the binary weren't correct. Are you writing to a file in a filesystem? I.e. FAT? I'm in the middle of doing more extensive tests, but file write to an FS might have problems. I am using the raw mmc interface. I've written u-boot to RAW eMMC (based on the LBA addressing). Moreover I was also able to write data to FAT and EXT4 fs (which uses standard fat/ext4 load commands). I see. Note that ext4 writes won't work; there is no offset to the write file command. You will have to have use a large enough buffer to handle the file's worst case. The 4 MiB buffer size was my wrong simplification. It shall be done as you proposed (with transfered data chopped to smaller chunks). The ext4write command will write data from DRAM buffer (e.g. 0x4400) to partition formatted with ext4 fs. (one just needs to remember that file size is given with hex number). I've posted some fixes for ext4 recently to ML. Nice. There is a big fat warning when you try to write an ext4 file at an offset other than 0; it should be easy to fix. There could be something there that it's missed. I'm in the middle of doing more extensive tests. It writes u-boot.bin, but in a way that the board is bricked after flashing. I need some time to perform the thorough review of core DFU patches (patches 7/10, 09/10, 10/10). OK. BTW: 1. What is your target device? What is the output of dfu mmc 0 list command on your device? I'm on am335x_evm target, actual board is a beaglebone. On trats it is: DFU alt settings list: dev: eMMC alt: 0 name: u-boot layout: RAW_ADDR dev: eMMC alt: 1 name: uImage layout: FAT # setenv dfu_alt_info 'test part 0 3' # mmc part U-Boot# mmc part Partition Map for MMC device 0 -- Partition Type: DOS PartStart SectorNum Sectors UUIDType 1 63 112392 7a348599-01 0c Boot 2 112455 7501331 7a348599-02 83 3 7613786 12966 7a348599-03 83 # dfu mmc 0 list DFU alt settings list: dev: eMMC alt: 0 name: test layout: RAW_ADDR Off topic: It would be nice to have all partitions listed with dfu mmc 0 list :-) and then have access to it via dfu-util tool (as a separate alt settings). But this is a task for the future :-). Are you downloading u-boot.bin to the raw nand? I.e. there's no boot partition? Yes, there isn't any partition for u-boot. I write to raw eMMC address. All my tests have been downloading a small ext3 image to the mmc. I'm in the middle of doing more extensive tests but those takes a huge amount of time... :( This is because of very low DFU transmission speed (It uses only EP0 with EPS=64B , so it is meant to transfer really small files). Updating rootfs via DFU would take much time. It is OK, to transfer u-boot, uImage, some log data. We have customers that do want to use DFU for all of their initial programming. Ok, I see. The limitations are known, but the fact is that they find it very convenient for their use. And it's not like you're limited by the USB interface, most of the time is spent writing to the medium. So in my opinion there would be nice to have some kind of caching of received data before writing to memory. Then we could write memory asynchronously, when we collect e.g. 1 MiB data in a buffer (and in meantime collect next data). I doubt that would work in a u-boot environment. There are no threads and I'm pretty sure most mass memory interfaces are PIO. I'm completely up to date on latest u-boot happenings, maybe this has changed. Regards -- Pantelis BTW, I've just confirmed that larger transfers get corrupted... :( Working on a fix now... Ok. 2. Please look into the TRATS board (especially the CONFIG_DFU_ALT constant) for reference. Already looked there. 3. What is yours dfu-util version? (Mine is 0.1+svnexported) Compiled from source git://gitorious.org/dfu-util/dfu-util.git Current master. Regards -- Pantelis Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/usb/gadget/f_dfu.c | 1 - include/g_dnl.h| 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
Re: [U-Boot] Switch from mmcboot to ramboot?
Hi Grant, How can I tell u-boot to boot with the ramboot= definition instead of mmcboot= ? - Grant You need to change environmental variable bootcmd setenv bootcmd ramboot saveenv run bootcmd or simpler: Stop u-boot - and access prompt then, run ramboot -- Best regards, Lukasz Majewski Samsung Poland RD Center | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 V4] I2C: Driver changes for FDT support
Hello Rajeshwari, On 29.11.2012 08:09, Rajeshwari Shinde wrote: Functions added to get the I2C bus number and reset I2C bus using FDT node. Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org Nitpick: missing my Acked by ... so here it comes again: Acked-by: Heiko Schocher h...@denx.de 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] U-Boot for MIPS AR7161
Hi Dmytro, On Wed, Nov 28, 2012 at 06:09:21PM +0200, Dmytro wrote: But if all you have decided to go to the end, or you need a JTAG fundamentally, I can put a patch for RAM_uboot AR724x (AP99 platform), so you can make the example of his version of the loader for AR71xx (AP96 platform). Please show us your patch. Luka ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra: remove custom TEGRA_DEVICE_SETTINGS for board files
TEGRA_DEVICE_SETTINGS lives now in tegra-common-post.h. This removes custom TEGRA_DEVICE_SETTINGS for all tegra boards providing video output, except seaboard, which was fixed by Stephen already. Cc: Thierry Reding thierry.red...@avionic-design.de Signed-off-by: Marc Dietrich marvi...@gmx.de --- Tom, this needs to be applied ontop of Stephen's patch tegra: only define TEGRA_DEVICE_SETTINGS if not already defined include/configs/medcom-wide.h | 6 -- include/configs/paz00.h | 6 -- include/configs/tec.h | 6 -- 3 files changed, 18 deletions(-) diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h index 452d587..bae4ba0 100644 --- a/include/configs/medcom-wide.h +++ b/include/configs/medcom-wide.h @@ -78,12 +78,6 @@ ext2load mmc 0 0x1700 /boot/uImage; \ bootm -#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS \ - stdin=serial\0\ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA diff --git a/include/configs/paz00.h b/include/configs/paz00.h index 4a74d00..2edb4aa 100644 --- a/include/configs/paz00.h +++ b/include/configs/paz00.h @@ -72,12 +72,6 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP -#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS \ - stdin=serial\0\ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA diff --git a/include/configs/tec.h b/include/configs/tec.h index 815afa6..caeb9cd 100644 --- a/include/configs/tec.h +++ b/include/configs/tec.h @@ -85,12 +85,6 @@ ext2load mmc 0 0x1700 /boot/uImage; \ bootm -#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS \ - stdin=serial\0\ - stdout=serial,lcd\0 \ - stderr=serial,lcd\0 - /* LCD support */ #define CONFIG_LCD #define CONFIG_PWM_TEGRA -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 V4] I2C: Driver changes for FDT support
Hi Heiko, Thank you for acking the patch. Had made a few changes in the Driver hence had removed the same. Regards, Rajeshwari Shinde. On Thu, Nov 29, 2012 at 2:03 PM, Heiko Schocher h...@denx.de wrote: Hello Rajeshwari, On 29.11.2012 08:09, Rajeshwari Shinde wrote: Functions added to get the I2C bus number and reset I2C bus using FDT node. Signed-off-by: Rajeshwari Shinderajeshwar...@samsung.com Acked-by: Simon Glasss...@chromium.org Nitpick: missing my Acked by ... so here it comes again: Acked-by: Heiko Schocher h...@denx.de 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: Handle large transfers correctly
Hi Pantelis,
The sequence number is a 16 bit counter; make sure we
handle rollover correctly. This fixes the wrong transfers for
large ( 256MB) images.
This is a bit misleading comment.
DFU 1.1 standard says:
The wBlockNum field is a block sequence number. It increments each time
a block is transferred, wrapping to zero from 65,535. It is used to
provide useful context to the DFU loader in the device.
Maybe above statement shall be put to the comment.
One more thing:
wTransferSize = 4096 and the DFU 1.1 standard says:
The host sends between bMaxPacketSize0 and wTransferSize and
increments wBlockNum (which is 16 bits).
Maybe we shall increase the wTransferSize (defined at
static const struct dfu_function_descriptor dfu_func) to e.g. 32 KiB
and leave the code unchanged?
Can you test this option on your setup?
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/dfu.c | 28 +++-
drivers/dfu/dfu_mmc.c | 3 +++
include/dfu.h | 2 ++
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 1260c55..2483018 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -82,7 +82,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-name, buf, size,
blk_seq_num, dfu-offset, dfu-i_buf - dfu-i_buf_start);
- if (blk_seq_num == 0) {
+ if (dfu-do_init) {
/* initial state */
dfu-crc = 0;
dfu-offset = 0;
@@ -90,6 +90,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+ dfu-do_init = 0;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -97,7 +99,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
- dfu-i_blk_seq_num++;
+ /* handle rollover */
+ dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
/* flush buffer if overflow */
if ((dfu-i_buf + size) dfu-i_buf_end) {
@@ -106,6 +109,13 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) ret = tret;
}
+ /* we should be in buffer now (if not then size too large) */
+ if ((dfu-i_buf + size) dfu-i_buf_end) {
+ printf(%s: Wrong size! [%d] [%d] - \n,
+__func__, dfu-i_blk_seq_num, blk_seq_num,
size);
+ return -1;
+ }
+
memcpy(dfu-i_buf, buf, size);
dfu-i_buf += size;
@@ -120,7 +130,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) if (size == 0) {
debug(%s: DFU complete CRC32: 0x%x\n, __func__,
dfu-crc);
- puts(\nDownload complete\n);
+ printf(\nDownload complete (CRC32 0x%04x)\n,
dfu-crc);
/* clear everything */
dfu-crc = 0;
@@ -129,6 +139,9 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+ dfu-do_init = 1;
+
}
return ret = 0 ? size : ret;
@@ -190,7 +203,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) debug(%s: name: %s buf: 0x%p size: 0x%x
p_num: 0x%x i_buf: 0x%p\n, __func__, dfu-name, buf, size,
blk_seq_num, dfu-i_buf);
- if (blk_seq_num == 0) {
+ if (dfu-do_init) {
ret = dfu-read_medium(dfu, 0, NULL, dfu-r_left);
if (ret != 0) {
debug(%s: failed to get r_left\n,
__func__); @@ -206,6 +219,8 @@ int dfu_read(struct dfu_entity *dfu,
void *buf, int size, int blk_seq_num) dfu-i_buf_end = dfu_buf +
sizeof(dfu_buf); dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+ dfu-do_init = 0;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -213,7 +228,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
- dfu-i_blk_seq_num++;
+ /* handle rollover */
+ dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
ret = dfu_read_buffer_fill(dfu, buf, size);
if (ret 0) {
@@ -232,6 +248,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+ dfu-do_init = 1;
}
return ret;
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 4c8994b..906df55 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -234,5 +234,8 @@ int dfu_fill_entity_mmc(struct
Re: [U-Boot] [PATCH] dfu: Handle large transfers correctly
Hi Lukasz,
On Nov 29, 2012, at 11:06 AM, Lukasz Majewski wrote:
Hi Pantelis,
The sequence number is a 16 bit counter; make sure we
handle rollover correctly. This fixes the wrong transfers for
large ( 256MB) images.
This is a bit misleading comment.
DFU 1.1 standard says:
The wBlockNum field is a block sequence number. It increments each time
a block is transferred, wrapping to zero from 65,535. It is used to
provide useful context to the DFU loader in the device.
Maybe above statement shall be put to the comment.
No problem there.
One more thing:
wTransferSize = 4096 and the DFU 1.1 standard says:
The host sends between bMaxPacketSize0 and wTransferSize and
increments wBlockNum (which is 16 bits).
Maybe we shall increase the wTransferSize (defined at
static const struct dfu_function_descriptor dfu_func) to e.g. 32 KiB
and leave the code unchanged?
Can you test this option on your setup?
No. The code as it stands, it's just broken. You will only delay the inevitable,
i.e. the rollover that is not handled correctly.
This is just bandaid, and is not fixing the problem.
Regards
-- Pantelis
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/dfu.c | 28 +++-
drivers/dfu/dfu_mmc.c | 3 +++
include/dfu.h | 2 ++
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 1260c55..2483018 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -82,7 +82,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-name, buf, size,
blk_seq_num, dfu-offset, dfu-i_buf - dfu-i_buf_start);
-if (blk_seq_num == 0) {
+if (dfu-do_init) {
/* initial state */
dfu-crc = 0;
dfu-offset = 0;
@@ -90,6 +90,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+dfu-do_init = 0;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -97,7 +99,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
-dfu-i_blk_seq_num++;
+/* handle rollover */
+dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
/* flush buffer if overflow */
if ((dfu-i_buf + size) dfu-i_buf_end) {
@@ -106,6 +109,13 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) ret = tret;
}
+/* we should be in buffer now (if not then size too large) */
+if ((dfu-i_buf + size) dfu-i_buf_end) {
+printf(%s: Wrong size! [%d] [%d] - \n,
+ __func__, dfu-i_blk_seq_num, blk_seq_num,
size);
+return -1;
+}
+
memcpy(dfu-i_buf, buf, size);
dfu-i_buf += size;
@@ -120,7 +130,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) if (size == 0) {
debug(%s: DFU complete CRC32: 0x%x\n, __func__,
dfu-crc);
-puts(\nDownload complete\n);
+printf(\nDownload complete (CRC32 0x%04x)\n,
dfu-crc);
/* clear everything */
dfu-crc = 0;
@@ -129,6 +139,9 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+dfu-do_init = 1;
+
}
return ret = 0 ? size : ret;
@@ -190,7 +203,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) debug(%s: name: %s buf: 0x%p size: 0x%x
p_num: 0x%x i_buf: 0x%p\n, __func__, dfu-name, buf, size,
blk_seq_num, dfu-i_buf);
-if (blk_seq_num == 0) {
+if (dfu-do_init) {
ret = dfu-read_medium(dfu, 0, NULL, dfu-r_left);
if (ret != 0) {
debug(%s: failed to get r_left\n,
__func__); @@ -206,6 +219,8 @@ int dfu_read(struct dfu_entity *dfu,
void *buf, int size, int blk_seq_num) dfu-i_buf_end = dfu_buf +
sizeof(dfu_buf); dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+dfu-do_init = 0;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -213,7 +228,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
-dfu-i_blk_seq_num++;
+/* handle rollover */
+dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
ret = dfu_read_buffer_fill(dfu, buf, size);
if (ret 0) {
@@ -232,6 +248,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+
Re: [U-Boot] [PATCH] dfu: Handle large transfers correctly
Hi Pantelis,
Please see below comments.
Moreover this patch doesn't solve the problem of bricking trats board
after flashing it with dfu after applying:
[U-Boot] [PATCH] dfu: Handle large transfers correctly
on top of:
[U-Boot] [PATCH 00/10] USB: Gadget DFU related fixes
Without your patches it works, so thorough examination is needed.
I will have time to do that after weekend.
The sequence number is a 16 bit counter; make sure we
handle rollover correctly. This fixes the wrong transfers for
large ( 256MB) images.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/dfu.c | 28 +++-
drivers/dfu/dfu_mmc.c | 3 +++
include/dfu.h | 2 ++
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 1260c55..2483018 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -82,7 +82,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-name, buf, size,
blk_seq_num, dfu-offset, dfu-i_buf - dfu-i_buf_start);
- if (blk_seq_num == 0) {
+ if (dfu-do_init) {
/* initial state */
dfu-crc = 0;
dfu-offset = 0;
@@ -90,6 +90,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+ dfu-do_init = 0;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -97,7 +99,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
- dfu-i_blk_seq_num++;
+ /* handle rollover */
+ dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
/* flush buffer if overflow */
if ((dfu-i_buf + size) dfu-i_buf_end) {
@@ -106,6 +109,13 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) ret = tret;
}
+ /* we should be in buffer now (if not then size too large) */
+ if ((dfu-i_buf + size) dfu-i_buf_end) {
+ printf(%s: Wrong size! [%d] [%d] - \n,
+__func__, dfu-i_blk_seq_num, blk_seq_num,
size);
Missing %d for size parameter.
+ return -1;
+ }
+
memcpy(dfu-i_buf, buf, size);
dfu-i_buf += size;
@@ -120,7 +130,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) if (size == 0) {
debug(%s: DFU complete CRC32: 0x%x\n, __func__,
dfu-crc);
- puts(\nDownload complete\n);
+ printf(\nDownload complete (CRC32 0x%04x)\n,
dfu-crc);
/* clear everything */
dfu-crc = 0;
@@ -129,6 +139,9 @@ int dfu_write(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+ dfu-do_init = 1;
+
}
return ret = 0 ? size : ret;
@@ -190,7 +203,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) debug(%s: name: %s buf: 0x%p size: 0x%x
p_num: 0x%x i_buf: 0x%p\n, __func__, dfu-name, buf, size,
blk_seq_num, dfu-i_buf);
- if (blk_seq_num == 0) {
+ if (dfu-do_init) {
ret = dfu-read_medium(dfu, 0, NULL, dfu-r_left);
if (ret != 0) {
debug(%s: failed to get r_left\n,
__func__); @@ -206,6 +219,8 @@ int dfu_read(struct dfu_entity *dfu,
void *buf, int size, int blk_seq_num) dfu-i_buf_end = dfu_buf +
sizeof(dfu_buf); dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+ dfu-do_init = 0;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -213,7 +228,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) __func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
- dfu-i_blk_seq_num++;
+ /* handle rollover */
+ dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
ret = dfu_read_buffer_fill(dfu, buf, size);
if (ret 0) {
@@ -232,6 +248,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
int size, int blk_seq_num) dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+ dfu-do_init = 1;
}
return ret;
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 4c8994b..906df55 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -234,5 +234,8 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu,
char *s) dfu-read_medium = dfu_read_medium_mmc;
dfu-write_medium = dfu_write_medium_mmc;
+ /* initial state */
+ dfu-do_init = 1;
+
return 0;
}
diff --git a/include/dfu.h b/include/dfu.h
index b662488..0ce91b7 100644
---
[U-Boot] [PATCH v0] mmc: forced sector mode when accessing OCR register
Some eMMC require this setting to work properly. Tested on: - Toshiba THGBM2G8D8FBAIB (the one giving the problem) - Toshiba THGBM4G4D1HBAR - Micron MTFC4GMVEA - Hynix H26M64002BNR - SanDisk SDIN5E1-32G Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it --- drivers/mmc/mmc.c |3 ++- include/mmc.h |1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 5ffd8c5..cf66811 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -530,7 +530,8 @@ static int mmc_send_op_cond(struct mmc *mmc) cmd.cmdarg = (mmc_host_is_spi(mmc) ? 0 : (mmc-voltages (cmd.response[0] OCR_VOLTAGE_MASK)) | -(cmd.response[0] OCR_ACCESS_MODE)); +(cmd.response[0] OCR_ACCESS_MODE)) | +OCR_ACCESS_SECTOR_MODE; if (mmc-host_caps MMC_MODE_HC) cmd.cmdarg |= OCR_HCS; diff --git a/include/mmc.h b/include/mmc.h index a13e2bd..f1314d8 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -108,6 +108,7 @@ #define OCR_HCS 0x4000 #define OCR_VOLTAGE_MASK 0x007FFF80 #define OCR_ACCESS_MODE 0x6000 +#define OCR_ACCESS_SECTOR_MODE (1 30) #define SECURE_ERASE 0x8000 -- 1.7.9.5 Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite. This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v0] davinci, mmc: Added a delay reading ext CSD register
Without this additional delay, some eMMC don't negotiate properly bus width
Tested on:
- Toshiba THGBM2G8D8FBAIB
- Toshiba THGBM4G4D1HBAR
- Micron MTFC4GMVEA (the one giving the problem)
- Hynix H26M64002BNR
- SanDisk SDIN5E1-32G
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
drivers/mmc/davinci_mmc.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
index ee8f261..d5a38a7 100644
--- a/drivers/mmc/davinci_mmc.c
+++ b/drivers/mmc/davinci_mmc.c
@@ -285,8 +285,11 @@ dmmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
*/
if (bytes_left fifo_bytes)
dmmc_wait_fifo_status(regs, 0x4a);
- else if (bytes_left == fifo_bytes)
+ else if (bytes_left == fifo_bytes) {
dmmc_wait_fifo_status(regs, 0x40);
+if (cmd-cmdidx == MMC_CMD_SEND_EXT_CSD)
+ udelay(600);
+ }
for (i = 0; bytes_left (i fifo_words); i++) {
cmddata = get_val(regs-mmcdrr);
--
1.7.9.5
Ce message, ainsi que tous les fichiers joints à ce message,
peuvent contenir des informations sensibles et/ ou confidentielles
ne devant pas être divulguées. Si vous n'êtes pas le destinataire
de ce message (ou que vous recevez ce message par erreur), nous
vous remercions de le notifier immédiatement à son expéditeur, et
de détruire ce message. Toute copie, divulgation, modification,
utilisation ou diffusion, non autorisée, directe ou indirecte, de
tout ou partie de ce message, est strictement interdite.
This e-mail, and any document attached hereby, may contain
confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dfu: Handle large transfers correctly (take #2)
The sequence number is a 16 bit counter; make sure we
handle rollover correctly. This fixes the wrong transfers for
large ( 256MB) images.
Also utilize a variable to handle initialization, so that we
don't rely on just the counter sent by the host.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/dfu/dfu.c | 42 +-
drivers/dfu/dfu_mmc.c | 3 +++
include/dfu.h | 2 ++
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 1260c55..fb9b417 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -82,7 +82,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
__func__, dfu-name, buf, size, blk_seq_num, dfu-offset,
dfu-i_buf - dfu-i_buf_start);
- if (blk_seq_num == 0) {
+ if (!dfu-inited) {
/* initial state */
dfu-crc = 0;
dfu-offset = 0;
@@ -90,6 +90,8 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+ dfu-inited = 1;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -97,7 +99,22 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
__func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
- dfu-i_blk_seq_num++;
+
+ /* DFU 1.1 standard says:
+* The wBlockNum field is a block sequence number. It increments each
+* time a block is transferred, wrapping to zero from 65,535. It is used
+* to provide useful context to the DFU loader in the device.
+*
+* This means that it's a 16 bit counter that roll-overs at
+* 0x - 0x. By having a typical 4K transfer block
+* we roll-over at exactly 256MB. Not very fun to debug.
+*
+* Handling rollover, and having an inited variable,
+* makes things work.
+*/
+
+ /* handle rollover */
+ dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
/* flush buffer if overflow */
if ((dfu-i_buf + size) dfu-i_buf_end) {
@@ -106,6 +123,13 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
ret = tret;
}
+ /* we should be in buffer now (if not then size too large) */
+ if ((dfu-i_buf + size) dfu-i_buf_end) {
+ printf(%s: Wrong size! [%d] [%d] - %d\n,
+ __func__, dfu-i_blk_seq_num, blk_seq_num, size);
+ return -1;
+ }
+
memcpy(dfu-i_buf, buf, size);
dfu-i_buf += size;
@@ -120,7 +144,7 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
if (size == 0) {
debug(%s: DFU complete CRC32: 0x%x\n, __func__, dfu-crc);
- puts(\nDownload complete\n);
+ printf(\nDownload complete (CRC32 0x%04x)\n, dfu-crc);
/* clear everything */
dfu-crc = 0;
@@ -129,6 +153,9 @@ int dfu_write(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf_start = dfu_buf;
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
+
+ dfu-inited = 0;
+
}
return ret = 0 ? size : ret;
@@ -190,7 +217,7 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
debug(%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x i_buf: 0x%p\n,
__func__, dfu-name, buf, size, blk_seq_num, dfu-i_buf);
- if (blk_seq_num == 0) {
+ if (!dfu-inited) {
ret = dfu-read_medium(dfu, 0, NULL, dfu-r_left);
if (ret != 0) {
debug(%s: failed to get r_left\n, __func__);
@@ -206,6 +233,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+ dfu-inited = 1;
}
if (dfu-i_blk_seq_num != blk_seq_num) {
@@ -213,7 +242,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
__func__, dfu-i_blk_seq_num, blk_seq_num);
return -1;
}
- dfu-i_blk_seq_num++;
+ /* handle rollover */
+ dfu-i_blk_seq_num = (dfu-i_blk_seq_num + 1) 0x;
ret = dfu_read_buffer_fill(dfu, buf, size);
if (ret 0) {
@@ -232,6 +262,8 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
int blk_seq_num)
dfu-i_buf_end = dfu_buf + sizeof(dfu_buf);
dfu-i_buf = dfu-i_buf_start;
dfu-b_left = 0;
+
+
[U-Boot] mtd/cfi: SST39VF3201B flash model not properly handled
Dear All, as Wolfgang Denx suggested me, i am trying to use the u-boot CFI driver with a CFI flash (SSTVF3201B). This flash chip allows erasing/writing blocks of 4 KBytes (called sectors in the SST datasheet), or 64 KBytes (called blocks). The command sequence table for this flash shows 2 different commands to operate on these 2 kind of blocks. 0x50 is for sector erase and 0x30 (the command used from u-boot CFI driver as AMD_CMD_ERASE_SECTOR) is for the 64KB block erase. The issue: now, u-boot CFI driver works fine on 64KB boundary ranges, but if i expect to erase a 4KB sector size i get a full 64KB block erased. Proposed solution: Initially, a single sector size definition would be good enough for this chip, so the user should specify if he wants a 64 or 4 KB sector to be used, using some CFG_X. CFI driver, through queries, should be able to identify this particular chip so that it can be handled in a specific way from the CFI driver (cmd 0x50 for 4KB secotrs, or 0x30 for 64KB secotrs). I am thinking about to post a patch on this. Anyway, until new AMCORE board patch is not accepted, there is the chance this can result as a dead code if no-one use this flash chip except me. So, before i start, please let me know how to proceed, maybe is better to use a specific flash.c for my board for now ? Or if you think a patch can be useful, any suggestion on how to implement it is really welcome. Best Regards, Angelo Dureghello ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mtd/cfi: SST39VF3201B flash model not properly handled
Hi Angelo, On 11/29/2012 01:03 PM, Angelo Dureghello wrote: as Wolfgang Denx suggested me, i am trying to use the u-boot CFI driver with a CFI flash (SSTVF3201B). Yes. But please take a look at the CONFIG_FLASH_CFI_LEGACY config option. This enables the legacy CFI flash devices. And IIRC the SST flash chips are supported via this driver/extension. This flash chip allows erasing/writing blocks of 4 KBytes (called sectors in the SST datasheet), or 64 KBytes (called blocks). The command sequence table for this flash shows 2 different commands to operate on these 2 kind of blocks. 0x50 is for sector erase and 0x30 (the command used from u-boot CFI driver as AMD_CMD_ERASE_SECTOR) is for the 64KB block erase. The issue: now, u-boot CFI driver works fine on 64KB boundary ranges, but if i expect to erase a 4KB sector size i get a full 64KB block erased. Proposed solution: Initially, a single sector size definition would be good enough for this chip, so the user should specify if he wants a 64 or 4 KB sector to be used, using some CFG_X. CFI driver, through queries, should be able to identify this particular chip so that it can be handled in a specific way from the CFI driver (cmd 0x50 for 4KB secotrs, or 0x30 for 64KB secotrs). I am thinking about to post a patch on this. Anyway, until new AMCORE board patch is not accepted, there is the chance this can result as a dead code if no-one use this flash chip except me. So, before i start, please let me know how to proceed, maybe is better to use a specific flash.c for my board for now ? Or if you think a patch can be useful, any suggestion on how to implement it is really welcome. Please see my comment above. And grep for CONFIG_FLASH_CFI_LEGACY to see how its used in the config header. And if necessary, you can always extend the CFI configuration in the JEDEC source: drivers/mtd/jedec_flash.c Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] README.scrapyard: add missing commit IDs
Now that the patches have made it into mainline, we can also add the commit IDs. Signed-off-by: Wolfgang Denk w...@denx.de --- doc/README.scrapyard | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/README.scrapyard b/doc/README.scrapyard index 2b868e6..9ad9296 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -11,13 +11,13 @@ easily if here is something they might want to dig for... Board ArchCPU removed Commit last known maintainer/contact = -AMX860 powerpc mpc860 - - Wolfgang Denk w...@denx.de -c2mon powerpc mpc855 - - Wolfgang Denk w...@denx.de -ETX094 powerpc mpc850 - - Wolfgang Denk w...@denx.de -IAD210 powerpc mpc860 - - - -LANTEC powerpc mpc850 - - Wolfgang Denk w...@denx.de -SCMpowerpc mpc8260 - - Wolfgang Grandegger w...@denx.de -SX1arm arm925t - - +AMX860 powerpc mpc860 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +c2mon powerpc mpc855 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +ETX094 powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +IAD210 powerpc mpc860 1b0757e 2012-10-28- +LANTEC powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +SCMpowerpc mpc8260 1b0757e 2012-10-28Wolfgang Grandegger w...@denx.de +SX1arm arm925t 53c4154 2012-10-26 TQM85xxpowerpc MPC85xx d923a5d5 2012-10-04Stefan Roese s...@denx.de apollon arm omap24xx 535c74f 2012-09-18Kyungmin Park kyungmin.p...@samsung.com tb0229 mipsmips32 3f3110d 2011-12-12 -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] usb: Fix bug when both DFU ETHER are defined
Dear Pantelis Antoniou, When both CONFIG_USB_GADGET CONFIG_USB_ETHER are defined the makefile links objects twice. Detect this and fix it with a not very elegant way in the makefile. Revisit and clean it later. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [...] This really needs some proper thinking and fixing. Besides ... can you please annotate the patches with proper V2: and a proper changelog, see [1]? [1] http://www.denx.de/wiki/U-Boot/Patches 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 00/10] USB: Gadget DFU related fixes
Dear Pantelis Antoniou, Various bugfixes, g_dnl DFU updates. Pantelis Antoniou (10): usb: Remove obsolete header file usb: Fix bug when both DFU ETHER are defined g_dnl: Issue connect/disconnect as appropriate g_dnl: Properly terminate string list. dfu: Only perform DFU board_usb_init() for TRATS dfu: Fix crash when wrong number of arguments given dfu: Send correct DFU response from composite_setup dfu: Properly zero out timeout value dfu: Add a partition type target dfu: Support larger than memory transfers. [...] Please address the few issues I pointed out and send a proper V2. Thanks! 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 04/10] g_dnl: Properly terminate string list.
Dear Pantelis Antoniou,
Well, not terminating the list causes very interesting crashes.
As in changing the vendor product ID crashes. Fun.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/usb/gadget/g_dnl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 25da733..a5a4c1f 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -69,6 +69,7 @@ static struct usb_device_descriptor device_desc = {
static struct usb_string g_dnl_string_defs[] = {
{ 0, manufacturer, },
{ 1, product, },
+ { }/* end of list */
So you're adding an uninited entry here? How'll this work?
};
static struct usb_gadget_strings g_dnl_string_tab = {
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver
Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 8:53 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2012-11-29 klockan 07:27 +0100 skrev Marek Vasut: Dear yegorsli...@googlemail.com, From: Yegor Yefremov yegorsli...@googlemail.com The driver code was taken from Linux kernel source: drivers/net/phy/icplus.c Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com [...] Is there any user for this PHY please? I don't have one, but know at least one user having one in an A10 based netbook. http://linux-sunxi.org/File:H6-netbook-mainboard.jpg I found these boards in kernel: arch/mips/configs/malta_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/bcm47xx_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/ip27_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/sead3_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/83xx/mpc832x_rdb_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc83xx_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ICPLUS_PHY=m Sure, but the question/point is ... won't this be dead code in u-boot? It won't once you add at least one board that actually uses it ... adding it only so it's there will only cause it to bitrot and it'll actually only add more burden to maintainers. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pxa25x_udc: Remove usbdescriptors.h
usbdescriptors.h conflicts with linux/usb/ch9.h. Remove it. Signed-off-by: Lukasz Dalek luk0...@gmail.com --- drivers/usb/gadget/pxa25x_udc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c index dd74143..9ce98f0 100644 --- a/drivers/usb/gadget/pxa25x_udc.c +++ b/drivers/usb/gadget/pxa25x_udc.c @@ -40,7 +40,6 @@ #include asm/io.h #include asm/arch/pxa.h -#include usbdescriptors.h #include linux/usb/ch9.h #include linux/usb/gadget.h #include usb/lin_gadget_compat.h -- 1.7.8.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver
On Thu, Nov 29, 2012 at 1:55 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 8:53 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2012-11-29 klockan 07:27 +0100 skrev Marek Vasut: Dear yegorsli...@googlemail.com, From: Yegor Yefremov yegorsli...@googlemail.com The driver code was taken from Linux kernel source: drivers/net/phy/icplus.c Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com [...] Is there any user for this PHY please? I don't have one, but know at least one user having one in an A10 based netbook. http://linux-sunxi.org/File:H6-netbook-mainboard.jpg I found these boards in kernel: arch/mips/configs/malta_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/bcm47xx_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/ip27_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/sead3_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/83xx/mpc832x_rdb_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc83xx_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ICPLUS_PHY=m Sure, but the question/point is ... won't this be dead code in u-boot? It won't once you add at least one board that actually uses it ... adding it only so it's there will only cause it to bitrot and it'll actually only add more burden to maintainers. It won't be dead code, because we will use it :-) Our board is derivative of BeagleBone Co, so the whole support stuff is already in u-boot. I can also image that some system didn't require network support in u-boot and didn't bother with implementing the phy driver. x86 systems are likely to have this phy too. And the driver is really small and uses mostly generic routines. Yegor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] g_dnl: Properly terminate string list.
Hi Marek,
On Nov 29, 2012, at 10:20 AM, Marek Vasut wrote:
Dear Pantelis Antoniou,
Well, not terminating the list causes very interesting crashes.
As in changing the vendor product ID crashes. Fun.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/usb/gadget/g_dnl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 25da733..a5a4c1f 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -69,6 +69,7 @@ static struct usb_device_descriptor device_desc = {
static struct usb_string[] = {
{ 0, manufacturer, },
{ 1, product, },
+{ }/* end of list */
So you're adding an uninited entry here? How'll this work?
This is very common idiom. It's not uninitialized, all the members are
set to 0, including the char * members.
It is exactly the same method used in drivers/usb/gadget/ether.c
};
static struct usb_gadget_strings g_dnl_string_tab = {
Best regards,
Marek Vasut
Regards
-- Pantelis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
On Wed, Nov 28, 2012 at 01:39:06AM -0600, Andy Fleming wrote: The following changes since commit 66dc452bfe13b0e276adddf3997b9c5abc00115d: Remove obsolete header file (2012-11-27 09:41:10 -0700) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to afbfdf545090472b734367ac2c874bfbe8928790: powerpc/mpc85xx: Fix a bug introduced by CONFIG_PPC_SPINTABLE_COMPATIBLE (2012-11-27 18:28:08 -0600) Andy Fleming (1): 8xxx: Change all 8*xx_DDR addresses to 8xxx Kim Phillips (1): powerpc/mpc8xxx: take fdt_fixup_crypto_node() off the checkstack list Timur Tabi (5): powerpc/85xx/p5040: add CONFIG_SYS_PPC64, del CONFIG_SYS_FSL_ELBC_MULTIBIT_ECC powerpc/85xx: add support for the Freescale P5040DS Superhydra reference board powerpc/85xx: implement check for erratum A-004849 work-around powerpc/85xx: implement check for erratum A-004580 work-around powerpc/85xx: update the work-around for P4080 erratum SERDES-9 York Sun (5): powerpc/qoriq: Move FMAN microcode location powerpc/corenet_ds: Update DDR timing for single-rank DIMMs powerpc/P2041RDB: Fix Flash address LAW address powerpc/mpc85xx: Temporary fix for spin table backward compatibility powerpc/mpc85xx: Fix a bug introduced by CONFIG_PPC_SPINTABLE_COMPATIBLE Yuanquan Chen (1): powerpc/p4080ds: fix PCI-e x8 link training down failure Zang Roy-R61911 (1): powerpc/corenet_ds: move SATA config to board configuration arch/powerpc/cpu/mpc85xx/cmd_errata.c | 114 arch/powerpc/cpu/mpc85xx/cpu.c| 14 +- arch/powerpc/cpu/mpc85xx/cpu_init.c | 12 + arch/powerpc/cpu/mpc85xx/ddr-gen1.c |4 +- arch/powerpc/cpu/mpc85xx/ddr-gen2.c |9 +- arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 14 +- arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c | 20 +- arch/powerpc/cpu/mpc85xx/release.S| 35 +- arch/powerpc/cpu/mpc86xx/ddr-8641.c |4 +- arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 10 +- arch/powerpc/cpu/mpc8xxx/ddr/util.c | 14 +- arch/powerpc/cpu/mpc8xxx/fdt.c|6 +- arch/powerpc/include/asm/config_mpc85xx.h | 20 +- arch/powerpc/include/asm/immap_83xx.h |6 +- arch/powerpc/include/asm/immap_85xx.h | 27 +- arch/powerpc/include/asm/immap_86xx.h |8 +- board/exmeritus/hww1u1a/hww1u1a.c |2 +- board/freescale/common/Makefile |2 + board/freescale/common/ngpixis.h |2 +- board/freescale/corenet_ds/Makefile |2 + board/freescale/corenet_ds/corenet_ds.c | 22 +- board/freescale/corenet_ds/ddr.c |4 +- board/freescale/corenet_ds/eth_superhydra.c | 722 + board/freescale/corenet_ds/p5040ds_ddr.c | 18 + board/freescale/mpc8540ads/mpc8540ads.c |2 +- board/freescale/mpc8560ads/mpc8560ads.c |2 +- board/freescale/mpc8569mds/mpc8569mds.c |2 +- board/freescale/p1023rds/p1023rds.c |2 +- board/freescale/p1_p2_rdb_pc/spl_minimal.c|2 +- board/freescale/p2020ds/p2020ds.c |2 +- board/sbc8548/ddr.c |2 +- board/socrates/sdram.c|2 +- boards.cfg|1 + drivers/net/fm/Makefile |1 + drivers/net/fm/p5040.c| 113 drivers/pci/fsl_pci_init.c| 22 + include/configs/P1010RDB.h|1 + include/configs/P1022DS.h |1 + include/configs/P1023RDS.h|2 +- include/configs/P2041RDB.h| 20 +- include/configs/P3041DS.h |1 + include/configs/P5020DS.h |1 + include/configs/P5040DS.h | 40 ++ include/configs/corenet_ds.h |2 +- nand_spl/board/freescale/p1010rdb/nand_boot.c |2 +- nand_spl/board/freescale/p1023rds/nand_boot.c |2 +- 46 files changed, 1207 insertions(+), 109 deletions(-) create mode 100644 board/freescale/corenet_ds/eth_superhydra.c create mode 100644 board/freescale/corenet_ds/p5040ds_ddr.c create mode 100644 drivers/net/fm/p5040.c create mode 100644 include/configs/P5040DS.h Really, this has now been applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Wed, Nov 28, 2012 at 11:52:21AM -0800, Simon Glass wrote:
Hi Tom,
(This is my first pull request for x86, so please view it with
suspicion and let me know of any steps I have missed, etc.)
The following changes since commit d41b3cc16fd97da23900f79e8fefdeedeebde8f6:
Merge branch 'master' of git://git.denx.de/u-boot-mips (2012-11-27
20:34:51 -0700)
are available in the git repository at:
http://git.denx.de/u-boot-x86.git master
Usual form is to use the git:// URI, fyi.
Gabe Black (4):
x86: Allow excluding reset vector code from u-boot
x86: Add some missing includes
x86: coreboot: Tell u-boot about PCI bus 0 when initializing
x86: coreboot: Implement recursively scanning PCI busses
Graeme Russ (4):
x86: Forward declare gd_t
x86: Put global data on the stack
x86: Remove duplicate PCI init
x86: Add ilog2 to bitops
Simon Glass (3):
x86: Add initial memory barrier macros
x86: Remove coreboot start16 code
x86: coreboot: Enable LPC TPM
Stefan Reinauer (1):
x86: coreboot: Move non-board specific files to coreboot arch directory
Vadim Bendebury (1):
x86: coreboot: Modify u-boot code to allow building coreboot payload
Makefile |6 +-
README |4 +
arch/x86/cpu/Makefile |5 +-
arch/x86/cpu/coreboot/Makefile |2 +
.../x86/cpu}/coreboot/coreboot.c |0
.../coreboot_pci.c = arch/x86/cpu/coreboot/pci.c | 35 ++
arch/x86/cpu/cpu.c |6 --
arch/x86/cpu/start.S | 67 +--
arch/x86/cpu/u-boot.lds|3 +
arch/x86/include/asm/bitops.h |5 ++
arch/x86/include/asm/global_data.h | 11 ++-
arch/x86/include/asm/init_helpers.h|1 -
arch/x86/include/asm/io.h |8 +++
arch/x86/include/asm/pci.h |2 +-
arch/x86/include/asm/processor.h |1 +
arch/x86/include/asm/u-boot.h |3 +
arch/x86/lib/board.c |5 +-
arch/x86/lib/init_helpers.c| 37 +---
board/chromebook-x86/coreboot/Makefile |2 -
board/chromebook-x86/coreboot/config.mk| 37 +++
board/chromebook-x86/coreboot/coreboot_start16.S | 13
include/configs/coreboot.h | 11 ++-
include/configs/eNET.h |6 --
23 files changed, 181 insertions(+), 89 deletions(-)
rename {board/chromebook-x86 = arch/x86/cpu}/coreboot/coreboot.c (100%)
rename board/chromebook-x86/coreboot/coreboot_pci.c =
arch/x86/cpu/coreboot/pci.c (51%)
create mode 100644 board/chromebook-x86/coreboot/config.mk
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot for MIPS AR7161
Dear Dmytro and others,
Sorry, I didn't post the output in the previous post, just the commands.
I am going to post the full output below, along with the details of the
ar71xx.cfg file, and output from openocd also.
The config file originally came from an AR724x processor as well, so it might
not be correct for an AR71xx.
I would appreciate assistance in identifying the mistakes and correcting them
if you don't mind please.
Please share with myself and others if you can.
The code that I am attempting to run in the processor, again for the AR724x, is
8Muboot_RAM_version.bin
It can be found easily on the internet with a google search. If you have the
expertise to identify what can be changed to make this compatile with the
AR71xx, please do.
This code partially runs because upon execution, it turns on an LED on the
board. However, it gives no UART output that I can see.
I am still interested in porting U-Boot to this processor as well, and I have
found bits and pieces of previous work done, but nothing that I can identify as
compelte.
MIPS does not seem to be in the main line for U-Boot, but I might be mistaken,
correct me if I am wrong here.
My experience is limited with MIPS archetecture, but I would be willing to
assist in a port, and testing on the hardware that I have.
Thanks,
Allan Drassal
output from openocd, (./bin/openocd -f interface/sheevaplug.cfg -f ar71xx.cfg):
Open On-Chip Debugger 0.6.1 (2012-11-23-20:49)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
131072
Info : clock speed 1000 kHz
Info : JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part:
0x, ver: 0x0)
Info : accepting 'telnet' connection from
Info : JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part:
0x, ver: 0x0)
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380
Info : JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part:
0x, ver: 0x0)
Warn : target not halted
in procedure 'mww'
Warn : target not halted
in procedure 'mww'
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380
in procedure 'mww'
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380
Info : JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part:
0x, ver: 0x0)
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc0
262144 bytes written at address 0x8000
downloaded 262144 bytes in 4.165334s (61.460 KiB/s)
output from the telnet session (telnet 127.0.0.1 ):
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Open On-Chip Debugger
reset
JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part: 0x,
ver: 0x0)
halt
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380
reset
JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part: 0x,
ver: 0x0)
mww 0xb8060008 3
target not halted
in procedure 'mww'
mww 0xb806000c 0x12c
target not halted
in procedure 'mww'
halt
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380
mww 0xb805 0x00090828
mww 0xb805 0x00050828
mww 0xb805 0x00040828
mww 0xb8050008 2
mww 0xb8050008 3
in procedure 'mww'
halt
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc00380
reset init
JTAG tap: ar71xx.cpu tap/device found: 0x0001 (mfg: 0x000, part: 0x,
ver: 0x0)
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc0
load_image 8Muboot_RAM_version.bin 0x8000
262144 bytes written at address 0x8000
downloaded 262144 bytes in 4.165334s (61.460 KiB/s)
resume 0x8000
ar71xx.cfg:
# Atheros AR71xx MIPS 24Kc SoC.
# tested on PB44 refererence board
adapter_nsrst_delay 100
jtag_ntrst_delay 100
reset_config trst_and_srst
set CHIPNAME ar71xx
jtag newtap $CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id 1
set TARGETNAME $CHIPNAME.cpu
target create $TARGETNAME mips_m4k -endian big -chain-position $TARGETNAME
$TARGETNAME configure -event reset-halt-post {
#setup PLL to lowest common denominator 300/300/150 setting
mww 0xb805 0x40140180 ;# reset val + CPU:3 DDR:3 AHB:0
mww 0xb805 0xc0140180 ;# send to PLL
#next command will reset for PLL changes to take effect
mww 0xb8050008 3;# set reset_switch and clock_switch
(resets SoC)
}
$TARGETNAME configure -event reset-init {
#complete pll initialization
mww 0xb805 0x800f0080 ;# set sw_update bit
mww 0xb8050008 0;# clear reset_switch bit
mww 0xb805
Re: [U-Boot] [PATCH] pxa25x_udc: Remove usbdescriptors.h
Dear Lukasz Dalek, usbdescriptors.h conflicts with linux/usb/ch9.h. Remove it. Applied, thanks Signed-off-by: Lukasz Dalek luk0...@gmail.com --- drivers/usb/gadget/pxa25x_udc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c index dd74143..9ce98f0 100644 --- a/drivers/usb/gadget/pxa25x_udc.c +++ b/drivers/usb/gadget/pxa25x_udc.c @@ -40,7 +40,6 @@ #include asm/io.h #include asm/arch/pxa.h -#include usbdescriptors.h #include linux/usb/ch9.h #include linux/usb/gadget.h #include usb/lin_gadget_compat.h 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 04/10] g_dnl: Properly terminate string list.
Dear Pantelis Antoniou,
Hi Marek,
On Nov 29, 2012, at 10:20 AM, Marek Vasut wrote:
Dear Pantelis Antoniou,
Well, not terminating the list causes very interesting crashes.
As in changing the vendor product ID crashes. Fun.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/usb/gadget/g_dnl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index 25da733..a5a4c1f 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -69,6 +69,7 @@ static struct usb_device_descriptor device_desc = {
static struct usb_string[] = {
{ 0, manufacturer, },
{ 1, product, },
+ { }/* end of list */
So you're adding an uninited entry here? How'll this work?
This is very common idiom. It's not uninitialized, all the members are
set to 0, including the char * members.
It is exactly the same method used in drivers/usb/gadget/ether.c
Blah, it's a matter of taste then (I prefer it explicit, but I don't really
care).
Thanks for clearing this up.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver
Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 1:55 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 8:53 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2012-11-29 klockan 07:27 +0100 skrev Marek Vasut: Dear yegorsli...@googlemail.com, From: Yegor Yefremov yegorsli...@googlemail.com The driver code was taken from Linux kernel source: drivers/net/phy/icplus.c Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com [...] Is there any user for this PHY please? I don't have one, but know at least one user having one in an A10 based netbook. http://linux-sunxi.org/File:H6-netbook-mainboard.jpg I found these boards in kernel: arch/mips/configs/malta_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/bcm47xx_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/ip27_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/sead3_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/83xx/mpc832x_rdb_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc83xx_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ICPLUS_PHY=m Sure, but the question/point is ... won't this be dead code in u-boot? It won't once you add at least one board that actually uses it ... adding it only so it's there will only cause it to bitrot and it'll actually only add more burden to maintainers. It won't be dead code, because we will use it :-) Our board is derivative of BeagleBone Co, so the whole support stuff is already in u-boot. You need to enable it for that board though ;-) I can also image that some system didn't require network support in u-boot and didn't bother with implementing the phy driver. x86 systems are likely to have this phy too. And the driver is really small and uses mostly generic routines. Yegor 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] dfu: Handle large transfers correctly (take #2)
Dear Pantelis Antoniou, The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large ( 256MB) images. Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host. [...] Uh, how come this doesn't apply ? Am I doing something wrong or is it the patch? :( Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver
On Thu, Nov 29, 2012 at 3:29 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 1:55 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 8:53 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2012-11-29 klockan 07:27 +0100 skrev Marek Vasut: Dear yegorsli...@googlemail.com, From: Yegor Yefremov yegorsli...@googlemail.com The driver code was taken from Linux kernel source: drivers/net/phy/icplus.c Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com [...] Is there any user for this PHY please? I don't have one, but know at least one user having one in an A10 based netbook. http://linux-sunxi.org/File:H6-netbook-mainboard.jpg I found these boards in kernel: arch/mips/configs/malta_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/bcm47xx_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/ip27_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/sead3_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/83xx/mpc832x_rdb_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc83xx_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ICPLUS_PHY=m Sure, but the question/point is ... won't this be dead code in u-boot? It won't once you add at least one board that actually uses it ... adding it only so it's there will only cause it to bitrot and it'll actually only add more burden to maintainers. It won't be dead code, because we will use it :-) Our board is derivative of BeagleBone Co, so the whole support stuff is already in u-boot. You need to enable it for that board though ;-) Will do this as soon as we come near to the release. I'd like to have basic stuff mainlined before. Yegor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Add L2 Cache Support.
On Thu, Nov 29, 2012 at 5:12 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch set adds L2 Cache Support to EXYNOS.
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/cpu/armv7/exynos/soc.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/soc.c b/arch/arm/cpu/armv7/exynos/soc.c
index ab65b8d..a45bbfb 100644
--- a/arch/arm/cpu/armv7/exynos/soc.c
+++ b/arch/arm/cpu/armv7/exynos/soc.c
@@ -23,6 +23,14 @@
#include common.h
#include asm/io.h
+#include asm/system.h
+
+enum l2_cache_params {
+ CACHE_TAG_RAM_SETUP = (19),
+ CACHE_DATA_RAM_SETUP = (15),
+ CACHE_TAG_RAM_LATENCY = (26),
+ CACHE_DATA_RAM_LATENCY = (20)
+};
void reset_cpu(ulong addr)
{
@@ -36,3 +44,31 @@ void enable_caches(void)
dcache_enable();
}
#endif
+
+#ifndef CONFIG_SYS_L2CACHE_OFF
+/*
+ * Set L2 cache parameters
+ */
+static void exynos5_set_l2cache_params(void)
+{
+ unsigned int val = 0;
+
+ asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r(val));
+
+ val |= CACHE_TAG_RAM_SETUP |
+ CACHE_DATA_RAM_SETUP |
+ CACHE_TAG_RAM_LATENCY |
+ CACHE_DATA_RAM_LATENCY;
+
+ asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val));
+}
+
+/*
+ * Sets L2 cache related parameters before enabling data cache
+ */
+void v7_outer_cache_enable(void)
+{
if (soc_is_exynos5250())
+ exynos5_set_l2cache_params();
Since it's not working at exynos4
Thank you,
Kyungmin Park
+}
+#endif
+
--
1.7.4.4
___
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] pxa25x_udc: Remove usbdescriptors.h
On 29.11.2012 15:27, Marek Vasut wrote: Dear Lukasz Dalek, usbdescriptors.h conflicts with linux/usb/ch9.h. Remove it. Applied, thanks Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/pxa25x_udc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c index dd74143..9ce98f0 100644 --- a/drivers/usb/gadget/pxa25x_udc.c +++ b/drivers/usb/gadget/pxa25x_udc.c @@ -40,7 +40,6 @@ #includeasm/io.h #includeasm/arch/pxa.h -#includeusbdescriptors.h #includelinux/usb/ch9.h #includelinux/usb/gadget.h #includeusb/lin_gadget_compat.h Best regards, Marek Vasut One more question. I've send you before patch which enables support for USB in h2200 device, which you accepted but didn't push. Did you find more problem out there or just forgot to apply? Łukasz Dałek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver
Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 3:29 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 1:55 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 8:53 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2012-11-29 klockan 07:27 +0100 skrev Marek Vasut: Dear yegorsli...@googlemail.com, From: Yegor Yefremov yegorsli...@googlemail.com The driver code was taken from Linux kernel source: drivers/net/phy/icplus.c Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com [...] Is there any user for this PHY please? I don't have one, but know at least one user having one in an A10 based netbook. http://linux-sunxi.org/File:H6-netbook-mainboard.jpg I found these boards in kernel: arch/mips/configs/malta_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/bcm47xx_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/ip27_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/sead3_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/83xx/mpc832x_rdb_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc83xx_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ICPLUS_PHY=m Sure, but the question/point is ... won't this be dead code in u-boot? It won't once you add at least one board that actually uses it ... adding it only so it's there will only cause it to bitrot and it'll actually only add more burden to maintainers. It won't be dead code, because we will use it :-) Our board is derivative of BeagleBone Co, so the whole support stuff is already in u-boot. You need to enable it for that board though ;-) Will do this as soon as we come near to the release. Release of what? The hardware? I'd like to have basic stuff mainlined before. Well, I'll leave that up to Joe anyway 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] pxa25x_udc: Remove usbdescriptors.h
Dear Łukasz Dałek, On 29.11.2012 15:27, Marek Vasut wrote: Dear Lukasz Dalek, usbdescriptors.h conflicts with linux/usb/ch9.h. Remove it. Applied, thanks Signed-off-by: Lukasz Dalekluk0...@gmail.com --- drivers/usb/gadget/pxa25x_udc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c index dd74143..9ce98f0 100644 --- a/drivers/usb/gadget/pxa25x_udc.c +++ b/drivers/usb/gadget/pxa25x_udc.c @@ -40,7 +40,6 @@ #includeasm/io.h #includeasm/arch/pxa.h -#includeusbdescriptors.h #includelinux/usb/ch9.h #includelinux/usb/gadget.h #includeusb/lin_gadget_compat.h Best regards, Marek Vasut One more question. I've send you before patch which enables support for USB in h2200 device, which you accepted but didn't push. Did you find more problem out there or just forgot to apply? It might have gone lost ... can you repost? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7] h2200: Add USB CDC ethernet support
Add support for ethernet over USB which can be used for e.g. booting
process. It works with tftp and dhcp clients code.
Signed-off-by: Lukasz Dalek luk0...@gmail.com
---
Changes for v7:
- Removed CONFIG_H2200_USBETH
Changes for v6:
- Defined only one entire for board
Changes for v5:
- Surrendered #include usb.h with CONFIGs
---
board/h2200/h2200.c | 11 +++
include/configs/h2200.h | 25 +
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/board/h2200/h2200.c b/board/h2200/h2200.c
index 3076306..720b06e 100644
--- a/board/h2200/h2200.c
+++ b/board/h2200/h2200.c
@@ -22,9 +22,16 @@
#include asm/arch/pxa.h
#include asm/arch/pxa-regs.h
#include asm/io.h
+#include usb.h
DECLARE_GLOBAL_DATA_PTR;
+int board_eth_init(bd_t *bis)
+{
+ usb_eth_initialize(bis);
+ return 0;
+}
+
int board_init(void)
{
/* We have RAM, disable cache */
@@ -36,6 +43,10 @@ int board_init(void)
/* adress of boot parameters */
gd-bd-bi_boot_params = 0xa100;
+ /* Let host see that device is disconnected */
+ udc_disconnect();
+ mdelay(500);
+
return 0;
}
diff --git a/include/configs/h2200.h b/include/configs/h2200.h
index ef14dd3..516a26e 100644
--- a/include/configs/h2200.h
+++ b/include/configs/h2200.h
@@ -154,4 +154,29 @@
#define CONFIG_BOOTARGS root=/dev/ram0 ro console=ttyS0,115200n8
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_USB_DEV_PULLUP_GPIO 33
+/* USB VBUS GPIO 3 */
+
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_PING
+
+#define CONFIG_BOOTDELAY 2
+#define CONFIG_BOOTCOMMAND \
+ setenv downloaded 0 ; while test $downloaded -eq 0 ; do \
+ if bootp ; then setenv downloaded 1 ; fi ; done ; \
+ source :script ; \
+ bootm ;
+
+#define CONFIG_USB_GADGET_PXA2XX
+#define CONFIG_USB_ETHER
+#define CONFIG_USB_ETH_SUBSET
+
+#define CONFIG_USBNET_DEV_ADDR de:ad:be:ef:00:01
+#define CONFIG_USBNET_HOST_ADDRde:ad:be:ef:00:02
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ stdin=serial\0 \
+ stdout=serial\0 \
+ stderr=serial\0
+
#endif /* __CONFIG_H */
--
1.7.8.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: add ICPlus PHY driver
On Thu, Nov 29, 2012 at 3:51 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 3:29 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 1:55 PM, Marek Vasut ma...@denx.de wrote: Dear Yegor Yefremov, On Thu, Nov 29, 2012 at 8:53 AM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2012-11-29 klockan 07:27 +0100 skrev Marek Vasut: Dear yegorsli...@googlemail.com, From: Yegor Yefremov yegorsli...@googlemail.com The driver code was taken from Linux kernel source: drivers/net/phy/icplus.c Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com [...] Is there any user for this PHY please? I don't have one, but know at least one user having one in an A10 based netbook. http://linux-sunxi.org/File:H6-netbook-mainboard.jpg I found these boards in kernel: arch/mips/configs/malta_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/bcm47xx_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/ip27_defconfig:CONFIG_ICPLUS_PHY=m arch/mips/configs/sead3_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc512x_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/52xx/motionpro_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/83xx/mpc832x_rdb_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/mpc83xx_defconfig:CONFIG_ICPLUS_PHY=y arch/powerpc/configs/ppc6xx_defconfig:CONFIG_ICPLUS_PHY=m Sure, but the question/point is ... won't this be dead code in u-boot? It won't once you add at least one board that actually uses it ... adding it only so it's there will only cause it to bitrot and it'll actually only add more burden to maintainers. It won't be dead code, because we will use it :-) Our board is derivative of BeagleBone Co, so the whole support stuff is already in u-boot. You need to enable it for that board though ;-) Will do this as soon as we come near to the release. Release of what? The hardware? Release of hardware and when two more patches hit main line u-boot: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/147860 http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/147859 I'd like to have basic stuff mainlined before. Well, I'll leave that up to Joe anyway O.K. Yegor ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v0] mmc: forced sector mode when accessing OCR register
Hi, i didn't understand why need to set by force? Best Regards, Jaehoon Chung 2012/11/29 Davide Bonfanti davide.bonfa...@bticino.it: Some eMMC require this setting to work properly. Tested on: - Toshiba THGBM2G8D8FBAIB (the one giving the problem) - Toshiba THGBM4G4D1HBAR - Micron MTFC4GMVEA - Hynix H26M64002BNR - SanDisk SDIN5E1-32G Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it --- drivers/mmc/mmc.c |3 ++- include/mmc.h |1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 5ffd8c5..cf66811 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -530,7 +530,8 @@ static int mmc_send_op_cond(struct mmc *mmc) cmd.cmdarg = (mmc_host_is_spi(mmc) ? 0 : (mmc-voltages (cmd.response[0] OCR_VOLTAGE_MASK)) | -(cmd.response[0] OCR_ACCESS_MODE)); +(cmd.response[0] OCR_ACCESS_MODE)) | +OCR_ACCESS_SECTOR_MODE; if (mmc-host_caps MMC_MODE_HC) cmd.cmdarg |= OCR_HCS; diff --git a/include/mmc.h b/include/mmc.h index a13e2bd..f1314d8 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -108,6 +108,7 @@ #define OCR_HCS 0x4000 #define OCR_VOLTAGE_MASK 0x007FFF80 #define OCR_ACCESS_MODE 0x6000 +#define OCR_ACCESS_SECTOR_MODE (1 30) #define SECURE_ERASE 0x8000 -- 1.7.9.5 Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite. This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___ 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] mmc: Split device init to decouple OCR-polling delay
Hi Simon,
Is it saved the 200ms? Could you tell me your environment?
I will check this patch..and share the result.
Best Regards,
Jaehoon Chung
2012/11/29 Simon Glass s...@chromium.org:
From: Che-Liang Chiou clch...@chromium.org
Most of time that MMC driver spends on initializing a device is polling
OCR (operation conditions register). To decouple this polling loop,
device init is split into two parts: The first part fires the OCR query
command, and the second part polls the result. So the caller is now no
longer bound to the OCR-polling delay; he may fire the query, go
somewhere and then come back later for the result.
To use this, call mmc_set_preinit() on any device which needs this.
This can save significant amounts of time on boot (e.g. 200ms) by
hiding the MMC init time behind other init.
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Rebase to master
drivers/mmc/mmc.c | 137
include/mmc.h | 30
2 files changed, 135 insertions(+), 32 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 72e8ce6..09695e8 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -503,48 +503,70 @@ static int sd_send_op_cond(struct mmc *mmc)
return 0;
}
-static int mmc_send_op_cond(struct mmc *mmc)
+/* We pass in the cmd since otherwise the init seems to fail */
+static int mmc_send_op_cond_iter(struct mmc *mmc, struct mmc_cmd *cmd,
+ int use_arg)
{
- int timeout = 1;
- struct mmc_cmd cmd;
int err;
+ cmd-cmdidx = MMC_CMD_SEND_OP_COND;
+ cmd-resp_type = MMC_RSP_R3;
+ cmd-cmdarg = 0;
+ if (use_arg !mmc_host_is_spi(mmc)) {
+ cmd-cmdarg =
+ (mmc-voltages
+ (mmc-op_cond_response OCR_VOLTAGE_MASK)) |
+ (mmc-op_cond_response OCR_ACCESS_MODE);
+
+ if (mmc-host_caps MMC_MODE_HC)
+ cmd-cmdarg |= OCR_HCS;
+ }
+ err = mmc_send_cmd(mmc, cmd, NULL);
+ if (err)
+ return err;
+ mmc-op_cond_response = cmd-response[0];
+ return 0;
+}
+
+int mmc_send_op_cond(struct mmc *mmc)
+{
+ struct mmc_cmd cmd;
+ int err, i;
+
/* Some cards seem to need this */
mmc_go_idle(mmc);
/* Asking to the card its capabilities */
- cmd.cmdidx = MMC_CMD_SEND_OP_COND;
- cmd.resp_type = MMC_RSP_R3;
- cmd.cmdarg = 0;
-
- err = mmc_send_cmd(mmc, cmd, NULL);
+ mmc-op_cond_pending = 1;
+ for (i = 0; i 2; i++) {
+ err = mmc_send_op_cond_iter(mmc, cmd, i != 0);
+ if (err)
+ return err;
- if (err)
- return err;
+ /* exit if not busy (flag seems to be inverted) */
+ if (mmc-op_cond_response OCR_BUSY)
+ return 0;
+ }
+ return IN_PROGRESS;
+}
- udelay(1000);
+int mmc_complete_op_cond(struct mmc *mmc)
+{
+ struct mmc_cmd cmd;
+ int timeout = 1000;
+ uint start;
+ int err;
+ mmc-op_cond_pending = 0;
+ start = get_timer(0);
do {
- cmd.cmdidx = MMC_CMD_SEND_OP_COND;
- cmd.resp_type = MMC_RSP_R3;
- cmd.cmdarg = (mmc_host_is_spi(mmc) ? 0 :
- (mmc-voltages
- (cmd.response[0] OCR_VOLTAGE_MASK)) |
- (cmd.response[0] OCR_ACCESS_MODE));
-
- if (mmc-host_caps MMC_MODE_HC)
- cmd.cmdarg |= OCR_HCS;
-
- err = mmc_send_cmd(mmc, cmd, NULL);
-
+ err = mmc_send_op_cond_iter(mmc, cmd, 1);
if (err)
return err;
-
- udelay(1000);
- } while (!(cmd.response[0] OCR_BUSY) timeout--);
-
- if (timeout = 0)
- return UNUSABLE_ERR;
+ if (get_timer(start) timeout)
+ return UNUSABLE_ERR;
+ udelay(100);
+ } while (!(mmc-op_cond_response OCR_BUSY));
if (mmc_host_is_spi(mmc)) { /* read OCR for spi */
cmd.cmdidx = MMC_CMD_SPI_READ_OCR;
@@ -1227,7 +1249,7 @@ block_dev_desc_t *mmc_get_dev(int dev)
}
#endif
-int mmc_init(struct mmc *mmc)
+int mmc_start_init(struct mmc *mmc)
{
int err;
@@ -1267,17 +1289,48 @@ int mmc_init(struct mmc *mmc)
if (err == TIMEOUT) {
err = mmc_send_op_cond(mmc);
- if (err) {
+ if (err err != IN_PROGRESS) {
printf(Card did not respond to voltage select!\n);
return UNUSABLE_ERR;
}
}
- err =
Re: [U-Boot] mtd/cfi: SST39VF3201B flash model not properly handled
Dear Stefan Roese, as Wolfgang Denx suggested me, i am trying to use the u-boot CFI driver with a CFI flash (SSTVF3201B). Yes. But please take a look at the CONFIG_FLASH_CFI_LEGACY config option. This enables the legacy CFI flash devices. And IIRC the SST flash chips are supported via this driver/extension. This flash chip allows erasing/writing blocks of 4 KBytes (called sectors in the SST datasheet), or 64 KBytes (called blocks). The command sequence table for this flash shows 2 different commands to Please see my comment above. And grep for CONFIG_FLASH_CFI_LEGACY to see how its used in the config header. And if necessary, you can always extend the CFI configuration in the JEDEC source: drivers/mtd/jedec_flash.c thaks for the hint, anyway seems i am unfortunate whit this flash chip: first of all, i would understand why a flash chip is defined/handled as leagacy. Can someone kindly clarify this ? SST39VF3201B is a 2M x 16, CFI compliant. CFI legacy dont seems anyway to support 0x50 command for erasing a sector, i grepped and found only a CMD_CLEAR_STATUS as 0x50 that don't seems to fit the case. But the code is not trivial, and i can miss something of course. Also, legacy flash_info_t don't have any field to define the erase sector command. But still, i am not sure this chip should be considered legacy. I grepped for *3201* SST chip, only baord that seems to use it is esd/common and this board has her own flash.c But still, has been suggested me to use CFI driver, so i need to know what the u-boot community would prefer as approach. Still a note. I found issues in Linux also for this chip (STT39VF3201B) and had to ask for a patch on the command set to allow the correct erase command to be used. So how should i proceed ? Many thanks. Best Regards Angelo Dureghello ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] am335x_evm: Define CONFIG_SYS_CACHELINE_SIZE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/12 01:33, Marek Vasut wrote: Dear Pantelis Antoniou, drivers/usb/gadget/composite.c requires that this is defined early. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Tom, this is OMAP, I'll leave this set to you, ok? Yes, thanks. Acked-by: Tom Rini tr...@ti.com Marek, once the DFU stuff is happy, please take these two parts via u-boot-usb. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQt4UyAAoJENk4IS6UOR1WeSUP/2HRfZgdELKR62EswlCKBn3b gAIbCHiVCnfzuNDdf3WAMeSUZZVpA9lEH/0F8VdCmCVddDsWJoj0EJ2jyrzR0NXm hlnnSpxrWXX94LMDb3pHx9R35emE7JVSwLhKHFoH6xIyUkGaLuQMJw+L0LRxvUNf TB51Mkw3IIlXFA3aPy9Qz75xQjxnWWkkFi9V7WcCo7mu1IuUxEKPvtPZm1Br7gMK QXEzO9mlsZH+CGXPO/aqmJK6NI4ogv3XxQ5IlVLdKC6Rn8cddkszC+efXwgGFMF7 Yge1ULv2dg9XGJWsLZrL7rH6gJvCShaYT8lUYeVLdT5yu1aJvHrGztS2uDWOACFz sonpfk2O941t8IokGnuubEDQ/RTKjomVPLQNhiAVfsvvg4eY6K9rmXhFVBGc0zLM 0dEA90uet+CpHlKW5LBI+Qe8nE7fjYeEKl8/nIS9lTMsv0S/8YQFFFSg2z+l23MY JkwyBRU5WH/d1IjQqBBrvu+oRgrgls2SqzACq8M+NltAzZUjY/Z0MAeZ/s8W1mdx X76KOaaqxebLlbMrsnZ8GoXrE7qVUs8nRMieTml6yLyh0ep+GnntPmpmFTFSxKpk dqV17cAS0SbC3L7MFIJgCq59DVjRa93jwfIpaap8sZJD47VPQdHQPvlF0aHG6c66 yn9KjfnSCdL2N5WaK9wG =uh9r -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] am335x_evm: Add DFU config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/12 02:34, Pantelis Antoniou wrote: Add configuration for using DFU on the am335x_evm boards Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Acked-by: Tom Rini tr...@ti.com - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQt4VHAAoJENk4IS6UOR1WVD4P/0BhOEMYefiOZnXHtIeZ/6D4 wd5p/imD2odhh9ZicoyCtYN1EIAYJJjoQplbrj7EeO9M1kjAlm57scI2v4qR3YE+ nRxTMnP4k3rGgeMHUkRyl3okzP0r27bPArVTeCbJ4U0Jx6vFmNScvGaOCKhv7GA7 pAq4Xu6RLGktt2qauZfxqbxTXqrfQNQ85xUotl+KpzM0RkB2RdAPa2lusI3nuLgS f8rvF2Y2nlPj5X39S5220oo55XbOU8XIBmbn0mR2Hj4c447qr1WtJjGydSspYqAq YtyZzKXHCZuM/kI5WXTeBnnlEi6/UHULqNVQXniI2GGmYjW4IBYLfNHgYZq6Y0uo 78cZKc0aHyiD0wcKGJtRpAZ/Np/umqD9zWZ5QbVsVDm8YP/ejcL+g9kOAjgewouT UHZDMmyERU+V/2p6SzwGZj4h06Lrr9Lt1Dd+QyuKCV2S/hieq8FPGkQdnbxIKMN1 M6JdEe517DrU5W3wO9R21p3j38vXUb2PPUL8gn4ctpsLrvKuZlVQhJvA/+wWu4HT L/7bJfQkxBJa/MKDnkHkyU9u7dULl5IorT52z3e/BYZLNHUh1MzUr2Sd9hOwoH2W L4ppYTNDRKVYsIs4iLBcfclcGKQg+GazZuQTbFvz6NQY1cLL3DX7t9BWbmdsqh9B fCcJMpshPOKDsq+TJkO8 =hZ65 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Add an mmcsilent option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/12 11:50, Pantelis Antoniou wrote: Hi Andy, On Nov 28, 2012, at 6:49 PM, Andy Fleming wrote: On Thu, Nov 29, 2012 at 1:34 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: When using MMC commands for dfu there is considerable noise. Suppress mmc messages when mmcsilent is set. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com I'm not familiar with DFU mode, but is there a reason it's invoking the command line call, rather than accessing the card programmatically? The reason that printf is there is because it's a user-facing interface, rather than a software-facing interface. No there is not. It's just what was there and the messages were irritating. I would prefer a software interface TBH. I'm trying to recall. Part of the issue was that, I believe, there wasn't an easy software interface to all of the MMC commands that we needed to use here. It might however have boiled down to as a future clean-up, abstract things so that cmd_mmc and cmd_dfu could make use of the same lower level code. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQt4XhAAoJENk4IS6UOR1WnUcQAJDRFObh3mxSRccDDtsJ4Cab RBDnAdV6KmiCEJF3x2aWtlUdQVVUI15lPwqG6oKHup5s4oNEupSgvmvdXE3I8lCs dWlDU3pSRlIHMFIMJbd6Cy4nYX0rEwxXVEtlujZ875y+wx6sG25FdA7NoQ42uxif c+Oyt/2aUOXx0z2oFsrB7dIadF3cWxglwhla4ob2XBS4w2RYEmti94Vmp4drjlmj s+DMbS3h9Ar9tUIty1sFGUFVU4DycgeZ2COS3IezbcD4E+H6vTGchhZpxFgzsOwo KydHMRsbMvo3px42fE4frFto/n/UwIiS/eSdnN7vpILdZUhH6MmzmPKeLTYpxyGb HiZWnttVmbZHGGLZ/i95XIbQe9PeLsA0WEy5sZrBrn/2JgQ5ktJdpoWHePNk/4VU jO+DItIUWlh5cAsfsi2WFi42MNwMvbkZTItKuQrMpWSTwjmZIiWiIlHmFu5DUo5b 2TNReo2Ybr+7ajb4jz3rBbyVLGJdSPE0lJ+ZUkn6qjf/v3Sz0Z2QsF41keN499PB RaVmLvPVH96r/0jZQN0zlEwPX5f8g5ULnUBHsjLGDo8uc0ZzR9aNGq2bOvFSXOVO bZ/qedEHZvqrGxTkDO5LCpGwQPt8UigL7s9FWfkoXgZLP+4y7D+X4tPOYw3VbV+6 RTnJU9MduHBf6AU7XgRI =55le -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Pull] u-boot-fdt/master
On Wed, Nov 28, 2012 at 08:14:12PM -0500, Jerry Van Baren wrote: Dear Tom, Please pull u-boot-fdt to fix the global_data compilation issue introduced in [PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present (identified by Dennis Lan). Thanks, gvb The following changes since commit d41b3cc16fd97da23900f79e8fefdeedeebde8f6: Merge branch 'master' of git://git.denx.de/u-boot-mips (2012-11-27 20:34:51 -0700) are available in the git repository at: git://git.denx.de/u-boot-fdt.git master for you to fetch changes up to f39612d360c02ce97e7ca7a872693f348f7ec8fd: fdt: Correct global_data condition in main (2012-11-28 19:26:49 -0500) Simon Glass (1): fdt: Correct global_data condition in main common/main.c |2 -- 1 file changed, 2 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v0] davinci, mmc: Added a delay reading ext CSD register
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/12 06:06, Davide Bonfanti wrote: Without this additional delay, some eMMC don't negotiate properly bus width Tested on: - Toshiba THGBM2G8D8FBAIB - Toshiba THGBM4G4D1HBAR - Micron MTFC4GMVEA (the one giving the problem) - Hynix H26M64002BNR - SanDisk SDIN5E1-32G Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it Acked-by: Tom Rini tr...@ti.com Andy, please take this for your MMC tree, thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQt50UAAoJENk4IS6UOR1WY/8P/05sFytV2CMqwEvZh325E1cS Ln6u/FeQSF8DMF/KHGprBRYCOxKwMrCSxs/qJxl0AnD4j5v8CFMacxN/HRo6ay9I YVOsTpa2wiDp9u6lxdO8ivrL5q+q0CRmKsItruXHaBqeJX3rSip4wT9Qb4WIhgPz r8WDlvlauBYF7BATUPqdXGDJWWJmJ2dy8jcarg86Ii6dHl88E43F6cCyD0MVpXn4 4m6T3YtQBLgl/D4wN+NPQcwCLQFEgYKG/rHKN1rDQeiOSvsIctGtXwhnPk3mFLQ9 6UqJpPoJHAwEgpCjPrGSuiKmtJY6A5qyHfvriRLD/LS3M9ylJzzzgm03gSn9FYF4 JP7DVmtol7licM8Vu7LNEcG2Iuiwh7/nmD0Iimg2SpgmG6JVCGCayQVTt6CsxuX4 zA52QA8X+hOPt76+nNmlRewrLepH0iFRWhoJ8/cCS5lLPYdzhC/JIlt/LAErzFwC yRNFyw9EH4IlYOmXYFxZye80Rv9l8fC3nCtoWGOxoR5uEqZkuSalCVrh/GrXu5q1 BVwqsukY3dxCCKc/PgEeDEAUh+9+RCJ9DTq0/AOYrDE0lHtP+uce72pR7MmPIpo9 DRV3YQjWclvnIb1LmV9rLYnOZbKSLS8XiVylbR5SW37eia8rQ3VGhXcPUkKrFWTb d+O32CkMw7KvcUTZJNWS =TseB -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] dfu: Only perform DFU board_usb_init() for TRATS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/12 11:08, Lukasz Majewski wrote: Hi Tom, On 11/28/12 09:47, Lukasz Majewski wrote: Hi Pantelis, USB initialization shouldn't happen for all the boards. The board_usb_init() follows u-boot policy, that SoC IPs (USB) are enabled and configured just before their usage. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- common/cmd_dfu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index 01d6b3a..327c738 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -55,7 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) goto done; } +#ifdef CONFIG_TRATS board_usb_init(); +#endif + In mine opinion this #ifdef shall be removed and each target board using the DFU shall define board_usb_init() at board file. But this isn't a called-only-once place. What are you really doing here and are you sure it's needed every time DFU is called? Hmm, you are correct here. But I don't have a good alternative for this. One solution would be to define a static flag for it at do_dfu function to indicate if this was executed once (however I'm reluctant do this). Any ideas? I think the answer, and it's what we do on am335x is that arch_misc_init() is what calls the equiv of s3c_udc_probe(...) under the logic of if we are built with usb gadget support, we want to use it, so init it. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQt56WAAoJENk4IS6UOR1WznYP/23g0QuMB2slIC41OLTeGKfh 11zybSEVZYZmSPfgjEsXqEWh1cYryQNyiNyKIzNfPPyH/ZAA2PuMH7mKMmdp5St6 p7IIhmFwO+phkLGgpLVSJ6PsCGfY68N1r1FU04JJhpteoNmSPtutBWrb2bJ8tib/ 5HHSjUEUSYIgE1OHHVouGUx4KzNwWgyr0nds9WyfJ/X9OnQ22WRuVlkOIpy74NCz r9QSIEOSbmqY6uU+YFFOorgp0Ox97okRJAH0KAsBNxq6PE2NmZard0Qg2m2Ism7L NFbBvlfeF+/m9cicnrnuygyVkkNRcsX5NjWzVilzXQCfYmwBSH2YKPZbpRb3XGmr wNSNqbfSEWG3Oxa+g0NnqI8SPqsTNVXR8X1QsF/f7zIOHlYZfXlbqsDEzITm1YoI S1OEmpYXQQI1kZEOaxfXyJYbMXnA1/y8uItX8Bl/JUMWDQqQMFeJMVS711khGYuR EUVL8YQam6N7Xgzk89sN8UPyOfAbxxOgB5fNyKeuSL+sz0vBaAkmv69gNsdPsfIr vFvfyUKwyMtqhWZO+cG0VU4jzI0S0SMHdh52GtrU6P/3r77MC6zrhVja2EylXqvD p8pSi7eEdeBUMbJ6uMgLd0kxYwh3NWy5NTTR10yKDyTXi8kh/grG89syI5Eiczwj /CW6UuwG8R7T2l2+d1X3 =mdL4 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: remove custom TEGRA_DEVICE_SETTINGS for board files
On 11/29/2012 02:23 AM, Marc Dietrich wrote: TEGRA_DEVICE_SETTINGS lives now in tegra-common-post.h. This removes custom TEGRA_DEVICE_SETTINGS for all tegra boards providing video output, except seaboard, which was fixed by Stephen already. Reviewed-by: Stephen Warren swar...@nvidia.com I guess I should have done this too, except I didn't see these since my patches were based on a branch that didn't include u-boot-tegra/next. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v0] mmc: forced sector mode when accessing OCR register
It seems to me a bug of the specific mmc like if that it declares byte-mode, but supports only sector mode. Sincerely I don't know if it is a good idea to accept a workaround like this, but this is the only way I found to have my board working. Best Regards, Davide Bonfanti -Jae hoon Chung jh80.ch...@gmail.com ha scritto: -Per: Davide Bonfanti davide.bonfa...@bticino.it Da: Jae hoon Chung jh80.ch...@gmail.com Data: 29/11/2012 16:10 Cc: u-boot@lists.denx.de, aflem...@gmail.com, Jaehoon Chung jh80.ch...@samsung.com Oggetto: Re: [U-Boot] [PATCH v0] mmc: forced sector mode when accessing OCR register Hi, i didn't understand why need to set by force? Best Regards, Jaehoon Chung 2012/11/29 Davide Bonfanti davide.bonfa...@bticino.it: Some eMMC require this setting to work properly. Tested on: - Toshiba THGBM2G8D8FBAIB (the one giving the problem) - Toshiba THGBM4G4D1HBAR - Micron MTFC4GMVEA - Hynix H26M64002BNR - SanDisk SDIN5E1-32G Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it --- drivers/mmc/mmc.c | 3 ++- include/mmc.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 5ffd8c5..cf66811 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -530,7 +530,8 @@ static int mmc_send_op_cond(struct mmc *mmc) cmd.cmdarg = (mmc_host_is_spi(mmc) ? 0 : (mmc-voltages (cmd.response[0] OCR_VOLTAGE_MASK)) | - (cmd.response[0] OCR_ACCESS_MODE)); + (cmd.response[0] OCR_ACCESS_MODE)) | + OCR_ACCESS_SECTOR_MODE; if (mmc-host_caps MMC_MODE_HC) cmd.cmdarg |= OCR_HCS; diff --git a/include/mmc.h b/include/mmc.h index a13e2bd..f1314d8 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -108,6 +108,7 @@ #define OCR_HCS 0x4000 #define OCR_VOLTAGE_MASK 0x007FFF80 #define OCR_ACCESS_MODE 0x6000 +#define OCR_ACCESS_SECTOR_MODE (1 30) #define SECURE_ERASE 0x8000 -- 1.7.9.5 Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite. This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___ 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 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined
Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, November 28, 2012 2:03 PM To: Simon Glass Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren; Marc Dietrich; Thierry Reding Subject: Re: [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined On 11/28/2012 02:01 PM, Simon Glass wrote: Hi Stephen, On Wed, Nov 28, 2012 at 9:50 AM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com seaboard.h attempts to undefine TEGRA_DEVICE_SETTINGS and provide a custom value. This worked when the pre included tegra20-common.h provided the default. However, changes in the main U-Boot repo removed this default from the pre included tegra20-common.h to the post included tegra-common-post.h, which uncondtionally provides the value. This causes the following compile warnings: In file included from /home/swarren/shared/git_wa/u- boot/include/configs/seaboard.h:129:0, from /home/swarren/shared/git_wa/u- boot/include/config.h:10, from /home/swarren/shared/git_wa/u- boot/include/common.h:37, from lib/asm-offsets.c:18: /home/swarren/shared/git_wa/u-boot/include/configs/tegra-common-post. h:163:0: warning: TEGRA_DEVICE_SETTINGS redefined /home/swarren/shared/git_wa/u-boot/include/configs/seaboard.h:110:0: note: this is the location of the previous definition Solve this by modifying tegra-common-post.h to only provide a value for TEGRA_DEVICE_SETTINGS if the board-specific header has not already provided a custom value. Signed-off-by: Stephen Warren swar...@nvidia.com These series doesn't apply to u-boot-tegra/master or /next for me, and the last one doesn't seem to apply to u-boot/master either. Can you please take a look, may be a timing issue. Yes, as I mentioned this problem will only exist once u-boot/master and u- boot-arm/master are merged together, so this patch series applies to the result of the merge, which will be (at least part of) the state of u-boot-tegra/* at some unspecified future time:-) Allen's TEGRA_DEVICE_SETTINGS patch is already in u-boot/master. I applied it to u-boot-tegra/master, then applied your 1/3 2/3 patches (3/3 isn't needed if Allen's patch is already in). Ran a MAKEALL -s tegra20 and that was fine. I then applied the LCD patches that are in u-boot-tegra/next (paz00, etc.), and then I applied Marc's 'tegra: remove custom TEGRA_DEVICE_SETTINGS ...' patch on top of that. Again, MAKEALL was OK. The resulting binaries seem to have the correct settings for stdin,stdout,stderr AFAICT. I'm going to push a new u-boot-tegra/master to denx.de for you, Marc, Simon, etc. to check out to make sure everything works the way you expect. I'll also do a git bisect through the top half-dozen commits. Tom -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined
On 11/29/2012 11:40 AM, Tom Warren wrote: Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, November 28, 2012 2:03 PM To: Simon Glass Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren; Marc Dietrich; Thierry Reding Subject: Re: [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined On 11/28/2012 02:01 PM, Simon Glass wrote: Hi Stephen, On Wed, Nov 28, 2012 at 9:50 AM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com seaboard.h attempts to undefine TEGRA_DEVICE_SETTINGS and provide a custom value. This worked when the pre included tegra20-common.h provided the default. However, changes in the main U-Boot repo removed this default from the pre included tegra20-common.h to the post included tegra-common-post.h, which uncondtionally provides the value. This causes the following compile warnings: In file included from /home/swarren/shared/git_wa/u- boot/include/configs/seaboard.h:129:0, from /home/swarren/shared/git_wa/u- boot/include/config.h:10, from /home/swarren/shared/git_wa/u- boot/include/common.h:37, from lib/asm-offsets.c:18: /home/swarren/shared/git_wa/u-boot/include/configs/tegra-common-post. h:163:0: warning: TEGRA_DEVICE_SETTINGS redefined /home/swarren/shared/git_wa/u-boot/include/configs/seaboard.h:110:0: note: this is the location of the previous definition Solve this by modifying tegra-common-post.h to only provide a value for TEGRA_DEVICE_SETTINGS if the board-specific header has not already provided a custom value. Signed-off-by: Stephen Warren swar...@nvidia.com These series doesn't apply to u-boot-tegra/master or /next for me, and the last one doesn't seem to apply to u-boot/master either. Can you please take a look, may be a timing issue. Yes, as I mentioned this problem will only exist once u-boot/master and u- boot-arm/master are merged together, so this patch series applies to the result of the merge, which will be (at least part of) the state of u-boot-tegra/* at some unspecified future time:-) Allen's TEGRA_DEVICE_SETTINGS patch is already in u-boot/master. Yup. I applied it to u-boot-tegra/master, then applied your 1/3 2/3 patches (3/3 isn't needed if Allen's patch is already in). Maybe. It depends how Tom Rini does the u-boot-arm/master - u-boot/master merge; u-boot-arm/master contains a patch that edits TEGRA_DEVICE_SETTINGS in seaboard.h (Simon's to add LCD support), and it's not obvious when merging those two branches that the merge result should be to remove that change from seaboard.h. No actually, that shouldn't be the merge result; if it was, the LCD additions would be removed from TEGRA_DEVICE_SETTINGS without patch 2/3 that I posted. That is, unless patch 2/3 of mine gets into u-boot-arm/master before Albert sends a pull request to Tom Rini... So, I think that once you rebase onto an upstream branch that itself includes all these patches rather than manually applying them, you will probably find patch 3/3 is required. Admittedly it's not if you just apply Allen's patch to the current u-boot-arm/master. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined
Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Thursday, November 29, 2012 12:10 PM To: Tom Warren Cc: Simon Glass; u-boot@lists.denx.de; Stephen Warren; Marc Dietrich; Thierry Reding Subject: Re: [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined On 11/29/2012 11:40 AM, Tom Warren wrote: Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, November 28, 2012 2:03 PM To: Simon Glass Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren; Marc Dietrich; Thierry Reding Subject: Re: [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined On 11/28/2012 02:01 PM, Simon Glass wrote: Hi Stephen, On Wed, Nov 28, 2012 at 9:50 AM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com seaboard.h attempts to undefine TEGRA_DEVICE_SETTINGS and provide a custom value. This worked when the pre included tegra20-common.h provided the default. However, changes in the main U-Boot repo removed this default from the pre included tegra20-common.h to the post included tegra-common-post.h, which uncondtionally provides the value. This causes the following compile warnings: In file included from /home/swarren/shared/git_wa/u- boot/include/configs/seaboard.h:129:0, from /home/swarren/shared/git_wa/u- boot/include/config.h:10, from /home/swarren/shared/git_wa/u- boot/include/common.h:37, from lib/asm-offsets.c:18: /home/swarren/shared/git_wa/u-boot/include/configs/tegra-common-post. h:163:0: warning: TEGRA_DEVICE_SETTINGS redefined /home/swarren/shared/git_wa/u-boot/include/configs/seaboard.h:110:0: note: this is the location of the previous definition Solve this by modifying tegra-common-post.h to only provide a value for TEGRA_DEVICE_SETTINGS if the board-specific header has not already provided a custom value. Signed-off-by: Stephen Warren swar...@nvidia.com These series doesn't apply to u-boot-tegra/master or /next for me, and the last one doesn't seem to apply to u-boot/master either. Can you please take a look, may be a timing issue. Yes, as I mentioned this problem will only exist once u-boot/master and u- boot-arm/master are merged together, so this patch series applies to the result of the merge, which will be (at least part of) the state of u-boot-tegra/* at some unspecified future time:-) Allen's TEGRA_DEVICE_SETTINGS patch is already in u-boot/master. Yup. I applied it to u-boot-tegra/master, then applied your 1/3 2/3 patches (3/3 isn't needed if Allen's patch is already in). Maybe. It depends how Tom Rini does the u-boot-arm/master - u-boot/master merge; u-boot-arm/master contains a patch that edits TEGRA_DEVICE_SETTINGS in seaboard.h (Simon's to add LCD support), and it's not obvious when merging those two branches that the merge result should be to remove that change from seaboard.h. No actually, that shouldn't be the merge result; if it was, the LCD additions would be removed from TEGRA_DEVICE_SETTINGS without patch 2/3 that I posted. That is, unless patch 2/3 of mine gets into u-boot-arm/master before Albert sends a pull request to Tom Rini... So, I think that once you rebase onto an upstream branch that itself includes all these patches rather than manually applying them, you will probably find patch 3/3 is required. Admittedly it's not if you just apply Allen's patch to the current u-boot-arm/master. I'm not anticipating doing a new pull request for u-boot-tegra/master any time real soon, so we can wait for upstream (u-boot-arm u-boot/master) to settle a bit. But regardless, Albert has said that he's fine with custodians submitting pull requests that contain/depend upon patches that are already in an upstream repo, or with the custodian stating explicitly which upstream patches are needed for a pull request to succeed/build/work. Note that the only patch I'm manually applying per se is Allen's TEGRA_DEVICE_SETTINGS patch that went in to u-boot/master via u-boot-usb via Marek. The rest are true Tegra patches. Take a look at tegra/master (or /next) and compare to u-boot/master, u-boot-arm, u-boot-usb, etc. if needed and let me know if you still think it's going to run into trouble if/when I do a pull request to arm/master. Thanks, Tom -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined
On 11/29/2012 12:50 PM, Tom Warren wrote: Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Thursday, November 29, 2012 12:10 PM To: Tom Warren Cc: Simon Glass; u-boot@lists.denx.de; Stephen Warren; Marc Dietrich; Thierry Reding Subject: Re: [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined On 11/29/2012 11:40 AM, Tom Warren wrote: Stephen, -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, November 28, 2012 2:03 PM To: Simon Glass Cc: u-boot@lists.denx.de; Tom Warren; Stephen Warren; Marc Dietrich; Thierry Reding Subject: Re: [PATCH 1/3] tegra: only define TEGRA_DEVICE_SETTINGS if not already defined On 11/28/2012 02:01 PM, Simon Glass wrote: Hi Stephen, On Wed, Nov 28, 2012 at 9:50 AM, Stephen Warren swar...@wwwdotorg.org wrote: From: Stephen Warren swar...@nvidia.com seaboard.h attempts to undefine TEGRA_DEVICE_SETTINGS and provide a custom value. This worked when the pre included tegra20-common.h provided the default. However, changes in the main U-Boot repo removed this default from the pre included tegra20-common.h to the post included tegra-common-post.h, which uncondtionally provides the value. This causes the following compile warnings: In file included from /home/swarren/shared/git_wa/u- boot/include/configs/seaboard.h:129:0, from /home/swarren/shared/git_wa/u- boot/include/config.h:10, from /home/swarren/shared/git_wa/u- boot/include/common.h:37, from lib/asm-offsets.c:18: /home/swarren/shared/git_wa/u-boot/include/configs/tegra-common-post. h:163:0: warning: TEGRA_DEVICE_SETTINGS redefined /home/swarren/shared/git_wa/u-boot/include/configs/seaboard.h:110:0: note: this is the location of the previous definition Solve this by modifying tegra-common-post.h to only provide a value for TEGRA_DEVICE_SETTINGS if the board-specific header has not already provided a custom value. Signed-off-by: Stephen Warren swar...@nvidia.com These series doesn't apply to u-boot-tegra/master or /next for me, and the last one doesn't seem to apply to u-boot/master either. Can you please take a look, may be a timing issue. Yes, as I mentioned this problem will only exist once u-boot/master and u- boot-arm/master are merged together, so this patch series applies to the result of the merge, which will be (at least part of) the state of u-boot-tegra/* at some unspecified future time:-) Allen's TEGRA_DEVICE_SETTINGS patch is already in u-boot/master. Yup. I applied it to u-boot-tegra/master, then applied your 1/3 2/3 patches (3/3 isn't needed if Allen's patch is already in). Maybe. It depends how Tom Rini does the u-boot-arm/master - u-boot/master merge; u-boot-arm/master contains a patch that edits TEGRA_DEVICE_SETTINGS in seaboard.h (Simon's to add LCD support), and it's not obvious when merging those two branches that the merge result should be to remove that change from seaboard.h. No actually, that shouldn't be the merge result; if it was, the LCD additions would be removed from TEGRA_DEVICE_SETTINGS without patch 2/3 that I posted. That is, unless patch 2/3 of mine gets into u-boot-arm/master before Albert sends a pull request to Tom Rini... So, I think that once you rebase onto an upstream branch that itself includes all these patches rather than manually applying them, you will probably find patch 3/3 is required. Admittedly it's not if you just apply Allen's patch to the current u-boot-arm/master. I'm not anticipating doing a new pull request for u-boot-tegra/master any time real soon, so we can wait for upstream (u-boot-arm u-boot/master) to settle a bit. But regardless, Albert has said that he's fine with custodians submitting pull requests that contain/depend upon patches that are already in an upstream repo, or with the custodian stating explicitly which upstream patches are needed for a pull request to succeed/build/work. I believe he said that about git commits (i.e. you can branch from a commit in u-boot/master just fine) not about patches (i.e. you can't manually apply a patch that's already upstream, since that will cause the patch itself to be duplicated in git). So, if you apply Allen's patch manually to u-boot-tegra/master, you'll need to rebase u-boot-tegra/master onto u-boot/master or u-boot-arm/master once Allen's patch is there, to remove the duplicate patch, rather than just sending a pull request containing a duplicate patch. BTW, your messages have suddenly stopped being word-wrapped, which makes quoting/reading them a bit hard. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] x86: Select stdio devices for coreboot
We want to support VGA, serial, USB keyboard and the Coreboot memory console buffer. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Collect settings in one place - Use eserial0 instead of serial since this is now the correct name - define CONFIG_EXTRA_ENV_SETTINGS so that these settings come through include/configs/coreboot.h | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h index 5da006f..cfe5db3 100644 --- a/include/configs/coreboot.h +++ b/include/configs/coreboot.h @@ -92,6 +92,15 @@ #define CONFIG_SYS_NS16550_COM2UART1_BASE #define CONFIG_SYS_NS16550_PORT_MAPPED +#define CONFIG_STD_DEVICES_SETTINGS stdin=usbkbd,vga,eserial0\0 \ + stdout=vga,eserial0,cbmem\0 \ + stderr=vga,eserial0,cbmem\0 + +#define CONFIG_CONSOLE_MUX +#define CONFIG_SYS_CONSOLE_IS_IN_ENV +#define CONFIG_SYS_STDIO_DEREGISTER +#define CONFIG_CBMEM_CONSOLE + /* max. 1 IDE bus */ #define CONFIG_SYS_IDE_MAXBUS 1 /* max. 1 drive per IDE bus */ @@ -243,4 +252,7 @@ */ #define CONFIG_PCI +#define CONFIG_EXTRA_ENV_SETTINGS \ + CONFIG_STD_DEVICES_SETTINGS + #endif /* __CONFIG_H */ -- 1.7.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Switch from mmcboot to ramboot?
How can I tell u-boot to boot with the ramboot= definition instead of mmcboot= ? - Grant You need to change environmental variable bootcmd setenv bootcmd ramboot saveenv run bootcmd or simpler: Stop u-boot - and access prompt then, run ramboot Hi Lucasz, that didn't work for me and I think it's because of the variables set by 'make am335x_evm_defconfig'. It seems like there are a set of standard u-boot commands and a higher level of variables set by 'make am335x_evm_defconfig' which appear in include/configs/am335x_evm.h and prevent you from using the standard u-boot commands in uEnv.txt. For example, even after adding the following to the top of my uEnv.txt: setenv bootcmd ramboot saveenv I still get: Booting from mmc ... I'm struggling to figure out how to use the framework provided by 'make am335x_evm_defconfig' in uEnv.txt. Can you point me to info on how to do that? - Grant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] README.scrapyard: add missing commit IDs
Hi Wolfgang, On Thu, Nov 29, 2012 at 11:53 PM, Wolfgang Denk w...@denx.de wrote: Now that the patches have made it into mainline, we can also add the commit IDs. Signed-off-by: Wolfgang Denk w...@denx.de --- doc/README.scrapyard | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/README.scrapyard b/doc/README.scrapyard index 2b868e6..9ad9296 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -11,13 +11,13 @@ easily if here is something they might want to dig for... Board ArchCPU removed Commit last known maintainer/contact = -AMX860 powerpc mpc860 - - Wolfgang Denk w...@denx.de -c2mon powerpc mpc855 - - Wolfgang Denk w...@denx.de -ETX094 powerpc mpc850 - - Wolfgang Denk w...@denx.de -IAD210 powerpc mpc860 - - - -LANTEC powerpc mpc850 - - Wolfgang Denk w...@denx.de -SCMpowerpc mpc8260 - - Wolfgang Grandegger w...@denx.de -SX1arm arm925t - - +AMX860 powerpc mpc860 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +c2mon powerpc mpc855 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +ETX094 powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +IAD210 powerpc mpc860 1b0757e 2012-10-28- +LANTEC powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +SCMpowerpc mpc8260 1b0757e 2012-10-28Wolfgang Grandegger w...@denx.de +SX1arm arm925t 53c4154 2012-10-26 TQM85xxpowerpc MPC85xx d923a5d5 2012-10-04Stefan Roese s...@denx.de apollon arm omap24xx 535c74f 2012-09-18Kyungmin Park kyungmin.p...@samsung.com tb0229 mipsmips32 3f3110d 2011-12-12 'removed' and 'Commit' don't match the order of the header Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] dfu: Only perform DFU board_usb_init() for TRATS
Hi Tom, -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/12 11:08, Lukasz Majewski wrote: Hi Tom, On 11/28/12 09:47, Lukasz Majewski wrote: Hi Pantelis, USB initialization shouldn't happen for all the boards. The board_usb_init() follows u-boot policy, that SoC IPs (USB) are enabled and configured just before their usage. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- common/cmd_dfu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index 01d6b3a..327c738 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -55,7 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) goto done; } +#ifdef CONFIG_TRATS board_usb_init(); +#endif + In mine opinion this #ifdef shall be removed and each target board using the DFU shall define board_usb_init() at board file. But this isn't a called-only-once place. What are you really doing here and are you sure it's needed every time DFU is called? Hmm, you are correct here. But I don't have a good alternative for this. One solution would be to define a static flag for it at do_dfu function to indicate if this was executed once (however I'm reluctant do this). Any ideas? I think the answer, and it's what we do on am335x is that arch_misc_init() is what calls the equiv of s3c_udc_probe(...) under the logic of if we are built with usb gadget support, we want to use it, so init it. I've understood the policy differently: We are build with gadget support and we _might_ use it, so enable low level code only when (or just before) we use it. What's about the power consumption? Why IP block which will be used from time to time shall be enabled and operational? - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQt56WAAoJENk4IS6UOR1WznYP/23g0QuMB2slIC41OLTeGKfh 11zybSEVZYZmSPfgjEsXqEWh1cYryQNyiNyKIzNfPPyH/ZAA2PuMH7mKMmdp5St6 p7IIhmFwO+phkLGgpLVSJ6PsCGfY68N1r1FU04JJhpteoNmSPtutBWrb2bJ8tib/ 5HHSjUEUSYIgE1OHHVouGUx4KzNwWgyr0nds9WyfJ/X9OnQ22WRuVlkOIpy74NCz r9QSIEOSbmqY6uU+YFFOorgp0Ox97okRJAH0KAsBNxq6PE2NmZard0Qg2m2Ism7L NFbBvlfeF+/m9cicnrnuygyVkkNRcsX5NjWzVilzXQCfYmwBSH2YKPZbpRb3XGmr wNSNqbfSEWG3Oxa+g0NnqI8SPqsTNVXR8X1QsF/f7zIOHlYZfXlbqsDEzITm1YoI S1OEmpYXQQI1kZEOaxfXyJYbMXnA1/y8uItX8Bl/JUMWDQqQMFeJMVS711khGYuR EUVL8YQam6N7Xgzk89sN8UPyOfAbxxOgB5fNyKeuSL+sz0vBaAkmv69gNsdPsfIr vFvfyUKwyMtqhWZO+cG0VU4jzI0S0SMHdh52GtrU6P/3r77MC6zrhVja2EylXqvD p8pSi7eEdeBUMbJ6uMgLd0kxYwh3NWy5NTTR10yKDyTXi8kh/grG89syI5Eiczwj /CW6UuwG8R7T2l2+d1X3 =mdL4 -END PGP SIGNATURE- ___ 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] Switch from mmcboot to ramboot?
Hi Grant, How can I tell u-boot to boot with the ramboot= definition instead of mmcboot= ? - Grant You need to change environmental variable bootcmd setenv bootcmd ramboot saveenv run bootcmd or simpler: Stop u-boot - and access prompt then, run ramboot Hi Lucasz, that didn't work for me and I think it's because of the variables set by 'make am335x_evm_defconfig'. It seems like there are a set of standard u-boot commands and a higher level of variables set by 'make am335x_evm_defconfig' which appear in include/configs/am335x_evm.h and prevent you from using the standard u-boot commands in uEnv.txt. I can give you an example with Samsung's soc. When you execute 'make trats_defconfig' then default envs defined at include/trats.h are compiled in. Then if envs are broken (or not available), then those values are default. Please type ? at u-boot prompt and look for env commands. When you type the command, then context help appears. On Samsung's SoCs you can easily write those default envs to memory (oneNAND or eMMC) with 'envs default'. And then edit those stored values (as I've written previously). For example, even after adding the following to the top of my uEnv.txt: I'm not familiar with am335x_evm board and I don't know what is the purpose of uEnv.txt. I may just guess, that this is a default command list to execute. Please investigate the env command if it can work for you. setenv bootcmd ramboot saveenv I still get: Booting from mmc ... I'm struggling to figure out how to use the framework provided by 'make am335x_evm_defconfig' in uEnv.txt. Can you point me to info on how to do that? - Grant Regards, Lukasz ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] dfu: Only perform DFU board_usb_init() for TRATS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/12 18:14, Lukasz Majewski wrote: Hi Tom, On 11/28/12 11:08, Lukasz Majewski wrote: Hi Tom, On 11/28/12 09:47, Lukasz Majewski wrote: Hi Pantelis, USB initialization shouldn't happen for all the boards. The board_usb_init() follows u-boot policy, that SoC IPs (USB) are enabled and configured just before their usage. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- common/cmd_dfu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index 01d6b3a..327c738 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -55,7 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) goto done; } +#ifdef CONFIG_TRATS board_usb_init(); +#endif + In mine opinion this #ifdef shall be removed and each target board using the DFU shall define board_usb_init() at board file. But this isn't a called-only-once place. What are you really doing here and are you sure it's needed every time DFU is called? Hmm, you are correct here. But I don't have a good alternative for this. One solution would be to define a static flag for it at do_dfu function to indicate if this was executed once (however I'm reluctant do this). Any ideas? I think the answer, and it's what we do on am335x is that arch_misc_init() is what calls the equiv of s3c_udc_probe(...) under the logic of if we are built with usb gadget support, we want to use it, so init it. I've understood the policy differently: We are build with gadget support and we _might_ use it, so enable low level code only when (or just before) we use it. What's about the power consumption? Why IP block which will be used from time to time shall be enabled and operational? Frankly, I think this shows we don't have a good setup right now, in general. Saying the gadget needs to whack and re-whack the device into on state (but isn't really turning it off once done) isn't ideal. There are also indeed drawbacks to saying gadget support enabled at boot-time, let me set it up. Right now, I don't really have a good answer. It also needs to cover things like gadget ethernet where we don't really want to disappear immediately after each command. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQuBJzAAoJENk4IS6UOR1WWncP/29E2kP1ErctSmBPUkJZASEk qmW+rYCwxpz3aesC6Dcnc0Urad+MwO9SPbzUFfQcB4CMVXXAXMcahH+4FY8FzTnV p8QqQjZ0o54xYxEI/evkaEWsTyM3nBBXtMq9II2gwYPMxP88i2JwL1NMOF6o2z+Y VVNyGO1685JIGU+WMzpoXp4WYjfd/8qv8JHhQ+moGoFe0p7p5c5kokYsbXdcxvyk rkeJrog8SV+vJQLnu0nUh8Q/pBYftiMDD+U8upQOiYNF1CPgGugX33XJydtYMoA8 rv6an/xh4PXUSJkAJbwp8vrxQqrHD0MYWtZEPwTEToFmTxvvaS2zJ0uOnNLkjanv dp8RrD38HIczsgMtAVXR9nhFsW89MB2EiXc7N/EoO0BA4E0pac1/+OUfUMwELj16 IKJIHa4BXkHfg/ybQXCxr+GDZEc8YwLGXxzyIw8cS3PffNSkR1fkJcjZwFg190y0 1IjmlF0Dhg0CGweej0WTFuzi3OmHQOvMJcvT0doiI35iVbFvGwhjNUt8dJeDr0Yr xkhWPhR3+iMXmzle+me+ZUxUe5g2vGqPC6HeGUO/fo0ntqZfITjzznMHKpN8Uxwv D6Njg2e785ZIgTxcMXKn/Q2xtPBF78/stWeStyIwIAxYOEDw/C+NipWAHEpJdGTp k8mhP+GKWgatyZ5yqDBA =01FA -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
From: Gabe Black gabebl...@chromium.org
We don't want this for coreboot, so provide a way of compiling it out.
Signed-off-by: Gabe Black gabebl...@chromium.org
Signed-off-by: Stefan Reinauer reina...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Rename real mode option to CONFIG_X86_NO_REAL_MODE
README|6 ++
arch/x86/lib/Makefile |9 ++---
arch/x86/lib/video.c |2 ++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/README b/README
index b9a3685..ed7d270 100644
--- a/README
+++ b/README
@@ -3668,6 +3668,12 @@ Low Level (hardware related) configuration options:
If defined, the x86 reset vector code is excluded. You will need
to do this when U-Boot is running from Coreboot.
+- CONFIG_X86_NO_REAL_MODE
+ If defined, x86 real mode code is omitted. This assumes a
+ 32-bit environment where such code is not needed. You will
+ need to do this when U-Boot is running from Coreboot.
+
+
Freescale QE/FMAN Firmware Support:
---
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 51836da..4325b25 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,11 +25,16 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(ARCH).o
+ifeq ($(CONFIG_X86_NO_REAL_MODE),)
SOBJS-$(CONFIG_SYS_PC_BIOS)+= bios.o
SOBJS-$(CONFIG_SYS_PCI_BIOS) += bios_pci.o
-SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o
+COBJS-y+= realmode.o
+SOBJS-y+= realmode_switch.o
COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o
+COBJS-$(CONFIG_VIDEO) += video_bios.o
+endif
+
COBJS-y+= board.o
COBJS-y+= bootm.o
COBJS-y+= cmd_boot.o
@@ -41,11 +46,9 @@ COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o
COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-$(CONFIG_PCI) += pci_type1.o
-COBJS-$(CONFIG_SYS_X86_REALMODE) += realmode.o
COBJS-y+= relocate.o
COBJS-y+= string.o
COBJS-$(CONFIG_SYS_X86_ISR_TIMER) += timer.o
-COBJS-$(CONFIG_VIDEO) += video_bios.o
COBJS-$(CONFIG_VIDEO) += video.o
COBJS-$(CONFIG_CMD_ZBOOT) += zimage.o
diff --git a/arch/x86/lib/video.c b/arch/x86/lib/video.c
index 3d6b24d..20e2416 100644
--- a/arch/x86/lib/video.c
+++ b/arch/x86/lib/video.c
@@ -222,8 +222,10 @@ int video_init(void)
int drv_video_init(void)
{
+#ifndef CONFIG_X86_NO_REAL_MODE
if (video_bios_init())
return 1;
+#endif
return video_init();
}
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Simon,
On Fri, Nov 30, 2012 at 12:57 PM, Simon Glass s...@chromium.org wrote:
From: Gabe Black gabebl...@chromium.org
We don't want this for coreboot, so provide a way of compiling it out.
Signed-off-by: Gabe Black gabebl...@chromium.org
Signed-off-by: Stefan Reinauer reina...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Rename real mode option to CONFIG_X86_NO_REAL_MODE
README|6 ++
arch/x86/lib/Makefile |9 ++---
arch/x86/lib/video.c |2 ++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/README b/README
index b9a3685..ed7d270 100644
--- a/README
+++ b/README
@@ -3668,6 +3668,12 @@ Low Level (hardware related) configuration options:
If defined, the x86 reset vector code is excluded. You will
need
to do this when U-Boot is running from Coreboot.
+- CONFIG_X86_NO_REAL_MODE
+ If defined, x86 real mode code is omitted. This assumes a
+ 32-bit environment where such code is not needed. You will
+ need to do this when U-Boot is running from Coreboot.
+
+
Freescale QE/FMAN Firmware Support:
---
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 51836da..4325b25 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,11 +25,16 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(ARCH).o
+ifeq ($(CONFIG_X86_NO_REAL_MODE),)
SOBJS-$(CONFIG_SYS_PC_BIOS)+= bios.o
SOBJS-$(CONFIG_SYS_PCI_BIOS) += bios_pci.o
-SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o
+COBJS-y+= realmode.o
+SOBJS-y+= realmode_switch.o
COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o
+COBJS-$(CONFIG_VIDEO) += video_bios.o
+endif
+
COBJS-y+= board.o
COBJS-y+= bootm.o
COBJS-y+= cmd_boot.o
@@ -41,11 +46,9 @@ COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o
COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-$(CONFIG_PCI) += pci_type1.o
-COBJS-$(CONFIG_SYS_X86_REALMODE) += realmode.o
COBJS-y+= relocate.o
COBJS-y+= string.o
COBJS-$(CONFIG_SYS_X86_ISR_TIMER) += timer.o
-COBJS-$(CONFIG_VIDEO) += video_bios.o
COBJS-$(CONFIG_VIDEO) += video.o
COBJS-$(CONFIG_CMD_ZBOOT) += zimage.o
diff --git a/arch/x86/lib/video.c b/arch/x86/lib/video.c
index 3d6b24d..20e2416 100644
--- a/arch/x86/lib/video.c
+++ b/arch/x86/lib/video.c
@@ -222,8 +222,10 @@ int video_init(void)
int drv_video_init(void)
{
+#ifndef CONFIG_X86_NO_REAL_MODE
if (video_bios_init())
return 1;
+#endif
return video_init();
}
Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you
define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you
will get a linker failure. Maybe change:
#if defined CONFIG_ZBOOT_32 to
#if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE)
Don't forget the end goal is to surgically remove all 16-bit support
(apart from the reset vector for non-coreboot boards)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Graeme, On Thu, Nov 29, 2012 at 6:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] } Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you will get a linker failure. Maybe change: #if defined CONFIG_ZBOOT_32 to #if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE) Funny I just had that and took it out. My thought was that it would be a strange board that didn't define both. I will add that code back in. Don't forget the end goal is to surgically remove all 16-bit support (apart from the reset vector for non-coreboot boards) Regards, Graeme Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Simon, On Fri, Nov 30, 2012 at 1:17 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Thu, Nov 29, 2012 at 6:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] } Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you will get a linker failure. Maybe change: #if defined CONFIG_ZBOOT_32 to #if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE) Funny I just had that and took it out. My thought was that it would be a strange board that didn't define both. I will add that code back in. Not strange - completely broken. Maybe add a #error if CONFIG_X86_NO_REAL_MODE is defined and CONFIG_ZBOOT_32 is not? It is perfectly legitimate to define CONFIG_ZBOOT_32 while not defining CONFIG_X86_NO_REAL_MODE Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/12] x86: Allow compiling out realmode/bios code
From: Gabe Black gabebl...@chromium.org
We don't want this for coreboot, so provide a way of compiling it out.
Signed-off-by: Gabe Black gabebl...@chromium.org
Signed-off-by: Stefan Reinauer reina...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Check for CONFIG_X86_NO_REAL_MODE in the zimage code
Changes in v2:
- Rename real mode option to CONFIG_X86_NO_REAL_MODE
README|6 ++
arch/x86/lib/Makefile |9 ++---
arch/x86/lib/video.c |2 ++
arch/x86/lib/zimage.c |4 ++--
4 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/README b/README
index b9a3685..ed7d270 100644
--- a/README
+++ b/README
@@ -3668,6 +3668,12 @@ Low Level (hardware related) configuration options:
If defined, the x86 reset vector code is excluded. You will need
to do this when U-Boot is running from Coreboot.
+- CONFIG_X86_NO_REAL_MODE
+ If defined, x86 real mode code is omitted. This assumes a
+ 32-bit environment where such code is not needed. You will
+ need to do this when U-Boot is running from Coreboot.
+
+
Freescale QE/FMAN Firmware Support:
---
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 51836da..4325b25 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,11 +25,16 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(ARCH).o
+ifeq ($(CONFIG_X86_NO_REAL_MODE),)
SOBJS-$(CONFIG_SYS_PC_BIOS)+= bios.o
SOBJS-$(CONFIG_SYS_PCI_BIOS) += bios_pci.o
-SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o
+COBJS-y+= realmode.o
+SOBJS-y+= realmode_switch.o
COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o
+COBJS-$(CONFIG_VIDEO) += video_bios.o
+endif
+
COBJS-y+= board.o
COBJS-y+= bootm.o
COBJS-y+= cmd_boot.o
@@ -41,11 +46,9 @@ COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o
COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-$(CONFIG_PCI) += pci_type1.o
-COBJS-$(CONFIG_SYS_X86_REALMODE) += realmode.o
COBJS-y+= relocate.o
COBJS-y+= string.o
COBJS-$(CONFIG_SYS_X86_ISR_TIMER) += timer.o
-COBJS-$(CONFIG_VIDEO) += video_bios.o
COBJS-$(CONFIG_VIDEO) += video.o
COBJS-$(CONFIG_CMD_ZBOOT) += zimage.o
diff --git a/arch/x86/lib/video.c b/arch/x86/lib/video.c
index 3d6b24d..20e2416 100644
--- a/arch/x86/lib/video.c
+++ b/arch/x86/lib/video.c
@@ -222,8 +222,10 @@ int video_init(void)
int drv_video_init(void)
{
+#ifndef CONFIG_X86_NO_REAL_MODE
if (video_bios_init())
return 1;
+#endif
return video_init();
}
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 2214286..b8c672b 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -171,7 +171,7 @@ struct boot_params *load_zimage(char *image, unsigned long
kernel_size,
else
*load_address = (void *)ZIMAGE_LOAD_ADDR;
-#if defined CONFIG_ZBOOT_32
+#if (defined CONFIG_ZBOOT_32 || defined CONFIG_X86_NO_REAL_MODE)
printf(Building boot_params at 0x%8.8lx\n, (ulong)setup_base);
memset(setup_base, 0, sizeof(*setup_base));
setup_base-hdr = params-hdr;
@@ -237,7 +237,7 @@ int setup_zimage(struct boot_params *setup_base, char
*cmd_line, int auto_boot,
struct setup_header *hdr = setup_base-hdr;
int bootproto = get_boot_protocol(hdr);
-#if defined CONFIG_ZBOOT_32
+#if (defined CONFIG_ZBOOT_32 || defined CONFIG_X86_NO_REAL_MODE)
setup_base-e820_entries = install_e820_map(
ARRAY_SIZE(setup_base-e820_map), setup_base-e820_map);
#endif
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Graham, On Thu, Nov 29, 2012 at 6:19 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Fri, Nov 30, 2012 at 1:17 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Thu, Nov 29, 2012 at 6:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] } Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you will get a linker failure. Maybe change: #if defined CONFIG_ZBOOT_32 to #if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE) Funny I just had that and took it out. My thought was that it would be a strange board that didn't define both. I will add that code back in. Not strange - completely broken. Maybe add a #error if CONFIG_X86_NO_REAL_MODE is defined and CONFIG_ZBOOT_32 is not? OK, I might need to put that in a new patch. Or do you think it is ok to stick it in here? I just sent a new version. It is perfectly legitimate to define CONFIG_ZBOOT_32 while not defining CONFIG_X86_NO_REAL_MODE OK. Regards, Simon Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Simon, On Fri, Nov 30, 2012 at 1:25 PM, Simon Glass s...@chromium.org wrote: Hi Graham, On Thu, Nov 29, 2012 at 6:19 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Fri, Nov 30, 2012 at 1:17 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Thu, Nov 29, 2012 at 6:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] } Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you will get a linker failure. Maybe change: #if defined CONFIG_ZBOOT_32 to #if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE) Funny I just had that and took it out. My thought was that it would be a strange board that didn't define both. I will add that code back in. Not strange - completely broken. Maybe add a #error if CONFIG_X86_NO_REAL_MODE is defined and CONFIG_ZBOOT_32 is not? OK, I might need to put that in a new patch. Or do you think it is ok to stick it in here? I just sent a new version. I don't think it really matters - that code will go soon anyway Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Add L2 Cache Support.
Hi Kyungmin Park,
Thank you for comment.
Will make the change and resubmit the patch.
Regards,
Rajeshwari Shinde.
On Thu, Nov 29, 2012 at 8:12 PM, Kyungmin Park kmp...@infradead.org wrote:
On Thu, Nov 29, 2012 at 5:12 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch set adds L2 Cache Support to EXYNOS.
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/cpu/armv7/exynos/soc.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/soc.c
b/arch/arm/cpu/armv7/exynos/soc.c
index ab65b8d..a45bbfb 100644
--- a/arch/arm/cpu/armv7/exynos/soc.c
+++ b/arch/arm/cpu/armv7/exynos/soc.c
@@ -23,6 +23,14 @@
#include common.h
#include asm/io.h
+#include asm/system.h
+
+enum l2_cache_params {
+ CACHE_TAG_RAM_SETUP = (19),
+ CACHE_DATA_RAM_SETUP = (15),
+ CACHE_TAG_RAM_LATENCY = (26),
+ CACHE_DATA_RAM_LATENCY = (20)
+};
void reset_cpu(ulong addr)
{
@@ -36,3 +44,31 @@ void enable_caches(void)
dcache_enable();
}
#endif
+
+#ifndef CONFIG_SYS_L2CACHE_OFF
+/*
+ * Set L2 cache parameters
+ */
+static void exynos5_set_l2cache_params(void)
+{
+ unsigned int val = 0;
+
+ asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r(val));
+
+ val |= CACHE_TAG_RAM_SETUP |
+ CACHE_DATA_RAM_SETUP |
+ CACHE_TAG_RAM_LATENCY |
+ CACHE_DATA_RAM_LATENCY;
+
+ asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val));
+}
+
+/*
+ * Sets L2 cache related parameters before enabling data cache
+ */
+void v7_outer_cache_enable(void)
+{
if (soc_is_exynos5250())
+ exynos5_set_l2cache_params();
Since it's not working at exynos4
Thank you,
Kyungmin Park
+}
+#endif
+
--
1.7.4.4
___
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6 V4] EXYNOS5: FDT : Decode peripheral id
On Wed, Nov 28, 2012 at 11:09 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: Api is added to decode peripheral id based on the interrupt number of the peripheral. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by; Simon Glass s...@chromium.org --- Chnages in V3: - New patch added. Chnages in V4: - Renamed decode_periph_id to pinmux_decode_periph_id. - Added comments in periph.h as suggested by Simon Glass. arch/arm/cpu/armv7/exynos/pinmux.c| 28 ++ arch/arm/include/asm/arch-exynos/periph.h | 31 arch/arm/include/asm/arch-exynos/pinmux.h |8 +++ 3 files changed, 54 insertions(+), 13 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6 V3] Sound: Add FDT support to driver
On Wed, Nov 28, 2012 at 11:55 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds FDT support to the sound driver. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes in V2: - Made single function to get i2s values,codec init and sount init in both FDT and non FDT support case. Changes in V3: - Removed #ifdef CONFIG_OF_CONTROL where ever not required. drivers/sound/sound.c | 173 + include/sound.h |4 +- 2 files changed, 105 insertions(+), 72 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6 V3] Sound: WM8994: Add FDT support to codec
On Wed, Nov 28, 2012 at 11:55 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds FDT support to the codec. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes in V2: - New patch. Changes in V3: - Removed #ifdef CONFIG_OF_CONTROL where ever not required. drivers/sound/wm8994.c | 76 ++- drivers/sound/wm8994.h |6 +-- 2 files changed, 76 insertions(+), 6 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6 V3] Sound: Add FDT support to CMD.
On Wed, Nov 28, 2012 at 11:55 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds FDT support to sound init in CMD.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- Same function call for sound init in case of FDT or non FDT support.
Changes in V3:
- Removed #ifdef CONFIG_OF_CONTROL where ever
not required.
common/cmd_sound.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_sound.c b/common/cmd_sound.c
index 459d1eb..cfca9dd 100644
--- a/common/cmd_sound.c
+++ b/common/cmd_sound.c
@@ -33,7 +33,7 @@ static int do_init(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
{
int ret;
- ret = sound_init();
+ ret = sound_init(gd-fdt_blob);
if (ret) {
printf(Initialise Audio driver failed\n);
return CMD_RET_FAILURE;
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] include/linux/byteorder: Always defines __fswab64, __swab64p and __swab64s
Hi, Tom. Could you pick this patch? Best regards, Nobuhiro On Fri, Nov 16, 2012 at 9:49 AM, Kim Phillips kim.phill...@freescale.com wrote: On Thu, 15 Nov 2012 16:35:26 +0900 Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com wrote: When __BYTEORDER_HAS_U64__ is not defined, we got warning following: - /tmp/include/linux/byteorder/little_endian.h: In function ‘__cpu_to_be64p’: /tmp/include/linux/byteorder/little_endian.h:71:2: warning: implicit declaration of function ‘__swab64p’ [-Wimplicit-function-declaration] - Usually, __arch__swab64* required for __fswab64, __swab64p and __swab64s is defined. Therefore, __BYTEORDER_HAS_U64__ is unnecessary. This removes __BYTEORDER_HAS_U64__. Signed-off-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com CC: Kim Phillips kim.phill...@freescale.com --- v2: Fix mail address. Reviewed-by: Kim Phillips kim.phill...@freescale.com Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Nobuhiro Iwamatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-sh/master
Hi Tom,
Please pull u-boot-sh master branch.
Best regards,
Nobuhiro
The following changes since commit b8715d8def240014da5614a4f940130ec06d9ebf:
Merge branch 'master' of git://git.denx.de/u-boot-fdt (2012-11-29
06:41:56 -0700)
are available in the git repository at:
git://git.denx.de/u-boot-sh master
for you to fetch changes up to 7c791b3f0a8e42f8012f782ef56ad6e88858e7c4:
serial: serial_sh: bugfix: autoboot fails if serial console is not
connected (2012-11-30 15:06:05 +0900)
Tetsuyuki Kobayashi (1):
serial: serial_sh: bugfix: autoboot fails if serial console is
not connected
Yoshihiro Shimoda (1):
sh: fix trigger_address_error()
arch/sh/include/asm/system.h |2 +-
drivers/serial/serial_sh.c | 20 +---
2 files changed, 14 insertions(+), 8 deletions(-)
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] README.scrapyard: add missing commit IDs
Dear Graeme Russ, In message calbutcjo15hswnydpuyppsxyngvx6s9h2xp0_dq+x4rpny+...@mail.gmail.com you wrote: Board ArchCPU removed Commit last known maintainer/contact = -AMX860 powerpc mpc860 - - Wolfgang Denk w...@denx.de -c2mon powerpc mpc855 - - Wolfgang Denk w...@denx.de -ETX094 powerpc mpc850 - - Wolfgang Denk w...@denx.de -IAD210 powerpc mpc860 - - - -LANTEC powerpc mpc850 - - Wolfgang Denk w...@denx.de -SCMpowerpc mpc8260 - - Wolfgang Grandegger w...@denx.de -SX1arm arm925t - - +AMX860 powerpc mpc860 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +c2mon powerpc mpc855 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +ETX094 powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +IAD210 powerpc mpc860 1b0757e 2012-10-28- +LANTEC powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +SCMpowerpc mpc8260 1b0757e 2012-10-28Wolfgang Grandegger w...@denx.de +SX1arm arm925t 53c4154 2012-10-26 TQM85xxpowerpc MPC85xx d923a5d5 2012-10-04Stefan Roese s...@denx.de apollon arm omap24xx 535c74f 2012-09-18Kyungmin Park kyungmin.p...@samsung.com tb0229 mipsmips32 3f3110d 2011-12-12 'removed' and 'Commit' don't match the order of the header Sorry, I don't get what you mean? Which header? Which order? 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 A mouse is an elephant built by the Japanese. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] EXYNOS5: Add L2 Cache Support.
This patch set adds L2 Cache Support to EXYNOS.
Signed-off-by: Arun Mankuzhi aru...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/cpu/armv7/exynos/soc.c | 37 +
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/soc.c b/arch/arm/cpu/armv7/exynos/soc.c
index ab65b8d..676a388 100644
--- a/arch/arm/cpu/armv7/exynos/soc.c
+++ b/arch/arm/cpu/armv7/exynos/soc.c
@@ -23,6 +23,14 @@
#include common.h
#include asm/io.h
+#include asm/system.h
+
+enum l2_cache_params {
+ CACHE_TAG_RAM_SETUP = (19),
+ CACHE_DATA_RAM_SETUP = (15),
+ CACHE_TAG_RAM_LATENCY = (26),
+ CACHE_DATA_RAM_LATENCY = (20)
+};
void reset_cpu(ulong addr)
{
@@ -36,3 +44,32 @@ void enable_caches(void)
dcache_enable();
}
#endif
+
+#ifndef CONFIG_SYS_L2CACHE_OFF
+/*
+ * Set L2 cache parameters
+ */
+static void exynos5_set_l2cache_params(void)
+{
+ unsigned int val = 0;
+
+ asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r(val));
+
+ val |= CACHE_TAG_RAM_SETUP |
+ CACHE_DATA_RAM_SETUP |
+ CACHE_TAG_RAM_LATENCY |
+ CACHE_DATA_RAM_LATENCY;
+
+ asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val));
+}
+
+/*
+ * Sets L2 cache related parameters before enabling data cache
+ */
+void v7_outer_cache_enable(void)
+{
+ if (cpu_is_exynos5())
+ exynos5_set_l2cache_params();
+}
+#endif
+
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] README.scrapyard: add missing commit IDs
Hi Wolfgang, On 30/11/2012, at 5:20 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message calbutcjo15hswnydpuyppsxyngvx6s9h2xp0_dq+x4rpny+...@mail.gmail.com you wrote: Board ArchCPU removed Commit last known maintainer/contact = apollon arm omap24xx 535c74f 2012-09-18Kyungmin Park kyungmin.p...@samsung.com tb0229 mipsmips32 3f3110d 2011-12-12 'removed' and 'Commit' don't match the order of the header Sorry, I don't get what you mean? Which header? Which order? The order of the field list on the first line doesn't match the order of the fields pf the entries Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
