ACT LED - Where this is enabled

[WanaGo]

Hello,

We are building a new product with the BCM2835 and I was just after some help with GPIO and Raspbian.

Just wondering if anyone can tell me where about the ACT LED signal is enabled from.
In the June release of Raspbian, it seems the ACT LED was enabled in the Kernel, however with the latest kernel release which we had compiled for us, it seems this is no longer the case.
3.12.22+ #691 from the June release triggers GPIO16, and 3.10.38+ #39 does not.

We are using GPIO16 for other purposes, so this latest kernel is much better for us, but I was just wondering where that ACT LED is now enabled from, so I can look to edit it to move it to a different GPIO.

Any help would be appreciated.

Another question

The B+ Pi doesnt look to use the Card Detect Signal anymore. I was just wondering what has to be done to get the Pi to boot without having to have this signal showing a card anymore. We would like to use that GPIO for the ACT LED instead.
Is this done in the VC4 firmware, in the kernel or somewhere else?

Any help would be appreciated.

We are currently waiting for our access to source code with Broadcom (SLA is signed), but just trying to discover this information ahead of time.

Thanks in advance.

[ShiftPlusOne]

This should provide some of the information you're after.

https://github.com/raspberrypi/document ... uration.md

[WanaGo]

yes this is great, thank you!

On the B+ however, the Card Detect line isnt mentioned... so surely there has to be somewhere in code telling the system to ignore that a Card Detect is even needed now, right?

If GPIO47 was Card Detect on the A/B models, then that is GND'ed when a card is inserted. There must be code detecting this and if 47 is GNDed then to do something... is that code located somewhere now?

Thanks

[WanaGo]

Also, is it the VC4 firmware which tells the kernel what board it is, REV1 vs REV2 vs B+ ?
So then the kernel (I assume its the kernel) knows which part of this blob (?) to load?

Our VC4 is custom so we can handle this if it is ( I am still learning the ins and out of all this myself though ).

Thanks

[Burngate]

Card Detect

Apparently, although GPIO 47 was connected on Rev 1 & Rev 2, Raspbian didn't use it, so for the B+ it was re-purposed for the ACT led. The original ACT led GPIO 16 is now on pin 36 of the header.

RISC-OS did, however, use the Card Detect. They've had to do a rewrite to get round it.

[WanaGo]

Hi again.

Just some more questions about this document.
https://github.com/raspberrypi/document ... uration.md

inside the dt-blob.dts file, it has pins_rev1, pins_rev2, pins_bplus etc.
Where abouts is it defined as to which is being used at any given time?
I assume there is some sort of parameter somewhere which determines what the given hardware is and therefore which section of the dt-blob should be 'used'?

Can someone set me straight. Just getting my head around this

Thanks

[ShiftPlusOne]

Hi again.

Just some more questions about this document.
https://github.com/raspberrypi/document ... uration.md

inside the dt-blob.dts file, it has pins_rev1, pins_rev2, pins_bplus etc.
Where abouts is it defined as to which is being used at any given time?
I assume there is some sort of parameter somewhere which determines what the given hardware is and therefore which section of the dt-blob should be 'used'?

Can someone set me straight. Just getting my head around this

Thanks

That's determnined automagically, given the revision and memory chip.

[WanaGo]

Hmm ok. Not quite what I was hoping for.

We are building a custom product with support from Broadcom and a design house.
Ideally I would like to find out how how automagic does determine it and if it can be infulenced so we can direct it to the correct section in the blob.
Where is the revision stored exactly?
How can I make it point to an entirely new section of the dt-blob. Currently it is using the rev2 section. Ideally I want to keep everything to do with the Raspberry Pi seperate, rather than editing one of the existing entries in the blob.

We already have the source code for the VC4 firmware and can generate our own start.elf file now, and I did some searching and I cannot find what I am looking for yet.

If this is a top secret thing, can someone please PM me. I would appreciate the insite so we at least understand what is going on rather than guessing and making a mistake for our customers.

Thanks

[ShiftPlusOne]

Since this doesn't really have anything to do with the raspberry pi, I can't offer any support.

[WanaGo]

That is unfortunate.

The product we are building is not a competitor of the Raspberry Pi in any way, and will be sold to a very niche market.

I do wish you would reconsider and provide me with some information please.

Regards

[ShiftPlusOne]

Being an intern, I don't decide these things. My personal rule is to not giving out information that's not publicly available, no matter how trivial.

[AndrewS]

AFAIK the revision is stored in the BCM2835's OTP (One Time Programmable memory) - http://www.raspberrypi.org/forums/searc ... s=otp_dump will give you more info about that.

For a list of previous revision values see http://elinux.org/RPi_HardwareHistory and http://raspberryalphaomega.org.uk/2013/ ... b1-and-b2/ although they both seem to be missing the values for the B+ and ComputeModule.

And regarding your original question, also see http://www.raspberrypi.org/forums/viewt ... 52#p571452

Most of the info is out there, you just need to find it and piece it all together...

[WanaGo]

Excellent, thank you.
Its its in the OTP then we can manage that also.
I will do more reading, many thanks.