On Sun, Jul 12, 2020 at 6:16 PM Bin Meng <bmeng...@gmail.com> wrote: > > Hi Alistair, > > On Sun, Jul 12, 2020 at 12:04 AM Alistair Francis <alistai...@gmail.com> > wrote: > > > > On Thu, Jul 9, 2020 at 5:50 PM Bin Meng <bmeng...@gmail.com> wrote: > > > > > > Hi Palmer, > > > > > > On Fri, Jul 10, 2020 at 8:45 AM Palmer Dabbelt <palmerdabb...@google.com> > > > wrote: > > > > > > > > On Thu, 09 Jul 2020 15:09:18 PDT (-0700), alistai...@gmail.com wrote: > > > > > On Thu, Jul 9, 2020 at 3:07 AM Bin Meng <bmeng...@gmail.com> wrote: > > > > >> > > > > >> From: Bin Meng <bin.m...@windriver.com> > > > > >> > > > > >> The reset vector codes are subject to change, e.g.: with recent > > > > >> fw_dynamic type image support, it breaks oreboot again. > > > > > > > > > > This is a recurring problem, I have another patch for Oreboot to fix > > > > > the latest breakage. > > > > > > > > > >> > > > > >> Add a subregion in the MROM, with the size of machine RAM stored, > > > > >> so that we can provide a reliable way for bootloader to detect > > > > >> whether it is running in QEMU. > > > > > > > > > > I don't really like this though. I would prefer that we don't > > > > > encourage guest software to behave differently on QEMU. I don't think > > > > > other upstream boards do this. > > > > > > > > I agree. If you want an explicitly virtual board, use the virt board. > > > > Users > > > > of sifive_u are presumably trying to do their best to test against what > > > > the > > > > hardware does without actually using the hardware. Otherwise there > > > > should be > > > > no reason to use the sifive_u board, as it's just sticking a layer of > > > > complexity in the middle of everything. > > > > > > Understood. Then let's drop this patch. > > > > > > > > > > > > Besides Oreboot setting up the clocks are there any other users of > > > > > this? > > > > > > > > IIRC we have a scheme for handling the clock setup in QEMU where we > > > > accept > > > > pretty much any control write and then just return reads that say the > > > > PLLs have > > > > locked. I'd be in favor of improving the scheme to improve > > > > compatibility with > > > > the actual hardware, but adding some way for programs to skip the clocks > > > > because they know they're in QEMU seems like the wrong way to go. > > > > > > > > > > Yep, that's my question to Oreboot too. > > > > > > U-Boot SPL can boot with QEMU and no problem was seen with clock > > > settings in PRCI model in QEMU. > > > > I don't think it's an unsolvable problem. There is just little work on > > Oreboot to run on QEMU. I can dig into it a bit and see if I can find > > a better fix on the Oreboot side. > > > > Can we remove the QEMU detect logic completely in Oreboot? Except the > QSPI controller QEMU should be able to run Oreboot since it runs > U-Boot SPL.
That is the eventual goal. Alistair > > Regards, > Bin