Embedded Linux: It's Linux, but somehow worse

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Embedded Linux: It's Linux, but somehow worse

«‹›11 »

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

sb hermit posted:

what is that bespoke clang doing to those machine language binaries???

# ? Aug 10, 2023 09:22

Adbot: ADBOT LOVES YOU

# ? Apr 28, 2024 09:20

FlapYoJacks: Feb 12, 2009

After much fighting, cursing, and head scratching, I am now able to build and run flutter apps using Buildroot! :woop:

# ? Aug 15, 2023 23:57

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

Noice. Have you tried it out to make a fart-app yet? Pretty interested in how well/bad the embedded and web guis work

Poopernickel fucked around with this message at 03:03 on Aug 16, 2023

# ? Aug 16, 2023 03:00

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

Noice. Have you tried it out to make a fart-app yet? Pretty interested in how well/bad the embedded and web guis work

I ported the flutter-gallery app, just haven�t submitted the package yet. Performance is pretty good with a x86 KVM. :v:

I don�t have a board to test with yet so QEMU it is.

# ? Aug 16, 2023 03:37

FlapYoJacks: Feb 12, 2009

FlapYoJacks posted:

I ported the flutter-gallery app; I just haven�t submitted the package yet. Performance is pretty good with an x86 KVM. I don�t have a board to test with yet, so QEMU it is.

After 7 versions of the Flutter patch series, I am happy with the results, and everything works properly. Now give Buildroot proper Vulkan support.

# ? Aug 30, 2023 17:32

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

Nice. Is this gonna make it into the next Buildroot release?

# ? Aug 31, 2023 00:39

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

Nice. Is this gonna make it into the next Buildroot release?

Nah, they are marked as next. The next BR release comes out in the next few days.

# ? Aug 31, 2023 00:55

FlapYoJacks: Feb 12, 2009

Does anyone want to take a crack at creating a build cache for Buildroot? :v:

# ? Aug 31, 2023 21:22

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

FlapYoJacks posted:

Does anyone want to take a crack at creating a build cache for Buildroot?

Buildroot: don't use Yocto, it's too complicated
also Buildroot: oh, wait actually those features might have a point

# ? Aug 31, 2023 21:49

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

Buildroot: don't use Yocto, it's too complicated
also Buildroot: oh, wait actually those features might have a point

Eh, that's been on the list of things to do for quite some time. Buildroot and its maintainers don't say "Don't use Yocto, it's too complicated." They say "Don't use Yocto, setup is a giant pain, and the reliance on community layers is a crapshoot." :v:

# ? Aug 31, 2023 21:56

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

The actual implementation might not be too bad though, tbh

It would probably look something like:
1. Require build isolation
2. Hash all of every package's Make variables (determined by prefix)
3. Build-step also has to learn how to depend on any source files that are local.
4. After package build, install to a temporary DESTDIR
5. Tar up the result, name it by hash, and put it in some cache folder
6. Delete the DESTDIR
7. When populating the sysroot for a new package build, always do it from the cache
8. Set dependency relationships appropriately

# ? Aug 31, 2023 21:56

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

3 might actually be a doozy if there's no mechanism for it today

# ? Aug 31, 2023 21:58

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

The actual implementation might not be too bad though, tbh

It would probably look something like:
1. Require build isolation
2. Hash all of every package's Make variables (determined by prefix)
3. Install to a temporary DESTDIR
4. Tar up the result, name it by hash, and put it in some cache folder
5. Delete the DESTDIR
7. When populating the sysroot for a new package build, always do it from the cache
8. Set dependency relationships appropriately

Creating the cache is easy. Yann (one of the maintainers) has already done that. Applying the cache is the difficult part.

- To extract a package, you must first extract all its dependencies.

Say you have 3 packages, A, B, and C. A depends on C, and B depends on C. Then, when you uncache A, you first need to uncache C. Then, when you uncache B, you first need to uncache C. But C is already uncached because you uncached A.
And then consider PPD. You need to uncache, but first, you need to pre-populate as the pre-configure rsyncs, which in turn requires that you are properly uncached dependencies.. Another question to consider: What to do when the build was done in /some/path, then cached, and then extracted for a new build on /some/other/path.

So, proper uncaching either requires that we duplicate the logic in the cache script (ugly) or that we integrate uncaching in the package infra (hard.)

# ? Aug 31, 2023 22:02

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

I'd expect Make's dependency solver to handle that OK though, right? For isolated packages, I'd expect Make logic that looks like:

code:

$(target).configure: $(foreach x,$(DEPS)),$(call populate_target_sysroot,$target,$x))
	...configure steps...

$(target).built: $(target).configure
	...build steps...

If there's something like that, couldn't populate_target_sysroot() have a dependency on a hashed-named tarball, which depends on some kind of build_or_fetch() task?

# ? Aug 31, 2023 23:20

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

I'd expect Make's dependency solver to handle that OK though, right? For isolated packages, I'd expect Make logic that looks like:
code:
$(target).configure: $(foreach x,$(DEPS)),$(call populate_target_sysroot,$target,$x))
	...configure steps...

$(target).built: $(target).configure
	...build steps...
If there's something like that, couldn't populate_target_sysroot() have a dependency on a hashed-named tarball, which depends on some kind of build_or_fetch() task?

I would have to look at the make infrastructure again. It's possible, just difficult. :v:

# ? Aug 31, 2023 23:29

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

FlapYoJacks posted:

or that we integrate uncaching in the package infra (hard.)

that's the right way to do it imo. Probably some additions to pkg-generic.mk - some pattern rules and some additions to inner-generic-package.

After all - what's more fun than digging through an inscrutable web of Make macros?

# ? Aug 31, 2023 23:30

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

that's the right way to do it imo. Probably some additions to pkg-generic.mk - some pattern rules and some additions to inner-generic-package.

After all - what's more fun than digging through an inscrutable web of Make macros?

If you do it I could get you a plane ticket to FOSDEM. Not joking.

# ? Sep 1, 2023 00:01

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

FlapYoJacks posted:

If you do it I could get you a plane ticket to FOSDEM. Not joking.

don't threaten me with a good time :wink:

Poopernickel fucked around with this message at 00:32 on Sep 1, 2023

# ? Sep 1, 2023 00:27

FlapYoJacks: Feb 12, 2009

submitted Vulcan packages. Now you too can have Vulcan support in Buildroot! Surprisingly easy with no real complications.

# ? Sep 1, 2023 17:35

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

FlapYoJacks posted:

If you do it I could get you a plane ticket to FOSDEM. Not joking.

how do you think the BR folks would feel about an implementation that used Make's `load` functionality to compile and run a C extension?

A correct cache implementation requires me to hash the metadata of each package defined in the build. It would be pretty slow if I had to shell out to sha256sum all the time, and I don't think I could do it in pure Makelang.

# ? Sep 1, 2023 22:47

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

how do you think the BR folks would feel about an implementation that used Make's `load` functionality to compile and run a C extension?

A correct cache implementation requires me to hash the metadata of each package defined in the build. It would be pretty slow if I had to shell out to sha256sum all the time, and I don't think I could do it in pure Makelang.

Ask them on irc on the OFTC server #buildroot. Warning: They are French :v:

Edit: They of course speak perfect English. The humor, +9 hour time difference, and more direct approach at debate is what the warning covers.

FlapYoJacks fucked around with this message at 22:56 on Sep 1, 2023

# ? Sep 1, 2023 22:49

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

FlapYoJacks posted:

Ask them on irc on the OFTC server #buildroot. Warning: They are French

Edit: They of course speak perfect English. The humor, +9 hour time difference, and more direct approach at debate is what the warning covers.

eh I don't want to get everybody's hopes up yet. Just want to feel out how it'd be received.

# ? Sep 1, 2023 23:28

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

eh I don't want to get everybody's hopes up yet. Just want to feel out how it'd be received.

I would also say that sha256 is a *bit* overkill for file verification. MD5 would be fine. :v:

# ? Sep 1, 2023 23:33

FlapYoJacks: Feb 12, 2009

Dealing with QT4 :shepicide:

# ? Sep 13, 2023 01:16

akadajet: Sep 14, 2003

FlapYoJacks posted:

Dealing with QT4

show some spirit

https://www.youtube.com/watch?v=NbTEVbQLC8s

# ? Sep 13, 2023 01:28

FlapYoJacks: Feb 12, 2009

akadajet posted:

show some spirit

https://www.youtube.com/watch?v=NbTEVbQLC8s

I love that video every time I see it. :allears:

I figured out the issue with QT4 and parallel package building. QT4 hard codes paths to the compiler tools in all the qmake.conf files it installs.
Then, another package will come around and rsync the qt4 host directory and will try to use a gcc/g++ in the wrong directory, which causes linking issues.
A sed command and a bunch of cursing later, and all is good. Now I can do the QT4 dance! :v:

FlapYoJacks fucked around with this message at 01:31 on Sep 14, 2023

# ? Sep 14, 2023 01:27

hobbesmaster: Jan 28, 2008

Qt4 is nice imo

this post sent from 2007

# ? Sep 14, 2023 01:54

FlapYoJacks: Feb 12, 2009

hobbesmaster posted:

Qt4 is nice imo

this post sent from 2007

I�m sure these guys would be on QT5 if they weren�t cheap. :v:

# ? Sep 14, 2023 02:08

hobbesmaster: Jan 28, 2008

Qt 6 is the �not cheap� option

# ? Sep 14, 2023 02:11

FlapYoJacks: Feb 12, 2009

hobbesmaster posted:

Qt 6 is the �not cheap� option

Ignoring licensing is the cheap option. :v:

Edit:
The time it took to figure this out is well worth the effort. Total build times went from 7 hours to 90 minutes for 7 boards and an emulator.

Things changed:
- Committed the dl/ directory
- Shared ccache between boards with the same processors
- Parallel package building.

# ? Sep 14, 2023 02:18

FlapYoJacks: Feb 12, 2009

https://gitlab.com/buildroot.org/buildroot/-/tree/master/package/flutter-engine?ref_type=heads

:getin:

# ? Oct 1, 2023 20:11

FlapYoJacks: Feb 12, 2009

The RPI5 is up for pre-orders. Looks like a 4x increase in GPU performance on average.

# ? Oct 4, 2023 17:14

Hen: Aug 22, 2006

Hey is there an FPGA programming thread and if not should we make one??

# ? Oct 4, 2023 23:59

hobbesmaster: Jan 28, 2008

if you want to talk about MPSoCs and such this would be close enough I suppose?

# ? Oct 5, 2023 00:18

Hen: Aug 22, 2006

hobbesmaster posted:

if you want to talk about MPSoCs and such this would be close enough I suppose?

Sure, I mean... I'm a total n00b and just got a Basys 3 introductory board so

# ? Oct 5, 2023 00:25

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

I have done an FPGA now and then! The basys3 looks sweet, I've never played with it.

I shipped a few Artix designs, back before I made the jump from hardware engineer to software engineer. Ask away if you want hot takes that haven't been updated in about 6 years

# ? Oct 5, 2023 05:44

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

fun-fact for the cool kids: Xilinx supports a yocto linux for its Microblaze soft CPUs

shockingly, it's actually not the worst experience if you just want to do some command-and-control type poo poo for your custom FPGA peripherals

# ? Oct 5, 2023 05:48

Hen: Aug 22, 2006

What's your HOTTEST 6 year old FPGA take??

# ? Oct 5, 2023 05:49

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

TCL is a good programming language

# ? Oct 5, 2023 07:29

Adbot: ADBOT LOVES YOU

# ? Apr 28, 2024 09:20

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

TCL is a good programming language

This infers there are good programming languages. shameful.

# ? Oct 5, 2023 11:55

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Embedded Linux: It's Linux, but somehow worse

«‹›11 »