u-boot VS oil

coreboot just initializes the hardware, the logo is something that the payload displays: https://www.coreboot.org/Payloads

The most typically used payload is u-boot: https://docs.u-boot.org/en/latest/

u-boot supports specifying splash screens via "splashfile", but it seems only bmp and maybe some raw image format are supported: https://github.com/u-boot/u-boot/blob/2f0282922b2c458eea7f85...

In other words, no support for png, which this exploit uses :). That doesn't mean that coreboot/u-boot aren't written in C though which is a language known for its vulnerabilities.

Probably a better example than WiFi would be the on-chip SDRAM controller. It's always somebody's IP and there's a blob in the boot firmware that's just binary register settings. Like so:

https://github.com/u-boot/u-boot/blob/master/arch/riscv/dts/...

Hello, It's my understanding that the following OSS software is used in the AtGames Legends family of products. Specifically: "Das U-Boot" https://github.com/u-boot/u-boot GPL-2.0+ Linux Kernel https://github.com/torvalds/linux GPL-2.0 The AtGames website at https://www.atgames.us/pages/credits does not contain the source code used in these products. Specifically, the GPL requires that if any modifications are made to GPL code, you must make the source code available to the users of the program as described in the GPL, and they must be allowed to redistribute and modify it as described in the GPL. Any modification to u-boot or the Linux Kernel adding the ability to boot a device must be made available to users of the program. Please see the following links regarding acceptable use of GPL software: https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic https://www.gnu.org/licenses/gpl-faq.en.html#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions https://www.gnu.org/licenses/gpl-faq.en.html#GPLCommercially https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietarySystem https://www.gnu.org/licenses/gpl-faq.en.html#DistributingSourceIsInconvenient Please let this request serve as written notice of a request for source code for the OSS software used in the following products: HA2810, HA2811, HA2812 AtGames Legends Core Puck HA2819 AtGames Legends Core Max HA8800, HA8801, HA8802 AtGames Legends Ultimate HA8810, HA8812 AtGames Legends Ultimate Mini HA8819, HA8819C AtGames Legends Pinball (Model unknown) AtGames Legends Pinball Micro At this point in time, AtGames is in violation of the GPL and should work to return to compliance by publishing the requested source code and making it available to users of the products.

Upstream u-boot also supports quite a lot of boards: https://github.com/u-boot/u-boot/tree/master/arch/arm/dts

git clone https://github.com/u-boot/u-boot make smdk5250_defconfig Makefile:40: *** missing operator. Stop.

Hey everyone, if this question is off-topic I apologize in advance and if you can redirect me into correct channel or any other source where I can ask question I would happily do, for now I think this is the best place to ask. I daily drive arch and wanted to run freeBSD/riscv64 image on qemu following this https://wiki.freebsd.org/riscv#QEMU_Emulator and u-boot guide: https://github.com/u-boot/u-boot/blob/master/doc/board/emulation/qemu-riscv.rst However it seems I'm doing something wrong and compilation results in error here is all additional info: https://pastebin.com/72shccGa

The normal way this is done is the DDR training blob is just embedded into the bootloader like any other data, and the bootloader loads it into the PMU. Same exact end result, minus involving a Cortex-M4 core for no reason and minus sticking the blob in external flash for no reason. Here, this is how U-Boot does it on every other platform:

https://github.com/u-boot/u-boot/blob/master/drivers/ddr/imx...

Same code, just running on the main CPU because it is absolutely pointless running it on another core, unless you're trying to obfuscate things to appease the FSF. And then the blob gets appended to the U-Boot image post-build:

https://github.com/u-boot/u-boot/blob/master/tools/imx8m_ima...

Purism went out of their way and wasted a ton of engineering hours just to create a more convoluted process with precisely the same end result, because somehow all these extra layers of obfuscation made the blob not a blob any more in the FSF's eyes.

The RK3399 LPDDR4 training code is open-source (albeit rather impenetrable to read) - implementations exist in coreboot, u-boot, and levinboot, so closed source firmware isn't required. I'm afraid I don't know answers to the other questions.

Some related references (on a somewhat messy wiki page) - https://github.com/oilshell/oil/wiki/Compact-AST-Representat...

Feel free to add others

will prevent almost all of the "silent footguns".

YSH has strict:all and then a bunch of NEW features.

There's been good feedback recently, which has led to many concrete changes. So your experience can definitely influence the language! https://github.com/oilshell/oil/wiki/Where-To-Send-Feedback

Regarding writing tools/tests/benchmarks in bash+Python, vs. writing tools in your main language:

I think we might eventually concede that something Debian-like is the “standard development environment” (at least for server side stuff, i.e. not iOS apps)

In this case, bash+Python is a non-issue. It works extremely reliably. That’s actually why I use it! Everything else seems to break, or it’s really slow (node.js is a very common alternative).

- Microsoft conceded this back in ~2017, by building Linux into their kernel with WSL, and providing Ubuntu on top

Yes bash + Python is a disaster on Windows (I have scars from it), but Microsoft agrees that the right place to solve that is in Windows :-)

- Every CI system runs Debian/Ubuntu

- Every hosting provider runs Debian/Ubuntu

- Every online dev env like gitpod.io provides Debian/Ubuntu

This is somewhat related to remote dev envs: https://lobste.rs/s/ucirlx/lapdev_self_hosted_remote_dev

One vision for https://www.oilshell.org/ is that the CI environment is the dev environment is the hosting environment.

Everything is just an equal node in a distributed system. BUT it’s more git like, in that you explicitly sync and work “locally”, wherever that is. You don’t have the network chatter and flakiness of “the cloud”.

Oils has a very large set of monotonically increasing properties too - https://www.oilshell.org/release/0.21.0/quality.html

All that is bash+Python that is run on every commit, and it’s extremely good at catching bugs and perf regressions.

I’m skeptical that any project has that level of quality automation written in pure Rust or Zig. More likely it’s a bunch of cloud services with YAML.

Also a bunch of “hard-coded” toolchains that you can’t script with bespoke code. Like some shell commands in your package.json, which is just a worse way of writing a shell script.

Our quality process is all self-hosted, in the repo, and runs on both Github Actions and sourcehut - https://www.oilshell.org/release/0.21.0/pub/metrics.wwz/line...

bash and Python runs perfectly on Github Actions and sourcehut, with zero change. Containers also do.

(Although we need to unify the CI and release, because the release runs on 2 different real hardware machines, while CI is cloud only.)

Also, a main point Oils is that bash now has another highly compatible, spec-driven implementation – OSH. Having 2 independent implementations is something newer languages don’t have.

(copy of lobste.rs comment)

in your bashrc to enable it. I've used it for probably ~18 years now.

It also works with https://www.oilshell.org/ since we use GNU readline. Just 'set -o vi' in ~/.config/oils/oshrc

No other shell does that.

But I didn't know it was called MULTIOS until now. (I guess that's read "mult I/O's"? I have a hard time not reading it was multi-OS :) )

It seems a bit niche to be honest, but it's possible to support in Oils.

---

Oils also uses Unix domain sockets already for the headless shell protocol

https://github.com/oilshell/oil/wiki/Headless-Mode

We could do something like dgsh, but so far I haven't seen a lot of uptake / demand. Every time it's mentioned, somebody kinda wants it, and then it kinda peters out again ... still possible though.

I think flat files work fine for a lot of use cases, and once you add streaming, you also want monitoring, more control over backpressure/queue sizes, etc.

which works well. You don't have to clean when rebuilding variants. IMO this is 100% essential for writing C++ these days. You need a bunch of test binaries, and all tests should be run with ASAN and UBSAN.

---

I wrote a mini-bazel on top of Ninja with these features:

https://www.oilshell.org/blog/2022/10/garbage-collector.html...

So it's ~1700 lines, but for that you get the build macros like asdl_library() generating C++ and Python (the same as proto_library(), a schema language that generates code)

And it also correctly finds dependencies of code generators. So if you change a .py file that is imported by another .py file that is used to generated a C++ header, everything will work. That was one of the trickier bits, with Ninja implicit dependencies.

I also use the Bazel-target syntax like //core/process

This build file example mixes low level Ninja n.rule() and n.build() with high level r.cc_library() and so forth. I find this layering really does make it scale better for bigger projects

https://github.com/oilshell/oil/blob/master/asdl/NINJA_subgr...

Some more description - https://lobste.rs/s/qnb7xt/ninja_is_enough_build_system#c_tu...

This is sort of a category error...

re2c is a lexer generator, and YAML and Python are recursive/nested formats.

You can definitely use re2c to lex them, but it's not the whole solution.

I use it for everything possible in https://www.oilshell.org, and it's amazing. It really reduces the amount of fiddly C code you need to parse languages, and it drops in anywhere.

SEEKING VOLUNTEERS - https://www.oilshell.org/ - https://github.com/oilshell/oil/

I'm looking for people to help fill out the "standard library" for Oils/YSH. We're implementing a shell for Python and JavaScript programmers who avoid shell!

On the surface, this is writing some very simple functions in typed Python. But I've realized that the hardest parts are specifying, TESTING, and documenting what the functions do.

---

The most recent release announcement also asks for help - https://www.oilshell.org/blog/2024/01/release-0.19.0.html (long)

If you find all those details interesting (if maybe overwhelming), you might have a mind for language design, and could be a good person to help.

Surveying what Python and JavaScript do is very helpful, e.g. for the recent Str.replace() function, which is nontrivial (takes a regex or string, replacement template or string)

But there are also very simple methods to get started, like Dict.values() and List.indexOf(). Other people have already contributed code. Examples:

https://github.com/oilshell/oil/commit/58d847008427dba2e60fe...

https://github.com/oilshell/oil/commit/8f38ee36d01162593e935...

This can also be useful to tell if you'll have fun working on the project - https://github.com/oilshell/oil/wiki/Where-Contributors-Have...

More on #help-wanted on Zulip (requires login) - https://oilshell.zulipchat.com/#narrow/stream/417617-help-wa...

Please send a message on Github or Zulip! Or e-mail me andy at oilshell dot org.

This is true, but then the corrolary is that new PRs need to come with this higher and rigorous level of test coverage.

And then that becomes a bit of a barrier to contribution -- that's a harness

I often write entirely new test harnesses for features, e.g. for https://www.oilshell.org, many of them linked here . All of these run in the CI - https://www.oilshell.org/release/latest/quality.html

The good thing is that it definitely helps me accept PRs faster. Current contributors are good at this kind of exhaustive testing, but many PRs aren't