**** BEGIN LOGGING AT Thu Jul 28 02:59:57 2022
Jul 28 06:21:37 <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?
Jul 28 06:32:51 <zmatt> Guest86: uhh, it's not?  the ai-64 is brand new
Jul 28 06:34:32 <zmatt> Guest86: did you mean the original beaglebone ai ?
Jul 28 06:34:55 <Guest86> No, ai-64
Jul 28 06:36:54 <zmatt> farnell says they expect to have 800 more units in stock in two months
Jul 28 06:37:15 <zmatt> okdo says they're in stock
Jul 28 06:38:03 <zmatt> can't check mouser since they still seem to be struggling with paperwork or something
Jul 28 06:39:50 <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
Jul 28 10:36:48 <Guest92> Hi is there any solution for GLBC 2.32 not found  issue for AM3358 BBB
Jul 28 11:25:23 <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
Jul 28 11:27:19 <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
Jul 28 11:30:08 <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
Jul 28 11:31:35 <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)
Jul 28 11:33:09 <zmatt> a final workaround would be to containerize the program bundled together with whatever libraries it needs
Jul 28 11:35:56 <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
Jul 28 11:54:08 <zmatt> Guest92: what are you trying to run that needs glibc 2.32 ?
Jul 28 13:04:52 <zmatt> ok bye I guess
Jul 28 15:07:34 <jfsimon1981> Hello,
Jul 28 15:08:24 <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 ?
Jul 28 15:08:38 <jfsimon1981> I can see the /boot/uboot empty
Jul 28 15:09:29 <lucascastro>  /boot/uEnv.txt
Jul 28 15:09:34 <jfsimon1981> I think we can pass parameters to u-boot through /boot/uEnv.txt is that right
Jul 28 15:09:37 <jfsimon1981> yes thanks
Jul 28 15:09:42 <lucascastro> depends on build patches
Jul 28 15:10:18 <lucascastro> you set the parameters in it .
Jul 28 15:10:28 <lucascastro> it's not an executable file.
Jul 28 15:10:46 <jfsimon1981> All right
Jul 28 15:11:10 <jfsimon1981> i think it's "cmdline= ..."
Jul 28 15:11:58 <jfsimon1981> Thanks i'll dive in to it
Jul 28 15:21:13 <lucascastro> depends on u-boot building you're using.
Jul 28 15:21:17 <jfsimon1981> We're going to enable the eMMC reliability setting if possible (WR_REL_SET) through u-boot configuration.
Jul 28 15:21:30 <lucascastro> idk about that
Jul 28 15:21:51 <jfsimon1981> Another question, has some of you experienced with long term operation and MMC reliability over time, say 5 to 8 years operation ?
Jul 28 15:22:34 <jfsimon1981> I think it has wear leveling although has someone run it for continuous for a long period ?
Jul 28 15:23:27 <jfsimon1981> The one on test bench run continuously for about 9 months now, no problem, though, for few years that could be different.
Jul 28 15:48:10 <jfsimon1981> Manufacturers won't say much, except they have wear levelling. Those info aren't show in the datashete. It's secret.
Jul 28 15:48:15 <jfsimon1981> Not good.
Jul 28 15:54:50 <zmatt> jfsimon1981: "enable the eMMC reliability setting .. through u-boot configuration"
Jul 28 15:54:54 <zmatt> why through u-boot
Jul 28 15:54:55 <zmatt> ?
Jul 28 15:55:13 <jfsimon1981> just one minute i'll be back
Jul 28 15:57:11 <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
Jul 28 15:57:33 <zmatt> SLC mode sacrifices 50% capacity but we only use a few hundred MB anyway so that doesn't matter for us
Jul 28 15:59:09 <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
Jul 28 16:00:07 <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
Jul 28 16:00:58 <jfsimon1981> zmatt
Jul 28 16:01:01 <jfsimon1981> Unsure,
Jul 28 16:01:40 <jfsimon1981> Though the eMMC controller datasheet has a note about 1 time thing which made me think this needs be configured at boot.
Jul 28 16:02:10 <jfsimon1981> Write reliability setting register (note 3)
Jul 28 16:02:36 <jfsimon1981> Default value 0x00 (note 4)
Jul 28 16:02:42 <jfsimon1981> (4) Can be set to 1Fh to enable reliability settings. This byte is one-time programmable.
Jul 28 16:02:59 <jfsimon1981> I think you got me
Jul 28 16:03:03 <zmatt> beware that the eMMC specs are quite obtuse and hard to read
Jul 28 16:03:10 <jfsimon1981> that's what i was looking for as well.
Jul 28 16:04:41 <jfsimon1981> Not sure that's exactly the same configuration bit.
Jul 28 16:05:08 <jfsimon1981> Do you use the BB eMMC as SLC 2Gb only as you mentionned ?
Jul 28 16:05:50 <jfsimon1981> That sounds intersting indeed
Jul 28 16:06:40 <jfsimon1981> Would need to tighten the space to do that, to get as much below 2G as possible.
Jul 28 16:07:07 <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
Jul 28 16:07:21 <jfsimon1981> indeed it looks like
Jul 28 16:07:40 <zmatt> so you need to do this while booted from sd card anyway, not while booted from eMMC obviously
Jul 28 16:07:41 <jfsimon1981> So i'd need to reflash it
Jul 28 16:07:50 <zmatt> yeah we do this as step 1 of flashing our boards
Jul 28 16:07:52 <jfsimon1981> yes ok
Jul 28 16:07:58 <jfsimon1981> Do you do that as standard ?
Jul 28 16:08:29 <jfsimon1981> So you do 2 steps, go into SLC and activate the write reliability switch as i understand.
Jul 28 16:08:36 <zmatt> there
Jul 28 16:09:38 <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)
Jul 28 16:10:37 <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
Jul 28 16:10:59 <zmatt> so, for example you can try out reliable-writes and then later enable SLC mode or vice versa
Jul 28 16:10:59 <jfsimon1981> Ok
Jul 28 16:11:09 <zmatt> you need to make all choices at the same time
Jul 28 16:11:31 <zmatt> and if you don't like your choices, well too bad since it's all one-time-programmable settings :D
Jul 28 16:11:31 <jfsimon1981> Do you have bad experiences with mmc reliability ?
Jul 28 16:11:57 <jfsimon1981> indeed i need to go safe side though
Jul 28 16:12:14 <jfsimon1981> Thnks for the tips
Jul 28 16:12:36 <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
Jul 28 16:13:29 <jfsimon1981> indeed
Jul 28 16:14:31 <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!)
Jul 28 16:17:00 <jfsimon1981> oh i was ashame to tell you
Jul 28 16:17:12 <jfsimon1981> Cause mine probably get shut down that way too.
Jul 28 16:17:35 <jfsimon1981> Except if implement a mini UPS with auto shutdown.
Jul 28 16:17:42 <jfsimon1981> And ship it along.
Jul 28 16:17:44 <zmatt> MLC flash is known to dislike power failures, so that's another reason we switched to SLC mode
Jul 28 16:17:55 <jfsimon1981> All right
Jul 28 16:17:59 <zmatt> we also try to minimize unnecessary eMMC writes of course
Jul 28 16:18:17 <jfsimon1981> i don't but that's something i can sort.
Jul 28 16:18:33 <jfsimon1981> It logs way too much at the moment.
Jul 28 16:18:42 <zmatt> oh we don't log to eMMC at all
Jul 28 16:19:21 <zmatt> we have a way to stream logs to the cloud if needed
Jul 28 16:19:34 <zmatt> (from journal)
Jul 28 16:20:34 <jfsimon1981> ok that won't be the case here, although i didn't know cout << would be logged if run from systemd
Jul 28 16:20:55 <zmatt> log output from systemd services by default goes to journal
Jul 28 16:21:04 <jfsimon1981> Hence i have very detailed log since the code had many console output still in, which was there while developping.
Jul 28 16:21:09 <jfsimon1981> Yes
Jul 28 16:21:27 <zmatt> which can be either persistent (if /var/log/journal/ exists) or kept in ram only (if that dir doesn't exist)
Jul 28 16:21:37 <jfsimon1981> So you configure that globally i think
Jul 28 16:21:40 <zmatt> we obviously keep in ram only
Jul 28 16:21:46 <jfsimon1981> ok
Jul 28 16:22:09 <zmatt> not sure what you mean by "that", but tons of things are configurable both globally and per-service
Jul 28 16:22:27 <jfsimon1981> according to the client, i probably have between 150 to more than 200 devices per year in the field
Jul 28 16:22:52 <jfsimon1981> Like 20 until the end of this year then probably a lot if things go right.
Jul 28 16:23:53 <jfsimon1981> Issues can arise say in 5 years or so. I get the default configuration hardenehardened.
Jul 28 16:24:35 <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
Jul 28 16:24:54 <zmatt> (man sd_journal_print )
Jul 28 16:26:15 <jfsimon1981> I understand we can activate "write reliability" from user space with mmc-utils
Jul 28 16:26:36 <jfsimon1981> I tries to install from package yesterday, it's not available.
Jul 28 16:27:02 <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.
Jul 28 16:27:20 <jfsimon1981> (I meant systemd logs)
Jul 28 16:28:22 <zmatt> jfsimon1981: ehh, like I said you should obviously not try to reconfigure eMMC while booted from eMMC
Jul 28 16:29:20 <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
Jul 28 16:29:35 <zmatt> mmc-utils is tiny and compiles easily iirc
Jul 28 16:30:29 <zmatt> if you don't want SLC mode then some steps in my custom command would need to be removed or commented-out
Jul 28 16:30:30 <jfsimon1981> ok
Jul 28 16:31:05 <jfsimon1981> you run 2 Gb of space with the 4 GB unit right ?
Jul 28 16:31:51 <jfsimon1981> All quite clear i think a bit of work and i shall give it a start SLC and reliability. switch on.
Jul 28 16:32:03 <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)
Jul 28 16:32:33 <jfsimon1981> Didn't you consider a hardware safe shutdown ?
Jul 28 16:33:22 <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
Jul 28 16:33:35 <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.
Jul 28 16:33:44 <jfsimon1981> Ok
Jul 28 16:34:20 <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
Jul 28 16:34:36 <jfsimon1981> indeed and temperature.
Jul 28 16:35:44 <jfsimon1981> Indeed it's not that easy, i thought about it quickly, that's also why i may not go into it.
Jul 28 16:36:21 <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
Jul 28 16:36:22 <jfsimon1981> Dual supply with diode voltage loss may not be possible, it would need to some work.
Jul 28 16:36:35 <jfsimon1981> really
Jul 28 16:36:41 <jfsimon1981> Sounds good
Jul 28 16:37:47 <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
Jul 28 16:37:51 <jfsimon1981> Clients took my prototype and got it broke many ways. I'm not too sure what the serie one will have to handle.
Jul 28 16:38:07 <jfsimon1981> If that's rock solid it sustain a chance.
Jul 28 16:38:55 <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.
Jul 28 16:39:03 <zmatt> lol
Jul 28 16:39:56 <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.
Jul 28 16:40:33 <jfsimon1981> Power supply and relays don't like by 70C and more, or can't do at all.
Jul 28 16:40:51 <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
Jul 28 16:41:14 <jfsimon1981> Ok i will try to burn a BB with those settings, that should do.
Jul 28 16:41:50 <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" !
Jul 28 16:41:53 <jfsimon1981> Design and client ming is different really.
Jul 28 16:42:04 <jfsimon1981> yes i got it
Jul 28 16:42:29 <jfsimon1981> I mean I'll reflash them, need to figure out the process and good to go.
Jul 28 16:42:51 <jfsimon1981> If they have issues i'll propose a mini ups with an extra cost.
Jul 28 16:43:07 <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
Jul 28 16:43:39 <zmatt> but, well, it's how it's in the eMMC spec
Jul 28 16:44:18 <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.
Jul 28 16:44:55 <jfsimon1981> Maybe something as simple as statc eeprom programming
Jul 28 16:45:37 <jfsimon1981> Which can be donc altogether at initial and won't give an option later. Can't say for sure.
Jul 28 16:46:25 <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
Jul 28 16:47:00 <zmatt> and like I said, the "initial" configuration is already a *re*configuration, i.e. from one operational configuration to another
Jul 28 16:47:26 <zmatt> I see no reason it can't just do exactly that a second time... obviously requiring a complete wipe but that's fine
Jul 28 16:47:54 <jfsimon1981> You don't think that a controller issue, which isn't the flash itself
Jul 28 16:47:59 <jfsimon1981> Don't know the internal design
Jul 28 16:48:12 <zmatt> it's just how the controller software is written
Jul 28 16:48:30 <zmatt> which itself is of course just the way it is because that's how the eMMC spec is written
Jul 28 16:48:54 <jfsimon1981> The write reliability would affect how the controller handles it, the flash and the controller are not the same device
Jul 28 16:49:18 <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
Jul 28 16:49:34 <jfsimon1981> They use Kingston for the flash and Micron for controler i think, from the part list, as i could find
Jul 28 16:49:56 <jfsimon1981> Gosh hope not
Jul 28 16:49:59 <zmatt> no, the controller and flash aren't separate parts, they're one chip
Jul 28 16:50:20 <jfsimon1981> They break the insulation to store data, that's about how to do it
Jul 28 16:50:32 <jfsimon1981> Yes
Jul 28 16:51:08 <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
Jul 28 16:51:09 <zmatt> and yes, all these "OTP" settings are just settings that affect how the controller firmware behaves
Jul 28 16:51:17 <zmatt> possible but highly unlikely
Jul 28 16:51:30 <jfsimon1981> yes maybe not
Jul 28 16:51:44 <jfsimon1981> cause of my microchip background
Jul 28 16:52:15 <jfsimon1981> I get to deliver 1 unit in august, will need make that one right
Jul 28 16:52:29 <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
Jul 28 16:53:04 <zmatt> ok, good luck? :D
Jul 28 16:53:26 <jfsimon1981> yes although we're accustommed these things take megs, which they might not require, bytes of kb could the unit
Jul 28 16:53:41 <jfsimon1981> Good luck yes, it's been tough
Jul 28 16:54:04 <zmatt> even seen an x-ray of a microsd card? https://www.researchgate.net/profile/Michael-Campbell-37/publication/258309794/figure/fig6/AS:297405909094411@1447918502565/X-ray-image-in-CSM-of-a-micro-SD-card-Image-consists-of-4-3-single-tiles-the.png
Jul 28 16:54:13 <jfsimon1981> We run out of the BB industry
Jul 28 16:54:31 <jfsimon1981> I have 20+ units, new deliveries will wait for months possibly
Jul 28 16:54:53 <jfsimon1981> never seen before
Jul 28 16:55:00 <zmatt> bb industrial is for low-temperature support I think?
Jul 28 16:55:06 <zmatt> like, below freezing
Jul 28 16:55:13 <jfsimon1981> At least the external package looks nice
Jul 28 16:55:35 <jfsimon1981> What's inside looks a bit messy, unless we understand it
Jul 28 16:55:45 <jfsimon1981> Yes below freezing
Jul 28 16:56:20 <jfsimon1981> High temp is not needed, since there are components going away from 70°C already, appart from the BB
Jul 28 16:56:30 <zmatt> well, you try to stick your entire design into the space of a microsd card ;)
Jul 28 16:56:31 <jfsimon1981> But -20°C or so it needs
Jul 28 16:56:54 <jfsimon1981> Except i like Unix design
Jul 28 16:57:23 <jfsimon1981> If you make it a bit modular, can do various things without re design the whole thing
Jul 28 16:57:53 <jfsimon1981> I reflect that in code, C/C++ i do are interfaced to be modular as much as i can too.
Jul 28 16:58:05 <jfsimon1981> BB blank can't do the negative temp right ?
Jul 28 16:58:15 <jfsimon1981> black
Jul 28 16:59:41 <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
Jul 28 17:00:20 <zmatt> and the controller is made by people who really deeply understand the flash and how it behaves
Jul 28 17:00:55 <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
Jul 28 17:02:45 <jfsimon1981> yes although what i meant, they surely have modular things at the die level in that case
Jul 28 17:03:21 <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
Jul 28 17:04:02 <jfsimon1981> But from the picture xray it's not too clear
Jul 28 17:05:09 <jfsimon1981> Things get inctricated a lot so that changes here affect somethings else far away often however hard we'd try not
Jul 28 17:05:27 <zmatt> visual neatness is of no benefit to the final product
Jul 28 17:06:38 <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
Jul 28 17:07:18 <zmatt> there can also be good reasons for curvy lines, for signal integrity
Jul 28 17:07:28 <jfsimon1981> although for the design i work now it needs be clean inside, the client wants to check and approve the product
Jul 28 17:07:41 <jfsimon1981> (to a certain point)
Jul 28 17:07:46 <zmatt> well, people typically don't see the inside of a microsd card ;)
Jul 28 17:08:22 <zmatt> but here, maybe you like this one better: https://pbs.twimg.com/media/EdKBfKxUMAAFkKC.jpg
Jul 28 17:08:30 <jfsimon1981> not many will
Jul 28 17:09:19 <jfsimon1981> That's reasonable
Jul 28 17:09:28 <jfsimon1981> Whereas the previous one we hope it works
Jul 28 17:09:42 <jfsimon1981> From a user perspective of course
Jul 28 17:09:54 <zmatt> this looks almost like a tiny pcb: https://i.imgur.com/kZgy0K5.jpg
Jul 28 17:09:59 <jfsimon1981> Maybe the designer didn't doubt it
Jul 28 17:10:18 <jfsimon1981> looks like it is
Jul 28 17:10:24 <zmatt> I have no doubt the designer didn't doubt it, does that first layout inspire any doubt in me
Jul 28 17:10:30 <jfsimon1981> very similar, vias, tracks
Jul 28 17:11:04 <jfsimon1981> The first one looked a bit strange
Jul 28 17:11:19 <zmatt> "strange" is just a matter of what you're used to
Jul 28 17:13:05 <zmatt> there's a pcb autorouter that produces output like this: https://www.eremex.com/images/434662.jpg
Jul 28 17:13:08 <zmatt> https://upload.wikimedia.org/wikipedia/commons/4/4e/Topor_bga.gif
Jul 28 17:13:18 <jfsimon1981> it seems the second one has much tighter dimensions in the tracks
Jul 28 17:13:34 <jfsimon1981> That could allow a more clean design
Jul 28 17:14:07 <jfsimon1981> Things explaine
Jul 28 17:14:09 <jfsimon1981> d
Jul 28 17:14:39 <zmatt> anyway, I have things to do, and I think so do you ;)
Jul 28 17:14:43 <jfsimon1981> yep
Jul 28 17:14:48 <jfsimon1981> thx for all
Jul 28 17:14:58 <jfsimon1981> will do my homework then
Jul 28 17:57:36 <vvn> hi all -- Can a device tree create a device symlink?
Jul 28 18:03:18 <jfsimon1981> I think ln -s
Jul 28 18:03:31 <jfsimon1981> for a symbolic link, doesn't work ?
Jul 28 18:05:37 <lucascastro> vvn: I don't think DT create anything at all. The device "read it" and then create what's needed.
Jul 28 18:07:36 <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
Jul 28 18:08:42 <lucascastro> Idk, and I'm not expect on that.
Jul 28 18:12:46 <lucas_> weird situation.
Jul 28 18:13:00 <lucas_> I guess
Jul 28 18:31:17 <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
Jul 28 18:31:21 <zmatt> *symlink
Jul 28 18:32:05 <zmatt> that won't work for the sd card since it has no representation in DT
Jul 28 18:32:22 <zmatt> but the sd card is always /dev/mmcblk0
Jul 28 18:32:53 <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
Jul 28 18:36:54 <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)
**** ENDING LOGGING AT Fri Jul 29 02:59:56 2022