[beagleboard] Re: Can I run Debian 7's beaglebone-black-eMMC-flasher.sh to upgrade to 9?

[Chris Green]

Dennis Lee Bieber  wrote:
> On Mon, 2 Apr 2018 17:34:18 +0100, Chris Green
>  declaimed the following:
> 
> >
> >I need to run my script above with the 'flasher' image
> >
> >or:-
> >
> >If I have a 'flasher' image on the microSD it will install itself
> >
> >
> 
> A flasher image /will/ flash to the eMMC -- WHEN the system boots from
> the SD card.
> 
> But if your device is old enough, it won't boot the SD card unless you
> hold down the boot button when applying power.
> 
> Newer eMMC images check for a bootable SD card and transfer control to
> it automatically.
> 
OK, that makes *some* sense but not altogether.

My (presumably 'flasher') Debian 9 image installed itself
automatically on an old (2Gb A6A) BBB that I tried it in.  However it
*didn't* do the same when plugged into what I'm pretty sure is a newer
(4Gb Bxx) BBB which is the one I actually want to upgrade.

I'll try holding the boot button down when I power up and see if that
works.

Thanks.

-- 
Chris Green
·

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cp0cpe-p63.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Can I run Debian 7's beaglebone-black-eMMC-flasher.sh to upgrade to 9?

[Chris Green]

Chris Green  wrote:
> In my quest to upgrade Debian 7 to Debian 9 I have found the script 
> /opt/scripts/tools/beaglebone-black-eMMC-flasher.sh.
> 
> If I run this script (as root) with the Debian 9 image on a mounted
> microSD card will the Debian 9 image get copied to the eMMC?  There
> are some prerequsites noted in the script which I will check, apart
> from these should it work?  I've kept my Debian 7 up to date so this
> script should (I suppose) be OK.
> 
Well I tried running the above script and it copied *loads* of files
(I think *from* the old Debian) and then said:-


sent 1452073606 bytes  received 1171735 bytes  2113811.41 bytes/sec total size 
is 1447416799  speedup is 1.00
`/tmp/rootfs/opt/scripts/images/beaglebg.jpg' -> 
`/tmp/rootfs/opt/desktop-background.jpg'
ln: failed to create symbolic link `/tmp/rootfs/etc/rc2.d/S18led_aging': File 
exists

but no update.

-- 
Chris Green
·

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bk8cpe-ts4.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Does not detect RTC (ds1307)

[Ron B.]

The kernel driver isn't seeing the RTC.  If it did, it would have claimed 
the I2C address and there would be "UU" in it's place instead of the 
address.  You're either missing the correct kernel driver for your RTC or 
the device tree isn't set up for this scenario.  I don't use any RTC parts 
so I can't help further.

Also, hwclock needs an RTC device like "/dev/rtc0".  You're pointing it to 
the I2C bus device.  That's why the "invalid IOCTL" message.

-Ron

On Monday, April 2, 2018 at 9:35:12 AM UTC-5, Paco Velasco wrote:
>
>
> 
>
>
> This is the screen when I connect a new beaglebone green with an rtc.
>
> If I burn the latest image, the beaglebone does not detect the rtc.
>
> El jueves, 22 de marzo de 2018, 23:38:03 (UTC+1), Jeff Andich escribió:
>>
>> I'm working with the RTC (MCP794110) at the moment, but on a "BB-X15 - 
>> like" custom board platform.
>>
>> I'm not sure I follow. your post.. What's the I2C tool? Are you talking 
>> about attaching the RTC to the BBB via the I2C tool or a problem with 
>> reading the RTC on the BBB? Pardon my ignorance but does the BBB come with 
>> an RTC (e.g. MCP794110) installed?  The BB-X15 does..
>>
>> Did you enable the I2C bus the RTC is attached to in the dev. tree? On my 
>> platform, I had to enable the I2C bus (I2C3) in the dev. tree before the 
>> drivers for the RTC would load.
>>
>> Then with some "new" RTC's on some of my boards, but not all, I got 
>> "unable to read the hardware clock, I think, when the kernel is attempting 
>> to set the system clock from the hardware clock (see the following):
>>
>> ebian@BeagleBoard-X15:~$ dmesg|grep rtc
>> [1.551522] rtc-ds1307 2-006f: rtc core: registered mcp7941x as rtc0
>> [1.551652] rtc-ds1307 2-006f: 64 bytes nvram
>> [1.554511] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc 
>> as rtc2
>> [1.558261] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: rtc 
>> core: registered 4807.i2c:tps659 as rtc1
>> [1.997160] rtc-ds1307 2-006f: hctosys: unable to read the hardware 
>> clock.
>>
>> From what I've read on posts involving the RTC the following messages:
>>
>> 1) "unable to read the hardware clock" message and  the 
>> 2) hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: 
>> Invalid argument.
>>
>> are due to the RTC's time being not initialized or (?invalid?).  I've 
>> been able to work-around this by setting the clock, but initially I get 
>> warning #2 when I initialize the clock with a valid date/time.  I'm 
>> wondering if anyone can confirm if this is the correct fix for this 
>> scenario...
>>
>> Also, when PTC builds the BB-X15, and the BBB manufacture builds the 
>> BBB's  (assuming BBB's have a RTC installed), do they ensure that the RTC 
>> is correctly initialized prior to shipping to the distributors ?
>>
>>
>> On Wednesday, March 21, 2018 at 6:18:27 PM UTC-5, Graham wrote:
>>>
>>> Do you have pull-up resistors?
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>>
>>> On Monday, March 19, 2018 at 8:28:51 AM UTC-5, Paco Velasco wrote:

 When I connect the rtc it does not detect the 68 address (I2C Tool).

 I have test with 2 RTC diferent,and with the BBB I have no problem.

 Anybody knows what could be the problem? Thanks



-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7df37a9b-b50c-4921-a30d-f2f8fe16e7e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling SPI in BBB, Debian Stretch

[Jon Lundstrom]

Thank you Robert,

That did the trick.

However, it has the side-effect of turning my display all black.
I use a Newhaven display cape and according to its User Guide, there should 
be no conflict for these SPI-pins.
(http://www.newhavendisplay.com/userguides/NHD-7.0CTP-CAPE_User_Guide.pdf)

So I had a look at the assigned pins in 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups and see that following 
group is added (using diff):

> group: pinmux_bb_spi0_pins
> pin 84 (PIN84)
> pin 85 (PIN85)
> pin 86 (PIN86)
> pin 87 (PIN87)

which seems in order, but following groups were removed:

< group: pinmux_bb_lcd_pwm_backlight_pins
< pin 18 (PIN18)

< group: pinmux_bb_lcd_lcd_pins
< pin 40 (PIN40)
< pin 41 (PIN41)
< pin 42 (PIN42)
< pin 43 (PIN43)
< pin 44 (PIN44)
< pin 45 (PIN45)
< pin 46 (PIN46)
< pin 47 (PIN47)
< pin 48 (PIN48)
< pin 49 (PIN49)
< pin 50 (PIN50)
< pin 51 (PIN51)
< pin 52 (PIN52)
< pin 53 (PIN53)
< pin 54 (PIN54)
< pin 55 (PIN55)
< pin 15 (PIN15)
< pin 14 (PIN14)
< pin 13 (PIN13)
< pin 12 (PIN12)
< pin 11 (PIN11)
< pin 10 (PIN10)
< pin 9 (PIN9)
< pin 8 (PIN8)
< pin 56 (PIN56)
< pin 57 (PIN57)
< pin 58 (PIN58)
< pin 59 (PIN59)
< pin 35 (PIN35)

< group: pinmux_edt_ft5x06_pins
< pin 105 (PIN105)

I don't know about the last group (PIN105) but the other two groups most 
certainly affect the display function.

I haven't seen the corresponding .dts-file for BB-SPIDEV0-00A0.dtbo, but I 
tried making my own that should not touch these pins: Still, the same 
result (same pin groups are removed). 

There seems to be some mechanism that disables the display pins when adding 
an overlay to the uEnv.txt. 

Robert, as an expert in BBB, do you have answer to this?

Best regards,
Jon Lundström.



Den torsdag 29 mars 2018 kl. 17:40:43 UTC+2 skrev RobertCNelson:
>
> On Thu, Mar 29, 2018 at 10:35 AM, Jon Lundstrom  > wrote: 
> > I'm trying to enable SPI on my BBB but constantly fail following the 
> advises 
> > I find in the forums. 
> > 
> > It seems like echoing anything into 
> /sys/devices/platform/bone_capemgr/slots 
> > is obsolete. Instead I should set up in /boot/uEnv.txt, but how? What 
> should 
> > I add in that file? 
> > 
> > I've tried: 
> > cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0 
> > or: 
> > optargs=quiet drm.debug=7 capemgr.enable_partno=BB-SPI0-01 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
>
> uboot_overlay_addr0=/lib/firmware/BB-SPIDEV0-00A0.dtbo 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c4eca54b-eb07-4e04-9eee-4d1389aff13e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enabling SPI in BBB, Debian Stretch

[Robert Nelson]

On Tue, Apr 3, 2018 at 10:26 AM, Jon Lundstrom  wrote:
>
> Thank you Robert,
>
> That did the trick.
>
> However, it has the side-effect of turning my display all black.
> I use a Newhaven display cape and according to its User Guide, there should
> be no conflict for these SPI-pins.
> (http://www.newhavendisplay.com/userguides/NHD-7.0CTP-CAPE_User_Guide.pdf)
>
> So I had a look at the assigned pins in
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups and see that following
> group is added (using diff):
>
>> group: pinmux_bb_spi0_pins
>> pin 84 (PIN84)
>> pin 85 (PIN85)
>> pin 86 (PIN86)
>> pin 87 (PIN87)
>
> which seems in order, but following groups were removed:
>
> < group: pinmux_bb_lcd_pwm_backlight_pins
> < pin 18 (PIN18)
>
> < group: pinmux_bb_lcd_lcd_pins
> < pin 40 (PIN40)
> < pin 41 (PIN41)
> < pin 42 (PIN42)
> < pin 43 (PIN43)
> < pin 44 (PIN44)
> < pin 45 (PIN45)
> < pin 46 (PIN46)
> < pin 47 (PIN47)
> < pin 48 (PIN48)
> < pin 49 (PIN49)
> < pin 50 (PIN50)
> < pin 51 (PIN51)
> < pin 52 (PIN52)
> < pin 53 (PIN53)
> < pin 54 (PIN54)
> < pin 55 (PIN55)
> < pin 15 (PIN15)
> < pin 14 (PIN14)
> < pin 13 (PIN13)
> < pin 12 (PIN12)
> < pin 11 (PIN11)
> < pin 10 (PIN10)
> < pin 9 (PIN9)
> < pin 8 (PIN8)
> < pin 56 (PIN56)
> < pin 57 (PIN57)
> < pin 58 (PIN58)
> < pin 59 (PIN59)
> < pin 35 (PIN35)
>
> < group: pinmux_edt_ft5x06_pins
> < pin 105 (PIN105)
>
> I don't know about the last group (PIN105) but the other two groups most
> certainly affect the display function.
>
> I haven't seen the corresponding .dts-file for BB-SPIDEV0-00A0.dtbo, but I
> tried making my own that should not touch these pins: Still, the same result
> (same pin groups are removed).
>
> There seems to be some mechanism that disables the display pins when adding
> an overlay to the uEnv.txt.
>
> Robert, as an expert in BBB, do you have answer to this?

Well, addr0 -> addr3 is for eeprom detected capes, so change:

uboot_overlay_addr0=/lib/firmware/BB-SPIDEV0-00A0.dtbo

to

uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo

https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYh%2B7eVk0Eib5KXk7tZ2EmUqxt11QRw8Un_db8fUWV__WA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Installing Debian "Buster" (or libqmi 1.20) on BBB

[leo . e . meza]

Hi all,

I'm having issues using libqmi (v1.16.x), currently with Debian "Stretch" 
installed. I'm trying to get the latest libqmi (v1.20), but I ran into 
dependency issues when trying to install libqmi 1.20 from source. So, now 
I'm looking at installing Debian "Buster" which I believe is packaged with 
libqmi v1.20. One of my problems now is that I'm a bit of a noob when it 
comes to building images as described 
here: https://elinux.org/BeagleBoardDebian

Can anyone tell me how to build a "Buster" image to run off my SD card (no 
flashing to eMMC necessary)?

Thanks in advance

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9fee119e-a74d-477c-b1bd-727e812f29b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Installing Debian "Buster" (or libqmi 1.20) on BBB

[Robert Nelson]

On Tue, Apr 3, 2018 at 9:24 AM,   wrote:
> Hi all,
>
> I'm having issues using libqmi (v1.16.x), currently with Debian "Stretch"
> installed. I'm trying to get the latest libqmi (v1.20), but I ran into
> dependency issues when trying to install libqmi 1.20 from source. So, now
> I'm looking at installing Debian "Buster" which I believe is packaged with
> libqmi v1.20. One of my problems now is that I'm a bit of a noob when it
> comes to building images as described here:
> https://elinux.org/BeagleBoardDebian
>
> Can anyone tell me how to build a "Buster" image to run off my SD card (no
> flashing to eMMC necessary)?

This one should be pretty normal:

v4.14.x-ti + ext4

https://rcn-ee.net/rootfs/bb.org/testing/2018-03-25/buster-iot/bone-debian-buster-iot-armhf-2018-03-25-4gb.img.xz

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgx1OZ8jSu%2BFMgtjdFgWidhym7KzzavBocCYzwMdXtYvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Running from eMMC will / "always" be mounted on /dev/mmcblk1p1, From SD Always/ on /dev/mmcblk0p1 ?

[Jeff Andich]

Hi,

When Linux and our application is running from eMMC, we wish to be able to 
create log files on a uSD card plugged into the uSD slot on our board.

I've ported some scripts which a former colleague wrote for the BeagleBone 
Black that create a mount point on a factory default SD card if the SD card 
exists, and re-formats the FAT to an ext4 partition.  Basically they used a 
udev script to trigger on the presence of /dev/mmcblk0p1 or /dev/mmcblk1p1 
and then call a shell script (from a systemd service launched by udev) for 
formatting and mounting the SD card.

One key thing that that shell script did was to detect where Linux was 
running (e.g. /dev/mmcblk0p1 vs mmcblk1p1) based on examining the label of 
the storage device, and then mounting the other device if it exists.  This 
capability to handle the '/' mount point "pingponging" between /dev/mmcblk0 
and mmcblk1 was needed due to the mount point changing for the eMMC 
depending on whether an uSD card was plugged into the slot on the 
BeagleBone Black with kernel 3.8.?.

However, on the baseline images I've been using for the BB-X15, I haven't 
yet observed any pingponging in that '/' always SEEMS to be mounted on 
/dev/mmcblk1 when running from eMMC and /dev/mmcblk0p1 when running from 
uSD card.  I've been working with a BB-X15 console image consisting of  
(Debian 8.10, kernel 4.4.110, and some variant of u-boot 2017.01), 

?? Will this always be the case for the BB-X15 (and other devices) or at 
least with the Debian version, kernel version, and u-boot version we're 
using??  

If so I'd like to take advantage of this fact in the shell script to only 
create a mount point on the SD card when it doesn't contain a Linux image 
and when '/' is mounted on /dev/mmcblk1p1.  But I'm afraid that this 
assumption may not hold and come back to bite us at some point.


Thanks in advance!

Jeff


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d0b5a93a-54c8-4b45-b79e-71213b2ce310%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running from eMMC will / "always" be mounted on /dev/mmcblk1p1, From SD Always/ on /dev/mmcblk0p1 ?

[Robert Nelson]

On Tue, Apr 3, 2018 at 3:53 PM, Jeff Andich  wrote:
> Hi,
>
> When Linux and our application is running from eMMC, we wish to be able to
> create log files on a uSD card plugged into the uSD slot on our board.
>
> I've ported some scripts which a former colleague wrote for the BeagleBone
> Black that create a mount point on a factory default SD card if the SD card
> exists, and re-formats the FAT to an ext4 partition.  Basically they used a
> udev script to trigger on the presence of /dev/mmcblk0p1 or /dev/mmcblk1p1
> and then call a shell script (from a systemd service launched by udev) for
> formatting and mounting the SD card.
>
> One key thing that that shell script did was to detect where Linux was
> running (e.g. /dev/mmcblk0p1 vs mmcblk1p1) based on examining the label of
> the storage device, and then mounting the other device if it exists.  This
> capability to handle the '/' mount point "pingponging" between /dev/mmcblk0
> and mmcblk1 was needed due to the mount point changing for the eMMC
> depending on whether an uSD card was plugged into the slot on the BeagleBone
> Black with kernel 3.8.?.
>
> However, on the baseline images I've been using for the BB-X15, I haven't
> yet observed any pingponging in that '/' always SEEMS to be mounted on
> /dev/mmcblk1 when running from eMMC and /dev/mmcblk0p1 when running from uSD
> card.  I've been working with a BB-X15 console image consisting of  (Debian
> 8.10, kernel 4.4.110, and some variant of u-boot 2017.01),
>
> ?? Will this always be the case for the BB-X15 (and other devices) or at
> least with the Debian version, kernel version, and u-boot version we're
> using??
>
> If so I'd like to take advantage of this fact in the shell script to only
> create a mount point on the SD card when it doesn't contain a Linux image
> and when '/' is mounted on /dev/mmcblk1p1.  But I'm afraid that this
> assumption may not hold and come back to bite us at some point.

According to my notes, this "randomness-race-label" condition was
first "fixed" in the v4.5.x merge and "really" fixed in v4.5.3

We back-ported these two fixes to our v4.4.x-ti tree for the bbb and bbx15.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=58821da858919f93f85c7e6823b49d439722a9e9

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=520bd7a8b4152aacfbd34eb7f7a447354b631039

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiZCEhN%3D3vP6k8Tqkg-QE17pB53QDVVFUdbRvYHtwD%2BCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running from eMMC will / "always" be mounted on /dev/mmcblk1p1, From SD Always/ on /dev/mmcblk0p1 ?

[Jeff Andich]

Thanks Robert!!

...One of these days, I need to be following what's going on with the 
commits and the upstream...

Regards,

jeff




On Tuesday, April 3, 2018 at 4:05:42 PM UTC-5, RobertCNelson wrote:
>
> On Tue, Apr 3, 2018 at 3:53 PM, Jeff Andich  > wrote: 
> > Hi, 
> > 
> > When Linux and our application is running from eMMC, we wish to be able 
> to 
> > create log files on a uSD card plugged into the uSD slot on our board. 
> > 
> > I've ported some scripts which a former colleague wrote for the 
> BeagleBone 
> > Black that create a mount point on a factory default SD card if the SD 
> card 
> > exists, and re-formats the FAT to an ext4 partition.  Basically they 
> used a 
> > udev script to trigger on the presence of /dev/mmcblk0p1 or 
> /dev/mmcblk1p1 
> > and then call a shell script (from a systemd service launched by udev) 
> for 
> > formatting and mounting the SD card. 
> > 
> > One key thing that that shell script did was to detect where Linux was 
> > running (e.g. /dev/mmcblk0p1 vs mmcblk1p1) based on examining the label 
> of 
> > the storage device, and then mounting the other device if it exists. 
>  This 
> > capability to handle the '/' mount point "pingponging" between 
> /dev/mmcblk0 
> > and mmcblk1 was needed due to the mount point changing for the eMMC 
> > depending on whether an uSD card was plugged into the slot on the 
> BeagleBone 
> > Black with kernel 3.8.?. 
> > 
> > However, on the baseline images I've been using for the BB-X15, I 
> haven't 
> > yet observed any pingponging in that '/' always SEEMS to be mounted on 
> > /dev/mmcblk1 when running from eMMC and /dev/mmcblk0p1 when running from 
> uSD 
> > card.  I've been working with a BB-X15 console image consisting of 
>  (Debian 
> > 8.10, kernel 4.4.110, and some variant of u-boot 2017.01), 
> > 
> > ?? Will this always be the case for the BB-X15 (and other devices) or at 
> > least with the Debian version, kernel version, and u-boot version we're 
> > using?? 
> > 
> > If so I'd like to take advantage of this fact in the shell script to 
> only 
> > create a mount point on the SD card when it doesn't contain a Linux 
> image 
> > and when '/' is mounted on /dev/mmcblk1p1.  But I'm afraid that this 
> > assumption may not hold and come back to bite us at some point. 
>
> According to my notes, this "randomness-race-label" condition was 
> first "fixed" in the v4.5.x merge and "really" fixed in v4.5.3 
>
> We back-ported these two fixes to our v4.4.x-ti tree for the bbb and 
> bbx15. 
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=58821da858919f93f85c7e6823b49d439722a9e9
>  
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=520bd7a8b4152aacfbd34eb7f7a447354b631039
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b87a5604-9487-4fec-95bf-a16912c23231%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: kernel 4.16.0-rc7-bone7 boot hangs

[Robert Nelson]

On Sun, Apr 1, 2018 at 1:51 AM, Drew Fustini  wrote:
> fyi - kernel 4.16.0-rc6-bone7 does work OK.  It is just the
> 4.16.0-rc7-bone7 kernel that hangs.
>
> On Sun, Apr 1, 2018 at 12:22 AM, Drew Fustini  wrote:
>> Robert -
>>
>> I'm using a BeagleBone Black Rev C running Stretch IoT 2018-03-25 SD
>> card image.  Kernel 4.16.0-rc2-bone3 boots OK.
>>
>> I recently updated to the latest mainline rc kernel with:
>>
>> /opt/scripts/tools/update_kernel.sh --exp-kernel --bone-kernel
>>
>> However, boot of 4.16.0-rc7-bone7 kernel hangs after "Starting kernel ..."
>>
>> Full serial console output:
>> https://gist.github.com/pdp7/3d49624f182cd28a3b3a72dbbd7aa493
>>
>> Any idea?

This looks like a fun one..

First git bisect run, lead to a false positive.

Here goes run #2. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYh8uvukbdOH9o_kNbqxZUc7gLj%3DmUPuTvqO6Fn%3DBf8POw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] can't enable PRU with kernel 4.4.113-ti-r145

[Sebastián Sáez]

Hi!,

I'm follow this tutorial, but I can't enable the PRU output
http://jkuhlm.bplaced.net/beaglebone-433mhz-transmitter/

root@beaglebone:~/rfsend# config-pin p8.11 pruout
> P8_11 pinmux file not found!
> Pin has no cape: P8_11


After some research in the forum I think maybe it's a problem with the 
kernel version, but I have no clue

In /boot/uEnv.txt this is line is uncomment
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo


This is my system (beaglebone green wireless)

> sudo /opt/scripts/tools/version.sh
> git:/opt/scripts/:[70edebd65fe6ea7de16ea8efe3c48b2a4062034a]
> eeprom:[A335BNLTGW1ABBGW16050761]
> model:[TI_AM335x_BeagleBone_Green_Wireless]
> dogtag:[BeagleBoard.org Debian Image 2018-02-01]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.01-2-g9aa111a004]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2017.03-2-gd12b1519b4]:[location: dd MBR]
> kernel:[4.4.113-ti-r145]
> nodejs:[v0.12.18]
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg:[bb-cape-overlays]:[4.4.20180322.0-0rcnee0~jessie+20180322]
> pkg:[bb-wl18xx-firmware]:[1.20180328-0rcnee2~jessie+20180328]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~jessie+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal netdev i2c bluetooth cloud9ide gpio pwm eqep 
> admin spi tisdk weston-launch xenomai]
> cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
> rootwait coherent_pool=1M net.ifnames=0 quiet]
> dmesg | grep pinctrl-single
> [1.154434] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
> dmesg | grep gpio-of-helper
> [1.155146] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0
> [1.155293] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1
> [1.155305] gpio-of-helper ocp:cape-universal: ready
> END



regards,
Sebastián

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/53305601-35e6-4e39-a75b-c89cc67a383c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] can't enable PRU with kernel 4.4.113-ti-r145

[Robert Nelson]

On Tue, Apr 3, 2018 at 4:59 PM, Sebastián Sáez  wrote:
> Hi!,
>
> I'm follow this tutorial, but I can't enable the PRU output
> http://jkuhlm.bplaced.net/beaglebone-433mhz-transmitter/
>
>> root@beaglebone:~/rfsend# config-pin p8.11 pruout
>> P8_11 pinmux file not found!
>> Pin has no cape: P8_11
>
>
> After some research in the forum I think maybe it's a problem with the
> kernel version, but I have no clue
>
> In /boot/uEnv.txt this is line is uncomment
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
>
>
> This is my system (beaglebone green wireless)
>>
>> sudo /opt/scripts/tools/version.sh
>> git:/opt/scripts/:[70edebd65fe6ea7de16ea8efe3c48b2a4062034a]
>> eeprom:[A335BNLTGW1ABBGW16050761]
>> model:[TI_AM335x_BeagleBone_Green_Wireless]
>> dogtag:[BeagleBoard.org Debian Image 2018-02-01]
>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
>> 2018.01-2-g9aa111a004]:[location: dd MBR]

>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
>> 2017.03-2-gd12b1519b4]:[location: dd MBR]

The old version of u-boot in the eMMC is blocking u-boot overlays from
working correctly..

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Then reboot and it'll work just fine..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjYYdWfg7Qpekv90BVJ4Rzy_Rmc2xodPRP5NDcsyNLypA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] can't enable PRU with kernel 4.4.113-ti-r145

[Sebastián Sáez]

thank!, I do the cmd but now the linux is not booting

this is the serial log

> U-Boot SPL 2018.01-2-g9aa111a004 (Jan 20 2018 - 12:45:29)
>
> Trying to boot from MMC1
>
>
>>
>> U-Boot 2018.01-2-g9aa111a004 (Jan 20 2018 - 12:45:29 -0600), Build: 
>> jenkins-github_Bootloader-Builder-32
>
>
>> CPU  : AM335X-GP rev 2.1
>
> I2C:   ready
>
> DRAM:  512 MiB
>
> No match for driver 'omap_hsmmc'
>
> No match for driver 'omap_hsmmc'
>
> Some drivers were not found
>
> Reset Source: Power-on reset has occurred.
>
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>
> Using default environment
>
>
>> Board: BeagleBone Black
>
>  not set. Validating first E-fuse MAC
>
> BeagleBone Black:
>
> Model: SeeedStudio BeagleBone Green Wireless:
>
> BeagleBone: cape eeprom: i2c_probe: 0x54:
>
> BeagleBone: cape eeprom: i2c_probe: 0x55:
>
> BeagleBone: cape eeprom: i2c_probe: 0x56:
>
> BeagleBone: cape eeprom: i2c_probe: 0x57:
>
> Net:   eth0: MII MODE
>
> Could not get PHY for cpsw: addr 0
>
> cpsw, usb_ether
>
> Press SPACE to abort autoboot in 2 seconds
>
> board_name=[A335BNLT] ...
>
> board_rev=[GW1A] ...
>
> switch to partitions #0, OK
>
> mmc0 is current device
>
> SD/MMC found on device 0
>
> ** Bad device 0:2 0x8200 **
>
> ** Bad device 0:2 0x8200 **
>
> switch to partitions #0, OK
>
> mmc0 is current device
>
> Scanning mmc 0:1...
>
> gpio: pin 56 (gpio 56) value is 0
>
> gpio: pin 55 (gpio 55) value is 0
>
> gpio: pin 54 (gpio 54) value is 0
>
> gpio: pin 53 (gpio 53) value is 1
>
> switch to partitions #0, OK
>
> mmc0 is current device
>
> gpio: pin 54 (gpio 54) value is 1
>
> Checking for: /uEnv.txt ...
>
> Checking for: /boot.scr ...
>
> Checking for: /boot/boot.scr ...
>
> Checking for: /boot/uEnv.txt ...
>
> gpio: pin 55 (gpio 55) value is 1
>
> 1867 bytes read in 43 ms (42 KiB/s)
>
> Loaded environment from /boot/uEnv.txt
>
> Checking if uname_r is set in /boot/uEnv.txt...
>
> gpio: pin 56 (gpio 56) value is 1
>
> Running uname_boot ...
>
> loading /boot/vmlinuz-4.4.125-bone22 ...
>
> 8506344 bytes read in 587 ms (13.8 MiB/s)
>
> uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
>
> uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
>
> loading /boot/dtbs/4.4.125-bone22/am335x-boneblack-uboot.dtb ...
>
> 50339 bytes read in 79 ms (622.1 KiB/s)
>
> uboot_overlays: [fdt_buffer=0x6] ...
>
> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
>
> 1440 bytes read in 179 ms (7.8 KiB/s)
>
> uboot_overlays: loading /lib/firmware/BB-BBGW-WL1835-00A0.dtbo ...
>
> 4839 bytes read in 69 ms (68.4 KiB/s)
>
> failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
>
> uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
>
> 711 bytes read in 219 ms (2.9 KiB/s)
>
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>
> failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
>
> base fdt does did not have a /__symbols__ node
>
> make sure you've compiled with -@
>
> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
>
> 883 bytes read in 162 ms (4.9 KiB/s)
>
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>
> failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
>
> base fdt does did not have a /__symbols__ node
>
> make sure you've compiled with -@
>
> uboot_overlays: loading /lib/firmware/univ-bbgw-EW-00A0.dtbo ...
>
> 82622 bytes read in 89 ms (906.3 KiB/s)
>
> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>
> failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
>
> base fdt does did not have a /__symbols__ node
>
> make sure you've compiled with -@
>
> loading /boot/initrd.img-4.4.125-bone22 ...
>
> 5415890 bytes read in 392 ms (13.2 MiB/s)
>
> debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>> net.ifnames=0 quiet] ...
>
> debug: [bootz 0x8200 0x8808:52a3d2 8800] ...
>
> ERROR: Did not find a cmdline Flattened Device Tree
>
> Could not find a valid device tree
>
> ** Invalid partition 2 **
>
> ** Invalid partition 3 **
>
> ** Invalid partition 4 **
>
> ** Invalid partition 5 **
>
> ** Invalid partition 6 **
>
> ** Invalid partition 7 **
>
> switch to partitions #0, OK
>
> mmc1(part 0) is current device
>
> ** No partition table - mmc 1 **
>
> gpio: pin 56 (gpio 56) value is 0
>
> gpio: pin 55 (gpio 55) value is 0
>
> gpio: pin 54 (gpio 54) value is 0
>
> gpio: pin 53 (gpio 53) value is 1
>
> switch to partitions #0, OK
>
> mmc1(part 0) is current device
>
> gpio: pin 54 (gpio 54) value is 1
>
> ** No partition table - mmc 1 **
>
> Checking for: /uEnv.txt ...
>
> ** No partition table - mmc 1 **
>
> Checking for: /boot.scr ...
>
> ** No partition table - mmc 1 **
>
> Checking for: /boot/boot.scr ...
>
> ** No partition table - mmc 1 **
>
> Checking for: /boot/uEnv.txt ...
>
> ** No partition table - mmc 1 **
>
> ** No partition table - mmc 1 **
>
> ** No partition table - mmc 1 **
>
> ** No partition table - mmc 1 **
>
> ** No partition table - mmc 1 **
>
> ** No partition table - mmc 

Re: [beagleboard] can't enable PRU with kernel 4.4.113-ti-r145

[Robert Nelson]

On Tue, Apr 3, 2018 at 5:11 PM, Sebastián Sáez  wrote:
> thank!, I do the cmd but now the linux is not booting
>
> this is the serial log
>>>
>>> U-Boot SPL 2018.01-2-g9aa111a004 (Jan 20 2018 - 12:45:29)
>>>
>>> Trying to boot from MMC1
>>>
>>>
>>>
>>> U-Boot 2018.01-2-g9aa111a004 (Jan 20 2018 - 12:45:29 -0600), Build:
>>> jenkins-github_Bootloader-Builder-32
>>>
>>>
>>> CPU  : AM335X-GP rev 2.1
>>>
>>> I2C:   ready
>>>
>>> DRAM:  512 MiB
>>>
>>> No match for driver 'omap_hsmmc'
>>>
>>> No match for driver 'omap_hsmmc'
>>>
>>> Some drivers were not found
>>>
>>> Reset Source: Power-on reset has occurred.
>>>
>>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
>>>
>>> Using default environment
>>>
>>>
>>> Board: BeagleBone Black
>>>
>>>  not set. Validating first E-fuse MAC
>>>
>>> BeagleBone Black:
>>>
>>> Model: SeeedStudio BeagleBone Green Wireless:
>>>
>>> BeagleBone: cape eeprom: i2c_probe: 0x54:
>>>
>>> BeagleBone: cape eeprom: i2c_probe: 0x55:
>>>
>>> BeagleBone: cape eeprom: i2c_probe: 0x56:
>>>
>>> BeagleBone: cape eeprom: i2c_probe: 0x57:
>>>
>>> Net:   eth0: MII MODE
>>>
>>> Could not get PHY for cpsw: addr 0
>>>
>>> cpsw, usb_ether
>>>
>>> Press SPACE to abort autoboot in 2 seconds
>>>
>>> board_name=[A335BNLT] ...
>>>
>>> board_rev=[GW1A] ...
>>>
>>> switch to partitions #0, OK
>>>
>>> mmc0 is current device
>>>
>>> SD/MMC found on device 0
>>>
>>> ** Bad device 0:2 0x8200 **
>>>
>>> ** Bad device 0:2 0x8200 **
>>>
>>> switch to partitions #0, OK
>>>
>>> mmc0 is current device
>>>
>>> Scanning mmc 0:1...
>>>
>>> gpio: pin 56 (gpio 56) value is 0
>>>
>>> gpio: pin 55 (gpio 55) value is 0
>>>
>>> gpio: pin 54 (gpio 54) value is 0
>>>
>>> gpio: pin 53 (gpio 53) value is 1
>>>
>>> switch to partitions #0, OK
>>>
>>> mmc0 is current device
>>>
>>> gpio: pin 54 (gpio 54) value is 1
>>>
>>> Checking for: /uEnv.txt ...
>>>
>>> Checking for: /boot.scr ...
>>>
>>> Checking for: /boot/boot.scr ...
>>>
>>> Checking for: /boot/uEnv.txt ...
>>>
>>> gpio: pin 55 (gpio 55) value is 1
>>>
>>> 1867 bytes read in 43 ms (42 KiB/s)
>>>
>>> Loaded environment from /boot/uEnv.txt
>>>
>>> Checking if uname_r is set in /boot/uEnv.txt...
>>>
>>> gpio: pin 56 (gpio 56) value is 1
>>>
>>> Running uname_boot ...
>>>
>>> loading /boot/vmlinuz-4.4.125-bone22 ...
>>>
>>> 8506344 bytes read in 587 ms (13.8 MiB/s)
>>>
>>> uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
>>>
>>> uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...
>>>
>>> loading /boot/dtbs/4.4.125-bone22/am335x-boneblack-uboot.dtb ...
>>>
>>> 50339 bytes read in 79 ms (622.1 KiB/s)
>>>
>>> uboot_overlays: [fdt_buffer=0x6] ...
>>>
>>> uboot_overlays: loading /lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo ...
>>>
>>> 1440 bytes read in 179 ms (7.8 KiB/s)
>>>
>>> uboot_overlays: loading /lib/firmware/BB-BBGW-WL1835-00A0.dtbo ...
>>>
>>> 4839 bytes read in 69 ms (68.4 KiB/s)
>>>
>>> failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
>>>
>>> uboot_overlays: loading /lib/firmware/BB-ADC-00A0.dtbo ...
>>>
>>> 711 bytes read in 219 ms (2.9 KiB/s)
>>>
>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>>
>>> failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
>>>
>>> base fdt does did not have a /__symbols__ node
>>>
>>> make sure you've compiled with -@
>>>
>>> uboot_overlays: loading /lib/firmware/AM335X-PRU-UIO-00A0.dtbo ...
>>>
>>> 883 bytes read in 162 ms (4.9 KiB/s)
>>>
>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>>
>>> failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
>>>
>>> base fdt does did not have a /__symbols__ node
>>>
>>> make sure you've compiled with -@
>>>
>>> uboot_overlays: loading /lib/firmware/univ-bbgw-EW-00A0.dtbo ...
>>>
>>> 82622 bytes read in 89 ms (906.3 KiB/s)
>>>
>>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
>>>
>>> failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
>>>
>>> base fdt does did not have a /__symbols__ node
>>>
>>> make sure you've compiled with -@
>>>
>>> loading /boot/initrd.img-4.4.125-bone22 ...
>>>
>>> 5415890 bytes read in 392 ms (13.2 MiB/s)
>>>
>>> debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
>>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M
>>> net.ifnames=0 quiet] ...
>>>
>>> debug: [bootz 0x8200 0x8808:52a3d2 8800] ...
>>>
>>> ERROR: Did not find a cmdline Flattened Device Tree
>>>
>>> Could not find a valid device tree

Okay that was weird, i'll retest that tomorrow at work..

4.4.125-bone22 + u-boot overlays should work..


libfdt fdt_check_header(): FDT_ERR_BADMAGIC
failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC
base fdt does did not have a /__symbols__ node
make sure you've compiled with -@


They were compiled with -@ wonder what failed...

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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 beagl

Re: [beagleboard] can't enable PRU with kernel 4.4.113-ti-r145

[Sebastián Sáez]

I burn a new microSD card with the same image and now the linux it's boot
>
> bone-debian-8.10-seeed-iot-armhf-2018-02-01-4gb.img


Try again and now this is the otuput
 

> config-pin p8.11 pruout

P8_11 pinmux file not found!
> bash: /sys/devices/platform/ocp/ocp*P8_11_pinmux/state: No such file or 
> directory
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P8_11_pinmux/state


here the new sytem info

sudo /opt/scripts/tools/version.sh
> git:/opt/scripts/:[ad016da40de5805f1a6f981cbb6c454b1a7f244b]
> eeprom:[A335BNLTGW1ABBGW16050761]
> model:[TI_AM335x_BeagleBone_Green_Wireless]
> dogtag:[BeagleBoard.org Debian Image 2018-02-01]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.01-2-g9aa111a004]
> kernel:[4.4.113-ti-r145]
> nodejs:[v0.12.18]
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg:[bb-cape-overlays]:[4.4.20180126.0-0rcnee0~jessie+20180126]
> pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~jessie+20180104]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~jessie+20170830]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal netdev i2c bluetooth cloud9ide gpio pwm eqep 
> admin spi tisdk weston-launch xenomai]
> dmesg | grep pinctrl-single
> [1.212781] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
> dmesg | grep gpio-of-helper
> [1.213903] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0
> [1.214074] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1
> [1.214218] gpio-of-helper ocp:cape-universal: Allocated GPIO id=2
> [1.214357] gpio-of-helper ocp:cape-universal: Allocated GPIO id=3
> [1.214497] gpio-of-helper ocp:cape-universal: Allocated GPIO id=4
> [1.214630] gpio-of-helper ocp:cape-universal: Allocated GPIO id=5
> [1.214762] gpio-of-helper ocp:cape-universal: Allocated GPIO id=6
> [1.214902] gpio-of-helper ocp:cape-universal: Allocated GPIO id=7
> [1.215048] gpio-of-helper ocp:cape-universal: Allocated GPIO id=8
> [1.215192] gpio-of-helper ocp:cape-universal: Allocated GPIO id=9
> [1.215327] gpio-of-helper ocp:cape-universal: Allocated GPIO id=10
> [1.215466] gpio-of-helper ocp:cape-universal: Allocated GPIO id=11
> [1.215609] gpio-of-helper ocp:cape-universal: Allocated GPIO id=12
> [1.215746] gpio-of-helper ocp:cape-universal: Allocated GPIO id=13
> [1.215882] gpio-of-helper ocp:cape-universal: Allocated GPIO id=14
> [1.216023] gpio-of-helper ocp:cape-universal: Allocated GPIO id=15
> [1.216634] gpio-of-helper ocp:cape-universal: Allocated GPIO id=16
> [1.216813] gpio-of-helper ocp:cape-universal: Allocated GPIO id=17
> [1.217031] gpio-of-helper ocp:cape-universal: Allocated GPIO id=18
> [1.217194] gpio-of-helper ocp:cape-universal: Allocated GPIO id=19
> [1.217341] gpio-of-helper ocp:cape-universal: Allocated GPIO id=20
> [1.217481] gpio-of-helper ocp:cape-universal: Allocated GPIO id=21
> [1.217619] gpio-of-helper ocp:cape-universal: Allocated GPIO id=22
> [1.217763] gpio-of-helper ocp:cape-universal: Allocated GPIO id=23
> [1.217902] gpio-of-helper ocp:cape-universal: Allocated GPIO id=24
> [1.218040] gpio-of-helper ocp:cape-universal: Allocated GPIO id=25
> [1.218193] gpio-of-helper ocp:cape-universal: Allocated GPIO id=26
> [1.218338] gpio-of-helper ocp:cape-universal: Allocated GPIO id=27
> [1.218486] gpio-of-helper ocp:cape-universal: Allocated GPIO id=28
> [1.218627] gpio-of-helper ocp:cape-universal: Allocated GPIO id=29
> [1.218769] gpio-of-helper ocp:cape-universal: Allocated GPIO id=30
> [1.218916] gpio-of-helper ocp:cape-universal: Allocated GPIO id=31
> [1.219057] gpio-of-helper ocp:cape-universal: Allocated GPIO id=32
> [1.219197] gpio-of-helper ocp:cape-universal: Allocated GPIO id=33
> [1.219349] gpio-of-helper ocp:cape-universal: Allocated GPIO id=34
> [1.219494] gpio-of-helper ocp:cape-universal: Allocated GPIO id=35
> [1.219643] gpio-of-helper ocp:cape-universal: Allocated GPIO id=36
> [1.219791] gpio-of-helper ocp:cape-universal: Allocated GPIO id=37
> [1.219933] gpio-of-helper ocp:cape-universal: Allocated GPIO id=38
> [1.220317] gpio-of-helper ocp:cape-universal: Allocated GPIO id=39
> [1.220485] gpio-of-helper ocp:cape-universal: Allocated GPIO id=40
> [1.220631] gpio-of-helper ocp:cape-universal: Allocated GPIO id=41
> [1.220785] gpio-of-helper ocp:cape-universal: Allocated GPIO id=42
> [1.220933] gpio-of-helper ocp:cape-universal: Allocated GPIO id=43
> [1.221079] gpio-of-helper ocp:cape-universal: Allocated GPIO id=44
> [1.221210] gpio-of-helper ocp:cape-universal: Allocated GPIO id=45
> [1.221221] gpio-of-helper ocp:cape-universal: ready
> END


thanks you for your time


regards,
Sebastián



On Tuesday, April 3, 20

Re: [beagleboard] Re: Cape Manager for U-Boot

[lgilbert]

I attached the dts files to a reply, did you get a chance to look at them?

best,

Leo

On Monday, March 26, 2018 at 6:27:56 PM UTC-7, RobertCNelson wrote:
>
> On Mon, Mar 26, 2018 at 5:56 PM,  > 
> wrote: 
> > Sorry, please disregard the uBoot output posted previously--that was 
> with 
> > our workaround of loading one big dtbo file. 
> > 
> > HERE IS THE OUTPUT FROM OUR MULTIPLE DTBOs... 
> > 
> > 
> > U-Boot SPL 2018.01-2-g9aa111a004 (Jan 20 2018 - 12:45:29) 
> > Trying to boot from MMC1 
> > 
> > 
> > U-Boot 2018.01-2-g9aa111a004 (Jan 20 2018 - 12:45:29 -0600), Build: 
> > jenkins-github_Bootloader-Builder-32 
> > 
> > CPU  : AM335X-GP rev 2.1 
> > I2C:   ready 
> > DRAM:  512 MiB 
> > No match for driver 'omap_hsmmc' 
> > No match for driver 'omap_hsmmc' 
> > Some drivers were not found 
> > Reset Source: Power-on reset has occurred. 
> > MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1 
> > Using default environment 
> > 
> > Board: BeagleBone Black 
> >  not set. Validating first E-fuse MAC 
> > BeagleBone Black: 
> > BeagleBone: cape eeprom: i2c_probe: 0x54: 
> > BeagleBone: cape eeprom: i2c_probe: 0x55: 
> > BeagleBone: cape eeprom: i2c_probe: 0x56: 
> > BeagleBone: cape eeprom: i2c_probe: 0x57: 
> > Net:   eth0: MII MODE 
> > cpsw, usb_ether 
> > Press SPACE to abort autoboot in 2 seconds 
> > board_name=[A335BNLT] ... 
> > board_rev=[00C0] ... 
> > switch to partitions #0, OK 
> > mmc0 is current device 
> > SD/MMC found on device 0 
> > ** Bad device 0:2 0x8200 ** 
> > ** Bad device 0:2 0x8200 ** 
> > switch to partitions #0, OK 
> > mmc0 is current device 
> > Scanning mmc 0:1... 
> > gpio: pin 56 (gpio 56) value is 0 
> > gpio: pin 55 (gpio 55) value is 0 
> > gpio: pin 54 (gpio 54) value is 0 
> > gpio: pin 53 (gpio 53) value is 1 
> > switch to partitions #0, OK 
> > mmc0 is current device 
> > gpio: pin 54 (gpio 54) value is 1 
> > Checking for: /uEnv.txt ... 
> > 2094 bytes read in 30 ms (67.4 KiB/s) 
> > gpio: pin 55 (gpio 55) value is 1 
> > Loaded environment from /uEnv.txt 
> > Importing environment from mmc ... 
> > Checking if uenvcmd is set ... 
> > Checking if client_ip is set ... 
> > Checking for: /boot.scr ... 
> > Checking for: /boot/boot.scr ... 
> > Checking for: /boot/uEnv.txt ... 
> > gpio: pin 55 (gpio 55) value is 1 
> > 2246 bytes read in 28 ms (78.1 KiB/s) 
> > Loaded environment from /boot/uEnv.txt 
> > debug: [dtb=am335x-boneblack-overlay.dtb] ... 
> > Using: dtb=am335x-boneblack-overlay.dtb ... 
> > Checking if uname_r is set in /boot/uEnv.txt... 
> > gpio: pin 56 (gpio 56) value is 1 
> > Running uname_boot ... 
> > loading /boot/vmlinuz-4.4.91-ti-r133 ... 
> > 8886912 bytes read in 579 ms (14.6 MiB/s) 
> > uboot_overlays: dtb=am335x-boneblack-overlay.dtb in /boot/uEnv.txt, 
> unable 
> > to use [uboot_base_dtb=am335x-boneblack-uboot.dtb] ... 
> > loading /boot/dtbs/4.4.91-ti-r133/am335x-boneblack-overlay.dtb ... 
> > 54603 bytes read in 84 ms (634.8 KiB/s) 
> > uboot_overlays: [fdt_buffer=0x6] ... 
> > uboot_overlays: loading /lib/firmware/maps_bbb_gpio-00A0.dtbo ... 
> > 1039 bytes read in 145 ms (6.8 KiB/s) 
> > uboot_overlays: loading /lib/firmware/maps_bbb_pwm-00A0.dtbo ... 
> > 1599 bytes read in 296 ms (4.9 KiB/s) 
> > uboot_overlays: loading /lib/firmware/maps_bbb_i2c-00A0.dtbo ... 
> > 1312 bytes read in 300 ms (3.9 KiB/s) 
> > uboot_overlays: loading /lib/firmware/maps_bbb_eqep-00A0.dtbo ... 
> > 2055 bytes read in 396 ms (4.9 KiB/s) 
>
> Okay these loaded fine.. 
>
>
> > uboot_overlays: uboot loading of 
> [/lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo] 
> > disabled by /boot/uEnv.txt [disable_uboot_overlay_emmc=1]... 
> > uboot_overlays: uboot loading of 
> [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
> > disabled by /boot/uEnv.txt [disable_uboot_overlay_video=1]... 
> > uboot_overlays: uboot loading of [/lib/firmware/BB-ADC-00A0.dtbo] 
> disabled 
> > by /boot/uEnv.txt [disable_uboot_overlay_adc=1]... 
> > uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo 
> ... 
> > 2402 bytes read in 356 ms (5.9 KiB/s) 
> > uboot_overlays: cape universal disabled, external cape enabled or 
> > detected... 
> > loading /boot/initrd.img-4.4.91-ti-r133 ... 
> > 5416133 bytes read in 361 ms (14.3 MiB/s) 
> > debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> > root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> > net.ifnames=0 quiet cape_universal=enable] ... 
> > debug: [bootz 0x8200 0x8808:52a4c5 8800] ... 
> > ## Flattened Device Tree blob at 8800 
> >Booting using the fdt blob at 0x8800 
> >Loading Ramdisk to 8fad5000, end 84c5 ... OK 
> >reserving fdt memory region: addr=8800 size=6e000 
> >Loading Device Tree to 8fa64000, end 8fad4fff ... OK 
> > 
> > Starting kernel ... 
> > 
> > [0.000833] clocksource_probe: no matching clocksources found 
> > [2.077791] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc 
> handle 
> > [2.249328] omap_voltage_la