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
Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev