[beagleboard] Find charge status or percentage of LiPo battery in BBBL

[Jeshwanth Kumar N K]

Hello,

How to find the battery charge percent in BBBL ? 

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/1688d4be-2760-4f20-9c27-3804a077a48a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: no data from /dev/input/event1

[John Franey]

I tried a clean reboot.  Now event writes events from /dev/input/event1 to 
stdout.  Too many actually.

In any case, my original issue seems resolved by a reboot.



On Tuesday, March 28, 2017 at 11:53:34 AM UTC-4, John Franey wrote:
>
> Hi,
>
> I am experimenting with gpio_keys driver, to see if I can get it to work. 
>  I fail.  Any suggestions?
>
> I can read the value of the gpio through /sys/class/gpio/cpio48/value, and 
> the value in fact changes depending on the button pressed/released.  The 
> trouble: NOTHING comes up through /dev/input/event1 when I hit the button, 
> demonstrated by evtest:
>
> root@beaglebone:~/keys/overlay# evtest
> No device specified, trying to scan all of /dev/input/event*
> Available devices:
> /dev/input/event0: tps65217_pwr_but
> /dev/input/event1: ocp:gpio_keys
> Select the device event number [0-1]: 1
> Input driver version is 1.0.1
> Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
> Input device name: "ocp:gpio_keys"
> Supported events:
>   Event type 0 (EV_SYN)
>   Event type 1 (EV_KEY)
> Event code 28 (KEY_ENTER)
> Properties:
> Testing ... (interrupt to exit)
>
>
>
> I hope I've provided enough information.
>
> Thanks.
>
>
>
> Attached is the overlay.  This was derived from Derek Molloy's dts (
> http://exploringbeaglebone.com/chapter6/), and from the universal cape 
> dts.  I started with Malloy's, but it didn't work.  I thought it was 
> because my circuit has a pull-down register and his configured the gpio 
> controller's pull-up resister).  So, I changed the dts to use neither, and, 
> incidentally, changed the node name from pushbotton_pins to P9_15_gpio_pin 
> (matching the name used by universal dts).  Then, I read here that the gpio 
> offset had changed from debian 3.8 to 4.x (which I'm using), and so also 
> made that necessary edit too.
>
>
> uname:
>
> root@beaglebone:~/keys/overlay# uname -a
> Linux beaglebone 4.4.36-ti-r72 #1 SMP Wed Dec 7 22:29:53 UTC 2016 armv7l 
> GNU/Linux
>
>
>
> Here is edge:
>
> root@beaglebone:~/keys/overlay# cat /sys/class/gpio/gpio48/edge
> both
>
> Yes, I had the universal cape disabled at boot time for this experiment.   
> My /boot/uEnv.txt:
>
> #cmdline=coherent_pool=1M quiet net.ifnames=0 cape_universal=enable
> cmdline=coherent_pool=1M quiet net.ifnames=0
>
>
>
>
>
> Here is slots:
>
> root@beaglebone:~/keys/overlay# cat 
> /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1 
>  1: PF  -1 
>  2: PF  -1 
>  3: PF  -1 
>  5: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-BONE-KEYS
>
>
> Here is dmesg:
>
> [ 1802.211933] bone_capemgr bone_capemgr: part_number 'BB-BONE-KEYS', 
> version 'N/A'
> [ 1802.212015] bone_capemgr bone_capemgr: slot #5: override
> [ 1802.212061] bone_capemgr bone_capemgr: Using override eeprom data at 
> slot 5
> [ 1802.212109] bone_capemgr bone_capemgr: slot #5: 'Override Board 
> Name,00A0,Override Manuf,BB-BONE-KEYS'
> [ 1802.238081] input: ocp:gpio_keys as 
> /devices/platform/ocp/ocp:gpio_keys/input/input2
> [ 1802.252947] bone_capemgr bone_capemgr: slot #5: dtbo 
> 'BB-BONE-KEYS-00A0.dtbo' loaded; overlay id #0
>
>
>

-- 
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/9aa59c29-b014-447f-a23c-6f66a1bf16d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Robots. Fast. BeagleBone Blue is here!

[Niels Jakob Buch]

Hi, is there any news on availability in Europe, asked Mouser and they 
claim export restrictions for the Blue board. Please update asap.

-- 
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/abb4c9a4-1919-43b0-84c5-b391af2cceee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Detecting state of GPIO pins during boot up

[Rao Gobburu]

Hi folks
I hope that I am posting to the correct group apologies if this is the 
wrong place.
We are creating a system based on the beagleboard black. We would like to 
implement a "Factory Reset". i.e. if I hold down a switch for a long period 
of time, say around 10 seconds, then we want to completely reset the 
system. 
Essentially the Reset pin is tied to one of the GPIO pins. So the GPIO 
follows the Reset pin. 
We would like to detect if the GPIO pin is still low about 10 seconds after 
the Reset has been asserted.
The issue is that this is the time when the system is still booting up. I 
am not sure how one could check on the status of the pin during the boot up.
Any ideas?
Thanks a lot
Rao



-- 
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/8dac92bb-1d9e-462b-8955-11bfc00f7706%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Can't enable service using systemctl: Bad message

[jedstainthorp]

I believe "Bad message" means there is a syntax error
I had this problem with a service I created and it was because of a typo.

The following command might give you sone useful information:
systemctl status wd.service


On Sunday, 4 September 2016 20:00:37 UTC+1, Duncan8410 wrote:
>
> Folks
>
> I've written a service (wd.service) which I want to start at boot on my 
> BBB (running 3.8.13-bone70).  I can use systemctl to start and stop it 
> using the commands
>
> systemctl start wd.service
>
> systemctl stop wd.service
>
> and everything works exactly as planned.  However, when I try and get it 
> to load at boot using the command
>
> systemctl enable wd.service
>
> I get the response
>
> 'Failed to issue method call: Bad message'
>
> I've scouted asround on the internet for similar error messages and there 
> are plenty of examples of 'Failed to issue method call: No such file' 
> (which all seem to boil down to overwriting the symlinks used by systemd), 
> but nothing referring to 'Bad message'.  It seems as though, for some 
> reason, systemctl doesn't understand (or won't accept) 'enable' as a valid 
> command, even though it seems that this absoltuely the standard way to get 
> services to load at boot.  I've tried all the simple tricks I can think of, 
> like renaming it, putting in the explicit path to the unit file, rebooting 
> etc but all to no avail.  (Incidentally, I get exactly the same response 
> using the 'disable' command).  And there are only so many times you can 
> check 'enable' to see if it's spelt correctly.
>
> So now I'm stumped. Anyone have any ideas as to what could be causing this?
>
> Any suggestions welcome,
>
> Thanks
>
> Duncan
>
>
>
>
>

-- 
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/322d1c32-cd67-41a3-9b64-46174a07f4b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBGW Kernel Panic

[jalexmullins91]

 On Tuesday, March 28, 2017 at 9:06:49 AM UTC-5, RobertCNelson wrote:

> On Mon, Mar 27, 2017 at 10:58 PM,   
> wrote: 
> > 
> > I'm encountering a kernel panic when I try to unload the "univ-bbgw" 
> cape 
> > from my $SLOTS file. 
> > 
> > My setup is: 
> > Seeed BeagleBone Green Wireless 
> > Seeed Grove Base Cape for Beaglebone v2.0 
> > bone-debian-8.7-seeed-iot-armhf-2017-03-26-4gb 
> > 
> > Here's my terminal output and dmesg of the error: 
> > https://gist.github.com/alexmullins/a4f9673b2cb280679b8df11be1f4140f. 
> > 
> > I think this is the relevant part of dmseg: 
> > 
> > [  380.483327] Unable to handle kernel NULL pointer dereference at 
> virtual 
> > address 000d 
> > [  380.491655] pgd = db5d4000 
> > [  380.494384] [000d] *pgd=9b533831, *pte=, *ppte= 
> > [  380.500908] Internal error: Oops: 17 [#1] SMP ARM 
> > 
> > I've looked at the univ-bbgw.dts and I don't see anything out of the 
> > ordinary there (I'm not great with device trees though). 
>
> That's normal, removing a cape via slots almost never works.. 
>
> Instead in /boot/uEnv.txt find the "cape_universal=enable", remove 
> that and reboot. 
>
 
Is the 'univ-bbgw' loaded on boot when cape_universal=enable? I ask because 
I 
only see it in my $SLOTS file after I mess around with a few pins. 
 

>
> > Also, I'm noticing that the Seeed Grove Base Cape for Beaglebone v2.0 
> > doesn't have a valid EEPROM signature: 
> > 
> > [2.554339] bone_capemgr bone_capemgr: Invalid signature '' 
> at 
> > slot 3 
> > 
> > Not sure if that could have something to do with this. 
> > 
> > Does anyone have any tips on where to go from here? 
>
> a custom overlay needs to be written for this cape. 
>
>  
Everything seems to work fine with the 'univ-bbgw' overlay so I'll let it 
be for now.

Thanks RCN!
 

> 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/097a37ec-9f30-40ab-ba82-fc4f5cfb51b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: UART4 RS485 (RTS) not working

[rndmpt]

Hi Mat,

I have the same issue: any response yet?



On Tuesday, March 28, 2017 at 2:52:07 PM UTC+2, Matthew Bezuidenhout wrote:
>
> Hi all,
>
> For days now, I've been attempting to get the Waveshare RS485/CAN Cape to 
> work on Beaglebone black.
>
> I've used kernels 4.4.x and 4.9.x-ti mainline, and encountered the same 
> problem.
>
> The cape can use any UART (have been trying with one), and requires the 
> use of pin P9_42 (0x164) as an RTS pin.
>
> The dtbo (standard from https://github.com/beagleboard/bb.org-overlays 
> which uses pin P9_27) loads fine using 
>
>echo BB-UART4-RS485 > /sys/devices/platform/bone_capemgr/slots
>
> A "cat /sys/devices/platform/bone_capemgr" reveals the slot has been 
> loaded correctly.
>
> The HDMI has successfully been disabled.
>
> Three problems arise:
>
> PROBLEM 1:
> The wavheshare cape requires the pulldown of both UART pins (I used 
> UART4), as it leaves the pins floating through the RS485 transceiver if 
> left standard. Now, the tricky thing is, if I enable BB-UARt4-RS485 in the 
> /boot/uEnv.txt file, it loads the cape fine, but will not do pulldowns. If 
> I allow the beaglebone to boot, then echo the BB-UART at slots, the 
> pulldown works and the transceiver can send a signal through, which is 
> curious as it is exactly the same dtbo it loads, whether from uEnv.txt or 
> echo.
>
> PROBLEM 2:
> Once loaded using echo after start, if I "cat /proc/tty/driver/serial" 
> immediately after loading UART RS485 overlay, the flags I'm presented with 
> are as below:
>
> 0: uart:8250 mmio:0x44E09000 irq:158 tx:8304 rx:0 RTS|CTS|DTR|DSR
> 1: uart:unknown port: irq:0
> 2: uart:unknown port: irq:0
> 3: uart:unknown port: irq:0
> 4: uart:8250 mmio:0x481A8000 irq:198 tx:0 rx:0 CTS|DSR
> 5: uart:unknown port: irq:0
>
>
> Showing UART4 (the one I'm using) has not loaded the CTS and RTS flags 
> appropriately. However, if, before performing the cat, I screen into ttyS4 
> or ttyO4 or echo some characters at the port, and then I perform the "cat" 
> as above, the RTS and DTR flags are both raised on 4. Thereafter, if I 
> screen in on ttyO4, and then quit, the RTS flag disappears after a cat. 
> Weird.
>
> However, regardless of these results, I'm left with the following main 
> problem,
>
> PROBLEM 3:
> Regardless of the flag position or whether I use the default 
> BB-UART4-RS485-00A0.dtbo from the source, the RTS pin does not switch (both 
> P9_27 and P9_42 are unresponsive to any efforts to communicate on the 
> UART4, where the UART transmits as evidenced by the oscilliscope, but the 
> oscilliscope shows that the RTS pin P9_42/27 does not move at all). I need 
> to get pin 9_42 to switch for RTS during uart, else this cape (and the 
> beaglebone) are useless to me.
>
> After copious amounts of time reading up on this, it seems that its a 
> common problem, and something to do with the OMAP serial driver vs the 8250 
> driver malfunctioning? If someone could provide some insight to the 
> problem, or a guide on how to get RTS working on this Beaglebone I'd be 
> very appreciative.
>
> Kind regards,
> Matt.
>  
>
>

-- 
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/efb2fc13-4e78-4693-87d0-f35e5b7ed7a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Custom device overlay or cape-universal - decisions...

[Hugh Frater]

Hi everyone, I'm building a custom piece of mechatronics as part of my day 
job. We have a custom interface cape laid out (it doesn't have an eeprom) 
and I've mapped out the 16 lines we need to go back to the BBB. I've 
written a custom device tree for these lines which compiles with dtc fine, 
no errors. I've configured uEnv.txt to not load any other overlays, 
everything we don't need is disabled. As a result of the universal-cape not 
being loaded, I can't use config-pin to query if my pins have been setup 
correctly through my device tree.

Should I ditch my device tree based setup, and use the universal-cape along 
with a script to configure my pimuxing? Would this approach be easier to 
debug/verify?

Thanks in advance, Hugh

-- 
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/e564a1f5-5efd-4832-8365-96817dede943%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] no data from /dev/input/event1

[John Franey]

Hi,

I am experimenting with gpio_keys driver, to see if I can get it to work. 
 I fail.  Any suggestions?

I can read the value of the gpio through /sys/class/gpio/cpio48/value, and 
the value in fact changes depending on the button pressed/released.  The 
trouble: NOTHING comes up through /dev/input/event1 when I hit the button, 
demonstrated by evtest:

root@beaglebone:~/keys/overlay# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: tps65217_pwr_but
/dev/input/event1: ocp:gpio_keys
Select the device event number [0-1]: 1
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "ocp:gpio_keys"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
Event code 28 (KEY_ENTER)
Properties:
Testing ... (interrupt to exit)



I hope I've provided enough information.

Thanks.



Attached is the overlay.  This was derived from Derek Molloy's dts 
(http://exploringbeaglebone.com/chapter6/), and from the universal cape 
dts.  I started with Malloy's, but it didn't work.  I thought it was 
because my circuit has a pull-down register and his configured the gpio 
controller's pull-up resister).  So, I changed the dts to use neither, and, 
incidentally, changed the node name from pushbotton_pins to P9_15_gpio_pin 
(matching the name used by universal dts).  Then, I read here that the gpio 
offset had changed from debian 3.8 to 4.x (which I'm using), and so also 
made that necessary edit too.


uname:

root@beaglebone:~/keys/overlay# uname -a
Linux beaglebone 4.4.36-ti-r72 #1 SMP Wed Dec 7 22:29:53 UTC 2016 armv7l 
GNU/Linux



Here is edge:

root@beaglebone:~/keys/overlay# cat /sys/class/gpio/gpio48/edge
both

Yes, I had the universal cape disabled at boot time for this experiment.   
My /boot/uEnv.txt:

#cmdline=coherent_pool=1M quiet net.ifnames=0 cape_universal=enable
cmdline=coherent_pool=1M quiet net.ifnames=0





Here is slots:

root@beaglebone:~/keys/overlay# cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1 
 1: PF  -1 
 2: PF  -1 
 3: PF  -1 
 5: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-BONE-KEYS


Here is dmesg:

[ 1802.211933] bone_capemgr bone_capemgr: part_number 'BB-BONE-KEYS', 
version 'N/A'
[ 1802.212015] bone_capemgr bone_capemgr: slot #5: override
[ 1802.212061] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 5
[ 1802.212109] bone_capemgr bone_capemgr: slot #5: 'Override Board 
Name,00A0,Override Manuf,BB-BONE-KEYS'
[ 1802.238081] input: ocp:gpio_keys as 
/devices/platform/ocp/ocp:gpio_keys/input/input2
[ 1802.252947] bone_capemgr bone_capemgr: slot #5: dtbo 
'BB-BONE-KEYS-00A0.dtbo' loaded; overlay id #0


-- 
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/c6cd258c-aa39-4d80-bc9c-097299f36ab2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


BB-BONE-KEYS-00A0.dts
Description: Binary data

Re: [beagleboard] Disabling PowerOff and Reset button

[PM]

Okay I found the dtsi file in /opt/source/dtb-4.9-ti/src/arm/ :)

Do I have to recompile it after editing the file ?

If Yes, what command should i type ?

Thanks :)


Le lundi 27 mars 2017 18:04:04 UTC+2, PM a écrit :
>
> Thanks for the info.
>
> I tried to find the corresponding dtb to modify but no success :(
>
> I can't find any am335x-bone-common.dtb. Do you know where should I look ?
>
> Regards,
>
> PM
>
> Le lundi 27 mars 2017 15:14:37 UTC+2, Jason Kridner a écrit :
>>
>>
>>
>> On Mar 27, 2017, at 8:47 AM, Gerald Coley  wrote:
>>
>> Reset pin goes to the reset line and the power button goes to the PMIC. 
>> PMIC pins and reset lines are not controlled via the DTS file 
>>
>>
>> The interrupt into software for the power button is dts controlled:
>>
>> https://patchwork.kernel.org/patch/9389243/
>>
>> You can eliminate the software shutdown, but the hardware will still do a 
>> power down if the button is held for more than about 10-12 seconds. 
>>
>>
>>
>>
>>
>> On Mon, Mar 27, 2017 at 5:02 AM, PM  wrote:
>>
>>> Hello everybody,
>>>
>>> I am trying to disable my reset & poweroff button from my LCD7 cape.
>>> I saw on the schematic diagram that these buttons are directly connected 
>>> to SYS_RESET & PWR_BUT.
>>>
>>> I would like to know if it is possible to disable these buttons by 
>>> editing any 'dts' or 'dtso' file ?
>>>
>>> Thank you very much.
>>>
>>> -- 
>>> 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/37da3ff7-94d4-4305-ad02-49b8c000655f%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Gerald
>>  
>> ger...@beagleboard.org
>> http://beagleboard.org/
>> gcol...@emprodesign.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/CAHK_S%2BccvBKiyy5-AXM7pU5eSP4S09%2B1XVH2kQp5P-zk-3PVzQ%40mail.gmail.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/99aea23d-37ac-4aaa-a5ca-984b6ec14b9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Checking battery status or charge available in the battery in BBBL

[Adam Bennett]

Jeshwanth,

You can approximate battery SOC from resting voltage, see the following 
links for the extended discussion:

https://www.rcgroups.com/forums/showthread.php?956764-LiPoly-Capacity-versus-open-voltage

http://www.helifreak.com/showthread.php?t=333661

The BBBL battery per-cell voltage is available with rc_check_battery

Adam

On Tuesday, March 28, 2017 at 7:34:12 AM UTC-4, Jeshwanth Kumar N K wrote:
>
> Hello,
>
> I have connected my LIPO battery to my BBBL. I would like to know the 
> charge lever in my battery. Is that feature available in BBL?
>
> I have checked in /sys/class/power_supply 
>
> noting I found, any driver I need to attach ?
>
> And battery_monitor.service is running fine.
>
> 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/2bff860f-d9d7-4e8c-b1ce-79ca8c3a0474%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bb.org-overlays: "File Exists" Error when attempting to load device tree for 'BB-UART1'

[Robert Nelson]

On Tue, Mar 28, 2017 at 9:16 AM,   wrote:
>
> Hello All,
>
> I am trying to get CAN working on a Beaglebone Black running the following
> kernel:
>
> Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l
> GNU/Linux
>
> I am attempting to use the CAN1 interface on the BeageBone as I have done
> previously on other distriubutions, however when I follow the instructions
> posted here: https://github.com/RobertCNelson/bb.org-overlays I get an
> error.
>
> For example, if I try the following:
>
> root@beaglebone:/home/debian#  echo 'BB-UART1' >
> /sys/devices/platform/bone_capemgr/slots
> bash: echo: write error: File exists
>
> Dmesg output:
>
> [   40.829790] bone-pinmux-helper: probe of ocp:P9_31_pinmux failed with
> error -22
> [   40.859306] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0
> [   40.859510] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1
> [   40.859679] gpio-of-helper ocp:cape-universal: Allocated GPIO id=2
> [   40.859851] gpio-of-helper ocp:cape-universal: Allocated GPIO id=3
> [   40.860015] gpio-of-helper ocp:cape-universal: Allocated GPIO id=4
> [   40.860176] gpio-of-helper ocp:cape-universal: Allocated GPIO id=5
> [   40.860351] gpio-of-helper ocp:cape-universal: Allocated GPIO id=6
> [   40.860513] gpio-of-helper ocp:cape-universal: Allocated GPIO id=7
> [   40.860683] gpio-of-helper ocp:cape-universal: Allocated GPIO id=8
> [   40.860852] gpio-of-helper ocp:cape-universal: Allocated GPIO id=9
> [   40.861016] gpio-of-helper ocp:cape-universal: Allocated GPIO id=10
> [   40.861194] gpio-of-helper ocp:cape-universal: Allocated GPIO id=11
> [   40.861365] gpio-of-helper ocp:cape-universal: Allocated GPIO id=12
> [   40.861534] gpio-of-helper ocp:cape-universal: Allocated GPIO id=13
> [   40.861705] gpio-of-helper ocp:cape-universal: Allocated GPIO id=14
> [   40.861874] gpio-of-helper ocp:cape-universal: Allocated GPIO id=15
> [   40.875457] gpio-of-helper ocp:cape-universal: Allocated GPIO id=16
> [   40.875733] gpio-of-helper ocp:cape-universal: Allocated GPIO id=17
> [   40.875912] gpio-of-helper ocp:cape-universal: Allocated GPIO id=18
> [   40.876095] gpio-of-helper ocp:cape-universal: Allocated GPIO id=19
> [   40.876259] gpio-of-helper ocp:cape-universal: Allocated GPIO id=20
> [   40.876418] gpio-of-helper ocp:cape-universal: Allocated GPIO id=21
> [   40.876580] gpio-of-helper ocp:cape-universal: Allocated GPIO id=22
> [   40.876735] gpio-of-helper ocp:cape-universal: Allocated GPIO id=23
> [   40.876889] gpio-of-helper ocp:cape-universal: Allocated GPIO id=24
> [   40.881135] gpio-of-helper ocp:cape-universal: Allocated GPIO id=25
> [   40.881355] gpio-of-helper ocp:cape-universal: Allocated GPIO id=26
> [   40.881558] gpio-of-helper ocp:cape-universal: Allocated GPIO id=27
> [   40.881716] gpio-of-helper ocp:cape-universal: Allocated GPIO id=28
> [   40.881877] gpio-of-helper ocp:cape-universal: Allocated GPIO id=29
> [   40.886404] gpio-of-helper ocp:cape-universal: Allocated GPIO id=30
> [   40.886687] gpio-of-helper ocp:cape-universal: Allocated GPIO id=31
> [   40.886865] gpio-of-helper ocp:cape-universal: Allocated GPIO id=32
> [   40.887041] gpio-of-helper ocp:cape-universal: Allocated GPIO id=33
> [   40.887201] gpio-of-helper ocp:cape-universal: Allocated GPIO id=34
> [   40.887366] gpio-of-helper ocp:cape-universal: Allocated GPIO id=35
> [   40.887526] gpio-of-helper ocp:cape-universal: Allocated GPIO id=36
> [   40.887538] gpio-of-helper ocp:cape-universal: ready
> [   40.898497] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 199,
> base_baud = 300) is a 8250
> [   40.908411] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 200,
> base_baud = 300) is a 8250
> [   40.918518] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 201,
> base_baud = 300) is a 8250
> [   40.930524] eqep 48300180.eqep: ver. 1.0
> [   40.940161] eqep 48302180.eqep: ver. 1.0
> [   40.957039] eqep 48304180.eqep: ver. 1.0
> [   40.975138] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
> [   41.016139] bone_capemgr bone_capemgr: slot #4: dtbo
> 'cape-universaln-00A0.dtbo' loaded; overlay id #0
> [   41.020746] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping
> ok
> [   42.912836] CAN device driver interface
> [   43.056608] c_can_platform 481cc000.can: c_can_platform device registered
> (regs=fa1cc000, irq=210)
> [   43.087789] c_can_platform 481d.can: c_can_platform device registered
> (regs=fa1d, irq=211)
> [  194.362266] bone_capemgr bone_capemgr: part_number 'BB-UART1', version
> 'N/A'
> [  194.362348] bone_capemgr bone_capemgr: slot #5: override
> [  194.362391] bone_capemgr bone_capemgr: Using override eeprom data at slot
> 5
> [  194.362439] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,BB-UART1'
> [  194.375726] bone_capemgr bone_capemgr: slot #5: BB-UART1 conflict P9.24
> (#4:cape-universaln)
> [  194.384469] bone_capemgr bone_capemgr: slot #5: Failed verification

[beagleboard] bb.org-overlays: "File Exists" Error when attempting to load device tree for 'BB-UART1'

[mta . alt03]

Hello All,

I am trying to get CAN working on a Beaglebone Black running the following 
kernel:

Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l 
GNU/Linux

I am attempting to use the CAN1 interface on the BeageBone as I have done 
previously on other distriubutions, however when I follow the instructions 
posted here: https://github.com/RobertCNelson/bb.org-overlays I get an 
error.

For example, if I try the following:

root@beaglebone:/home/debian#  echo 'BB-UART1' > 
/sys/devices/platform/bone_capemgr/slots
bash: echo: write error: File exists

Dmesg output:

[   40.829790] bone-pinmux-helper: probe of ocp:P9_31_pinmux failed with 
error -22
[   40.859306] gpio-of-helper ocp:cape-universal: Allocated GPIO id=0
[   40.859510] gpio-of-helper ocp:cape-universal: Allocated GPIO id=1
[   40.859679] gpio-of-helper ocp:cape-universal: Allocated GPIO id=2
[   40.859851] gpio-of-helper ocp:cape-universal: Allocated GPIO id=3
[   40.860015] gpio-of-helper ocp:cape-universal: Allocated GPIO id=4
[   40.860176] gpio-of-helper ocp:cape-universal: Allocated GPIO id=5
[   40.860351] gpio-of-helper ocp:cape-universal: Allocated GPIO id=6
[   40.860513] gpio-of-helper ocp:cape-universal: Allocated GPIO id=7
[   40.860683] gpio-of-helper ocp:cape-universal: Allocated GPIO id=8
[   40.860852] gpio-of-helper ocp:cape-universal: Allocated GPIO id=9
[   40.861016] gpio-of-helper ocp:cape-universal: Allocated GPIO id=10
[   40.861194] gpio-of-helper ocp:cape-universal: Allocated GPIO id=11
[   40.861365] gpio-of-helper ocp:cape-universal: Allocated GPIO id=12
[   40.861534] gpio-of-helper ocp:cape-universal: Allocated GPIO id=13
[   40.861705] gpio-of-helper ocp:cape-universal: Allocated GPIO id=14
[   40.861874] gpio-of-helper ocp:cape-universal: Allocated GPIO id=15
[   40.875457] gpio-of-helper ocp:cape-universal: Allocated GPIO id=16
[   40.875733] gpio-of-helper ocp:cape-universal: Allocated GPIO id=17
[   40.875912] gpio-of-helper ocp:cape-universal: Allocated GPIO id=18
[   40.876095] gpio-of-helper ocp:cape-universal: Allocated GPIO id=19
[   40.876259] gpio-of-helper ocp:cape-universal: Allocated GPIO id=20
[   40.876418] gpio-of-helper ocp:cape-universal: Allocated GPIO id=21
[   40.876580] gpio-of-helper ocp:cape-universal: Allocated GPIO id=22
[   40.876735] gpio-of-helper ocp:cape-universal: Allocated GPIO id=23
[   40.876889] gpio-of-helper ocp:cape-universal: Allocated GPIO id=24
[   40.881135] gpio-of-helper ocp:cape-universal: Allocated GPIO id=25
[   40.881355] gpio-of-helper ocp:cape-universal: Allocated GPIO id=26
[   40.881558] gpio-of-helper ocp:cape-universal: Allocated GPIO id=27
[   40.881716] gpio-of-helper ocp:cape-universal: Allocated GPIO id=28
[   40.881877] gpio-of-helper ocp:cape-universal: Allocated GPIO id=29
[   40.886404] gpio-of-helper ocp:cape-universal: Allocated GPIO id=30
[   40.886687] gpio-of-helper ocp:cape-universal: Allocated GPIO id=31
[   40.886865] gpio-of-helper ocp:cape-universal: Allocated GPIO id=32
[   40.887041] gpio-of-helper ocp:cape-universal: Allocated GPIO id=33
[   40.887201] gpio-of-helper ocp:cape-universal: Allocated GPIO id=34
[   40.887366] gpio-of-helper ocp:cape-universal: Allocated GPIO id=35
[   40.887526] gpio-of-helper ocp:cape-universal: Allocated GPIO id=36
[   40.887538] gpio-of-helper ocp:cape-universal: ready
[   40.898497] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 199, 
base_baud = 300) is a 8250
[   40.908411] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 200, 
base_baud = 300) is a 8250
[   40.918518] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 201, 
base_baud = 300) is a 8250
[   40.930524] eqep 48300180.eqep: ver. 1.0
[   40.940161] eqep 48302180.eqep: ver. 1.0
[   40.957039] eqep 48304180.eqep: ver. 1.0
[   40.975138] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz
[   41.016139] bone_capemgr bone_capemgr: slot #4: dtbo 
'cape-universaln-00A0.dtbo' loaded; overlay id #0
[   41.020746] asoc-simple-card sound: i2s-hifi <-> 48038000.mcasp mapping 
ok
[   42.912836] CAN device driver interface
[   43.056608] c_can_platform 481cc000.can: c_can_platform device 
registered (regs=fa1cc000, irq=210)
[   43.087789] c_can_platform 481d.can: c_can_platform device 
registered (regs=fa1d, irq=211)
[  194.362266] bone_capemgr bone_capemgr: part_number 'BB-UART1', version 
'N/A'
[  194.362348] bone_capemgr bone_capemgr: slot #5: override
[  194.362391] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 5
[  194.362439] bone_capemgr bone_capemgr: slot #5: 'Override Board 
Name,00A0,Override Manuf,BB-UART1'
[  194.375726] bone_capemgr bone_capemgr: slot #5: BB-UART1 conflict P9.24 
(#4:cape-universaln)
[  194.384469] bone_capemgr bone_capemgr: slot #5: Failed verification


I have no idea how to move forward and have been stuck here for a few days, 
does anyone have any suggestions?

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are 

Re: [beagleboard] BBGW Kernel Panic

[Robert Nelson]

On Mon, Mar 27, 2017 at 10:58 PM,   wrote:
>
> I'm encountering a kernel panic when I try to unload the "univ-bbgw" cape
> from my $SLOTS file.
>
> My setup is:
> Seeed BeagleBone Green Wireless
> Seeed Grove Base Cape for Beaglebone v2.0
> bone-debian-8.7-seeed-iot-armhf-2017-03-26-4gb
>
> Here's my terminal output and dmesg of the error:
> https://gist.github.com/alexmullins/a4f9673b2cb280679b8df11be1f4140f.
>
> I think this is the relevant part of dmseg:
>
> [  380.483327] Unable to handle kernel NULL pointer dereference at virtual
> address 000d
> [  380.491655] pgd = db5d4000
> [  380.494384] [000d] *pgd=9b533831, *pte=, *ppte=
> [  380.500908] Internal error: Oops: 17 [#1] SMP ARM
>
> I've looked at the univ-bbgw.dts and I don't see anything out of the
> ordinary there (I'm not great with device trees though).

That's normal, removing a cape via slots almost never works..

Instead in /boot/uEnv.txt find the "cape_universal=enable", remove
that and reboot.

> Also, I'm noticing that the Seeed Grove Base Cape for Beaglebone v2.0
> doesn't have a valid EEPROM signature:
>
> [2.554339] bone_capemgr bone_capemgr: Invalid signature '' at
> slot 3
>
> Not sure if that could have something to do with this.
>
> Does anyone have any tips on where to go from here?

a custom overlay needs to be written for this cape.

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

[beagleboard] Does SPI1 need timer4 pin 8.07?

[Gaurav S]

Hello,

I am creating a custom cape which uses SPI1 with both cs0 and cs1 and uses 
multiple GPIO pins including 8.07 mapped as GPIO pin.. My prototype has 
been working without issues but I recently noticed a curious issue while 
parsing dmesg:


[   10.775173] pinctrl-single 44e10800.pinmux: pin 44e10890.0 already 
requested by ocp:gpio_helper; cannot claim for 481a.spi
[   10.786802] pinctrl-single 44e10800.pinmux: pin-36 (481a.spi) status 
-22
[   10.793955] pinctrl-single 44e10800.pinmux: could not request pin 36 
(44e10890.0) from group MYTEST_GPIO  on device pinctrl-single
[   10.805516] omap2_mcspi 481a.spi: Error applying setting, reverse 
things back


where MYTEST_GPIO is:

__overlay__ {
  my_example: MYTEST_GPIO {
pinctrl-single,pins = <
0x090 0x07  // P8_07 this seems to be the 
offending pin 
0x094 0x07  // P8_08 
   // few more pins not shown here
>;
 };
 };

The SPI overlay is:
bb_spi1_pins: pinmux_bb_spi1_pins {
pinctrl-single,pins = <
0x190 0x33 /* spi1_sclk, INPUT_PULLUP | MODE3 */
0x194 0x13 /* spi1_d0, OUTPUT_PULLUP | MODE3 */
0x19c 0x13 /* spi1_cs0, OUTPUT_PULLUP | MODE3 */
0x164 0x12 /* spi1_cs1 OUTPUT_PULLUP | MODE2 */
>;
};

I am not defining the use of a timer in the overlays. I understand SPI 
needs to generate a clock in master mode, though I am not sure if one of 
the timers is used for this purpose. However, I am not sure I understand 
why is the pin 8.07 physically required especially when I am mapping it as 
a GPIO pin. 

Some system information if it helps:
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.47-ti-r87 #1 SMP Mon Feb 6 22:21:49 UTC 2017 armv7l 
GNU/Linux

debian@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
 0: P---L-   0 4D 4.3 LCD CAPE- 4DCAPE-43T ,00A1,4D SYSTEMS 
 ,BB-BONE-LCD4-01
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   1 Override Board Name,00A0,Override Manuf,MYTEST-SPIDEV1
 5: P-O-L-   2 Override Board Name,00A0,Override Manuf,MYTEST-GPIO

Any thoughts would be appreciated..

Thanks
Gaurav


-- 
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/6238f910-b71f-475a-ab34-a790cb892821%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] UART4 RS485 (RTS) not working

[Matthew Bezuidenhout]

Hi all,

For days now, I've been attempting to get the Waveshare RS485/CAN Cape to 
work on Beaglebone black.

I've used kernels 4.4.x and 4.9.x-ti mainline, and encountered the same 
problem.

The cape can use any UART (have been trying with one), and requires the use 
of pin P9_42 (0x164) as an RTS pin.

The dtbo (standard from https://github.com/beagleboard/bb.org-overlays 
which uses pin P9_27) loads fine using 

   echo BB-UART4-RS485 > /sys/devices/platform/bone_capemgr/slots

A "cat /sys/devices/platform/bone_capemgr" reveals the slot has been loaded 
correctly.

The HDMI has successfully been disabled.

Three problems arise:

PROBLEM 1:
The wavheshare cape requires the pulldown of both UART pins (I used UART4), 
as it leaves the pins floating through the RS485 transceiver if left 
standard. Now, the tricky thing is, if I enable BB-UARt4-RS485 in the 
/boot/uEnv.txt file, it loads the cape fine, but will not do pulldowns. If 
I allow the beaglebone to boot, then echo the BB-UART at slots, the 
pulldown works and the transceiver can send a signal through, which is 
curious as it is exactly the same dtbo it loads, whether from uEnv.txt or 
echo.

PROBLEM 2:
Once loaded using echo after start, if I "cat /proc/tty/driver/serial" 
immediately after loading UART RS485 overlay, the flags I'm presented with 
are as below:

0: uart:8250 mmio:0x44E09000 irq:158 tx:8304 rx:0 RTS|CTS|DTR|DSR
1: uart:unknown port: irq:0
2: uart:unknown port: irq:0
3: uart:unknown port: irq:0
4: uart:8250 mmio:0x481A8000 irq:198 tx:0 rx:0 CTS|DSR
5: uart:unknown port: irq:0


Showing UART4 (the one I'm using) has not loaded the CTS and RTS flags 
appropriately. However, if, before performing the cat, I screen into ttyS4 
or ttyO4 or echo some characters at the port, and then I perform the "cat" 
as above, the RTS and DTR flags are both raised on 4. Thereafter, if I 
screen in on ttyO4, and then quit, the RTS flag disappears after a cat. 
Weird.

However, regardless of these results, I'm left with the following main 
problem,

PROBLEM 3:
Regardless of the flag position or whether I use the default 
BB-UART4-RS485-00A0.dtbo from the source, the RTS pin does not switch (both 
P9_27 and P9_42 are unresponsive to any efforts to communicate on the 
UART4, where the UART transmits as evidenced by the oscilliscope, but the 
oscilliscope shows that the RTS pin P9_42/27 does not move at all). I need 
to get pin 9_42 to switch for RTS during uart, else this cape (and the 
beaglebone) are useless to me.

After copious amounts of time reading up on this, it seems that its a 
common problem, and something to do with the OMAP serial driver vs the 8250 
driver malfunctioning? If someone could provide some insight to the 
problem, or a guide on how to get RTS working on this Beaglebone I'd be 
very appreciative.

Kind regards,
Matt.
 

-- 
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/925dcc4d-8281-42a8-9b3c-69d03a7be467%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Checking battery status or charge available in the battery in BBBL

[Jeshwanth Kumar N K]

Hello,

I have connected my LIPO battery to my BBBL. I would like to know the 
charge lever in my battery. Is that feature available in BBL?

I have checked in /sys/class/power_supply 

noting I found, any driver I need to attach ?

And battery_monitor.service is running fine.

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/69343586-76c2-4545-847e-3224f26b1433%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] seedstudio Grove Cape on BBG

[jalexmullins91]

I have this board (V2) and get the same error on boot. I pulled the EEPROM 
from the board with:

cat /sys/devices/platform/ocp/4819c000.i2c/i2c-2/2-0057/eeprom > 
/var/tmp/eeprom.dump 

and contains all 0x. 

On Tuesday, February 14, 2017 at 1:10:28 PM UTC-6, RobertCNelson wrote:
>
> On Tue, Feb 14, 2017 at 11:40 AM, Rva  
> wrote: 
> > on a IOT Image :bone-debian-8.6-iot-armhf-2016-11-06-4gb.img 
> > 
> > Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l 
> > GNU/Linux 
> > 
> > 
> > 
> > Dmesg , shows me some errors 
> > 
> > 
> > [2.302582] bone_capemgr bone_capemgr: Baseboard: 
> > 'A335BNLT,BBG1,BBG216060130' 
> > 
> > [2.302615] bone_capemgr bone_capemgr: 
> > compatible-baseboard=ti,beaglebone-black - #slots=4 
> > 
> > [2.341680] bone_capemgr bone_capemgr: slot #0: No cape found 
> > 
> > [2.385679] bone_capemgr bone_capemgr: slot #1: No cape found 
> > 
> > [2.429675] bone_capemgr bone_capemgr: slot #2: No cape found 
> > 
> > [2.460699] bone_capemgr bone_capemgr: Invalid signature '' 
> at 
> > slot 3 
>
> With no eeprom, that makes detection hard.. Which cape is this? 
>
> http://wiki.seeed.cc/Grove_Base_Cape_for_BeagleBone_v2/ 
>
> or 
>
> http://wiki.seeed.cc/Grove_Cape_for_BeagleBone_Series/ 
>
> 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/dec087a9-2207-4c0b-b6a5-4debbac47ab2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBGW Kernel Panic

[jalexmullins91]

I'm encountering a kernel panic when I try to unload the "univ-bbgw" cape 
from my $SLOTS file. 

My setup is: 
Seeed BeagleBone Green Wireless
Seeed Grove Base Cape for Beaglebone v2.0
bone-debian-8.7-seeed-iot-armhf-2017-03-26-4gb

Here's my terminal output and dmesg of the error: 
https://gist.github.com/alexmullins/a4f9673b2cb280679b8df11be1f4140f. 

I think this is the relevant part of dmseg: 

[  380.483327] Unable to handle kernel NULL pointer dereference at virtual 
address 000d
[  380.491655] pgd = db5d4000
[  380.494384] [000d] *pgd=9b533831, *pte=, *ppte=
[  380.500908] Internal error: Oops: 17 [#1] SMP ARM

I've looked at the univ-bbgw.dts 

 and 
I don't see anything out of the ordinary there (I'm not great with device 
trees though).

Also, I'm noticing that the Seeed Grove Base Cape for Beaglebone v2.0 
doesn't have a valid EEPROM signature:

[2.554339] bone_capemgr bone_capemgr: Invalid signature '' at 
slot 3

Not sure if that could have something to do with this.

Does anyone have any tips on where to go from here?

Thanks,

-Alex

-- 
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/a2b3d1f6-aa39-45a3-980b-99fdb10651ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.