i2c bus address

[clicky]

Hi all,

I must have missed something, but now I have installed the latest kernel and updated firmware (all part of the same process) for 512Mb device I found that two i2c buses have swapped addresses!

Previously using Chris's Digital Realm kernel i2c bus on the header (gpio 0 and gpio 1) was on bus 0. Now it is on bus 1. Am I making a mistake somewhere in the way module is loaded and configured or it is meant to be like that and previous kernel/kernel builds got it wrong?

[Gert van Loo]

I must have missed something,

Yes, you did miss something
The rev-2 spec states that the I2C port on the GPIO connector and the Camera have been swapped.
So I2C0 <=> I2C1

[clicky]

Oh, thanks! That makes perfect sense. Only think I am not sure now is (as I have both revision RPis and would like to use both):

a) should I in software detect revision of board and adjust bus number accordingly?

or

b) is there a way something else to do it for me (underlying software, kernel, module or whatever is responsible for it)?

If it is the first one, does anyone know good reference how to detect revision of the board so I can adjust bus number accordingly?

[gordon@drogon.net]

Oh, thanks! That makes perfect sense. Only think I am not sure now is (as I have both revision RPis and would like to use both):

a) should I in software detect revision of board and adjust bus number accordingly?

or

b) is there a way something else to do it for me (underlying software, kernel, module or whatever is responsible for it)?

If it is the first one, does anyone know good reference how to detect revision of the board so I can adjust bus number accordingly?

Detect the board ID )-:

I've been through several iterations of this - boards programmed incorrectly, with bogus numbers and so on and finally settled on this algorithm:

Read /proc/cpuinfo and search for "Revision" and extract the string.

Look at the last digit - if it's "2" or "3" then it's a Rev 1 board - anything else and it's Rev 2.

no-doubt this will break again in the future, but for now, it seems to be the best way.

(It won't catch the incorrectly programmed rev 1's which have 0000 there, but I'm fairly sure I've heard of a Rev 2 with 0000 there too)

I wish there was a better way.

-Gordon

[techpaul]

Wish total memory was reported so you couls tell that must be rev 2

[gordon@drogon.net]

Wish total memory was reported so you couls tell that must be rev 2

I've a funny feeling some very early Rev 2's only had 256MB on them, so even if that were possible, it might not be foolproof...

-Gordon

[techpaul]

Wish total memory was reported so you couls tell that must be rev 2

I've a funny feeling some very early Rev 2's only had 256MB on them, so even if that were possible, it might not be foolproof...

-Gordon

The joys of version control

[techpaul]

Wish total memory was reported so you couls tell that must be rev 2

I've a funny feeling some very early Rev 2's only had 256MB on them, so even if that were possible, it might not be foolproof...

-Gordon

Suddenly remembered what I realy should have said.

But all units with 512MB are Rev 2, so at that point no further revision checks (until Rev 3 appears).

If 256MB still do other checks for revision.2

[clicky]

Suddenly remembered what I realy should have said.

But all units with 512MB are Rev 2, so at that point no further revision checks (until Rev 3 appears).

If 256MB still do other checks for revision.2

That's good to know, but rev 2 board without flashed firmware (updated kernel or whatever else is needed or however it is called) is still reporting 256Mb of memory, so it isn't the most deterministic way. And as you said, it doesn't cover future changes I think I'll, for now, stick with trying to identify Rev 1 board and hope that Rev 3 will have bus on the same place... Anyway - thanks all for the ideas!