From owner-freebsd-arm@freebsd.org Tue Oct 9 03:31:44 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B661610BBF51 for ; Tue, 9 Oct 2018 03:31:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4077771F6F for ; Tue, 9 Oct 2018 03:31:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1KHL87YVM1k.X.Wep3CByqdbxxiZEn0ipyNpGObjTUweqHfTlGX748dvacOW6tK Bt7HNjpbnPp5ozNJ2fMYgkwPv05ksOOmbeiyyFVoirW.C_EqK_xM0e6NomNXj_SKjybJsmiAJJoJ pGaMXXnvSvvwG1nFeiua1nslsEe38FeUn5vlau5aCFsSQA6ZQinof7.kvpxUV_f.HDfCccqifUI1 ZDehMwEQwqoeWNqgs3qjn6m9lAFizrqSTKi6we1piW.iUSIT10UyWyEZsARDcG55h92c7RBTmA9I NbVlDHgEdPXajLnGjvloiG157KeTa0b3QufSd0NsJ..1AbXW5h9FyWVxvueRIt7wqeCP035AHvhK HWt2Xl87bHqqdVHYAkwS1Bs0BA6hl3Vhr6KyNYpENTgN_wQl2QqfzcnzT.FbnCp0.CrIzN7JizRf LgvgRucXmzzy2MqUyhHOJlo3.VThSLDef7He7guNwoH7r7Ayj.jO4bDMHu2jUi7MPpn1cL6G3mhq S2jGjzD0MOHz4Fctr3LRrLpRm1j3lPnMfcVr97LDRScY1vg7Oa6S5F.OSsIHLuX6PlngHlRvOoKy zMdtFr3FpU2Qqq8Do8mKWCrA56dQlt3WqoVEaevRMky5Ew6GdRRWkBlpET9qsWnRuf3LxTGoEGBf PIXmDUfa8.aBEWmG39ayfbbaEjBoGMAqXUzarc4LSJzaMm5SY7CVwPJjgjiNd0Jz9cycoXvwuNU. qtTb9RYor1M_OJmCW3nQ_BJooT0jLZjBQq43x_f0la0JFlB6KpaO8K3Txb99XsjkA.yAdhhui9JN kggBSLzJzReG8imHDMuHq_APeusI6f5a17B67x0olgVtOg8OFCIccOugIYPoxLn5J7BMytWftwiK 2OmMYm9KSlnfCyS6qySfKNudZdxtuxH34HlkMXLQ2px2GbSMsWtmwGP4AYVXU0fjiy.csjVIPEmY HrNBjNFG7PJkQgpnGLcMhCcvGAwYzpWUM9HDJp.47Bfl8i8J8HGKQIb2NIl9.Ul8zIBGpgLBFqdI AOYSY7PFuWpnWCaa0dDbPCyaNH3bw04HjEbjPw_tZPHd8X1rQGrrttdm2KL0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Oct 2018 03:31:37 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.101]) ([76.115.7.162]) by smtp418.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fb3614a4dbb1d0fb304f2be6d24ef3ef; Tue, 09 Oct 2018 03:31:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Question: How to boot FreeBSD head on a MACCHIATOBin (double shot)? From: Mark Millard In-Reply-To: <1539033028.40692.0@smtp.migadu.com> Date: Mon, 8 Oct 2018 20:31:36 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <1539023879.3199.0@smtp.migadu.com> <84911233-9535-4005-82DC-1910BC3BF101@yahoo.com> <1539033028.40692.0@smtp.migadu.com> To: Greg V X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 03:31:45 -0000 On 2018-Oct-8, at 2:10 PM, Greg V = wrote: > On Mon, Oct 8, 2018 at 10:54 PM, Mark Millard = wrote: >> On 2018-Oct-8, at 11:37 AM, Greg V = wrote: >>> On Mon, Oct 8, 2018 at 1:05 AM, Mark Millard via freebsd-arm = 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. >>> =46rom 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=3DUse+SATA+drives+in+U-Bo= ot >> 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 =3D 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 [fdt address] >> - boot EFI payload stored at address . >> If specified, the device tree located at gets >> exposed as EFI configuration table. >> I interpreted this as a lack of direct use of on-media EFI >> material being supported. >=20 > I agree with the EDK2 recommendation, but in case you (or anyone = reading the list) want to do in in U-Boot: >=20 > U-Boot is rather low level, nothing is direct :) > You have to take two steps =E2=80=94 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.) >=20 > There are usually suggested addresses exposed as variables like = kernel_addr_r and fdt_addr_r. >=20 > For example, I boot most of my SBCs over the network with a script = like this: >=20 > env set serverip 192.168.1.2 > env set baudrate 15000000 > env set bootargs boot.nfsroot.server=3D${serverip} = boot.nfsroot.path=3D/solitude-tank/greg/Netboot/ROCKPro64 = 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} >=20 > 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@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 =3D -2 Marvell>>=20 So the loads are changing the behavior. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)