Date: Sun, 1 Dec 2019 02:21:24 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm@freebsd.org Cc: mw@semihalf.com Subject: Problems booting a MACCHIATObin Double Shot Rev 1.3 with head -r335027 Message-ID: <C5CAD1EC-52E0-4952-87DA-D6E0F20EB7EA@yahoo.com> References: <C5CAD1EC-52E0-4952-87DA-D6E0F20EB7EA.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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):
. . .
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]...
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.
I got here via using a UEFI image from:
=
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/Binar=
ies/
specifically using:
=
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/wiki/files=
/flash-image-mcbin-mainline-r20190509.bin
on uSD media via (on another FreeBSD machine):
dd if=3D/root/flash-image-mcbin-mainline-r20190509.bin bs=3D512 seek=3D1 =
of=3D/dev/da3 conv=3Dsync
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.)
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.
Having done this I only get as far as:
. . .
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB provided by EFI at 0xbe844018.
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.
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:
kern.cam.boot_delay=3D10000
vfs.mountroot.timeout=3D10
I did notice one distinction for before vs. after the -r35027
update. Before the update always got:
loaddev=3Ddisk0p2:
After the update always got:
loaddev=3Ddisk0p1:
disk0p1 has the efi file system; disk0p2 has the ufs file system.
By contrast, currdev got "disk0p2:" in both contexts.
(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.)
=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?C5CAD1EC-52E0-4952-87DA-D6E0F20EB7EA>