[beagleboard] rc_test_motors Kernel panic

[One Speed]

Has anyone seen this? Odd since it is new for me. Beaglebone Blue. Have to 
forcibly reboot in order to get out of this issue.




root@beaglebone:/home/debian# timeout 1 rc_test_motors -s .1

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.506728] Internal error: : 1028 [#1] PREEMPT SMP ARM

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.625561] Process rc_test_motors (pid: 1075, stack limit = 
0xdb306218)

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.632292] Stack: (0xdb307e18 to 0xdb308000)

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.636669] 7e00:
   0001 

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.644886] 7e20:  db307e7c db49cd80 c081df48 db49cda0 
  db239910

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.653104] 7e40: db307e74 db307e50 c081b72c c081df54 c1504dc8 
 dc520394 db49cd80

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.661322] 7e60: 0002 daa85840 db307eb4 db307e78 c081be7c 
c081b618  9c40

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.669538] 7e80:   0001 77533b88 0002 
c081be00 db239900 

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.677755] 7ea0:  db307f68 db307ecc db307eb8 c092f108 
c081be0c c092f0e0 db239900

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.685972] 7ec0: db307ee4 db307ed0 c03855c4 c092f0ec 0002 
db239900 db307f1c db307ee8

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.694190] 7ee0: c0384c10 c0385580   db678188 
c0384b18 dabff600 b6e84aec

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.702407] 7f00: db307f68  b6e84aec 0002 db307f34 
db307f20 c02f9258 c0384b24

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.710624] 7f20: 0002 dabff600 db307f64 db307f38 c02f943c 
c02f923c  c031bba0

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.718841] 7f40: c1504dc8 dabff600   dabff600 
b6e84aec db307fa4 db307f68

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.727058] 7f60: c02f96a4 c02f9394   0002 
77533b88 0005 0001

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.735275] 7f80: 000a  0004 c01090e4 db306000 
  db307fa8

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.743491] 7fa0: c0108f00 c02f9654 0001 000a 0003 
b6e84aec 0002 b6ea5620

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.751707] 7fc0: 0001 000a  0004 bef97568 
0005 0006 0007

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.759925] 7fe0:  bef974ac b6e66c8d b6e463b6 00070030 
0003  

Message from syslogd@beaglebone at Feb 15 04:00:34 ...
 kernel:[   74.839124] Code: e598 e6ffa07e eb049325 e5985028 (e1d570b0)
Segmentation fault

-- 
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/9d9cc377-94ff-4cf7-abd7-a28edef51992%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RPMsg not working on PRU1

[dinuxbg]

Did you also update the interrupt map:

struct ch_map pru_intc_map[] = { {18, 3},
 {19, 1},
};



Did you check that your PRU1 core is actually running and can drive the 
LED? For example, toggle the LED without rpmsg with a simple loop and delay.

Regards,
Dimitar

On Wednesday, February 13, 2019 at 9:06:48 PM UTC+2, Jacek Radzikowski 
wrote:
>
> I did. I even ran examples provided by TI, and the one for PRU1 does not 
> work.
>
> Jacek.
>
>
> On Wed, Feb 13, 2019 at 1:30 PM > wrote:
>
>> Did you change the interrupt numbers?
>>
>> /* The PRU-ICSS system events used for RPMsg are defined in the Linux 
>> device tre
>> e 
>>  * PRU0 uses system event 16 (To ARM) and 17 (From ARM) 
>>  * PRU1 uses system event 18 (To ARM) and 19 (From ARM) 
>>  */ 
>> #define TO_ARM_HOST 18   
>> #define FROM_ARM_HOST   19
>>
>>
>>
>> Regards,
>> Dimitar
>>
>> On Wednesday, February 13, 2019 at 10:02:25 AM UTC+2, Jacek Radzikowski 
>> wrote:
>>>
>>> Hello,
>>>
>>> I have problems with receiving remoteproc messages on PRU1. The code 
>>> works fine when configured and executed on PRU0, but PRU1 never receives 
>>> any interrupts (event numbers set for each PRU accordingly).
>>> I modified examples PRU_RPMsg_Echo_Interrupt0 and 
>>> PRU_RPMsg_Echo_Interrupt1 to flip I/O pins with LEDs whenever interrupt 
>>> comes. 
>>> On PRU0 example works as expected. Each time a message comes, the LED 
>>> switches state. However, example for PRU1 behaves like it never receives 
>>> any interrupts from ARM host. In my application I'm using interrupts to 
>>> signal PRU1 from PRU0, and hey work fine.
>>> Has anybody been able to resolve this issue?
>>>
>>> I'm running kernel 4.14.94-ti-r93 on Debian Image 2019-01-27, with PRU 
>>> tools installed by ti-pru-cgt-installer  2.1.5-0rcnee1~stretch+20180514
>>>
>>> Regards,
>>> Jacek.
>>>
>>>
>>> -- 
>>> Given a choice between two theories, take the one which is funnier 
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/9ade0464-7903-4a00-9885-4649b243c1b7%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Given a choice between two theories, take the one which is funnier 
>

-- 
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/07741e37-2dca-4c5d-8559-65c5f488b4b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Blue +5v won't shut down

[Mala Dies]

Hello,

While reviewing this info. you provided, an optocoupler might just work. I 
found a site that sells them but I also found on that site, some datasheet. 
See here for the 
datasheet: 
https://www.analog.com/media/en/technical-documentation/data-sheets/ADuM1200_1201.pdf.

Seth

P.S. I have not tried this conversion yet so my mind would say take time. 
Do not rush if possible. Oh and from what I understand, the optocoupler 
works by shutting off instead of transferring the signal any further. The 
DigiKey site has some and I found one that is 
unidirectional: 
https://www.digikey.com/product-detail/en/analog-devices-inc/ADUM1201AR/ADUM1201AR-ND/725709&?gclid=CjwKCAiAwJTjBRBhEiwA56V7q0A4N0DBiSwt5Wm4ahl6pdiosiiP-YLgdJr-Y9oH2wYF3XcMOvw7FBoCLmoQAvD_BwE.
 
That datasheet above is the sheet for this link.

On Wednesday, February 13, 2019 at 8:57:09 PM UTC-6, Dan Hammans wrote:
>
> I'm kind of at a standstill. I found a circuit design to use a transistor 
> to take a 3.3v input, and switch on the 5v for the GPS but then while doing 
> more reading someone said that was a really bad idea because they weren't 
> opto-isolated. I didn't really know what that was, but after reading it 
> makes a little more sense. If the transistor fails or is otherwise damaged, 
> it could end up feeding 5v into the 3.3v section of the Beagleboard and fry 
> it.
>
> I was looking for an opto-isolated transistor relay, found one but haven't 
> gotten one ordered yet to try it out.
>
> That's pretty much the status, I was going to try and talk to an 
> electrical engineer friend of mine to see what he thought of the situation. 
> What do you think?
>
> Thanks,
> Dan
>
> On Wed, Feb 13, 2019 at 8:17 PM Mala Dies > 
> wrote:
>
>> Hey Man,
>>
>> Seth here. Did you ever figure out the issue w/ setting up a GPIO pin to 
>> control the 5v for your GPS?
>>
>> Seth
>>
>> On Sunday, February 10, 2019 at 12:38:52 AM UTC-6, Dan Hammans wrote:
>>>
>>> No apologies needed, I'm just trying to figure this out. What  I meant 
>>> was using a GPIO pin to trigger the relay/transistor which would then 
>>> switch on +5v.
>>>
>>> I'll take a look at the links above, appreciate your help!
>>>
>>> On Saturday, February 9, 2019 at 11:58:08 PM UTC-6, Mala Dies wrote:

 Sir,

 I just found a source for ideas: 
 https://next-hack.com/index.php/2017/09/15/how-to-interface-a-5v-output-to-a-3-3v-input/.
  
 Adding a button and software could prove valuable. If anything, it may 
 help 
 a bit.

 Seth

 P.S. GPIO works for buttons, LEDs, and other circuitry. I am sure you 
 know how to do things. I was trying to latch on to learn more. Sorry.

 On Saturday, February 9, 2019 at 11:19:47 PM UTC-6, Dan Hammans wrote:
>
> Hi Seth, I really appreciate the reply.
>
> I was afraid of that. My GPS module requires +5v. Is there another +5v 
> source on the board that is switched off when the board powers down? What 
> about the black power connector above the GPS UART port?
>
> Otherwise it looks like I will be building a resistor circuit and 
> triggering it from a GPIO pin.
>
> On Saturday, February 9, 2019 at 11:07:14 PM UTC-6, Mala Dies wrote:
>>
>> Sir,
>>
>> Seth here. I just got done dealing w/ someone on this subject. The 5v 
>> pin from the GPS connection cannot be "un"powered. It stays powered on 
>> while the board has power.
>>
>> Seth
>>
>> P.S. Try UART instead at 3.3v. This may help.
>>
>> On Saturday, February 9, 2019 at 2:58:12 AM UTC-6, Dan Hammans wrote:
>>>
>>> I'm not sure that I understand the difference between the 
>>> Beagleboard forum and the Beaglebone forum, but thought I would try 
>>> posting 
>>> here as well.
>>>
>>> I have a Beaglebone Blue connected to a GPS module via the GPS micro 
>>> JST connector. I selected this one because it has +5v, which is what is 
>>> needed for my GPS as opposed to 3.3v on the other UARTs. 
>>>
>>> The GPS module works correctly, but my issue is I can't power it 
>>> down. It's been suggested that the 5v rail can't be shut down with the 
>>> battery connected, but that seems rather odd to me. The also suggested 
>>> solution was to use a transistor to switch 5v power via a 3.3v GPIO 
>>> pin. I 
>>> suppose that's a solution but not a very elegant one if the board can 
>>> be 
>>> somehow configured to power off the 5v rail. It seems like this should 
>>> be 
>>> possible, albiet not easily accessible. There doesn't seem to be 
>>> much/any 
>>> documentation available about this at all.
>>>
>>> I made a Youtube video showing what's going on;
>>> https://www.youtube.com/watch?v=9xrXKRy97Yk
>>>
>>> Any suggestions appreciated, otherwise I think I'm going to have to 
>>> go down the path of the transistor relay...
>>>
>>>
>>> -- 
>> 

Re: [beagleboard] 4.19 bone kernel with uio_pruss?

['Suman Anna' via BeagleBoard]

On 2/13/19 1:11 PM, Matthijs van Duin wrote:
> On Wed, 13 Feb 2019 at 13:42, Roger Quadros  wrote:
>> On 13/02/19 13:57, Matthijs van Duin wrote:
>>> +#ifdef CONFIG_ARCH_DAVINCI_DA850
>>>   if (pdata->sram_pool) {
>>>   gdev->sram_pool = pdata->sram_pool;
>>
>> What is this sram pool? Is it about MSMC/OCMC RAM?
> 
> No idea, the sram pool is part of the uio-pruss driver for
> freon/primus (OMAP-L1xx / AM1xxx / TMS320C674x / DA8xx) SoCs which is
> in mainline, but it was never extended to the AM335x (or DT-based
> configuration in general).
> 
>> Why is this only for DA850?
> 
> I simply copied that #ifdef from the previous patchset that existed.
> Looking at mach-davinci/Kconfig, I guess it should probably be DA8XX
> instead. Since this patchset has so far only been used for kernels
> that aren't used on freon/primus anyway, it hasn't really mattered.
> 
>>> 0002: add missing hwmods for pruss on dra7 (cherry-pick of a commit also 
>>> needed for remoteproc-pru)
>>
>> This part will eventually be not needed as we are moving away from hwmods.
> 
> Yeah I know hwmods are going away in the long run, but this patchset
> was specifically to get things working on 4.19.
> 
>>> 0003: add support for ti,deassert-hard-reset (needed for uio-pruss on 
>>> am335x)
>>
>> This should also be managed by ti-sysc bus driver but using some form of
>> reset control driver that can toggle the necessary PRM registers RESET bit.
>> There were some challenges as to how to keep the clockdomain out of auto-idle
>> before reset can be issued.
> 
> Presumably whatever solution works for remoteproc-pru should also work
> for uio-pruss.
> 
>> The only issue I see here is these 2 properties
>>
>> compatible = "ti,pruss-v2";
>> ti,pintc-offset = <0x2>;
>>
>> It will be nice if we can retain the compatibles that I'm using here 
>> https://lkml.org/lkml/2019/2/4/679
> 
> I'm confused. Those are for remoteproc-pru, not uio-pruss. They expose
> different APIs to userspace, and in practice people use the
> compatible-string to select the driver.
> 
>> We use a different compatible for every SoC as there are differences e.g. 
>> different RAM sizes, number of interrupts, INTC offset, etc.
> 
> Although in principle the host interrupts available could be detected
> based on what's declared in DT, it actually seems to be the same
> across all PRUSS instances I've seen (namely 8: host2..host9). The
> only other thing that uio-pruss cares about is the INTC offset, which
> seems to be 0x4000 for the old PRUSS on freon/primus and 0x2 for
> every instance of PRU-ICSS (including PRU-ICSSG), so the two
> compatible-strings that the uio-pruss driver uses seem to be
> sufficient for determining that. The uio-pruss driver does not care at
> all about any other differences such as RAM sizes.
> 
>>> Obviously we could also change the uio-pruss driver to avoid this need for 
>>> this property entirely. It ought to be implicit from the compatible-string.
>>
>> Exactly.
> 
> When I find a moment I'll see if I can fix that.

Yeah, best to deal with this as a match data property. We can obviously
supply this using pdata-quirks as well, but definitely want to avoid
that short-term path.

Just FYI, I will be preparing my TI 4.19 baseline to support all the
SoCs within the next two weeks, and this will still follow the current
4.14 binding style, but I am going to move some of the files out of
remoteproc folder like Roger's series (as per the remoteproc
maintainer's wishes).

Roger's current upstream series is not yet ready to scale for all the
SoCs, and we are also lacking a whole bunch of ti-sysc support for
AM335x/AM437x on vanilla 4.19 kernel.

regards
Suman

-- 
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/e3463371-0eb9-dd02-1ef2-1e35a9b90883%40ti.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: No space on left device

[Mark A. Yoder]

If your SD is bigger than 4G try:

bone$ */opt/scripts/tools/grow_partition.sh*

The default images are for a 4G card.  If your card is bigger you need to 
grow your partition for the bigger card.

--Mark

On Thursday, February 14, 2019 at 3:55:14 AM UTC-5, Tarmo Kuuse wrote:
>
> Hi Ichrak,
>
> On Friday, 10 August 2018 20:42:33 UTC+3, Ichrak Mansour wrote:
>>
>> Hello,
>>
>> I am newbie, I use the version buster of my BeagleBone and when I run my 
>> application on it, I get "no space on left device" 
>>
>> How can I fix that please ? 
>>
>
> To diagnose the state of your disk space there are two basic tools. 
>
> 1. To get an overview of what's going on with your storage, "df -h" tells 
> how big is each mounted file system and how much of it is used.
> 2. To dig into specific directories, "sudo du -hs /dir" will tell you how 
> much storage space is used by files in directory /dir. 
>
> You can run snippets such as this to understand what exactly is consuming 
> space in directory /dir "sudo find /dir -maxdepth 1 -exec du -hs {} \;"
>
> Anyway, do mind where your application writes data - some filesystems such 
> as /tmp and /var/tmp are mounted as tmpfs (i.e. ramdisks) with rather small 
> size.
>
> To have a look at installed packages and their disk usage, I have found 
> this command to be useful: "dpkg-query -W -f '${Installed-Size} 
> ${Package}\n' | sort -n"
>
> --
> Kind regards,
> Tarmo
>

-- 
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/3c1e10ac-938a-4289-8bb9-b83fde13790e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Eth0 Stopped Working

[evilwulfie]

On 2/14/2019 1:40 AM, Tarmo Kuuse wrote:

Hi Jim,

On Wednesday, 13 February 2019 21:24:52 UTC+2, Jim Fell wrote:

Yesterday, my BeagleBone Black (Rev C) was working fine.  Today,
when I powered up the system eth0 is not coming up.

$ ip addr show eth0
2: eth0:  mtu 1500 qdisc noop state DOWN
group default qlen 1000
    link/ether c8:df:84:d7:07:a6 brd ff:ff:ff:ff:ff:ff


How do I get eth0 to come up again?  I've tried rebooting the
board with `$ sudo reboot` and restarting the service with `$ sudo
/etc/init.d/networking restart` but neither helped.  Yesterday, I
installed smbclient and cifs-utils, and deleted the /usr/src and
/usr/include directories.  Does anyone know how to get eth0 working?


There is a known problem with the Ethernet MAC not coming up on boot. 
This is likely to happen when you're powering the BeagleBone through 
the barrel connector. If this is the case, a simple reboot won't help. 
You need to shut down, remove power for 10 seconds and reconnect 
power. IIRC the physical reset button also helps.



physical reset button is a soft reset. a power cycle is the only way.


--
Kind regards,
Tarmo
--
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/16a25c7f-26aa-48fc-85c1-24270c0cd7b2%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/efc9301b-14bd-3837-360d-fb071e675d48%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Eth0 Stopped Working

[Jim Fell]

Thanks, Tarmo.  I re-imaged my BBB with the latest firmware from the 
BeagleBone website, and the problem seems to have cleared up.


On Thursday, February 14, 2019 at 3:40:16 AM UTC-5, Tarmo Kuuse wrote:
>
> Hi Jim,
>
> On Wednesday, 13 February 2019 21:24:52 UTC+2, Jim Fell wrote:
>>
>> Yesterday, my BeagleBone Black (Rev C) was working fine.  Today, when I 
>> powered up the system eth0 is not coming up.
>>
>> $ ip addr show eth0
>> 2: eth0:  mtu 1500 qdisc noop state DOWN group 
>> default qlen 1000
>> link/ether c8:df:84:d7:07:a6 brd ff:ff:ff:ff:ff:ff
>>
>>
>> How do I get eth0 to come up again?  I've tried rebooting the board with 
>> `$ sudo reboot` and restarting the service with `$ sudo 
>> /etc/init.d/networking restart` but neither helped.  Yesterday, I installed 
>> smbclient and cifs-utils, and deleted the /usr/src and /usr/include 
>> directories.  Does anyone know how to get eth0 working?
>>
>
> There is a known problem with the Ethernet MAC not coming up on boot. This 
> is likely to happen when you're powering the BeagleBone through the barrel 
> connector. If this is the case, a simple reboot won't help. You need to 
> shut down, remove power for 10 seconds and reconnect power. IIRC the 
> physical reset button also helps.
>
> --
> Kind regards,
> Tarmo 
>

-- 
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/e4749c71-e2a8-4fc0-8b9a-b6f9312790d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: LXQT autostart problem

[Harke Smits]

Hello Seth, and others interested,

Yes the .service file for the rtc works fine.
But my LXQT Autostart problem is getting strange. I have three versions of
basically the same Python script. V 3.6: using digital  I/O bits. V4.6 and
V5.6 use two pwm bits as well. And guess what: only V3.6 starts
automatically (on the same system) via Autostart. I can manually start the
other versions without any errors whatsoever. I tried different pwm pins,
no success. On another system v4.6 starts in autostart.

Its really puzzling. And taking a lot of time.
Will resume later unless you have a brilliant idea?
Best regards,
Harke




On Sun, 10 Feb 2019 at 18:41, Mala Dies  wrote:

> Yea. Harke,
>
> Hello...I think you need to update the entire image if you want to work w/
> a fixed/new bugs in the kernel. Anyway:
> https://wiki.qt.io/BeagleBone_Black_Beginners_Guide. That guide is
> something I found locally on this wiki/group.
>
> Seth
>
> P.S. I know that you are having trouble w/ the .service file for starting
> services on boot w/ QT. Do you have your .service file or a rendition?
>
> On Sunday, February 10, 2019 at 7:41:47 AM UTC-6, Harke Smits wrote:
>>
>> Hi Seth,
>>
>> Yes, the autorun problem is still there.
>> Going from old Debian releases to the latest one (9.5) gave me a couple
>> of surprises. My Python application proved to be portable but a lot needed
>> to be modified. One was the repacement of i2c-1 by i2c-2, while i2c-1 was
>> no longer accessible, by default. It took a while to understand what was
>> going on. I opened a topic elsewhere on this site but no response. Then
>> I applied the latest Adafruit rtc recipe (adapted for i2c-2!) and could
>> make the rtc work, in a way. I even managed to make a rtc installation
>> service work! Though the learning curve is steep at times, I am still no
>> expert and I doubt that the i2c issues has an influence on the aurorun
>> problem.
>> I am not familiar with .profile entries.
>> Thanks (again) for your efforts, Seth!
>> Cheers,
>> H
>>
>> On Sun, 10 Feb 2019 at 06:30, Mala Dies  wrote:
>>
>>> What about the .profile entries?
>>>
>>> Seth
>>>
>>> On Tuesday, February 5, 2019 at 3:41:10 AM UTC-6, Harke Smits wrote:

 Hello,

 I have a strange LXQT autostart problem. I have 4 BBB's all running the
 latest image (Debian 9.5). My python application runs fine on all of them
 (from QTerminal). On two of these systems I can make LXQT-Autostart my
 application work (LXQT settings-Session settings-Application Autostart,
 under LXQT Autostart). On the other two nothing runs automatically.  The
 .desktop files are all the same, their names as well. I tried everything I
 could think of, I even re-installed the image. No luck. This already took
 me days. Please help  me out or give me a pointer where to look.
 Thanks a lot.
 Harke  .

>>> --
>>> 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/SdeWndpLKck/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/8727de25-7917-4293-aab0-5d83112cabf4%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/SdeWndpLKck/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/msgid/beagleboard/2ec5e916-0da2-4836-9e24-c4c4b29cf094%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/CAHmciaY1V5HSsir_r%3DyPZXy7%3Dxvd7kXR9VNt0oDgtZ1zfn0cWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: No space on left device

[Tarmo Kuuse]

Hi Ichrak,

On Friday, 10 August 2018 20:42:33 UTC+3, Ichrak Mansour wrote:
>
> Hello,
>
> I am newbie, I use the version buster of my BeagleBone and when I run my 
> application on it, I get "no space on left device" 
>
> How can I fix that please ? 
>

To diagnose the state of your disk space there are two basic tools. 

1. To get an overview of what's going on with your storage, "df -h" tells 
how big is each mounted file system and how much of it is used.
2. To dig into specific directories, "sudo du -hs /dir" will tell you how 
much storage space is used by files in directory /dir. 

You can run snippets such as this to understand what exactly is consuming 
space in directory /dir "sudo find /dir -maxdepth 1 -exec du -hs {} \;"

Anyway, do mind where your application writes data - some filesystems such 
as /tmp and /var/tmp are mounted as tmpfs (i.e. ramdisks) with rather small 
size.

To have a look at installed packages and their disk usage, I have found 
this command to be useful: "dpkg-query -W -f '${Installed-Size} 
${Package}\n' | sort -n"

--
Kind regards,
Tarmo

-- 
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/f5b49abd-22da-4635-b41e-b1981765cb86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Eth0 Stopped Working

[Tarmo Kuuse]

Hi Jim,

On Wednesday, 13 February 2019 21:24:52 UTC+2, Jim Fell wrote:
>
> Yesterday, my BeagleBone Black (Rev C) was working fine.  Today, when I 
> powered up the system eth0 is not coming up.
>
> $ ip addr show eth0
> 2: eth0:  mtu 1500 qdisc noop state DOWN group 
> default qlen 1000
> link/ether c8:df:84:d7:07:a6 brd ff:ff:ff:ff:ff:ff
>
>
> How do I get eth0 to come up again?  I've tried rebooting the board with 
> `$ sudo reboot` and restarting the service with `$ sudo 
> /etc/init.d/networking restart` but neither helped.  Yesterday, I installed 
> smbclient and cifs-utils, and deleted the /usr/src and /usr/include 
> directories.  Does anyone know how to get eth0 working?
>

There is a known problem with the Ethernet MAC not coming up on boot. This 
is likely to happen when you're powering the BeagleBone through the barrel 
connector. If this is the case, a simple reboot won't help. You need to 
shut down, remove power for 10 seconds and reconnect power. IIRC the 
physical reset button also helps.

--
Kind regards,
Tarmo 

-- 
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/16a25c7f-26aa-48fc-85c1-24270c0cd7b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.