12:25 <OP> Hi all, developing a custom beagle bone board (based on OSD3358-512M-BSM) to make it fiber-ethernet ready. Most of my questions are already sorted out. What I'm currently fiddling with is the eMMC. Never had one in my designs. Question is what to consider when selecting it (there are tons with the distributors). Size, clock-rate, ... Special

12:25 <OP> (in)-compatibilities with the OSD3358...?

13:02 <zmatt> OP: mainly just size and price... there might also be variations in performance and/or reliability features (e.g. SMART-like monitoring)

13:04 <OP> Thanks zmatt. Took BeagleBoneBlack as reference and it has a 4GB Kingston which is not available. Is 4GB a sensible value then? 32 is common what I see and acceptable in price.

13:05 <zmatt> OP: that's up to you and your application... we only use about half a gig of space on our production devices

13:06 <OP> How much the operational system will use from the eMMC (a common debian)?

13:07 <zmatt> that doesn't have an answer, it's completely dependent on what you're going to install on it or use it for

13:07 <OP> Sure.

13:08 <OP> Not planing to store any data. Using network mounts here. It is basically the default debian running Python scripts. Nothing more.

13:09 <zmatt> even "default" depends on what image you use... the iot image needs a fair bit of space because it's crammed full of crap that may be of use to some users

13:12 <OP> OK. So just for OS and applications I should be safe with 32G I guess then. With our prototype we used a BBBlack with a debian image around 3GB in size when I recall correctly. Some apps installed already.

13:12 <zmatt> 32G sounds like an excessive amount of space, but if that's the cheapest you can find then sure

13:15 <OP> Kay, thanks!

13:15 <OP> Regarding the power supply. I see the OSD3358-512M-BSM can be operated by a supply as low as 3.7V. Unfortunately not lower (3.3V) right?

14:07 <zmatt> OP: tps65217 recommends a supply of 4.3-5.8V, if you're going to use USB it should be 4.75-5.25V (i.e. 5V ±5%)

14:12 <zmatt> unless you mean VIN_BAT, which is for a li-ion/lipo cell specifically (not just any random power supply)

14:12 <zmatt> and 3.7V is not its minimum... I'm not sure what the minimum is, at some point the 3.3V supplies will start to lose regulation

14:14 <zmatt> if you do intend to run from a battery, beware that it comes with a bunch of caveats (e.g. the SYS_VDD1_3P3V of the OSD3358-SM should not be used in that case)

14:15 <OP> I was referring to the VIN_BAT pin. We did some experiments with that pin. I remember the chip needed AC/USB power to boot but could later be switched to the BAT power. Guess we will need to go with AC/USB then.

14:16 <OP> Could not get it working properly.

14:16 <zmatt> it doesn't need AC/USB to boot, but you do need to press the power button to power on if on BAT only

14:18 <zmatt> and if both BAT and AC/USB are present it will try to charge the battery via BAT

14:18 <OP> It needed a edge there, you are right!

14:18 <OP> It needed an edge there, you are right!

14:18 <OP> This would have need to be emulated then (so the button press).

14:20 <zmatt> also beware that BAT remains connected to SYS_5V even while the device is powered off

14:20 <OP> Yes, thanks!

14:20 <zmatt> and again, do not use SYS_VDD1_3P3V for anything if you're using BAT

14:20 <zmatt> and of course USB will not work and should be disabled in DT

14:21 <zmatt> (USB host port I mean)

15:01 <OP> With the power manager on the BBBlack there was another issue. It's default settings (which could not be changed) was to have a lower voltage threshold of something around 3.5V (on the VIN_BAT). This setting could be change during runtime but would fall back on a power cycle (volatile).

15:09 <OP> Thats why we could not boot it with 3.3V on VIN_BAT.

16:29 <zmatt> 3.3V on VBAT would also result in the 3.3V supplies being out of regulation, resulting in potential stability issues

16:30 <zmatt> you're not going to get 3.3V out of an LDO when you supply it with 3.3V on its input

16:31 <zmatt> it'll just turn into a resistor, resulting in voltage fluctuations as the current draw varies

23:20 <set_> -Wall is a miracle w/ the BBB!

23:20 <set_> I was having a set_ moment. Luckily, www.

23:22 <set_> Hey, I think you guys handled the pwm functionality in a file somewhere on the BBB. I say this b/c I see the polarity and enable is already located on the BBB in /dev/pwm/ but the sysfs files are there too, e.g. w/out me making the files available.

23:23 <set_> I never gave up on making PWM work. For instance, I know it works. It does. But...in .c files along w/ a .h or many .c files, it takes some research.

23:23 <set_> I think...blah.

23:24 <set_> I mean...blah. Did someone already make the pwm functionality available on the BBB w/ kernel 4.19.x and 5.10.x so people do not bug you all about it?

23:25 <set_> I ask b/c it is way more interesting than once thought... at first, it was a hassle. Now, it is totally awesome!

23:26 <set_> See. i have a dislocated mindset here, i.e. as I do/did not know of this fact being real. I just thought it was a given. NOt so!

23:31 <set_> sometimes w/ the sysfs interface, things need to be allocated to it in userspace or even beforehand like w/ the images available.

23:34 <set_> Hello?

23:49 <set_> It is me...