Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-20 Thread Wolfgang Denk
Dear Chris Packham, In message loom.20100520t005209-...@post.gmane.org you wrote: While it would be possible to shuffle the memory map around there is one problem with the hardware design that I don't think can be overcome (I'd love to be proven wrong). The boot chip select is mapped to the

Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-20 Thread Chris Packham
Hi Wolfgang, On Thu, May 20, 2010 at 1:35 AM, Wolfgang Denk w...@denx.de wrote: Dear Chris Packham, In message loom.20100520t005209-...@post.gmane.org you wrote: While it would be possible to shuffle the memory map around there is one problem with the hardware design that I don't think can

Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-19 Thread Stefan Roese
Mark, On Tuesday 18 May 2010 22:10:51 mark tomlinson wrote: Yes we do have 2 flash chips. Here's the mapping: #define CONFIG_SYS_FLASH_BASE 0xf800 /* 2 chips*16M */ Hmmm. 2 * 16MByte, thats 32MByte == 0x200. So you should have one chip at base address 0xff00 and one at

Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-19 Thread mark tomlinson
Sorry, no. The flash chips are 0xf800-0xf9ff (32MB). (Actually we have twice this area reserved for 64MB flash in the future). The flash chip from 0xf800 is also mirrored at 0xfff0 at boot time. I don't know if you consider this a hardware bug to not have all the flash at the

Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-19 Thread Wolfgang Denk
Dear mark tomlinson, Please restrict your line length to some 70 characters or so, and stop posting HTML! In message 4bf4fc5e02b800012...@gwia.alliedtelesyn.co.nz you wrote: Sorry, no. The flash chips are 0xf800-0xf9ff (32MB). (Actually we have twice this area reserved for 64MB

Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-19 Thread Chris Packham
Disclaimer: I'm workmate of Mark's Wolfgang Denk wd at denx.de writes: It's not a hardware bug, but a configuration error. f800-fbff 64M Flash fe00-fe0f1M Battery-backed RAM ff00-ff00 64K On-board logic ff70-ff7f1M CCSR

Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-18 Thread Stefan Roese
Hi Mark, On Tuesday 18 May 2010 07:26:34 Mark Tomlinson wrote: Our hardware has part of the flash mapped in two address ranges. The CONFIG_SYS_MONITOR_BASE is in the upper 'boot' area, whereas the CONFIG_SYS_FLASH_BANKS_LIST has the full flash available at a lower address. Just to be sure:

Re: [U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-18 Thread mark tomlinson
Yes we do have 2 flash chips. Here's the mapping: #define CONFIG_SYS_FLASH_BASE 0xf800 /* 2 chips*16M */ #define CONFIG_SYS_MONITOR_BASE TEXT_BASE /* start of monitor */ and in our config.mk file: TEXT_BASE = 0xfff4 This is the same flash chip as that at 0xf800, but

[U-Boot] [PATCH 0/1] Fix hang trying to protect flash sectors

2010-05-17 Thread Mark Tomlinson
Our hardware has part of the flash mapped in two address ranges. The CONFIG_SYS_MONITOR_BASE is in the upper 'boot' area, whereas the CONFIG_SYS_FLASH_BANKS_LIST has the full flash available at a lower address. This all works fine until the code in cfi_flash.c:flash_init(), which uses