CuBox GeexBox doesn’t load driver for eSATA

[b01Member]

How can I get GeeXBoX to detect and load partitions on an HDD connected to the eSATA port?

I’m trying to boot GeeXBoX from eSATA (SSD drive). However, it appears that GeeXboX does not load the “Marvell Serial ATA Adapter” on the CuBox. I can see that it loads a lot of the other devices, just not the SATA Adapter, and port.

[Warped RudiMember]

Could it be that you are using version 3.0 ? If so, please try a more recent snapshot.

[b01Member]

Those are more recent versions, I will give them a try.

I can’t be sure of which version I have all I can see is the date it was built: Welcome to GeeXboX arm devel-20130717-r16287 (C) 2002-2013

So it looks like I on an old version, I’m not sure how I can tell what version it is.

Also, here’s a pastebin of my output: Cubox – GeeXboX output

I can see at some point it loads an ATA device controller later on, but after it checks devices for boot partitions.

• This reply was modified 1 week, 2 days ago by b01.
• This reply was modified 1 week, 2 days ago by b01.
• This reply was modified 1 week, 2 days ago by b01.

[Warped RudiMember]

Your version is fairly recent. So no need to update. I don’t know if anyone has ever tried booting from SATA, but from your log I see that you have a bootable MMC inserted. This will actually prevent booting from the harddrive, since the sequence is USB -> MMC -> SATA. IOW, if a “boot.scr” is found on MMC, we expect kernel image and root file system to be on MMC as well and we don’t look at SATA at all. Assuming that your SSD caries a valid root file system (including /boot), you can try to remove the SD card and see what happens…

[b01Member]

Sorry, but that log is from loading from the microSD card. I was in a hurry this morning and that was the only log I had. I will post an updated log later on showing the error. I am also aware of the boot order (USB, mmc, eSATA, Network), and have tried to boot with eSATA drive connected and no microSD inserted in the CuBox.

I’m starting to think no one has booted GeeXboX from eSATA on the CuBox. It will be interesting to see if an I can, and if it speeds boot time up a bit.

I’m so close, don’t want to give up now.

• This reply was modified 1 week, 2 days ago by b01.

[b01Member]

Here is a log of trying to boot to eSATA on CuBox and failing: CuBox no eSATA

You can see that GeeXboX can find the CuBox internal flash and my USB stick, but not the eSATA drive I have plugged in (yes I have Power to the SATA drive).

• This reply was modified 1 week, 1 day ago by b01.

[Warped RudiMember]

VFS: Cannot open root device “sdb1″ or unknown-block(0,0): error -6
Please append a correct “root=” boot option; here are the available partitions:
1f00 4096 mtdblock0 (driver?)
0800 1956832 sda driver: sd
0801 1956800 sda1 00000000-0000-0000-0000-000000000000

Ahh. It “thinks” that the root file system is “sdb1″ while in reality it is “sda1″. ISTR, that a (much) older version of our “boot.scr” did that. You could try “boot.scr” from a more recent version…

[Warped RudiMember]

Looking a bit closer at the logs I see this:

SD card boot:

Loading file “/boot/boot.scr” from mmc device 0:1 mmcda1
1331 bytes read

eSATA boot:

Loading file “/boot/boot.scr” from ide device 0:1 hda1
304 bytes read

Clearly “boot.scr” is different. The 1331-bytes-version is our default one. It is supposed to be usable unchanged on all devices. So the simplest thing for you would be to copy “/boot/boot*” from the SD card to your harddrive and try again.

BTW, I don’t expect a big boot speedup. There is a lot of time wasted in u-boot itself. But that is probably due to the software structure. A good starting point would be to do the USB/MMC/IDE reset and rescan (including ‘waiting for storage devices to settle”) during the time while we are waiting for possible user input to abort boot anyway. Also the number of messages sent to the terminal while searching “boot.cfg” should be reduced. Not only that it is confusing, it also wastes time. The same is true for kernel messages.

[b01Member]

Yes, I made my own boot.scr and replaced the boot.scr that came with GeeXboX. The reason is because when I first installed GeeXboX and restarted the CuBox, it would not load and I would be sitting there staring at a black screen.

But I will restore the one that came with GeeXboX and see what happens in the serial console.

Also, I made a USB boot.scr and connected the SSD drive with a USB cabled to port-0:1 and it loaded just fine. And you are right, boot was not faster nor was the FPS (currently I only get 24fps).

[b01Member]

OK, putting the boot.scr back works fine, but the boot.scr is not the problem, it’s after the uImage successfully loads is when I get the Kernel Panic. Which is because the SATA drive is not detect. The CuBox detects the drive fine, but GeeXboX does not.

My theory is that GeeXboX never loads a driver for the Marvell SATA Adapter, and then properly detects any devices connected to the eSATA port, and thus cannot find it’s partitions.

If I switch to USB, the very same drive and install of GeeXboX works fine.

I want to know how can I get GeeXboX to load the driver for the CuBox SATA controller before the Kernel panic happens?

[Warped RudiMember]

it’s after the uImage successfully loads is when I get the Kernel Panic.

Log ?

My theory is that GeeXboX never loads a driver for the Marvell SATA Adapter, and then properly detects any devices connected to the eSATA port

How would it properly detect devices without loading the adapter driver ? BTW, the SATA driver is compiled into the kernel. So there is a fat chance, that it is there.

I have ordered an eSATA adapter. Wanted to try an external disk anyway… Maybe I’ll have a look into that when it arrives.

In the mean while: what might be worth a try is to add the parameter “rootwait” or “rootdelay=X” (X=10..60) to the kernel command line.

[b01Member]

Maybe I’m using the wrong terminology here, what I mean is that the “/boot/uImage” on ide 0:1 starts to load, this is being initiated on line 208 of CuBox no eSata log. I assume at this point that GeeXboX is now in control (see line 226).

It’s not until later, at line 450 in the log, that the rootfs cannot be found.

VFS: Cannot open root device “sdb1″ or unknown-block(0,0): error -6

Causing a kernel panic (see line 455 in the log) and bringing the system to a halt.

So if the SATA adapter driver is in the Kernel, why is it not loaded before trying to find the rootfs? All of the other hard ware drivers are loaded, and the devices are detected properly (can also be seen in the log). However, you will not see where the SATA adapter and the drive connected to the sata port is detected before the Kernel panic.

• This reply was modified 6 days, 21 hours ago by b01.
• This reply was modified 6 days, 21 hours ago by b01.

[Warped RudiMember]

Maybe I’m using the wrong terminology here, what I mean is that the “/boot/uImage” on ide 0:1 starts to load, this is being initiated on line 208 of CuBox no eSata log.

That is the boot loader (i.e. ‘Das U-Boot’).

I assume at this point that GeeXboX is now in control (see line 226).

That is the Linux kernel. I would not call it GeeXboX.

So if the SATA adapter driver is in the Kernel, why is it not loaded before trying to find the rootfs?

Good question. I got a bit confused by the logs you posted. The first log a kernel built on Wed Jul 17 08:36:28 is used. This should be r16287. It shows some messages from the SATA driver. Even though rather late in the boot process. That is well after the rootfs is mounted.
In the second log, the kernel is dated Sat Aug 3 15:43:37, which should be r16298. Here we see no messages from SATA. But (probably to confuse me even a litte bit more) there was a non-bootable USB stick attached…
Our commit logs don’t indicate any modifications regarding SATA between r16287 and r16298. Thus these kernels should behave identical. Even though it would be better to test the very same version.

Now I see two possible explanations for the behavior we are seeing:

1.) The SATA driver needs some time to be able to access the drive. That is the reason why the kernel parameter “rootwait” exists. And in order to minimize other side effects, I suggest to start with only the harddrive attached and nothing in SD slot or on USB port.
2.) After loading the kernel, u-boot leaves the controller in a state that causes the SATA driver not to detect the hardware. If that is the case, either u-boot or sata_mv will need some fixing.

[Warped RudiMember]

I gave the latest snapshot (r16329) a try and it booted right away from my Samsung 830. Note that we switched kernels from 3.5.7 to 3.6.9 between the version you tested and this one. However, I’m not convinced that it’s the reason… The default “boot.scr” requires the root file system to be on the first partition of the hard drive and to be formatted as ext4.

BTW, the boot process is indeed a little bit faster than using an SD card . But not dramatically.

[Author]

Posts