waydroid VS u-boot

Android on the desktop works very well on Wayland with Waydroid and it even supports Google Play store. https://waydro.id/

Great running apps not available on Linux with a touchscreen PC. It only seems to run Android apps compiled for x86, but it is very fast.

There are practical use cases, and it is very usable. I haven’t tried it on WSL2, but it seems like a practical approach without reliance on Microsoft.

There's a piece of software called Waydroid[1] that allows you to run Android applications on GNU/Linux platforms - including the PinePhone. Sxmo, despite its name, can run Wayland instead of X and therefore supports Waydroid.

Personally, I haven't managed to get Waydroid to work, a task hindered due to some massive initial downloads which are required to set it up. However, I haven't tried particular hard, and there are videos online by those more successful than me[2].

[1]: https://waydro.id/

[2]: https://tilvids.com/w/2b2f3a24-ae23-458e-a0fd-2f24a185a11b

I thought it was uncharacteristic of to see a service like this offered by a large tech company, and wanted to share.

Found whilst installing Waydroid: https://waydro.id/

Check out the Waydroid application.

I have setup an Arch linux server on my old pc. i mainly use it for plex, transmission, docker etc and it works pretty well! I wanted to install Waydroid https://waydro.id/ on that server. Is there a way that I can view waydroid using a VNC viewer on my laptop on the same network? is it possible or would I have to install a GUI like xfce before installing waydroid to view the same on tigervnc or some other VNC viewer? Thanks & regards.

> I run Fedora Linux after removing ChromeOS

Same here. Sometimes, it crashes on a measly 4 GB of RAM.

> (the only thing I'm missing is running Android apps)

I would recommend using Waydroid[1]. It runs fairly well in my use case, and runs LineageOS on top of it with the full LineageOS GUI.

[1]: https://waydro.id/

i am using KDE Neon (user edition) on two machines (thinkpad laptops with intel). On mentioned machines i would like to try and use waydroid: https://waydro.id/ Waydroid required wayland as display server (it will probably not work on x11).

Check (Waydroid)[https://waydro.id/]

Waydroid is rebuilding the original idea behind Anbox with explicit focus on modern Wayland powered desktop environments.

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.