Question: How to boot FreeBSD head on a MACCHIATOBin (double shot)?

[Greg V]

On Mon, Oct 8, 2018 at 10:54 PM, Mark Millard <marklmi at yahoo.com> wrote:
> On 2018-Oct-8, at 11:37 AM, Greg V <greg at unrelenting.technology> 
> wrote:
> 
>>  On Mon, Oct 8, 2018 at 1:05 AM, Mark Millard via freebsd-arm 
>> <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.
>> 
>>  From what I remember on this mailing list, PCIe and Ethernet won't 
>> work.
>> 
>>  (BTW, OpenBSD does have a PCIe driver for it already... and for the 
>> Rockchip RK3399 too... dang)
>> 
>>>  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.
>> 
>>  According to their wiki, SATA is supported in U-Boot:
>>  
>> http://wiki.macchiatobin.net/tiki-index.php?page=Use+SATA+drives+in+U-Boot
> 
> Various details do not seem to match, such as the 1, 8, 9
> device numbering for SATA (scsi) vs.:
> 
> 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 = 953.8 GB (2000409264 x 512)
> 
> 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.
> 
>>  You should be able to just load and run loader.efi from the drive's 
>> EFI System Partition.
> 
> The help at the Marvell>> prompt mentioned EFI once:
> 
> bootefi - Boots an EFI payload from memory
> 
> with the longer description being:
> 
> 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.
> 
> 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 
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 — first load the EFI file from a 
filesystem (or network, or whatever) into some address in memory, then 
bootefi that address.
(Also load the FDT file using the same mechanism.)
Look up the fatload command for the FAT filesystem (which includes EFI 
System Partitions.)

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

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

env set serverip 192.168.1.2
env set baudrate 15000000
env set bootargs boot.nfsroot.server=${serverip} 
boot.nfsroot.path=/solitude-tank/greg/Netboot/ROCKPro64 
comconsole_speed=${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' 
(or load for any file system really).