Who remembers details about this guy?
flashrom hardcodes the flash chip address to 0x9400000 with -DTS5300 instead of the regular 4G-flash chip size.
There's a comment suggesting that it should be possible to autodetect when flashrom is running on TS-5300, but there is no mention of how.
The Technologic TS-5300 is an AMD Elan 520 PC/104 design which seems to still sell at $259 on http://www.embeddedarm.com/products/board-detail.php?product=TS-5300
I want to get rid of the #define. Probe it or lose it!
//Peter
Peter Stuge wrote:
Who remembers details about this guy?
flashrom hardcodes the flash chip address to 0x9400000 with -DTS5300 instead of the regular 4G-flash chip size.
There's a comment suggesting that it should be possible to autodetect when flashrom is running on TS-5300, but there is no mention of how.
The Technologic TS-5300 is an AMD Elan 520 PC/104 design which seems to still sell at $259 on http://www.embeddedarm.com/products/board-detail.php?product=TS-5300
I want to get rid of the #define. Probe it or lose it!
I say NACK to dropping this code.
Please don't get the code drop frenzy! There are enough other open working lots.
There's a register in the SC520 which lets you map the ROM to a certain address. On the TS5300 it was strapped to 0x9400000, other SC520 systems may be configured differently. But basically all have their flash at non-standard positions afaik.
If you want to write code to do the probing, I'll gladly ACK it. I can't test anymore - the TS5300 stayed back at the linuxtag in 07. No idea what happened to it.
On Sun, Jun 22, 2008 at 12:27:27PM +0200, Stefan Reinauer wrote:
Who remembers details about this guy?
flashrom hardcodes the flash chip address to 0x9400000 with -DTS5300 instead of the regular 4G-flash chip size.
..
I want to get rid of the #define. Probe it or lose it!
I say NACK to dropping this code.
Please don't get the code drop frenzy! There are enough other open working lots.
Just a little cleaning up.
On the TS5300 it was strapped to 0x9400000, other SC520 systems may be configured differently. But basically all have their flash at non-standard positions afaik.
Hm? You say strapped, to me that means controlled by board design/jumpers. Is the address always set by hardware, and then that address is readable in the PAR registers?
If you want to write code to do the probing, I'll gladly ACK it.
I won't write that until it can be tested by someone before commit.
I can't test anymore - the TS5300 stayed back at the linuxtag in 07. No idea what happened to it.
Maybe Carsten still has it?
Does anyone else have access to a SC520 system?
I hope you agree that it is not so useful to spend time on adding support for a 7+ year old board, which noone can test on, that has already been compiled out of the utility by default since forever.
//Peter
Peter Stuge wrote:
On the TS5300 it was strapped to 0x9400000, other SC520 systems may be configured differently. But basically all have their flash at non-standard positions afaik.
Hm? You say strapped, to me that means controlled by board design/jumpers. Is the address always set by hardware, and then that address is readable in the PAR registers?
I hint you to the SC520 manuals on AMDs web page.
Does anyone else have access to a SC520 system?
I hope you agree that it is not so useful to spend time on adding support for a 7+ year old board, which noone can test on, that has already been compiled out of the utility by default since forever.
Absolutely my point. This is why the current state is possibly the best it can get in this regard.
We won't drop coreboot support for sc520 either, just because the default case (ie. compiling a K8 or LX target) does not include that code (.. since many years)
That code worked fine when I last tested it last year, so there's absolutely no reason to remove it.
Stefan
On Sun, Jun 22, 2008 at 07:20:22PM +0200, Stefan Reinauer wrote:
Hm? You say strapped, to me that means controlled by board design/jumpers. Is the address always set by hardware, and then that address is readable in the PAR registers?
I hint you to the SC520 manuals on AMDs web page.
Yeah, already had a look at some of them, nothing in the register doc, but I didn't yet check the users's guide even though it is supposed to detail BOOTCS# stuff.
I hope you agree that it is not so useful to spend time on adding support for a 7+ year old board, which noone can test on, that has already been compiled out of the utility by default since forever.
Absolutely my point. This is why the current state is possibly the best it can get in this regard.
..
That code worked fine when I last tested it last year, so there's absolutely no reason to remove it.
Fair enough!
If someone has a board with the SC520 and can help test, please speak up so we can have a generic board enable. (Carsten, still tuned in? Do you remember if you saw Stefan's board? I don't remember seeing it when we packed but it was a while ago. :\ )
//Peter
you can't put more than 64k flash up in high memory on the ts5300 -- it's an sc520 limitation -- they drop 64k of hardware registers right in the middle of what is supposed to be (by standard) BIOS ROM address space. If you want to delete this code, be aware that you may be removing sc520 flashing support completely. Absent a test, I recommend you NOT delete it.
I think that for this type of change, you must be very very careful to ensure it works before a commit. sc520 has very strange limitations. A neat chip but I don't ever want to work with it again ...
ron
-
Peter Stuge -
ron minnich -
Stefan Reinauer