Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 09 Oct 2018 00:10:28 +0300
From:      Greg V <greg@unrelenting.technology>
To:        Mark Millard <marklmi@yahoo.com>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: Question: How to boot FreeBSD head on a MACCHIATOBin (double shot)?
Message-ID:  <1539033028.40692.0@smtp.migadu.com>
In-Reply-To: <84911233-9535-4005-82DC-1910BC3BF101@yahoo.com>
References:  <BA84F14D-A7D6-45C6-B97B-79F6F02EA009@yahoo.com> <1539023879.3199.0@smtp.migadu.com> <84911233-9535-4005-82DC-1910BC3BF101@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Mon, Oct 8, 2018 at 10:54 PM, Mark Millard <marklmi@yahoo.com> wrote:
> On 2018-Oct-8, at 11:37 AM, Greg V <greg at unrelenting.technology>=20
> wrote:
>=20
>>  On Mon, Oct 8, 2018 at 1:05 AM, Mark Millard via freebsd-arm=20
>> <freebsd-arm at freebsd.org> wrote:
>>>  Anyone willing to provide notes or instructions
>>>  for setting up a MACCHIATOBin (double shot) to boot
>>>  FreeBSD head from a SATA SSD? (Failing that: a USB
>>>  storage device?) (Failing that: microsd card?)
>>>  This could well include notes/instructions about
>>>  what needs to be on the media that may be unique
>>>  to the MACCHIATOBin. I realize that various things
>>>  will not work yet. I'd just explore some of what
>>>  does work.
>>=20
>>  From what I remember on this mailing list, PCIe and Ethernet won't=20
>> work.
>>=20
>>  (BTW, OpenBSD does have a PCIe driver for it already... and for the=20
>> Rockchip RK3399 too... dang)
>>=20
>>>  Needing to have the kernel and earlier stages
>>>  and a preliminary /etc/fstab and /boot/loader.conf
>>>  on an microsd card but getting the UFS file system
>>>  (/) from the SATA SSD is likely a workable combination,
>>>  similar to what I've sometimes done on smaller
>>>  single board computers. For such, it is the kernel
>>>  and earlier stages where I'm unclear on the details
>>>  for the MACCHIATOBin double shot.
>>=20
>>  According to their wiki, SATA is supported in U-Boot:
>> =20
>> http://wiki.macchiatobin.net/tiki-index.php?page=3DUse+SATA+drives+in+U-=
Boot
>=20
> Various details do not seem to match, such as the 1, 8, 9
> device numbering for SATA (scsi) vs.:
>=20
> Marvell>> scsi scan
> scanning bus for devices...
> SATA link 0 timeout.
> SATA link 1 timeout.
> AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
> flags: 64bit ncq led only pmp fbss pio slum part sxs
> Target spinup took 0 ms.
> SATA link 1 timeout.
> AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
> flags: 64bit ncq led only pmp fbss pio slum part sxs
>   Device 0: (0:0) Vendor: ATA Prod.: Samsung SSD 850 Rev: EXM0
>             Type: Hard Disk
>             Capacity: 976762.3 MB =3D 953.8 GB (2000409264 x 512)
>=20
> The text seem to be for some older version of the board
> and/or firmware: the picture and description of the
> SATA connector position numbering is for an older board.
>=20
>>  You should be able to just load and run loader.efi from the drive's=20
>> EFI System Partition.
>=20
> The help at the Marvell>> prompt mentioned EFI once:
>=20
> bootefi - Boots an EFI payload from memory
>=20
> with the longer description being:
>=20
> bootefi <image address> [fdt address]
>   - boot EFI payload stored at address <image address>.
>     If specified, the device tree located at <fdt address> gets
>     exposed as EFI configuration table.
>=20
> I interpreted this as a lack of direct use of on-media EFI
> material being supported.

I agree with the EDK2 recommendation, but in case you (or anyone=20
reading the list) want to do in in U-Boot:

U-Boot is rather low level, nothing is direct :)
You have to take two steps =97 first load the EFI file from a=20
filesystem (or network, or whatever) into some address in memory, then=20
bootefi that address.
(Also load the FDT file using the same mechanism.)
Look up the fatload command for the FAT filesystem (which includes EFI=20
System Partitions.)

There are usually suggested addresses exposed as variables like=20
kernel_addr_r and fdt_addr_r.

For example, I boot most of my SBCs over the network with a script like=20
this:

env set serverip 192.168.1.2
env set baudrate 15000000
env set bootargs boot.nfsroot.server=3D${serverip}=20
boot.nfsroot.path=3D/solitude-tank/greg/Netboot/ROCKPro64=20
comconsole_speed=3D${baudrate}
tftpboot ${kernel_addr_r} loader.efi
tftpboot ${fdt_addr_r} dtb/rockchip/rk3399-rockpro64.dtb
bootefi ${kernel_addr_r} ${fdt_addr_r}

In the local storage case, instead of 'tftpboot' you'd use 'fatload'=20
(or load for any file system really).
=




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1539033028.40692.0>