[U-Boot-Users] PATCH: Add command support for second I2Ccontroller

[U-Boot-Users] PATCH: Add command support for second I2Ccontroller

[Menon, Nishanth]

Ben,

> This approach sounds good.  The only down-side that I can see is that
> the driver needs to keep track of context.  Personally, I prefer
Yes and no, yes- if the driver has multiple busses to support, and no-
if they don't have multiple busses to support.

> 
> In order to do this properly, we should add to the base API in
> include/i2c.h something like:
> 
> void i2c_set_bus(uchar dev);
> uchar i2c_get_bus(void);
> void i2c_set_bus_speed(int speed);
> int i2c_get_bus_speed(void);
> 
> or merge the index and speed as you have in your code.
For controllers allowing me to switch between standard/full speed/HS
mode or standard/fullspeed: Two commands to run 
Versus:
For controllers having a single speed:
One command..

Interesting call.. Being biased towards my platform I'd suggest merged
code.. but I leave it to the common wisdom to decide :)

> 
> The drivers can then either choose to implement or not implement this
> feature, and we can add a parallel command tree based on 'i2c' as
> Wolfgang has suggested.
Don't know if a parallel cmd tree is required, as far as I see, it is an
additional command to extend the reach of i2c driver, and since the
changes wont affect other drivers, I hope it can be patched in to the
mainline tree..

Regards,
Nishanth Menon

[U-Boot-Users] PATCH: Add command support for second I2Ccontroller

[Ben Warren]

One sticky part is, how do we deal with the 'CFG_I2C_NOPROBE' stuff?
This is a list defined for each board of chips that the 'iprobe' command
should bypass. The current implementation has this list instantiated as
a static array within 'cmd_i2c.c', and is of course relevant only to the
first bus.  As we add buses, it gets ugly.  How about defining a
structure that includes all bus information:

typedef struct _i2c_bus
{
	int	baseAddress
	int	busSpeed;
	uchar	noProbeList[];
	...  /* whatever else might be useful */
} i2c_bus;

On the other hand, maybe the NOPROBE list is rarely used and we
shouldn't be worrying too much about it.

regards,
Ben

On Tue, 2006-05-16 at 10:43 -0500, Menon, Nishanth wrote:
> Ben,
> 
> > This approach sounds good.  The only down-side that I can see is that
> > the driver needs to keep track of context.  Personally, I prefer
> Yes and no, yes- if the driver has multiple busses to support, and no-
> if they don't have multiple busses to support.
> 
> > 
> > In order to do this properly, we should add to the base API in
> > include/i2c.h something like:
> > 
> > void i2c_set_bus(uchar dev);
> > uchar i2c_get_bus(void);
> > void i2c_set_bus_speed(int speed);
> > int i2c_get_bus_speed(void);
> > 
> > or merge the index and speed as you have in your code.
> For controllers allowing me to switch between standard/full speed/HS
> mode or standard/fullspeed: Two commands to run 
> Versus:
> For controllers having a single speed:
> One command..
> 
> Interesting call.. Being biased towards my platform I'd suggest merged
> code.. but I leave it to the common wisdom to decide :)
> 
> > 
> > The drivers can then either choose to implement or not implement this
> > feature, and we can add a parallel command tree based on 'i2c' as
> > Wolfgang has suggested.
> Don't know if a parallel cmd tree is required, as far as I see, it is an
> additional command to extend the reach of i2c driver, and since the
> changes wont affect other drivers, I hope it can be patched in to the
> mainline tree..
> 
> Regards,
> Nishanth Menon

[U-Boot-Users] PATCH: Add command support for second I2Ccontroller

[Wolfgang Denk]

In message <1147798734.16780.201.camel@saruman.qstreams.net> you wrote:
> One sticky part is, how do we deal with the 'CFG_I2C_NOPROBE' stuff?
> This is a list defined for each board of chips that the 'iprobe' command
> should bypass. The current implementation has this list instantiated as
> a static array within 'cmd_i2c.c', and is of course relevant only to the
> first bus.  As we add buses, it gets ugly.  How about defining a
> structure that includes all bus information:
> 
> typedef struct _i2c_bus
> {
> 	int	baseAddress
> 	int	busSpeed;
> 	uchar	noProbeList[];
> 	...  /* whatever else might be useful */
> } i2c_bus;

Please keep as small as possible.

> On the other hand, maybe the NOPROBE list is rarely used and we
> shouldn't be worrying too much about it.

Ummm... at least the following board configurations use it:

include/configs/MPC8540ADS.h
include/configs/MPC8541CDS.h
include/configs/MPC8555CDS.h
include/configs/MPC8560ADS.h
include/configs/PM854.h
include/configs/SBC8540.h
include/configs/SBC8560.h
include/configs/XPEDITE1K.h
include/configs/bubinga.h
include/configs/ebony.h
include/configs/ocotea.h
include/configs/sbc8560.h
include/configs/stxgp3.h
include/configs/MPC8540EVAL.h
include/configs/MPC8548CDS.h
include/configs/PM856.h
include/configs/KAREF.h
include/configs/METROBOX.h
include/configs/TQM85xx.h
include/configs/p3p440.h
include/configs/MPC8349EMDS.h

That's definitely more than "rarely used".

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Make it right before you make it faster.

[U-Boot-Users] PATCH: Add command support for second I2Ccontroller

[Ben Warren]

I'm working on a solution that retains NOPROBE support, while keeping
the footprint as small as possible.  Should have a patch tomorrow.

regards,
Ben

On Tue, 2006-05-16 at 22:15 +0200, Wolfgang Denk wrote:

> In message <1147798734.16780.201.camel@saruman.qstreams.net> you wrote:
> > One sticky part is, how do we deal with the 'CFG_I2C_NOPROBE' stuff?
> > This is a list defined for each board of chips that the 'iprobe' command
> > should bypass. The current implementation has this list instantiated as
> > a static array within 'cmd_i2c.c', and is of course relevant only to the
> > first bus.  As we add buses, it gets ugly.  How about defining a
> > structure that includes all bus information:
> > 
> > typedef struct _i2c_bus
> > {
> > 	int	baseAddress
> > 	int	busSpeed;
> > 	uchar	noProbeList[];
> > 	...  /* whatever else might be useful */
> > } i2c_bus;
> 
> Please keep as small as possible.
> 
> > On the other hand, maybe the NOPROBE list is rarely used and we
> > shouldn't be worrying too much about it.
> 
> Ummm... at least the following board configurations use it:
> 
> include/configs/MPC8540ADS.h
> include/configs/MPC8541CDS.h
> include/configs/MPC8555CDS.h
> include/configs/MPC8560ADS.h
> include/configs/PM854.h
> include/configs/SBC8540.h
> include/configs/SBC8560.h
> include/configs/XPEDITE1K.h
> include/configs/bubinga.h
> include/configs/ebony.h
> include/configs/ocotea.h
> include/configs/sbc8560.h
> include/configs/stxgp3.h
> include/configs/MPC8540EVAL.h
> include/configs/MPC8548CDS.h
> include/configs/PM856.h
> include/configs/KAREF.h
> include/configs/METROBOX.h
> include/configs/TQM85xx.h
> include/configs/p3p440.h
> include/configs/MPC8349EMDS.h
> 
> That's definitely more than "rarely used".
> 
> Best regards,
> 
> Wolfgang Denk
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20060516/2d38da91/attachment.htm 

[U-Boot-Users] Help explain the Ramdisk Load Address: 00000000

[muqiyong]

Dear Group:
	When my 9200 board boot, it shows load message like this:
## Booting image at c0100000 ...
   Image Name:   Linux-2.6.17-rc4
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    923060 Bytes = 901.4 kB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at c0300000 ...
   Image Name:   MQY Ramdisk
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    2870735 Bytes =  2.7 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

	It's confuse for the load address of Ramdisk, it shows 00000000,
The kernel's boot args shows: initrd=204100, so I think here should display
Same as set in the kernel config.
	Please explain why it looks like this?

Thanks a lot!
KylongMu

[U-Boot-Users] Help explain the Ramdisk Load Address: 00000000

[Wolfgang Denk]

In message <BAY107-DAV1916A08A39B528912CEBBFC5A10@phx.gbl> <000001c679d1$d6d5a810$b7899d0a@first> you wrote:
>
> 	It's confuse for the load address of Ramdisk, it shows 00000000,

A ramdisk has no such thing as a load address or an entry  point,  so
0x0000  is  perfectly OK. Normally (using a same Linux kernel) U-Boot
will not touch the ramdisk at all  and  just  pass  it's  address  to
Linux, no matter where it is stored (RAM or flash).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our business is run on trust.  We trust you will pay in advance.