[beagleboard] Re: Where are VDD and SYS_RESETn?

[Graham]

I have been unable to get a PocketBeagle to run for more than about 12 
hours without rebooting when powered from Vin (P1-pin1), using a trusted 
power supply.
It usually reboots itself successfully, so in order to see it, run some 
commands to turn off the blinking blue lights. If they come back on by 
themselves, it has rebooted.
Or you can read the system logs.

It works fine when powered from Vi (P1-pin7) which is the same as the Vusb 
+5 Volt input/output.
It works fine when Vi and Vin are paralleled, but I am uncomfortable 
paralleling power supplies, unless someone who really understands them says 
it is OK.

The docs indicate that Vin (P1-pin1) should be the primary power input for 
power inputs other than battery or USB, and this input should have the 
highest current handling capability of the three.

So far, I find that Vin is approximately worthless.
Your mileage may vary.
So far, no reaction or comment from Jason or Robert.

If you can, or can not, duplicate my observations, please comment.

As far as a replacement for  SYS_RESETn, I don't think that the external 
3V3 power appears until the system has booted, so you could use this 
Voltage to gate things that might upset the boot process, or break things 
prior to the CPU booting.
At least that is how it worked on the BBB, so I assume the same on the 
PocketBone.

--- Graham

==

On Friday, December 8, 2017 at 3:16:45 AM UTC-6, mike.ma...@gmail.com wrote:
>
> Nobody an idea? While searching through the board here I find two 
> different opinions about VDD/where to apply external power to, so some 
> clarification would be really nice...
>
>
>
> On Saturday, December 2, 2017 at 6:22:47 PM UTC+1, mike.ma...@gmail.com 
> wrote:
>>
>> Can somebody verify where the following pins/signals can be found at the 
>> PocketBeagle (comparing to BeagleBone Black):
>>
>> - VDD (to supply externel power apart from USB)
>> - SYS_RESETn (signalling SiP is in reset state and no inputs are allowed 
>> to be pulled to LOW or HIGH)
>>
>> ?
>>
>> 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/745ad78f-2b4c-468f-baf0-aca487c7d8d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone time runs slow despite starting /lib/systemd/systemd-timesyncd

[Graham]

I have been chasing something similar.
On Debian 8.8 and prior Jessie versions, systemd-timesyncd worked very well 
and issued a lot of (level debug) messages that told you what was going on, 
and the level of correction being applied.
When it is running the time would stay synced within 20 milliseconds or so.

On Stretch, I have been unable to receive any of these update messages.
Normally every 30 minutes, after initial correction convergence.
 rsyslog is correctly configured to capture them.

All I see is a single syslog message at the time of initial sync, then 
nothing.

I am unable to convince myself that systemd-timesyncd is actually running, 
even though

systemctl status systemd-timesyncd.service

says that it is.

--- Graham

==

On Friday, December 8, 2017 at 9:39:21 PM UTC-6, wku...@gmail.com wrote:
>
> I've an IOT application distributed over multiple systems all on a local 
> network and  all synchronized with some flavor of ntp running.
>
> These all stay syncronized to within a second over long periods:
> Raspberry Pi2
> Raspberry Pi3
> Raspberry PiZero-W
> Ubuntu 16.04 desktop
> Commercial Lorex security DVR
>
> These two have drifted about three seconds slow already, although they 
> seem well synced with each other:
> Beaglebone Green running Debian 8.9  (rebooted this morning)
> Beaglebone White running Debian 9.2 (booted yesterday morning)
>
>
> All the Raspberries are running Raspbian, verson 8 for the Pi2 and version 
> 9 for the rest
>
> My initial assumption is somehow they are using different time servers 
> that have a systematic error.  Problem is I can't find where the 
> systemd-timesync stores its servers to see if Beaglebones  ntp server 
> settings matches the others.
>
> The Lorex box would drift until I changed it sync interval from 6 hours to 
> 1 hour.  All the systems that now stay synced appear to be using 
> pool.ntp.org,  I can't seem to find where the Beaglbones store the server 
> they use.
>
> Like with most things systemd I'm finding lots of misleading and confusing 
> information that is generally not matching what I'm finding on my systems, 
> but the Beaglebone solution may be as simple as it was for the Lorex device 
> -- shorten the sync interval.  But how do I find what the interval is and 
> then how do I shorten it?
>
> This system has been running and evolving since 2015, and I've noticed the 
> Beaglebones generally would be "off" + or - a few seconds from the 
> beginning of development, but I'm just now getting to adding the feature 
> that needs time sync accurate within one second.
>
>
>

-- 
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/e68d2316-638c-4c02-a874-969ab3bb96e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone time runs slow despite starting /lib/systemd/systemd-timesyncd

[wkulecz]

I've an IOT application distributed over multiple systems all on a local 
network and  all synchronized with some flavor of ntp running.

These all stay syncronized to within a second over long periods:
Raspberry Pi2
Raspberry Pi3
Raspberry PiZero-W
Ubuntu 16.04 desktop
Commercial Lorex security DVR

These two have drifted about three seconds slow already, although they seem 
well synced with each other:
Beaglebone Green running Debian 8.9  (rebooted this morning)
Beaglebone White running Debian 9.2 (booted yesterday morning)


All the Raspberries are running Raspbian, verson 8 for the Pi2 and version 
9 for the rest

My initial assumption is somehow they are using different time servers that 
have a systematic error.  Problem is I can't find where the 
systemd-timesync stores its servers to see if Beaglebones  ntp server 
settings matches the others.

The Lorex box would drift until I changed it sync interval from 6 hours to 
1 hour.  All the systems that now stay synced appear to be using 
pool.ntp.org,  I can't seem to find where the Beaglbones store the server 
they use.

Like with most things systemd I'm finding lots of misleading and confusing 
information that is generally not matching what I'm finding on my systems, 
but the Beaglebone solution may be as simple as it was for the Lorex device 
-- shorten the sync interval.  But how do I find what the interval is and 
then how do I shorten it?

This system has been running and evolving since 2015, and I've noticed the 
Beaglebones generally would be "off" + or - a few seconds from the 
beginning of development, but I'm just now getting to adding the feature 
that needs time sync accurate within one second.


-- 
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/d9b34e8e-a0c8-471e-996b-303e489059c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Stretch pwm difference

[Johan Henselmans]

OK, found out. Note to future self:

If you want /sys/clas/pwm/pwm-6:0, do an 
echo  0 > /sys/class/pwm/pwmchip6/export

I misunderstood that echo 0> /sys/class/pwm/pwmchip3/export was an unexport 
to reset things. 

To remove that channel, of course do a 
echo 0> /sys/class/pwm/pwmchip6/unexport
and
echo 1> /sys/class/pwm/pwmchip6/unexport

After that, first do some pwm settings, eg:
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:0/period
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:0/duty_cycle
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:1/period
echo 500 > /sys/class/pwm/pwmchip6/pwm-6\:1/duty_cycle

and after that you can do 

echo -n "1" > /sys/class/pwm/pwmchip6/pwm-6\:0/enable
echo -n "1" > /sys/class/pwm/pwmchip6/pwm-6\:1/enable

to have an effect. 

If you first enable the stuff before doing any setttings on period or 
duty_cycle, the kernel will not allow it.



On Thursday, December 7, 2017 at 10:35:08 AM UTC+1, Johan Henselmans wrote:
>
> I am trying to get p8_45 and p8_49 to run PWM2A and PWM2B signals. I am 
> running 4.14.3-ti-r14 with 
> enable_uboot_overlays=1
> enable_uboot_cape_universal=1
> disable_uboot_overlay_video=1
>
>
> According to the SRM that is possible, When I do an export to 
> echo 1 > /sys/class/pwm/pwmchip6/export
> , I only get /sys/clas/pwm/pwm-6:1
> With 
> echo 1 > /sys/class/pwm/pwmchip3/export
> , I get /sys/clas/pwm/pwm-3:0 and /sys/clas/pwm/pwm-3:1. 
>
> Why is that? Should I do anything else?
>
>
>
> On Friday, September 29, 2017 at 11:18:26 PM UTC+2, RobertCNelson wrote:
>>
>> On Fri, Sep 29, 2017 at 3:19 PM, William Hermans  
>> wrote: 
>> > Robert, 
>> > 
>> > Ok I think I see what you mean now( fully ). With universal IO and the 
>> > generic startup script enabled. I did see something similar to what you 
>> were 
>> > saying. However, if one disables both universal IO, and the generic 
>> startup 
>> > script, then writes their own custom overlay for all 3 of the PWM chips 
>> that 
>> > are dual channel. You get a structure like this: 
>> > 
>> > root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm 
>> > /sys/class/pwm/pwmchip0/: 
>> > npwm 
>> > /sys/class/pwm/pwmchip2/: 
>> > npwm 
>> > /sys/class/pwm/pwmchip4/: 
>> > npwm 
>> > 
>> > This is consistent across multiple images on the same board. In this 
>> case a 
>> > 4G beaglebone black( rev C ). But at the same time as you can see from 
>> the 
>> > output above. The two PWM channels for each PWM chip are not enabled. 
>> In 
>> > Jessie, these are populated automatically at boot. How can I make that 
>> > happen in stretch ? I could write a script, but I think that is done 
>> > automatically through cape_manager in Jessie ? 
>>
>> What's happening in v4.4.x, the pwm's are now in the correct order, if 
>> you look at v4.4.x: (pwm came before ecap) 
>>
>> #4.4.88-ti-r129 
>> pwmchip0 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip0 
>> pwmchip2 -> 
>> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2 
>> pwmchip4 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip4 
>> pwmchip6 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip6 
>> pwmchip7 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7 
>>
>> In v4.9.x: (since ecap are considered pwm's) they are now in the order 
>> of the register address: 
>>
>> pwmchip0 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0 
>> pwmchip1 -> 
>> ../../devices/platform/ocp/4830.epwmss/48300200.pwm/pwm/pwmchip1 
>> pwmchip3 -> 
>> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip3 
>> pwmchip5 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5 
>> pwmchip6 -> 
>> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip6 
>>
>> In your case, you only want the dual mode "pwm", (48300200.pwm, 
>> 48302200.pwm, 48304200.pwm), you shouldn't blindly enable the 
>> "pwmchip0,2,4" as they are dynamic.  You should grep the symlink 
>> first. 
>>
>> Ps, watch out for v4.11.x too: 
>>
>> #v4.4.x/v4.9.x 
>> /sys/class/pwm/pwmchip1/: 
>> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm0 
>> drwxr-xr-x 3 root root0 Sep 29 21:06 pwm1 
>>
>> #v4.11.x+ 
>>
>> /sys/class/pwm/pwmchip1/: 
>> drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:0 
>> drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:1 
>>
>> (ps, this last change is good thing, notice that udev correctly added 
>> the "root:pwm" rule.. ;) ) 
>>
>> 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 

[beagleboard] Re: Has Anyone Had Difficulty Outputting GPIO, UART, or I2C on the BB-X15's Expansion Header?

[Jeff Andich]

Ok, here's some of what we tried today on the 572xEVM/BB-X15. Once again, 
we were able to get GPIO working on our custom hardware board with the 
5728, but not yet on the 5728EVM/BB-X15.


1) We re-configured a pin (VOUT1_D6 on header P18) on the expansion header 
which is normally used for LCD video on the 572xEVM/BB-X15.  

2) We first confirmed that this pin, VOUT1_D6, was producing signals on the 
p18 expansion header, pin #45 (which I'm guessing is video for the LCD 
touchscreen) with a running BB-X15 LXQT image.  This gave a measure of 
confidence that this expansion port pin is connected to something on the 
5728, so it should be possible to put out GPIO on this expansion header 
pin, since the attached solder ball on the 5728 also has GPIO8_6 when you 
change MUX mode from 0 to 14..

3) We modified the pad configuration of VOUT_D6 in the SPL from  MuxMode, 
M0 to MuxMode 14 M14 by hacking the change directly into the operative pad 
configuration array entry (pad conf array delta array) for mux_data.h.  
{VOUT1_D6, (M14 | PIN_OUTPUT)}, /* vout1_d6.gpio8_6*/

4) We left the Pullup/Pulldown and slewcontrol bits the same as in 
VOUT_D6.  just changed M0 to M14!  I wasn't sure if this was correct, 
because other GPIO outputs like the 4 USR LEDs are configured as 
PIN_INPUT_PULLDOWN.  Not sure if the PU/PD state is related to the 
peripheral the PAD is connected to on the 5728 or what the peripheral 
connects to downstream.

5) We didn't change the IO delay array, as I didn't see any entries in the 
existing table for vout signals.

6) We then switched to a console image (uname_r 4.4.89-ti-r130 and 
/etc/dogtag= BeagleBoard.org Debian Image 2017-10-02) and then DD'ed the 
re-built SPL and u-boot.img to the uSD card.

7) We then checked the pin configuration by looking at 
/sys/kerne/debug/pinctl/4a003400.pinmux:
root@BeagleBoard-X15:/sys/kernel/debug/pinctrl/4a003400.pinmux# 
grep 35f4 *
pinmux-pins:pin 125 (4a0035f4.0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pins:pin 125 (4a0035f4.0) 0001000e pinctrl-single

Note: The change from 0 to E in the least significant nibble confirms 
change in pad configuration from M0 to M14.
Note: My assumption is that the kernel reads in an has knowledge of the pad 
configuration on the BB-X15.  Assume that you don't have to configure the 
pad again in the device tree.  The only peripheral which gets its pinmux 
setup in the device tree on the 5728 is the MMC.  I believe this is all 
described in TI's SPRAC44 app note.  Please correct and clarify this 
statement as you see fit..

8) We attempted to set the gpio pin, gpio8_6 via sysfs (Note, there are no 
GPIO enable directives in the device tree yet!)

Assume gpio8_6 is gpio 230 = [(8-1) * 32 + 6] = 230.

/sys/class/gpio/echo 230 > export

cat gpio230/direction = in

echo out > gpio230/direction

echo 1 >gpio230/value  ==> scope indicates pin #45 on connector, 
P18 is 0V.

echo 0 >gpio230/value  ==> scope indicates pin #45 on connector, 
P18 is 0V.


So this didn't affect the voltage on pin #45 on the P18 connector.


9) Then after not seeing any change in the voltage on pin #45, we attempted 
to turn on GPIO8 in the device tree:
 {
ti,no-reset-on-init;
ti,no-idle-on-init;
gpio = < 6 GPIO_ACTIVE_HIGH>;
};
Recompiled all the device trees in our 4.4.y RCN kernel tree using 
a modified version of build_kernel.sh to just re-build the dtb's.

copied to BB-X15, to /boot/dts/uname-r and then re-booted.

10) Repeat Step #8
   Got the same result.  No variation in voltage on pin #45 when 
echoing 1 vs 0 into the corresponding value file.

Next-steps:
Investigate what the correct PU/PD and slew control states should be 
for outputting signals on the expansion header.
Possibly update to a more recent image of u-boot and the kernel.
Possibly attempt to reproduce this on the latest TI SDK, as there was a 
discussion thread on E2E about this, and TI will only support their SDK.

Any and all suggestions/criticisms would be greatly appreciated!!


On Friday, December 8, 2017 at 10:21:54 AM UTC-6, Jeff Andich wrote:

> Still investigating this.  Still no luck with getting GPIO or UART to come 
> out on the corresponding pins on the expansion header with our PCBA 
> breakout board.
>
> I'll try to write up what I've found thus far by end of today (or by 
> Sunday).
>
>
> In the meantime, just taking a poll:
>
> Who here has successfully gotten her/his BeagleBoard-X15 to output known 
> signals on the expansion header pin? 
>
>
> Any information would be greatly appreciated.  Even a "Yes this worked 
> fine for me," would be helpful!
>
>
>
> On Tuesday, December 5, 2017 at 6:28:00 PM UTC-6, Jeff Andich wrote:
>>
>>
>>
>> On Tuesday, December 5, 2017 at 6:25:17 PM UTC-6, Jeff Andich wrote:
>>>
>>> Note: Per the 572xEVM_REVA3 schematic and the pad configuration of our 
>>> boot 

Re: [beagleboard] Re: Is there a BeagleBone Black IMU cape?

[Kyle Sulek]

There are also several IMU drivers in the mainline linux kernel

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/imu?h=v4.14

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

Re: [beagleboard] Maximum current on pins

[Giulio Moro]

For future reference:
this datasheet http://www.ti.com/lit/ds/symlink/am3358.pdf , Table 4-1 "Pin 
Attributes" 

On Thursday, May 25, 2017 at 4:05:28 PM UTC+1, gcoley1 wrote:
>
> It is found in the processor datashhet. It isn't much. 6mA max and as low 
> as 3mA.
>
>  
>
> Gerald
>
>  
>
>  
>
> *From:* beagl...@googlegroups.com  [mailto:
> beagl...@googlegroups.com ] *On Behalf Of *fm.wi...@gmail.com 
> 
> *Sent:* Thursday, May 25, 2017 8:20 AM
> *To:* BeagleBoard 
> *Subject:* [beagleboard] Maximum current on pins
>
>  
>
> Hello, 
>
> how do I figure out, how much current I can source/sink from my BeagleBone 
> Black's pins? What I have found:
> The manual of the AM335x Sitara Processor (
> http://www.ti.com/product/AM3359/technicaldocuments) provides me with a 
> table of the pin attributes. 
> The following pictures show the pin configuration of my BeagleBone Black.
>
> [image: 
> https://lh3.googleusercontent.com/-br4zU6dpRn8/WSbWd2-x6-I/AB0/A66cMQyc_3EUIkvH6LtG3Y6uaw5mLUJdQCLcB/s1600/P8_Header.png]
> For example: I want to know the maximum current I can source from P9_11. 
> Then I would look for the signal "GPIO_30". 
> The table tells me its provided by the processor pin named "GPCM_CSn1" 
> which can provide 6 mA. 
>
> *Is my answer correct?*
>
> However, I can't find "SYS_5V" for example. *How much current can I 
> source from that pin? And where do I get the information from?*
>
> I would be grateful for your help.
>
> -- 
> 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/23e9163d-032c-4e16-a5c6-b0d614daa15f%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/bf378fc0-12bb-44eb-9ae5-d3828403de97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Is there a BeagleBone Black IMU cape?

[Giulio Moro]

Slightly off-topic, but it may be more appropriate for some applications: 
there is an IMU (BNO055) for which there exists a Linux library. This IMU 
can be connected to the BeagleBone over I2C: 
https://github.com/theleadingzero/belaonurhead/tree/master/lib

On Tuesday, November 14, 2017 at 11:16:45 PM UTC, Kyle wrote:
>
> Does anyone know of a beaglebone cape with IMU capabilities that is still 
> in production? I have found plenty that seem to be end-of-life.
>

-- 
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/e9dee091-e83e-40b2-b5c8-cba338303e88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: fsck fails to start on writable partition at boot/startup

[mindentropy]

On Friday, December 8, 2017 at 9:05:02 PM UTC+5:30, Dennis Lee Bieber wrote:
>
> On Thu, 7 Dec 2017 19:17:09 -0800 (PST), 
> minde...@gmail.com  declaimed the 
> following: 
>
> > I too have a similar problem but not have worked directly on the 
> problem. 
> >This is in medical devices where the instruments power is pulled off 
> >abruptly without shutting down. Also the wear and tear of the eMMC and 
> >detection of errors etc. The problems become much more serious and I 
> cannot 
>
> Somehow I don't see a medical device being approved for usage if 
> it is 
> sensitive to the above. 
>
 
Yes it will not get approved if it is sensitive to all of these. Most of 
the regulated industries will not approve.

I'd suspect the device will need to have an ancillary power 
> management 
> circuit (super-cap or such to carry through a shutdown cycle with safety 
> margin) with an intermediate processor monitoring the main power. On 
> detection of loss of main power, the intermediate would trigger the safe 
> shutdown of the BBx. The eMMC would only contain the operating firmware 
> (ideally, it would be a read-only system), any dynamic data (logs, etc.) 
> should be placed on a field serviceable SD card. 
>
> I have seen this majority in microcontrollers. Being usually low power the 
super cap is ideal. There is also good voltage supervisors present to 
monitor the supply voltage.

You'll probably also need a few processes running that just 
> performs 
> checksums/CRCs of the critical firmware, and in extreme cases, periodic 
> tests of RAM (tricky to do when the OS can put a program anywhere in RAM). 
>

I have seen this being done in implantable medical hardware. Have you done 
something in similar to this. Would really like to hear your story.

Thanks,
Gautam.

 

> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.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/d60c5361-b9fe-427b-bae6-7a8060f29e52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Has Anyone Had Difficulty Outputting GPIO, UART, or I2C on the BB-X15's Expansion Header?

[Jeff Andich]

Still investigating this.  Still no luck with getting GPIO or UART to come 
out on the corresponding pins on the expansion header with our PCBA 
breakout board.

I'll try to write up what I've found thus far by end of today (or by 
Sunday).


In the meantime, just taking a poll:

Who here has successfully gotten her/his BeagleBoard-X15 to output known 
signals on the expansion header pin? 


Any information would be greatly appreciated.  Even a "Yes this worked fine 
for me," would be helpful!



On Tuesday, December 5, 2017 at 6:28:00 PM UTC-6, Jeff Andich wrote:
>
>
>
> On Tuesday, December 5, 2017 at 6:25:17 PM UTC-6, Jeff Andich wrote:
>>
>> Note: Per the 572xEVM_REVA3 schematic and the pad configuration of our 
>> boot loader, gpio5_8 comes out on pin 55 of the P17 expansion header on the 
>> BB-X15.
>>
>> Incidentally, I tried varying the brightness in 
>> /sys/class/leds/gpio_jeff_test to see if the level of gpio5_8 would change 
>> on the scope, but no luck  Varying the brightness works great with the 
>> blinking leds (gpio7_8, 7_9, 7_14, 7_15) on the top of the bb-x15.  You can 
>> turn them on an off by echoing different values in for "brightness."
>>
>> I was wondering if the expansion headers could be mis-labled on my 
>> board.  So I tried moving the breakout board around to all 4 of the 
>> expansion headers, but keeping the scope probe on the same pin, pin55. But 
>> no luck.
>>
>> I also tried the ADAFRUIT GPIO module in Python, yesterday, but it looks 
>> like there isn't yet a Python module which exposes all of the gpio chips 
>> for the BB-X15.  Please correct me if I'm wrong.
>>
>> Also, I have the following gpio fragment in my dts.
>>
>>  {
>> ti,no-reset-on-init;
>> ti,no-idle-on-init;
>> };
>>
>> Maybe a reasonable next-step is to find some known signals coming out on 
>> the expansion headers, and then reverse engineer how they're getting 
>> generated..  Maybe video signals or touchscreen input signals for the 
>> external touchscreen would be a good place to start
>>
>> Thanks!
>>
>
>  
>
>>
>> On Monday, December 4, 2017 at 5:49:59 PM UTC-6, Jeff Andich wrote:
>>>
>>> Hi,
>>>
>>> Has anyone had any difficulty outputting GPIO,UART, I2C, signals from 
>>> the BB-X15's expansion header?  I haven't yet been able to successfully get 
>>> GPIO and/or UART data to come out on the associated pins of the 4 expansion 
>>> ports of the am572xEVM/BB-X15.  We made a PCBA breakout board which breaks 
>>> out 30/60 signals on each header. 
>>>
>>> If you were able to get this working, what were some of the key 
>>> considerations?
>>>
>>> I stumbled across this post on TI E2E, where others were encountering 
>>> issues with this as well.
>>>
>>>
>>> https://e2e.ti.com/support/embedded/linux/f/354/p/595855/2206686#pi317016=1
>>>  
>>>
>>> Here I THINK the TI employee indicated that one of the critical steps is 
>>> specifying the correct offset in the device tree for the pad configuration 
>>> register of interest.  But when I look at the device tree, 
>>> am57xx-evm-reva3, and the associated included dtsi and dts files, I didn't 
>>> see this kind of thing for GPIO pins:
>>>
>>> gpio5_pins: pinmux_gpio5_pins {
>>> pinctrl-single,pins = <
>>> DRA7XX_CORE_IOPAD(0x, (PIN_INPUT | 
>>> MUX_MODEX))
>>> DRA7XX_CORE_IOPAD(0x, (PIN_OUTPUT| 
>>> MUX_MODE3))
>>> >;
>>> };
>>>
>>>
>>> in the case of attempting to set GPIO5_8, and using sysfs commands, echo 
>>> 1,0 > /sys/class/gpio/gpio136/value (after setting the direction to OUT), 
>>> the value and direction files always jive with what gets echo'd into the 
>>> file - however the state of the line doesn't change.
>>>
>>> I DO have a modified board.c file, but I'm pretty confident the pinmux 
>>> in mux_data.h for GPIO5_8 is the same as the development board.  Granted 
>>> this maybe an older revision, as I grabbed one of the earlier revisions of 
>>> u-boot 2017.01.
>>>  
>>> I even tried hacking,  am57xx-beagle-x15-common.dtsi by adding another 
>>> phantom LED fragment/cluster.
>>>
>>> .
>>> .
>>> .
>>> leds {
>>> .
>>> .
>>> .
>>>   led@4 {
>>> label = "gpio_jeff_test";
>>> gpios = < 8 GPIO_ACTIVE_HIGH>;
>>> linux,default-trigger = "ide-disk";
>>> default-state = "off";
>>> };
>>> };
>>>
>>> The good news is, the  gpio line is 3.3V with this statement.
>>> The bad news: When I change this to GPIO_ACTIVE_LOW, gpio5_8 is still 
>>> stuck at 3.3V..
>>>
>>>
>>> The only luck I've had to date is on our custom hardware board, coupling 
>>> GPIO5_8 with UART5 for the rts line, and then toggle the GPIO line via 
>>> sysfs commands and by toggling the state of the rtscts flag in Pyserial in 
>>> Python (This after swapping out the 8250 serial driver for the OMAP driver):
>>>

[beagleboard] Re: fsck fails to start on writable partition at boot/startup

[tarmo]

On Wednesday, December 6, 2017 at 10:40:11 PM UTC+2, Dave Barndt wrote:
>
> Does anything there look strange to you?
>

Can't say it does. Your /var/ file system is writable and gets corrupted - 
this is expected. fsck failing to run is unexpected. 

Looks like systemd has taken over the responsibility of boot-time fsck-ing. 
A look at the service which fails 
(/lib/systemd/system/systemd-fsck@.service) tells me that there is some 
scant documentation available in "man systemd-fsck". However, it looks like 
you might have to dig into systemd source to analyze how exactly boot-time 
fsck-s are triggered and what could go wrong there.

Alternatively, perhaps you'd want to have a quick glance at changelog for 
systemd, to see if they've fixed any bugs in this area since your installed 
version. My BBB with Debian 8 is running systemd version "230-7~bpo8+2" 
(dpkg -l systemd) and they've made 5 releases since.

--
Kind regards,
Tarmo Kuuse

-- 
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/09bb67af-fd7e-461d-abaa-242b8f225fb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PWM in Pocket Beagle Bone

[Rohit Karkala]

Hello All, 

I want to disable the PWM functionality of Pocket Beagle Bone and use it as 
GPIO.

How can i do this.

-- 
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/e36ae0cc-325c-42ac-9228-a07340fb04a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Where are VDD and SYS_RESETn?

[mike . maikaefer]

Nobody an idea? While searching through the board here I find two different 
opinions about VDD/where to apply external power to, so some clarification 
would be really nice...



On Saturday, December 2, 2017 at 6:22:47 PM UTC+1, mike.ma...@gmail.com 
wrote:
>
> Can somebody verify where the following pins/signals can be found at the 
> PocketBeagle (comparing to BeagleBone Black):
>
> - VDD (to supply externel power apart from USB)
> - SYS_RESETn (signalling SiP is in reset state and no inputs are allowed 
> to be pulled to LOW or HIGH)
>
> ?
>
> 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/a0eb2424-7702-4330-99a7-10ef05f5e3ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.