Date: Sun, 1 Dec 2019 11:46:54 -0800 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, "mw@semihalf.com" <mw@semihalf.com> Subject: Re: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 Message-ID: <32A4EC20-53AA-4985-BD93-34DA5FC270E8@yahoo.com> In-Reply-To: <ydCU-MIAsoAlrNW81KZUmAahyQsWbeD49hg2MbS03xvqqZ8eDljPVRb_8aHGpGdBDbvwosY_ABZgcVzB1RyC903KD9RuyXMUybaRVK7NWcw=@protonmail.com> References: <C5CAD1EC-52E0-4952-87DA-D6E0F20EB7EA.ref@yahoo.com> <C5CAD1EC-52E0-4952-87DA-D6E0F20EB7EA@yahoo.com> <ydCU-MIAsoAlrNW81KZUmAahyQsWbeD49hg2MbS03xvqqZ8eDljPVRb_8aHGpGdBDbvwosY_ABZgcVzB1RyC903KD9RuyXMUybaRVK7NWcw=@protonmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2019-Dec-1, at 06:53, Robert Crowston <crowston at protonmail.com> = wrote: > Given your hang happens before "--<BOOT>--" is written to the console, = it seems like a problem in stand. (mountroot etc is a distraction; that = happens towards the end of the boot process.) The mountroot material from when the kernel got that far was from the old version of FreeBSD. What changed was the FreeBSD materials being updated. A mismatch between the more modern FreeBSD and the dtb content it is set up to deal with vs. what is provided for the dtb is a possibility. >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by EFI at 0xbe844018. >=20 > I would try using a different dtb instead of the one u-boot is = providing. >=20 Note that edk2 is for UEFI. It is configurable for if it hands over a dtb vs. ACPI information. Trying ACPI just got a report of the dtb being missing. So I continued with the dtb option. Both before and after updating the FreeBSD version involved reported the same dtb line, with the address matching: Using DTB provided by EFI at 0xbe844018 As far as I can tell the dtb did not vary except when I tried other ones: I built and tried -r355027 's materials and tried another old one that I had around. I'm not sure where another appropriate one might be. Of course, when I tried the older edk2 (18.09.4) = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/files= /flash-image-18.09.4.bin the reported address was different --and likely the older content might have been somewhat different for the dtb. So I've tried 3-4 dtb's so far. > At the boot loader "OK" prompt, you can change the DTB. You can even = try to pass in the one you think u-boot is giving you, in case it is = passing the wrong address to the bootloader. Something like (I don't = remember exactly): >=20 > OK load /path/to/kernel > OK load -t dtb /path/to/dtb > OK boot Yep. But, so far, I've not found one that gets any farther along in the serial output with head -r355027 . > You can also enable verbose boot, which might show a tiny little more = detail before the hang, but since we don't get to --<BOOT>--, I am not = optimistic. boot -v displayed nothing extra. (It is one of the things I'd tried in order to get information but produced nothing to report.) > btw, if you are a programmer, these problems are much easier to = diagnose with a JTAG, which can be as cheap as 20 USD. JTAG is not something I've ever used. (Accident of my history.) I made need to. What I'm thinking of doing next is trying different kernels (and possibly loaders) from artifacts.ci.freebsd.org . (Avoiding needing to build them, plus they are debug builds, in case that helps figure things out.) First I'd likely confirm that reverting to somewhere around 339076 repeats what I originally got. (I may have to replace the -r355027 world with an old one so the time relationship to the kernel is right if it looks like I want try beyond mountroot at some point.) Thanks for the notes. [Nothing more added below.] > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 = Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2= =80=90 > On Sunday, 1 December 2019 10:21, Mark Millard via freebsd-arm = <freebsd-arm@freebsd.org> wrote: >=20 >> I tried to get a MACCHIATObin Double Shot Rev 1.3 to boot -r355027 >> (a non-debug build). The first (partial) result based on older >> materials made me hopeful, but trying more modern materials did not >> get as far. >>=20 >> I started from old media that I happened to have around from last = time >> I'd had access and tried to boot the MACCHIATObin and got to (showing >> the old vintage as well): >>=20 >> . . . >> FreeBSD 12.0-ALPHA8 #3 r339076M: Thu Oct 4 14:24:26 PDT 2018 >> = markmi@FBSDUSSD:/usr/obj/cortexA57_clang/arm64.aarch64/usr/src/arm64.aarch= 64/sys/GENERIC-NODBG arm64 >> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on = LLVM 6.0.1) >> . . . >> Release APs...done >> Trying to mount root from ufs:/dev/gpt/FBSDCA57root [rw]... >>=20 >> The /etc/fstab was wrong and I knew it would be. This was a quick = test before >> updating to more modern content that I was actually interested in. / = for all >> this was (and is) on a Samsung SATA SSD. >>=20 >> I got here via using a UEFI image from: >>=20 >> = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/Binar= ies/ >>=20 >> specifically using: >>=20 >> = https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/files= /flash-image-mcbin-mainline-r20190509.bin >>=20 >> on uSD media via (on another FreeBSD machine): >>=20 >> dd if=3D/root/flash-image-mcbin-mainline-r20190509.bin bs=3D512 = seek=3D1 of=3D/dev/da3 conv=3Dsync >>=20 >> I had set the jumpers to have the MACCHIATObin use the uSD media = instead >> of spi content. (That is also how I booted Arch Linux ARM from uSD = media >> so it was already set up that way.) >>=20 >> After getting this far I updated to having head -r355027 on the SATA >> SSD (matching other context I have around) and copied over the modern >> loader.efi to replace the old efi file. >>=20 >> Having done this I only get as far as: >>=20 >> . . . >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by EFI at 0xbe844018. >>=20 >> A "|" or "/" sometimes shows up on the next line but it does not >> show the typical sequence of symbols and there is no more evidence >> of progress. The text is seen via the serial console. >>=20 >> I've hypothesized bunches of things that might make a difference, >> none have. I tried putting back the old .efi file. I tried building >> the .dtb from the -r355027 materials and forcing that to be loaded. >> (Each failing alternative was reverted as I went along.) I tried >> an old .dtb file that I had around. I tried the 18.09.4 .bin file >> on the uSD media. I tried various ways of specifying were / was >> supposed to be from. I tried with and without: >>=20 >> kern.cam.boot_delay=3D10000 >> vfs.mountroot.timeout=3D10 >>=20 >> I did notice one distinction for before vs. after the -r35027 >> update. Before the update always got: >>=20 >> loaddev=3Ddisk0p2: >>=20 >> After the update always got: >>=20 >> loaddev=3Ddisk0p1: >>=20 >> disk0p1 has the efi file system; disk0p2 has the ufs file system. >>=20 >> By contrast, currdev got "disk0p2:" in both contexts. >>=20 >> (Side note: I last tried to boot this board with FreeBSD was over >> a year ago but ended up redirected and without access until >> recently. Marcin had tried to help me back then. I'm not sure >> how long I'll have access this round.) >>=20 >>=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?32A4EC20-53AA-4985-BD93-34DA5FC270E8>