[beagleboard] Re: Looking for some assistance on finding an image that has a working pinmux driver set.

[aallmanams]

Thanks for the quick response!

I saw that there's a new branch on the Strawson library that's being 
actively worked on, so that's very encouraging.

I'm new to linux, so when I first starting playing with the BBB last year, 
it was quite a learning curve.  What made things especially difficult was 
that many good resources (i.e. Derek Molloy's book & website) were based on 
older images and many examples didn't work.  Although it was a frustrating 
experience, I definitely learned a lot and was able to successfully use the 
BBB for a couple of projects around the house (replaced the commercial 
sprinkler system controller, monitor/control garage door, etc).

My target for the blue is definitely robotics.  I was a mentor for a couple 
of FIRST FLL (lego robotics) teams and some of these kids have expressed an 
interest in getting into "real" robotics & programming.  The BB blue seems 
like a great platform for that especially if some of the low-level details 
can be abstracted away through these libraries.  Most of the kids have been 
exposed to javascript & python in school.

I'll try the image from 3/2017 and see how it goes.

-- 
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/4b749eed-fedc-474f-9ea3-97e3a42c65bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black powers down when AC adapter is removed while the USB is connected.

[bglazierjr]

Sorry to revive an old thread but I wanted to add my solution to this 
problem somewhere and this seems like the most appropriate place to do it. 
I was also experiencing the Bone shutting itself down on AC Power removal 
regardless of a battery present. The logs showed it was registering the 
removal as a button press condition and powering down the unit. I had a 
product running on 4.1.19-bone20 and did not want to update to a later 
kernel but it appears to be resolved in later kernels already. 

To fix on 4.1.19-bone20, I modified the file mentioned here 
(/drivers/mfd/tps65217.c) and commented out this code entirely:

/*
if (int_reg & TPS65217_INT_ACI) {
/* Handle AC power status change 
dev_dbg(tps->dev, "AC power status change\n");
/* Press KEY_POWER when AC not present 
input_report_key(tps->pwr_but, KEY_POWER,
~status_reg & TPS65217_STATUS_ACPWR);
input_sync(tps->pwr_but);
}
*/

After I rebuilt and deployed the modified kernel, the problem was resolved, 
no more power down on AC removal.
For anyone who needs further instructions, I'd be happy to help.


On Wednesday, November 19, 2014 at 10:12:05 AM UTC-5, 
dhi...@schneiderdcim.com wrote:
>
> in /drivers/mfd/tps65217.c  i believe this is where the magic happens, and 
> needs to be changed
>
>
>  if (int_reg & TPS65217_INT_PBI) { 
>  /* Handle push button */ 
>  dev_dbg(tps->dev, "power button status change\n"); 
>input_report_key(tps->pwr_
> but, KEY_POWER, 
>  status_reg & TPS65217_STATUS_PB); 
>  input_sync(tps->pwr_but); 
>  } 
>  if (int_reg & TPS65217_INT_ACI) { 
>  /* Handle AC power status change */ 
>
>
>
> On Tuesday, November 18, 2014 1:57:47 PM UTC-5, Gerald wrote:
>>
>> Then the SW needs to be changed to change that behavior.
>>
>> Gerald
>>
>>
>> On Tue, Nov 18, 2014 at 10:37 AM, David Hirst  wrote:
>>
>>> The fact that it powers down is a problem to me, if for instance a 
>>> slight power interruption occurs ( lets say 5 seconds) during which time 
>>> the CPU is powered by the battery backup I would like to carry on running, 
>>> if its longer then I would like to make the decision when to shutdown. 
>>> As it stands now I have no option but to have the system power down.
>>> With the current implementation In the event of a small interruption, 
>>> the system will start to power down but if that the power has now returned 
>>> prior to the shutdown occurring  the system needs intervention to power 
>>> back up, by power cycling either the USB or AC. I want to smooth out short 
>>> power cycles and let the long power outages re-power the board when the 
>>> power returns
>>>
>>>
>>> On Monday, November 17, 2014 10:04:21 AM UTC-5, Gerald wrote:

 That should be bale to be fixed by changing the behavior of the SW. You 
 can look at the datasheet for the TPS65217C to see what registers to 
 change.

 Gerald

 On Mon, Nov 17, 2014 at 8:58 AM, Michel Gerin  
 wrote:

> Attn Gerald Coley,
>
> Hello,
> In order to avoid any misunderstanding, I wrote "I had a similar 
> problem". But I didn't use the USB connection.
> Only 5V DC and battery were connected to the BBB.
> As soon as 5V DC PS was off, the Debian LXDE version was shutting down 
> but a warning was appearing telling the user the system was shutting down 
> within 60s if this procedure wasn't canceled.
> Maybe David Hirst's problem is related to the same software 
> "mecanism". 
>
> Kind regards
>
> Michel. 
>   
>
> 2014-11-17 12:31 GMT+01:00 Gerald Coley :
>
>> Interesting. Sounds like something I need to get fixed.
>>
>> Gerald
>>
>>
>> On Monday, November 17, 2014, Michel Gerin  
>> wrote:
>>
>>> Hello,
>>> I had a similar problem. David mentions perhaps this thread:
>>>
>>> https://mail.google.com/mail/u/0/?tab=wm#inbox/149198bbf7826f64
>>>
>>> Bremenpl suggested to use the debian console version instead of the 
>>> LXDE version. It solved my problem. 
>>>
>>> We just encontered a 2 hours mains power outage this saterday.The 
>>> BBB went on running flawless with the battery backup.
>>>
>>> Michel
>>>
>>> 2014-11-17 1:09 GMT+01:00 David Funk :
>>>
 There is a previous thread, several weeks ago about this same 
 behavior. That thread involved an application that ran off mains but 
 had 
 battery backup and everytime mains failed, and 5V goes away, the BBB 
 shutdown. 

 IIRC, this is a known software default behavior when the 5V goes 
 away, it is programmable and needs to be set accordingly to how the 
 end 
 user whats it to behave.


 -david

Re: [beagleboard] Re: I2C SCL Voltage level too low?

[John Syne]

Yeah, I agree there is something else going on here. with a 1K resistor, the 
signals should not have a slow rising time. The rise time doesn’t look like a 
capacitor, but I agree, that is about the only explanation that would cause the 
rise time to slow like this. Maybe the I2C part is faulty. Try plugging in 
another I2C part to see if the problem persists. 

Regards,
John





> On Apr 5, 2018, at 8:02 AM, Graham  wrote:
> 
> 
>  It looks like you have some extra capacitance on the bus.  There should not 
> be any capacitors bridging the I2C data and clock lines. Some of the 
> third-party universal interface cards have extra capacitance, so take those 
> off.
> 
> I have never heard of an I2C part with built in pull-up resistors.
> 
> Do to the multi-drop nature of the I2C bus, pull up resistors are almost 
> always external. There are some "weak pull up" resistors you could turn on in 
> the BBB, but are too high in value for most applications.
> 
> I suggest you read up on how to select pull up resistors for an I2C bus.  
> Phillips (now NXP) initially developed the bus and has good documentation.
> Google: NXP I2C bus documentation
> 
> But the short answer is that for a 3.3V bus, resistors in the range of 1.2K 
> to 3.3K should work fine. The value is not critical. You want to pull 1 to 3 
> mA through the resistor when the bus is low.
> 
> --- Graham
> 
> ==
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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/a8ed3ca6-d286-4d29-8dc1-8851aa384db3%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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/CA2B23DC-7B39-4E85-AB6E-2D196A6DE203%40gmail.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]

Hi,

Ok this was a great help and allow our automount scripts to create a mount 
point on an SD card when running from eMMC.  


But I'm having a bit of a STRANGE problem, with the 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
script apparently affecting UDEV's ability to trigger on an SD card (e.g. 
mmcblk0p1) inserted in the slot - both on the source eMMC image and the 
destination flasher image on SD card, after I run the eMMC cloner script.

When  I run beaglebone-black-make-microSD-flasher-from-eMMC.sh, for some 
reason, it does something to the image currently flashed on the eMMC to 
permanently kill udev's ability to trigger on an SD card plugged into the 
SD card slot.  However, while in this state, our udev rule still triggers 
on the presence of mmcblk1p1.  Then when we subsequently use that flasher 
image from the cloned SD card to re-flash the eMMC, this udev 
excommunicating mmcblk0p1 behavior seems to persist.  I've got a a master 
SD card image, which when I utilize it to flash the eMMC, udev triggers on 
mmcblk0p1 when a properly formatted SD card is inserted.

So in other words, before running this eMMC cloner script, our working 
image running from eMMC triggers off the following line just fine in our 
udev rules file in /etc/udev/rules.d/ (10-mmc-blah-blah):

KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"

But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, it 
appears like udev stops seeing mmcblk0p1 when an uSD card is inserted. Even 
though calling ls -l /dev/mmc* shows both mmcblk0p1 and mmcblk1p1 (see 
listing below).


However, after calling the script, if we change this line in the udev rules 
file to:

KERNEL!="mmcblk[0-1]p1", GOTO="mmc_mount_end"

Then udev triggers on the presence of mmcblk1p1 (eMMC) and ultimately the 
shell script for formatting 
and mounting the uSD card gets called.



Notes:

1) ***I have a master flasher image an an SD card which contains the same 
SD card auto-mount scripts, and when I run the SD card to eMMC flasher 
script to flash the eMMC.  Everything works just fine!!  UDEV triggers on 
mmcblk0p1 when an SD card is plugged into the slot and the above rules file 
initiates the systemd service which calls a shell script.  It's just after 
running beaglebone-black-make-microSD-flasher-from-eMMC.sh that UDEV 
apparently no longer reacts to a "blank" SD card inserted in the slot.

2) Initially the SD card inserted in the slot, was originally formatted 
with a single, FAT 32 WIN95 partition, but then reformatted
to ext4 by mkfs.ext4 in the "automount" shellscript.  When this was the 
case, the application was actively storing logfiles on the mount point on 
the SD card when I called the eMMC to SD cloner script. 

3) I then reformatted the SD card by just erasing the first 1GB (and not 
creating a partition ) per a comment the eMMC cloner script spits out.  
This time the SD automount script wasn't able to create a mount point, so 
the application wasn't running when I called  the cloner script, converted 
the SD card to a flasher, and flashed the eMMC, but I got the same result 
as before: UDEV excommunicated mmcblk0p1.

4) cat  /etc/dogtag:  2018-01-01.  

5) I have not run a git pull on the /opt/scripts/tools directory, but I 
didn't SEE any updates to functions.sh post 2018-01-01..

6) kernel: 4.4.110

7) After running the eMMC to SD card cloner script, even though UDEV 
apparently no longer reacts to mmcblk0p1:

ls -l /dev/mmc* :

brw-rw 1 root disk 179,  0 Apr  5 19:58 /dev/mmcblk0
brw-rw 1 root disk 179,  1 Apr  5 19:58 /dev/mmcblk0p1
brw-rw 1 root disk 179,  8 Apr  5 19:58 /dev/mmcblk1
brw-rw 1 root disk 179, 16 Apr  5 19:58 /dev/mmcblk1boot0
brw-rw 1 root disk 179, 24 Apr  5 19:58 /dev/mmcblk1boot1
brw-rw 1 root disk 179,  9 Apr  5 19:58 /dev/mmcblk1p1

8) I "slightly hacked" and renamed functions.sh in that I copied our custom 
board u-boot and MLO to the backup/uboot folder and reference that in the 
functions.sh script instead of the default (This maybe not needed and a bad 
idea which I will have to fix later), but I don't THINK any of this gets 
called anyway for the eMMC to SD card and flasher scripts I'm running.


As always, thanks for reading my novels on here!!













On Tuesday, April 3, 2018 at 4:18:35 PM UTC-5, Jeff Andich wrote:
>
> 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 

Re: [beagleboard] How to replace 4.4.x Linux kernel in BBB eMMC after cross compiling from source?

[jirkarck]

Thank you very much, this worked well!

Please, could you tell me, what is the default make path of kernel modules? 
A have not found them after compilation.

Dne úterý 9. ledna 2018 22:49:08 UTC+1 Dennis K napsal(a):
>
> Robert,
>
> Thanks that was just what I needed.
> I have successfully rebooted the system with the new kernel.
>
> I did have to do some more research since I had neglected to compile and 
> install the modules to a folder, but I was able to get through that.
>
> One thing that bothers me is whether I need to do anything about the 
> kernel headers.
>
> I was wondering since I still can not access /dev/mem.
> There is something locking me out that I need to find and change.
>
> I know that the c program that I have to access /dev/mem works since I was 
> able to get it to work with an older kernel but I was forced to upgrade 
> because with the older kernel the pru_rproc driver did not work.
>
> Dennis
>
> On Friday, January 5, 2018 at 4:08:14 PM UTC-5, RobertCNelson wrote:
>>
>> On Fri, Jan 5, 2018 at 2:59 PM, Dennis K  
>> wrote: 
>> > 
>> > I need to recompile my current Beaglebone Black Linux kernel (4.4.91) 
>> to set 
>> > CONFIG_STRICT_DEVMEM=n. 
>> > This will allow the use of mmap to access the SPI interface hardware 
>> > directly, among other things. 
>> > 
>> > So far... 
>> > I have loaded the latest version of arm-linux-gnueabihf gcc. 
>> > Cloned the latest kernel source (
>> https://github.com/beagleboard/linux/git) 
>> > which is currently 4.4.91. 
>> > Modified the kernel config options to set CONFIG_STRICT_DEVMEM=n. 
>> > Compiled the kernel. 
>> > Cloned, patched, and compiled u-boot. 
>> > 
>> > At this point the instructions that I have been following diverge and 
>> are 
>> > more concerned with creating a bootable image 
>> > on the SD card for testing or for replacing the entire contents of the 
>> eMMC 
>> > on the Beaglebone. 
>> > 
>> > What I want to do is replace the existing kernel on eMMC with minimal 
>> impact 
>> > to the current configuration. 
>> > My current filesystem is BeagleBoard.org Debian Image 2016-05-13. 
>> > 
>> > Can someone explain the process to replace the kernel on eMMC? 
>>
>> First cat ./include/generated/utsrelease.h in your build directory: 
>>
>> You'll see something similar like: 
>>
>> #define UTS_RELEASE "4.14.12-4-gdb0cd0519e45" 
>>
>> That's your Kernel Version, then just follow this: 
>>
>> Copy zImage to /boot/vmlinuz-`Kernel Version` 
>> Copy *.dtb to /boot/dtbs/`Kernel Version`/ 
>> Copy modules to /lib/modules/`Kernel Version` 
>> Edit /boot/uEnv.txt and update uname_r=`Kernel Version` 
>>
>> 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/fb9edae5-edc5-45db-bce3-c92887bb0aa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to replace 4.4.x Linux kernel in BBB eMMC after cross compiling from source?

[jirkarck]

Thank You very much, it works well!

Please, could you tell me, what is the default path of module compiling 
output? I have compiled kernel and modules, kernel is in 
./linux/arch/arm/boot/, but I can not find .ko files anywhere...

Many thanks.

Dne pátek 5. ledna 2018 22:08:14 UTC+1 RobertCNelson napsal(a):
>
> On Fri, Jan 5, 2018 at 2:59 PM, Dennis K  > wrote: 
> > 
> > I need to recompile my current Beaglebone Black Linux kernel (4.4.91) to 
> set 
> > CONFIG_STRICT_DEVMEM=n. 
> > This will allow the use of mmap to access the SPI interface hardware 
> > directly, among other things. 
> > 
> > So far... 
> > I have loaded the latest version of arm-linux-gnueabihf gcc. 
> > Cloned the latest kernel source (
> https://github.com/beagleboard/linux/git) 
> > which is currently 4.4.91. 
> > Modified the kernel config options to set CONFIG_STRICT_DEVMEM=n. 
> > Compiled the kernel. 
> > Cloned, patched, and compiled u-boot. 
> > 
> > At this point the instructions that I have been following diverge and 
> are 
> > more concerned with creating a bootable image 
> > on the SD card for testing or for replacing the entire contents of the 
> eMMC 
> > on the Beaglebone. 
> > 
> > What I want to do is replace the existing kernel on eMMC with minimal 
> impact 
> > to the current configuration. 
> > My current filesystem is BeagleBoard.org Debian Image 2016-05-13. 
> > 
> > Can someone explain the process to replace the kernel on eMMC? 
>
> First cat ./include/generated/utsrelease.h in your build directory: 
>
> You'll see something similar like: 
>
> #define UTS_RELEASE "4.14.12-4-gdb0cd0519e45" 
>
> That's your Kernel Version, then just follow this: 
>
> Copy zImage to /boot/vmlinuz-`Kernel Version` 
> Copy *.dtb to /boot/dtbs/`Kernel Version`/ 
> Copy modules to /lib/modules/`Kernel Version` 
> Edit /boot/uEnv.txt and update uname_r=`Kernel Version` 
>
> 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/5237fc69-9ba1-4da6-a662-207c6edce742%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pocket beagle not clean shutdown?

[Robert Nelson]

On Wed, Apr 4, 2018 at 7:01 AM,   wrote:
> The problem seems to be, that the rtc has no active oscillator:
> If I set RTC_OSC_REG to 0x40 (internal oscillator) shutdown works normal.
> But I'm not sure whether this is the correct way to solve this issue.

Thanks guys, with the help of Matthijs, we have this implement in
u-boot and the kernel..

My PocketBeagle now shut's down..

You can get the updated bootloader via:

debian@beaglebone:~$ sudo /opt/scripts/tools/developers/update_bootloader.sh

I've also add a print statement about the RTC

U-Boot 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500),
Build: jenkins-github_Bootloader-Builder-47

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.
RTC 32KCLK Source: Internal.  <---

Pocket: Internal
BeagleBone Black: External

Right now only v4.16.0-bone7 has the kernel change, and it's building right now

http://gfnd.rcn-ee.org:81/farm/deb/

I'll start the backport shortly to previous kernels..

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/CAOCHtYjzLqvFZKJt0kNyzmuWvj_aX7NXn6he8vb%2BQyZVZidVaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I *still* can't get Debian 9 onto my BBB

[Chris Green]

Robert Nelson  wrote:
> On Thu, Apr 5, 2018 at 3:44 AM, Chris Green  wrote:
> > Robert Nelson  wrote:
> >
> > Thanks for continuing to help Robert.  :-)
> >
> >
> >> > What I need (help/information) is:-
> >> >
> >> > What Debian 9 image to use (minimal non-GUI system)
> >> >
> >> > How to write it to the microSD card (on a Linux system)
> >> >
> >> > A script to run that will install it on the eMMC.
> >>
> >> With: bone-debian-9.3-iot-armhf-2018-01-28-4gb.img.xz booted on the microSD
> >>
> >> Run:
> >>
> >> sudo /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
> >>
> > I don't have that script in the existing Debian 7 installation:-
> >
> > chris@odin:~$ ls /opt/scripts/tools/eMMC
> > beaglebone-black-make-microSD-flasher-from-eMMC.sh
> > chris@odin:~$
> >
> > Should I run it from the mounted Debian 9 image?
> 
> ALL the scripts assume you are directly "running" the image from a
> fresh bootup, that you would like to "copy" to the secondary storage.
> Don't do anything fancy beyond that.
> 
OK, thanks, that's all I needed to know (I hope).

-- 
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/su1ipe-b79.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Can someone clarify "Debian Image Snapshots" please

[Chris Green]

Robert Nelson  wrote:
> On Thu, Apr 5, 2018 at 8:19 AM, Chris Green  wrote:
> > I'm looking at:-
> >
> > https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2018-03-25_-_Debian_9_.28Stretch.29_-_Weekly
> >  
> 
> >
> > ... and trying to decide which image I want to use.
> >
> > So I presume the ones headed 'microSD/Standalone' are the ones that boot
> > and run from the microSD card and the 'Flasher' ones are the ones that
> > copy themselves to the eMMC at boot.
> >
> > Then there are 2Gb and 4Gb, I can understand that bit! :-)
> >
> > Finally there are lxqt, lxqt-xm, iot and console.  Again I *think* I
> > understand these as the GUI (lxqt, lxqt-xm) or not (console).  What
> > does 'iot' mean though.
> >
> > I don't need a GUI so I can go for the "microSD/Standalone:
> > (stretch-console) (All BeagleBone Variants & PocketBeagle)" image.
> > This will presumably simply boot from and use the microSD card.
> 
> iot is lxqt minus the gui...
> 
Ah, sort of somewhere between lxqt and console, thank you.

-- 
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/n02ipe-b79.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I2C SCL Voltage level too low?

[Graham]

 It looks like you have some extra capacitance on the bus.  There should 
not be any capacitors bridging the I2C data and clock lines. Some of the 
third-party universal interface cards have extra capacitance, so take those 
off.

I have never heard of an I2C part with built in pull-up resistors.

Do to the multi-drop nature of the I2C bus, pull up resistors are almost 
always external. There are some "weak pull up" resistors you could turn on 
in the BBB, but are too high in value for most applications.

I suggest you read up on how to select pull up resistors for an I2C bus.  
Phillips (now NXP) initially developed the bus and has good documentation.
Google: NXP I2C bus documentation

But the short answer is that for a 3.3V bus, resistors in the range of 1.2K 
to 3.3K should work fine. The value is not critical. You want to pull 1 to 
3 mA through the resistor when the bus is low.

--- Graham

==






-- 
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/a8ed3ca6-d286-4d29-8dc1-8851aa384db3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Can someone clarify "Debian Image Snapshots" please

[Robert Nelson]

On Thu, Apr 5, 2018 at 8:19 AM, Chris Green  wrote:
> I'm looking at:-
>
> 
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2018-03-25_-_Debian_9_.28Stretch.29_-_Weekly
>
> ... and trying to decide which image I want to use.
>
> So I presume the ones headed 'microSD/Standalone' are the ones that boot
> and run from the microSD card and the 'Flasher' ones are the ones that
> copy themselves to the eMMC at boot.
>
> Then there are 2Gb and 4Gb, I can understand that bit! :-)
>
> Finally there are lxqt, lxqt-xm, iot and console.  Again I *think* I
> understand these as the GUI (lxqt, lxqt-xm) or not (console).  What
> does 'iot' mean though.
>
> I don't need a GUI so I can go for the "microSD/Standalone:
> (stretch-console) (All BeagleBone Variants & PocketBeagle)" image.
> This will presumably simply boot from and use the microSD card.

iot is lxqt minus the gui...

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/CAOCHtYiYNfQG2%2BN3Jy7W-2RDRhu-mZJAJgtoch5QdXgWdenD8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: I *still* can't get Debian 9 onto my BBB

[Robert Nelson]

On Thu, Apr 5, 2018 at 3:44 AM, Chris Green  wrote:
> Robert Nelson  wrote:
>
> Thanks for continuing to help Robert.  :-)
>
>
>> > What I need (help/information) is:-
>> >
>> > What Debian 9 image to use (minimal non-GUI system)
>> >
>> > How to write it to the microSD card (on a Linux system)
>> >
>> > A script to run that will install it on the eMMC.
>>
>> With: bone-debian-9.3-iot-armhf-2018-01-28-4gb.img.xz booted on the microSD
>>
>> Run:
>>
>> sudo /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
>>
> I don't have that script in the existing Debian 7 installation:-
>
> chris@odin:~$ ls /opt/scripts/tools/eMMC
> beaglebone-black-make-microSD-flasher-from-eMMC.sh
> chris@odin:~$
>
> Should I run it from the mounted Debian 9 image?

ALL the scripts assume you are directly "running" the image from a
fresh bootup, that you would like to "copy" to the secondary storage.
Don't do anything fancy beyond that.

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/CAOCHtYjdpKLn9pWz2o8NCytPOR9Xi16GuTkgR2Y6cXqpTqNodQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Can someone clarify "Debian Image Snapshots" please

[Chris Green]

I'm looking at:-


https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2018-03-25_-_Debian_9_.28Stretch.29_-_Weekly

... and trying to decide which image I want to use.

So I presume the ones headed 'microSD/Standalone' are the ones that boot
and run from the microSD card and the 'Flasher' ones are the ones that
copy themselves to the eMMC at boot.

Then there are 2Gb and 4Gb, I can understand that bit! :-)

Finally there are lxqt, lxqt-xm, iot and console.  Again I *think* I
understand these as the GUI (lxqt, lxqt-xm) or not (console).  What
does 'iot' mean though.

I don't need a GUI so I can go for the "microSD/Standalone:
(stretch-console) (All BeagleBone Variants & PocketBeagle)" image.
This will presumably simply boot from and use the microSD card.


-- 
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/ubkhpe-o15.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Looking for some assistance on finding an image that has a working pinmux driver set.

[Drew Viersen]

Hi Andy!

Short answer. Only the 3/2017 image works correctly for Libroboticscape,
RCPY, Jhonny5, and node-robotics cape. And even then with the node red,
most of it doesn't work at all. RCPY is just conversion of the
libroboticscape, but most of the functions aren't there from the
libroboticscape. Newer 4.x kernels simply won't work.

Long answer.

The folks who designed the board use it for a class in a class at a
university. As such, Robert C Nelson has disabled overlays for the Blue
board. He also as of this point hasn't updated the code to pull out all of
the pinmuxes in newer boards despite protests from several of us so far.
again because he doesn't want top break the code the school uses if the
board is accidently updated. The BBBLue also pulls out some pinmuxes that
aren't standard on a normal beaglebone, and assigns them under a different
nomenclature than a normal Beaglebone. This is important later.

The libroboticscape library uses some older coding and very specific coding
to perform some back end wizardry to handle the 4th encoder & the servos.
this eliminates the ability to use them without the library. the Analog
pins are also handled via mmap, which means you can't get to them from
python. This library is also called for the battery checker. RCPY is
another university class grade piece of code, and largely unmaintained as
you'll find. unfortunately, to use everything and use it easily/correctly,
this library is required. In python especially, there is no way to use the
Analog pins, or even read from them. using the "State" in RCPY and in any
of even the "C" examples is blocking, meaning that you can't run two
instances with it, it'll close the first so the second. with some kajigery
i was able to get some things out of it, right or not. it's working for me
so far.

Adafruit BBIO uses a certain nomenclature when setting pinmuxes. this is in
the format of "P8_8", and it's hard coded. This is because the underlying
software for setting the pinmuxes to do things is also hard coded for this
style that the Adafruit BBIO uses under everything. the non-standard
nomenclature of some of the pinmuxes means you can't access them via this
python library.

The node-roboticscape is based on an even earlier piece of code that's no
longer supported by node-red. as such, most of it's corresponding functions
aren't even available. Johnny5 looks for things exported to
/sys/class/gpio, which aren't there because the overlays pinmux things
instead. You can export pins in this directly, but all PWM is handled via
pinmuxing and the PRUs.

Between the 3/2017 and the newer versions of the kernal, the pru driver
changed. so newer kernel functions for PRUs doesn't work correctly. This
includes encoder #4, and all servo pins.

Now, with all of the depressing things out of the way that inhibit the use
of it on newer kernels, there is a newer version of libroboticscape in the
works. how it will function is beyond me and the developer isn't responding
to inquiries so far after over a month. it does appear Robert C nelson is
helping them at least.

I myself am not willing to give up on this thing just yet. I'm on the
3/2017 kernel.none of the others work, or provide complete functionality,
including the debian and ROS images. i'm not fluent in C and i bought this
thing to do some fun things with my daughter, which means python for me.
i've done some things to get the functionality i want and use a variety
silly things to get it, but i can at least get some of the things needed to
make it all work. if any of it is of interest to let me know, and i'd be
happy to share what i've done to get it going. there are likely easier
ways, mostly tied to learning how to create a better, more complete version
of RCPY, but it's all well outside of what i know how to do on such a large
scale.

Thanks!
Drew







On Thu, Apr 5, 2018, 7:34 AM  wrote:

> Hi Drew,
>
> Have you had any luck with this so far?  I've hit the same point (which is
> how I came across this post).
>
> If it's not possible to get the robotics cape, rcpy/pyctrl, node-roboticscape,
> etc. working with the "current" image, I'm happy running an older image.
> It might be helpful to have a warning in any Blue-specific documentation
> that the newer images should be avoided until things are better.
>
> Any recommendations for an older image where things like the EduMIP robot
> examples will work?
>
> Thanks!
> Andy
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/GHeMjrAM5AE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> 

[beagleboard] Re: Looking for some assistance on finding an image that has a working pinmux driver set.

[aallmanams]

Hi Drew,

Have you had any luck with this so far?  I've hit the same point (which is 
how I came across this post).

If it's not possible to get the robotics cape, 
rcpy/pyctrl, node-roboticscape, etc. working with the "current" image, I'm 
happy running an older image.  It might be helpful to have a warning in any 
Blue-specific documentation that the newer images should be avoided until 
things are better.

Any recommendations for an older image where things like the EduMIP robot 
examples will work?

Thanks!
Andy

-- 
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/9bdd6e4b-6ea3-44e9-a4d6-3300a5bfdae6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I *still* can't get Debian 9 onto my BBB

[Chris Green]

Dennis Lee Bieber  wrote:
> On Wed, 4 Apr 2018 20:52:50 +0100, Chris Green
>  declaimed the following:
> 
> >
> >When inserted in the BBB I want to update it did nothing on rebooting.
> >I also tried powering up with the 'boot' button held down but that did
> >no good either, it simply did nothing.
> >
> "nothing"? Did it even boot?
> 
No, it didn't even boot, the single (power?) LED came on but that was
all.  Had me worried for a minute but without the boot button down it
acted quite normally still and booted Debian 7,


> >I tried running the script:-
> >
> >/opt/scripts/tools/beaglebone-black-eMMC-flasher.sh
> >
> >and that didn't work either (as reported above in an earlier posting),
> >it seems to have done something to the microSD which had Debian 9 on
> >it too.
> >
> 
> Given what I could understand of the script (I'm no where near a BASH
> script expert -- my heaviest "shell script" experience is VAX/VMS DCL,
> AREXX [Amiga REXX]... I don't consider Python a "scripting language" (AREXX
> could be used to control any application that opened an AREXX message port,
> and any statement in a script that did not parse as native AREXX would be
> sent to the current "command host" -- ie; the shell by default or an
> application if one did "address application-name" first -- and the easiest
> way to make a statement "not native" was to quote the first word) -- pardon
> the harangue -- I understand the script to copy files from the /booted/
> system media to the other media. If it booted from the eMMC, running the
> script will copy the eMMC to the SD card.
> 
> I could be all wet with that hypothesis 
> 
I think you're spot on actually!  :-)   I didn't stare all that hard
at the code but it certainly did seem to copy from the eMMC to the
microSD card.  


> >
> >So, how on earth am I going to get Debian 9 onto my BBB?  Surely there
> >must be a reliable way to do this, especially as I have a running
> >Debian system on it.  Is there a script I can get which can install an
> >OS from an image on a microSD?  I'd really be happiest with a
> >script/program I can load and run on my existing system rather than
> >some sort of automatic load which requires a combination of buttons
> >pressed and power-up sequences.
> >
> 
> Boot with your existing system. Insert the SD card. MOUNT the SD card
> if it isn't automatically mounted (there was a period of time where the
> Wheezy images would auto-mount SD cards).
> 
Yes, my Debian 7 does automount SD cards.


> Edit the /boot/uEnv.txt file (NOT a file on the eMMC) as
> described http://beagleboard.org/latest-images
> 
> Reboot. If the reboot doesn't read the SD card a start flashing, 
> reboot
> with the boot button held down! Due to the changes in device tree handling
> since Wheezy, a Wheezy era eMMC uBoot may not be compatible (hypothesis --
> I don't think I've used the boot button since Wheezy) and my understanding
> is that the boot button totally bypasses the eMMC uBoot for the one on the
> SD card (newer versions, I believe, use the eMMC uBoot which transfers to
> the SD card if installed to complete the boot).
> .
OK, thanks, that does seem to make sense to me.  I'll need to wait
until I'm next back on the boat which will be a week or so now.  The
boat is in France and I'm in England, it's not just down the road! :-)

-- 
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/fu3hpe-beu.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: I *still* can't get Debian 9 onto my BBB

[Chris Green]

Robert Nelson  wrote:

Thanks for continuing to help Robert.  :-)


> > What I need (help/information) is:-
> >
> > What Debian 9 image to use (minimal non-GUI system)
> >
> > How to write it to the microSD card (on a Linux system)
> >
> > A script to run that will install it on the eMMC.
> 
> With: bone-debian-9.3-iot-armhf-2018-01-28-4gb.img.xz booted on the microSD
> 
> Run:
> 
> sudo /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
> 
I don't have that script in the existing Debian 7 installation:-

chris@odin:~$ ls /opt/scripts/tools/eMMC
beaglebone-black-make-microSD-flasher-from-eMMC.sh
chris@odin:~$ 

Should I run it from the mounted Debian 9 image?


> It should "work", but there is a good reason we moved to flashing the
> eMMC in single user mode...
> 
> So IF it fails, follow the standard eMMC flashing directions here:
> 
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC
> 
OK, thank you.

As I said above I'm away from the boat for a while now, I should be
able to retry in a week or two.

-- 
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/784hpe-beu.ln1%40esprimo.zbmc.eu.
For more options, visit https://groups.google.com/d/optout.