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'm just downloading the Centos 7.2 aarch64 ISO, so more in a bit.
Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev