Hi Prasun, So just to understand your setup correctly, you're saying that you are using vboot in an RW-A/B configuration -- but your RO image is some old coreboot version, and you just updated the RW-A to the newest one? Unfortunately, that's not how vboot can work -- when building coreboot master, you always need to use RO and RW-A/B from the same commit. There are numerous interaction points between the RO and RW stages (e.g. the memory layout in CAR) that need to fit together perfectly to make it all work. We make changes to coreboot that are incompatible with older RO versions all the time (my patch series added a CBFS mcache area to the CAR layout, that's probably what's causing your issue), if you have been running this configuration for a while it was just pure luck that you didn't see it fail yet.
vboot was designed so you would create a branch when you build your RO version, and then the RW-A/B should only be updated with bug fixes built from that branch where you only cherry-pick in patches to solve specific small issues, and you need to carefully make sure that none of those patches touch the RO/RW interface. It's not designed to just keep updating the RW part to the newest master. We want to keep developing across all stages for master so unfortunately that's really the only way it can work. (I guess we could start having official RW-update branches for each coreboot release tag to pick in RW-safe fixes and small features... I think there just hasn't been enough interest in upstream vboot to do that for now.) On Thu, Dec 10, 2020 at 2:24 AM Prasun Gera <prasun.g...@gmail.com> wrote: > > This is still broken for my vboot setup on Thinkpad T530. I have pulled in > the most recent fixes (i.e., https://review.coreboot.org/48482). I flashed to > RW_A, which does not boot. My old build on RO still works fine. The RO build > is a few months old. On IRC, one suggestion was to try with NO_CBFS_MCACHE, > which does work. That is, building with NO_CBFS_MCACHE and flashing to RW_A > works. Any ideas ? It's quite difficult to open this laptop. So I would like > to not touch RO if possible. > > My defconfig: > # CONFIG_USE_BLOBS is not set > CONFIG_VENDOR_LENOVO=y > CONFIG_FMDFILE="src/mainboard/lenovo/t530/vboot-rwab.fmd" > CONFIG_VBOOT=y > CONFIG_HAVE_IFD_BIN=y > CONFIG_BOARD_LENOVO_T530=y > CONFIG_PCIEXP_L1_SUB_STATE=y > CONFIG_PCIEXP_CLK_PM=y > CONFIG_H8_SUPPORT_BT_ON_WIFI=y > CONFIG_H8_FN_KEY_AS_VBOOT_RECOVERY_SW=y > CONFIG_HAVE_ME_BIN=y > CONFIG_CHECK_ME=y > CONFIG_USE_ME_CLEANER=y > CONFIG_HAVE_GBE_BIN=y > CONFIG_DRIVERS_PS2_KEYBOARD=y > CONFIG_COREINFO_SECONDARY_PAYLOAD=y > CONFIG_MEMTEST_SECONDARY_PAYLOAD=y > CONFIG_NVRAMCUI_SECONDARY_PAYLOAD=y > CONFIG_TINT_SECONDARY_PAYLOAD=y > CONFIG_MEMTEST_MASTER=y > > > On Mon, Dec 7, 2020 at 3:48 PM Julius Werner <jwer...@chromium.org> wrote: >> >> Sorry for the breakage and thanks for narrowing down the issue. I >> think Arthur had also just figured out the same problem and uploaded a >> quick fix here: https://review.coreboot.org/48407 >> >> On Sun, Dec 6, 2020 at 11:09 PM Iru Cai <mytbk920...@gmail.com> wrote: >> > >> > By using gdb, I can debug on QEMU. I can see in bootblock, romstage and >> > postcar, >> > when USE_OPTION_TABLE is set, the debug_level option is always read, so >> > there >> > is a cbfs_map_ro() in each stage. The buggy thing is in postcar stage, the >> > cbfs mcache >> > cannot be found, so its size becomes zero, then all the files in the cbfs >> > cannot be loaded >> > because of the mcache overflow, which results in failing to load the >> > ramstage. >> > >> > On Mon, Dec 7, 2020 at 12:18 PM Iru Cai <mytbk920...@gmail.com> wrote: >> >> >> >> Confirmed on qemu-i440fx. It's strange that it already has different >> >> behavior in romstage between setting and not setting >> >> USE_OPTION_TABLE. I still don't know what is broken in this commit. >> >> >> >> On Sun, Dec 06, 2020 at 11:24:11PM +0100, Merlin Büge wrote: >> >> > >> >> > 9d0cc2aea9 cbfs: Introduce cbfs_ro_map() and cbfs_ro_load() >> >> > https://review.coreboot.org/c/coreboot/+/39306 >> >> > >> > >> > >> > >> > -- >> > My website: https://vimacs.lcpu.club >> > >> > Please do not send me Microsoft Office/Apple iWork documents. Send >> > OpenDocument instead! http://fsf.org/campaigns/opendocument/ >> _______________________________________________ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
