capemgr.disable_partno=BB-BONE-EMMC-2G does not work?

[Bas Laarhoven]

The HDMI can be disabled with "capemgr.disable_partno=BB-BONELT-HDMI".

But if I ad a similar option to disable the EMCC it does not work. Any
ideas?

-- Bas

[Charles Steinkuehler]

I haven't tried doing this from the kernel command line yet, but I did
manage to unload the eMMC driver at runtime with no ill effects
(although I'm not sure if I was just lucky...unloading overlays seems
extremely rough around the edges).

Did you try this with two capemgr.disable_partno= stanzas, or with
multiple part numbers in one stanza? I haven't dug through the code to
see what capemgr is expecting to see.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas Laarhoven]

Thanks, Charles. You saved my day! Separating the part numbers with a
comma does indeed work.
I just didn't notice because (although the cape manager is ignoring the
eMMC) the pins are still being activated by the kernel during boot : (

-- Bas

[Charles Steinkuehler]

On 6/6/2013 6:30 AM, Bas Laarhoven wrote:
> Thanks, Charles. You saved my day! Separating the part numbers with a
> comma does indeed work.
> I just didn't notice because (although the cape manager is ignoring the
> eMMC) the pins are still being activated by the kernel during boot : (

Yeah, that's why the eMMC pins are still commented out in my device tree
overlay. I'm away from my lab and can't verify the boot-loader or
kernel aren't twiddling them before the system comes up. Sounds like
I'm right to worry.

I may be re-soldering the boot mode resistors on my 'black in the
not-too-distant future! :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas Laarhoven]

On 6-6-2013 13:40, Charles Steinkuehler wrote:
> On 6/6/2013 6:30 AM, Bas Laarhoven wrote:
>> Thanks, Charles. You saved my day! Separating the part numbers with a
>> comma does indeed work.
>> I just didn't notice because (although the cape manager is ignoring the
>> eMMC) the pins are still being activated by the kernel during boot : (
> Yeah, that's why the eMMC pins are still commented out in my device tree
> overlay. I'm away from my lab and can't verify the boot-loader or
> kernel aren't twiddling them before the system comes up. Sounds like
> I'm right to worry.

Just got it confirmed: The kernel (3.8.13) enables the MMC during boot
although the cape manager did skip the loading of the cape. Then the
kernel activates the MMC signals on P8. This is probably a bug?

>
> I may be re-soldering the boot mode resistors on my 'black in the
> not-too-distant future! :)
>

Easiest way is probably to just short the boot button!

-- Bas

[Gerald Coley]

Shorting the boot button just changes the boot order and does not render the eMMC unusable or inactive.

Gerald

--

Gerald

 

ger...@beagleboard.org

g-co...@ti.com

http://beagleboard.org/

http://circuitco.com/support/

[Bas Laarhoven]

On 6-6-2013 14:07, Gerald Coley wrote:

Shorting the boot button just changes the boot order and does not render the eMMC unusable or inactive.

Gerald

On Thu, Jun 6, 2013 at 7:01 AM, Bas Laarhoven <sj...@xs4all.nl> wrote:

On 6-6-2013 13:40, Charles Steinkuehler wrote:

On 6/6/2013 6:30 AM, Bas Laarhoven wrote:

Thanks, Charles. You saved my day! Separating the part numbers with a
comma does indeed work.
I just didn't notice because (although the cape manager is ignoring the
eMMC) the pins are still being activated by the kernel during boot : (

Yeah, that's why the eMMC pins are still commented out in my device tree
overlay.  I'm away from my lab and can't verify the boot-loader or
kernel aren't twiddling them before the system comes up.  Sounds like
I'm right to worry.

Just got it confirmed: The kernel (3.8.13) enables the MMC during boot although the cape manager did skip the loading of the cape. Then the kernel activates the MMC signals on P8. This is probably a bug?

Gerald, what's your opinion here. Is this intentional or will this be fixed?

-- Bas

I may be re-soldering the boot mode resistors on my 'black in the
not-too-distant future!  :)

Easiest way is probably to just short the boot button!

-- Bas

--

Gerald

 

ger...@beagleboard.org

g-co...@ti.com

http://beagleboard.org/

http://circuitco.com/support/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Gerald Coley]

I see you consider it an issue to be "fixed" but others may not. I do not see it as an issue that can easily be fixed. Everyone needs to be in agreement as to what the "issue

" is and if it can or should be "fixed". So for now, consider it intentional.

Of course you are free to fix it via a patch in your own Uboot and kernel builds.

Gerald

[Bas Laarhoven]

Gerald,

I'm not sure if we understand each other: Are you saying that although some feature is disabled via the DT, the corresponding driver then can do whatever it wants? If this is true either I don't understand the DT concept (not entirely impossible), or the implementation is badly broken. Maybe some DT expert can have a say here...

-- Bas

[Gerald Coley]

I am the hadrware guy. I hate the DT. It has been nothing but a disaster. But Linus did not ask me for my opinion as I am an outsider.

For an explanation of DT I suggest you go to http://circuitco.com/support/index.php?title=BeagleBone_Black_FAQ

However the cape manager works, or whatever needs to be fixed, or repaired, that is all up to the thousands of developers in the community to determine and come to an agreement. Best place to discuss this as I have mentioned before is on the IRC channel. http://beagleboard.org/Community/Live%20Chat

Gerald

[Charles Steinkuehler]

On 6/6/2013 8:11 AM, Gerald Coley wrote:
> I am the hadrware guy. I hate the DT. It has been nothing but a disaster.
> But Linus did not ask me for my opinion as I am an outsider.

I'm a hardware guy too, and while I'm away from my 'scope, I think the
issue is on the 'Black the MMC is accessed at the very start of the boot
process. I'm still crawling through the AM335x boot modes and the
'Black schematic, but do you know if there's an easy way to force the
'Black to boot directly off the SD card (ie: same boot mode as the
'White) and not talk to the MMC to try and find a boot loader?

If that's possible (and hopefully easy), it should be possible to avoid
any subsequent access to the MMC via a proper uBoot image and device
tree. Unless, of course, there's some sort of kernel bug, but I doubt
that's the case.

> For an explanation of DT I suggest you go to
> http://circuitco.com/support/index.php?title=BeagleBone_Black_FAQ
>
> However the cape manager works, or whatever needs to be fixed, or repaired,
> that is all up to the thousands of developers in the community to determine
> and come to an agreement. Best place to discuss this as I have mentioned
> before is on the IRC channel. http://beagleboard.org/Community/Live%20Chat

So far I'm kind of liking device tree for it's intended use (defining a
static hardware layout at boot time). IMHO the problems everyone is
having are mostly related to trying to layer dynamic hot-plugging on top
of this architecture that was intended to be static.

...but I'm not sure what would work better. Maybe we can ask the TI
folks to re-architect all the SoC driver code to fully support the
hot-plug infrastructure?!? ;-) <just kidding!>

--
Charles Steinkuehler
cha...@steinkuehler.net

[Gerald Coley]

You can force a boot by removing the MLO from the eMMC card, erasing it, or holding the Boot button down. However, shorting the Boot button also shorts the LCD pin causing the HDMI image to be affected. If you do not want he UBoot to enable the eMMC, then simply change the code to enable eMMC, activate the RESET pin, and activate the reset pin and then move on.

I like the DT for its intended use as well. It is the lack of desire, people reading the documentation, training, and understanding that is missing. A lot of people seem to want it to work their way. Cape manager is intended to allow on the fly configuration based on the capes plugged in, something that DT does not seem to handle very well natively.

Well, as to the TI folks archictecting this, that is not exactly under their control if they want to be Linux compatible. Cape manager is an attempt to do the hot plug, outside of what the Linux community seem to dictate. But, even it has to fit into the current and future DT architecture. Then again, there is always Windows!!

Gerald

[Charles Steinkuehler]

On 6/6/2013 8:59 AM, Gerald Coley wrote:
> You can force a boot by removing the MLO from the eMMC card, erasing it, or
> holding the Boot button down. However, shorting the Boot button also shorts
> the LCD pin causing the HDMI image to be affected. If you do not want he
> UBoot to enable the eMMC, then simply change the code to enable eMMC,
> activate the RESET pin, and activate the reset pin and then move on.

I've now crawled through the docs, and it looks like holding the boot
button down at power-on will work for the BeBoPr board, but this doesn't
fully replicate the 'White behavior as now the SPI0 pins are twiddled by
the ROM code which the 'White doesn't do. It's also not likely users
will remember to hold the button down every time they boot.

Since the BeBoPr board doesn't use any of the SPI pins, it would be
enough to swap one resistor (move R68 to R93) which will make the board
behave like the boot button is always pressed (but not short the
LCD_DATA2 line to ground). This would work for any capes that don't
mind the SPI0 lines twiddling while the ROM code tries to boot before it
falls back to the SD card (MMC0).

To fully mimic the 'White is a bit more complex:

Move R67 to R92 (SYS_BOOT3 = 0)
Leave R68 alone (SYS_BOOT2 = 1)
Move R94 to R69 (SYS_BOOT1 = 1)
Move R95 to R70 (SYS_BOOT0 = 1)

This will boot from the SD card slot first, without trying to boot from
any other source (the same boot mode used on the BeagleBone white), but
software somewhere will need to insure the eMMC reset line for the
'Black is asserted before anything tries to talk to the pins connected
to the eMMC interface.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Gerald Coley]

That is why the resistors are there if you choose to use them.

Gerald

--
Charles Steinkuehler
cha...@steinkuehler.net

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bas Laarhoven]

This is now solved. I found the reason why mmc2 was left enabled,
even when the eMMC was disabled (by a capemgr override). It's not in
the kernel but just a DT (mis)configuration.

With this fix, after u-boot is done, a Black can act just like a White
on the P8 (no bus contention).

I've sent a patch to Koen. For people compiling their own kernel: In
"arch/arm/boot/dts/am335x-boneblack.dts", find the section starting
with "&mmc2 {" and in section change  status = "okay" into "disabled".

On a black this setting is overridden by the BB-BONE-EMMC-2G overlay
that enables the device. So by default it will work like before!

Besides disabling the mmc2 bus, the eMMC should be kept quiet too.
This can be done by keeping the eMMC in reset, as has often been said
on this list. But no software solution for that was given. I was able to do
this by adding a line with
   gpio set 52
at  the start of my uEnv.txt file. This will assert the reset to the eMMC,
and as long as if the mmc2 driver is kept disabled it will remain asserted.
(unless someone starts fooling around with gpio1[20]).

One more step: the eMMC device must be programmed to accept the
reset signal. This seems to be a non-volatile setting, so this has to be done
once for each BBB. Go to the u-boot prompt and type:
   mmc dev 1
   mmc rstn 1
(Or add these lines to the start of your uEnv.txt file, reboot once and remove
them again)

Have Fun,

-- Bas

[Bas Laarhoven]

-- Bas

[Jack Zhang]

Hi Bas,

By disabling the mmc2 from the DT file, my board wouldn't even boot. So how do you get around that?

Jack

[Bas Laarhoven]

Jack,

I seem to have left out some of the details. You need an SD card that replaces your
eMMC storage. So the Black will behave like a White: It needs an SD card to boot
from (and for the root filesystem).

Only the first stage (MLO and u-boot.img) is loaded from the eMMC device.
U-boot then takes over and tries to find a uEnv.txt file. If one is found on the SD-card,
that environment is loaded and the boot process resumes as defined by uEnv.txt
from the SD-card. I've found no need to press the BOOT button.

My SD card boots Wheezy, the image was made by Michael Haberler. I think it's pretty
generic. Maybe Charles can comment on that, I think he's using the same image with his
LinuxCNC port.

-- Bas

[Jack Zhang]

Don't worry I solved it! https://groups.google.com/forum/#!category-topic/beagleboard/gpmc/QENqyIYTlO0