Date: Thu, 17 Dec 2020 00:22:08 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4 vs. use of /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin : RPi4 boot crashes in my context; only 1st RAM page is reserved Message-ID: <6F62F9B6-9092-4833-A78B-477FBAB69D34@yahoo.com> In-Reply-To: <B3AD61A3-9C4E-4ABD-BDAF-CA8B4E62EC78@yahoo.com> References: <B3AD61A3-9C4E-4ABD-BDAF-CA8B4E62EC78@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Dec-16, at 23:25, Mark Millard <marklmi at yahoo.com> wrote: > Based on using /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin > and the bdinfo u-boot command, note the reserved.reg[0x0].size value > and .base value for the RPi4 8 GiByte example that I tested with: >=20 > lmb_dump_all: > memory.cnt =3D 0x3 > memory.size =3D 0x0 > memory.reg[0x0].base =3D 0x0 > .size =3D 0x3e000000 > memory.reg[0x1].base =3D 0x40000000 > .size =3D 0xbc000000 > memory.reg[0x2].base =3D 0x100000000 > .size =3D 0x100000000 >=20 > reserved.cnt =3D 0x2 > reserved.size =3D 0x0 > reserved.reg[0x0].base =3D 0x0 > .size =3D 0x1000 > reserved.reg[0x1].base =3D 0x3db4bb30 > .size =3D 0x4b44d0 >=20 >=20 > Only 1 page at the beginning of RAM is protected from accidental > use by u-boot. This is the same general type of problem that > u-boot-rpi4 used to have with not handling armstub8-gic.bin 's > memory use requirements: more than one page needs to be > protected. The above paragraph is wrong in its details, despite a similarity in the older and new problem contexts: The old problem fix was making the FreeBSD kernel see a reserved area bigger than a page so that the kernel did not mess up armstub8-gic.bin RAM content. (Previously the kernel had not touched that RAM just by accident.) The above problem is making u-boot internal activities see a reserved area sufficently bigger than a page to also avoid messing up armstub8-gic.bin RAM content (including the code), but at an earlier stage in the boot sequence. The crash never got to the FreeBSD kernel so the problem is distinct from the older crash details. I've not done enough to prove that the reserves size is the cause the cause of the crash when I use u-boot-rpi-arm64's u-boot.bin . My use of a u-boot-rpi4 u-boot.bin variant that also respects armstub_rsrvd means that my u-boot-rpi4 based boots do have a u-boot that reserves the armstub8-gic.bin RAM. But its booting fine does not prove that no other difference is involved: it is just suggestive. > That might be contributing to the boot attempts ending up with > Synchronous Abort: >=20 > PM_RSTS: 0x00001000 > RPi: BOOTLOADER release VERSION:c305221a DATE: Sep 3 2020 TIME: = 13:11:46 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=3D1599135103 = 0x2e7284c8 0x00d03114 > uSD voltage 3.3V > Initialising SDRAM 'Micron' 32Gb x2 total-size: 64 Gbit 3200 > . . . > MESS:00:00:07.718966:0: gpioman: gpioman_get_pin_num: pin = SDCARD_CONTROL_POWER not defined >=20 >=20 > U-Boot 2020.10 (Dec 15 2020 - 20:55:53 +0000) >=20 > DRAM: 7.9 GiB > RPI 4 Model B (0xd03114) > MMC: mmc@7e300000: 1, emmc2@7e340000: 0 > Loading Environment from FAT... In: serial > Out: vidconsole > Err: vidconsole > Net: eth0: ethernet@7d580000 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: probe failed, error -110 > No working controllers found > Hit any key to stop autoboot: 0=20 > "Synchronous Abort" handler, esr 0x96000004 > elr: 000000000009c0c8 lr : 0000000000092194 (reloc) > elr: 000000003df790c8 lr : 000000003df6f194 > x0 : d519b040aa010000 x1 : 000000000000005c > x2 : 0000000000800000 x3 : 000000003dfd3670 > x4 : b900080152b00000 x5 : 000000000000005c > x6 : 000000003dfd3670 x7 : b900080152afff90 > x8 : 0000000000000000 x9 : 0000000000000008 > x10: 00000000ffffffd0 x11: 0000000000000006 > x12: 000000000001869f x13: 000000000000add8 > x14: 000000003db4ce38 x15: 0000000000000002 > x16: 0000000000004110 x17: 5497100900024000 > x18: 000000003db58d90 x19: 000000003dfd30b0 > x20: 0000000000000070 x21: 000000000000006d > x22: 000000000000000a x23: 0000000000000005 > x24: 000000003dfbf8ef x25: 000000003dfc7ad6 > x26: 0000000000000000 x27: 000000000000006d > x28: 000000003dfe4e94 x29: 000000003db4c100 >=20 > Code: eb03005f 54ffff43 f9400ca4 17ffffe0 (f9400404)=20 > Resetting CPU ... >=20 > resetting ... >=20 >=20 > Context details (booted using a variant of u-boot-rpi4 that > also respects armstub_rsrvd): >=20 > # uname -apKU > FreeBSD RPi4B 13.0-CURRENT FreeBSD 13.0-CURRENT #47 r368500M: Thu Dec = 10 03:15:10 PST 2020 = root@FBSDFHUGE:/usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch6= 4/sys/GENERIC-NODBG arm64 aarch64 1300131 1300131 >=20 > # svnlite info /usr/ports/ > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: svn://svn.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 558163 > Node Kind: directory > Schedule: normal > Last Changed Author: manu > Last Changed Rev: 558163 > Last Changed Date: 2020-12-15 07:07:07 -0800 (Tue, 15 Dec 2020) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6F62F9B6-9092-4833-A78B-477FBAB69D34>