This is the board that I am working with myself. I've got this working for
quite a while and have sent
my "physmap.c" file to a few folks personally (that's the original physmap.c
file from CVS hacked for the SC520 CDP- this was before there was
a physmap file in CVS for this board.)

Anywhy, why I bring this is up, there is a *nasty* surprise waiting for folks
that use the default address of 0x8400000 as programmed by the BIOS
shipped with the board.

This "nasty surpirse" is documented in my hacked physmap.c that I reproduct
below (and attached):

/* The Embedded Systems BIOS decodes the first FLASH starting at
   0x8400000. This is a *terrible* place for it bacause accessing
   the flash at this location causes the A22 address line to be high
   (that's what 0x8400000 binary's out to be). But this is the highest
   order address line on the raw flash devices themselves!!
   This causes the top HALF of the flash to be accessed first. Beyond
   the physical limits of the flash, the flash chip aliases over (to
   0x880000 which causes the bottom half to be accessed. This splits the
   flash into two and inverts it! If you then try to acces this from another
   program that does NOT do this insanity, then you *will* access the
   first half of the flash, but not find what you expect there. That
   stuff is in the *second* half!
*/

So, what's the problem you ask? Well if you don't want to use the BIOS to boot
the board
and want to boot the kernel image directly from flash (which I wanted to do and
finally did),
you would probably decode the FLASH starting at a more sensible location- like
0x8800000 in the
first place. But you won't find the kernel there if you put it there when the
board was booted
with the original BIOS. That kernel is sitting in the second half of the flash
bank, even though you put
it at the start of /dev/mtd0!

Attached is my physmap.c file. There is code there to change to PAR reg's to
redecode the FLASH
at a more sensible location. There is also some code that dumps all PAR reg's
that may be useful
to others.

I suggest that whoever checked the sc520cdp.c file into CVS, at the very least
pick up the above comments
and include them as a warning, even if they don't want to reprogram the PAR at
the new and proper address
(I suggest that we reprogram the PAR regs).

Sorry for the long post.

Vipin








David Woodhouse wrote:

> rob@sysgo.de said:
> >  Probably (assuming the 'interesting' license allows it). Maybe
> > someone with access to a Net520 board could be persuaded to test/
> > maintain it ?
>
> The 'interesting' licence is just a mistake on the web site - I don't think
> they really meant to claim copyright on the entire MTD snapshot tarball :)
>
> The ideal volunteer for testing/maintenance would be Mark, but he appears to
> be away till April 25th, by which time I'm hoping to have completed the
> merge. If I actually do manage to send patches off by then, I'll just
> include it as net520.c. Otherwise I'll seek his advice upon his return.
>
> --
> dwmw2
>
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org