From: Dirk Eibach eib...@gdsys.de
This patch adds a generic command for programming I2C bootstrap
eeproms on PPC4xx. An implementation for Canyonlands board is
included.
The command name is intentionally chosen not to be PPC4xx specific.
This way other CPU's/SoC's can implement a similar command
On Friday 17 July 2009 11:26:03 Stefan Roese wrote:
From: Dirk Eibach eib...@gdsys.de
Sorry, but this From: Dirk... slipped in by accident. Dirk has provided some
parts of this framework, but the real command is more complete rewrite from
myself. I kept Dirk's Copyright's in the header, but
Dirk, if you like I can add you s-o-b to the next patch
version, since you contributed to this code as well. Just let me know.
Sure, you can list me as s-o-b.
Cheers
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
Dear Stefan Roese,
In message 1247822763-20761-1-git-send-email...@denx.de you wrote:
From: Dirk Eibach eib...@gdsys.de
This patch adds a generic command for programming I2C bootstrap
eeproms on PPC4xx. An implementation for Canyonlands board is
included.
The command name is
Hi Wolfgang,
On Friday 17 July 2009 12:45:01 Wolfgang Denk wrote:
= cpu_config
Available configurations:
600-nor - NOR CPU: 600 PLB: 200 OPB: 100 EBC: 100
600-nand- NAND CPU: 600 PLB: 200 OPB: 100 EBC: 100
800-nor - NOR CPU: 800 PLB: 200 OPB: 100 EBC: 100
Dear Stefan Roese,
In message 200907171313.37259...@denx.de you wrote:
Why are the lines indented by one space?
It was this way in the original bootstrap version. I can remove it if you
prefer.
Please do.
Would it be possible to also mark the current setting in this output?
Like
On Friday 17 July 2009 13:20:17 Wolfgang Denk wrote:
Would it be possible to also mark the current setting in this output?
Like printing an asterisk befor or after it?
No. Currently the implementation only checks strings and has no idea of
frequencies. Also, not only PLL frequencies
Dear Stefan Roese,
In message 200907171326.25645...@denx.de you wrote:
But would it not be useful to be able to detect any illegal
settings, for example resulting from accidentyial corruption of the
EEPROM data?
I don't understand this. How should the code detect an illegal
On Friday 17 July 2009 13:40:50 Wolfgang Denk wrote:
But would it not be useful to be able to detect any illegal
settings, for example resulting from accidentyial corruption of the
EEPROM data?
I don't understand this. How should the code detect an illegal setting?
All
9 matches
Mail list logo
