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 at centos.org
> https://lists.centos.org/mailman/listinfo/arm-dev