August 2011 - U-Boot

[U-Boot] [PATCH V2] NAND: Allow per-buffer allocation
by Marek Vasut 10 Aug '11

10 Aug '11

Don't allocate NAND buffers as one block, but allocate them separately. This allows systems where DMA to buffers happen to allocate these buffers properly aligned. Signed-off-by: Marek Vasut <marek.vasut(a)gmail.com> --- drivers/mtd/nand/nand_base.c | 30 +++++++++++++++++++++++------- include/linux/mtd/nand.h | 7 ++++--- 2 files changed, 27 insertions(+), 10 deletions(-) V2: Fix the chip->buffers->buffer condition diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 1a95a91..2c0863f 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2749,13 +2749,27 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips, */ int nand_scan_tail(struct mtd_info *mtd) { - int i; + int i, bufsize; + uint8_t *buf; struct nand_chip *chip = mtd->priv; - if (!(chip->options & NAND_OWN_BUFFERS)) - chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL); - if (!chip->buffers) - return -ENOMEM; + if (!(chip->options & NAND_OWN_BUFFERS)) { + chip->buffers = malloc(sizeof(struct nand_buffers)); + if (!chip->buffers) + return -ENOMEM; + + bufsize = NAND_MAX_PAGESIZE + (3 * NAND_MAX_OOBSIZE); + buf = malloc(bufsize); + if (!buf) { + free(chip->buffers); + return -ENOMEM; + } + + chip->buffers->buffer = (struct nand_buffers *)buf; + chip->buffers->ecccalc = buf; + chip->buffers->ecccode = buf + NAND_MAX_OOBSIZE; + chip->buffers->databuf = buf + (2 * NAND_MAX_OOBSIZE); + } /* Set the internal oob buffer location, just after the page data */ chip->oob_poi = chip->buffers->databuf + mtd->writesize; @@ -2996,6 +3010,8 @@ void nand_release(struct mtd_info *mtd) /* Free bad block table memory */ kfree(chip->bbt); - if (!(chip->options & NAND_OWN_BUFFERS)) - kfree(chip->buffers); + if (!(chip->options & NAND_OWN_BUFFERS)) { + free(chip->buffers->buffer); + free(chip->buffers); + } } diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 987a2ec..c3449a9 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -370,9 +370,10 @@ struct nand_ecc_ctrl { * consecutive order. */ struct nand_buffers { - uint8_t ecccalc[NAND_MAX_OOBSIZE]; - uint8_t ecccode[NAND_MAX_OOBSIZE]; - uint8_t databuf[NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE]; + uint8_t *buffer; + uint8_t *ecccalc; + uint8_t *ecccode; + uint8_t *databuf; }; /** -- 1.7.5.4

1 0

[U-Boot] [PATCH] NAND: Allow per-buffer allocation
by Marek Vasut 10 Aug '11

10 Aug '11

Don't allocate NAND buffers as one block, but allocate them separately. This allows systems where DMA to buffers happen to allocate these buffers properly aligned. Signed-off-by: Marek Vasut <marek.vasut(a)gmail.com> --- drivers/mtd/nand/nand_base.c | 27 +++++++++++++++++++++------ include/linux/mtd/nand.h | 7 ++++--- 2 files changed, 25 insertions(+), 9 deletions(-) NOTE: This less intrusive approach should avoid breaking older drivers (this is the reason for malloc()ing chip->buffers). diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 1a95a91..be8469c 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2749,12 +2749,25 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips, */ int nand_scan_tail(struct mtd_info *mtd) { - int i; + int i, bufsize; + uint8_t *buf; struct nand_chip *chip = mtd->priv; - if (!(chip->options & NAND_OWN_BUFFERS)) - chip->buffers = kmalloc(sizeof(*chip->buffers), GFP_KERNEL); - if (!chip->buffers) + if (!(chip->options & NAND_OWN_BUFFERS)) { + chip->buffers = malloc(sizeof(struct nand_buffers)); + if (!chip->buffers) + return -ENOMEM; + + bufsize = NAND_MAX_PAGESIZE + (3 * NAND_MAX_OOBSIZE); + buf = malloc(bufsize); + + chip->buffers->buffer = (struct nand_buffers *)buf; + chip->buffers->ecccalc = buf; + chip->buffers->ecccode = buf + NAND_MAX_OOBSIZE; + chip->buffers->databuf = buf + (2 * NAND_MAX_OOBSIZE); + } + + if (!chip->buffers->buffer) return -ENOMEM; /* Set the internal oob buffer location, just after the page data */ @@ -2996,6 +3009,8 @@ void nand_release(struct mtd_info *mtd) /* Free bad block table memory */ kfree(chip->bbt); - if (!(chip->options & NAND_OWN_BUFFERS)) - kfree(chip->buffers); + if (!(chip->options & NAND_OWN_BUFFERS)) { + free(chip->buffers->buffer); + free(chip->buffers); + } } diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 987a2ec..c3449a9 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -370,9 +370,10 @@ struct nand_ecc_ctrl { * consecutive order. */ struct nand_buffers { - uint8_t ecccalc[NAND_MAX_OOBSIZE]; - uint8_t ecccode[NAND_MAX_OOBSIZE]; - uint8_t databuf[NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE]; + uint8_t *buffer; + uint8_t *ecccalc; + uint8_t *ecccode; + uint8_t *databuf; }; /** -- 1.7.5.4

2 2

[U-Boot] CONFIRMATION LETTER FROM KIA.
by Monica Veldhuizen 10 Aug '11

10 Aug '11

Attention: Lucky Winner, confirmation Approval #: KIASOULXX72/2011. We are happy to announce that you are one of our Lucky Ten (10) Star Prize Winner in this year edition of the KIA MOTORS END OF YEAR 2011 LOTTERY PROMOTION. This makes you a proud owner a KIA's brand new 2011 Soul Car and a cash sum of £550,000.00 Great British Pounds Sterling. ************************************************* Contact: Mr. ZACHARY ASHTON Email: kiaawarddeptoffice(a)yahoo.com.hk Call Tel No.: +4407035966196 ************************************************* Provide Her with your Full Name:( )Tel:( )Sex:( )Age( ) Marital Status:( )Occupation:( )Country:( )City:( ) Alternative E-mail:( ) and Approval # (KIASOULXX72/2011). **Note: Forward All replies, Concerning your claims should be sent to kiaawarddeptoffice(a)yahoo.com.hk DaVita Inc.

1 0

[U-Boot] 4-bit ECC (BCH) support for NAND
by Hitz, Christian 09 Aug '11

09 Aug '11

Hi, we are looking to change the NAND flash part on our custom board (AT91SAM9G20-EK based). The new part requires at least a 4-bit ECC algorithm (e.g. BCH). As our processor has no hardware ECC capabilities the ECC has to be calculated in software. The Linux kernel has support for BCH ECC since 2.6.39. Has U-Boot support for this kind of ECC algorithm? E.g. Could we use U-Boot to write a kernel and rootfs with matching ECC into the flash? Regards, Christian -- Christian Hitz aizo ag, Schlieren, Switzerland, www.aizo.com

2 1

[U-Boot] USB works (or not) depending on SYS_BOOT (with TPS65920)
by Orjan Friberg 09 Aug '11

09 Aug '11

Hi, I'm seeing some weird behaviour with host mode USB on the OTG port in u-boot (2011.03), and just wondering if anyone else seen this. Booting from NAND after a power cycle, host mode USB doesn't work (the 'usb reset' command times out). However, if I change the boot order (external button) to go through USB and UART before NAND it does work (it enters host mode, and devices are discovered). After that, USB continues to work after warm-resetting the board. It's not until after a cold reset/power cycle that it stops working again. It seems the boot rom must be doing some initialization of the USB phy (this is with a TPS65920). Dumping the I2C regs of the USB phy in u-boot shows a lot of differences between the two boot modes. This is on a custom board, BeagleBoard derived but with a 3730. Any ideas? Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB

2 4

Re: [U-Boot] Confirmation Letter From Microsoft/Yahoo Web Team
by King, Gary 09 Aug '11

09 Aug '11

________________________________ From: King, Gary Sent: Tuesday, August 09, 2011 11:06 AM To: King, Gary Subject: Confirmation Letter From Microsoft/Yahoo Web Team This is a confidential message from the Microsoft/Yahoo Office, You have been approved by the Microsoft/Yahoo Foundation Payment Board to receive a cash grant of $552,000.00 Dollars E-mail us on: msoft-helpdesk1(a)hotmail.com<mailto:msoft-helpdesk1@hotmail.com> Contact Secertary- Mr. Wilson Harlings on this email: msoft-helpdesk1(a)hotmail.com<mailto:msoft-helpdesk1@hotmail.com> Provide him With 1. Full Name: 2. Address: 3. Tel/Mobile: 4. Occupation: 5. Date of Birth: 6. Payment number: G-900-94 Note: All response and Queries concerning your claims should be sent via email to :(msoft-helpdesk1@hotmail.com<mailto:msoft-helpdesk1@hotmail.com>) King Gary- Announcer CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain proprietary and privileged information for the use of the designated recipients named above. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

1 0

[U-Boot] [PATCH] mkimage: Fix 'Unknown OMAP image type - 5'
by Dirk Behme 09 Aug '11

09 Aug '11

From: Dirk Behme <dirk.behme(a)googlemail.com> Using mkimage with e.g. tools/mkimage -A arm -T firmware -O u-boot -d u-boot.bin foo.img gives a warning "Unknown OMAP image type - 5" while it seems that the image itself is created successfully. This does come from the patch "mkimage: Add OMAP boot image support". Reordering the init_xx_image_type() sequence does make this message go away. Signed-off-by: Dirk Behme <dirk.behme(a)googlemail.com> CC: John Rigby <john.rigby(a)linaro.org> CC: Aneesh V <aneesh(a)ti.com> CC: Sandeep Paulraj <s-paulraj(a)ti.com> --- This is reproducable with the recent mainline mkimage where the patch "mkimage: Add OMAP boot image support" is applied: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=3decb14abe76d… tools/mkimage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: u-boot.git/tools/mkimage.c =================================================================== --- u-boot.git.orig/tools/mkimage.c +++ u-boot.git/tools/mkimage.c @@ -156,12 +156,12 @@ main (int argc, char **argv) init_imx_image_type (); /* Init FIT image generation/list support */ init_fit_image_type (); - /* Init TI OMAP Boot image generation/list support */ - init_omap_image_type(); /* Init Default image generation/list support */ init_default_image_type (); /* Init Davinci UBL support */ init_ubl_image_type(); + /* Init TI OMAP Boot image generation/list support */ + init_omap_image_type(); params.cmdname = *argv; params.addr = params.ep = 0;

4 4

[U-Boot] Linux boot and list loading feature
by Simon Schwarz 09 Aug '11

09 Aug '11

Hi Aneesh, I am working on the OS booting right now and have a bigger change of your code in spl.c in mind. Hope you can say one or two words what you think about it. THE PROBLEM For the direct OS boot and in some other situations - env image e.g., I have to load more than one image in SPL. This can be done by hardcoding these cases and use #ifdef or ifs to switch between them. Or I can implement a general image loading with lists. (This was discussed here: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345) I already implemented the list for NAND - and now start prototyping it also for MMC. There will be some change to your spl.c-code so I decided to ask what you think about it. These are the modifications in the board config: /* Assemble boot lists */ /* Last image in list is image to boot! */ /* NAND boot lists */ #define CONFIG_SPL_NAND_OS_LOAD {CONFIG_CMD_SAVEBP_NAND_OFS, \ CONFIG_SYS_NAND_SPL_KERNEL_OFFS} #ifdef CONFIG_NAND_ENV_DST #ifdef CONFIG_ENV_OFFSET_REDUND #define CONFIG_SPL_NAND_UBOOT_LOAD {CONFIG_ENV_OFFSET_REDUND, \ CONFIG_ENV_OFFSET, \ CONFIG_SYS_NAND_U_BOOT_OFFS} #endif #define CONFIG_SPL_NAND_UBOOT_LOAD {CONFIG_ENV_OFFSET, \ CONFIG_SYS_NAND_U_BOOT_OFFS} #else #define CONFIG_SPL_NAND_UBOOT_LOAD {CONFIG_SYS_NAND_U_BOOT_OFFS} #endif /* MMC RAW boot lists */ #define CONFIG_SPL_MMCSD_RAW_OS_LOAD {0x0, 0x0} /* XXX: define me */ #define CONFIG_SPL_MMCSD_RAW_UBOOT_LOAD {\ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR} /* MMC RAW boot lists */ #define CONFIG_SPL_MMCSD_FAT_OS_LOAD {"uImage", "fdt_params.img"} #define CONFIG_SPL_MMCSD_FAT_UBOOT_LOAD {CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME} Essentially just putting together the lists for all the different boot devices/modes. Your mmc_load_image_raw will then look like this: static void mmc_load_image_raw(struct mmc *mmc) { u32 image_size_sectors, err; const struct image_header *header; uint32_t i; #ifdef CONFIG_SPL_OS_BOOT uint32_t load_list_os[] = CONFIG_SPL_MMCSD_RAW_OS_LOAD; #endif uint32_t load_list_uboot[] = CONFIG_SPL_MMCSD_RAW_UBOOT_LOAD; uint32_t *load_list = load_list_uboot; header = (struct image_header *)(CONFIG_SYS_TEXT_BASE - sizeof(struct image_header)); #ifdef CONFIG_SPL_OS_BOOT if (!uboot_key()) load_list = load_list_os; #endif for(i = 0; i < N_LOAD_LIST_ENTRYS; i++) { /* read image header to find the image size & load address */ err = mmc->block_dev.block_read(0, load_list[i], 1, (void *)header); if (err <= 0) goto end; parse_image_header(header); /* convert size to sectors - round up */ image_size_sectors = (image_size + MMCSD_SECTOR_SIZE - 1) / MMCSD_SECTOR_SIZE; /* Read the header too to avoid extra memcpy */ err = mmc->block_dev.block_read(0, load_list[i], image_size_sectors, (void *)image_load_addr); } end: if (err <= 0) { printf("spl: mmc blk read err - %d\n", err); hang(); } } This is just a protoype - quick, dirty & untested. I would be happy to hear what you think about the approach. Regards Simon

4 6

[U-Boot] problem with mpc837x start.S
by shawn Bai 09 Aug '11

09 Aug '11

Hello, boys and girls, my name is shawn Bai. I am new here and hope not disturb you. Although I have not posted before, what you do is very helpful to me to understand what is bsp, how it runs, and so on. I don't know whether the question below is mentioned or not before. If yes, do you mind telling me where I can find the answer. Thanks in advance. The question is about arch\powerpc\cpu\83xx\start.S. the demo board I use is MPC837xERDB, there is 8MBytes Nor flash on it. by default, uboot is booted from lower address, it means BMS field in HRCW is 0, which will affect value of MSR[IP] later. First instruction locates at _start label in uboot. Before first instruction runs, hardware reset configuration word will be loaded to make some basic configuration. Before branching to MONITOR_BASE+in_flash using blr instruction， size of LCS0 is inflated to 4GBytes， and eLBC access window 1 is configured with BAR MONITOR_BASE, and SIZE 8MBytes. After this is done, blr to MONITOR_BASE+in_flash. after branching to MONITOR_BASE+in_flash, LCS0 BAR is modified to MONITOR_BASE, and its size is configured with 8Mbytes again. This is what I know. But the problem which is confused to me is after reset, the default value of LCS0 BAR is 0x0000_0000, and its size is 8Mbytes. In order to branch to MONITOR_BASE+in_flash, inlarge Nor flash to 4GB, and configure eLBC access window 1. But the actual size of Nor flash is 8MB , even after inlarging it, where (MONITOR_BASE+in_flash) points to? why? why does branching to in_flash need absolute address? and make absolute address like this? I rack my brains, but there is no result. Do you mind showing me a way? Thanks very much. Shawn Bai > > ------------------------------ > > _______________________________________________ > U-Boot mailing list > U-Boot(a)lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > **************************************

2 9

[U-Boot] y-modem protocol issue
by Angelo Dureghello 09 Aug '11

09 Aug '11

Hi all, just to inform, seems xyzModem is not following the protocol spec of YModem: YMODEM Batch Transmission Session (1 file) SENDER RECEIVER <-- C (command:rb) SOH 00 FF foo.c NUL[123] CRC CRC --> <-- ACK <-- C SOH 01 FE Data[128] CRC CRC --> <-- ACK SOH 02 FC Data[128] CRC CRC --> <-- ACK SOH 03 FB Data[100] CPMEOF[28] CRC CRC --> <-- ACK EOT --> <-- NAK EOT --> <-- ACK <-- C SOH 00 FF NUL[128] CRC CRC --> <-- ACK After first EOT u-boot send an ACK, not correct. Same behavior using SOH or STX. Regards angelo

2 2