On 12/03/16 15:52, Jeremiah Rothschild wrote: > On Sat, Mar 12, 2016 at 10:10:45AM +0000, Gordan Bobic wrote: >> On 11/03/16 22:51, Jeremiah Rothschild wrote: >>> On Fri, Mar 11, 2016 at 08:02:40PM +0000, Gordan Bobic wrote: >>>> On 11/03/16 17:56, Jeremiah Rothschild wrote: >>>>> On Fri, Mar 11, 2016 at 05:03:46PM +0000, Michael Howard wrote: >>>>>> >>>>>> >>>>>> On 11/03/2016 16:45, Richard W.M. Jones wrote: >>>>>>> On Fri, Mar 11, 2016 at 10:31:20AM +0000, Michael Howard wrote: >>>>>>>> 5 seconds only to be precise, at least on my board :) >>>>>>> I found TFTP to be slower and more unreliable than that. However my >>>>>>> TFTP server is dnsmasq running on an old box, >>>>>> >>>>>> That could be the reason then. Sdcards are painfully slow so you get >>>>>> what you pay for metaphorically speaking. No big deal either way I >>>>>> guess but I much prefer tftp here on a completely 1Gb network and a >>>>>> tftp server on a 24/7 Xenserver VM. >>>>> >>>>> Both methods are a little unorthodox - at least in my experience. >>>> >>>> In the ARM world, booting the kernel straight out of u-boot is the >>>> norm. It is how the boot process works on the vast majority of ARM >>>> devices. It is loading UEFI at all that is unorthodox. UEFI and BIOS >>>> before it are very much x86-isms. >>> >>> To clarify, it's the SD/TFTP booting that I find unorthodox for a >>> functional, disk having server. I know there are many use cases but, >>> personally, as a sys admin, I'd typically only go down that route for >>> operations like kickstart, rescue, etc. >>> >>>>> Is there >>>>> a spinning disk based solution perhaps, too? I would imagine the chain >>>>> could be loaded from any storage resource. Can it be hacked onto an extra >>>>> OS drive partition or something? >>>> >>>> UEFI requires a FAT partition anyway that you could also use for >>>> this. >>> >>> Nod. I do have the /boot/efi partition. Further leveraging it, or another >>> partition, would be sweet. >>> >>>> The main question is whether u-boot that ships with this board >>>> actually supports SATA. If it does it would be trivially easy to >>>> make that work. Ask me again in 48 hours and I'll be able to tell >>>> you whether that works on this particular Gigabyte board. :) >>> >>> Interesting. I'm new to U-Boot but it never occurred to me that it wouldn't >>> detect all of my devices. That said, I have 2x SSD's in here yet: >>> >>> MP30AR0# scsi info >>> SCSI dev. 0: device type unknown >>> SCSI dev. 1: device type unknown >>> SCSI dev. 2: device type unknown >>> SCSI dev. 3: device type unknown >>> SCSI dev. 4: device type unknown >>> SCSI dev. 5: device type unknown >> >> 6 devices? There are only 4 SATA connectors on the motherboard. I >> connected a single SATA device (just a normal 250GB SATA disk) and >> it seems to have detected that fine, and can read partitions and >> ext4 contents (ext4ls scsi 0:1) from it. > > Seems I had to first issue the `scsi init' command: > > MP30AR0# scsi init > SATA1 link 0 timeout. > No drive connected > SATA1 link 1 timeout. > No drive connected > AHCI1 0001.0300 32 slots 2 ports 6 Gbps 0x3 impl SATA mode > flags: 64bit ncq pm only pmp fbss pio slum part ccc > Target spinup toTarget spinup took 0 ms. > AHCI2 0001.0300 32 slots 2 ports 6 Gbps 0x3 impl SATA mode > flags: 64bit ncq pm only pmp fbss pio slum part ccc > scanning bus for devices... > Device 0: (4:0) Vendor: ATA Prod.: CT240BX200SSD1 Rev: MU01 > Type: Hard Disk > Capacity: 228936.5 MB = 223.5 GB (468862128 x 512) > Device 1: (5:0) Vendor: ATA Prod.: CT240BX200SSD1 Rev: MU01 > Type: Hard Disk > Capacity: 228936.5 MB = 223.5 GB (468862128 x 512) > Found 2 device(s). > > MP30AR0# scsi info > SCSI dev. 0: (4:0) Vendor: ATA Prod.: CT240BX200SSD1 Rev: MU01 > Type: Hard Disk > Capacity: 228936.5 MB = 223.5 GB (468862128 x 512) > SCSI dev. 1: (5:0) Vendor: ATA Prod.: CT240BX200SSD1 Rev: MU01 > Type: Hard Disk > Capacity: 228936.5 MB = 223.5 GB (468862128 x 512) > > Should be fairly smooth sailing from here, I think/hope. I just tried it. Simply copy the two .fd files from the USB stick to /boot/efi, and change the u-boot variable thusly: MP30AR0# setenv load_tianocore ' scsi init; fatload scsi 0:1 0x82000000 mp30ar0_tianocore_ubt.fd; fatload scsi 0:1 0x1d000000 mp30ar0_tianocore_sec_ubt.fd;' At this point I think we are also ready to make the UEFI boot the default action, so: MP30AR0# setenv bootcmd 'run load_tianocore run_tianocore' MP30AR0# save MP30AR0# reset Enjoy. :) Gordan