|
21
on: May 25, 2013, 04:18:30 AM
|
||
| Started by NewIT - Last post by NewIT | ||
|
We have a new shop, come and take a look
|
||
|
22
on: May 18, 2013, 08:18:39 PM
|
||
| Started by cbxbiker61 - Last post by spinifex | ||
|
We have 3 (or is it 4) versions of Dreamplug and I think they have different flash memory, yet we have one DTS for the Dreamplug. Does anyone know which models work with the mainline Dreamplug kernel ?
|
||
|
23
on: May 16, 2013, 01:30:55 AM
|
||
| Started by cbxbiker61 - Last post by apemberton | ||
|
@cbxbiker, Yes, of course, you are right as I now see. I should have thought a bit longer as booting the kernel halted after loading it and never got to do anything after. Silly really.
I have now loaded your 3.9.2 kernels for an eSata and a SDHC based Sheevaplugs and they work. It still seems a shame that different .dtb files are needed depending on whether a disk or SDHC is used to boot from. Despite these working, I will still try rolling my own so I understand what is going on - plus I will need bit bashed 1-Wire on my Guruplugs in the not too far distant future. A nice, easy to read tutorial on .dtb would be welcome (though I havn't looked at the devicetree.org site lately). Onward and upward! |
||
|
24
on: May 15, 2013, 07:00:43 PM
|
||
| Started by cbxbiker61 - Last post by cbxbiker61 | ||
|
Well I tried the precompiled 3.9.2 kernel on my compiler/test eSata Sheevaplug using the script but my system did not boot. It loaded the uImage but then failed to load. I am pretty sure that the problem is that I am using EXT4 on root (/dev/sda1) and by default, I see that EXT4 is not set up either as a module or builtin. Therefore, I am starting to build a 3.9.2 kernel with Device Tree from scratch! Its edukayshun innit! I'm not sure what you're looking at...but it's not the config I'm using, which has always had EXT4 built-in. |
||
|
25
on: May 15, 2013, 10:38:12 AM
|
||
| Started by cbxbiker61 - Last post by apemberton | ||
|
Well I tried the precompiled 3.9.2 kernel on my compiler/test eSata Sheevaplug using the script but my system did not boot. It loaded the uImage but then failed to load. I am pretty sure that the problem is that I am using EXT4 on root (/dev/sda1) and by default, I see that EXT4 is not set up either as a module or builtin.
Therefore, I am starting to build a 3.9.2 kernel with Device Tree from scratch! Its edukayshun innit! |
||
|
26
on: May 15, 2013, 04:51:25 AM
|
||
| Started by cbxbiker61 - Last post by apemberton | ||
|
@cbxbiker Many thanks for that.
 I'll have a tinker later when I get a couple of hours.I had a look at your site and see there are many patches that I had not seen previously so there is some 'reading' I have to do. Keep up the good work! I still need to get to grips with Device Trees for my own satisfaction (its the old geek in me I guess) and other embedded hardware I wish to develop. |
||
|
27
on: May 14, 2013, 04:04:23 PM
|
||
| Started by cbxbiker61 - Last post by cbxbiker61 | ||
|
Yes the same uImage. I really do not want to use different kernel variants for my Sheevaplugs depending on the type of storage used. The built xilka kernels (at least the last time I looked at the xilka .config files) still treated eSata as a module and thus would not boot from disk as I want. Although I havn't checked yet, yes, I think my problem is use of .dtb (flattened device tree) files for hardware in the new kernel. Taking the .config (/proc/config.gz) file from an older kernel, not using fdt, will try and use the old style hardware setup. As the SDIO is (I think) now set up in fdt, there plainly is an incompatability. With eSata, it does not seem to matter. Obviously this is something I will have to check. As I also want to get newer kernels for Tonidoplug2 (Topkick) and previously had no success with the fdt version, I will have to see how these work in 3.9+. I will also try and understand the use of fdt in u-boot and kernel as documentation is a bit scattered in my opinion. I've just updated 3.9.2 to build sata_mv into the kernel, this should work fine for sheevaplug-esata boot from sata. The main reason that I didn't build sata_mv into the kernel before was that the standard sheeva's were hanging on boot due to missing sata hardware. That should no longer be the case with .dtb kernels. |
||
|
28
on: May 14, 2013, 01:33:08 AM
|
||
| Started by cbxbiker61 - Last post by apemberton | ||
|
Yes the same uImage. I really do not want to use different kernel variants for my Sheevaplugs depending on the type of storage used. The built xilka kernels (at least the last time I looked at the xilka .config files) still treated eSata as a module and thus would not boot from disk as I want.
Although I havn't checked yet, yes, I think my problem is use of .dtb (flattened device tree) files for hardware in the new kernel. Taking the .config (/proc/config.gz) file from an older kernel, not using fdt, will try and use the old style hardware setup. As the SDIO is (I think) now set up in fdt, there plainly is an incompatability. With eSata, it does not seem to matter. Obviously this is something I will have to check. As I also want to get newer kernels for Tonidoplug2 (Topkick) and previously had no success with the fdt version, I will have to see how these work in 3.9+. I will also try and understand the use of fdt in u-boot and kernel as documentation is a bit scattered in my opinion. |
||
|
29
on: May 13, 2013, 10:00:29 AM
|
||
| Started by cbxbiker61 - Last post by cbxbiker61 | ||
|
I have also compiled 3.9.1 for my sheevaplugs with mixed results. Three of my Sheevaplugs use eSata to boot from and 3.9.1 works fine. However I tried the same kernel on a SD card based Sheevaplug and that failed when setting up the sdio subsytem. If I had known, I should have saved the console output but I needed to return the 'plug to service ASAP so reverted to an older kernel. I did notice that the console output differed around the sdio setup between 3.6.10 and 3.9.1. I am using a newer u-boot (2012-??) than stock. I don't think Sheevaplugs use flattened device tree yet (though it seems that Guruplugs may do so). I used the cbxbiker patches (3) and used 'make oldconfig' taking the current '/proc/config.gz' as a base. So from my limited knowledge, I would say there is a problem with the Marvell sdio in the 3.9+ kernels and looking at the kernel changelogs, plainly there are changes afoot in that area. I think someone has to get the right combination of configuration, modules and possibly code changes in the sdio area to get Sheevaplugs working with 3.9+ kernels. You're using the kernel's on e-SATA plugs and I'm using them on the original Sheevaplug (booting from SD), so it appears that they work on both. When you say using the "same" kernel, do you mean the same uImage? If so that would be the wrong thing to do. The uImage is a merged common zImage with the appropriate .dtb appended. The .dtb is what differentiates the different models (see UPDATE-KERNEL.sh). |
||
|
30
on: May 13, 2013, 01:34:35 AM
|
||
| Started by cbxbiker61 - Last post by apemberton | ||
|
I have also compiled 3.9.1 for my sheevaplugs with mixed results. Three of my Sheevaplugs use eSata to boot from and 3.9.1 works fine. However I tried the same kernel on a SD card based Sheevaplug and that failed when setting up the sdio subsytem. If I had known, I should have saved the console output but I needed to return the 'plug to service ASAP so reverted to an older kernel. I did notice that the console output differed around the sdio setup between 3.6.10 and 3.9.1. I am using a newer u-boot (2012-??) than stock. I don't think Sheevaplugs use flattened device tree yet (though it seems that Guruplugs may do so). I used the cbxbiker patches (3) and used 'make oldconfig' taking the current '/proc/config.gz' as a base.
So from my limited knowledge, I would say there is a problem with the Marvell sdio in the 3.9+ kernels and looking at the kernel changelogs, plainly there are changes afoot in that area. I think someone has to get the right combination of configuration, modules and possibly code changes in the sdio area to get Sheevaplugs working with 3.9+ kernels. |
||