February 2011 - U-Boot

[U-Boot] [PATCH 1/3 RESEND] MC13892: Add SWx buck switchers definitions
by Marek Vasut 01 Feb '11

01 Feb '11

Define voltages configurable on SWx buck switchers. Signed-off-by: Marek Vasut <marek.vasut(a)gmail.com> Acked-by: Stefano Babic <sbabic(a)denx.de> --- include/mc13892.h | 39 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/include/mc13892.h b/include/mc13892.h index 61c3e6e..a1078a5 100644 --- a/include/mc13892.h +++ b/include/mc13892.h @@ -160,4 +160,43 @@ /* Reg Power Control 2*/ #define WDIRESET (1 << 12) +/* Buck Switchers (SW1,2,3,4) Output Voltage */ +/* + * NOTE: These values are for SWxHI = 0, + * SWxHI = 1 adds 0.5V to the desired voltage + */ +#define SWx_0_600V 0 +#define SWx_0_625V 1 +#define SWx_0_650V 2 +#define SWx_0_675V 3 +#define SWx_0_700V 4 +#define SWx_0_725V 5 +#define SWx_0_750V 6 +#define SWx_0_775V 7 +#define SWx_0_800V 8 +#define SWx_0_825V 9 +#define SWx_0_850V 10 +#define SWx_0_875V 11 +#define SWx_0_900V 12 +#define SWx_0_925V 13 +#define SWx_0_950V 14 +#define SWx_0_975V 15 +#define SWx_1_000V 16 +#define SWx_1_025V 17 +#define SWx_1_050V 18 +#define SWx_1_075V 19 +#define SWx_1_100V 20 +#define SWx_1_125V 21 +#define SWx_1_150V 22 +#define SWx_1_175V 23 +#define SWx_1_200V 24 +#define SWx_1_225V 25 +#define SWx_1_250V 26 +#define SWx_1_275V 27 +#define SWx_1_300V 28 +#define SWx_1_325V 29 +#define SWx_1_350V 30 +#define SWx_1_375V 31 +#define SWx_VOLT_MASK 0x1F + #endif -- 1.7.2.3

5 15

[U-Boot] [PATCH] MXC: removed warnings from IMX51 ATA driver
by Stefano Babic 01 Feb '11

01 Feb '11

Drop warnings due to unused variables. Signed-off-by: Stefano Babic <sbabic(a)denx.de> CC: Marek Vasut <marek.vasut(a)gmail.com> --- drivers/block/mxc_ata.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/block/mxc_ata.c b/drivers/block/mxc_ata.c index 842a633..f22f4f4 100644 --- a/drivers/block/mxc_ata.c +++ b/drivers/block/mxc_ata.c @@ -87,11 +87,8 @@ struct mxc_data_hdd_regs { /* PIO timing table */ #define NR_PIO_SPECS 5 -static uint16_t pio_t0[NR_PIO_SPECS] = { 600, 383, 240, 180, 120 }; static uint16_t pio_t1[NR_PIO_SPECS] = { 70, 50, 30, 30, 25 }; static uint16_t pio_t2_8[NR_PIO_SPECS] = { 290, 290, 290, 80, 70 }; -static uint16_t pio_t2_16[NR_PIO_SPECS] = { 165, 125, 100, 80, 70 }; -static uint16_t pio_t2i[NR_PIO_SPECS] = { 40, 0, 0, 0, 0 }; static uint16_t pio_t4[NR_PIO_SPECS] = { 30, 20, 15, 10, 10 }; static uint16_t pio_t9[NR_PIO_SPECS] = { 20, 15, 10, 10, 10 }; static uint16_t pio_tA[NR_PIO_SPECS] = { 50, 50, 50, 50, 50 }; -- 1.7.1

2 1

[U-Boot] [PATCH] BLOCK: Fixup iMX51 ATA driver
by Marek Vasut 01 Feb '11

01 Feb '11

Signed-off-by: Marek Vasut <marek.vasut(a)gmail.com> --- NOTE: Wolfgang, is this what you meant ? If so, I'll merge this with the old driver and send a v2 patch. Otherwise, can you point me in a right direction? NOTE2: I haven't tested this, I'll do so in the evening. drivers/block/mxc_ata.c | 131 +++++++++++++++++++++++++--------------------- 1 files changed, 71 insertions(+), 60 deletions(-) diff --git a/drivers/block/mxc_ata.c b/drivers/block/mxc_ata.c index 6f19e6f..e65cfa7 100644 --- a/drivers/block/mxc_ata.c +++ b/drivers/block/mxc_ata.c @@ -37,49 +37,53 @@ #include <asm/arch/clock.h> /* MXC ATA register offsets */ -enum { - MXC_ATA_TIME_OFF = 0x00, - MXC_ATA_TIME_ON = 0x01, - MXC_ATA_TIME_1 = 0x02, - MXC_ATA_TIME_2W = 0x03, - MXC_ATA_TIME_2R = 0x04, - MXC_ATA_TIME_AX = 0x05, - MXC_ATA_TIME_PIO_RDX = 0x06, - MXC_ATA_TIME_4 = 0x07, - MXC_ATA_TIME_9 = 0x08, - MXC_ATA_TIME_M = 0x09, - MXC_ATA_TIME_JN = 0x0a, - MXC_ATA_TIME_D = 0x0b, - MXC_ATA_TIME_K = 0x0c, - MXC_ATA_TIME_ACK = 0x0d, - MXC_ATA_TIME_ENV = 0x0e, - MXC_ATA_TIME_UDMA_RDX = 0x0f, - MXC_ATA_TIME_ZAH = 0x10, - MXC_ATA_TIME_MLIX = 0x11, - MXC_ATA_TIME_DVH = 0x12, - MXC_ATA_TIME_DZFS = 0x13, - MXC_ATA_TIME_DVS = 0x14, - MXC_ATA_TIME_CVH = 0x15, - MXC_ATA_TIME_SS = 0x16, - MXC_ATA_TIME_CYC = 0x17, - MXC_ATA_FIFO_DATA_16 = 0x1c, - MXC_ATA_FIFO_DATA_32 = 0x18, - MXC_ATA_FIFO_FILL = 0x20, - MXC_ATA_ATA_CONTROL = 0x24, - MXC_ATA_INTERRUPT_PENDING = 0x28, - MXC_ATA_INTERRUPT_ENABLE = 0x2c, - MXC_ATA_INTERRUPT_CLEAR = 0x30, - MXC_ATA_FIFO_ALARM = 0x34, - MXC_ATA_DRIVE_DATA = 0xa0, - MXC_ATA_DRIVE_FEATURES = 0xa4, - MXC_ATA_DRIVE_SECTOR_COUNT = 0xa8, - MXC_ATA_DRIVE_SECTOR_NUM = 0xac, - MXC_ATA_DRIVE_CYL_LOW = 0xb0, - MXC_ATA_DRIVE_CYL_HIGH = 0xb4, - MXC_ATA_DRIVE_DEV_HEAD = 0xb8, - MXC_ATA_COMMAND = 0xbc, - MXC_ATA_STATUS = 0xbc, - MXC_ATA_ALT_STATUS = 0xd8, +struct mxc_ata_config_regs { + u8 time_off; /* 0x00 */ + u8 time_on; + u8 time_1; + u8 time_2w; + u8 time_2r; + u8 time_ax; + u8 time_pio_rdx; + u8 time_4; + u8 time_9; + u8 time_m; + u8 time_jn; + u8 time_d; + u8 time_k; + u8 time_ack; + u8 time_env; + u8 time_udma_rdx; + u8 time_zah; /* 0x10 */ + u8 time_mlix; + u8 time_dvh; + u8 time_dzfs; + u8 time_dvs; + u8 time_cvh; + u8 time_ss; + u8 time_cyc; + u32 hole; + u32 fifo_data_16; + u32 fifo_data_32; + u32 fifo_fill; + u32 ata_control; + u32 interrupt_pending; + u32 interrupt_enable; + u32 interrupt_clear; + u32 fifo_alarm; +}; + +struct mxc_data_hdd_regs { + u32 drive_data; /* 0xa0 */ + u32 drive_features; + u32 drive_sector_count; + u32 drive_sector_num; + u32 drive_cyl_low; + u32 drive_cyl_high; + u32 drive_dev_head; + u32 command; + u32 status; + u32 alt_status; }; /* PIO timing table */ @@ -93,47 +97,54 @@ uint16_t pio_t4[NR_PIO_SPECS] = { 30, 20, 15, 10, 10 }; uint16_t pio_t9[NR_PIO_SPECS] = { 20, 15, 10, 10, 10 }; uint16_t pio_tA[NR_PIO_SPECS] = { 50, 50, 50, 50, 50 }; -#define REG_TO_OFFSET(reg) ((reg & 0x3) * 8) +#define REG2OFF(reg) ((((uint32_t)reg) & 0x3) * 8) static void set_ata_bus_timing(unsigned char mode) { uint32_t val; uint32_t T = 1000000000 / mxc_get_clock(MXC_IPG_CLK); + struct mxc_ata_config_regs *ata_cfg_regs; + ata_cfg_regs = (struct mxc_ata_config_regs *)CONFIG_SYS_ATA_BASE_ADDR; + if (mode >= NR_PIO_SPECS) return; /* Write TIME_OFF/ON/1/2W */ - val = (3 << REG_TO_OFFSET(MXC_ATA_TIME_OFF)) | - (3 << REG_TO_OFFSET(MXC_ATA_TIME_ON)) | - (((pio_t1[mode] + T) / T) << REG_TO_OFFSET(MXC_ATA_TIME_1)) | - (((pio_t2_8[mode] + T) / T) << REG_TO_OFFSET(MXC_ATA_TIME_2W)); - writel(val, MXC_ATA_TIME_OFF + CONFIG_SYS_ATA_BASE_ADDR); + val = (3 << REG2OFF(&ata_cfg_regs->time_off)) | + (3 << REG2OFF(&ata_cfg_regs->time_on)) | + (((pio_t1[mode] + T) / T) << REG2OFF(&ata_cfg_regs->time_1)) | + (((pio_t2_8[mode] + T) / T) << REG2OFF(&ata_cfg_regs->time_2w)); + writeb(val, &ata_cfg_regs->time_off); /* Write TIME_2R/AX/RDX/4 */ - val = (((pio_t2_8[mode] + T) / T) << REG_TO_OFFSET(MXC_ATA_TIME_2R)) | - (((pio_tA[mode] + T) / T + 2) << REG_TO_OFFSET(MXC_ATA_TIME_AX)) | - (1 << REG_TO_OFFSET(MXC_ATA_TIME_PIO_RDX)) | - (((pio_t4[mode] + T) / T) << REG_TO_OFFSET(MXC_ATA_TIME_4)); - writel(val, MXC_ATA_TIME_2R + CONFIG_SYS_ATA_BASE_ADDR); + val = (((pio_t2_8[mode] + T) / T) << REG2OFF(&ata_cfg_regs->time_2r)) | + (((pio_tA[mode] + T) / T + 2) << REG2OFF(&ata_cfg_regs->time_ax)) | + (1 << REG2OFF(&ata_cfg_regs->time_pio_rdx)) | + (((pio_t4[mode] + T) / T) << REG2OFF(&ata_cfg_regs->time_4)); + writel(val, &ata_cfg_regs->time_2r); /* Write TIME_9 ; the rest of timing registers is irrelevant for PIO */ - val = (((pio_t9[mode] + T) / T) << REG_TO_OFFSET(MXC_ATA_TIME_9)); - writel(val, MXC_ATA_TIME_9 + CONFIG_SYS_ATA_BASE_ADDR); + val = (((pio_t9[mode] + T) / T) << REG2OFF(&ata_cfg_regs->time_9)); + writel(val, &ata_cfg_regs->time_9); } int ide_preinit(void) { - uint32_t ata_control = CONFIG_SYS_ATA_BASE_ADDR + MXC_ATA_ATA_CONTROL; + struct mxc_ata_config_regs *ata_cfg_regs; + ata_cfg_regs = (struct mxc_ata_config_regs *)CONFIG_SYS_ATA_BASE_ADDR; /* 46.3.3.4 @ FSL iMX51 manual */ - writel(0x80, ata_control); /* FIFO normal op., drive reset */ - writel(0xc0, ata_control); /* FIFO normal op., drive not reset */ + /* FIFO normal op., drive reset */ + writel(0x80, ata_cfg_regs->ata_control); + /* FIFO normal op., drive not reset */ + writel(0xc0, ata_cfg_regs->ata_control); /* Configure the PIO timing */ set_ata_bus_timing(CONFIG_MXC_ATA_PIO_MODE); /* 46.3.3.4 @ FSL iMX51 manual */ - writel(0x41, ata_control); /* Drive not reset, IORDY handshake */ + /* Drive not reset, IORDY handshake */ + writel(0x41, ata_cfg_regs->ata_control); return 0; } -- 1.7.2.3

2 2

[U-Boot] nand commands missing wtchdog reset
by Jaap de Jong 01 Feb '11

01 Feb '11

Hi all, On my board (at91sam9263ek) I have enabled the watchdog. It will reset the processor after about 16 seconds. It looks like it is working but if I'm writing a large file into nand it seems that the watchdog is not reset and finally my processor resets. I've patched it, but I'm not sure if it is the right way to do it this way... diff -urN a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c --- a/drivers/mtd/nand/nand_base.c 2010-12-22 20:22:14.000000000 +0100 +++ b/drivers/mtd/nand/nand_base.c 2011-01-31 08:45:07.818135600 +0100 @@ -447,6 +447,7 @@ if (chip->dev_ready) if (chip->dev_ready(mtd)) break; + WATCHDOG_RESET (); } } @@ -730,6 +731,7 @@ if (this->read_byte(mtd) & NAND_STATUS_READY) break; } + WATCHDOG_RESET (); } #ifdef PPCHAMELON_NAND_TIMER_HACK reset_timer(); Regards, Jaap

2 4

[U-Boot] Flashing ubinize image under U-Boot
by Robert Hodaszi 01 Feb '11

01 Feb '11

Hi, I would like to support UBI under U-Boot. I could successfully flash a raw UBIFS image with the "ubi write" command, and also a UBI (ubinize) image with the nand write command. So it's working well. But in the second case, I will loose all existing information (e.g. the erase counters). Under Linux, there's the "ubiformat" application, which can flash this image, while preserves the existing informations. Does the U-Boot support flashing UBI (ubinize) images on the same way (preserving partition informations)? Or if not, then is there any plan to extend the "ubi write" to support the ubinize images?

1 0

[U-Boot] [PATCH 1/6] mtd: add writebufsize field to mtd_info struct
by Holger Brunck 01 Feb '11

01 Feb '11

This field will be used to indicate the write buffer size of the MTD device. UBI will set it's minimal I/O unit size (min_io_size) to the indicated write buffer size. By this change we intend to fix failed recovery of UBIFS partitions we currently observe on NOR flash when mounting the partition after unclean unmount. Currently the min_io_size is set to mtd->writesize (which is 1 byte for NOR flash). But flash programming is often done from prepared write buffer containing multiple bytes and is performed in one programming operation which could be interrupted by a power cut or a system reset causing corrupted (partially written) areas in a flash sector. Knowing the size of potentially corrupted areas UBIFS scanning and recovery algorithms are able to perform successful recovery. Signed-off-by: Holger Brunck <holger.brunck(a)keymile.com> --- include/linux/mtd/mtd.h | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 3b18d7d..14d6f70 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -129,6 +129,17 @@ struct mtd_info { */ u_int32_t writesize; + /* + * Size of the write buffer used by the MTD. MTD devices having a write + * buffer can write multiple writesize chunks at a time. E.g. while + * writing 4 * writesize bytes to a device with 2 * writesize bytes + * buffer the MTD driver can (but doesn't have to) do 2 writesize + * operations, but not 4. Currently, all NANDs have writebufsize + * equivalent to writesize (NAND page size). Some NOR flashes do have + * writebufsize greater than writesize. + */ + u_int32_t writebufsize; + u_int32_t oobsize; /* Amount of OOB data per block (e.g. 16) */ u_int32_t oobavail; /* Available OOB bytes per block */ -- 1.7.0.5

3 9

Re: [U-Boot] [U-BOOT PROBLEM] RAM loading RAMdisk addresses
by Wolfgang Denk 01 Feb '11

01 Feb '11

Dear "GRACE, ERWAN (ERWAN)** CTR **", please make sure to keep the mailing list on Cc: Also, please restrict your line length to some 70 characters or so. In message <F427B25935CD0742BA694C0B6918F5701B70632924(a)FRMRSSXCHMBSE2.dc-m.alcatel-lucent.com> you wrote: > > Thank you for your answer. I'd like to precise that the 2 RAMdisks > weren't built from exactly the same set of files. There's a small > difference between these RAMdisks as one of them was generated > after replacing only one filewith another file which is supposed to > be exactly the same as the first one. So, at the end of the day, > these RAMdisks should have the same size but that isn't the case. I No, they should not. They should probably have the same content on a file system level, but when erasing a file and replacing it by another one (or even an identical copy) you will have other file system blocks used, other inode and free block lists, etc. In other words, the binary images of the file systems will be different. They will most probably also compress to different sizes, then. > precise that I'm not the person who generated these RAMdisks, > that's why I try to understand why there's such a difference betw > een them. Moreover, in the messages displayed on the screen when the They are different images, with different sizes. > board is booting, we can see that the addresses shown in the line > "Loading RAMdisk to ..., end ... OK" are different. I'd like to > know where these addressesare defined (in a configuration file? In They are computed based on the ramdisk sizes (plus some rounding). Given different ramdisk sizes you end up with different load addresses. There is no magic anywhere here. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Emotions are alien to me. I'm a scientist. -- Spock, "This Side of Paradise", stardate 3417.3

1 0

[U-Boot] Nice To Meet You.
by Mary Aburey 01 Feb '11

01 Feb '11

Nice To Meet You. Howare you and how is your work? i hope that all is well with you, My name is miss Mary. i know that you may be suprise how i get your email, i got your email today when i was browsing looking for honest partner, then i feel to drop this few line to you , and i will like you to contact me through my email so that we can know each other and exchange our pictures, and we may become partner. Remember the distance does not matter what matters is the love we share with each other. i am waiting to hear from you soon. kiss regards Miss Mary.

1 0

[U-Boot] calling pci_init before relocation?
by Michael Schwingen 01 Feb '11

01 Feb '11

Hi, ist it allowed to call pci_init before relocation? The code looks like this is not supposed to happen. However, on ARM, arm_pci_init (which calls pci_init in turn) is called from init_sequence, which happens before relocation. Am I overlooking some way in which this can actually work? Are there boards using this? If I move pci_init down into board_init_r, I can get PCI working on IXP42x, but I am worried if this will cause problems on other boards. cu Michael

4 10

[U-Boot] PPC 405EX hangs waiting for PCIE to reset
by David Thomas 01 Feb '11

01 Feb '11

We have a board with an AMCC PPC 405EX connected to two fpga's with PCIE interfaces. On some boards, on power up, the u-boot code hangs in the while loop in the following code waiting for PCIE1 to come out of reset. PCIE0 comes out of reset successfully. The PHYSTA for PCIE1 always reads back with the value 0x30000000, indicating the the interface is in the P2 state and that the PLL has not locked. If a timeout is added and U-boot is allowed to proceed, a machine check is eventually taken and the processor reboots. During the reboot, u-boot runs through the same code but this time both PCIE interfaces successfully come out of reset and the board comes up normally. Any suggestions about what might be happening here? Thanks David Thomas. u-boot/arch/powerpc/cpu/ppc4xx/4xx_pcie.c, lines 840-848: SDR_WRITE(SDRN_PESDR_RCSSET(port), 0x01101000); /* poll for phy !reset */ while (!(SDR_READ(SDRN_PESDR_PHYSTA(port)) & 0x00001000)) ; /* deassert the PE0_gpl_utl_reset */ SDR_WRITE(SDRN_PESDR_RCSSET(port), 0x00101000);

2 1