Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
On 05/25/2011 05:38 PM, Michael Jones wrote: > While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c > bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more > devices when probing an i2c bus". It detects more devices indeed, such > as some that don't even exist. Even better than that, it detects > different devices every time. It looks like just false positives, the > existent devices seem to always be found among the ghost devices. > > Here's the behavior I see: > -- > # i2c probe > Valid chip addresses: 05 18 30 49 50 51 5E 7A > # i2c probe > Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C > # i2c probe > Valid chip addresses: 18 2E 30 33 35 50 51 62 6F > # i2c probe > Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D > # i2c probe > Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 > # i2c probe > Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C > > > Here's what it looks like after reverting the commit: > -- > # i2c probe > Valid chip addresses: 18 30 50 51 > # i2c probe > Valid chip addresses: 18 30 50 51 > # i2c probe > Valid chip addresses: 18 30 50 51 > # i2c probe > Valid chip addresses: 18 30 50 51 > > > -Michael Sorry- relevant point here: I have a device with a 2-byte subaddress, which I suspect is the culprit here. As Nick mentioned in his commit message, such devices are unsupported by the current OMAP i2c driver. I'm in the process of adding support for 2-byte subaddresses to the driver. In light of the above, I now realize that such changes will probably have to involve i2c_probe() as well. -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
Hello Michael, Michael Jones wrote: > On 05/25/2011 05:38 PM, Michael Jones wrote: >> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c >> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more >> devices when probing an i2c bus". It detects more devices indeed, such >> as some that don't even exist. Even better than that, it detects >> different devices every time. It looks like just false positives, the >> existent devices seem to always be found among the ghost devices. >> >> Here's the behavior I see: >> -- >> # i2c probe >> Valid chip addresses: 05 18 30 49 50 51 5E 7A >> # i2c probe >> Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C >> # i2c probe >> Valid chip addresses: 18 2E 30 33 35 50 51 62 6F >> # i2c probe >> Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D >> # i2c probe >> Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 >> # i2c probe >> Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C >> >> >> Here's what it looks like after reverting the commit: >> -- >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> >> >> -Michael > > Sorry- relevant point here: I have a device with a 2-byte subaddress, > which I suspect is the culprit here. As Nick mentioned in his commit > message, such devices are unsupported by the current OMAP i2c driver. > I'm in the process of adding support for 2-byte subaddresses to the > driver. In light of the above, I now realize that such changes will > probably have to involve i2c_probe() as well. Ah, good point. Thanks! (I just looked at this commit, and couldn;t find, why it does such a mess) ... waiting for a patch, which adds 2-byte subaddress support ;-) 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] uses hardware FP, whereas u-boot uses software FP
hill all I encountered an error libgcc.a(_divsi3.oS) uses hardware FP, whereas u-boot uses software FP when I compile u-boot How do I solve this problem and I am very confused with that gcc's soft's float and glibc's soft float who can help me or show me the Information where can i find Best regards ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
Michael, > On 05/25/2011 05:38 PM, Michael Jones wrote: >> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c >> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more >> devices when probing an i2c bus". It detects more devices indeed, such >> as some that don't even exist. Even better than that, it detects >> different devices every time. It looks like just false positives, the >> existent devices seem to always be found among the ghost devices. >> >> Here's the behavior I see: >> -- >> # i2c probe >> Valid chip addresses: 05 18 30 49 50 51 5E 7A >> # i2c probe >> Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C >> # i2c probe >> Valid chip addresses: 18 2E 30 33 35 50 51 62 6F >> # i2c probe >> Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D >> # i2c probe >> Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 >> # i2c probe >> Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C >> >> >> Here's what it looks like after reverting the commit: >> -- >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> >> >> -Michael > Sorry- relevant point here: I have a device with a 2-byte subaddress, > which I suspect is the culprit here. As Nick mentioned in his commit > message, such devices are unsupported by the current OMAP i2c driver. > I'm in the process of adding support for 2-byte subaddresses to the > driver. In light of the above, I now realize that such changes will > probably have to involve i2c_probe() as well. Using CONFIG_SYS_I2C_NOPROBES for the extended adressing devices should do the trick. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-samsung/master
Hi Minkyu, Le 26/05/2011 08:24, Minkyu Kang a écrit : >> Rather than a merge, could you please do a rebase (onto f14a522a >> (Beagleboard: fixed typo in typecast) as indicated in >> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#BEFORE_Requesting_a_Pull)? > > I already did a rebase. > Any problem? The problem is, it is not a rebase. What you did apparently is merge the u-boot-arm master branch to yours, yielding the commit that your pull request is based upon. What the Wiki suggests is that you rebase your branch onto the target one before doing the pull request, so that it is based upon the tip of the target branch. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
Dear Graeme Russ, In message you wrote: > > and then start banging on arch maintainers heads to implement the trivial > ISR to kick the prescaler: I guess a lot of my confusion could be removed if you could think of a better name for this function. For me a "prescaler" has a very definitive meaning, and it is nothing you need to "kick". 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 Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uses hardware FP, whereas u-boot uses software FP
Dear =?gb2312?B?vaq6o7fh?=, In message you wrote: > > hill all valley you! > I encountered an error > libgcc.a(_divsi3.oS) uses hardware FP, whereas u-boot uses software FP > when I compile u-boot > How do I solve this problem and I am very confused with that gcc's soft's > float and glibc's soft float > who can help me or show me the Information where can i find Search the archives? Short answer: Set USE_PRIVATE_LIBGCC=yes in your environment and rebuild. 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 It all seemed, he thought, to be rather a lot of trouble to go to just sharpen a razor blade. - Terry Pratchett, _The Light Fantastic_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fixed patch for broken at91sam9263ek board
Hi all I did a patch for broken at91sam9263ek board and it fixes the u-boot compilation errors due to rework. If anybody uses the board, please test it and let me know the bugs. Waiting for ur response. Thanks & Regards vicky at91sam9263.patch Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Review of U-Boot timer API
On Thursday, May 26, 2011, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message you wrote: >> >> and then start banging on arch maintainers heads to implement the trivial >> ISR to kick the prescaler: > > I guess a lot of my confusion could be removed if you could think of a > better name for this function. For me a "prescaler" has a very > definitive meaning, and it is nothing you need to "kick". sync_timebase ? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] after relocation, the original text_base memory section can't be used
Hi, With 2011.03 uboot, I am adding firmware flashing feature to our arm cortex a9 soc platform via usb, in which the data firstly be uploaded to memory wholly (more than 200MB, thanks our 512MB physical memory), then burned. By my understanding, after relocation the successive memory range (0~~ relocaddr) can be (re)used. however, if the original text section (in my case, 0x0150) is written, the data abort happens when accessing 0x0160; if the memory section (0x0150~0x0160) not written, everything is ok. please correct me if I am wrong. u-boot image: arm-none-linux-gnueabi-objdump -h .obj/boot/uboot/u-boot .obj/boot/uboot/u-boot: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 000373f4 0150 0150 8000 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .rodata 804c 015373f4 015373f4 0003f3f4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 0040 0153f440 0153f440 00047440 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .data 0a74 0153f480 0153f480 00047480 2**3 CONTENTS, ALLOC, LOAD, DATA 4 .got.plt 000c 0153fef4 0153fef4 00047ef4 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .u_boot_cmd 04f8 0153ff00 0153ff00 00047f00 2**2 CONTENTS, ALLOC, LOAD, DATA 6 .dynsym 00b0 015462a0 0154bb6c 00053b6c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .rel.dyn 5ea8 015403f8 015403f8 000483f8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .bss 58cc 015403f8 015403f8 0004e2a0 2**3 ALLOC 9 .ARM.attributes 002d 00053c1c 2**0 CONTENTS, READONLY and the u-boot runtime info U-Boot 2011.03-dirty-svn4940 (May 26 2011 - 15:08:09) for PRIMA2 U-Boot code: 0150 -> 015403F8 BSS: -> 01545CC4 CPU:Prima2 Board: Prima2 EVB monitor len: 00045CC4 ramsize: 2000 TLB table at: 1fff Top of RAM usable for U-Boot at: 1fff Reserving 279k for U-Boot at: 1ffaa000 Reserving 1056k for malloc() at: 1fea2000 Reserving 24 Bytes for Board Info at: 1fea1fe8 Reserving 120 Bytes for Global Data at: 1fea1f70 New Stack Pointer is: 1fea1f68 RAM Configuration: Bank #0: 512 MiB relocation Offset is: 1eaaa000 monitor flash len: 00046350 Now running in RAM - U-Boot at: 1ffaa000 MMC: to Init SD0... Prima2 SD/MMC: 0 *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 Prima2 # Thanks. Yuping ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
On 26/05/11 08:03, Michael Jones wrote: > On 05/25/2011 05:38 PM, Michael Jones wrote: >> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c >> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more >> devices when probing an i2c bus". It detects more devices indeed, such >> as some that don't even exist. Even better than that, it detects >> different devices every time. It looks like just false positives, the >> existent devices seem to always be found among the ghost devices. >> >> Here's the behavior I see: >> -- >> # i2c probe >> Valid chip addresses: 05 18 30 49 50 51 5E 7A >> # i2c probe >> Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C >> # i2c probe >> Valid chip addresses: 18 2E 30 33 35 50 51 62 6F >> # i2c probe >> Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D >> # i2c probe >> Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 >> # i2c probe >> Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C >> >> >> Here's what it looks like after reverting the commit: >> -- >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> # i2c probe >> Valid chip addresses: 18 30 50 51 >> >> >> -Michael > > Sorry- relevant point here: I have a device with a 2-byte subaddress, > which I suspect is the culprit here. As Nick mentioned in his commit > message, such devices are unsupported by the current OMAP i2c driver. > I'm in the process of adding support for 2-byte subaddresses to the > driver. In light of the above, I now realize that such changes will > probably have to involve i2c_probe() as well. > > -Michael Hi Michael, What do you mean by sub-address? The address within the device or an extended chip address? The change I made aborts the write after sending the 7 bit chip address and 1 write bit, so a device's internal address shouldn't be relevant. Extended chip addressing devices would not be supported as it stands. I can imagine NACK may not be occur for a device waiting for more chip address bits, though I would have thought it wouldn't drive the bus low until the full address is received. Can you tell us what device this is? Even better a link to the data sheet. Does your bus have only one master (the OMAP)? There could be an issue if bus arbitration failures occur. I guess your bus pull-ups are strong enough to assert the NAK...? If not, you probably you would have seen other issues before now. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-samsung/master
Dear Albert ARIBAUD, On 26 May 2011 17:13, Albert ARIBAUD wrote: > Hi Minkyu, > > Le 26/05/2011 08:24, Minkyu Kang a écrit : > >>> Rather than a merge, could you please do a rebase (onto f14a522a >>> (Beagleboard: fixed typo in typecast) as indicated in >>> >>> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#BEFORE_Requesting_a_Pull)? >> >> I already did a rebase. >> Any problem? > > The problem is, it is not a rebase. What you did apparently is merge the > u-boot-arm master branch to yours, yielding the commit that your pull > request is based upon. What the Wiki suggests is that you rebase your branch > onto the target one before doing the pull request, so that it is based upon > the tip of the target branch. > OK. I see. I'll send pull request again. Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-samsung/master
Dear Albert ARIBAUD,
The following changes since commit f14a522a6cb6b843d31fd099b5af6a57142f2364:
BeagleBoard: fixed typo in typecast (2011-05-23 09:04:39 +0200)
are available in the git repository at:
ssh://gu-sams...@git.denx.de/u-boot-samsung master
Chander Kashyap (4):
S5P: GPIO Macro Values Corrected.
S5P:SROM config code moved to s5p-common directory
ARMV7: Add support for Samsung SMDKV310 Board
ARMV7: MMC SPL Boot support for SMDKV310 board
David Müller (ELSOFT AG) (4):
SMDK2410: activate ARM relocation feature
SMDK2410: remove unneeded config.mk
SMDK2410: use the CFI driver (and remove the old one)
SMDK2410: various cleanup/code style fixes
Dirk Behme (1):
MMC S5P: Fix typo
Jaehoon Chung (1):
S5P: add set_mmc_clk for external clock control
Minkyu Kang (2):
S5PC2XX: Support the cpu revision
S5PC2XX: clock: support pwm clock for evt1 (cpu revision 1)
seedshope (1):
Add _end for the end of u-boot image for SMDK6400
MAINTAINERS|4 +
Makefile | 11 +
arch/arm/cpu/armv7/s5p-common/Makefile |3 +-
arch/arm/cpu/armv7/s5p-common/cpu_info.c |2 +
arch/arm/cpu/armv7/{s5pc1xx => s5p-common}/sromc.c | 22 +-
arch/arm/cpu/armv7/s5pc1xx/Makefile|1 -
arch/arm/cpu/armv7/s5pc1xx/clock.c |5 +
arch/arm/cpu/armv7/s5pc2xx/clock.c | 76 +++-
arch/arm/include/asm/arch-s5pc1xx/clk.h|1 +
arch/arm/include/asm/arch-s5pc1xx/gpio.h |4 +-
arch/arm/include/asm/arch-s5pc1xx/mmc.h|1 +
.../include/asm/arch-s5pc1xx/{smc.h => sromc.h}|8 +-
arch/arm/include/asm/arch-s5pc2xx/clk.h|1 +
arch/arm/include/asm/arch-s5pc2xx/cpu.h| 12 +-
arch/arm/include/asm/arch-s5pc2xx/gpio.h |7 +-
arch/arm/include/asm/arch-s5pc2xx/mmc.h|1 +
arch/arm/include/asm/arch-s5pc2xx/sromc.h | 51 +++
board/samsung/smdk2410/Makefile|2 +-
board/samsung/smdk2410/config.mk | 25 -
board/samsung/smdk2410/flash.c | 433 --
board/samsung/smdk2410/smdk2410.c | 73 ++--
board/samsung/smdkc100/smdkc100.c |4 +-
board/samsung/smdkv310/Makefile| 46 ++
board/samsung/smdkv310/lowlevel_init.S | 470
board/samsung/smdkv310/mem_setup.S | 365 +++
board/samsung/smdkv310/smdkv310.c | 136 ++
boards.cfg |1 +
drivers/mmc/s5p_mmc.c |6 +-
include/configs/smdk2410.h | 181 +---
include/configs/smdkv310.h | 169 +++
mmc_spl/board/samsung/smdkv310/Makefile| 105 +
mmc_spl/board/samsung/smdkv310/mmc_boot.c | 85
.../board/samsung/smdkv310/tools/mkv310_image.c| 116 +
mmc_spl/board/samsung/smdkv310/u-boot.lds | 86
nand_spl/board/samsung/smdk6400/u-boot.lds |2 +
35 files changed, 1921 insertions(+), 594 deletions(-)
rename arch/arm/cpu/armv7/{s5pc1xx => s5p-common}/sromc.c (68%)
rename arch/arm/include/asm/arch-s5pc1xx/{smc.h => sromc.h} (92%)
create mode 100644 arch/arm/include/asm/arch-s5pc2xx/sromc.h
delete mode 100644 board/samsung/smdk2410/config.mk
delete mode 100644 board/samsung/smdk2410/flash.c
create mode 100644 board/samsung/smdkv310/Makefile
create mode 100644 board/samsung/smdkv310/lowlevel_init.S
create mode 100644 board/samsung/smdkv310/mem_setup.S
create mode 100644 board/samsung/smdkv310/smdkv310.c
create mode 100644 include/configs/smdkv310.h
create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile
create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c
create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c
create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-samsung/master
Hi Minkyu, Le 26/05/2011 12:43, Minkyu Kang a écrit : > Dear Albert ARIBAUD, > > The following changes since commit f14a522a6cb6b843d31fd099b5af6a57142f2364: > >BeagleBoard: fixed typo in typecast (2011-05-23 09:04:39 +0200) > > are available in the git repository at: >ssh://gu-sams...@git.denx.de/u-boot-samsung master Applied, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] after relocation, the original text_base memory section can't be used
Hi, Le 26/05/2011 11:04, Yuping Luo a écrit : > Hi, > > With 2011.03 uboot, I am adding firmware flashing feature to our > arm cortex a9 soc platform via usb, in which the data firstly be > uploaded to memory wholly (more than 200MB, thanks our 512MB physical > memory), then burned. > By my understanding, after relocation the successive memory range > (0~~ relocaddr) can be (re)used. however, if the original text section > (in my case, 0x0150) is written, the data abort happens when > accessing 0x0160; if the memory section (0x0150~0x0160) > not written, everything is ok. please correct me if I am wrong. Well, what is sure is that not all of 150-160 was used before relocation either (it ends around 1546000), so 160 was not accessed before reloc. How can you be sure the issue happens after reloc? For all we know, it could be a bug in the code code that writes 150 to 160 itself. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SMDKV310: CPU fequency and mmc_pre_ratio modified
Modifies CPU Frequency to 1GHz and removes hard coding of mmc_pre_ratio for MMC Channel2 in FSYS2 register. Signed-off-by: Chander Kashyap --- board/samsung/smdkv310/lowlevel_init.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/samsung/smdkv310/lowlevel_init.S b/board/samsung/smdkv310/lowlevel_init.S index 359cff4..04f6579 100644 --- a/board/samsung/smdkv310/lowlevel_init.S +++ b/board/samsung/smdkv310/lowlevel_init.S @@ -170,7 +170,7 @@ system_clock_init: * COREM1_RATIO[8] 0x7 * COREM0_RATIO[4] 0x3 */ - ldr r1, =0x01133730 + ldr r1, =0x0133730 ldr r2, =0x14500@CLK_DIV_CPU0_OFFSET str r1, [r0, r2] @@ -245,7 +245,7 @@ system_clock_init: str r1, [r0, r2] /* MMC[2:3] */ - ldr r1, =0x000f020f /* 800(MPLL) / (15 + 1) */ + ldr r1, =0x000f000f /* 800(MPLL) / (15 + 1) */ ldr r2, =0x0C548@ CLK_DIV_FSYS2 str r1, [r0, r2] -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/22] armv7: embed u-boot size within u-boot for use from SPL
Hi Wolfgang, On Wednesday 18 May 2011 11:36 AM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4dd352ea.3090...@ti.com> you wrote: >> >>> What you are doing here is defining an image format. Such an image >>> format must be good enough not only for OMAP4 and for loading U-Boot >>> as second stage, but for all other architectures and use cases as >>> well. >> >> I am not defining and publishing a format for the external world. It's > > In the essence this is what you are doing: you are defining an > interface how the payload has to look like. Anything not meeting this > "specification" or "image format" or "ABI" or whatever you call it > will not be directly loadable by the SPL. This is not exactly true. I had implemented a fall-back option albeit with a maximum size assumed for U-Boot. > > But I want to make sure that we can load arbitrary payloads as second > stage, not only U-Boot images. Because we cannot guarantee that we > can embed such information into other payloads we may want to load, we > must prepend or append such information, but not embed it somewhere > within the image itself. > >> just an internal information much like any other info embedded in >> start.S such as _bss_end_ofs, _end_ofs etc. It's just that SPL, being >> an insider, can take advantage of it. > > This is not quite correct. SPL needs this information. We are defining > an API here, and we should make sure it fits the use cases we can see > now (and ideally is flexible enough so we can adjust/extend it for > future use). Agree that mkimage approach works better for different types of payloads. > >> I feel creating a new mkimage target just for this will be an overkill. > > We don't have to create a new format. We can, for example, use the > existing format with a prepended 64 byte header. The only thing that > needs changes is that we now have to consider the header when loading > the image, but the same problem will always exist when we accept that > we cannot embed the information within the payload. We don't need any > new code to implement this solution. We can easily create the images > using "mkimage -T firmware -O u-boot". The existing target u-boot.img works for me. Just a couple of questions: 1. I see that size is at offset 0xC in this header. Is this a standard? 2. I see that the header is 64 bytes. Is that again a standard for mkimage. 3. Is it ok to add u-boot.img to the target "ALL"? 4. If not, is it ok to add it to "ALL" when CONFIG_SPL is defined? Something like this: ifeq ($(CONFIG_SPL),y) .PHONEY : SPL -ALL += SPL +ALL += SPL u-boot.img endif Is it ok to add support for kernel payload as a subsequent incremental step. That's, right now I intend to parse the mkimage header, find the size and load address and load the image and pass control to it, but *without* passing any parameters. Is that ok? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] omap3_beagle: enable EHCI and USB storage.
Hi Alexander Holler, is EHCI on omap3 already working? On my beagleboard xM usb start hangs at this position in method ehci_hcd_init: + /* perform TLL soft reset, and wait until reset is complete */ + writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, + OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); regards, chris. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
On 05/26/2011 11:23 AM, Nick Thompson wrote: > On 26/05/11 08:03, Michael Jones wrote: >> On 05/25/2011 05:38 PM, Michael Jones wrote: >>> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c >>> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more >>> devices when probing an i2c bus". It detects more devices indeed, such >>> as some that don't even exist. Even better than that, it detects >>> different devices every time. It looks like just false positives, the >>> existent devices seem to always be found among the ghost devices. >>> >>> Here's the behavior I see: >>> -- >>> # i2c probe >>> Valid chip addresses: 05 18 30 49 50 51 5E 7A >>> # i2c probe >>> Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C >>> # i2c probe >>> Valid chip addresses: 18 2E 30 33 35 50 51 62 6F >>> # i2c probe >>> Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D >>> # i2c probe >>> Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 >>> # i2c probe >>> Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C >>> >>> >>> Here's what it looks like after reverting the commit: >>> -- >>> # i2c probe >>> Valid chip addresses: 18 30 50 51 >>> # i2c probe >>> Valid chip addresses: 18 30 50 51 >>> # i2c probe >>> Valid chip addresses: 18 30 50 51 >>> # i2c probe >>> Valid chip addresses: 18 30 50 51 >>> >>> >>> -Michael >> >> Sorry- relevant point here: I have a device with a 2-byte subaddress, >> which I suspect is the culprit here. As Nick mentioned in his commit >> message, such devices are unsupported by the current OMAP i2c driver. >> I'm in the process of adding support for 2-byte subaddresses to the >> driver. In light of the above, I now realize that such changes will >> probably have to involve i2c_probe() as well. >> >> -Michael > Hi Nick, > Hi Michael, > > What do you mean by sub-address? The address within the device or an > extended chip address? I mean the address within the device. > > The change I made aborts the write after sending the 7 bit chip > address and 1 write bit, so a device's internal address shouldn't be > relevant. Mmm, OK. I only jumped to that conclusion because your comment in the commit message mentions that the driver only supports devices with single-byte subaddresses. > > Extended chip addressing devices would not be supported as it stands. > I can imagine NACK may not be occur for a device waiting for more > chip address bits, though I would have thought it wouldn't drive the bus > low until the full address is received. Curious. It sounds like you would've expected it to work with my device. > > Can you tell us what device this is? Even better a link to the data > sheet. It's a 128 Kbit EEPROM. http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00259167.pdf > > Does your bus have only one master (the OMAP)? There could be an issue > if bus arbitration failures occur. OMAP is the only master. > > I guess your bus pull-ups are strong enough to assert the NAK...? > If not, you probably you would have seen other issues before now. Right- I assume this is not the problem because I haven't had other issues before now. > > Nick. I am going to focus on getting proper reads and writes working with my device before looking into this myself. If you have suggestions in the meantime, I'm all ears. Otherwise I'll be in touch when I get around to looking at probe again. -Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I2C: OMAP: spurious i2c probe addresses
On 26/05/11 12:38, Michael Jones wrote: > On 05/26/2011 11:23 AM, Nick Thompson wrote: >> On 26/05/11 08:03, Michael Jones wrote: >>> On 05/25/2011 05:38 PM, Michael Jones wrote: While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more devices when probing an i2c bus". It detects more devices indeed, such as some that don't even exist. Even better than that, it detects different devices every time. It looks like just false positives, the existent devices seem to always be found among the ghost devices. Here's the behavior I see: -- # i2c probe Valid chip addresses: 05 18 30 49 50 51 5E 7A # i2c probe Valid chip addresses: 02 06 0B 18 1D 24 25 30 35 50 51 57 5D 6F 7C # i2c probe Valid chip addresses: 18 2E 30 33 35 50 51 62 6F # i2c probe Valid chip addresses: 18 1B 1F 2D 30 46 50 51 5C 5D # i2c probe Valid chip addresses: 0A 18 21 26 2B 30 32 50 51 60 66 69 6D 79 # i2c probe Valid chip addresses: 08 09 18 1B 30 50 51 5E 6C Here's what it looks like after reverting the commit: -- # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 # i2c probe Valid chip addresses: 18 30 50 51 -Michael >>> >>> Sorry- relevant point here: I have a device with a 2-byte subaddress, >>> which I suspect is the culprit here. As Nick mentioned in his commit >>> message, such devices are unsupported by the current OMAP i2c driver. >>> I'm in the process of adding support for 2-byte subaddresses to the >>> driver. In light of the above, I now realize that such changes will >>> probably have to involve i2c_probe() as well. >>> >>> -Michael >> > > Hi Nick, > >> Hi Michael, >> >> What do you mean by sub-address? The address within the device or an >> extended chip address? > > I mean the address within the device. > >> >> The change I made aborts the write after sending the 7 bit chip >> address and 1 write bit, so a device's internal address shouldn't be >> relevant. > > Mmm, OK. I only jumped to that conclusion because your comment in the > commit message mentions that the driver only supports devices with > single-byte subaddresses. That appears to true. The Davinci driver supports two byte addresses. You might be able to use that as a template for your changes. > >> >> Extended chip addressing devices would not be supported as it stands. >> I can imagine NACK may not be occur for a device waiting for more >> chip address bits, though I would have thought it wouldn't drive the bus >> low until the full address is received. > > Curious. It sounds like you would've expected it to work with my device. Yes. I've made a similar change to Davinci's probe and it works with a 25x256 (Spansion) device (and more stubborn Analog Devices DACs and ADCs, as well as temperature and current sensors). The probe always returns the same results, much like our OMAP boards. > >> >> Can you tell us what device this is? Even better a link to the data >> sheet. > > It's a 128 Kbit EEPROM. > http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00259167.pdf > > >> >> Does your bus have only one master (the OMAP)? There could be an issue >> if bus arbitration failures occur. > > OMAP is the only master. Okay. > >> >> I guess your bus pull-ups are strong enough to assert the NAK...? >> If not, you probably you would have seen other issues before now. > > Right- I assume this is not the problem because I haven't had other > issues before now. Hmm, I'm a bit stumped then. I'm still playing with I2C on Davinci, so more ideas may come out of that. The bus pull-ups on our boards are 2k-ohm to 3v3 rail, if it helps. > >> >> Nick. > > I am going to focus on getting proper reads and writes working > with my device before looking into this myself. If you have > suggestions in the meantime, I'm all ears. Otherwise I'll be > in touch when I get around to looking at probe again. Okay, let me know how you get on. > > -Michael Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/fsl_pci: Fix device tree fixups for newer platforms
On May 20, 2011, at 1:06 AM, Kumar Gala wrote: > We assumed that only a small set of compatiable strings would be needed > to find the PCIe device tree nodes to be fixed up. However on newer > platforms the simple rules no longer work. We need to allow specifying > the PCIe compatiable string for each individual SoC. > > We introduce CONFIG_SYS_FSL_PCIE_COMPAT for this purpose and set it if > the default isn't sufficient. > > Signed-off-by: Kumar Gala > --- > README|5 + > arch/powerpc/include/asm/config_mpc85xx.h |9 + > arch/powerpc/include/asm/fsl_pci.h|6 +- > 3 files changed, 19 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hello Everyone,
OK - Starting a new thread to discuss implementation details. This is a
heads-up for arch/platform maintainers - Once this is a bit more stable, I
will put it on the wiki
Assumed Capabilities of the Platform
- Has a 'tick counter' that does not rely on software to increment
- tick interval may by a fixed constant which cannot be controlled
via software, or it could be programmable (PIT)
API Functions (/lib/timer.c)
- u32 get_timer(u32 start)
- Returns the number of elapsed milliseconds since 'start'
API Functions (/arch/...)
- void udelay(u32 delay)
- Used for 'short' delays (generally up to several seconds)
- Can use the tick counter if it is fast enough
- MUST NOT RESET THE TICK COUNTER
'Helper' Functions (/lib/timer.c)
- void sync_timebase(void)
- Updates the millisecond timer
- Utilises HAL functions to access the platform's tick counter
- Must be called more often than the rollover period of the
platform's tick counter
- Does not need to be called with a regular frequency (immune
to interrupt skew)
- Is always called by get_timer()
- For platforms with short tick counter rollovers it should
be called by an ISR
- Bill Campbell wrote a good example which proved this can be common
and arbitrary (and optionally free of divides and capable of
maintaining accuracy even if the tick frequency is not an even
division of 1ms)
HAL Functions (/arch/... or /board/...)
- u64 get_ticks(void)
- Returns a tick count as an unsigned 64-bit integer
- Abstracts the implementation of the platform tick counter
(platform may by 32-bit 3MHz counter, might be a 16-bit
0-999 microsecond plus 16-bit 0-65535 millisecond etc)
- u64 ticks_per_millisecond()
- Returns the number of ticks (as returned by get_ticks()) per
millisecond
- void timer_isr()
- Optional (particularly if tick counter rollover period is
exceptionally log which is usually the case for native 64-bit tick
counters)
- Simply calls sync_timebase()
- For platforms without any tick counter, this can implement one
(but accuracy will be harmed due to usage of disable_interrupts() and
enable_interrupts() in U-Boot
So to get the new API up and running, only two functions are mandatory:
get_ticks() which reads the hardware tick counter and deals with any 'funny
stuff' including rollovers, short timers (12-bit for example), composite
counters (16-bit 0-999 microsecond + 16-bit millisecond) and maintains a
'clean' 64-bit tick counter which rolls over from all 1's to all 0's. The
64-bit tick counter does not need to be reset to zero ever (even on startup
- sync_timebase tacks care of all the details)
ticks_per_millisecond() simply return the number of ticks in a millisecond
- This may as simple as:
inline u64 ticks_per_millisecond(void)
{
return CONFIG_SYS_TICK_PER_MS;
}
But it may be trickier if you have a programmable tick frequency
The optional timer ISR is required if the tick counter has a short roll
over duration (short is up to you - 1 second is short, 1 hour might be, 1
century is not)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP
Hi Wolfgang, On Tuesday 17 May 2011 06:23 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4dd26b36.4050...@ti.com> you wrote: >> >> And how do you distinguish between the two cases at the top level >> Makefile? Using a CONFIG flag or on a per platform basis? > > The decision should not be make in the top level makefile, but in > spl/Makefile. And this can simply check if a board directory exists > in the first place. 1. How about the case where there is some board dependent code but also code shared by the boards(SoC based code). Will we have different 'Makefile's then - one for board and one for SoC. Will we then build different libraries at each leavel and link them together etc? 2. I think one key thing that you are perhaps missing is that in SPL the board level Makefile is not just meant for board level files. Instead it is used to pull together files from all the layers and make a custom image. IMHO, we will get into un-necessary complexities if we lose this property of SPL. We may rather spend efforts on making the regular U-Boot more configurable. > >> Why not just invoke the board level Makefile from the top-level >> Makefile and let it decide about the code-reuse by doing something like >> I did? > > Because then we need board specific directories and board specific > Makefiles even for those boards where no board specific code exists, > and all these Makefiles will be semi-identical copies of each other. > Considering point 2 above I think this is logical. The board level Makefile needs to have all the files. For the SoC level selection of files and the SoC level rules, include the respective *.mk files. Because in this case there are no board specific files there is nothing more in the Makefile. Please note that this may not be the case in general. Most boards, I suspect, may have some board specific files too. I wouldn't really consider the include statements as duplication of code. Instead, that was a way of avoiding duplication of code "given the constraints of the SPL model". best regards, Aneesh >>> Then we should adapt the directory and Makefile structure and allow >>> for such common code without need for separate spl/board/ >>> directories. >> >> Do you have any specific proposals? I have a feeling that this may get >> un-necessarily complicated. > > Having to maintain multiple copies of identical Makefiles is more > complicated and error prone in the long run. Let's rather spoend a few > thoughts initially and solve this problem before it spreads. > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] keymile arm boards update, part 2
Hello everybody, Prafulla Wadaskar wrote: > >> -Original Message- >> From: Wolfgang Denk [mailto:w...@denx.de] >> Sent: Friday, May 20, 2011 6:36 PM >> To: Valentin Longchamp >> Cc: Prafulla Wadaskar; albert.u.b...@aribaud.net; u-boot@lists.denx.de; >> holger.bru...@keymile.com; Ashish Karkare; Prabhanjan Sarnaik; Heiko >> Schocher >> Subject: Re: [PATCH v3 0/8] keymile arm boards update, part 2 >> >> Dear Valentin Longchamp, >> >> In message <4dd65683.60...@keymile.com> you wrote: >>> Wolfgang, what is your opinion on how this should be merged ? The >>> patches have really been posted quite a long time ago (they were >>> split in 3 series in the meantime) and you have applied the other two >>> series already. It would be good for us that the 3 series are able to >>> make it for v2011.06. >> My understanding is that these patches are on Prafulla's desk. >> >> Prafulla, can you please comment? > > Hi Wolfgang > > I was offline, and will have limited network access this week. I'll check and > pull them by coming Tuesday. > > Regards.. > Prafulla . . Albert, what is your current position regarding this series that was acked by Prafulla now that he has sent this message yesterday ? Do you want to apply them in you tree and (and maybe ask for a pull request for the 2011.06 release) or do you think waiting for Prafulla's return on June 1st (here an hint from Wolfgang to know if it's ok to wait until then would be welcome). Thank you and best regards -- Valentin Longchamp Embedded Software Engineer Hardware and Chip Integration __ KEYMILE AG Schwarzenburgstr. 73 CH-3097 Liebefeld Phone +41 31 377 1318 Fax +41 31 377 1212 valentin.longch...@keymile.com www.keymile.com __ KEYMILE: A Specialist as a Partner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NAND] Fixes 16bit NAND support with the NDFC
I know there has been a lot of activity related to other things in the U-Boot source, but has anyone had a chance to review this patch? Regards, Alex -- Alex Waterman Computer Engineer Phone: 215-896-4920 Email: awater...@dawning.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Hi Wolfgang, On Tuesday 17 May 2011 01:46 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4dd21cd8.2080...@ti.com> you wrote: >> >>> There are common, board independent parts both in spl/nand and >>> spl/onenand. >> >> How about having them at the root level in 'spl/' ? > > Why? It seems more logical to me to group nand and onenand related > files in their own subdirectories. I do not have any issue in having media specific files in their respective directories. However, I would like to see the 'Makefile's coming from the same directory tree irrespective of the media. So, how about something like this: spl/ mmc/ nand/ one-nand/ board///Makefile The idea is to have the board level Makefile in 'spl/board/ //' no matter what the SPL type is. This will help in better consolidation of SPLs. I see 3 SPL use-cases in general: 1. A single SPL that supports multiple media(suitable for SoCs with large internal RAM) 2. A single SPL supporting a single media(the board supports only one media) 3. Multiple SPLs for the same board each supporting a different memory device(maybe preferred over 1 to keep the foot-print of each small). Supporting (1) and (2) is straight forward with the above directory structure. To support (3) the board level Makefile should conditionally include the respective image file in the target 'all' based on CONFIG options. For instance 'all' may include 'onenand-ipl-2k.bin' if CONFIG_ONENAND_U_BOOT is defined and so on. Please let me know if any of you have better ideas. I would like to finalize on this before re-working on my patch-set. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] video: Add SHARP LQ084S3LG01 LCD support on P1022DS
The SHARP LQ084S3LG01 is a TFT LCD used on the P1022DS (revision "C") board.
This device only supports 800x600 resolution, so if that resolution is selected,
assume that this is the device. The device is attached to the LVDS port
on the P1022DS board.
The existing 800x600 entry (for the PDM360NG board) is actually 800x480,
so we fix that. To support two different 800x resolutions, the Y-resolution
is now passed to fsl_diu_init() and both values are used to pick the proper
fb_videomode structure.
The data for the 800x600 video mode is originally from Jiang Yutang.
Signed-off-by: Timur Tabi
Signed-off-by: Jiang Yutang
---
arch/powerpc/cpu/mpc512x/diu.c|2 +-
board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c |2 +-
board/freescale/p1022ds/diu.c |2 +-
drivers/video/fsl_diu_fb.c| 51 +---
include/fsl_diu_fb.h |2 +-
5 files changed, 40 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/cpu/mpc512x/diu.c b/arch/powerpc/cpu/mpc512x/diu.c
index 9dc1e48..b7db249 100644
--- a/arch/powerpc/cpu/mpc512x/diu.c
+++ b/arch/powerpc/cpu/mpc512x/diu.c
@@ -56,5 +56,5 @@ int platform_diu_init(unsigned int xres, unsigned int yres,
const char *port)
unsigned int pixel_format = 0x3316;
debug("mpc5121_diu_init\n");
- return fsl_diu_init(xres, pixel_format, 0);
+ return fsl_diu_init(xres, yres, pixel_format, 0);
}
diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
index 3011bb8..358a432 100644
--- a/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
+++ b/board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c
@@ -83,5 +83,5 @@ int platform_diu_init(unsigned int xres, unsigned int yres,
const char *port)
printf("DIU: Switching to %s monitor @ %ux%u\n", name, xres, yres);
out_8(&pixis->brdcfg0, temp);
- return fsl_diu_init(xres, pixel_format, gamma_fix);
+ return fsl_diu_init(xres, yres, pixel_format, gamma_fix);
}
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index 7d1f6aa..cef81ce 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -139,7 +139,7 @@ int platform_diu_init(unsigned int xres, unsigned int yres,
const char *port)
clrsetbits_be32(&gur->pmuxcr, PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_DIU);
pmuxcr = in_be32(&gur->pmuxcr);
- return fsl_diu_init(xres, pixel_format, 0);
+ return fsl_diu_init(xres, yres, pixel_format, 0);
}
/*
diff --git a/drivers/video/fsl_diu_fb.c b/drivers/video/fsl_diu_fb.c
index 0709849..e1d6c26 100644
--- a/drivers/video/fsl_diu_fb.c
+++ b/drivers/video/fsl_diu_fb.c
@@ -78,13 +78,9 @@ struct fb_videomode {
unsigned int flag;
};
-#define FB_SYNC_VERT_HIGH_ACT 2 /* vertical sync high active*/
-#define FB_SYNC_COMP_HIGH_ACT 8 /* composite sync high active */
-#define FB_VMODE_NONINTERLACED 0 /* non interlaced */
-
/* This setting is used for the ifm pdm360ng with PRIMEVIEW PM070WL3 */
-static struct fb_videomode fsl_diu_mode_800 = {
- .name = "800x600-60",
+static struct fb_videomode fsl_diu_mode_800_480 = {
+ .name = "800x480-60",
.refresh= 60,
.xres = 800,
.yres = 480,
@@ -99,13 +95,30 @@ static struct fb_videomode fsl_diu_mode_800 = {
.vmode = FB_VMODE_NONINTERLACED
};
+/* For the SHARP LQ084S3LG01, used on the P1022DS board */
+static struct fb_videomode fsl_diu_mode_800_600 = {
+ .name = "800x600-60",
+ .refresh= 60,
+ .xres = 800,
+ .yres = 600,
+ .pixclock = 25000,
+ .left_margin= 88,
+ .right_margin = 40,
+ .upper_margin = 23,
+ .lower_margin = 1,
+ .hsync_len = 128,
+ .vsync_len = 4,
+ .sync = FB_SYNC_COMP_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED
+};
+
/*
* These parameters give default parameters
* for video output 1024x768,
* FIXME - change timing to proper amounts
* hsync 31.5kHz, vsync 60Hz
*/
-static struct fb_videomode fsl_diu_mode_1024 = {
+static struct fb_videomode fsl_diu_mode_1024_768 = {
.name = "1024x768-60",
.refresh= 60,
.xres = 1024,
@@ -121,7 +134,7 @@ static struct fb_videomode fsl_diu_mode_1024 = {
.vmode = FB_VMODE_NONINTERLACED
};
-static struct fb_videomode fsl_diu_mode_1280 = {
+static struct fb_videomode fsl_diu_mode_1280_1024 = {
.name = "1280x1024-60",
.refresh= 60,
.xres = 1280,
@@ -263,7 +276,7 @@ static struct diu_ad *allocate_fb(unsigned int xres,
unsigned int yres,
return ad;
}
-int fsl_diu_init(int xres, u32 pixel_format, int gamma_fix)
+int fsl_diu_init(u16 xres, u16 yres, u
[U-Boot] [GIT PULL] Please pull u-boot-mpc85xx.git
The following changes since commit 7a82c208143bbc774ffcb4e53239410f867a0794: Prepare v2011.06-rc1 (2011-05-19 22:23:50 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kumar Gala (1): powerpc/fsl_pci: Fix device tree fixups for newer platforms README|5 + arch/powerpc/include/asm/config_mpc85xx.h |9 + arch/powerpc/include/asm/fsl_pci.h|6 +- 3 files changed, 19 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] omap3_beagle: enable EHCI and USB storage.
Am 26.05.2011 13:30, schrieb Christian Spielberger: > Hi Alexander Holler, > > is EHCI on omap3 already working? > > On my beagleboard xM > > usb start > > hangs at this position in method ehci_hcd_init: > > + /* perform TLL soft reset, and wait until reset is complete */ > + writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET, > + OMAP3_USBTLL_BASE + OMAP_USBTLL_SYSCONFIG); It works on a normal BeagleBoard (720 MHz). On the XM it seems you have either move the initialization of the usb-clocks a bit upwards (e.g. before the reset of the phy) or you have to add a check if the clock runs after it was initialized (before that writel). The XM seems to be too fast and the peripheral-clock isn't ready when that writel wants to write to the peripheral-register, therefor it hangs there on a XM. But even than USB doesn't seem to work on a BeagleBoard XM (at least some people told me so). I don't have a XM, so I can't help more there. It might be a problem with (a needed reset of) the HUB which is included on the XM, I don't know. And a side note: don't try a kernel compiled with gcc 4.6 on the BeagleBoard. EHCI on the OMAP3 doesn't come up here when the kernel is compiled with gcc 4.6. That seems to be specific to OMAP, I don't have those problems on other ARM hw (I use successfull e.g. EHCI on some armv5 devices with kernels which are compiled with gcc 4.6).When I compile the same kernel using gcc 4.5.2 I have no problems with EHCI on the BeagleBoard. Haven't investigated that further. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Graeme,
Thanks very much for doing this. I have been following the discussion
and am very happy that you have continued with it.
On Thu, May 26, 2011 at 6:27 AM, Graeme Russ wrote:
> Hello Everyone,
>
> OK - Starting a new thread to discuss implementation details. This is a
> heads-up for arch/platform maintainers - Once this is a bit more stable, I
> will put it on the wiki
>
> Assumed Capabilities of the Platform
> - Has a 'tick counter' that does not rely on software to increment
> - tick interval may by a fixed constant which cannot be controlled
> via software, or it could be programmable (PIT)
>
> API Functions (/lib/timer.c)
> - u32 get_timer(u32 start)
> - Returns the number of elapsed milliseconds since 'start'
Can we have a microsecond one also please? Some sort of microsecond
support is needed for udelay anyway. It can be implemented as
get_timer() * 1000 as a fallback. I saw this in your original
proposal. Given the 100 emails you have endured I understand if death
is losing its sting, but it is still a useful feature.
>
> API Functions (/arch/...)
> - void udelay(u32 delay)
> - Used for 'short' delays (generally up to several seconds)
> - Can use the tick counter if it is fast enough
> - MUST NOT RESET THE TICK COUNTER
>
> 'Helper' Functions (/lib/timer.c)
> - void sync_timebase(void)
> - Updates the millisecond timer
> - Utilises HAL functions to access the platform's tick counter
> - Must be called more often than the rollover period of the
> platform's tick counter
> - Does not need to be called with a regular frequency (immune
> to interrupt skew)
> - Is always called by get_timer()
> - For platforms with short tick counter rollovers it should
> be called by an ISR
> - Bill Campbell wrote a good example which proved this can be common
> and arbitrary (and optionally free of divides and capable of
> maintaining accuracy even if the tick frequency is not an even
> division of 1ms)
>
> HAL Functions (/arch/... or /board/...)
> - u64 get_ticks(void)
> - Returns a tick count as an unsigned 64-bit integer
> - Abstracts the implementation of the platform tick counter
> (platform may by 32-bit 3MHz counter, might be a 16-bit
> 0-999 microsecond plus 16-bit 0-65535 millisecond etc)
> - u64 ticks_per_millisecond()
> - Returns the number of ticks (as returned by get_ticks()) per
> millisecond
> - void timer_isr()
> - Optional (particularly if tick counter rollover period is
> exceptionally log which is usually the case for native 64-bit tick
> counters)
> - Simply calls sync_timebase()
> - For platforms without any tick counter, this can implement one
> (but accuracy will be harmed due to usage of disable_interrupts() and
> enable_interrupts() in U-Boot
I suppose this isn't the U-Boot way, but perhaps these could have
names which obviously indicate they are time and HAL-related, and need
to be implemented by a board. Perhaps a timer_ prefix?
>
> So to get the new API up and running, only two functions are mandatory:
>
> get_ticks() which reads the hardware tick counter and deals with any 'funny
> stuff' including rollovers, short timers (12-bit for example), composite
> counters (16-bit 0-999 microsecond + 16-bit millisecond) and maintains a
> 'clean' 64-bit tick counter which rolls over from all 1's to all 0's. The
> 64-bit tick counter does not need to be reset to zero ever (even on startup
> - sync_timebase tacks care of all the details)
>
> ticks_per_millisecond() simply return the number of ticks in a millisecond
> - This may as simple as:
>
> inline u64 ticks_per_millisecond(void)
> {
> return CONFIG_SYS_TICK_PER_MS;
> }
>
> But it may be trickier if you have a programmable tick frequency
This sounds find as I assume it allows the compiler to optimize to
avoid division, etc. For the microsecond case
ticks_to_microseconds(u64) might be better since the factor may not be
an integer.
>
> The optional timer ISR is required if the tick counter has a short roll
> over duration (short is up to you - 1 second is short, 1 hour might be, 1
> century is not)
Regards,
Simon
>
> Regards,
>
> Graeme
> ___
> 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] [NAND] Fixes 16bit NAND support with the NDFC
On Thu, 26 May 2011 09:40:46 -0400 Alex Waterman wrote: > > I know there has been a lot of activity related to other things in the U-Boot > source, but has anyone had a chance to review this patch? Looks mostly OK to me -- I was going to consider it for next, rather than master, as despite "fix" in the name it's really adding new hardware support. You may want to use an #ifdef for bus width in nand_boot.c rather than spending bytes to check it dynamically. Likewise in the non-SPL driver code, you already have CONFIG_SYS_NDFC_16BIT, so why check dynamically in ndfc_read_byte()? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Is there a working 2011 version of u-boot on i.MX31?
Hi,
I tried to upgrade my 2010/09 version of u-boot for our i.MX31
board, fixed the stuff needed for the new relocation scheme and ...
nothing, ... no prompt, so I compiled for mx31pdk (without any change of
source code) as it is very similar (RAM setup, etc.) and this also shows
no action on the uart (DEBUG is on).
After some hours of JTAG debugging I finally found that not even
board_early_init_f is called (neither for mx31pdk nor for our board).
Tracking down the assembler stuff in start.S and board.c shows that:
1) relocation is done at the end of 'board_init_f'
2) all early init functions are called at the very start of 'board_init_f'
3) these init functions are stored in an array of function pointers
'init_sequence', which is initialized data and which is not initialized yet.
4) the C-code in general is linked using -pie, but the compiler flag
-PIE (or -PIC) is missing, so code is not really position independent.
It is linked for the RAM addresses (0x87f0), but relocation is not
yet done.
5) uboot dies when the first function (board_early_init_f) should be called.
Adding -PIE in arch/arm/cpu/arm1136/config.mk and putting initialized
arrays (with constant values) into the text segment (__attribute__
((section (".text")) improves the situation, but butts out a little
further down the road. I stopped at this point.
There also seems to be a problem with the setup of gd in 'board_init_f'
which is placed at exactly the same position where start.S sets the
initial stack pointer (in internal RAM). I think this was not intended.
On the other hand I found several patches in the last months about
changes in the mx31pdk code which suggest a running uboot port for mx31pdk.
Can someone clarify what I'm missing?
Helmut
--
Scanned by MailScanner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On 5/26/2011 6:27 AM, Graeme Russ wrote: > Hello Everyone, > > OK - Starting a new thread to discuss implementation details. This is a > heads-up for arch/platform maintainers - Once this is a bit more stable, I > will put it on the wiki > > Assumed Capabilities of the Platform > - Has a 'tick counter' that does not rely on software to increment Hi All, The nios2 with the most basic timer does not meet this requirement. It will not count at all without the 10 ms interrupt. I don't think this requirement matters anyway. We need a 'tick counter' that 'ticks'. If it takes software to make it tick, we don't much care. There may be problems with early use of udelay in that case, but that is a different issue. > - tick interval may by a fixed constant which cannot be controlled > via software, or it could be programmable (PIT) > > API Functions (/lib/timer.c) > - u32 get_timer(u32 start) > - Returns the number of elapsed milliseconds since 'start' > > API Functions (/arch/...) > - void udelay(u32 delay) > - Used for 'short' delays (generally up to several seconds) > - Can use the tick counter if it is fast enough > - MUST NOT RESET THE TICK COUNTER There is a requirement that udelay be available before relocation and before the BSS is available. One can use the tick counter to provide udelay as long as sync_timebase is not called OR sync timebase does not use BSS. It appears many implementations ignore this requirement at present. We should try to fix this, but is should not be a requirement. > 'Helper' Functions (/lib/timer.c) I think this function should be weak, so that it is possible for people to override it with a "custom" function. The fully general sync_timebase has lots of code in it that can be simplified in special cases. We want and need a fully general function to be available, but other users who are real tight on space may want a cut down version. We should make that easily possible. > - void sync_timebase(void) > - Updates the millisecond timer > - Utilises HAL functions to access the platform's tick counter > - Must be called more often than the rollover period of the >platform's tick counter > - Does not need to be called with a regular frequency (immune >to interrupt skew) > - Is always called by get_timer() > - For platforms with short tick counter rollovers it should >be called by an ISR > - Bill Campbell wrote a good example which proved this can be common >and arbitrary (and optionally free of divides and capable of >maintaining accuracy even if the tick frequency is not an even >division of 1ms) > > HAL Functions (/arch/... or /board/...) > - u64 get_ticks(void) For what it's worth, I would like to propose using a (gasp!) typedef here. It seems to me there are a whole lot of cases where the max number of ticks is a u32 or less. In those cases, the wrap at 32 bits helps things a lot. If the tick counter is really 64 bits, the function of sync_timebase is simply to convert the tick value to millisec, and that is it. Otherwise, if it is 32 bits or less then some other actions will be required. I think this is one of those times where a typedef would help, We could define a type called timer_tick_t to describe this quantity. That would allow a pure 32 bit implementation where appropriate. Another suggestion is that perhaps we want a u32 get_ticks_lsb(void) as well as a regular get_ticks. The lsb version would be used for udelay and could possibly come from another timer if that was necessary/desirable. See the requirement for early udelay early availability. > - Returns a tick count as an unsigned 64-bit integer > - Abstracts the implementation of the platform tick counter >(platform may by 32-bit 3MHz counter, might be a 16-bit >0-999 microsecond plus 16-bit 0-65535 millisecond etc) > - u64 ticks_per_millisecond() > - Returns the number of ticks (as returned by get_ticks()) per >millisecond I think ticks_per_sec would be a better choice. First, such a function already exists in almost all u-boots. Second, if one wants the best accuracy for things like udelay, you need better accuracy than millisec. Since this function is used only infrequently, when things are initialized, a divide to get ticks_per_millsec (if that is what you really want) is no big deal. Lastly, I think this function can remain u32. Yes, there is a 4 GHz limit on the clock rate. If this ever becomes an issue, we can change the type to timer_tick_t. When the CPU clock rate gets quite high, it is an advantage to divide it down for performance measurement anyway. The AMD/Intel chips already do this. If the hardware doesn't do it, shift the timer value right two bits. I doubt you will miss the 0.4 nanoseconds resolution loss from your 10 GHz timestamp. > - void timer_isr() > - Optional (particularly if tick counter
[U-Boot] [PATCH] ARM: i.MX51: Config option to disable PLL1
i.MX51 PLL1 seems to have stability problems. It is advised to not use it, although it is unclear whether all boards and/or chip revisions have this problem. Using PLL2 for the core and DDR2 seems to fix the problem. No official errata yet. Signed-off-by: David Jander --- arch/arm/cpu/armv7/mx5/lowlevel_init.S | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S b/arch/arm/cpu/armv7/mx5/lowlevel_init.S index 96ebfe2..e1d6c35 100644 --- a/arch/arm/cpu/armv7/mx5/lowlevel_init.S +++ b/arch/arm/cpu/armv7/mx5/lowlevel_init.S @@ -153,7 +153,11 @@ mov r1, #0x4 str r1, [r0, #CLKCTL_CCSR] +#if defined(CONFIG_MX51_AVOID_PLL1) + setup_pll PLL1_BASE_ADDR, 216 +#else setup_pll PLL1_BASE_ADDR, 800 +#endif #if defined(CONFIG_MX51) setup_pll PLL3_BASE_ADDR, 665 @@ -165,7 +169,11 @@ str r1, [r0, #CLKCTL_CBCMR] ldr r1, =0x13239145 str r1, [r0, #CLKCTL_CBCDR] +#if defined(CONFIG_MX51_AVOID_PLL1) + setup_pll PLL2_BASE_ADDR, 800 +#else setup_pll PLL2_BASE_ADDR, 665 +#endif /* Switch peripheral to PLL2 */ ldr r0, =CCM_BASE_ADDR @@ -197,7 +205,11 @@ #endif str r1, [r0, #CLKCTL_CACRR] /* Switch ARM back to PLL 1 */ +#if defined(CONFIG_MX51_AVOID_PLL1) + mov r1, #0x0104 /* Set ARM/DDR to PLL2 */ +#else mov r1, #0 +#endif str r1, [r0, #CLKCTL_CCSR] #if defined(CONFIG_MX51) @@ -228,7 +240,11 @@ /* Use PLL 2 for UART's, get 66.5MHz from it */ ldr r1, =0xA5A2A020 str r1, [r0, #CLKCTL_CSCMR1] +#if defined(CONFIG_MX51_AVOID_PLL1) + ldr r1, =0x0104041a /* Adjust dividers for 800MHz on PLL2 */ +#else ldr r1, =0x00C30321 +#endif str r1, [r0, #CLKCTL_CSCDR1] #elif defined(CONFIG_MX53) ldr r1, [r0, #CLKCTL_CSCDR1] -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/22] armv7: embed u-boot size within u-boot for use from SPL
Dear Aneesh V, In message <4dde34c5.1050...@ti.com> you wrote: > > 1. I see that size is at offset 0xC in this header. Is this a standard? > 2. I see that the header is 64 bytes. Is that again a standard for > mkimage. Both are not really "standards" in the sense that any standardization group like ANSI or IEEE has approved this, but these are standard within U-Boot context. The header (struct image_header) is defined in "include/image.h" > 3. Is it ok to add u-boot.img to the target "ALL"? No, because in the general case this is not needed, so it's just a waste of build time and disk space. > 4. If not, is it ok to add it to "ALL" when CONFIG_SPL is defined? > Something like this: > > ifeq ($(CONFIG_SPL),y) > .PHONEY : SPL > -ALL += SPL > +ALL += SPL u-boot.img > endif IN principle this should be OK, but please pay attention not to break out-of-tree builds (You have to prefext target names with "$(obj)"). > Is it ok to add support for kernel payload as a subsequent incremental > step. That's, right now I intend to parse the mkimage header, find the > size and load address and load the image and pass control to it, but > *without* passing any parameters. Is that ok? That's perfectly fine. 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 Due to lack of disk space, this fortune database has been discontinued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Simon Glass, In message you wrote: > > Can we have a microsecond one also please? Some sort of microsecond I guess you cannot, at least not in general. In worst case that would mean we have to process 1e6 interrupts per second, which leaves little time for anything useful. 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 There you go man, Keep as cool as you can. It riles them to believe that you perceive the web they weave. Keep on being free! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is there a working 2011 version of u-boot on i.MX31?
Dear Helmut Raiger, In message <4dde7bae.7020...@hale.at> you wrote: > > On the other hand I found several patches in the last months about > changes in the mx31pdk code which suggest a running uboot port for mx31pdk. I canot comment on the mx31pdk, but top-of-tree is running fine on some i.MX31 boards, for example qong. 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 Wisdom is one of the few things that looks bigger the further away it is. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear Graeme Russ,
In message <4dde5548.3020...@gmail.com> you wrote:
>
> Assumed Capabilities of the Platform
> - Has a 'tick counter' that does not rely on software to increment
I think we should delete the "does not rely on software to increment"
part. It is not really essential.
> - tick interval may by a fixed constant which cannot be controlled
>via software, or it could be programmable (PIT)
>
> API Functions (/lib/timer.c)
> - u32 get_timer(u32 start)
> - Returns the number of elapsed milliseconds since 'start'
If you really want to make the code flexible, then say
"returns the number of "1/CONFIG_SYS_HZ" time units since
'start'"
The 1 ms resolution is actually tied to the CONFIG_SYS_HZ
definition (which is the reason why I always fought that
CONFIG_SYS_HZ must be defined as 1000).
Of course we could also drop this definition completely...
> API Functions (/arch/...)
> - void udelay(u32 delay)
> - Used for 'short' delays (generally up to several seconds)
no. only good for delays well below one second.
> - Can use the tick counter if it is fast enough
> - MUST NOT RESET THE TICK COUNTER
Should ne not state that the tick counter must never be reset during
the life-time -f U-Boot?
We should also note that neither get_timer() nor udelay() make any
guarantee for the precision of the returned timing information, except
that udelay(N) is always supposed to delay for _at_least_ N
microseconds.
> 'Helper' Functions (/lib/timer.c)
> - void sync_timebase(void)
Can be a macro (to avoid call overhead).
> - Updates the millisecond timer
We need to define that term.. Eventually you want to change the
definition of get_timer() into "returns the content of the millisecond
timer" or similar.
> - Utilises HAL functions to access the platform's tick counter
> - Must be called more often than the rollover period of the
> platform's tick counter
> - Does not need to be called with a regular frequency (immune
> to interrupt skew)
> - Is always called by get_timer()
> - For platforms with short tick counter rollovers it should
> be called by an ISR
> - Bill Campbell wrote a good example which proved this can be common
> and arbitrary (and optionally free of divides and capable of
> maintaining accuracy even if the tick frequency is not an even
> division of 1ms)
>
> HAL Functions (/arch/... or /board/...)
> - u64 get_ticks(void)
> - Returns a tick count as an unsigned 64-bit integer
> - Abstracts the implementation of the platform tick counter
> (platform may by 32-bit 3MHz counter, might be a 16-bit
> 0-999 microsecond plus 16-bit 0-65535 millisecond etc)
> - u64 ticks_per_millisecond()
> - Returns the number of ticks (as returned by get_ticks()) per
> millisecond
I recommend to stick with the existing ticks2usec() and usec2ticks();
you can then use usec2ticks(1000) to get the ticks per millisecond.
> - void timer_isr()
> - Optional (particularly if tick counter rollover period is
> exceptionally log which is usually the case for native 64-bit tick
> counters)
> - Simply calls sync_timebase()
> - For platforms without any tick counter, this can implement one
> (but accuracy will be harmed due to usage of disable_interrupts() and
> enable_interrupts() in U-Boot
>
> So to get the new API up and running, only two functions are mandatory:
>
> get_ticks() which reads the hardware tick counter and deals with any 'funny
> stuff' including rollovers, short timers (12-bit for example), composite
> counters (16-bit 0-999 microsecond + 16-bit millisecond) and maintains a
> 'clean' 64-bit tick counter which rolls over from all 1's to all 0's. The
> 64-bit tick counter does not need to be reset to zero ever (even on startup
> - sync_timebase tacks care of all the details)
>
> ticks_per_millisecond() simply return the number of ticks in a millisecond
> - This may as simple as:
>
> inline u64 ticks_per_millisecond(void)
> {
> return CONFIG_SYS_TICK_PER_MS;
> }
Better move this part up to the description of usec2ticks() / ticks2usec().
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
"There are three principal ways to lose money: wine, women, and en-
gineers. While the first two are more pleasant, the third is by far
the more certain." -- Baron Rothschild, ca. 1800
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Interrupt handler in U-Boot for MIPS based platform
Hi all, I was working on enabling the watchdog timer in the U-Boot for MIPS based platform. I set up the timer and watchdog. when the timer expires, I need to kick the watchdog until the user timeout period expires. I see that for ARM we have do_irq function which gets called when there is interrupt but I don't see any such mechanism for the MIPS. Has any one implemented it for MIPS based platform? If not, any hint to get it working. Thanks, Pandu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear "J. William Campbell", In message <4dde8639.3090...@comcast.net> you wrote: > I think it is the task of get_ticks to return the hardware tick counter > as an increasing counter, period. The counter may wrap at some final > count that is not all ones. That is ok. Sync_timebase deals with the NO! We want to be able to compute time differences using simple unsigned arithmentics, even after a rollover of the counter. For this it is mandatory that the counter always gets only incremented until it wraps around at te end of it's number range, and never gets reset before. > You will have to call the routine that initializes sync_timebase. This > routine should have a name, like void init_sync_timebase(void)? init_timebase(). 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 Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: i.MX51: Config option to disable PLL1
On Thu, 26 May 2011 19:00:14 +0200 David Jander wrote: > i.MX51 PLL1 seems to have stability problems. It is advised to not use it, > although it is unclear whether all boards and/or chip revisions have this > problem. Using PLL2 for the core and DDR2 seems to fix the problem. > No official errata yet. Forgot to mention this in the commit message: All boards that need this fix (all of them?) should change their board config header file to include this: #define CONFIG_MX51_AVOID_PLL1 ... #ifdef CONFIG_MX51_AVOID_PLL1 #define CONFIG_SYS_CLKTL_CBCDR 0x59EC7580 #else #define CONFIG_SYS_CLKTL_CBCDR 0x59E35100 #endif This is the case for mx51evk.h, and the exact value of CONFIG_SYS_CLKTL_CBCDR may vary depending on crystal frequency, type of RAM, NFC clocks, etc... I would like to have some feedback before resubmitting the patch with the amended commit message. I would also like to know whether I should include another patch fixing all affected board-config headers? I guess this should be decided by the respective maintainers, since this requires fixing the linux kernel clock driver also... Beste regards, -- David Jander Protonic Holland. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NAND] Fixes 16bit NAND support with the NDFC
Scott, > Looks mostly OK to me -- I was going to consider it for next, rather than > master, as despite "fix" in the name it's really adding new hardware support. Ahh, yeah, that makes sense. I will change "Fixes" to "Adds" for next submission. > You may want to use an #ifdef for bus width in nand_boot.c rather than > spending bytes to check it dynamically. OK. I suppose its unlikely that a NAND chip will swap from 8bit to 16bit (or vice versa) from one compile to another :). > Likewise in the non-SPL driver code, you already have > CONFIG_SYS_NDFC_16BIT, so why check dynamically in ndfc_read_byte()? My thought process was something along the lines of one compiled binary working on potentially multiple similar boards... Though in thinking about it, that seems like a needless requirement. I will change to #ifdefs for smaller code size. That's probably more useful overall. Regards, Alex -- Alex Waterman Computer Engineer Phone: 215-896-4920 Email: awater...@dawning.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On 5/26/2011 10:53 AM, Wolfgang Denk wrote: > Dear "J. William Campbell", > > In message<4dde8639.3090...@comcast.net> you wrote: > >> I think it is the task of get_ticks to return the hardware tick counter >> as an increasing counter, period. The counter may wrap at some final >> count that is not all ones. That is ok. Sync_timebase deals with the > NO! We want to be able to compute time differences using simple > unsigned arithmentics, even after a rollover of the counter. For this > it is mandatory that the counter always gets only incremented until it > wraps around at te end of it's number range, and never gets reset Hi All, I agree that that is what must happen, but it should happen inside sync_timebase. Sync_timebase does what is needed to convert the less-than-fully capable counters into a fully capable one. You could move that functionality down into get_ticks, but if you do, you end up much like the present scheme where the multiple different get_ticks routines expected to cope with expanding the hardware counter properly. To date, it has been shown conclusively that this process cannot be relied upon, or we wouldn't be having this discussion. If we put that functionality inside sync_timebase, it is in one place and debuggable once. All sync_timebase requires to do this is ticks per second and maximum tick value. I do request that counters that decrement be negated in the get_ticks routine, but beyond that, it should be a simple read of the tick register(s). Best Regards, Bill Campbell > before. > >> You will have to call the routine that initializes sync_timebase. This >> routine should have a name, like void init_sync_timebase(void)? > init_timebase(). > > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is there a working 2011 version of u-boot on i.MX31?
Helmut, On Thu, May 26, 2011 at 2:30 PM, Wolfgang Denk wrote: > Dear Helmut Raiger, > > In message <4dde7bae.7020...@hale.at> you wrote: >> >> On the other hand I found several patches in the last months about >> changes in the mx31pdk code which suggest a running uboot port for mx31pdk. > > I canot comment on the mx31pdk, but top-of-tree is running fine on > some i.MX31 boards, for example qong. I have been using MX31PDK with top-of-tree U-boot version and it works fine for me. I build it as "make mx31pdk_nand_config" and then I use ATK tool to program u-boot.bin into NAND. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear "J. William Campbell", In message <4ddea165.9010...@comcast.net> you wrote: > > >> I think it is the task of get_ticks to return the hardware tick counter > >> as an increasing counter, period. The counter may wrap at some final > >> count that is not all ones. That is ok. Sync_timebase deals with the > > NO! We want to be able to compute time differences using simple > > unsigned arithmentics, even after a rollover of the counter. For this > > it is mandatory that the counter always gets only incremented until it > > wraps around at te end of it's number range, and never gets reset > > I agree that that is what must happen, but it should happen inside > sync_timebase. Sync_timebase does what is needed to convert the > less-than-fully capable counters into a fully capable one. You could I think you also want this behaviour for get_ticks(). > To date, it has been shown conclusively that this process cannot be > relied upon, or we wouldn't be having this discussion. If we put that > functionality inside sync_timebase, it is in one place and debuggable > once. All sync_timebase requires to do this is ticks per second and > maximum tick value. I do request that counters that decrement be negated > in the get_ticks routine, but beyond that, it should be a simple read of > the tick register(s). I think using ticks per second is not a good idea. It may exceed ULONG_MAX, and having to use 64 bit for all calculations is probably overkill. The existing ticks2usec/usec2ticks work fine so far. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de As of 1992, they're called European Economic Community fries. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On 5/26/2011 12:16 PM, Wolfgang Denk wrote: > Dear "J. William Campbell", > > In message<4ddea165.9010...@comcast.net> you wrote: I think it is the task of get_ticks to return the hardware tick counter as an increasing counter, period. The counter may wrap at some final count that is not all ones. That is ok. Sync_timebase deals with the >>> NO! We want to be able to compute time differences using simple >>> unsigned arithmentics, even after a rollover of the counter. For this >>> it is mandatory that the counter always gets only incremented until it >>> wraps around at te end of it's number range, and never gets reset >>I agree that that is what must happen, but it should happen inside >> sync_timebase. Sync_timebase does what is needed to convert the >> less-than-fully capable counters into a fully capable one. You could > I think you also want this behaviour for get_ticks(). Hi Wolfgang, I understand why that might be nice. But to do that with common code would require get_ticks to call a generic routine (say sync_ticks) that would expand the counter to 64 bits. Note that this is not always totally trivial, as the timer may roll over at 10 ms or some other not-so-nice number. Then sync_timer would convert the 64 bit number to milliseconds. That approach will work. However, I think that is overkill, as we really want the result in milliseconds. If you look at the prototype sync_timer routine, you can see an example of how this is possible without resorting to 64 bit math. I think that avoiding the 64 bit math on processors that don't have a 64 bit tick counter (and are therefore probably less capable) is worthwhile. I also think that the purpose of the get_time routine abstracting the time into milliseconds is to avoid dealing with ticks anywhere except in the timer routines. Presumably, nobody but sync_timer would ever have reason to call get_ticks. If that is not your thinking, fine, we just disagree on that point, and having a sync_ticks to expand the tick counter certainly can be done. >> To date, it has been shown conclusively that this process cannot be >> relied upon, or we wouldn't be having this discussion. If we put that >> functionality inside sync_timebase, it is in one place and debuggable >> once. All sync_timebase requires to do this is ticks per second and >> maximum tick value. I do request that counters that decrement be negated >> in the get_ticks routine, but beyond that, it should be a simple read of >> the tick register(s). > I think using ticks per second is not a good idea. It may exceed > ULONG_MAX, and having to use 64 bit for all calculations is probably > overkill. The existing ticks2usec/usec2ticks work fine so far. I certainly agree using 64 bits for all calculations is vast overkill. In fact, I think using 64 bit calculations on systems that have only a 32 bit or less timer register is probably overkill. :-) However, to date,AFAIK, no processor has exceeded the u32 in ticks per second. As I pointed out in a previous e-mail, if they ever do this, we can just drop one or 2 bits off the 64 bit counter and in millisecond resolution, nobody will ever know. Also as previously pointed out, usec2ticks is not present yet in lots of implementations. Also, if the fundamental clock frequency is 32 kHz (or anything less than 1 MHz), usec2ticks is 0! This probably rules out using it to get ticks per millisec or ticks per sec. Best Regards, Bill Campbell > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Dear "J. William Campbell", In message <4ddeafe0.8060...@comcast.net> you wrote: > > I certainly agree using 64 bits for all calculations is vast overkill. > In fact, I think using 64 bit calculations on systems that have only a > 32 bit or less timer register is probably overkill. :-) However, to > date,AFAIK, no processor has exceeded the u32 in ticks per second. As I Not yet. But it makes no sense to start a new design with settings already in critical range, especially since there is zero problem with breaking it down by a factor of 1000 or 1e6. > pointed out in a previous e-mail, if they ever do this, we can just drop > one or 2 bits off the 64 bit counter and in millisecond resolution, > nobody will ever know. Also as previously pointed out, usec2ticks is No. I will not accept a design that is so close on the edge of breaking. What is your exact problem with the existing interfaces ticks2usec() and usec2ticks() ? > not present yet in lots of implementations. Also, if the fundamental > clock frequency is 32 kHz (or anything less than 1 MHz), usec2ticks is > 0! This probably rules out using it to get ticks per millisec or ticks > per sec. The statement "usec2ticks is 0" makes absolutely no sense as long as you don't say which argument you pass in. You get a return value of 0 even for a tick rate in the GHz range if you pass 0 as argument. Hoewver, usec2ticks(1000) or maybe usec2ticks(10) will probably return pretty useful values. [Note that by passing properly scaled arguments you can also avoid a number of rounding errors.] 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 Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On 5/26/2011 1:27 PM, Wolfgang Denk wrote: > Dear "J. William Campbell", > > In message<4ddeafe0.8060...@comcast.net> you wrote: >> I certainly agree using 64 bits for all calculations is vast overkill. >> In fact, I think using 64 bit calculations on systems that have only a >> 32 bit or less timer register is probably overkill. :-) However, to >> date,AFAIK, no processor has exceeded the u32 in ticks per second. As I > Not yet. But it makes no sense to start a new design with settings > already in critical range, especially since there is zero problem > with breaking it down by a factor of 1000 or 1e6. > >> pointed out in a previous e-mail, if they ever do this, we can just drop >> one or 2 bits off the 64 bit counter and in millisecond resolution, >> nobody will ever know. Also as previously pointed out, usec2ticks is > No. I will not accept a design that is so close on the edge of > breaking. > > What is your exact problem with the existing interfaces ticks2usec() > and usec2ticks() ? > >> not present yet in lots of implementations. Also, if the fundamental >> clock frequency is 32 kHz (or anything less than 1 MHz), usec2ticks is >> 0! This probably rules out using it to get ticks per millisec or ticks >> per sec. > The statement "usec2ticks is 0" makes absolutely no sense as long as > you don't say which argument you pass in. You get a return value of > 0 even for a tick rate in the GHz range if you pass 0 as argument. > > Hoewver, usec2ticks(1000) or maybe usec2ticks(10) will probably > return pretty useful values. > > [Note that by passing properly scaled arguments you can also avoid a > number of rounding errors.] Hi Wolfgang, Yes, you are correct. I was thinking usec2ticks(1), which is certainly not the way to do it. I am happy with usec2ticks and ticks2usec. That works for me. Sorry for the noise. How about the first part of my response? Are you still thinking about it or is it just too bad for words :-) ? Best Regards, Bill Campbell > > Best regards, > > Wolfgang Denk > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] omap4 EHCI support and SMSC95xx support on panda
Hello,
I am trying to get tftp working on the pandaboard; I am testing Simon's v6
patch series and Gilles EHCI patches
doc/README.sub claims that the SMSC driver supports usbethaddr, I do not
see this
smsc95xx_init_mac_address() fails to get the hwaddr from eeprom and then
it should do
if (eth_getenv_enetaddr_by_index("usbeth", 0, eth->enetaddr)) {
debug("MAC address read from usbethaddr\n");
return 0;
}
which is missing?
this is what I get after fixing the usbethaddr issue -- any ideas?
U-Boot 2011.06-rc1-4-g1822426-dirty (May 26 2011 - 22:36:28)
CPU : OMAP4430
Board: OMAP4 Panda
I2C: ready
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0
Using default environment
In:serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
Panda # set usbethaddr 0:0:1:2:3:4
Panda # usb start
(Re)start USB...
USB: Register 1313 NbrPorts 3
USB EHCI 1.00
scanning bus for devices... The request port(2) is not configured
The request port(2) is not configured
3 USB Device(s) found
scanning bus for ethernet devices...
USB Ethernet device detected
Endpoints In 1 Out 2 Int 3
** smsc95xx_eth_get_info()
1 Ethernet Device(s) found
Panda # ping 192.168.1.1
** smsc95xx_halt()
** smsc95xx_init()
No EEPROM present
MAC address read from usbethaddr
** smsc95xx_write_hwaddr()
MAC 00:00:01:02:03:04
Read Value from HW_CFG : 0x
Read Value from HW_CFG after writing HW_CFG_BIR_: 0x1000
rx_urb_size=18944
Read Value from BURST_CAP after writing: 0x0025
Read Value from BULK_IN_DLY after writing: 0x2000
Read Value from HW_CFG: 0x1000
Read Value from HW_CFG after writing: 0x1022
ID_REV = 0xec02
COE_CR = 0x
phy initialised succesfully
Waiting for Ethernet connection... done.
Using sms0 device
** smsc95xx_send(), len 42, buf 0x9febf80c
Tx: len = 50, actual = 50, err = 0
** smsc95xx_recv()
Rx: len = 2048, actual = 68, err = 0
** smsc95xx_send(), len 42, buf 0x9febf7cc
Tx: len = 50, actual = 50, err = 0
** smsc95xx_recv()
EHCI timed out on TD - token=0x88008d80
Rx: len = 2048, actual = 50, err = -1
Rx: failed to receive
** smsc95xx_halt
[U-Boot] omap4 EHCI support and SMSC95xx support on panda
Hello,
I am trying to get tftp working on the pandaboard; I am testing Simon's v6
patch series and Gilles EHCI patches
doc/README.sub claims that the SMSC driver supports usbethaddr, I do not
see this
smsc95xx_init_mac_address() fails to get the hwaddr from eeprom and then
it should do
if (eth_getenv_enetaddr_by_index("usbeth", 0, eth->enetaddr)) {
debug("MAC address read from usbethaddr\n");
return 0;
}
which is missing?
this is what I get after fixing the usbethaddr issue -- any ideas?
U-Boot 2011.06-rc1-4-g1822426-dirty (May 26 2011 - 22:36:28)
CPU : OMAP4430
Board: OMAP4 Panda
I2C: ready
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0
Using default environment
In:serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
Panda # set usbethaddr 0:0:1:2:3:4
Panda # usb start
(Re)start USB...
USB: Register 1313 NbrPorts 3
USB EHCI 1.00
scanning bus for devices... The request port(2) is not configured
The request port(2) is not configured
3 USB Device(s) found
scanning bus for ethernet devices...
USB Ethernet device detected
Endpoints In 1 Out 2 Int 3
** smsc95xx_eth_get_info()
1 Ethernet Device(s) found
Panda # ping 192.168.1.1
** smsc95xx_halt()
** smsc95xx_init()
No EEPROM present
MAC address read from usbethaddr
** smsc95xx_write_hwaddr()
MAC 00:00:01:02:03:04
Read Value from HW_CFG : 0x
Read Value from HW_CFG after writing HW_CFG_BIR_: 0x1000
rx_urb_size=18944
Read Value from BURST_CAP after writing: 0x0025
Read Value from BULK_IN_DLY after writing: 0x2000
Read Value from HW_CFG: 0x1000
Read Value from HW_CFG after writing: 0x1022
ID_REV = 0xec02
COE_CR = 0x
phy initialised succesfully
Waiting for Ethernet connection... done.
Using sms0 device
** smsc95xx_send(), len 42, buf 0x9febf80c
Tx: len = 50, actual = 50, err = 0
** smsc95xx_recv()
Rx: len = 2048, actual = 68, err = 0
** smsc95xx_send(), len 42, buf 0x9febf7cc
Tx: len = 50, actual = 50, err = 0
** smsc95xx_recv()
EHCI timed out on TD - token=0x88008d80
Rx: len = 2048, actual = 50, err = -1
Rx: failed to receive
** smsc95xx_halt
[U-Boot] Read NAND flash error - nand_do_read_ops() function failed with an error code -117
Hi there,
I am experiencing reading NAND flash failure, that nand_do_read_ops() function
returns an error -117 (EUCLEAN) in file nand_base.c.
If I comment out this line and hardcoded to "return 0" like this:
// return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
return 0;
Then I am able to read the entire kernel image correctly and boot into linux
just fine.
My question is why this function returns an error when there is an software ecc
correction happened (mtd->ecc_stats.corrected value is changed to be different
from that in stats.corrected)? Can I keep the hardcoded "return 0" in the
product?
I added printing out of the values:
400.001 before entering nand_do_read_ops() len=0x0002, buff=2100
500.001 hardcoded to return ok. ecc_stats.corrected=4, stats.corrected=0
400.001 before entering nand_do_read_ops() len=0x0002, buff=2102
500.001 hardcoded to return ok. ecc_stats.corrected=5, stats.corrected=4
400.001 before entering nand_do_read_ops() len=0x0002, buff=2104
500.001 hardcoded to return ok. ecc_stats.corrected=9, stats.corrected=5
400.001 before entering nand_do_read_ops() len=0x0002, buff=2106
500.001 hardcoded to return ok. ecc_stats.corrected=14, stats.corrected=9
( More )
This is a customized Atmel AT91SAM9260-EK with NAND flash chip from Micron
(MT29F1G08ABBHC-ET:B, 1Gbx8bit).
Here is the nand init code:
int board_nand_init(struct nand_chip *nand)
{
nand->ecc.mode = NAND_ECC_SOFT;
nand->cmd_ctrl = at91sam9260ek_nand_hwcontrol;
nand->dev_ready = at91sam9260ek_nand_ready;
nand->chip_delay = 20;
return 0;
}
Any help is hight appreciated.
Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap4 EHCI support and SMSC95xx support on panda
Hi,
It is a little tricky to know what you are applying as this is not in
the tree yet AFAIK.
I have a small change request so will make that and send out another
patch to the list which will hopefully be applied.
However...this doesn't look good:
EHCI timed out on TD - token=0x88008d80
It might be worth looking at why this is happening.
Regards,
Simon
On Thu, May 26, 2011 at 2:01 PM, Peter Meerwald wrote:
> Hello,
>
> I am trying to get tftp working on the pandaboard; I am testing Simon's v6
> patch series and Gilles EHCI patches
>
> doc/README.sub claims that the SMSC driver supports usbethaddr, I do not
> see this
>
> smsc95xx_init_mac_address() fails to get the hwaddr from eeprom and then
> it should do
> if (eth_getenv_enetaddr_by_index("usbeth", 0, eth->enetaddr)) {
> debug("MAC address read from usbethaddr\n");
> return 0;
> }
> which is missing?
>
>
> this is what I get after fixing the usbethaddr issue -- any ideas?
>
> U-Boot 2011.06-rc1-4-g1822426-dirty (May 26 2011 - 22:36:28)
>
> CPU : OMAP4430
> Board: OMAP4 Panda
> I2C: ready
> DRAM: 512 MiB
> MMC: OMAP SD/MMC: 0
> Using default environment
>
> In: serial
> Out: serial
> Err: serial
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
> Panda # set usbethaddr 0:0:1:2:3:4
> Panda # usb start
> (Re)start USB...
> USB: Register 1313 NbrPorts 3
> USB EHCI 1.00
> scanning bus for devices... The request port(2) is not configured
> The request port(2) is not configured
> 3 USB Device(s) found
> scanning bus for ethernet devices...
>
> USB Ethernet device detected
> Endpoints In 1 Out 2 Int 3
> ** smsc95xx_eth_get_info()
> 1 Ethernet Device(s) found
> Panda # ping 192.168.1.1
> ** smsc95xx_halt()
> ** smsc95xx_init()
> No EEPROM present
> MAC address read from usbethaddr
> ** smsc95xx_write_hwaddr()
> MAC 00:00:01:02:03:04
> Read Value from HW_CFG : 0x
> Read Value from HW_CFG after writing HW_CFG_BIR_: 0x1000
> rx_urb_size=18944
> Read Value from BURST_CAP after writing: 0x0025
> Read Value from BULK_IN_DLY after writing: 0x2000
> Read Value from HW_CFG: 0x1000
> Read Value from HW_CFG after writing: 0x1022
> ID_REV = 0xec02
> COE_CR = 0x
> phy initialised succesfully
> Waiting for Ethernet connection... done.
> Using sms0 device
> ** smsc95xx_send(), len 42, buf 0x9febf80c
> Tx: len = 50, actual = 50, err = 0
> ** smsc95xx_recv()
> Rx: len = 2048, actual = 68, err = 0
> ** smsc95xx_send(), len 42, buf 0x9febf7cc
> Tx: len = 50, actual = 50, err = 0
> ** smsc95xx_recv()
> EHCI timed out on TD - token=0x88008d80
> Rx: len = 2048, actual = 50, err = -1
> Rx: failed to receive
> ** smsc95xx_halt()
> ping failed; host 192.168.1.1 is not alive
> Panda #
>
>
>
> sorry if I got something wrong, I hope I am looking at the right
> patches...
>
> regards, p.
>
> --
>
> Peter Meerwald
> +43-664-218 (mobile)
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message you wrote: >> >> Can we have a microsecond one also please? Some sort of microsecond > > I guess you cannot, at least not in general. In worst case that would > mean we have to process 1e6 interrupts per second, which leaves little > time for anything useful. If we implemented a sync_us_timer(), we could either: a) Never kick it using an interrupt at all (only kick it in udelay()) b) Kick it in a much slower interrupt (1ms+ period) Remember, the kicking of the sync function does not need to correlate to the incrementing of the tick counter - Only to the roll-over period of the tick counter. For a 64-bit sub microsecond tick counter, interrupts will probably not ever be needed (unless the tick frequency is ludicrous - even a nanosecond tick counter will take 213 days to wrap) so in this case, sync_us_timer() would be fine Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Fri, May 27, 2011 at 3:49 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4dde5548.3020...@gmail.com> you wrote:
>>
>> Assumed Capabilities of the Platform
>> - Has a 'tick counter' that does not rely on software to increment
>
> I think we should delete the "does not rely on software to increment"
> part. It is not really essential.
I am sure there has been confusion with a misunderstanding the the
tick counter is NOT interrupt driven
>> - tick interval may by a fixed constant which cannot be controlled
>> via software, or it could be programmable (PIT)
>>
>> API Functions (/lib/timer.c)
>> - u32 get_timer(u32 start)
>> - Returns the number of elapsed milliseconds since 'start'
>
> If you really want to make the code flexible, then say
> "returns the number of "1/CONFIG_SYS_HZ" time units since
> 'start'"
>
> The 1 ms resolution is actually tied to the CONFIG_SYS_HZ
> definition (which is the reason why I always fought that
> CONFIG_SYS_HZ must be defined as 1000).
>
> Of course we could also drop this definition completely...
>
I think we should - If CONFIG_SYS_HZ _MUST_ be 1000 anyway, what is the
point. Also, get_timer() utilisation as it stands for the most part already
assumes a 1ms time base. Maybe we should change get_timer() to
get_ms_timer() to avoid any ambiguity
>> API Functions (/arch/...)
>> - void udelay(u32 delay)
>> - Used for 'short' delays (generally up to several seconds)
>
> no. only good for delays well below one second.
>
>> - Can use the tick counter if it is fast enough
>> - MUST NOT RESET THE TICK COUNTER
>
> Should ne not state that the tick counter must never be reset during
> the life-time -f U-Boot?
Yes, I think you are right
> We should also note that neither get_timer() nor udelay() make any
> guarantee for the precision of the returned timing information, except
> that udelay(N) is always supposed to delay for _at_least_ N
> microseconds.
Correct
>> 'Helper' Functions (/lib/timer.c)
>> - void sync_timebase(void)
>
> Can be a macro (to avoid call overhead).
True
>> - Updates the millisecond timer
>
> We need to define that term.. Eventually you want to change the
> definition of get_timer() into "returns the content of the millisecond
> timer" or similar.
>
>> - Utilises HAL functions to access the platform's tick counter
>> - Must be called more often than the rollover period of the
>> platform's tick counter
>> - Does not need to be called with a regular frequency (immune
>> to interrupt skew)
>> - Is always called by get_timer()
>> - For platforms with short tick counter rollovers it should
>> be called by an ISR
>> - Bill Campbell wrote a good example which proved this can be common
>> and arbitrary (and optionally free of divides and capable of
>> maintaining accuracy even if the tick frequency is not an even
>> division of 1ms)
>>
>> HAL Functions (/arch/... or /board/...)
>> - u64 get_ticks(void)
>> - Returns a tick count as an unsigned 64-bit integer
>> - Abstracts the implementation of the platform tick counter
>> (platform may by 32-bit 3MHz counter, might be a 16-bit
>> 0-999 microsecond plus 16-bit 0-65535 millisecond etc)
>> - u64 ticks_per_millisecond()
>> - Returns the number of ticks (as returned by get_ticks()) per
>> millisecond
>
> I recommend to stick with the existing ticks2usec() and usec2ticks();
> you can then use usec2ticks(1000) to get the ticks per millisecond.
Can do - And that would mean a sync_us_timer() would call usec2ticks(1)
>> - void timer_isr()
>> - Optional (particularly if tick counter rollover period is
>> exceptionally log which is usually the case for native 64-bit tick
>> counters)
>> - Simply calls sync_timebase()
>> - For platforms without any tick counter, this can implement one
>> (but accuracy will be harmed due to usage of disable_interrupts() and
>> enable_interrupts() in U-Boot
>>
>> So to get the new API up and running, only two functions are mandatory:
>>
>> get_ticks() which reads the hardware tick counter and deals with any 'funny
>> stuff' including rollovers, short timers (12-bit for example), composite
>> counters (16-bit 0-999 microsecond + 16-bit millisecond) and maintains a
>> 'clean' 64-bit tick counter which rolls over from all 1's to all 0's. The
>> 64-bit tick counter does not need to be reset to zero ever (even on startup
>> - sync_timebase tacks care of all the details)
>>
>> ticks_per_millisecond() simply return the number of ticks in a millisecond
>> - This may as simple as:
>>
>> inline u64 ticks_per_millisecond(void)
>> {
>> return CONFIG_SYS_TICK_PER_MS;
>> }
>
> Better move this part up to the description of usec2ticks() / ticks2usec().
OK
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Fri, May 27, 2011 at 4:52 AM, J. William Campbell wrote: > On 5/26/2011 10:53 AM, Wolfgang Denk wrote: >> >> Dear "J. William Campbell", >> >> In message<4dde8639.3090...@comcast.net> you wrote: >> >>> I think it is the task of get_ticks to return the hardware tick counter >>> as an increasing counter, period. The counter may wrap at some final >>> count that is not all ones. That is ok. Sync_timebase deals with the >> >> NO! We want to be able to compute time differences using simple >> unsigned arithmentics, even after a rollover of the counter. For this >> it is mandatory that the counter always gets only incremented until it >> wraps around at te end of it's number range, and never gets reset > > Hi All, > I agree that that is what must happen, but it should happen inside > sync_timebase. Sync_timebase does what is needed to convert the > less-than-fully capable counters into a fully capable one. You could move How will sync_timebase() know that a rollover has happened before all 1's? We would then need to tell sync_timebase() what the maximum value returned by get_ticks() is. Easier to do have get_ticks() handle it as that is a platform specific detail > that functionality down into get_ticks, but if you do, you end up much like > the present scheme where the multiple different get_ticks routines expected > to cope with expanding the hardware counter properly. To date, it has been Correct - the tick counter is a platform specific implementation detail and therefore the implementation of the HAL (get_ticks()) must also be platform specific > shown conclusively that this process cannot be relied upon, or we wouldn't > be having this discussion. If we put that functionality inside > sync_timebase, it is in one place and debuggable once. All sync_timebase > requires to do this is ticks per second and maximum tick value. I do request > that counters that decrement be negated in the get_ticks routine, but beyond > that, it should be a simple read of the tick register(s). But how do you handle cases like the sc520 - A microsecond counter which counts 0-999, kicking a 16-bit millisecond counter on rollover. Reading of the millisecond counter latches the microsecond counter and resets the millsecond counter to zero There is no uniform tick counter to read - It has to be fudged - in get_ticks() Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] powerpc/i2c: introduce CONFIG_I2C_TWR for setting tWR value
From: york
EEPROM requires tWR for write cycle time. Since there is no other way to
poll if the internal programming ends, wait for 5ms which is the max timing
for AT24C01/02/04/08/16 by default. It can be overridden by defining
CONFIG_I2C_TWR in configuration file if the slowest device has different write
cycle time.
Signed-off-by: York Sun
---
README|7 +++
drivers/i2c/fsl_i2c.c |9 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 8bb9c8d..83a316c 100644
--- a/README
+++ b/README
@@ -1717,6 +1717,13 @@ The following options need to be configured:
devices can use either method, but some require one or
the other.
+ CONFIG_I2C_TWR
+
+ defining this will override the default write cycle time
+ 5ms which is the default for AT24C01/02/4/08/16. If the
+ slowest I2C device has different write cycle time, this
+ option should be defined. The unit is microsecond.
+
- SPI Support: CONFIG_SPI
Enables SPI driver (so far only tested with
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index cb13dee..d192b2a 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -42,6 +42,14 @@
#define CONFIG_I2C_TIMEOUT 1
#endif
+/*
+ * tWR is the write cycle time for EEPROM device
+ * in microseconds
+ */
+#ifndef CONFIG_I2C_TWR
+#define CONFIG_I2C_TWR 5000
+#endif
+
#define I2C_READ_BIT 1
#define I2C_WRITE_BIT 0
@@ -416,6 +424,7 @@ i2c_write(u8 dev, uint addr, int alen, u8 *data, int length)
if (i2c_wait4bus()) /* Wait until STOP */
debug("i2c_write: wait4bus timed out\n");
+ udelay(CONFIG_I2C_TWR);
if (i == length)
return 0;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] powerpc/mpc8xxx: adjust DDR burst length and chop accroding to sdram width
From: york
If the bus width is 32-bit, burst chop should be disabled and burst length
should be 8. Read from SPD or other source to determine the width.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/options.c | 24
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
index 6ccc3b0..80c7046 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
@@ -418,8 +418,19 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
/* Choose dynamic power management mode. */
popts->dynamic_power = 0;
- /* 0 = 64-bit, 1 = 32-bit, 2 = 16-bit */
- popts->data_bus_width = 0;
+ /*
+* check first dimm for primary sdram width
+* presuming all dimms are similar
+* 0 = 64-bit, 1 = 32-bit, 2 = 16-bit
+*/
+ if (pdimm[0].primary_sdram_width == 64)
+ popts->data_bus_width = 0;
+ else if (pdimm[0].primary_sdram_width == 32)
+ popts->data_bus_width = 1;
+ else if (pdimm[0].primary_sdram_width == 16)
+ popts->data_bus_width = 2;
+ else
+ panic("Error: invalid primary sdram width!\n");
/* Choose burst length. */
#if defined(CONFIG_FSL_DDR3)
@@ -427,8 +438,13 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
popts->OTF_burst_chop_en = 0; /* on-the-fly burst chop disable */
popts->burst_length = DDR_BL8; /* Fixed 8-beat burst len */
#else
- popts->OTF_burst_chop_en = 1; /* on-the-fly burst chop */
- popts->burst_length = DDR_OTF; /* on-the-fly BC4 and BL8 */
+ if (popts->data_bus_width == 1) { /* 32-bit bus */
+ popts->OTF_burst_chop_en = 0;
+ popts->burst_length = DDR_BL8;
+ } else {
+ popts->OTF_burst_chop_en = 1; /* on-the-fly burst chop */
+ popts->burst_length = DDR_OTF; /* on-the-fly BC4 and BL8 */
+ }
#endif
#else
popts->burst_length = DDR_BL4; /* has to be 4 for DDR2 */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] powerpc/mpc8xxx: check SPD length before using part number
From: york Only use DDR DIMM part number if SPD has valid length, to prevent from display garbage in case SPD doesn't cover these fields. Signed-off-by: York Sun --- arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c index 756b15f..838cebe 100644 --- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c +++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c @@ -114,7 +114,8 @@ ddr_compute_dimm_parameters(const ddr3_spd_eeprom_t *spd, * and copying the part name in ASCII from the SPD onto it */ memset(pdimm->mpart, 0, sizeof(pdimm->mpart)); - memcpy(pdimm->mpart, spd->mpart, sizeof(pdimm->mpart) - 1); + if ((spd->info_size_crc & 0xF) > 1) + memcpy(pdimm->mpart, spd->mpart, sizeof(pdimm->mpart) - 1); /* DIMM organization parameters */ pdimm->n_ranks = ((spd->organization >> 3) & 0x7) + 1; -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] powerpc/mpc8xxx: Add 16-bit support for DDR3
Add support for 16-bit DDR bus. Also deal with system using 64- and 32-bit
DDR devices.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/main.c | 14 +-
arch/powerpc/cpu/mpc8xxx/ddr/options.c |3 ++-
arch/powerpc/include/asm/fsl_ddr_sdram.h |3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
index 2b43e73..db7cf11 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
@@ -174,7 +174,19 @@ int step_assign_addresses(fsl_ddr_info_t *pinfo,
switch (pinfo->memctl_opts[i].data_bus_width) {
case 2:
/* 16-bit */
- printf("can't handle 16-bit mode yet\n");
+ for (j = 0; j < CONFIG_DIMM_SLOTS_PER_CTLR; j++) {
+ unsigned int dw;
+ if (!pinfo->dimm_params[i][j].n_ranks)
+ continue;
+ dw =
pinfo->dimm_params[i][j].primary_sdram_width;
+ if ((dw == 72 || dw == 64)) {
+ dbw_cap_adj[i] = 2;
+ break;
+ } else if ((dw == 40 || dw == 32)) {
+ dbw_cap_adj[i] = 1;
+ break;
+ }
+ }
break;
case 1:
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
index 80c7046..02efe58 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
@@ -438,7 +438,8 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
popts->OTF_burst_chop_en = 0; /* on-the-fly burst chop disable */
popts->burst_length = DDR_BL8; /* Fixed 8-beat burst len */
#else
- if (popts->data_bus_width == 1) { /* 32-bit bus */
+ if ((popts->data_bus_width == 1) || (popts->data_bus_width == 2)) {
+ /* 32-bit or 16-bit bus */
popts->OTF_burst_chop_en = 0;
popts->burst_length = DDR_BL8;
} else {
diff --git a/arch/powerpc/include/asm/fsl_ddr_sdram.h
b/arch/powerpc/include/asm/fsl_ddr_sdram.h
index 127a840..1778cc5 100644
--- a/arch/powerpc/include/asm/fsl_ddr_sdram.h
+++ b/arch/powerpc/include/asm/fsl_ddr_sdram.h
@@ -181,6 +181,9 @@ typedef struct memctl_options_partial_s {
unsigned int all_DIMMs_minimum_tRCD_ps;
} memctl_options_partial_t;
+#define DDR_DATA_BUS_WIDTH_64 0
+#define DDR_DATA_BUS_WIDTH_32 1
+#define DDR_DATA_BUS_WIDTH_16 2
/*
* Generalized parameters for memory controller configuration,
* might be a little specific to the FSL memory controller
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] powerpc/mpc8xxx: Adding fallback to raw timing on supported boards
In case of empty SPD or checksum error, fallback to raw timing on
supported boards.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/main.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
index db7cf11..2e43da6 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
@@ -343,12 +343,20 @@ fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int
start_step,
&(pinfo->dimm_params[i][j]);
retval = compute_dimm_parameters(spd, pdimm, i);
+#ifdef CONFIG_DDR_RAW_TIMING
+ if (retval != 0) {
+ printf("SPD error! Trying fallback to "
+ "raw timing calculation\n");
+ fsl_ddr_get_dimm_params(pdimm, i, j);
+ }
+#else
if (retval == 2) {
printf("Error: compute_dimm_parameters"
" non-zero returned FATAL value "
"for memctl=%u dimm=%u\n", i, j);
return 0;
}
+#endif
if (retval) {
debug("Warning: compute_dimm_parameters"
" non-zero return value for memctl=%u "
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] powerpc/mpc8xxx: Enable calculation for fixed DDR chips
From: york
We used to have fixed parameters for soldered DDR chips. This patch enables
calculation based on raw timing data, implemneted in board-specific file.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/cpu.c|4 +++-
arch/powerpc/cpu/mpc8xxx/ddr/Makefile | 13 +++--
arch/powerpc/cpu/mpc8xxx/ddr/ddr.h|5 +
arch/powerpc/cpu/mpc8xxx/ddr/main.c | 12
4 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index f863f4a..8c2272a 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -336,7 +336,9 @@ phys_size_t initdram(int board_type)
}
#endif
-#if defined(CONFIG_SPD_EEPROM) || defined(CONFIG_DDR_SPD)
+#ifdefined(CONFIG_SPD_EEPROM) || \
+ defined(CONFIG_DDR_SPD) || \
+ defined(CONFIG_DDR_RAW_TIMING)
dram_size = fsl_ddr_sdram();
#else
dram_size = fixed_sdram();
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/Makefile
b/arch/powerpc/cpu/mpc8xxx/ddr/Makefile
index 4a5a785..d1b4c4b 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/Makefile
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/Makefile
@@ -12,15 +12,24 @@ LIB = $(obj)libddr.o
COBJS-$(CONFIG_FSL_DDR1) += main.o util.o ctrl_regs.o options.o \
lc_common_dimm_params.o
-COBJS-$(CONFIG_FSL_DDR1) += ddr1_dimm_params.o
COBJS-$(CONFIG_FSL_DDR2) += main.o util.o ctrl_regs.o options.o \
lc_common_dimm_params.o
-COBJS-$(CONFIG_FSL_DDR2) += ddr2_dimm_params.o
COBJS-$(CONFIG_FSL_DDR3) += main.o util.o ctrl_regs.o options.o \
lc_common_dimm_params.o
+ifdef CONFIG_DDR_SPD
+SPD := y
+endif
+ifdef CONFIG_SPD_EEPROM
+SPD := y
+endif
+ifdef SPD
+COBJS-$(CONFIG_FSL_DDR1) += ddr1_dimm_params.o
+COBJS-$(CONFIG_FSL_DDR2) += ddr2_dimm_params.o
COBJS-$(CONFIG_FSL_DDR3) += ddr3_dimm_params.o
+endif
+
SRCS := $(START:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
index 1e866fe..eb2180e 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
@@ -14,6 +14,7 @@
#include "common_timing_params.h"
+#if defined(CONFIG_DDR_SPD) || defined(CONFIG_SPD_EEPROM)
/*
* Bind the main DDR setup driver's generic names
* to this specific DDR technology.
@@ -25,6 +26,7 @@ compute_dimm_parameters(const generic_spd_eeprom_t *spd,
{
return ddr_compute_dimm_parameters(spd, pdimm, dimm_number);
}
+#endif
/*
* Data Structures
@@ -80,4 +82,7 @@ extern void check_interleaving_options(fsl_ddr_info_t *pinfo);
extern unsigned int mclk_to_picos(unsigned int mclk);
extern unsigned int get_memory_clk_period_ps(void);
extern unsigned int picos_to_mclk(unsigned int picos);
+
+/* board specific function */
+int fsl_ddr_get_dimm_params(dimm_params_t *pdimm, unsigned int dimm_number);
#endif
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
index c8fa123..2b43e73 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
@@ -313,6 +313,7 @@ fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int
start_step,
switch (start_step) {
case STEP_GET_SPD:
+#if defined(CONFIG_DDR_SPD) || defined(CONFIG_SPD_EEPROM)
/* STEP 1: Gather all DIMM SPD data */
for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++) {
fsl_ddr_get_spd(pinfo->spd_installed_dimms[i], i);
@@ -344,6 +345,17 @@ fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int
start_step,
}
}
+#else
+ case STEP_COMPUTE_DIMM_PARMS:
+ for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++) {
+ for (j = 0; j < CONFIG_DIMM_SLOTS_PER_CTLR; j++) {
+ dimm_params_t *pdimm =
+ &(pinfo->dimm_params[i][j]);
+ fsl_ddr_get_dimm_params(pdimm, i);
+ }
+ }
+ debug("Filling dimm parameters from board specific file\n");
+#endif
case STEP_COMPUTE_COMMON_PARMS:
/*
* STEP 3: Compute a common set of timing parameters
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] powerpc/mpc8xxx: change raw timing function call parameters
Adding controller number so board implementation can distinguish.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |4 +++-
arch/powerpc/cpu/mpc8xxx/ddr/main.c |2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
index eb2180e..f59aa33 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
@@ -84,5 +84,7 @@ extern unsigned int get_memory_clk_period_ps(void);
extern unsigned int picos_to_mclk(unsigned int picos);
/* board specific function */
-int fsl_ddr_get_dimm_params(dimm_params_t *pdimm, unsigned int dimm_number);
+int fsl_ddr_get_dimm_params(dimm_params_t *pdimm,
+ unsigned int controller_number,
+ unsigned int dimm_number);
#endif
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
index 2e43da6..b559787 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/main.c
@@ -371,7 +371,7 @@ fsl_ddr_compute(fsl_ddr_info_t *pinfo, unsigned int
start_step,
for (j = 0; j < CONFIG_DIMM_SLOTS_PER_CTLR; j++) {
dimm_params_t *pdimm =
&(pinfo->dimm_params[i][j]);
- fsl_ddr_get_dimm_params(pdimm, i);
+ fsl_ddr_get_dimm_params(pdimm, i, j);
}
}
debug("Filling dimm parameters from board specific file\n");
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Bill, On Fri, May 27, 2011 at 2:56 AM, J. William Campbell wrote: > On 5/26/2011 6:27 AM, Graeme Russ wrote: >> >> Hello Everyone, >> >> OK - Starting a new thread to discuss implementation details. This is a >> heads-up for arch/platform maintainers - Once this is a bit more stable, I >> will put it on the wiki >> >> Assumed Capabilities of the Platform >> - Has a 'tick counter' that does not rely on software to increment > > Hi All, > The nios2 with the most basic timer does not meet this requirement. It > will not count at all without the 10 ms interrupt. I don't think this > requirement matters anyway. We need a 'tick counter' that 'ticks'. If it > takes software to make it tick, we don't much care. There may be problems > with early use of udelay in that case, but that is a different issue. I think we will need to define get_timer() weak - Nios will have to override the default implementation to cater for it's (Nios') limitations >> - tick interval may by a fixed constant which cannot be controlled >> via software, or it could be programmable (PIT) >> >> API Functions (/lib/timer.c) >> - u32 get_timer(u32 start) >> - Returns the number of elapsed milliseconds since 'start' >> >> API Functions (/arch/...) >> - void udelay(u32 delay) >> - Used for 'short' delays (generally up to several seconds) >> - Can use the tick counter if it is fast enough >> - MUST NOT RESET THE TICK COUNTER > > There is a requirement that udelay be available before relocation and before > the BSS is available. One can use the tick counter to provide udelay as long > as sync_timebase is not called OR sync timebase does not use BSS. It appears > many implementations ignore this requirement at present. We should try to > fix this, but is should not be a requirement. If you really wanted to, sync_timebase() could use global data (it doesn't have many static variables) in which case all timer functions would be available before relocation >> >> 'Helper' Functions (/lib/timer.c) > > I think this function should be weak, so that it is possible for people to > override it with a "custom" function. The fully general sync_timebase has > lots of code in it that can be simplified in special cases. We want and need > a fully general function to be available, but other users who are real tight > on space may want a cut down version. We should make that easily possible. Agree >> >> - void sync_timebase(void) >> - Updates the millisecond timer >> - Utilises HAL functions to access the platform's tick counter >> - Must be called more often than the rollover period of the >> platform's tick counter >> - Does not need to be called with a regular frequency (immune >> to interrupt skew) >> - Is always called by get_timer() >> - For platforms with short tick counter rollovers it should >> be called by an ISR >> - Bill Campbell wrote a good example which proved this can be common >> and arbitrary (and optionally free of divides and capable of >> maintaining accuracy even if the tick frequency is not an even >> division of 1ms) >> >> HAL Functions (/arch/... or /board/...) >> - u64 get_ticks(void) > > For what it's worth, I would like to propose using a (gasp!) typedef here. > It seems to me there are a whole lot of cases where the max number of ticks > is a u32 or less. In those cases, the wrap at 32 bits helps things a lot. If > the tick counter is really 64 bits, the function of sync_timebase is simply > to convert the tick value to millisec, and that is it. Otherwise, if it is > 32 bits or less then some other actions will be required. I think this is > one of those times where a typedef would help, We could define a type called > timer_tick_t to describe this quantity. That would allow a pure 32 bit > implementation where appropriate. > > Another suggestion is that perhaps we want a u32 get_ticks_lsb(void) as well > as a regular get_ticks. The lsb version would be used for udelay and could > possibly come from another timer if that was necessary/desirable. See the > requirement for early udelay early availability. I think this all adds unnecessary complexity >> - Returns a tick count as an unsigned 64-bit integer >> - Abstracts the implementation of the platform tick counter >> (platform may by 32-bit 3MHz counter, might be a 16-bit >> 0-999 microsecond plus 16-bit 0-65535 millisecond etc) >> - u64 ticks_per_millisecond() >> - Returns the number of ticks (as returned by get_ticks()) per >> millisecond > > I think ticks_per_sec would be a better choice. First, such a function > already exists in almost all u-boots. Second, if one wants the best accuracy > for things like udelay, you need better accuracy than millisec. Since this > function is used only infrequently, when things are initialized, a divide to > get ticks_per_millsec (if that is what you really want) is no big deal. > Lastly, I think this functio
[U-Boot] [Patch v3 1/2] Adding more SPD registers
Adding byte 32 and 33
Signed-off-by: York Sun
---
include/ddr_spd.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/ddr_spd.h b/include/ddr_spd.h
index e895d61..40a0463 100644
--- a/include/ddr_spd.h
+++ b/include/ddr_spd.h
@@ -219,7 +219,9 @@ typedef struct ddr3_spd_eeprom_s {
Delay Time*/
unsigned char opt_features;/* 30 SDRAM Optional Features */
unsigned char therm_ref_opt; /* 31 SDRAM Thermal and Refresh Opts */
- unsigned char res_32_59[28]; /* 32-59 Reserved, General Section */
+ unsigned char therm_sensor;/* 32 Module Thermal Sensor */
+ unsigned char device_type; /* 33 SDRAM device type */
+ unsigned char res_34_59[26]; /* 34-59 Reserved, General Section */
/* Module-Specific Section: Bytes 60-116 */
union {
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [PATCH 1/7] powerpc/i2c: introduce CONFIG_I2C_TWR for setting tWR value
York Sun wrote: > From: york You should fix this so that it includes your full name. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot-release] [PATCH 1/7] powerpc/i2c: introduce CONFIG_I2C_TWR for setting tWR value
On Thu, 2011-05-26 at 17:20 -0700, Tabi Timur-B04825 wrote: > York Sun wrote: > > From: york > > You should fix this so that it includes your full name. > > -- Sure. I can fix it along with other feedback. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On 5/26/2011 4:28 PM, Graeme Russ wrote: > Hi Bill, > > On Fri, May 27, 2011 at 2:56 AM, J. William Campbell > wrote: >> On 5/26/2011 6:27 AM, Graeme Russ wrote: >>> Hello Everyone, >>> >>> OK - Starting a new thread to discuss implementation details. This is a >>> heads-up for arch/platform maintainers - Once this is a bit more stable, I >>> will put it on the wiki >>> >>> Assumed Capabilities of the Platform >>> - Has a 'tick counter' that does not rely on software to increment >> Hi All, >>The nios2 with the most basic timer does not meet this requirement. It >> will not count at all without the 10 ms interrupt. I don't think this >> requirement matters anyway. We need a 'tick counter' that 'ticks'. If it >> takes software to make it tick, we don't much care. There may be problems >> with early use of udelay in that case, but that is a different issue. > I think we will need to define get_timer() weak - Nios will have to > override the default implementation to cater for it's (Nios') limitations Hi All, Yes, that will probably be required here. >>> - tick interval may by a fixed constant which cannot be controlled >>> via software, or it could be programmable (PIT) >>> >>> API Functions (/lib/timer.c) >>> - u32 get_timer(u32 start) >>> - Returns the number of elapsed milliseconds since 'start' >>> >>> API Functions (/arch/...) >>> - void udelay(u32 delay) >>> - Used for 'short' delays (generally up to several seconds) >>> - Can use the tick counter if it is fast enough >>> - MUST NOT RESET THE TICK COUNTER >> There is a requirement that udelay be available before relocation and before >> the BSS is available. One can use the tick counter to provide udelay as long >> as sync_timebase is not called OR sync timebase does not use BSS. It appears >> many implementations ignore this requirement at present. We should try to >> fix this, but is should not be a requirement. > If you really wanted to, sync_timebase() could use global data (it doesn't > have many static variables) in which case all timer functions would be > available before relocation Yes, my implementation of the sync_timebase routine was written that way, using gd-> for the required variables. >>> 'Helper' Functions (/lib/timer.c) >> I think this function should be weak, so that it is possible for people to >> override it with a "custom" function. The fully general sync_timebase has >> lots of code in it that can be simplified in special cases. We want and need >> a fully general function to be available, but other users who are real tight >> on space may want a cut down version. We should make that easily possible. > Agree > >>> - void sync_timebase(void) >>> - Updates the millisecond timer >>> - Utilises HAL functions to access the platform's tick counter >>> - Must be called more often than the rollover period of the >>>platform's tick counter >>> - Does not need to be called with a regular frequency (immune >>>to interrupt skew) >>> - Is always called by get_timer() >>> - For platforms with short tick counter rollovers it should >>>be called by an ISR >>> - Bill Campbell wrote a good example which proved this can be common >>>and arbitrary (and optionally free of divides and capable of >>>maintaining accuracy even if the tick frequency is not an even >>>division of 1ms) >>> >>> HAL Functions (/arch/... or /board/...) >>> - u64 get_ticks(void) >> For what it's worth, I would like to propose using a (gasp!) typedef here. >> It seems to me there are a whole lot of cases where the max number of ticks >> is a u32 or less. In those cases, the wrap at 32 bits helps things a lot. If >> the tick counter is really 64 bits, the function of sync_timebase is simply >> to convert the tick value to millisec, and that is it. Otherwise, if it is >> 32 bits or less then some other actions will be required. I think this is >> one of those times where a typedef would help, We could define a type called >> timer_tick_t to describe this quantity. That would allow a pure 32 bit >> implementation where appropriate. >> >> Another suggestion is that perhaps we want a u32 get_ticks_lsb(void) as well >> as a regular get_ticks. The lsb version would be used for udelay and could >> possibly come from another timer if that was necessary/desirable. See the >> requirement for early udelay early availability. > I think this all adds unnecessary complexity > >>> - Returns a tick count as an unsigned 64-bit integer >>> - Abstracts the implementation of the platform tick counter >>>(platform may by 32-bit 3MHz counter, might be a 16-bit >>>0-999 microsecond plus 16-bit 0-65535 millisecond etc) >>> - u64 ticks_per_millisecond() >>> - Returns the number of ticks (as returned by get_ticks()) per >>>millisecond >> I think ticks_per_sec would be a better choice. First, such a function >> already exists in a
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Bill,
On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
wrote:
> On 5/26/2011 4:28 PM, Graeme Russ wrote:
>>
>> Why mess around with bit shifting (which you would then have to cludge
>> into
>> your platform code) when carting around a 64-bit value is relatively
>> cheap,
>> transparent and poratble (all all supported up-to-date tool chains)
>>
> I really STRONGLY disagree with this statement. If you actually needed 64
> bit variables, fine use them. But as I have already shown, you do not need
> them in general. We are computing a 32 bit result. There is some entropy
> argument that says you shouldn't need 64 bits to do so. Another way to look
> at it is that converting the top 32 bit word and the bottom 32 bit word to
> ms separately can be easier than doing them both together at once. However,
> as we will see below, I do agree we need two 32 bit words to make this
> process go smoothly. I just don't agree that they should/will constitute a
> 64 bit binary word. See below.
- void timer_isr()
- Optional (particularly if tick counter rollover period is
exceptionally log which is usually the case for native 64-bit tick
counters)
- Simply calls sync_timebase()
- For platforms without any tick counter, this can implement one
(but accuracy will be harmed due to usage of disable_interrupts()
and
enable_interrupts() in U-Boot
So to get the new API up and running, only two functions are mandatory:
get_ticks() which reads the hardware tick counter and deals with any
'funny
stuff' including rollovers, short timers (12-bit for example), composite
counters (16-bit 0-999 microsecond + 16-bit millisecond) and maintains a
'clean' 64-bit tick counter which rolls over from all 1's to all 0's.
The
>>>
>>> I think it is the task of get_ticks to return the hardware tick counter
>>> as
>>> an increasing counter, period. The counter may wrap at some final count
>>> that is not all ones. That is ok. Sync_timebase deals with the rollovers
>>> if
>>
>> The hardware tick counter may, the 64-bit software tick counter maintained
>> by get_ticks() may not
>
>>> necessary. get_ticks is very lightweight. get_ticks should deal with
>>> decrementing counters by returning the complement of the counter. The
>>> sc520
>>> case is a bit more complex if you intend to use the 0-999 and 16 bit
>>> millisec registers, in that you do need to add them to the previous value
>>> to
>>
>> As I mentioned in another post, this is a problem for the platform
>> maintainer and is abstracted away throught the platform specific
>> implementation of get_ticks()
>>
>>> make an increasing counter. Sync_timebase "likes" short counters in that
>>> they are easy to convert to millisec and tick remainders.
>>
>> The compiler should handle using 64-bit rather than 32-bit transparently
>
> True enough. But you don't need 64 bit variables at this point two 32 bit
> ones work just fine, in fact better in most cases.
Remember, we are not dealing with a high performance OS here. The primary
goal is portability - Performance optimisations (which do not break
portability) can be performed later
64-bit tick counter does not need to be reset to zero ever (even on
startup
- sync_timebase tacks care of all the details)
>>>
>>> True, but sync_timebase does have to be initialized (as does the timer
>>> itself in most cases, so this is not a restriction).
>>
>> This can be done in timer_init() via a call to sync_timebase() after the
>> timer has been configured. This should bring everything into line
>>
ticks_per_millisecond() simply return the number of ticks in a
millisecond
- This may as simple as:
inline u64 ticks_per_millisecond(void)
{
return CONFIG_SYS_TICK_PER_MS;
}
But it may be trickier if you have a programmable tick frequency
>>>
>>> You will have to call the routine that initializes sync_timebase. This
>>> routine should have a name, like void init_sync_timebase(void)?
The optional timer ISR is required if the tick counter has a short roll
over duration (short is up to you - 1 second is short, 1 hour might be,
1
century is not)
Regards,
Graeme
>>> It is probably true that sync_timebase should have a parameter flag. The
>>> reason is that if the timer isr is called only when the timer wraps, then
>>> the calls to sync_timebase may be slightly more than a full timer period
>>> apart. (due to interrupt latency). Therefore, when the timer difference
>>> is
>>> computed, if the current update is due to a wrap AND the previous update
>>> is
>>> due to a wrap, the difference should be approximately 1 wrap. If it comes
>>> up
>>> real short, you must add a wrap. This isn't necessary if the routine is
>>> called more often than once per wrap. Also, when sync_timebase is called
>>> in
>>
>> timer_isr()
Re: [U-Boot] after relocation, the original text_base memory section can't be used
Hi, Albert Thanks for your help. I found the root cause: In our implementation, the RomCode initialises the mmu with one hardcode page table address (0x014F8000) to store the 16KB table, however, it's rewritten by the data. we may refer to the uboot way of using the dynamically generated TLB address and memory in arch/arm/lib/board.c, it's flexible. regards, Yuping On Thu, May 26, 2011 at 7:10 PM, Albert ARIBAUD wrote: > Hi, > > Le 26/05/2011 11:04, Yuping Luo a écrit : >> Hi, >> >> With 2011.03 uboot, I am adding firmware flashing feature to our >> arm cortex a9 soc platform via usb, in which the data firstly be >> uploaded to memory wholly (more than 200MB, thanks our 512MB physical >> memory), then burned. >> By my understanding, after relocation the successive memory range >> (0~~ relocaddr) can be (re)used. however, if the original text section >> (in my case, 0x0150) is written, the data abort happens when >> accessing 0x0160; if the memory section (0x0150~0x0160) >> not written, everything is ok. please correct me if I am wrong. > > Well, what is sure is that not all of 150-160 was used before > relocation either (it ends around 1546000), so 160 was not accessed > before reloc. How can you be sure the issue happens after reloc? For all > we know, it could be a bug in the code code that writes 150 to > 160 itself. > > Amicalement, > -- > Albert. > ___ > 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] [RFC][Timer API] Revised Specification - Implementation details
On 5/26/2011 6:51 PM, Graeme Russ wrote:
> Hi Bill,
>
> On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
> wrote:
>> On 5/26/2011 4:28 PM, Graeme Russ wrote:
>>> Why mess around with bit shifting (which you would then have to cludge
>>> into
>>> your platform code) when carting around a 64-bit value is relatively
>>> cheap,
>>> transparent and poratble (all all supported up-to-date tool chains)
>>>
>> I really STRONGLY disagree with this statement. If you actually needed 64
>> bit variables, fine use them. But as I have already shown, you do not need
>> them in general. We are computing a 32 bit result. There is some entropy
>> argument that says you shouldn't need 64 bits to do so. Another way to look
>> at it is that converting the top 32 bit word and the bottom 32 bit word to
>> ms separately can be easier than doing them both together at once. However,
>> as we will see below, I do agree we need two 32 bit words to make this
>> process go smoothly. I just don't agree that they should/will constitute a
>> 64 bit binary word. See below.
> - void timer_isr()
> - Optional (particularly if tick counter rollover period is
>exceptionally log which is usually the case for native 64-bit tick
>counters)
> - Simply calls sync_timebase()
> - For platforms without any tick counter, this can implement one
>(but accuracy will be harmed due to usage of disable_interrupts()
> and
>enable_interrupts() in U-Boot
>
> So to get the new API up and running, only two functions are mandatory:
>
> get_ticks() which reads the hardware tick counter and deals with any
> 'funny
> stuff' including rollovers, short timers (12-bit for example), composite
> counters (16-bit 0-999 microsecond + 16-bit millisecond) and maintains a
> 'clean' 64-bit tick counter which rolls over from all 1's to all 0's.
> The
I think it is the task of get_ticks to return the hardware tick counter
as
an increasing counter, period. The counter may wrap at some final count
that is not all ones. That is ok. Sync_timebase deals with the rollovers
if
>>> The hardware tick counter may, the 64-bit software tick counter maintained
>>> by get_ticks() may not
necessary. get_ticks is very lightweight. get_ticks should deal with
decrementing counters by returning the complement of the counter. The
sc520
case is a bit more complex if you intend to use the 0-999 and 16 bit
millisec registers, in that you do need to add them to the previous value
to
>>> As I mentioned in another post, this is a problem for the platform
>>> maintainer and is abstracted away throught the platform specific
>>> implementation of get_ticks()
>>>
make an increasing counter. Sync_timebase "likes" short counters in that
they are easy to convert to millisec and tick remainders.
>>> The compiler should handle using 64-bit rather than 32-bit transparently
>> True enough. But you don't need 64 bit variables at this point two 32 bit
>> ones work just fine, in fact better in most cases.
> Remember, we are not dealing with a high performance OS here. The primary
> goal is portability - Performance optimisations (which do not break
> portability) can be performed later
>
> 64-bit tick counter does not need to be reset to zero ever (even on
> startup
> - sync_timebase tacks care of all the details)
True, but sync_timebase does have to be initialized (as does the timer
itself in most cases, so this is not a restriction).
>>> This can be done in timer_init() via a call to sync_timebase() after the
>>> timer has been configured. This should bring everything into line
>>>
> ticks_per_millisecond() simply return the number of ticks in a
> millisecond
> - This may as simple as:
>
> inline u64 ticks_per_millisecond(void)
> {
> return CONFIG_SYS_TICK_PER_MS;
> }
>
> But it may be trickier if you have a programmable tick frequency
You will have to call the routine that initializes sync_timebase. This
routine should have a name, like void init_sync_timebase(void)?
> The optional timer ISR is required if the tick counter has a short roll
> over duration (short is up to you - 1 second is short, 1 hour might be,
> 1
> century is not)
>
> Regards,
>
> Graeme
>
It is probably true that sync_timebase should have a parameter flag. The
reason is that if the timer isr is called only when the timer wraps, then
the calls to sync_timebase may be slightly more than a full timer period
apart. (due to interrupt latency). Therefore, when the timer difference
is
computed, if the current update is due to a wrap AND the previous update
is
due to a wrap, the difference should be approximately 1 wrap. If it comes
up
real short, you must add a wrap. This isn't necessary if the r
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Bill,
On Fri, May 27, 2011 at 1:54 PM, J. William Campbell
wrote:
> On 5/26/2011 6:51 PM, Graeme Russ wrote:
>>
>> Hi Bill,
>>
>> On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
>> wrote:
>>>
[snip]
>>>
>>> Yes, that is the problem. I have come to the view that two 32 bit words
>>> are
>>> the best approach. Note that the lsb may actually not fill the full 32
>>> bits.
>>
>> Urghhh
>
> Hi All,
> Consider the case where we have a 16 bit counter clocked by 1.0 MHz (a
> nice number) interrupting on overflow. We could return (overflow counter <<
> 16) | hardware counter from the get_ticks routine, which maintains the
> "binaryness" of the "number".
> OTOH, suppose the counter is a down counter clocked at 1.19318 MHz with a 1
> ms period, like the PC counter is set up at present. What do we return
> then? Whatever we do, it depends on the clock rate, which may change, and
> involves some math, which may not work for all clock rates. In effect, you
> have a dual radix number. Yes, conversion is possible but it is messy and
> would be present in different forms in all the various get_tick routines.
get_ticks() does not care about the clock rate - It simply looks at the
current value of the hardware tick counter and the value of the hardware
tick counter the last time get_ticks() was called, calculates the difference
and adds that to the 64-bit software tick-counter
I don't see how it being a down counter makes that any more difficult
> This is neither simple nor maintainable. Further, it is un-necessary, as the
> sync_timer routine is just going to convert the number from whatever radix
> we converted it to into millisec. If we leave the two numbers as split, all
> that complexity is removed from get_ticks and sent upward to the common
> routine that converts the answer into ms anyway. This makes the system more
> maintainable by placing the minimum requirement on get_ticks. The "tick"
> should be opaque to anybody but sync_timebase anyway.
But how is the common routine going to know if it is a split timer, up
timer, down timer, little endian, big endian, etc, etc.
get_ticks() abstracts the hardware implementation of the hardware timer
from sync_timer()
>>>
>>> The top 32 bits are the rollover count and the bottom 32 bits are the
>>> current counter. If the counter is a full 32 bits, so much the better.
>>
>> Ah - Lets keep it that way
>>
>>> Again, one could put them together inside the interrupt routine , but it
>>> is
>>> easier to check for a changed value if you don't do this. Otherwise, you
>>> have to check both words. It also makes the isr faster. It is just an
>>
>> As I said before - Simple First, Fast Later
>
> I am in favor of simple. That is why I want get_ticks to do as little as
> possible. It should just read the hardware register and the overflow counter
> if it is separate. Make sure the overflow didn't change while we were
> reading. This is redundant if we are not using interrupts but we can leave
> the code in. It just won't do anything. We can also move the rollover
> detection to sync_timebase. It will be redundant if we are using interrupts,
> because time will never "back up". But we can do it this way. This
> centralizes the overflow detection, which is a good thing.
That does not sound simple to me. This, however, does:
u64 get_ticks(void)
{
static u64 last_hw_tick_count;
static u64 last_sw_tick_count;
/* Now for the platform specific stuff - Read hardware tick counter */
u64 current_hw_tick_count = /* Read hw registers etc */
/* Deal with hardware weirdness - errata, stupid hw engineers etc */
u64 elapsed_ticks = current_hw_tick_count - last_hw_tick_count;
last_sw_tick_count += elapsed_ticks;
return last_sw_tick_count;
}
The '/* Read hw registers etc */' bit will always be the same, no matter
what way you do it
The '/* Deal with hardware weirdness - errata, stupid hw engineers etc */'
bit is where we are truly abstracting the hardware away - This is the
bit you propose to leave mangled and deal with in sync_time? You make a
lot of assumptions about the consistency of this highly variable logic
across all current (and future) U-Boot platforms
What if the hardware engineer figures he can save a squeeze some extra
mileage out of a FPGA by implementing a 24-bit counter + 8-bit status
in one 32-bit register - get_ticks() strips all that out
You want to do some in get_ticks(), some in the ISR and some in
sync_timer() - Put all the weird stuff on one place - The HAL
>>>
>>> increment of the overflow counter, like the PPC is now. I happen to think
>>> it
>>> is easier to convert the two 32 bit words to milliseconds one at a time,
>>> but
>>> if you feel you must use 64 bit words, that is fine too. Just remember,
>>> the
>>> counter does not always fill the entire bottom word.
>>
>> Urghhh
>>
>>> In cases where there are no interrupts, get_ticks has to detect that the
>>> timer has "bac
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Thu, May 26, 2011 at 3:44 PM, Graeme Russ wrote:
> On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk wrote:
>> Dear Simon Glass,
>>
>> In message you wrote:
>>>
>>> Can we have a microsecond one also please? Some sort of microsecond
>>
>> I guess you cannot, at least not in general. In worst case that would
>> mean we have to process 1e6 interrupts per second, which leaves little
>> time for anything useful.
Sorry Wolfgang I don't really understand this. We would only process
when we read it, and then hopefully only a simple multiple or shift,
after compiler optimizations kick in. Probably I am just missing what
you are saying.
>
> If we implemented a sync_us_timer(), we could either:
>
> a) Never kick it using an interrupt at all (only kick it in udelay())
> b) Kick it in a much slower interrupt (1ms+ period)
>
> Remember, the kicking of the sync function does not need to correlate to
> the incrementing of the tick counter - Only to the roll-over period
> of the tick counter.
>
> For a 64-bit sub microsecond tick counter, interrupts will probably not
> ever be needed (unless the tick frequency is ludicrous - even a nanosecond
> tick counter will take 213 days to wrap) so in this case, sync_us_timer()
> would be fine
Hi Graeme,
Well yes, I feel that you either worry about rollover or you use
64-bits. Since you are using 64-bits it shouldn't matter.
I hope we can avoid integer division in the microsecond case. Someone
stated that time delays are the main use for the timer, but some of us
have performance-monitoring plans.
Re the atomicity of handling 64-bit numbers, how about just
disable/enable interrupts around this? I think 64-bit is overkill but
at least it is simple, and prefer a u64 to a struct { u32 lo, hi; }.
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 1/7] powerpc/i2c: introduce CONFIG_I2C_TWR for setting tWR value
Hello York,
York Sun wrote:
> From: york
>
> EEPROM requires tWR for write cycle time. Since there is no other way to
> poll if the internal programming ends, wait for 5ms which is the max timing
> for AT24C01/02/04/08/16 by default. It can be overridden by defining
> CONFIG_I2C_TWR in configuration file if the slowest device has different write
> cycle time.
>
> Signed-off-by: York Sun
> ---
> README|7 +++
> drivers/i2c/fsl_i2c.c |9 +
> 2 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/README b/README
> index 8bb9c8d..83a316c 100644
> --- a/README
> +++ b/README
> @@ -1717,6 +1717,13 @@ The following options need to be configured:
> devices can use either method, but some require one or
> the other.
>
> + CONFIG_I2C_TWR
Maybe CONFIG_SYS_I2C_EEPROM_TWR is better?
> +
> + defining this will override the default write cycle time
the default eeprom write cycle time ...
> + 5ms which is the default for AT24C01/02/4/08/16. If the
> + slowest I2C device has different write cycle time, this
> + option should be defined. The unit is microsecond.
> +
> - SPI Support: CONFIG_SPI
>
> Enables SPI driver (so far only tested with
> diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
> index cb13dee..d192b2a 100644
> --- a/drivers/i2c/fsl_i2c.c
> +++ b/drivers/i2c/fsl_i2c.c
> @@ -42,6 +42,14 @@
> #define CONFIG_I2C_TIMEOUT 1
> #endif
>
> +/*
> + * tWR is the write cycle time for EEPROM device
> + * in microseconds
> + */
> +#ifndef CONFIG_I2C_TWR
> +#define CONFIG_I2C_TWR 5000
> +#endif
> +
> #define I2C_READ_BIT 1
> #define I2C_WRITE_BIT 0
>
> @@ -416,6 +424,7 @@ i2c_write(u8 dev, uint addr, int alen, u8 *data, int
> length)
> if (i2c_wait4bus()) /* Wait until STOP */
> debug("i2c_write: wait4bus timed out\n");
>
> + udelay(CONFIG_I2C_TWR);
> if (i == length)
> return 0;
>
Hmm.. you add this timeout in the i2c driver, which will result in
adding this default 5 ms delay for *all* i2c writes, not only for
eeprom devices ... why you didn;t add this timeout in cmd_eeprom,
where it seems to me is the better place for it? Looking in this
common/cmd_eeprom.c there is a CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS
define ... is this not adequate?
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] omap4 EHCI support and SMSC95xx support on panda
On 05/26/2011 10:52 PM, Peter Meerwald wrote:
> Hello,
>
> I am trying to get tftp working on the pandaboard; I am testing Simon's v6
> patch series and Gilles EHCI patches
>
> doc/README.sub claims that the SMSC driver supports usbethaddr, I do not
> see this
>
> smsc95xx_init_mac_address() fails to get the hwaddr from eeprom and then
> it should do
> if (eth_getenv_enetaddr_by_index("usbeth", 0, eth->enetaddr)) {
> debug("MAC address read from usbethaddr\n");
> return 0;
> }
> which is missing?
>
>
> this is what I get after fixing the usbethaddr issue -- any ideas?
Hi Peter,
A few details I forgot to post it on this list: in order to get EHCI
working on Panda, I had to add the following patch on top of Simon's
patches:
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index 4d8dde0..97f2729 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -873,6 +873,7 @@ int smsc95xx_eth_get_info(struct usb_device *dev,
struct ueth_data *ss,
eth->send = smsc95xx_send;
eth->recv = smsc95xx_recv;
eth->halt = smsc95xx_halt;
+ eth->write_hwaddr = smsc95xx_write_hwaddr;
eth->priv = ss;
return 1;
}
>From the traces you show, I am not sure this is what you are missing,
though. The other "detail", is that I used the latest version of
X-loader git, it may enable some clocks that previous versions did not
enable. I would like to rebase the patches on the SPL patches posted
recently.
Regards.
--
Gilles.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] powerpc/i2c: introduce CONFIG_I2C_TWR for setting tWR value
On Fri, 2011-05-27 at 08:04 +0200, Heiko Schocher wrote: > Hmm.. you add this timeout in the i2c driver, which will result in > adding this default 5 ms delay for *all* i2c writes, not only for > eeprom devices ... why you didn;t add this timeout in cmd_eeprom, > where it seems to me is the better place for it? Looking in this > common/cmd_eeprom.c there is a CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS > define ... is this not adequate? > You are right. I overlooked CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS and should use this instead. Drop this patch, please. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On 5/26/2011 9:33 PM, Graeme Russ wrote:
> Hi Bill,
>
> get_ticks() does not care about the clock rate - It simply looks at the
> current value of the hardware tick counter and the value of the hardware
> tick counter the last time get_ticks() was called, calculates the difference
> and adds that to the 64-bit software tick-counter
> I don't see how it being a down counter makes that any more difficult
>
>> This is neither simple nor maintainable. Further, it is un-necessary, as the
>> sync_timer routine is just going to convert the number from whatever radix
>> we converted it to into millisec. If we leave the two numbers as split, all
>> that complexity is removed from get_ticks and sent upward to the common
>> routine that converts the answer into ms anyway. This makes the system more
>> maintainable by placing the minimum requirement on get_ticks. The "tick"
>> should be opaque to anybody but sync_timebase anyway.
> But how is the common routine going to know if it is a split timer, up
> timer, down timer, little endian, big endian, etc, etc.
>
> get_ticks() abstracts the hardware implementation of the hardware timer
> from sync_timer()
Hi All,
I understand your point. I prefer a higher level of abstraction.
You are correct that there are some aspects of the tick counter that are
very hardware quirky, and these attributes are hard to abstract. If the
timer is embedded into a bit field with other variables, it is
reasonable to expect get_ticks to extract the bit field and right
justify the number. If there are endian issues, the get_ticks routine
must return the number in the "natural" endianness of the platform.
However, after that point, the values are extremely "regular". The fact
that a counter is a down counter can be expressed in a data structure as
a boolean. The high limit of the hardware counter is a number. The
number of ticks per millsecond is obtainable from usec2ticks(1000), or
1 if we want to avoid some roundoff. From these values, sync_timer
can take the two part ticks value and convert it to millisec. Trust me
on this. I have the routines to do it. This puts as much of the
abstraction of the two numbers into ONE COMMON ROUTINE, sync_timer. Now
it is clearly possible to move some of the abstraction down a level into
sync_timer. For instance you could move inverting the counter down to
that level, and then multiply the msb by the maximum value of the lsb
counter and add in the msb. It is clearly possible to move ALL of
sync_timer down into get_ticks, if one wanted to. It is clearly possible
to replace general values in gd-> with platform specific constant
values. However, if you do that, you end up with a lot of duplicate, or
almost duplicate, code running around. That has proven to be error
prone, and it has left new ports of u-boot to sort of fend for
themselves in figuring out how things should work. I prefer to abstract
that all up into sync_timer. That way, all the math is in one place, and
is table driven so it is easy to change.
The top 32 bits are the rollover count and the bottom 32 bits are the
current counter. If the counter is a full 32 bits, so much the better.
>>> Ah - Lets keep it that way
>>>
Again, one could put them together inside the interrupt routine , but it
is
easier to check for a changed value if you don't do this. Otherwise, you
have to check both words. It also makes the isr faster. It is just an
>>> As I said before - Simple First, Fast Later
>> I am in favor of simple. That is why I want get_ticks to do as little as
>> possible. It should just read the hardware register and the overflow counter
>> if it is separate. Make sure the overflow didn't change while we were
>> reading. This is redundant if we are not using interrupts but we can leave
>> the code in. It just won't do anything. We can also move the rollover
>> detection to sync_timebase. It will be redundant if we are using interrupts,
>> because time will never "back up". But we can do it this way. This
>> centralizes the overflow detection, which is a good thing.
> That does not sound simple to me. This, however, does:
>
> u64 get_ticks(void)
> {
> static u64 last_hw_tick_count;
> static u64 last_sw_tick_count;
>
> /* Now for the platform specific stuff - Read hardware tick counter */
> u64 current_hw_tick_count = /* Read hw registers etc */
>
> /* Deal with hardware weirdness - errata, stupid hw engineers etc */
>
> u64 elapsed_ticks = current_hw_tick_count - last_hw_tick_count;
> last_sw_tick_count += elapsed_ticks;
>
> return last_sw_tick_count;
> }
>
> The '/* Read hw registers etc */' bit will always be the same, no matter
> what way you do it
Agree.
> The '/* Deal with hardware weirdness - errata, stupid hw engineers etc */'
> bit is where we are truly abstracting the hardware away - This is the
> bit you propose to leave mangled and deal with in sync_time?
Not totally. The get_
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On Fri, May 27, 2011 at 4:33 PM, J. William Campbell wrote: > On 5/26/2011 9:33 PM, Graeme Russ wrote: >> >> Hi Bill, >> > >> [massive snip] OK, you have my ears pricked - Can you give me code samples for: - get_ticks() - sync_timbase() (no need to implement the whole lot if that is too much effort right now) - timer_isr() that handle the following hardware tick counter scenarios: a) 64-bit up counter b) 64-bit down counter c) 32-bit up counter, wraps at 65000 d) 16-bit microsecond up counter 0-999 which wraps and triggers a 16-bit millisecond up counter. Reading milliseconds latched microseconds and clears milliseconds (look in arch/x86/cpu/sc520/timer.c for example) e) 24-bit counter occupying bits 2-25 of a 32-bit word (just to be difficult) f) Any other option anyone cares to throw ;) All of these options must be covered using: - Minimal global data (we would like it to work before relocation, but not mandatory - GD footprint would be nice) - All use the same sync_timebase function - Demonstrate using an ISR NOT synced to the hardware tick counter and an ISR that is - Parameters to get_ticks() and sync_timer() are permitted, but not for timer_isr() (naturally) > I don't' see any reason to push this down to a lower level. It is just one > more thing to get messed up across implementations. Agreed >>> detection in the non-interrupt case to sync_timebase as well. >>> Sync_timebase >>> can also invert the down-counting counters, removing that from get_ticks. >>> The wrap detection code can be #ifdef out if one is using interrupts and >> >> Urghh - Why are you adding unnecessary ugliness - #ifdef in the middle of >> code is usually a sign you are doing something wrong > > As I said, this is an optional optimization. I do not agree that an #ifdef > in the middle of code indicates you have a bad design. Lots and Lots of > ifdefs certainly indicates a bad design. An ifdef to eliminate code if some > option is not selected is hardly such a strange thing, especially only a > single #ifdef. However, feel free to not have it if you so desire. OK, I'll let this slide for the moment - please include in above example >>> offended by it's presence. Thanks for pointing this out and compelling me >>> to >>> reduce the number of cases! Making get_ticks more lightweight is a good >>> idea >>> in my opinion. Lets say you have a platform with a 32-bit tick counter running at a reasonably long rollover time so you decide not to use interrupts. Then you create a new platform with the same tick counter, but it runs much faster and you realise you need to implement the interrupt routine to make get_timer() work for long enough periods - Fine, you add an ISR for the new platform that calls sync_timebase - No other changes are required. The last thing we want is for the 64-bit tick counter to be conceptually different across platforms I just realised - the ISR _does not need to call the sync_timebase at all_ The ISR only needs to call get_ticks(), so it will be fast anyway >>> >>> The problem is that the way we previously detected wrapping does not work >>> if >>> the interrupt rate is == to the counter wrap time, which it essentially >>> always is. If get_ticks is trying to update the wrap count when an >>> interrupt >> >> Is it, always, on every platform? > > Yes, pretty much. You get a terminal count/counter underflow interrupt and > that is it. Not on sc520 - The micro/millisecond counter cannot be used to driver an interrupt - you need to setup a seperate timer. I think the x86 internal performance counters are the same >>> comes in, it will do it wrong. If the interrupt rate was faster, it would >>> work, because get_ticks would always know the correct answer. Consider >>> the >>> following. Get ticks is called by the counter overflowing (which resets >>> it >>> to 0) and executes with the counter value at 0. Later, at the next >>> rollover, >>> with no intervening calls to get ticks, the interrupt routine calls get >>> ticks. Assuming negligible interrupt latency, get_ticks just sees the >>> counter is still 0, so it will not detect a wrap condition. So now you >>> loose >> >> But wait a minute, don't you KNOW that the interrupt gets triggered on a >> rollover so therefore there MUST have been a rollover, therefore there has >> been 2^32 (or 2^16 or 2^whatever) ticks which you can just subtract from >> the >> last known tick count (which would be zero if there had been no get_timer >> calls in between) > > Except if this interrupt was delayed because get_ticks turned off > interrupts, get_ticks may have already compensated the number. When we then > get the (delayed) interrupt, we will do it twice. That would mean get_timer() got called EXACTLY on the rollover - A race condition that should be avoided. But still, a race can still occur through using disable/enable interrupts which could push the timer isr
