|
you’re not going to get a memory management unit for a nickel 
|
#
?
Nov 2, 2021 06:05
|
|
|
|
| # ? Apr 25, 2024 10:10 |
|
|
I went to look up budgetary pricing for an attiny to try and make a joke and found thisquote:Out of Stock now I’m just depressed
|
|
#
?
Nov 2, 2021 06:06
|
|
|
the chip shortage is real, my friend that said, digikey has a bunch of attiny parts in stock
|
|
#
?
Nov 2, 2021 06:51
|
|
|
in my day you had a kernel and busybox and that’s it.
|
|
#
?
Nov 2, 2021 08:10
|
|
|
just do something like this OPcode:eschaton fucked around with this message at 08:16 on Nov 2, 2021 |
|
#
?
Nov 2, 2021 08:11
|
|
|
is it here where i barge in and tell you guys i use gentoo for "embedded" work
Tankakern fucked around with this message at 09:26 on Nov 2, 2021 |
|
#
?
Nov 2, 2021 08:56
|
|
|
No joke, I'm doing a Linux for a 10MHz CPU. Ten. I rate the experience 0/10 would not do again.
|
|
#
?
Nov 2, 2021 16:01
|
|
|
Poopernickel posted:No joke, I'm doing a Linux for a 10MHz CPU. Ten. nope. Linux bottoms out at around 50 mips before being completely worthless, and that’s with the most bare bones cut down system you can have
|
|
#
?
Nov 2, 2021 16:16
|
|
|
It's actually more usable than you'd think with a minimal kernel and a BusyBox rootfs. Target is an armv8 running in an emulator. RAM runs at a much faster clock rate. Serial console is usable and feels "ok" but not great. Shell scripts are tolerable speed-wise. Boot time is around 90 seconds once the kernel has loaded. Poopernickel fucked around with this message at 17:57 on Nov 2, 2021 |
|
#
?
Nov 2, 2021 16:22
|
|
|
My current project uses an AM3358 and I hate it so much.
|
|
#
?
Nov 2, 2021 17:13
|
|
|
Yocto's bbappend/layer system is good, and Buildroot should emulate it. Make it easier for users to modify recipe behavior. In today's world, you have to either: 1. jump through a bunch of hoops, or 2. fork Buildroot if you don't like how a built-in recipe does something or other. #2 is what I see most companies do, and it has a high long-term maintenance cost. Adam Buildroot, make #1 easier for your users and minimize human suffering. Do the needful T I A
|
|
#
?
Nov 3, 2021 01:57
|
|
|
As an example, I recently found a package that had a missing dependency when built with some config options. My choices for how to add that dependency were: 1. Fork Buildroot just to add one missing dependency to a package. 2. Say "gently caress it who cares". 3. Dig into pkg-generic.mk to figure out what internal behavior I had to modify. Appending to ${PKG}_DEPENDENCIES doesn't work because it gets parsed during the recipe's call to pkg-generic. Poopernickel fucked around with this message at 02:12 on Nov 3, 2021 |
|
#
?
Nov 3, 2021 02:10
|
|
|
submit a patch upstream.
|
|
#
?
Nov 3, 2021 02:15
|
|
|
DoomTrainPhD posted:submit a patch upstream. Cool, I guess that'll solve my today problem in 6 months when the next stable release comes out. Poopernickel fucked around with this message at 02:54 on Nov 3, 2021 |
|
#
?
Nov 3, 2021 02:22
|
|
|
it means you don’t have to maintain the patch when it’s time to update.
|
|
#
?
Nov 3, 2021 02:59
|
|
|
the only industry standard in embedded is that your poo poo is always different from everybody else in the industry.
|
|
#
?
Nov 3, 2021 03:00
|
|
|
Meanwhile in Yocto land, you can upstream your patch _and_ fix it locally for the release you're currently using via a bbappend.
Poopernickel fucked around with this message at 03:18 on Nov 3, 2021 |
|
#
?
Nov 3, 2021 03:06
|
|
|
DuckConference posted:the only industry standard in embedded is that your poo poo is always different from everybody else in the industry. Truuuuuuth son
|
|
#
?
Nov 3, 2021 03:06
|
|
|
Ah yes, a patch that’s applied to Buildroot when you build the container that builds Buildroot, or a gigantic mess of recipes that append recipes that append recipes. way more maintainable.
|
|
#
?
Nov 3, 2021 03:34
|
|
|
Sapozhnik posted:i hate to say it but use docker. or podman or w/e. qemu-build your p-lang crap into an oci container and then deploy it on fedora iot or similar. this doesn't help as much as you might think because you still have to janitor compiling things and you'll probably get a lot of duplication and updating is a pain (these devices aren't guaranteed to be network connected and need to be sneakernet updateable) CRIP EATIN BREAD posted:yeah, the problem is that yocto is designed into being very explicit about dependencies and their licenses. bringing in the free-for-all nightmare that is python and node dependencies is a nightmare. no, that's not the problem. you see, there's a lot of modern dependency management tools for plangs that in fact have the same goal, and let you decide every so often to update and when you do the update command it does dependency resolution, locks it down, and then whenever you're actually setting up an environment it downloads identical-by-hash locked versions of the deps that you specified. the problem is this overlaps with the stuff yocto and buildroot does. it could actually go in pretty seamlessly i think but nobody wants to deal with doing it (including me lol jesus christ imagining doing big internals work on either buildroot or yocto gives me insane heebie jeebies)
|
|
#
?
Nov 3, 2021 04:25
|
|
|
also it's really funny that both peoples concept of what should be done involves having text patches to core functionality either applied or upstreamed via email. kill us all
|
|
#
?
Nov 3, 2021 04:28
|
|
|
I see the reality of simply forking buildroot when a project starts, and keeping all development for a specific project on that fork, to be the industry standard. No one is going to update packages in the middle of development unless they're willing to spend a lot of real dollars to have qa go through all the testing, auditing, and qualification (not to mention pre-certification) steps when there's a material software change. It would have likely been the same thing with yocto. Tankakern posted:is it here where i barge in and tell you guys i use gentoo for "embedded" work don't you have a raspberry pi running gentoo?
|
|
#
?
Nov 3, 2021 04:47
|
|
|
sb hermit posted:I see the reality of simply forking buildroot when a project starts, and keeping all development for a specific project on that fork, to be the industry standard. No one is going to update packages in the middle of development unless they're willing to spend a lot of real dollars to have qa go through all the testing, auditing, and qualification (not to mention pre-certification) steps when there's a material software change. I worked on a product that took around 2 years to take to market. We upgraded Yocto versions shortly before beta. I had to bump three submodules, change a couple of config files, delete one .bbappend (fix got upstreamed), and tweak another. It took one workday. Yocto is great if you want to keep your customizations somewhere other than mixed with your upstream sources. Poopernickel fucked around with this message at 05:41 on Nov 3, 2021 |
|
#
?
Nov 3, 2021 05:23
|
|
|
nope
FlapYoJacks fucked around with this message at 21:49 on Apr 6, 2022 |
|
#
?
Nov 3, 2021 06:39
|
|
|
sb hermit posted:
i did, for several projects, but as of right now my rpis now are for like.. minecraft and irc and such, so i copped out and put fedora on them. another fun project was setting up a musl-based gentoo system on a 486 running systemd (which had to get lot of patches back then to get systemd to compile against musl), i still have that setup working. not getting much use though, weirdly enough. takes like 15 minutes to boot up to sshd running
|
|
#
?
Nov 3, 2021 10:08
|
|
|
Tankakern posted:i did, for several projects, but as of right now my rpis now are for like.. minecraft and irc and such, so i copped out and put fedora on them. how much ram does it have? 4 or 16?
|
|
#
?
Nov 3, 2021 13:55
|
|
|
it was a ram monstrosity for its time, i think it has 48 MB (filled in all the slots, think there were 8 or 10 slots). so no issues with memory, it's just slow as hell, as a 66mhz 486 should be
|
|
#
?
Nov 3, 2021 14:34
|
|
|
Tankakern posted:it was a ram monstrosity for its time, i think it has 48 MB (filled in all the slots, think there were 8 or 10 slots). so no issues with memory, it's just slow as hell, as a 66mhz 486 should be Dang! I think I used to run a 486 as a home router in 2000. Can't remember if it had 4 or 16 MB RAM but I like to lean to the former.
|
|
#
?
Nov 3, 2021 16:41
|
|
|
In other news, I submitted a patch to bump OpenJDK 16 to 17 for Buildroot. This means Buildroot supports the last two LTS versions (11 and 17.) It's still crazy that the meta-java layer for Yocto still only supports 7 and 8 and kind of 14. This is why community-provided and "maintained" recipes are bad. 
|
|
#
?
Nov 4, 2021 19:58
|
|
|
just use
|
|
#
?
Nov 4, 2021 20:49
|
|
|
that's open source, baby! Lots of stuff still using java 8, I'm sure, and not enough corporate support to bump up the versions and start updating packages
|
|
#
?
Nov 4, 2021 21:02
|
|
|
DoomTrainPhD posted:In other news, I submitted a patch to bump OpenJDK 16 to 17 for Buildroot. This means Buildroot supports the last two LTS versions (11 and 17.) It's still crazy that the meta-java layer for Yocto still only supports 7 and 8 and kind of 14. nothing stopping you from submitting a patch, my dude - there's no difference there. Just like in Buildroot land, it'll happen as soon as somebody wants it enough to do it. 
Poopernickel fucked around with this message at 21:10 on Nov 4, 2021 |
|
#
?
Nov 4, 2021 21:06
|
|
|
Poopernickel posted:nothing stopping you from submitting a patch, my dude - there's no difference there. Just like in Buildroot land, it'll happen as soon as somebody wants it enough to do it. And if I get hit by a bus then there's no core group of maintainers that will take over lol. Also, there's no standard patch review process. Each community-provided recipe varies wildly in quality. sb hermit posted:that's open source, baby! The lack of TLS 1.3 support in Java 8 is the reason for them to upgrade. It scares me that there is so much ancient Java 8 stuff out there.
|
|
#
?
Nov 4, 2021 22:54
|
|
|
java 8 is used in so much software, and no one wants to update it to at least 11. bit rot is real
|
|
#
?
Nov 5, 2021 01:07
|
|
|
the difficulty of updating tls versions in embedded devices and cacerts rotating faster than before is going to wreck a lot of devices over the next few years
|
|
#
?
Nov 5, 2021 01:27
|
|
|
I think I'd rather embed myself into a wall than embed linux
|
|
#
?
Nov 5, 2021 01:54
|
|
|
hobbesmaster posted:the difficulty of updating tls versions in embedded devices and cacerts rotating faster than before is going to wreck a lot of devices over the next few years Good.
|
|
#
?
Nov 5, 2021 02:36
|
|
|
planned obsolescence, in the name of security Might as well, since there's a lot of bluetooth vulnerabilities going public today. When you have to rely on suppliers to fix old drivers, why bother with the illusion of "fully patched"?
|
|
#
?
Nov 5, 2021 02:51
|
|
|
maybe someone who isn’t Google could come up with an embedded linux base OS that can do over-the-air automatic updates and keep an lts release maintained. lol just kidding, it will take legislation before anyone does anything other than abandon their firmware as soon as it ships.
|
|
#
?
Nov 5, 2021 05:15
|
|
|
|
| # ? Apr 25, 2024 10:10 |
|
|
just remember folks, the S in IoT stands for security
|
|
#
?
Nov 5, 2021 05:24
|
|