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

Tue Oct 9 03:31:45 UTC 2018

On 2018-Oct-8, at 2:10 PM, Greg V <greg at unrelenting.technology> wrote:

> 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).

I took the .dtb from the linux boot media and put a copy
in the fat file system tied to the FreeBSD media. The
.efi is a copy of one that boots another arm FreeBSD
system and was already in place.

I tried fatload for each ( using $kernel_addr then $fdt_addr )
and end up with:

QUOTE
Marvell>> bootefi $kernel_addr $fdt_addr
## Starting EFI application at 05000000 ...
Scanning disk sdhci at 6e0000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 26
Found 1 disks
"Synchronous Abort" handler, esr 0x96000045
ELR:     7ff7f260
LR:      7ff79bb0
x0 : 00000000bffff000 x1 : 0000000000000000
x2 : 000000000000001f x3 : 0000000000000000
x4 : 0000000000000018 x5 : 0000000000000000
x6 : 0000000000000003 x7 : 0000000000000001
x8 : 000000007ff9f748 x9 : 0000000000000008
x10: 0000000000000001 x11: 0000000000000006
x12: 00000000ffffffff x13: 00000000ffffffff
x14: 000000007f70f40c x15: 0000000008000000
x16: 000000007ff9c594 x17: 000000007ff9c594
x18: 000000007f716d18 x19: 00000000bffff000
x20: 000000007ff9d530 x21: 0000000008000fff
x22: 000000007ffa5a30 x23: 000000007ffb26b4
x24: 000000007f70f4f0 x25: 000000007ff8a000
x26: 000000007ff9d530 x27: 000000007e6fade8
x28: 0000000000000000 x29: 000000007f70f490

Resetting CPU ...
END QUOTE

for anything that I've tried for env set bootargs.

By contrast, just after power up, no fatload
use or other such, produced:

Marvell>> bootefi $kernel_addr $fdt_addr
## Starting EFI application at 05000000 ...
WARNING: Invalid device tree, expect boot to fail
efi_load_pe: Invalid DOS Signature
## Application terminated, r = -2
Marvell>> 

So the loads are changing the behavior.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)