Re: [U-Boot] [PATCH] standalone: Increment XF_VERSION to 6
On Friday 02 October 2009 16:08:54 Peter Tyser wrote: > Signed-off-by: Peter Tyser > --- > This should be squashed with the top-most commit in the > reloc branch. if it doesnt get squashed, the changelog should mention the exact reason for bumping the version ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mem_mtest: fix error reporting, allow escape with ^C
On Friday 02 October 2009 18:18:33 Paul Gortmaker wrote: > The basic memtest function tries to watch for ^C after each > pattern pass as an escape mechanism, but if things are horribly > wrong, we'll be stuck in an inner loop flooding the console with > error messages and never check for ^C. To make matters worse, > if the user waits for all the error messages to complete, we > then incorrectly report the test passed without errors. > > Adding a check for ^C after any error is printed will give > the end user an escape mechanism from a console flood without > slowing down the overall test speed on a slow processor. > > Also, the more extensive memtest quit after just a single error, > which is inconsistent with the normal memtest, and not useful if > if you are doing dynamic environmental impact testing, such as > heating/cooling etc. > > Both tests now track the error count and report it properly > at test completion. thanks, Acked-by: Mike Frysinger -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_dos: check status flags of partitions
ping? On Mon, Sep 28, 2009 at 12:04:00PM +0200, Daniel Mack wrote: > The current fatload code has a problem together with the way the DOS > partition parser is implemented. > > This hit me when I tried to load a file from a USB stick which had no > partition table but a FAT16 directly written to the first sector. > > With such an environment, get_partition_info_extended() still finds a > valid partition at the first sector since the 0x55aa magic is valid for > both the MBR and the FAT boot sector. > > As a result, part_offset in fs/fat/fat.c is then set to some ridiculous > value and the code searching for the directory entry gets lots in an > endless loop. > > The fix is quite simple though - we just need to check the status field > of the partitions more stricly. According to the specs, it may only > contain 0x00 and 0x80. If get_partition_info() fails for this case, the > fatload code falls back to the assumption that there is no partition > table and does the right thing then. > > Please consider applying the following patch. > > Daniel > > > From 381a85bf04adc228cc70e8fa7af899a6dbf07e42 Mon Sep 17 00:00:00 2001 > From: Daniel Mack > Date: Mon, 28 Sep 2009 11:40:38 +0200 > Subject: [PATCH] part_dos: check status flags of partitions > > Only read partitions which have 0x00 or 0x80 set in their status field. > All others are invalid. > > Signed-off-by: Daniel Mack > --- > disk/part_dos.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/disk/part_dos.c b/disk/part_dos.c > index 93bf3dd..e32d58e 100644 > --- a/disk/part_dos.c > +++ b/disk/part_dos.c > @@ -188,7 +188,8 @@ static int get_partition_info_extended (block_dev_desc_t > *dev_desc, int ext_part >* fdisk does not show the extended partitions that >* are not in the MBR >*/ > - if ((pt->sys_ind != 0) && > + if (((pt->boot_ind & ~0x80) == 0) && > + (pt->sys_ind != 0) && > (part_num == which_part) && > (is_extended(pt->sys_ind) == 0)) { > info->blksz = 512; > -- > 1.6.3.3 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc83xx: cosmetic comment update relating to SPD EEPROM
commit 6d0f6bcf337c5261c08fabe12982178c2c489d76 did the big rename of CFG_ macros to CONFIG_SYS macros. But it missed a couple of instances within comments. Signed-off-by: Paul Gortmaker --- include/configs/sbc8349.h |2 +- include/configs/vme8349.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/sbc8349.h b/include/configs/sbc8349.h index bf7cf82..4dea27d 100644 --- a/include/configs/sbc8349.h +++ b/include/configs/sbc8349.h @@ -304,7 +304,7 @@ #define CONFIG_SYS_I2C1_OFFSET 0x3000 #define CONFIG_SYS_I2C2_OFFSET 0x3100 #define CONFIG_SYS_I2C_OFFSET CONFIG_SYS_I2C2_OFFSET -/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SPD_BUS_NUM... */ +/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SYS_SPD_BUS_NUM... */ /* TSEC */ #define CONFIG_SYS_TSEC1_OFFSET 0x24000 diff --git a/include/configs/vme8349.h b/include/configs/vme8349.h index d0690fe..f9db73b 100644 --- a/include/configs/vme8349.h +++ b/include/configs/vme8349.h @@ -224,7 +224,7 @@ #define CONFIG_SYS_I2C1_OFFSET 0x3000 #define CONFIG_SYS_I2C2_OFFSET 0x3100 #define CONFIG_SYS_I2C_OFFSET CONFIG_SYS_I2C1_OFFSET -/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SPD_BUS_NUM... */ +/* could also use CONFIG_I2C_MULTI_BUS and CONFIG_SYS_SPD_BUS_NUM... */ #define CONFIG_SYS_I2C_8574_ADDR2 0x20/* I2C1, PCF8574 */ -- 1.6.5.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc86xx: delete unused MPC86xx_DDR_SDRAM_CLK_CNTL define
This is an orphaned legacy leftover that is just polluting the config file namespace. Signed-off-by: Paul Gortmaker --- include/configs/MPC8610HPCD.h |2 -- include/configs/MPC8641HPCN.h |2 -- include/configs/sbc8641d.h|2 -- 3 files changed, 0 insertions(+), 6 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 7619328..7cb4ccd 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -102,8 +102,6 @@ #define CONFIG_SYS_MAX_DDR_BAT_SIZE0x8000 /* BAT mapping size */ #define CONFIG_VERY_BIG_RAM -#define MPC86xx_DDR_SDRAM_CLK_CNTL - #define CONFIG_NUM_DDR_CONTROLLERS 1 #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL (2 * CONFIG_DIMM_SLOTS_PER_CTLR) diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index b0ae25c..a46f7c8 100644 --- a/include/configs/MPC8641HPCN.h +++ b/include/configs/MPC8641HPCN.h @@ -141,8 +141,6 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_SYS_MAX_DDR_BAT_SIZE0x8000 /* BAT mapping size */ #define CONFIG_VERY_BIG_RAM -#define MPC86xx_DDR_SDRAM_CLK_CNTL - #define CONFIG_NUM_DDR_CONTROLLERS 2 #define CONFIG_DIMM_SLOTS_PER_CTLR 2 #define CONFIG_CHIP_SELECTS_PER_CTRL (2 * CONFIG_DIMM_SLOTS_PER_CTLR) diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h index 2865df5..682d241 100644 --- a/include/configs/sbc8641d.h +++ b/include/configs/sbc8641d.h @@ -121,8 +121,6 @@ #define CONFIG_SYS_MAX_DDR_BAT_SIZE0x8000 /* BAT mapping size */ #define CONFIG_VERY_BIG_RAM -#define MPC86xx_DDR_SDRAM_CLK_CNTL - #define CONFIG_NUM_DDR_CONTROLLERS 2 #define CONFIG_DIMM_SLOTS_PER_CTLR 2 #define CONFIG_CHIP_SELECTS_PER_CTRL (2 * CONFIG_DIMM_SLOTS_PER_CTLR) -- 1.6.5.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mem_mtest: fix error reporting, allow escape with ^C
The basic memtest function tries to watch for ^C after each pattern pass as an escape mechanism, but if things are horribly wrong, we'll be stuck in an inner loop flooding the console with error messages and never check for ^C. To make matters worse, if the user waits for all the error messages to complete, we then incorrectly report the test passed without errors. Adding a check for ^C after any error is printed will give the end user an escape mechanism from a console flood without slowing down the overall test speed on a slow processor. Also, the more extensive memtest quit after just a single error, which is inconsistent with the normal memtest, and not useful if if you are doing dynamic environmental impact testing, such as heating/cooling etc. Both tests now track the error count and report it properly at test completion. Signed-off-by: Paul Gortmaker --- Changes: fixed return values since prev. version. common/cmd_mem.c | 58 - 1 files changed, 44 insertions(+), 14 deletions(-) diff --git a/common/cmd_mem.c b/common/cmd_mem.c index 9850800..a34b342 100644 --- a/common/cmd_mem.c +++ b/common/cmd_mem.c @@ -631,7 +631,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) vu_long *addr, *start, *end; ulong val; ulong readback; - int rcode = 0; + ulong errs = 0; int iterations = 1; int iteration_limit; @@ -698,9 +698,9 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) if (iteration_limit && iterations > iteration_limit) { - printf("Tested %d iteration(s) without errors.\n", - iterations-1); - return 0; + printf("Tested %d iteration(s) with %lu errors.\n", + iterations-1, errs); + return errs != 0; } printf("Iteration: %6d\r", iterations); @@ -732,9 +732,14 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) *dummy = ~val; /* clear the test data off of the bus */ readback = *addr; if(readback != val) { -printf ("FAILURE (data line): " + printf ("FAILURE (data line): " "expected %08lx, actual %08lx\n", val, readback); + errs++; + if (ctrlc()) { + putc ('\n'); + return 1; + } } *addr = ~val; *dummy = val; @@ -743,6 +748,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) printf ("FAILURE (data line): " "Is %08lx, should be %08lx\n", readback, ~val); + errs++; + if (ctrlc()) { + putc ('\n'); + return 1; + } } } } @@ -808,7 +818,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) printf ("\nFAILURE: Address bit stuck high @ 0x%.8lx:" " expected 0x%.8lx, actual 0x%.8lx\n", (ulong)&start[offset], pattern, temp); - return 1; + errs++; + if (ctrlc()) { + putc ('\n'); + return 1; + } } } start[test_offset] = pattern; @@ -826,7 +840,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) printf ("\nFAILURE: Address bit stuck low or shorted @" " 0x%.8lx: expected 0x%.8lx, actual 0x%.8lx\n", (ulong)&start[offset], pattern, temp); - return 1; + errs++; + if (ctrlc()) { + putc ('\n'); + return 1; + } } } start[test_offset] = pattern; @@ -864,7 +882,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) printf ("\nFAILURE (read/write) @ 0x%.8lx:" " expected 0x%.8lx, actual 0x%.8lx)\n", (ulong)&start[offset], pattern, temp); - return 1; +
Re: [U-Boot] Preserving frame buffer memory between uboot and Linux
Dear Steven Zedeck, In message <25722060.p...@talk.nabble.com> you wrote: > > We have a situation when we want to display an image towards the end of > Uboot's execution, before we boot Linux. I have that already. > > However, my issue is that while Linux boots it mallocs a new frame buffer > and reinitializes the LCD controller with a new memory address. At the > moment in Uboot the frame buffer is at 0x23F39000. In Linux I see it being > mapped to 0x2398. > > Is there a way to force Linux to use the already-allocated frame buffer > memory so the image doesn't go away? In mainline: not, or not yet at least. In our linux-2.6-denx repo you can find these commits: commit 01baab26e52bc66cb1781ab970fba932b592f2ee Author: Anatolij Gustschin Date: Wed May 28 23:45:21 2008 +0200 Fix to enable console cursor drawing capability if CONFIG_FB_PRE_INIT_FB defined Background: By defining the CONFIG_FB_PRE_INIT_FB option in the Linux kernel configuration the framebuffer state set by the boot loader before booting the Linux kernel will be preserved in order to avoid display flicker and splash screen destruction. To ensure this, this option also disabled framebuffer console cursor drawing capability entirely. This was pretty invasive restriction and didn't allow using console cursor drawing later in applications which need the visible cursor. Now this patch is introduced to get rid of this restriction. If CONFIG_FB_PRE_INIT_FB is defined in the Linux kernel configuration, the framebuffer state will still be preserved (as set by the boot loader) and also framebuffer console cursor drawing will be disabled. If an application needs visible cursor, it should enable cursor drawing by writing escape sequence ESC[?25h to the console device. E.g. echo -e "\33[?25h" > /dev/tty0 Signed-off-by: Anatolij Gustschin ... commit 6c3b5cdbc84b43190996124debc8fb29c9bf90ed Author: Anatolij Gustschin Date: Tue Jan 15 00:28:23 2008 +0100 Add CONFIG_FB_PRE_INIT_FB option CONFIG_FB_PRE_INIT_FB option allows to inherit display controller configuration and framebuffer contents from the state set by the bootloader. Signed-off-by: Anatolij Gustschin They do exactly what you are looking for. I remember that someone tried to clean this up and poush it into mainline, but IIRC this attempt failed because the PTB considered this an exotic requirement from those insane embedded folks which was not needed on any real systems. > I am running on an Atmel AT91SAM9RL with Uboot 2008.10 and 2.6.28 Linux. Hope this helps. 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 Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, "Day of the Dove", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Dear "J. William Campbell", In message <4ac660e3.4010...@comcast.net> you wrote: > > At this point it might be appropriate to ask if including such a reset > in udelay() is a good idea. The way it is, no "infinite loop" in u-boot > that contains a udelay() will ever allow the watchdog to time out. That Indeed. We do not have any watchdog preotection for U-Boot itself. U-Boot just makes sure to allow booting an OS with the watchdog activated. > Just because the program invokes udelay, there is no assurance that > measurable progress is being made. The udelay may be part of a process > that will never complete. Therefore, having a watchdog reset in udelay > seems like a less than optimal idea in general. Maybe now would be a > good time to look at removing it? There are other places which have similar issues. For example, you will probably find that most serial drivers (at least those being used on systems with active watchdogs) will have WATCHDOG_RESET() calls in their getc() implementations - which is needed to trigger the WD while the board is in interactive mode, waiting for input. WD support in U-Boot is just good enough to bridge the time until the OS starts to do the right thing. We do not trry to WD-protect U-Boot itself yet. Implementing such protection would definitely be a good thing to have, but non-trivial effort, too. It would require much more changes than removing the trigger from the udelay() code. Please feel free to submit patches... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A door is what a dog is perpetually on the wrong side of. - Ogden Nash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] problem detecting CFI
I can fix this problem not but I really don't understand how the problem happens in the first place. I found gp got changed in relocate_code in file start.S. In relocate_code "function", the $gp is adjusted to point to the new location, but somehow before program jumps to the relocated place, $gp was changed. But I don't know where it is changed. So I used t8 register to save the adjusted gp, and put it back before it jump to DRAM. But I don't know why $gp was changed in the between. Can someone give me some idea? I did not touch any thing else in this file. /* * Fix $gp: * * New $gp = (Old $gp - CONFIG_SYS_MONITOR_BASE) + Destination Address */ movet6, gp sub gp, CONFIG_SYS_MONITOR_BASE add gp, a2 /* gp now adjusted */ movet8, gp /* add here <=== save gp */ ... /* Jump to where we've relocated ourselves. */ movegp, t8/* add here <=== copy gp back */ addit0, s2, in_ram - _start jr t0 nop On Thu, 01 Oct 2009 18:25 -0500, w...@fastmail.fm wrote: > I just found something interesting - > > In my previous email I thought the CFI detection was running from > DRAM, but that assumption seems to be wrong. Previously I though it > was running from DRAM because I traced the execution using BDI into > mips/start">cpu/mips/start.S relocate_code, it runs to the place where > it relocates itself. To be exact, here - > > addi t0, s2, in_ram - start jr t0 nop > > I checked and found the pc register changed to pointing to a SDRAM > location, so relocation seems to be fine. I also load the symbol-file > to the DRAM location at that point. But afterwards if I set breakpoint > to board_init_r, the breakpoint is not triggered. > > Then I realized if I keep using the same symbol-file, the breakpoint > at board_init_r can be triggered, and at that point, I can see the PC > is still pointing to the flash. > > I don't understand how can the code, which has been relocated to SDRAM > at one point, suddenly going back to run in the flash when it calls > board_init_r. Can someone help me? > > Thanks. > > > On Thu, 01 Oct 2009 16:47 -0500, w...@fastmail.fm wrote: > > I have a working u-boot 2008.10 on a mips 32 board and am trying to > > port it over to u-boot 2009.06. So I used buildroot 2009.08 to build > > the tool chain for my mips32 board as well as u-boot2009.06. I also > > copied the previous u-boot initialization code to initialize timer, > > serial port, ram and etc from u-boot 2008.10 to 2009.06. > > > > Right now the problem is the new u-boot 2009.06 does not detect cfi > > of the flash. I am pretty sure u-boot is running from SDRAM when the > > problem happens because the address is in the range of SDRAM. Please > > let me know if you have any suggestion - I am running out of ideas. > > I am attaching the printout from both the working u-boot 2008.10 and > > u-boot 2009.06 below. > > > > Thanks a lot. > > > > U-Boot 2009.06 (Sep 30 2009 - 18:41:26) > > > > Reset Cause: Hardware Reset DRAM: 64 MB Top of RAM usable for U- > > Boot at: 9800 Reserving 139k for U-Boot at: 97fdc000 Reserving > > 4352k for malloc() at: 97b9c000 Reserving 36 Bytes for Board Info > > at: 97b9bfdc Reserving 36 Bytes for Global Data at: 97b9bfb8 > > Reserving 128k for boot params() at: 97b7bfb8 Stack Pointer at: > > 97b7bf98 Now running in RAM - U-Boot at: 97fdc000 flash detect cfi > > not found flash detect cfi not found > > > > > > U-Boot 2008.10 (Sep 30 2009 - 11:37:03) > > > > Reset Cause: Hardware Reset DRAM: 64 MB Top of RAM usable for U- > > Boot at: 9800 Reserving 736k for U-Boot at: 97f44000 Reserving > > 4352k for malloc() at: 97b04000 Reserving 44 Bytes for Board Info > > at: 97b03fd4 Reserving 36 Bytes for Global Data at: 97b03fb0 > > Reserving 128k for boot params() at: 97ae3fb0 Stack Pointer at: > > 97ae3f98 Now running in RAM - U-Boot at: 97f44000 flash detect cfi > > fwc addr b000 cmd f0 f0 8bit x 8 bit fwc addr b000 cmd ff ff > > 8bit x 8 bit fwc addr b055 cmd 98 98 8bit x 8 bit is= cmd 51(Q) > > addr b010 is= 4f 51 fwc addr b555 cmd 98 98 8bit x 8 bit is= > > cmd 51(Q) addr b010 is= 4f 51 fwc addr b000 cmd f0 f0f0 > > 16bit x 8 bit fwc addr b000 cmd ff 16bit x 8 bit fwc addr > > b0aa cmd 98 9898 16bit x 8 bit is= cmd 51(Q) addr b020 is= > > 5151 5151 is= cmd 52(R) addr b022 is= 5252 5252 is= cmd 59(Y) > > addr b024 is= 5959 5959 device interface is 2 found port 2 chip > > 1 port 16 bits chip 8 bits > > ___ > > 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-ARM 1/4, v2] Clean-up of cpu_arm920t and cpu_arm920t_s3c24x0 code
Minkyu Kang wrote: > Dear kevin Morfitt > > sorry for blank message > > 2009/9/30 Minkyu Kang : >> Dear Kevin Morfitt >> >> 2009/9/26 kevin.morf...@fearnside-systems.co.uk >> : >>> Changes since v1: >>> - re-formatted patch to remove line wrapping >>> >>> Note that patch 2/4 of this series has not changed. >>> >>> This patch re-formats the code in cpu/arm920t and cpu/arm920t/23c24x0 in >>> preparation for changes to add support for the Embest SBC2440-II Board. >>> >>> The changes are as follows: >>> - re-indent the code using Lindent >>> - make sure register layouts are defined using a C struct >>> - replace the upper-case typedef'ed C struct names with lower case >>> non-typedef'ed ones >>> - make sure registers are accessed using the proper accessor functions >>> - run checkpatch.pl and fix any error reports >>> >>> Note that usb_ohci.c still has two lines that exceed 80 characters. This is >>> because the statements on those lines lose readability when wrapped - the >>> Linux >>> coding style guidelines allow for this. >>> >>> It assumes the following patch has been applied first: >>> - [U-Boot][PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards, >>> 05/09/2009 >>> >>> Tested on an Embest SBC2440-II Board with local u-boot patches as I don't >>> have >>> any s3c2400 or s3c2410 boards but need this patch applying before I can >>> submit >>> patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets >>> and no >>> new warnings or errors were found. >>> >>> Signed-off-by: Kevin Morfitt >>> --- >>> cpu/arm920t/s3c24x0/interrupts.c |2 +- >>> cpu/arm920t/s3c24x0/speed.c | 42 +- >>> cpu/arm920t/s3c24x0/timer.c | 74 ++- >>> cpu/arm920t/s3c24x0/usb.c| 30 +- >>> cpu/arm920t/s3c24x0/usb_ohci.c | 1268 >>> -- >>> cpu/arm920t/s3c24x0/usb_ohci.h | 187 +++--- >>> cpu/arm920t/start.S | 63 +- >>> 7 files changed, 873 insertions(+), 793 deletions(-) >>> > > I didn't see all of your patch. Here are links to the patches and notes on their states: - [U-boot] [PATCH-ARM] CONFIG_SYS_HZ change for cpu/arm920t/s3c24x0 boards: http://lists.denx.de/pipermail/u-boot/2009-September/thread.html, JP said it looked OK but needed testing, then it was tested by Wolfgang - [U-Boot] [PATCH-ARM 1/4, v2] Clean-up of cpu/arm920t and cpu/arm920t/s3c24x0 code (this patch): one comment so far (your own) - [U-Boot] [PATCH-ARM 2/4] Clean-up of s3c24x0 header files: http://lists.denx.de/pipermail/u-boot/2009-September/060111.html, no comments as yet - [U-Boot] [PATCH-ARM 3/4, v2] Clean-up of s3c24x0 drivers excluding nand driver, http://lists.denx.de/pipermail/u-boot/2009-September/061583.html, one comment by Gaye Abdoulaye Walsimou, fixed in v2 - [U-Boot] [PATCH-ARM 4/4, v2] Clean-up of s3c24x0 nand driver, http://lists.denx.de/pipermail/u-boot/2009-September/061584.html, v1 was Acked by Scott here - http://lists.denx.de/pipermail/u-boot/2009-September/060580.html > But there are remained more works for cleaning My aim is to clean up just the s3c24x0 common code so I can later add support for the Embest SBC2440-II Board. I can see that the rest of the arm920t code also needs cleaning but this would be a much bigger job and could be done later - I'd rather limit these patches to s3c24x0 code. > please use lower case name at C structure's members and functions I think I have changed all structure names to lower case in the s3c24x0 code. I also think I've changed all function names to lower case except where the change would affect too many other areas - for example, if I change get_HCLK() to get_hclk() in cpu/arm920t/s3c24x0/speed.c I'd also need to change the same in include/common.h, cpu/lh7a40x, arm920t/imx and arm1176/s3c64xx and all functions that call get_HCLK() throughout u-boot. Again, this does need doing but could be done later. Regards Kevin > > Thanks > Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Freescale MXC: NAND UnCorrectable RS-ECC Error
Thanks Magnus! > Which MXC platform are you using and does it support 4K page size? And > does mxc_nand.c support 4K page size? I am using mx35 and the NAND flash controller therein supports 4K page operations as evident from the manual. from the code in "mxc_nand.c" it looks like it checks for whether or not its a 4K page NAND and assigns a different OOB layout based on that. I am not sure as i havent gathered a full understanding of the ECC/OOB mechanism. How do we define the functions owned by the mxc_nand.c(board specific driver) and the generic driver nand_base.c or is it a layered design? Can you please elaborate on it? -Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Preserving frame buffer memory between uboot and Linux
Hi, We have a situation when we want to display an image towards the end of Uboot's execution, before we boot Linux. I have that already. However, my issue is that while Linux boots it mallocs a new frame buffer and reinitializes the LCD controller with a new memory address. At the moment in Uboot the frame buffer is at 0x23F39000. In Linux I see it being mapped to 0x2398. Is there a way to force Linux to use the already-allocated frame buffer memory so the image doesn't go away? I am running on an Atmel AT91SAM9RL with Uboot 2008.10 and 2.6.28 Linux. Thanks in advance, Steve -- View this message in context: http://www.nabble.com/Preserving-frame-buffer-memory-between-uboot-and-Linux-tp25722060p25722060.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Mike Frysinger wrote: > On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote: > >> Ingo van Lil wrote: >> >>> The CFI driver does not reset the device's watchdog, so long-running >>> flash operations will cause the watchdog timer to expire. A comment in >>> flash_status_check() suggests that udelay() is expected to reset the >>> watchdog, but I can't find any architecture where it does. >>> >> Please have a closer look, then. On PowerPC, udelay() >> ["lib_ppc/time.c"] calls wait_ticks(), which in turn >> ["lib_ppc/ticks.S"] calls WATCHDOG_RESET >> >> If this is missing in other architectures, it should be fixed at the >> root cause, i. e. in udelay() or in the respective support routines. >> > > Blackfin is missing it as well as i really had no idea it was supposed to be > there. certainly no doc states this requirement. perhaps it'd make sense to > break apart the common stuff to a common udelay() that does things like call > the watchdog and then call the implementation __udelay(). there should be at > least a doc/README.arch that includes these kind of details ... > -mike > > At this point it might be appropriate to ask if including such a reset in udelay() is a good idea. The way it is, no "infinite loop" in u-boot that contains a udelay() will ever allow the watchdog to time out. That restriction is somewhat non-obvious. I would argue that there are basically two classes of commands in u-boot, those that should execute so fast that there is no way the watchdog should be triggered, and commands that may take "a long time" during which the watchdog may erroneously be triggered if there is no provision made to reset it. In the second case, the resetting of the watchdog must be placed where "measurable progress" towards command completion is being made, i.e. there is a certainty that we are getting closer to a command complete. Just because the program invokes udelay, there is no assurance that measurable progress is being made. The udelay may be part of a process that will never complete. Therefore, having a watchdog reset in udelay seems like a less than optimal idea in general. Maybe now would be a good time to look at removing it? Bill Campbell > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] standalone: Increment XF_VERSION to 6
Signed-off-by: Peter Tyser --- This should be squashed with the top-most commit in the reloc branch. Ideally we could fold "[PATCH/RFC] arm/microblaze/nios/nios2/sh: Remove relocation fixups" into the reloc branch too so we don't have to increment XF_VERSION again in the next release. I have no way of testing these arches though include/exports.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/exports.h b/include/exports.h index 16ea03a..2e8fd8b 100644 --- a/include/exports.h +++ b/include/exports.h @@ -47,7 +47,7 @@ enum { XF_MAX }; -#define XF_VERSION 5 +#define XF_VERSION 6 #if defined(CONFIG_I386) extern gd_t *global_data; -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Dear Mike Frysinger, In message <200910021431.23079.vap...@gentoo.org> you wrote: > > Blackfin is missing it as well as i really had no idea it was supposed to be > there. certainly no doc states this requirement. perhaps it'd make sense to > break apart the common stuff to a common udelay() that does things like call > the watchdog and then call the implementation __udelay(). there should be at > least a doc/README.arch that includes these kind of details ... Agreed - we should start and collect such documentation about internal data structures, APIs, "expectations" of the code and the like to the wiki. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The heart is not a logical organ. -- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
On Friday 02 October 2009 08:30:51 Wolfgang Denk wrote: > Ingo van Lil wrote: > > The CFI driver does not reset the device's watchdog, so long-running > > flash operations will cause the watchdog timer to expire. A comment in > > flash_status_check() suggests that udelay() is expected to reset the > > watchdog, but I can't find any architecture where it does. > > Please have a closer look, then. On PowerPC, udelay() > ["lib_ppc/time.c"] calls wait_ticks(), which in turn > ["lib_ppc/ticks.S"] calls WATCHDOG_RESET > > If this is missing in other architectures, it should be fixed at the > root cause, i. e. in udelay() or in the respective support routines. Blackfin is missing it as well as i really had no idea it was supposed to be there. certainly no doc states this requirement. perhaps it'd make sense to break apart the common stuff to a common udelay() that does things like call the watchdog and then call the implementation __udelay(). there should be at least a doc/README.arch that includes these kind of details ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ppc4xx: Rework cmd reginfo
The command "reginfo" got an overhaul for the ppc4xx. It dumps all the relevant HW configuration registers (address, symbolic name, content). This allows to easily detect errors in *.h files and changes in the HW configuration. Signed-off-by: Niklaus Giger --- common/cmd_reginfo.c | 158 +- cpu/ppc4xx/Makefile |4 + cpu/ppc4xx/reginfo.c | 369 ++ 3 files changed, 377 insertions(+), 154 deletions(-) create mode 100644 cpu/ppc4xx/reginfo.c diff --git a/common/cmd_reginfo.c b/common/cmd_reginfo.c index d0ebd0f..89fd9ec 100644 --- a/common/cmd_reginfo.c +++ b/common/cmd_reginfo.c @@ -25,8 +25,8 @@ #include #if defined(CONFIG_8xx) #include -#elif defined (CONFIG_405GP) || defined(CONFIG_405EP) -#include +#elif defined (CONFIG_4xx) +extern void ppc4xx_reginfo(void); #elif defined (CONFIG_5xx) #include #elif defined (CONFIG_MPC5200) @@ -90,158 +90,8 @@ int do_reginfo (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]) * May be some CPM info here? */ -#elif defined (CONFIG_405GP) - printf ("\n405GP registers; MSR=%08x\n",mfmsr()); - printf ("\nUniversal Interrupt Controller Regs\n" - "UIC0SRUIC0ERUIC0CRUIC0PRUIC0TRUIC0MSR UIC0VR UIC0VCR" - "\n" - "%08x %08x %08x %08x %08x %08x %08x %08x\n", - mfdcr(UIC0SR), - mfdcr(UIC0ER), - mfdcr(UIC0CR), - mfdcr(UIC0PR), - mfdcr(UIC0TR), - mfdcr(UIC0MSR), - mfdcr(UIC0VR), - mfdcr(UIC0VCR)); - - puts ("\nMemory (SDRAM) Configuration\n" - "besrabesrsa besrbbesrsb bear mcopt1 rtr pmit\n"); - - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESR0); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESRS0);printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESR1); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BESRS1);printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_BEAR); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_CFG); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_RTR); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_PMIT); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - - puts ("\n" - "mb0cfmb1cfmb2cfmb3cfsdtr1ecccfeccerr\n"); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B0CR); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B1CR); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B2CR); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_B3CR); printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_TR);printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_ECCCFG);printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - mtdcr(SDRAM0_CFGADDR,SDRAM0_ECCESR);printf ("%08x ", mfdcr(SDRAM0_CFGDATA)); - - printf ("\n\n" - "DMA Channels\n" - "DMASRDMASGC DMAADR\n" - "%08x %08x %08x\n" - "dmacr_0 dmact_0 dmada_0 dmasa_0 dmasb_0\n" - "%08x %08x %08x %08x %08x\n" - "dmacr_1 dmact_1 dmada_1 dmasa_1 dmasb_1\n" - "%08x %08x %08x %08x %08x\n", - mfdcr(DMASR), mfdcr(DMASGC),mfdcr(DMAADR), - mfdcr(DMACR0), mfdcr(DMACT0),mfdcr(DMADA0), mfdcr(DMASA0), mfdcr(DMASB0), - mfdcr(DMACR1), mfdcr(DMACT1),mfdcr(DMADA1), mfdcr(DMASA1), mfdcr(DMASB1)); - - printf ( - "dmacr_2 dmact_2 dmada_2 dmasa_2 dmasb_2\n" "%08x %08x %08x %08x %08x\n" - "dmacr_3 dmact_3 dmada_3 dmasa_3 dmasb_3\n" "%08x %08x %08x %08x %08x\n", - mfdcr(DMACR2), mfdcr(DMACT2),mfdcr(DMADA2), mfdcr(DMASA2), mfdcr(DMASB2), - mfdcr(DMACR3), mfdcr(DMACT3),mfdcr(DMADA3), mfdcr(DMASA3), mfdcr(DMASB3) ); - - puts ("\n" - "External Bus\n" - "PBEARPBESR0 PBESR1 EBC0_CFG\n"); - mtdcr(EBC0_CFGADDR,PBEAR); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PBESR0); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PBESR1); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,EBC0_CFG); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - - puts ("\n" - "PB0CRPB0APPB1CRPB1APPB2CRPB2APPB3CR PB3AP\n"); - mtdcr(EBC0_CFGADDR,PB0CR); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB0AP); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB1CR); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB1AP); printf ("%08x ", mfdcr(EBC0_CFGDATA)); - mtdcr(EBC0_CFGADDR,PB2CR); printf ("%08x ", mfdcr(
[U-Boot] [PATCH 1/4] ppc4xx: Cleanup some HW register names
Signed-off-by: Niklaus Giger --- include/4xx_i2c.h |2 +- include/ppc405.h |4 +- include/ppc440.h | 179 ++-- include/ppc4xx_enet.h | 220 + 4 files changed, 216 insertions(+), 189 deletions(-) diff --git a/include/4xx_i2c.h b/include/4xx_i2c.h index f0e772c..070657f 100644 --- a/include/4xx_i2c.h +++ b/include/4xx_i2c.h @@ -63,7 +63,7 @@ #define IIC_EXTSTS (I2C_REGISTERS_BASE_ADDRESS+IICEXTSTS) #define IIC_LSADR (I2C_REGISTERS_BASE_ADDRESS+IICLSADR) #define IIC_HSADR (I2C_REGISTERS_BASE_ADDRESS+IICHSADR) -#define IIC_CLKDIV (I2C_REGISTERS_BASE_ADDRESS+IICCLKDIV) +#define IIC_CLKDIV (I2C_REGISTERS_BASE_ADDRESS+IIC0_CLKDIV) #define IIC_INTRMSK(I2C_REGISTERS_BASE_ADDRESS+IICINTRMSK) #define IIC_XFRCNT (I2C_REGISTERS_BASE_ADDRESS+IICXFRCNT) #define IIC_XTCNTLSS (I2C_REGISTERS_BASE_ADDRESS+IICXTCNTLSS) diff --git a/include/ppc405.h b/include/ppc405.h index 5e56897..4c62249 100644 --- a/include/ppc405.h +++ b/include/ppc405.h @@ -578,7 +578,7 @@ #defineIICEXTSTS 0x09 #defineIICLSADR0x0A #defineIICHSADR0x0B -#defineIICCLKDIV 0x0C +#defineIIC0_CLKDIV 0x0C #defineIICINTRMSK 0x0D #defineIICXFRCNT 0x0E #defineIICXTCNTLSS 0x0F @@ -760,7 +760,7 @@ #define CPR0_PLLD 0x060 #define CPR0_CPUD 0x080 #define CPR0_PLBD 0x0a0 -#define CPR0_OPBD 0x0c0 +#define CPR0_OPBD0 0x0c0 #define CPR0_PERD 0x0e0 #define SDR0_PINSTP0x0040 diff --git a/include/ppc440.h b/include/ppc440.h index 378a9de..9299a71 100644 --- a/include/ppc440.h +++ b/include/ppc440.h @@ -60,9 +60,9 @@ /* values for clkcfga register - indirect addressing of these regs */ #define CPR0_PLLC 0x0040 #define CPR0_PLLD 0x0060 -#define CPR0_PRIMAD0x0080 -#define CPR0_PRIMBD0x00a0 -#define CPR0_OPBD 0x00c0 +#define CPR0_PRIMAD0 0x0080 +#define CPR0_PRIMBD0 0x00a0 +#define CPR0_OPBD0 0x00c0 #define CPR0_PERD 0x00e0 #define CPR0_MALD 0x0100 #define CPR0_SPCID 0x0120 @@ -100,7 +100,7 @@ #define SDR0_PFC1 0x4101 /* Pin Function 1 */ #define SDR0_MFR 0x4300 /* SDR0_MFR reg */ -#ifdef CONFIG_440GX +#if defined(CONFIG_440GX) #define SD0_AMP0x0240 #define SDR0_XPLLC 0x01c1 #define SDR0_XPLLD 0x01c2 @@ -1319,6 +1319,19 @@ #define SDR0_MFR_PKT_REJ_POL 0x0008 /* Packet Reject Polarity */ #endif + +#if defined(CONFIG_440EPX) +#define CPM0_ER0x00B0 +#define CPM1_ER0x00F0 +#define PLB4A0_ACR 0x0081 +#define PLB4A1_ACR 0x0089 +#define PLB3A0_ACR 0x0077 +#define OPB2PLB40_BCTRL0x0350 +#define P4P3BO0_CFG0x0026 +#define SPI0_MODE 0xEF600090 /* SPI Mode Regsgiter */ + +#endif + #if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) #define SDR0_PFC1_EPS_ENCODE(n)unsigned long)(n))&0x07)<<22) #define SDR0_PFC1_EPS_DECODE(n)unsigned long)(n))>>22)&0x07) @@ -1385,6 +1398,12 @@ #define SDR0_SRST1_FPU 0x4000 /* Floating Point Unit */ #define SDR0_SRST1_KASU00x2000 /* Kasumi Engine */ +#define SDR0_EMAC0RXST 0x4301 /* */ +#define SDR0_EMAC0TXST 0x4302 /* */ +#define SDR0_CRYP0 0x4500 +#define SDR0_EBC0 0x0100 +#define SDR0_SDSTP20x4001 +#define SDR0_SDSTP30x4001 #elif defined(CONFIG_460EX) || defined(CONFIG_460GT) #define SDR0_SRST0 SDR0_SRST /* for compatability reasons */ @@ -1586,7 +1605,7 @@ #define IICEXTSTS 0x09 #define IICLSADR 0x0A #define IICHSADR 0x0B -#define IICCLKDIV 0x0C +#define IIC0_CLKDIV0x0C #define IICINTRMSK 0x0D #define IICXFRCNT 0x0E #define IICXTCNTLSS0x0F @@ -1595,10 +1614,10 @@ /*- | PCI Internal Registers et. al. (accessed via plb) +*/ -#define PCIX0_CFGADR (CONFIG_SYS_PCI_BASE + 0x0ec0) -#define PCIX0_CFGDATA (CONFIG_SYS_PCI_BASE + 0x0ec4) -#define PCIX0_CFGBASE (CONFIG_SYS_PCI_BASE + 0x0ec8) -#define PCIX0_IOBASE (CONFIG_SYS_PCI_BASE + 0x0800) +#define PCIL0_CFGADR (CONFIG_SYS_PCI_BASE + 0x0ec0) +#define PCIL0_CFGDATA (CONFIG_SYS_PCI_BASE + 0x0ec4) +#define PCIL0_CFGBASE (CONFIG_SYS_PCI_BASE + 0x0ec8) +#define PCIL0_IOBASE (CONFIG_SYS_PCI_BASE + 0x0800) #if defined(CONFIG_440EP) || defined(CONFIG_440GR) || \ defined(CONFIG_440EPX) || defined(CONFIG_440GRX) @@ -1608,82 +1627,
[U-Boot] [PATCH 0/4] ppc4xx: Overhaul for cmd reginfo
The command "reginfo" got an overhaul for the ppc4xx. It dumps all the relevant HW configuration registers (address, symbolic name, content). This allows to easily detect errors in *.h files and changes in the HW configuration. It is split in the following parts: - Cleanup some HW register names: Here you find all the changes in the include directory for new register names and adapting other ones to the names used by AMCC in their manuals, e.g. For 440EPx/GRPPC440EPx/GRX, Revision 1.15 â September 22, 2008 For PPC405GP Embedded Processor, Revision 1.02 â March 22, 2006 - Apply new HW register names Modify all existing *.c files to use the new register names. - Rework cmd reginfo Here the real work done to improve the reginfo command. - respect 80-chars per line in ppc*.h files After running checkstyle.pl on the three previous patches I noted that in the *.h files there were a lot of long lines. This patch solves this problem. I tested the changes on my PPC405GPr board HCU4 and PPC440EPx board HCU5. Only ran MAKEALL 4xx as I have no other cross-compilers installed. As I had not time to consult the documentation of all PPC440 variants (not have I boards to test it) the code in reginfo will probably dump less registers for none PPC440EPx variants. The DMA-registers are not dumped for the PPC440. I know that I could spend not only many hours but weeks to cleanup all the PPC4xx register naming conventions. I did not feel it my responsability to bring the lines in all 4xx board specific code to fit into 80 chars. But I think I will have soon a look at all the common 4xx files to bring them in shape as I would really like that a tool like checkstyle.pl from the Linux kernel only reports my errors. Niklaus Giger (4): ppc4xx: Cleanup some HW register names ppc_4xx: Apply new HW register names ppc4xx: Rework cmd reginfo ppc4xx: respect 80-chars per line in ppc*.h files board/amcc/bamboo/bamboo.c| 32 +- board/amcc/canyonlands/canyonlands.c | 22 +- board/amcc/ebony/ebony.c | 22 +- board/amcc/katmai/katmai.c| 22 +- board/amcc/luan/epld.h| 22 +- board/amcc/luan/luan.c| 22 +- board/amcc/ocotea/ocotea.c| 22 +- board/amcc/sequoia/sequoia.c | 28 +- board/amcc/taishan/showinfo.c | 112 ++-- board/amcc/taishan/taishan.c | 22 +- board/amcc/yosemite/yosemite.c| 32 +- board/amcc/yucca/yucca.c | 22 +- board/esd/common/cmd_loadpci.c|2 +- board/esd/du440/du440.c | 28 +- board/esd/pmc440/cmd_pmc440.c | 10 +- board/esd/pmc440/pmc440.c | 32 +- board/exbitgen/init.S |4 +- board/gdsys/gdppc440etx/gdppc440etx.c | 32 +- board/gdsys/intip/intip.c | 22 +- board/korat/korat.c | 28 +- board/lwmon5/lwmon5.c | 32 +- board/netstal/hcu5/hcu5.c | 28 +- board/pcs440ep/pcs440ep.c | 32 +- board/prodrive/alpr/alpr.c| 52 +- board/prodrive/p3p440/p3p440.c| 22 +- board/sandburst/common/ppc440gx_i2c.h |2 +- board/sandburst/common/sb_common.c| 22 +- board/xes/xpedite1000/xpedite1000.c | 24 +- common/cmd_reginfo.c | 158 + cpu/ppc4xx/4xx_pci.c | 48 +- cpu/ppc4xx/Makefile |4 + cpu/ppc4xx/cpu_init.c |4 +- cpu/ppc4xx/miiphy.c | 24 +- cpu/ppc4xx/reginfo.c | 369 + cpu/ppc4xx/speed.c|6 +- drivers/net/4xx_enet.c| 100 ++-- include/4xx_i2c.h |2 +- include/ppc405.h | 530 +++--- include/ppc440.h | 1401 +++-- include/ppc4xx.h | 36 +- include/ppc4xx_enet.h | 314 post/cpu/ppc4xx/ether.c | 50 +- 42 files changed, 2108 insertions(+), 1690 deletions(-) create mode 100644 cpu/ppc4xx/reginfo.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] ppc4xx: Overhaul for cmd reginfo
The command "reginfo" got an overhaul for the ppc4xx. It dumps all the relevant HW configuration registers (address, symbolic name, content). This allows to easily detect errors in *.h files and changes in the HW configuration. It is split in the following parts: - Cleanup some HW register names: Here you find all the changes in the include directory for new register names and adapting other ones to the names used by AMCC in their manuals, e.g. For 440EPx/GRPPC440EPx/GRX, Revision 1.15 â September 22, 2008 For PPC405GP Embedded Processor, Revision 1.02 â March 22, 2006 - Apply new HW register names Modify all existing *.c files to use the new register names - Rework cmd reginfo Here the real work done to improve the reginfo command. - respect 80-chars per line in ppc*.h files After running checkstyle.pl on the three previous patches I noted that in the *.h files there were a lot of long lines. This patch solves this problem. I tested the changes on my PPC405GPr board HCU4 and PPC440EPx board HCU5. Only ran MAKEALL 4xx as I have no other cross-compilers installed. The DMA-registers are not dumped for the PPC440. I know that I could spend not only many hours but weeks to cleanup all the PPC4xx register naming conventions. Niklaus Giger (4): ppc4xx: Cleanup some HW register names ppc_4xx: Apply new HW register names ppc4xx: Rework cmd reginfo ppc4xx: respect 80-chars per line in ppc*.h files board/amcc/bamboo/bamboo.c| 32 +- board/amcc/canyonlands/canyonlands.c | 22 +- board/amcc/ebony/ebony.c | 22 +- board/amcc/katmai/katmai.c| 22 +- board/amcc/luan/epld.h| 22 +- board/amcc/luan/luan.c| 22 +- board/amcc/ocotea/ocotea.c| 22 +- board/amcc/sequoia/sequoia.c | 28 +- board/amcc/taishan/showinfo.c | 112 ++-- board/amcc/taishan/taishan.c | 22 +- board/amcc/yosemite/yosemite.c| 32 +- board/amcc/yucca/yucca.c | 22 +- board/esd/common/cmd_loadpci.c|2 +- board/esd/du440/du440.c | 28 +- board/esd/pmc440/cmd_pmc440.c | 10 +- board/esd/pmc440/pmc440.c | 32 +- board/exbitgen/init.S |4 +- board/gdsys/gdppc440etx/gdppc440etx.c | 32 +- board/gdsys/intip/intip.c | 22 +- board/korat/korat.c | 28 +- board/lwmon5/lwmon5.c | 32 +- board/netstal/hcu5/hcu5.c | 28 +- board/pcs440ep/pcs440ep.c | 32 +- board/prodrive/alpr/alpr.c| 52 +- board/prodrive/p3p440/p3p440.c| 22 +- board/sandburst/common/ppc440gx_i2c.h |2 +- board/sandburst/common/sb_common.c| 22 +- board/xes/xpedite1000/xpedite1000.c | 24 +- common/cmd_reginfo.c | 158 + cpu/ppc4xx/4xx_pci.c | 48 +- cpu/ppc4xx/Makefile |4 + cpu/ppc4xx/cpu_init.c |4 +- cpu/ppc4xx/miiphy.c | 24 +- cpu/ppc4xx/reginfo.c | 369 + cpu/ppc4xx/speed.c|6 +- drivers/net/4xx_enet.c| 100 ++-- include/4xx_i2c.h |2 +- include/ppc405.h | 530 +++--- include/ppc440.h | 1401 +++-- include/ppc4xx.h | 36 +- include/ppc4xx_enet.h | 314 post/cpu/ppc4xx/ether.c | 50 +- 42 files changed, 2108 insertions(+), 1690 deletions(-) create mode 100644 cpu/ppc4xx/reginfo.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Freescale MXC: NAND UnCorrectable RS-ECC Error
Hi 2009/10/2 alfred steele : > Hi All, > > I am trying to introduce a Samsung NAND flash part (K9F8G08U0M) to a > Freescale mxc platform. Looks like the device code used in the NAND > "read id" operation is already a part of the > drivers/mtd/nand/nand_ids.c, looking at line "{"NAND 1GiB 3,3V 8-bit", > 0xD3, 0, 1024, 0, LP_OPTIONS},) Its different in the sense that it > has a page size of 4K but the code specific to 4k page size handling > seems to be there in the code > > After booting out of RAM, i am getting "UnCorrectable RS-ECC Error" > during an initial page read operation. > > Am i missing something related to spare area/OOB. > Please let me know the fastest path to or get around or debug this issue. Which MXC platform are you using and does it support 4K page size? And does mxc_nand.c support 4K page size? /Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Freescale MXC: NAND UnCorrectable RS-ECC Error
Hi All, I am trying to introduce a Samsung NAND flash part (K9F8G08U0M) to a Freescale mxc platform. Looks like the device code used in the NAND "read id" operation is already a part of the drivers/mtd/nand/nand_ids.c, looking at line "{"NAND 1GiB 3,3V 8-bit", 0xD3, 0, 1024, 0, LP_OPTIONS},) Its different in the sense that it has a page size of 4K but the code specific to 4k page size handling seems to be there in the code After booting out of RAM, i am getting "UnCorrectable RS-ECC Error" during an initial page read operation. Am i missing something related to spare area/OOB. Please let me know the fastest path to or get around or debug this issue. NAND: UnCorrectable RS-ECC Error Bad block table found at page 262080, version 0x01 UnCorrectable RS-ECC Error UnCorrectable RS-ECC Error Bad block table found at page 262016, version 0x01 UnCorrectable RS-ECC Error UnCorrectable RS-ECC Error nand_read_bbt: Bad block at 0x1e08 nand_read_bbt: Bad block at 0x1e0c nand_read_bbt: Bad block at 0x1e30 nand_read_bbt: Bad block at 0x1e34 nand_read_bbt: Bad block at 0x2334 nand_read_bbt: Bad block at 0x3694 nand_read_bbt: Bad block at 0x3698 nand_read_bbt: Bad block at 0x369c nand_read_bbt: Bad block at 0x36a0 nand_read_bbt: Bad block at 0x3ad0 nand_read_bbt: Bad block at 0x3ad4 nand_read_bbt: Bad block at 0x3ad8 nand_read_bbt: Bad block at 0x3f70 nand_read_bbt: Bad block at 0x3f74 nand_read_bbt: Bad block at 0x3f80 nand_read_bbt: Bad block at 0x3f84 nand_read_bbt: Bad block at 0x3f88 nand_read_bbt: Bad block at 0x3f90 nand_read_bbt: Bad block at 0x3f9c nand_read_bbt: Bad block at 0x3fa4 nand_read_bbt: Bad block at 0x3fa8 nand_read_bbt: Bad block at 0x3fac nand_read_bbt: Bad block at 0x3fb0 nand_read_bbt: Bad block at 0x3fb4 nand_read_bbt: Bad block at 0x3fb8 nand_read_bbt: Bad block at 0x3fc4 nand_read_bbt: Bad block at 0x3fc8 nand_read_bbt: Bad block at 0x3fd0 nand_read_bbt: Bad block at 0x3fd4 nand_read_bbt: Bad block at 0x3fe8 nand_read_bbt: Bad block at 0x3ff0 nand_read_bbt: Bad block at 0x3ff4 nand_read_bbt: Bad block at 0x3ff8 nand_read_bbt: Bad block at 0x3ffc 1024 MiB My gdb backtrace if it helps at all: (gdb) bt #0 mxc_nand_ecc_status (mtd=) at mxc_nand.c:272 #1 0x87f0bfb0 in mxc_nand_command (mtd=0x87f29c90, command=0, column=0, page_addr=0) at mxc_nand.c:924 #2 0x87f08dd0 in nand_do_read_ops (mtd=0x87f29c90, from=, ops=0x87f29e18) at nand_base.c:1197 #3 0x87f09a64 in nand_read (mtd=0x1000, from=13310103653403, len=2280692324, retlen=0x87e5fef4, buf=0x87e627b8 '�' ...) at nand_base.c:1319 #4 0x87f13d18 in readenv (offset=262144, buf=0x87e627b8 '�' ...) at u-boot/include/nand.h:41 #5 0x87f13d88 in env_relocate_spec () at env_nand.c:349 #6 0x87f13b58 in env_relocate () at env_common.c:264 #7 0x87f01874 in start_armboot () at board.c:357 #8 0x8c18 in ?? () Thanks, Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Make arm926ejs use -mabi=apcs-gnu to avoid EABI problems
On Thu, 01 Oct 2009 20:27:11 +0200 Wolfgang Denk wrote: > > > > > -PLATFORM_CPPFLAGS += -march=armv5te > > > > > +PLATFORM_CPPFLAGS += -march=armv5te -mabi=apcs-gnu > > I have to admit that I really hesitate ifwe should add this - the > longer I think about it, the more I tend to say no. > > I call upon everybody who has some time and resources and who is able > to reproduce the problem (so far I was not) to help and dig into this, > so we can understand what's going on, and finally fix the cause of the > problem, instead of trying to hush it up. OK, I understand. I meant to take a look at this today again, but got busy with other things. I'll try to get some time for this again next week. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM646x: Adding initial support for DM6467 EVM
Paulraj, Sandeep wrote: > > >>> + >>> +/* SoC Configuration */ >>> +#define CONFIG_ARM926EJS /* arm926ejs CPU */ >>> +#define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 >>> */ >> Is there a logical register #define you could use instead of the magic >> number? > > I can include the hardware.h and get the value from there, but the way the > hardware.h for DaVinci has evolved over the years, including it in the config > will result in compilation failure. > I'll add this to my TODO list and send in a patch to clean up for all DaVinci > SOC's the moment I get some free cycles. > That is fine. >>> + >>> +/* I2C Configuration */ >>> +#define CONFIG_HARD_I2C >>> +#define CONFIG_DRIVER_DAVINCI_I2C >>> +#define CONFIG_SYS_I2C_SPEED 8 >> This speed is unusual. > > The same speed has been used with a slightly older version of U-boot and has > worked fine > >> davinci_sonata.h has a comment that it had a silicon bug with 100k >> Could the same comment be applied here ? > > I don't believe so Ok fine as-is. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM646x: Adding initial support for DM6467 EVM
> > Patches will also be sent to enable EMAC, NAND and other features. > > Makefile|3 + > > Needs an addition to MAKEALL and optionally Maintainers Ok I will add > > diff --git a/include/configs/davinci_dm6467evm.h > b/include/configs/davinci_dm6467evm.h > > new file mode 100644 > > index 000..c23d533 > > --- /dev/null > > +++ b/include/configs/davinci_dm6467evm.h > > @@ -0,0 +1,131 @@ > > +/* > > + * Copyright (C) 2009 Texas Instruments Incorporated - > http://www.ti.com/ > > Above copyright did not have the http. > You should be consistent. > Add or remove, your choice. Ok I will rectify > > + > > +/* SoC Configuration */ > > +#define CONFIG_ARM926EJS /* arm926ejs CPU */ > > +#define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 > > */ > > Is there a logical register #define you could use instead of the magic > number? I can include the hardware.h and get the value from there, but the way the hardware.h for DaVinci has evolved over the years, including it in the config will result in compilation failure. I'll add this to my TODO list and send in a patch to clean up for all DaVinci SOC's the moment I get some free cycles. > > + > > +/* I2C Configuration */ > > +#define CONFIG_HARD_I2C > > +#define CONFIG_DRIVER_DAVINCI_I2C > > +#define CONFIG_SYS_I2C_SPEED 8 > > This speed is unusual. The same speed has been used with a slightly older version of U-boot and has worked fine > davinci_sonata.h has a comment that it had a silicon bug with 100k > Could the same comment be applied here ? I don't believe so > > +/* U-Boot general configuration */ > > +#undef CONFIG_USE_IRQ /* No IRQ/FIQ in U-Boot > > */ > > There is a TAB between #undef and CONFIG_USB_IRQ. > Other undef's here use a space. Ok will fix. > > > > +#define CONFIG_BOOTDELAY 3 > > +#define CONFIG_BOOTFILE"uImage"/* Boot file name */ > > +#define CONFIG_SYS_PROMPT "DM6467 EVM > " /* Monitor Command Prompt > */ > > +#define CONFIG_SYS_CBSIZE 1024/* Console I/O Buffer Size */ > > +#define CONFIG_SYS_PBSIZE \ > > + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) > > +#define CONFIG_SYS_MAXARGS 16 > > +#define CONFIG_VERSION_VARIABLE > > +#define CONFIG_AUTO_COMPLETE > > +#define CONFIG_SYS_HUSH_PARSER > > +#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > > +#define CONFIG_CMDLINE_EDITING > > +#define CONFIG_SYS_LONGHELP > > +#define CONFIG_CRC32_VERIFY > > +#define CONFIG_MX_CYCLIC > > +#define CONFIG_BOOTCOMMAND "source 0x8208; dhcp; bootm" > > 3 spaces at the end of CONFIG_BOOTCOMMAND can be removed. Will fix > Tom Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: DaVinci DM365: Flag for updated EMAC driver.
s-paul...@ti.com wrote: > From: Sandeep Paulraj > > The flag "CONFIG_DAVINCI_EMAC_VERSION2" is used by > the DaVinci EMAC driver to differentiate between > different versions of the IP. > > Signed-off-by: Sandeep Paulraj > --- > include/configs/davinci_dm365evm.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/include/configs/davinci_dm365evm.h > b/include/configs/davinci_dm365evm.h > index 2797f82..643d26c 100644 > --- a/include/configs/davinci_dm365evm.h > +++ b/include/configs/davinci_dm365evm.h > @@ -57,6 +57,7 @@ > > /* Network Configuration */ > #define CONFIG_DRIVER_TI_EMAC > +#define CONFIG_DAVINCI_EMAC_VERSION2 > #define CONFIG_MII > #define CONFIG_BOOTP_DEFAULT > #define CONFIG_BOOTP_DNS This is fine if you do not change the logic in the previous patch which would require this to change to #define CONFIG_DAVINCI_EMAC_VERSION 2 Either way is fine. Ack Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Fix msg "initialization as root-complex failed" upon PCIe scan
Hi Wolfgang, On Friday 02 October 2009 14:41:58 Wolfgang Denk wrote: > But looking at this patch, it seems that larger parts in this > (supposedly) board-specific code are actually more or less identical. > > Should we not factor out such common code? Yes, this could (should) be done. But there are differences in these board specific functions. This consolidation could introduce new errors/bugs. And I didn't want to do such a thing, now that the merge window is closed. And frankly, I don't have the time for such a cleanup right now. But I'll put this on my to-do list. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI: DaVinci: Updating EMAC driver for DM365 and DM646x
s-paul...@ti.com wrote: > From: Sandeep Paulraj > > The EMAC IP on DM365 and DM646x is slightly different from > that on DM644x. This patch updates the DaVinci EMAC driver > so that EMAC becomes operational on DM365 in U-Boot. > A flag 'CONFIG_DAVINCI_EMAC_VERSION2' is used in the driver. > This flag will need to be defined in the DM365 config file. > > Signed-off-by: Sandeep Paulraj > --- > The same modifications work on DM646x in a slightly older version > of U-Boot. So when enabled this should work on the DM6467 EVM as well. > This has at this point of time not been tested on the DM6467 in the latest > version of U-Boot. > drivers/net/davinci_emac.c | 79 ++- > 1 files changed, 77 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c > index fa8cee4..0d61c91 100644 > --- a/drivers/net/davinci_emac.c > +++ b/drivers/net/davinci_emac.c > @@ -107,6 +107,33 @@ static void davinci_eth_mdio_enable(void) > while (adap_mdio->CONTROL & MDIO_CONTROL_IDLE) {;} checkpatch complains here. infinite loop statement should be on the next line. ERROR: trailing statements should be on next line #44: FILE: drivers/net/davinci_emac.c:119: + while ((adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) != 0); > } > > +/* Read a PHY register via MDIO inteface */ > +static int mdio_read(int phy_addr, int reg_num) > +{ > + adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO | > + MDIO_USERACCESS0_WRITE_READ | > + ((reg_num & 0x1F) << 21) | > + ((phy_addr & 0x1F) << 16); > + > + /* Wait for command to complete */ > + while ((adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) != 0); > + > + return adap_mdio->USERACCESS0 & 0x; > +} > + > +/* Write to a PHY register via MDIO inteface */ > +void mdio_write(int phy_addr, int reg_num, unsigned int data) > +{ > + /* Wait for User access register to be ready */ > + while ((adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) != 0); checkpatch complains here. infinite loop statement should be on the next line. ERROR: trailing statements should be on next line #53: FILE: drivers/net/davinci_emac.c:128: + while ((adap_mdio->USERACCESS0 & MDIO_USERACCESS0_GO) != 0); > + > + adap_mdio->USERACCESS0 = MDIO_USERACCESS0_GO | > + MDIO_USERACCESS0_WRITE_WRITE | > + ((reg_num & 0x1F) << 21) | > + ((phy_addr & 0x1F) << 16) | > + (data & 0x); > +} > + > /* > * Tries to find an active connected PHY. Returns 1 if address if found. > * If no active PHY (or more than one PHY) found returns 0. > @@ -248,6 +275,31 @@ static int davinci_mii_phy_write(char *devname, unsigned > char addr, unsigned cha > > #endif > > +static void emac_gigabit_enable(void) > +{ > + int temp; > + > + temp = mdio_read(EMAC_MDIO_PHY_NUM, 0); > + > + if (temp & (1 << 6)) { Is there a logical #define bitfield that could be used here ? > + /* > + * Check if link detected is giga-bit > + * If Gigabit mode detected, enable gigbit in MAC and PHY > + */ > + adap_emac->MACCONTROL |= EMAC_MACCONTROL_GIGFORCE | > + EMAC_MACCONTROL_GIGABIT_ENABLE; > + > + /* > + * The SYS_CLK which feeds the SOC for giga-bit operation > + * does not seem to be enabled after reset as expected. > + * Force enabling SYS_CLK by writing to the PHY > + */ > + temp = mdio_read(EMAC_MDIO_PHY_NUM, 22); > + temp |= (1 << 4); > + mdio_write(EMAC_MDIO_PHY_NUM, 22, temp); > + } > +} > + > > /* Eth device open */ > static int davinci_eth_open(struct eth_device *dev, bd_t *bis) > @@ -261,10 +313,15 @@ static int davinci_eth_open(struct eth_device *dev, > bd_t *bis) > /* Reset EMAC module and disable interrupts in wrapper */ > adap_emac->SOFTRESET = 1; > while (adap_emac->SOFTRESET != 0) {;} checkpatch complains here. infinite loop statement should be on the next line. ERROR: trailing statements should be on next line #103: FILE: drivers/net/davinci_emac.c:318: + while (adap_ewrap->SOFTRST != 0); > +#if defined(CONFIG_DAVINCI_EMAC_VERSION2) > + adap_ewrap->SOFTRST = 1; > + while (adap_ewrap->SOFTRST != 0); > +#else > adap_ewrap->EWCTL = 0; > for (cnt = 0; cnt < 5; cnt++) { > clkdiv = adap_ewrap->EWCTL; > } > +#endif You may want to handle this like #if defined(CONFIG_DAVINIC_EMAC_VERSION) && CONFIG_DAVINCI_EMAC_VERSION >= 2 > > rx_desc = emac_rx_desc; > > @@ -282,6 +339,10 @@ static int davinci_eth_open(struct eth_device *dev, bd_t > *bis) > adap_emac->MACADDRLO = >
Re: [U-Boot] [PATCH] ppc4xx: Fix msg "initialization as root-complex failed" upon PCIe scan
Dear Stefan Roese, In message <1254486916-3040-1-git-send-email...@denx.de> you wrote: > This message is printed upon PCIe bus scan, not only upon error, but also > if no PCIe device is detected at all. Since this is not an error, let's > remove this message in this case. We already have the message > "link is not up." if there is no PCIe device present. Thanks. Acked-by: Wolfgang Denk But looking at this patch, it seems that larger parts in this (supposedly) board-specific code are actually more or less identical. Should we not factor out such common code? 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 Real programmers don't comment their code. It was hard to write, it should be hard to understand. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Fix msg "initialization as root-complex failed" upon PCIe scan
This message is printed upon PCIe bus scan, not only upon error, but also if no PCIe device is detected at all. Since this is not an error, let's remove this message in this case. We already have the message "link is not up." if there is no PCIe device present. Signed-off-by: Stefan Roese --- board/amcc/canyonlands/canyonlands.c |3 +++ board/amcc/katmai/katmai.c |3 +++ board/amcc/kilauea/kilauea.c |3 +++ board/amcc/makalu/makalu.c |3 +++ board/amcc/yucca/yucca.c |3 +++ cpu/ppc4xx/4xx_pcie.c|3 ++- 6 files changed, 17 insertions(+), 1 deletions(-) diff --git a/board/amcc/canyonlands/canyonlands.c b/board/amcc/canyonlands/canyonlands.c index f359d23..9495b62 100644 --- a/board/amcc/canyonlands/canyonlands.c +++ b/board/amcc/canyonlands/canyonlands.c @@ -28,6 +28,7 @@ #include #include #include +#include extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH chips */ @@ -414,6 +415,8 @@ void pcie_setup_hoses(int busno) ret = ppc4xx_init_pcie_endport(i); else ret = ppc4xx_init_pcie_rootport(i); + if (ret == -ENODEV) + continue; if (ret) { printf("PCIE%d: initialization as %s failed\n", i, is_end_point(i) ? "endpoint" : "root-complex"); diff --git a/board/amcc/katmai/katmai.c b/board/amcc/katmai/katmai.c index bcef707..aa6d0ab 100644 --- a/board/amcc/katmai/katmai.c +++ b/board/amcc/katmai/katmai.c @@ -32,6 +32,7 @@ #include #include #include +#include DECLARE_GLOBAL_DATA_PTR; @@ -391,6 +392,8 @@ void pcie_setup_hoses(int busno) ret = ppc4xx_init_pcie_endport(i); else ret = ppc4xx_init_pcie_rootport(i); + if (ret == -ENODEV) + continue; if (ret) { printf("PCIE%d: initialization as %s failed\n", i, is_end_point(i) ? "endpoint" : "root-complex"); diff --git a/board/amcc/kilauea/kilauea.c b/board/amcc/kilauea/kilauea.c index 5ebe692..5cd822a 100644 --- a/board/amcc/kilauea/kilauea.c +++ b/board/amcc/kilauea/kilauea.c @@ -28,6 +28,7 @@ #include #include #include +#include #if defined(CONFIG_PCI) #include @@ -317,6 +318,8 @@ void pcie_setup_hoses(int busno) ret = ppc4xx_init_pcie_endport(i); else ret = ppc4xx_init_pcie_rootport(i); + if (ret == -ENODEV) + continue; if (ret) { printf("PCIE%d: initialization as %s failed\n", i, is_end_point(i) ? "endpoint" : "root-complex"); diff --git a/board/amcc/makalu/makalu.c b/board/amcc/makalu/makalu.c index fb0e7b7..d4277dd 100644 --- a/board/amcc/makalu/makalu.c +++ b/board/amcc/makalu/makalu.c @@ -29,6 +29,7 @@ #include #include #include +#include #if defined(CONFIG_PCI) #include @@ -273,6 +274,8 @@ void pcie_setup_hoses(int busno) ret = ppc4xx_init_pcie_endport(i); else ret = ppc4xx_init_pcie_rootport(i); + if (ret == -ENODEV) + continue; if (ret) { printf("PCIE%d: initialization as %s failed\n", i, is_end_point(i) ? "endpoint" : "root-complex"); diff --git a/board/amcc/yucca/yucca.c b/board/amcc/yucca/yucca.c index 033bdd2..5c9d491 100644 --- a/board/amcc/yucca/yucca.c +++ b/board/amcc/yucca/yucca.c @@ -32,6 +32,7 @@ #include #include #include +#include #include "yucca.h" @@ -830,6 +831,8 @@ void pcie_setup_hoses(int busno) yucca_setup_pcie_fpga_rootpoint(i); ret = ppc4xx_init_pcie_rootport(i); } + if (ret == -ENODEV) + continue; if (ret) { printf("PCIE%d: initialization as %s failed\n", i, is_end_point(i) ? "endpoint" : "root-complex"); diff --git a/cpu/ppc4xx/4xx_pcie.c b/cpu/ppc4xx/4xx_pcie.c index e880c28..19d2c7d 100644 --- a/cpu/ppc4xx/4xx_pcie.c +++ b/cpu/ppc4xx/4xx_pcie.c @@ -30,6 +30,7 @@ #include #include #include +#include #if (defined(CONFIG_440SPE) || defined(CONFIG_405EX) ||\ defined(CONFIG_460EX) || defined(CONFIG_460GT)) && \ @@ -874,7 +875,7 @@ int ppc4xx_init_pcie_port(int port, int rootport) val = SDR_READ(SDRN_PESDR_LOOP(port)); if (!(val & 0x1000)) { printf("PCIE%d: link is not up.\n", port); - return -1; + return -ENODEV; } /* -- 1.6.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Dear Ingo van Lil, In message <20091002103417.ga9...@zaphod.peppercon.de> you wrote: > The CFI driver does not reset the device's watchdog, so long-running > flash operations will cause the watchdog timer to expire. A comment in > flash_status_check() suggests that udelay() is expected to reset the > watchdog, but I can't find any architecture where it does. Please have a closer look, then. On PowerPC, udelay() ["lib_ppc/time.c"] calls wait_ticks(), which in turn ["lib_ppc/ticks.S"] calls WATCHDOG_RESET If this is missing in other architectures, it should be fixed at the root cause, i. e. in udelay() or in the respective support routines. 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 long as we're going to reinvent the wheel again, we might as well try making it round this time.- Mike Dennison ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM365: Fix Compilation warning for DM365 EVM
s-paul...@ti.com wrote: > From: Sandeep Paulraj > > This patch fixes a compilation warning while compiling > the DM365 EVM. > > Signed-off-by: Sandeep Paulraj > --- > board/davinci/dm365evm/dm365evm.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/board/davinci/dm365evm/dm365evm.c > b/board/davinci/dm365evm/dm365evm.c > index 5b97060..1e3a14f 100644 > --- a/board/davinci/dm365evm/dm365evm.c > +++ b/board/davinci/dm365evm/dm365evm.c > @@ -79,8 +79,8 @@ int board_eth_init(bd_t *bis) > static void nand_dm365evm_select_chip(struct mtd_info *mtd, int chip) > { > struct nand_chip*this = mtd->priv; > - u32 wbase = (u32) this->IO_ADDR_W; > - u32 rbase = (u32) this->IO_ADDR_R; > + unsigned long wbase = (unsigned long) this->IO_ADDR_W; > + unsigned long rbase = (unsigned long) this->IO_ADDR_R; > > if (chip == 1) { > __set_bit(14, &wbase); This looks familiar.. good job getting both cases. Ack-ed. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM355: Fix Compilation warning for DM355 EVM
s-paul...@ti.com wrote: > From: Sandeep Paulraj > > This patch fixes a compilation warning while compiling > the DM355 EVM. > > Signed-off-by: Sandeep Paulraj > --- > board/davinci/dm355evm/dm355evm.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/board/davinci/dm355evm/dm355evm.c > b/board/davinci/dm355evm/dm355evm.c > index 0a44748..87f284c 100644 > --- a/board/davinci/dm355evm/dm355evm.c > +++ b/board/davinci/dm355evm/dm355evm.c > @@ -92,8 +92,8 @@ int board_eth_init(bd_t *bis) > static void nand_dm355evm_select_chip(struct mtd_info *mtd, int chip) > { > struct nand_chip*this = mtd->priv; > - u32 wbase = (u32) this->IO_ADDR_W; > - u32 rbase = (u32) this->IO_ADDR_R; > + unsigned long wbase = (unsigned long) this->IO_ADDR_W; > + unsigned long rbase = (unsigned long) this->IO_ADDR_R; > > if (chip == 1) { > __set_bit(14, &wbase); Ack-ed. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] TI DaVinci DM646x: Adding initial support for DM6467 EVM
s-paul...@ti.com wrote: > From: Sandeep Paulraj > > This patch adds the initial support for DM6467 EVM. > Other features like NET and NAND support will be added as follow up patches. > > Signed-off-by: Sandeep Paulraj > --- > There are multiple flavours of the DM646x. The newest DM646x SOC can operate > at 1 GHz. The DM6467 EVM from Spectrum Digital can be used for both speed > grades of the DM646x SOC . The only change on the EVM being an oscilator that > operated at a higher frequency. The same board file will be used to support > both SOC's. Support for this feature will be added as follow up patches. > > Patches will also be sent to enable EMAC, NAND and other features. > Makefile|3 + Needs an addition to MAKEALL and optionally Maintainers > board/davinci/dm6467evm/Makefile| 52 ++ > board/davinci/dm6467evm/config.mk |2 + > board/davinci/dm6467evm/dm6467evm.c | 31 > include/configs/davinci_dm6467evm.h | 131 > +++ > 5 files changed, 219 insertions(+), 0 deletions(-) > create mode 100644 board/davinci/dm6467evm/Makefile > create mode 100644 board/davinci/dm6467evm/config.mk > create mode 100644 board/davinci/dm6467evm/dm6467evm.c > create mode 100644 include/configs/davinci_dm6467evm.h > > diff --git a/Makefile b/Makefile > index 0b61d05..dc797b0 100644 > --- a/Makefile > +++ b/Makefile > @@ -2962,6 +2962,9 @@ davinci_dm355evm_config : unconfig > davinci_dm365evm_config :unconfig > @$(MKCONFIG) $(@:_config=) arm arm926ejs dm365evm davinci davinci > > +davinci_dm6467evm_config : unconfig > + @$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci > + > imx27lite_config:unconfig > @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 > > diff --git a/board/davinci/dm6467evm/Makefile > b/board/davinci/dm6467evm/Makefile > new file mode 100644 > index 000..26b0705 > --- /dev/null > +++ b/board/davinci/dm6467evm/Makefile > @@ -0,0 +1,52 @@ > +# > +# (C) Copyright 2000, 2001, 2002 > +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. > +# > +# Copyright (C) 2007 Sergey Kubushyn > +# > +# See file CREDITS for list of people who contributed to this > +# project. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation; either version 2 of > +# the License, or (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, > +# MA 02111-1307 USA > +# > + > +include $(TOPDIR)/config.mk > + > +LIB = $(obj)lib$(BOARD).a > + > +COBJS:= $(BOARD).o > +SOBJS:= > + > +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(COBJS)) > +SOBJS:= $(addprefix $(obj),$(SOBJS)) > + > +$(LIB): $(obj).depend $(OBJS) $(SOBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) > + > +clean: > + rm -f $(SOBJS) $(OBJS) > + > +distclean: clean > + rm -f $(LIB) core *.bak $(obj).depend > + > +# > +# This is for $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +# > diff --git a/board/davinci/dm6467evm/config.mk > b/board/davinci/dm6467evm/config.mk > new file mode 100644 > index 000..ca801c2 > --- /dev/null > +++ b/board/davinci/dm6467evm/config.mk > @@ -0,0 +1,2 @@ > +#Provide at least 16MB spacing between us and the Linux Kernel image > +TEXT_BASE = 0x8108 > diff --git a/board/davinci/dm6467evm/dm6467evm.c > b/board/davinci/dm6467evm/dm6467evm.c > new file mode 100644 > index 000..9605818 > --- /dev/null > +++ b/board/davinci/dm6467evm/dm6467evm.c > @@ -0,0 +1,31 @@ > +/* > + * Copyright (C) 2009 Texas Instruments Incorporated > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; i
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
On 10/02/2009 01:06 PM, Stefan Roese wrote: >> The CFI driver does not reset the device's watchdog, so long-running >> flash operations will cause the watchdog timer to expire. A comment in >> flash_status_check() suggests that udelay() is expected to reset the >> watchdog, but I can't find any architecture where it does. > > PPC does it this way. udelay() in lib_ppc/time.c calls wait_ticks(). And here > you will find WATCHDOG_RESET. You're right. Seems to be an exception, though: According to ctags there are 40 separate implementations of udelay(), and the ones in lib_ppc and lib_nios seem to be the only ones that actually do call WATCHDOG_RESET. > Which platform are you using? I support this needs to be fixed in your > platform. I'm using an Atmel AT91-based custom board, and the udelay() function can be found in cpu/arm926ejs/at91/timer.c. Unfortunately there's no central udelay() implementation in lib_arm. Regards, Ingo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ppc4xx/master
The following changes since commit 1d96cfe8f5eebfc6ea39d1a387f35ca4499e6b67: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Felix Radensky (1): ppc4xx: Reorganize DDR2 ECC handling Matthias Fuchs (1): ppc4xx: Add SDRAM detection for PMC440 boards Stefan Roese (1): ppc4xx: Merge PPC4xx DDR and DDR2 ECC handling board/esd/pmc440/init.S | 11 +- board/esd/pmc440/sdram.c| 82 ++--- cpu/ppc4xx/44x_spd_ddr2.c | 366 --- cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c |6 +- cpu/ppc4xx/ecc.c| 167 +++- cpu/ppc4xx/ecc.h| 52 +++--- include/asm-ppc/ppc4xx-sdram.h |7 +- include/configs/PMC440.h|1 - 8 files changed, 341 insertions(+), 351 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ppc4xx: Add SDRAM detection for PMC440 boards
On Wednesday 30 September 2009 11:55:04 Matthias Fuchs wrote: > This patch adds support to detect the amount of DDR2 SDRAM > on PMC440 modules. Detection is done by probing through > a list of available and supported hardware configurations > from 1GByte down to 256MB. > > The static TLB entry is replaced by dynamically created entries. Applied to u-boot-ppc4xx/master. Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ppc4xx: Merge PPC4xx DDR and DDR2 ECC handling
On Tuesday 29 September 2009 08:39:28 Stefan Roese wrote: > This patch merges the ECC handling (ECC parity byte writing) into one > file (ecc.c) for all PPC4xx SDRAM controllers except for PPC440EPx/GRx. > This exception is because only those PPC's use the completely different > Denali SDRAM controller core. > > Previously we had two routines to generate/write the ECC parity bytes. > With this patch we now only have one core function left. > > Tested on Kilauea (no ECC) and Katmai (with and without ECC). Applied to u-boot-ppc4xx/master. Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Reorganize DDR2 ECC handling
On Sunday 27 September 2009 23:56:12 Felix Radensky wrote: > Reorganize DDR2 ECC handling to use common code for > SPD DIMMs and soldered SDRAM. Also, use common code > to display SDRAM info (ECC, CAS latency) for SPD and > soldered SDRAM variants. Applied to u-boot-ppc4xx/master. Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
Hi Ingo, On Friday 02 October 2009 12:34:17 Ingo van Lil wrote: > The CFI driver does not reset the device's watchdog, so long-running > flash operations will cause the watchdog timer to expire. A comment in > flash_status_check() suggests that udelay() is expected to reset the > watchdog, but I can't find any architecture where it does. PPC does it this way. udelay() in lib_ppc/time.c calls wait_ticks(). And here you will find WATCHDOG_RESET. Which platform are you using? I support this needs to be fixed in your platform. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] CFI Driver: Reset watchdog timer after each flash operation
The CFI driver does not reset the device's watchdog, so long-running flash operations will cause the watchdog timer to expire. A comment in flash_status_check() suggests that udelay() is expected to reset the watchdog, but I can't find any architecture where it does. Signed-off-by: Ingo van Lil --- drivers/mtd/cfi_flash.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c index 6eea49a..5dcd62d 100644 --- a/drivers/mtd/cfi_flash.c +++ b/drivers/mtd/cfi_flash.c @@ -39,6 +39,7 @@ #include #include #include +#include /* * This file implements a Common Flash Interface (CFI) driver for @@ -675,7 +676,8 @@ static int flash_status_check (flash_info_t * info, flash_sect_t sector, flash_write_cmd (info, sector, 0, info->cmd_reset); return ERR_TIMOUT; } - udelay (1); /* also triggers watchdog */ + udelay (1); + WATCHDOG_RESET(); } return ERR_OK; } -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot