00:47 <m4t> hrm i'm trying to do some brief verification of a new u-boot for my pogoplug e02 (kirkwood). currently it's running 'U-Boot 2014.04 (May 31 2014 - 19:16:34)'

00:47 <m4t> i'm trying tftpboot + go but it freezes right at the NAND probe consistently. tried playing with loaddr and text base

00:47 <m4t> is there anything more i can do, besides pray and jtag otherwise?

00:48 <m4t> kwboot apparently does not work for this (i've been trying for a bit, but just read it's unsupported)

00:49 <m4t> last time i flashed this 'saveenv' bricked it because the default location overlapped with u-boot on flash :P that was fun...

00:50 <m4t> (that was several yrs ago)

00:58 <m4t> https://github.com/u-boot/u-boot/blob/master/configs/pogo_e02_defconfig#L9

01:52 <Forty-Bot> > is there anything more i can do, besides pray and jtag otherwise?

01:52 <Forty-Bot> update?

01:57 <sjg1> milkylainen: I bisected it to a commit e7bae8283fe (HEAD, refs/bisect/bad) x86: Allow installing an e820 when booting from coreboot

01:57 <sjg1> milkylainen: Have not looked at why yet

02:14 <m4t> Forty-Bot: i want to confirm that it won't brick my board before flashing it...

02:14 <Forty-Bot> do you have a filesystem around? you could use ENV_IS_IN_FAT

02:15 <m4t> i can't boot into the new u-boot without flashing it to nand at 0x0

02:15 <m4t> in the past i've had success just chainloading to test before flashing, but not in this case

02:16 <Forty-Bot> well, if you're that concerned then get jtag working

02:17 <m4t> ...

02:34 <m4t> so i can chainload into the openwrt second stage image (u-boot-pogo_e02_second_stage)

02:37 <m4t> +# CONFIG_SECOND_STAGE is not set

02:37 <m4t> duh..

02:38 <m4t> https://github.com/openwrt/openwrt/blob/master/package/boot/uboot-kirkwood/patches/200-openwrt-config.patch interesting

02:40 <m4t> it's the environment load from nand that the openwrt second stage "hack" bypasses (it sets CONFIG_ENV_IS_NOWHERE), and i'm seeing boot hang at the nand probe... so i will try that

02:43 <m4t> there's something different with 2021.07 vs openwrt's prebuilt 2020.04 variants: https://paste.ee/p/N3OzD#59aTseDJzPAw15yvrSmAE4WipZ9KIBZr

02:44 <m4t> the non-second stage openwrt image aborts at the nand environment load, but gets past the nand probe itself. the second stage one also gets past the nand probe and lands at a prompt.

02:44 <m4t> however, 2021.07 was hanging at the nand probe completely, and 2021.07 with environment disabled gives a data abort

03:16 <sjg1> milkylainen: I sent a patch for the 2021.07 problem. For me the kernel boots, so I might need to get a copy of your kernel

03:16 <sjg1> milkylainen: I am using qemu BTW

06:30 <milkylainen_> sjg1: Nice! I'll try "x86: Ensure the e820 map is installed in all cases" and let you know.

06:47 <milkylainen_> sjg1: Kernel boots with 2021.07 :)

06:47 <milkylainen_> One issue down.

12:22 <sjg1> milkylainen_: For the other issue I'm not sure what to do, as I don't have the hardware. Probably needs more debugging. I do see [Firmware Bug] in my boot. I added info about that at the bottom

12:28 <milkylainen_> sjg1: Mm. I think I'll do some more digging there. My initial guess is either some old x86 legacy io-poll (keyboard serial or smth) or something regarding mmc init. That's the only two things I can think of right now.

12:30 <milkylainen_> sjg1: But I'm very much grateful for your help with 2021.04+. :)

12:31 <sjg1> milkylainen_: Yes could be...you should be able to debug it since it is still in U-Boot, as I understand it

12:58 <milkylainen_> sjg1: Regarding the firmware bug errors with QEMU, I see no such messages with the EDKII based one in Virtualbox.

13:03 <sjg1> milkylainen_: Well perhaps there is something wrong with the EFI I am using

13:04 <sjg1> milkylainen_: I got it from: https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-ia32-0-20210421.18.g15ee7b7689.noarch.rpm

23:05 <m4t> chainloading is working fine on 2021.07 with the defconfig, btw. i think the version that was hanging may have been too big

23:06 <m4t> enabling LTO causes an immediate reset though....

23:14 <m4t> actually, i take that back. v2021.07 hangs at NAND, tip of master does not... eek

23:34 <m4t> this is what fixes it: "bootstage: Eliminate when not enabled"

23:35 <m4t> https://github.com/u-boot/u-boot/commit/cb80ff20f2c8392f19248418f9a19a0474661860

23:35 <m4t> if i revert that on the tip of master, it hangs at the NAND probe. very reproducible.

23:35 <m4t> will try applying that to v2021.07 just to be certain.

23:40 <m4t> weird, v2021.07 with cb80ff20 applied doesn't see nand at all: NAND: 0 MiB

23:44 <m4t> this might just be chainloading side effects...

23:44 <m4t> e.g. NAND: BUG at drivers/mtd/nand/raw/nand_base.c:5062/nand_scan_tail()!