<Guest86>
Hi, I have a question, I can not order beaglebone ai-64, because all sellers tell me that this board was discontinued, what's the reason of discontinuing?
<zmatt>
Guest86: uhh, it's not? the ai-64 is brand new
<zmatt>
Guest86: did you mean the original beaglebone ai ?
<Guest86>
No, ai-64
<zmatt>
farnell says they expect to have 800 more units in stock in two months
<zmatt>
okdo says they're in stock
<zmatt>
can't check mouser since they still seem to be struggling with paperwork or something
<zmatt>
anyway, the ai-64 is brand new and definitely not discontinued... if some seller told you otherwise then either they misunderstood your query or you misunderstood their response
demirok has quit [Quit: Leaving.]
Guest86 has quit [Ping timeout: 252 seconds]
ikarso has joined #beagle
samael has joined #beagle
zmatt has quit [Ping timeout: 252 seconds]
florian has joined #beagle
starblue1 has quit [Ping timeout: 245 seconds]
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #beagle
demirok has joined #beagle
frostsnow has quit [Ping timeout: 276 seconds]
zmatt has joined #beagle
frostsnow has joined #beagle
johanhenselmans has quit [Quit: johanhenselmans]
indigaz0 has joined #beagle
indigaz has quit [Ping timeout: 245 seconds]
indigaz0 is now known as indigaz
johanhenselmans has joined #beagle
Shadyman has quit [Remote host closed the connection]
Guest92 has joined #beagle
johanhenselmans has quit [Quit: johanhenselmans]
<Guest92>
Hi is there any solution for GLBC 2.32 not found issue for AM3358 BBB
frostsnow has quit [Ping timeout: 245 seconds]
<zmatt>
Guest92: that's not really a BBB-specific question... that just means you're trying to run a program that was compiled against glibc 2.32 on a system that has an older version of glibc
<zmatt>
the solution is to either compile the program against the glibc version actually present on the target system (ditto for any other libraries it needs), or if that's not an option then you'd need to upgrade the system... however, debian bullseye (the current testing image) uses glibc 2.31, so that would still not be recent enough
<zmatt>
debian 12 (bookworm) has 2.33, however this debian version has no stable release yet, nor any prebuilt image for the bbb as far as I know, so you'd need to install a minimal bullseye image and then manually upgrade to bookwork and hope nothing breaks
<zmatt>
so solution number 1 is still: compile the program against the correct glibc version (which would happen automatically if it's compiled on the bbb itself or any other arm-based board running the same debian release)
<zmatt>
a final workaround would be to containerize the program bundled together with whatever libraries it needs
<zmatt>
depending on the exact situation (e.g. what kind of program it is, what things it needs to access on the system, etc) this can be fairly easy or quite difficult
<zmatt>
Guest92: what are you trying to run that needs glibc 2.32 ?
Guest92 has quit [Quit: Client closed]
frostsnow has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
johanhenselmans has joined #beagle
johanhenselmans has quit [Client Quit]
<zmatt>
ok bye I guess
alan_o has quit [Quit: Leaving]
alan_o has joined #beagle
johanhenselmans has joined #beagle
florian has quit [Quit: Ex-Chat]
lucascastro has quit [Quit: Leaving]
lucascastro has joined #beagle
<jfsimon1981>
Hello,
<jfsimon1981>
Should I need to tune the u-boot configuration (to tune the eMMC settings), do you know where the u-boot configuration file is ?
<jfsimon1981>
I can see the /boot/uboot empty
<lucascastro>
/boot/uEnv.txt
<jfsimon1981>
I think we can pass parameters to u-boot through /boot/uEnv.txt is that right
<jfsimon1981>
yes thanks
<lucascastro>
depends on build patches
<lucascastro>
you set the parameters in it .
<lucascastro>
it's not an executable file.
<jfsimon1981>
All right
<jfsimon1981>
i think it's "cmdline= ..."
<jfsimon1981>
Thanks i'll dive in to it
<lucascastro>
depends on u-boot building you're using.
<jfsimon1981>
We're going to enable the eMMC reliability setting if possible (WR_REL_SET) through u-boot configuration.
<lucascastro>
idk about that
<jfsimon1981>
Another question, has some of you experienced with long term operation and MMC reliability over time, say 5 to 8 years operation ?
<jfsimon1981>
I think it has wear leveling although has someone run it for continuous for a long period ?
<jfsimon1981>
The one on test bench run continuously for about 9 months now, no problem, though, for few years that could be different.
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
akaWolf has quit [Ping timeout: 245 seconds]
akaWolf has joined #beagle
vagrantc has joined #beagle
<jfsimon1981>
Manufacturers won't say much, except they have wear levelling. Those info aren't show in the datashete. It's secret.
<jfsimon1981>
Not good.
buzzmarshall has joined #beagle
<zmatt>
jfsimon1981: "enable the eMMC reliability setting .. through u-boot configuration"
<zmatt>
why through u-boot
<zmatt>
?
<jfsimon1981>
just one minute i'll be back
<zmatt>
we configure the eMMC into SLC mode (1 bit/cell instead of 2 bits/cell) with reliable writes enabled, just to make the eMMC as robust as possible
<zmatt>
SLC mode sacrifices 50% capacity but we only use a few hundred MB anyway so that doesn't matter for us
<zmatt>
but since all of these eMMC settings are one-time-programmable and kinda fiddly and error-prone (which is not a great combination), what I did was add a custom command to mmc-utils that performs a bunch of sanity-checking and then performs all of the required OTP config writes in one sequence: https://github.com/dutchanddutch/mmc-utils/commit/d550d3e2edaa4518af99ffdc101a32e93c5d37a5
<zmatt>
I don't exclude the possibility you can do this in u-boot also, but that just seems like a much less comfortable environment to do so
<jfsimon1981>
zmatt
<jfsimon1981>
Unsure,
<jfsimon1981>
Though the eMMC controller datasheet has a note about 1 time thing which made me think this needs be configured at boot.
<jfsimon1981>
(4) Can be set to 1Fh to enable reliability settings. This byte is one-time programmable.
<jfsimon1981>
I think you got me
<zmatt>
beware that the eMMC specs are quite obtuse and hard to read
<jfsimon1981>
that's what i was looking for as well.
lucascastro has quit [Ping timeout: 272 seconds]
<jfsimon1981>
Not sure that's exactly the same configuration bit.
<jfsimon1981>
Do you use the BB eMMC as SLC 2Gb only as you mentionned ?
<jfsimon1981>
That sounds intersting indeed
<jfsimon1981>
Would need to tighten the space to do that, to get as much below 2G as possible.
<zmatt>
I'm pretty sure that bit is part of a cluster of settings that need to be jointly configured once, and like my commit message says requires eMMC to be power-cycled and also wipes it
<jfsimon1981>
indeed it looks like
<zmatt>
so you need to do this while booted from sd card anyway, not while booted from eMMC obviously
<jfsimon1981>
So i'd need to reflash it
<zmatt>
yeah we do this as step 1 of flashing our boards
<jfsimon1981>
yes ok
<jfsimon1981>
Do you do that as standard ?
<jfsimon1981>
So you do 2 steps, go into SLC and activate the write reliability switch as i understand.
<zmatt>
there
<zmatt>
there's a bunch of settings that are part of the "partitioning process" of the eMMC, which can be used to configure the storage to appear as one or more (iirc up to 5) block devices with configurable size and settings (e.g. write-reliability)
<zmatt>
all of those settings are configured at the same time, and you get only one chance... then as the final step a PARTITION_SETTING_COMPLETED bit is set and upon power-cycling the eMMC it will erase itself and reconfigure into the programmed configuration
<zmatt>
so, for example you can try out reliable-writes and then later enable SLC mode or vice versa
<jfsimon1981>
Ok
<zmatt>
you need to make all choices at the same time
<zmatt>
and if you don't like your choices, well too bad since it's all one-time-programmable settings :D
<jfsimon1981>
Do you have bad experiences with mmc reliability ?
<jfsimon1981>
indeed i need to go safe side though
<jfsimon1981>
Thnks for the tips
<zmatt>
not really no... we did manage to wear-out an eMMC but that was a development system (without these reliability-settings) and due to a bug that caused gigabytes of data per HOUR to be written to eMMC
<jfsimon1981>
indeed
<zmatt>
I think I've seen a few more dead eMMCs over the years but not many, and we have quite a decent number of products out in the field (which are turned on and off by users, no clean shutdown!)
<jfsimon1981>
oh i was ashame to tell you
<jfsimon1981>
Cause mine probably get shut down that way too.
<jfsimon1981>
Except if implement a mini UPS with auto shutdown.
<jfsimon1981>
And ship it along.
<zmatt>
MLC flash is known to dislike power failures, so that's another reason we switched to SLC mode
<jfsimon1981>
All right
<zmatt>
we also try to minimize unnecessary eMMC writes of course
<jfsimon1981>
i don't but that's something i can sort.
<jfsimon1981>
It logs way too much at the moment.
<zmatt>
oh we don't log to eMMC at all
<zmatt>
we have a way to stream logs to the cloud if needed
<zmatt>
(from journal)
<jfsimon1981>
ok that won't be the case here, although i didn't know cout << would be logged if run from systemd
<zmatt>
log output from systemd services by default goes to journal
<jfsimon1981>
Hence i have very detailed log since the code had many console output still in, which was there while developping.
<jfsimon1981>
Yes
<zmatt>
which can be either persistent (if /var/log/journal/ exists) or kept in ram only (if that dir doesn't exist)
<jfsimon1981>
So you configure that globally i think
<zmatt>
we obviously keep in ram only
<jfsimon1981>
ok
<zmatt>
not sure what you mean by "that", but tons of things are configurable both globally and per-service
<jfsimon1981>
according to the client, i probably have between 150 to more than 200 devices per year in the field
<jfsimon1981>
Like 20 until the end of this year then probably a lot if things go right.
<jfsimon1981>
Issues can arise say in 5 years or so. I get the default configuration hardenehardened.
<zmatt>
for logging to yournal you can use the functions provided by libsystemd to log at various priority levels (so you can easily filter debug crap), and include extra metadata in the journal entries... by default it'll also embed the original source file and line
<zmatt>
(man sd_journal_print )
<jfsimon1981>
I understand we can activate "write reliability" from user space with mmc-utils
<jfsimon1981>
I tries to install from package yesterday, it's not available.
<jfsimon1981>
That means we can turn on the flag while the system is in use, strange why the datasheet mentions something about one time configuration.
<jfsimon1981>
(I meant systemd logs)
<zmatt>
jfsimon1981: ehh, like I said you should obviously not try to reconfigure eMMC while booted from eMMC
<zmatt>
there's definitely a debian package for mmc-utils, though obviously if you want to use my custom command you'll need to build my git branch from source
<zmatt>
mmc-utils is tiny and compiles easily iirc
<zmatt>
if you don't want SLC mode then some steps in my custom command would need to be removed or commented-out
<jfsimon1981>
ok
<jfsimon1981>
you run 2 Gb of space with the 4 GB unit right ?
<jfsimon1981>
All quite clear i think a bit of work and i shall give it a start SLC and reliability. switch on.
<zmatt>
yeah, SLC mode simply means you lose 50% space (since each NAND flash cell will now only be used to store 1 bit instead of 2 bits)
<jfsimon1981>
Didn't you consider a hardware safe shutdown ?
<zmatt>
considered? sure. but it did not seem feasible, and it doesn't appear to be necessary... at least with our choice of eMMC settings and our usage pattern
<jfsimon1981>
On my side the PCB design is already ready, i still could change it though i have to put another battery in. Can be done, i think very little power needed just for halt.
<jfsimon1981>
Ok
<zmatt>
we looked into that idea but it's much trickier than you think, and if you embed a li-ion battery into your product you may also run into shipping issues
<jfsimon1981>
indeed and temperature.
<jfsimon1981>
Indeed it's not that easy, i thought about it quickly, that's also why i may not go into it.
<zmatt>
looks like we use about 300M for the system and about 85M or so for our custom software, so most of eMMC is free space for us
<jfsimon1981>
Dual supply with diode voltage loss may not be possible, it would need to some work.
<jfsimon1981>
really
<jfsimon1981>
Sounds good
<zmatt>
I mean, I think it's rather bulky but given that we have plenty of space there's not much reason to further trim the system
<jfsimon1981>
Clients took my prototype and got it broke many ways. I'm not too sure what the serie one will have to handle.
<jfsimon1981>
If that's rock solid it sustain a chance.
<jfsimon1981>
They told me they installed some devices by transformer side at 85°C, and it melted it away. I have instructed +50°C max for this one.
<zmatt>
lol
<jfsimon1981>
I calculated a bit, that's working to 64°C ambiant there about, no electrolyte cap, but i'll get the client spec lower, 50 C good enough.
<jfsimon1981>
Power supply and relays don't like by 70C and more, or can't do at all.
<zmatt>
we once had a case where prototype speakers had been run at such an excessively loud volume for a whole evening that apparently the heat of the voice coil caused the permanent magnet in one of the speakers to get demagnetized
<jfsimon1981>
Ok i will try to burn a BB with those settings, that should do.
samael has quit [Ping timeout: 268 seconds]
<zmatt>
I hope I don't need to say it again but just in case: remember this is _one time programmable_ ! there's no "undo" !
<jfsimon1981>
Design and client ming is different really.
<jfsimon1981>
yes i got it
<jfsimon1981>
I mean I'll reflash them, need to figure out the process and good to go.
<jfsimon1981>
If they have issues i'll propose a mini ups with an extra cost.
<zmatt>
I honestly don't understand _why_ it's one-time-programmable though, I have trouble believing that the eMMC can reconfigure itself once (even after having first been used to store data) yet not a second time
<zmatt>
but, well, it's how it's in the eMMC spec
<jfsimon1981>
They got me constrained on price because we worked with the Aruino price tag in the begining, and now we have an external RTC, a BBB red industry, a 4x20 LCD and more. Can't keep te price, customer cut a bit from what i intended.
<jfsimon1981>
Maybe something as simple as statc eeprom programming
<jfsimon1981>
Which can be donc altogether at initial and won't give an option later. Can't say for sure.
<zmatt>
it obviously uses flash to store settings... that's what eMMC is, a giant flash memory with a controller in front of it :P
<zmatt>
and like I said, the "initial" configuration is already a *re*configuration, i.e. from one operational configuration to another
<zmatt>
I see no reason it can't just do exactly that a second time... obviously requiring a complete wipe but that's fine
<jfsimon1981>
You don't think that a controller issue, which isn't the flash itself
<jfsimon1981>
Don't know the internal design
<zmatt>
it's just how the controller software is written
<zmatt>
which itself is of course just the way it is because that's how the eMMC spec is written
<jfsimon1981>
The write reliability would affect how the controller handles it, the flash and the controller are not the same device
<zmatt>
though I think "written" is perhaps too nice a word for the eMMC spec... "haphazardly cobbled together" would be a better choice of words :P
<jfsimon1981>
They use Kingston for the flash and Micron for controler i think, from the part list, as i could find
<jfsimon1981>
Gosh hope not
<zmatt>
no, the controller and flash aren't separate parts, they're one chip
<jfsimon1981>
They break the insulation to store data, that's about how to do it
lucascastro has joined #beagle
<jfsimon1981>
Yes
<jfsimon1981>
i mean the controller and the flash are separate things in the same chip, it's possible the controller does'nt use the flash for its parameters storage
<zmatt>
and yes, all these "OTP" settings are just settings that affect how the controller firmware behaves
<zmatt>
possible but highly unlikely
<jfsimon1981>
yes maybe not
<jfsimon1981>
cause of my microchip background
<jfsimon1981>
I get to deliver 1 unit in august, will need make that one right
<zmatt>
the controller already needs to store lots of stuff, not all settings are one-time-programmable there are also plenty of settings you can change repeatedly, and of course lots of metadata and internal bookkeeping
<zmatt>
ok, good luck? :D
<jfsimon1981>
yes although we're accustommed these things take megs, which they might not require, bytes of kb could the unit
<jfsimon1981>
I have 20+ units, new deliveries will wait for months possibly
<jfsimon1981>
never seen before
<zmatt>
bb industrial is for low-temperature support I think?
<zmatt>
like, below freezing
<jfsimon1981>
At least the external package looks nice
<jfsimon1981>
What's inside looks a bit messy, unless we understand it
<jfsimon1981>
Yes below freezing
<jfsimon1981>
High temp is not needed, since there are components going away from 70°C already, appart from the BB
<zmatt>
well, you try to stick your entire design into the space of a microsd card ;)
<jfsimon1981>
But -20°C or so it needs
<jfsimon1981>
Except i like Unix design
<jfsimon1981>
If you make it a bit modular, can do various things without re design the whole thing
<jfsimon1981>
I reflect that in code, C/C++ i do are interfaced to be modular as much as i can too.
<jfsimon1981>
BB blank can't do the negative temp right ?
<jfsimon1981>
black
<zmatt>
nice idea, but doesn't always work... for example, "managed nand" such as eMMC can actually be cheaper than the raw nand flash embedded inside it. the reason is that the controller is smart enough to be able to deal with defects in the nand flash, which means that they can stick nand in there that wouldn't really be tolerated as a discrete product
<zmatt>
and the controller is made by people who really deeply understand the flash and how it behaves
<zmatt>
so, it's not a nice clean modular interface between the two... the flash depends on the controller to deal with its defects, and the controller embeds deep knowledge of the flash
<jfsimon1981>
yes although what i meant, they surely have modular things at the die level in that case
<jfsimon1981>
In this world, it's maybe not so hard to re-arrange and build the die, i don't know too much about this
<jfsimon1981>
But from the picture xray it's not too clear
<jfsimon1981>
Things get inctricated a lot so that changes here affect somethings else far away often however hard we'd try not
<zmatt>
visual neatness is of no benefit to the final product
<zmatt>
the pads on the dies are whereever they happened to be convenient in the design, and it all needs to be wired up in extremely little space
<zmatt>
there can also be good reasons for curvy lines, for signal integrity
<jfsimon1981>
although for the design i work now it needs be clean inside, the client wants to check and approve the product
<jfsimon1981>
(to a certain point)
<zmatt>
well, people typically don't see the inside of a microsd card ;)
<jfsimon1981>
it seems the second one has much tighter dimensions in the tracks
<jfsimon1981>
That could allow a more clean design
<jfsimon1981>
Things explaine
<jfsimon1981>
d
<zmatt>
anyway, I have things to do, and I think so do you ;)
<jfsimon1981>
yep
<jfsimon1981>
thx for all
<jfsimon1981>
will do my homework then
lucascastro has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
<vvn>
hi all -- Can a device tree create a device symlink?
<jfsimon1981>
I think ln -s
<jfsimon1981>
for a symbolic link, doesn't work ?
<lucascastro>
vvn: I don't think DT create anything at all. The device "read it" and then create what's needed.
<vvn>
lucascastro: yeah I suppose... It would have been convenient to described fixed symlinks from the device tree such as /dev/sdcard, but I can understand that this is out of scope
<lucascastro>
Idk, and I'm not expect on that.
lucas_ has joined #beagle
lucas_ has quit [Remote host closed the connection]
lucas_ has joined #beagle
<lucas_>
weird situation.
lucascastro has quit [Read error: Connection reset by peer]
<lucas_>
I guess
lucas_ is now known as lucascastro
lucascastro has quit [Read error: Connection reset by peer]
<zmatt>
vvn: assuming you're using a not-ancient beagleboard.org debian system, adding a symlink = "foo/bar"; property to the DT node will create a /dev/foo/bar symlimk
<zmatt>
*symlink
<zmatt>
that won't work for the sd card since it has no representation in DT
<zmatt>
but the sd card is always /dev/mmcblk0
<zmatt>
vvn: this "symlink" property is not a kernel thing, it's the result of an udev rule, /etc/udev/rules.d/10-of-symlink.rules
<zmatt>
this only works for actual devices that create a device node in /dev/ ... for other things there are other solutions, e.g. I use https://pastebin.com/MMC6u7pR to create named symlinks in /dev/gpio/ for sysfs gpio (https://pastebin.com/raw/R5pP0jSQ)
lucascastro has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
PhotoJim has quit [Remote host closed the connection]
PhotoJim has joined #beagle
lucascastro has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
lucascastro has joined #beagle
starblue has joined #beagle
lucascastro has quit [Ping timeout: 260 seconds]
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 260 seconds]
starblue has quit [Ping timeout: 245 seconds]
lucascastro has joined #beagle
starblue has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
Guest23 has joined #beagle
Guest23 has quit [Client Quit]
starblue has quit [Ping timeout: 245 seconds]
Shadyman has joined #beagle
samael has quit [Ping timeout: 252 seconds]
zjason` has quit [Read error: Connection reset by peer]
zjason` has joined #beagle
GenTooMan has quit [Ping timeout: 268 seconds]
GenTooMan has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]