On Tue, Oct 4, 2022 at 1:03 PM Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > What I'm asking, I guess, is why you're messing with this board > model at all if you haven't added this functionality to u-boot. > This is just an emulation of an ancient bit of MIPS hardware, which > nobody really cares about very much I hope. I think most people emulating MIPS would disagree. This is basically a reference platform for most intents and purposes. As I mentioned, this involves `-kernel` -- the thing that's used when you explicitly opt-in to not using a bootloader, so when you sign up for QEMU arranging the kernel image and its environment. Neglecting to pass an RNG seed would be a grave mistake. > I'm not saying this is a bad patch -- I'm just saying that > QEMU should not be in the business of defining bootloader-to-kernel > interfaces if it can avoid it, so usually the expectation is > that we are just implementing interfaces that are already > defined, documented and implemented by a real bootloader and kernel. Except that's not really the way things have ever worked here. The kernel now has the "rngseed" env var functionality, which is useful for a variety of scenarios -- kexec, firmware, and *most importantly* for QEMU. Don't block progress here. > -kernel generally means "emulate the platform's boot loader" And here, a platform bootloader could pass this, just as is the case with m68k's BI_RNG_SEED or x86's setup_data RNG SEED or device tree's rng-seed or EFI's LINUX_EFI_RANDOM_SEED_TABLE_GUID or MIPS' "rngseed" fw environment variable. These are important facilities to have. Bootloaders and hypervisors alike must implement them. *Do not block progress here.* Jason
