Related
Hello,
I would like to build a 2.6.29 kernel for Hero for us to run properly Donut roms.
Here is my progress so far:
- I have sync the android kernel msm from git.
# git clone git://android.git.kernel.org/kernel/msm.git
# cd msm
# git checkout --track -b android-msm-2.6.29 origin/android-msm-2.6.27
- then:
# adb pull config.gz ./
# gunzip config.gz && mv config .config
# make PATH=$PATH:android-1.6_r1/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin ARCH=arm SUBARCH=arm CROSS_COMPILE=arm-eabi-
But no luck: it asks me questions to configure the kernel (error in .config?)
I have attached some useful files.
Try running make menuconfig and manually load the .config file. What happens?
kernel sources for hero is not available on http://developer.htc.com/ then no hero support in android.git.kernel.org/kernel/msm.git
Z!L0G80 said:
kernel sources for hero is not available on http://developer.htc.com/ then no hero support in android.git.kernel.org/kernel/msm.git
Click to expand...
Click to collapse
Well this guy did it here for sapphire before Htc released kernel sources.... So I think we can.
erikwt said:
Try running make menuconfig and manually load the .config file. What happens?
Click to expand...
Click to collapse
I copied the hero .config file to kernel root, then "make menuconfig" and loaded .config, then exit and yes to "write .config" question.
Make failed, output attached (make1.txt)
I then applied TigerTael sapphire patch as he "tends to think the memory locations may be correct". Tried to manually load hero's .config and got attached error (error.txt)
I then "make msm_defconfig" and could compile a kernel witch I added to ADP-1.6 boot.img. But no luck it does not work and adb logcat waits for device.... while I am waiting for advices
Regards
Was the downloaded config copied from a build of the same kernel version? If not do "make oldconfig" before commencing with "make menuconfig" or other build.
phel21 said:
Was the downloaded config copied from a build of the same kernel version? If not do "make oldconfig" before commencing with "make menuconfig" or other build.
Click to expand...
Click to collapse
'make oldconfig' asks me the questions to configure the kernel.....
Edit:
If that could help:
cat /proc/iomem
00700000-0079afff : msm_panel.1
007a0000-007bffff : ram_console
19200000-257fffff : System RAM
19223000-19513fff : Kernel text
19514000-195ebf7f : Kernel data
a0200000-a0200fff : msm_serial_hs.0
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : msm_sdcc.2
a0800000-a0800fff : msm_hsusb
a9900000-a9900fff : msm_i2c.0
a9900000-a9900fff : msm_i2c
a9c00000-a9c00fff : msm_serial.2
a9c00000-a9c00fff : msm_serial
aa200000-aa2effff : mdp
aa600000-aa600fff : msm_mddi.0
Yes. It will ask you questions as the kernel has added new capabilities - which you will need to configure. Use the help for the new options to guide your choices, although usually the default is the best way to go. Not doing "oldconfig" step will leave you with a busted build configuration.
I assume you're using the config options from /proc/config.gz on the phone?
CombinedEffort said:
I assume you're using the config options from /proc/config.gz on the phone?
Click to expand...
Click to collapse
of course I do
gecka said:
of course I do
Click to expand...
Click to collapse
Godspeed! (sorry, i cannot contribute anything as I am a total noob, but I'll read your progress regardless!)
(edit: i could beta test though..^_^)
http://forum.xda-developers.com/showpost.php?p=4737995&postcount=37
maybe this could be of any help?
E2K said:
http://forum.xda-developers.com/showpost.php?p=4737995&postcount=37
maybe this could be of any help?
Click to expand...
Click to collapse
please read first post
Now that kernel sources are out, it is time to port changes to 2.6.29.
Hey guys what would be the best? Apply HTC Hero kernel changes to 2.6.29 or apply 2.6.29 changes from 2.6.27 to hero kernel ?
I have applied HTC changes (3.4Mo patch!) to android2.6.29msm and I can compile it. When I run it it says it is a 2.6.27-dirty kernel... Why dirty ?
Lox, it probably means that some of your kernel changes from 2.6.27? or coded for 2.6.27 are not valid in the newer build, hence the 'dirty' reference.
Dirty here meaning spoilt or wrong.
I don't code, and i don't know exactly how much experience you have yourself, but do you reckon Cyanogen or maybe Drizzy could help some of you Hero ROM chefs out with some tips? I'm sure they'd love to give some pointers as to how they've gone about cooking on the Sapphire and Magic.
maybe you did a dirty trick
Lox_Dev said:
Hey guys what would be the best? Apply HTC Hero kernel changes to 2.6.29 or apply 2.6.29 changes from 2.6.27 to hero kernel ?
I have applied HTC changes (3.4Mo patch!) to android2.6.29msm and I can compile it. When I run it it says it is a 2.6.27-dirty kernel... Why dirty ?
Click to expand...
Click to collapse
You can get dirty tagged when you change owner of the files compared to the user who pulled them from git.
packetlss said:
You can get dirty tagged when you change owner of the files compared to the user who pulled them from git.
Click to expand...
Click to collapse
Well I understand that but I don't understand why it is not 2.6.29 ?
I have done:
git checkout --track -b android-msm-2.6.29 origin/android-msm-2.6.27
Why start with 2.6.29 and not the latest stable kernel (2.6.31.x) now that HTC-patches just have been released. According to the changelogs there's quite a few interesting android-specific improvements in those later revisions.
Is the intention to match kernel version for android 1.6 source? I'd expect generic android kernel-enhancements to be integrated into the kernel.org kernel. In that case it should be fairly easy to use a more recent kernel than that included in an official android release.
Lox, is this a dead project? Are you focusing on your optimized .27 kernel for our devices?
Here we go
Common gingerbread-samsung git branch for all of us
This branch contains the fixed Gingerbread source (compiling and working) everyone of us may use as reference git repository.
Fixed in this source:
- all cleaned up gitignores
- missing FSR in Makefile
Take also a look at the updated README.txt that will explain you how to compile and get it working with modules
Also: makes sure you disable, in .config:
[*] Automatically append version information to the version string in menuconfig or CONFIG_LOCALVERSION_AUTO in .config
It will help each developer to exchange patches easily because of the common starting point.
bilboa1 said:
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
I certainly support this idea.
Click to expand...
Click to collapse
How you can fork this repository:
- clone it via github directly
or, if you prefer keeping only this gingerbread branch directly, on your dev computer:
Code:
git clone git://github.com/project-voodoo/linux_gt-i9000.git -b gingerbread-samsung
cd linux_gt-i9000
git remote rm origin
git remote add origin git://your-new-remote-repository.git
git remote add common git://github.com/project-voodoo/linux_gt-i9000.git
This way, for people re-using Vodooo sound for example, it will be as easy as:
Code:
git fetch common
git merge gingerbread-voodoo-sound
If you have more idea of collaboration like that, express yourself
FAQ:
Q: Bleh! I hate this Kernel/ directory.
A: Yes, this was the case for the original commits but now it's a standard Linux repository with everything on its root.
But it didn't worked as expected, so I had to make the change, sorry for the inconvenience to the early adopters.
Q: What happens when Samsung update their source code tarballs
A: I'll update the common git repository accordingly (hopefully fast enough for you)
On your side, all you'll need to do will is.
Code:
git fetch common
− or git fetch git://github.com/project-voodoo/linux_gt-i9000.git
git merge gingerbread-samsung
Say good bye to messy tarballs!
PS: if you're looking to initramfs, take a shot at https://github.com/project-voodoo/samsung_initramfs − contribution welcome.
Good idea, I second that, it will be easier
wrong link
Github reads http://project-voodo.org/
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
Forking in git hub is VERY VERY easy btw.
I certainly support this idea.
Awesome! - I also support this idea
United Galaxy S Developers
Nice idea! Perfect spirit of open source
I hope good things come out og this.
Great move Supercurio - once again !
Simply awesome men
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
pikachu01 said:
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
Click to expand...
Click to collapse
The gingerbread-samsung branch promoted here will only contain Samsung kernel sources and won't interfere with other developers modifications.
Only exception is if this source is broken and needs something to work, like nikademus's patch: https://github.com/project-voodoo/linux_gt-i9000/commit/6c8f989f58999770d23236bb172c3a4e1c80586b
It seems that JVK and JVB was pulled from Kies because of an update problem. Looks like we're going to have new ROMs to play with in a week or two (maybe less)
Edit: What about the SSL fix (http://forum.xda-developers.com/showthread.php?t=1040005)
Great, good idea. That's how community development should work!
zorxd said:
Great, good idea. That's how community development should work!
Click to expand...
Click to collapse
Agreed! Thanks for getting things started Supercurio! Now I have to start making a Vibrant branch.
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
ttabbal said:
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
Click to expand...
Click to collapse
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
supercurio said:
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Click to expand...
Click to collapse
Excellent! I just did a defconfig to check it out and saw the preempt in there.. Nice to see Samsung fixing things up a little. Now I need to get a GB ROM to install so I can try to boot.
Thanks again. I'll send a pull request when I have a Vibrant branch ready. Going for minimal modifications, fix touch button mapping and such. People can add whatever they want after that. Now I need to learn the new code tree... wheee! Hopefully the basics are the same, getting the changes into an i9k froyo kernel is pretty easy.
zorxd said:
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
Click to expand...
Click to collapse
You will need an initramfs... anyone have a default one we can start with for 2.3?
zImage will have to be in a TAR file to flash with Odin. Heimdall can flash a bare zImage, as can the SGS Kernel Flasher tool for Android.
Oh... think I saw a setting in "make menuconfig" for the cross-compiler prefix. Might be able to avoid Makefile mods....
Sorry for the newb question, but how do we generate the initramfs? I guess we could take the one from stock JVB. But how do we extract it and how do we combine our compiled kernel with it?
On a side note, I noticed that CFQ is the default scheduler. Isn't it better to use No-op for flash memory?
The Motorola kernel source releases don't seem to include the kernel config. Anyone know if the configs are available somewhere? Or perhaps someone has already gone through the work to create an approximation config that works for building modules and could share?
Hi,
There are some Motorola specific configs in the kernel\omap3\arch\arm\configs\ext_config folder. Is this what you missing?
mapphone_defconfig
Hi quasimidi,
quasimidi said:
There are some Motorola specific configs in the kernel\omap3\arch\arm\configs\ext_config folder. Is this what you missing?
Click to expand...
Click to collapse
Thanks! Not exactly as the stuff in ext_config seem to be config fragments only, but you pointed me in just the right direction for the full configuration.
There is a mapphone_defconfig target that seems to produce a suitable config. This is what I did, perhaps this is useful to someone:
- Download kernel source from sf.net/motorola, unpack
- Get ARM cross toolchain with gcc 4.4 - I got mine from emdebian
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- mapphone_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
The build tree can now be used to build modules. I only did a quick test, but the module inserted cleanly and appears to be working so far.
https://github.com/CyanogenDefy/and...n/blob/gingerbread/modules/mapphone_defconfig
its the one i use for modules... its based on the one in kernel sources, but result of a build in a repo
So I pretty much would like to start building my own kernels and Roms from AOSP, but not sure where to start. I have downloaded the SDK already, and started downloaded some file with git and these commands:
git clone https://android.googlesource.com/kernel/omap
cd omap
git checkout origin/android-omap-tuna-3.0-mr0
but the guides I've been reading don't offer much more help. And then there is a toolchain of some sort? I can get my way around linux fairly well and have built my own kernels about a year and a half ago for my Vibrant, but took a completely different course.
Was wondering if someone could point me in the right direction, thanks!
You're on the right track. Use Linux ubuntu, install all the packages, the Android tool chain, then just clone the aokp kernel like you showed. But you had the wrong repo link. Go to team kangs github page, go to the nexus kernel, then at the top will be their git link in a box.
Git clone "link"
Then just run the make command in terminal. Make sure you navigated yo the downloaded kernel folder.
RogerPodacter said:
You're on the right track. Use Linux ubuntu, install all the packages, the Android tool chain, then just clone the aokp kernel like you showed. But you had the wrong repo link. Go to team kangs github page, go to the nexus kernel, then at the top will be their git link in a box.
Git clone "link"
Then just run the make command in terminal. Make sure you navigated yo the downloaded kernel folder.
Click to expand...
Click to collapse
Thanks a lot, will try that. The link on their page is AOSP?
Sent from my Galaxy Nexus using XDA
The guy is asking us on how to clone AOSP tuna kernel tree, and you tell him to clone teamKang kernel project?
@op, no, you dont have the incorrect url. Clone from there, then checkout branch android-omap-3.0.
Type:
'make tuna_defconfig'
'make -j4'
You'll then have a zimage in arch/arm/boot, which you'll need to merge with a compatible ramdisk (either by fastboot or manually).
sent from my i9250
bk201doesntexist said:
The guy is asking us on how to clone AOSP tuna kernel tree, and you tell him to clone teamKang kernel project?
@op, no, you dont have the incorrect url. Clone from there, then checkout branch android-omap-3.0.
Type:
'make tuna_defconfig'
'make -j4'
You'll then have a zimage in arch/arm/boot, which you'll need to merge with a compatible ramdisk (either by fastboot or manually).
sent from my i9250
Click to expand...
Click to collapse
Sweet will continue with these steps and look onto the merge
Sent from my Galaxy Nexus using XDA
bk201doesntexist said:
The guy is asking us on how to clone AOSP tuna kernel tree, and you tell him to clone teamKang kernel project?
@op, no, you dont have the incorrect url. Clone from there, then checkout branch android-omap-3.0.
Type:
'make tuna_defconfig'
'make -j4'
You'll then have a zimage in arch/arm/boot, which you'll need to merge with a compatible ramdisk (either by fastboot or manually).
sent from my i9250
Click to expand...
Click to collapse
Oh holy crap haha I completely thought he asked about aokp kernel, my bad I didn't read.
AOSP kernel for HTC Explorer/Pico
Can you tell me how to build aosp kernel for htc explorer?
monishvster said:
Can you tell me how to build aosp kernel for htc explorer?
Click to expand...
Click to collapse
Just do the same thing, but instead sync the htc kernel rather than the nexus. Go search and find out if source code has been released for that phone.
Then just run the make command.
Somebody call 911, we've been hijacked
Note: 'make tuna_defconfig' is for maguro, i dont know what is the name of default config file for the htc, why should we? User should refer to htc explorer subforum @xda or to kernel documentation.
Sent from my i9250
Hello everyone.
This guide will help you in building a kernel from source for your Nexus 10
Later, when 4.2 hits AOSP, i'll add a guide for building that too
You will need a computer running Linux / OSX to build the kernel, natively, or via a VM.
This guide assumes you’re running any Linux distro.
Getting a toolchain:
You need a toolchain to build the kernel.
The preferred one is Google’s toolchain, the same they use to build AOSP.
In a terminal, type:
Code:
git clone [url]https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.6/[/url]
export PATH=$PATH:$(pwd)/arm-linux-androideabi-4.6/bin
export CROSS_COMPILE=arm-linux-androideabi-
TIp: paste the export statements in your ~/.bashrc to have them exported each login.
Getting the kernel source:
The kernel source for Nexus devices is available from Google’s servers.
Source : https://android.googlesource.com/kernel/exynos
Github Mirror: https://github.com/chirayudesai/android_kernel_exynos
Open the terminal, and type the below commands to get the kernel source on your computer.
Code:
mkdir -p android/kernel
cd android/kernel
For Nexus 10, we get the exynos kernel sources.
Code:
git clone [url]https://android.googlesource.com/kernel/exynos[/url]
Next, we change our directory to the newly fetched source.
Type
Code:
cd exynos
Figuring out what to build:
Now, we need to figure out which revision to build.
You need to be exactly sure about this, otherwise there are chances that the compiled kernel won’t work.
The commit to build upon can be found by a few ways.
To get the kernel sources matching the device tree, type the below in the device tree.
Code:
git log kernel
Then type the below in the kernel tree
Code:
git checkout <commit>
The commit of the version running on the current review units is 52f6ab1 (probably), which is same as branch android-exynos-manta-3.4-jb-mr1-fr .
Compiling:
Name of defconfig: manta_defconfig
cd to the directory of the kernel source, then type the below in a terminal.
Code:
export ARCH=arm
export SUBARCH=arm
Code:
make <name_of_defconfig>
make
The kernel image will be ready at arch/arm/boot/zImage
To flash it, you need to make it into a boot.img, more on that later. when we have more sources.
Nice work, it's been nice to see some instructions on building additional kernel modules too.
Sent from my GT-I9300 using Tapatalk 2
Great guide! I look forward to seeing your tutorial on compiling 4.2 from source .
Sent from my SCH-I535 using xda premium
Super awesome! I'm currently thoroughly:good: learning the rom building process with my nexus... ill get to this!
looking forward towards the development
Great! This is very helpful and useful
hey man, i got stuck at this point
Code:
git log kernel
it gives me this error
Code:
fatal: ambiguous argument 'kernel': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
didn't really get that point... thanks :good:
matt95 said:
hey man, i got stuck at this point
Code:
git log kernel
it gives me this error
Code:
fatal: ambiguous argument 'kernel': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
didn't really get that point... thanks :good:
Click to expand...
Click to collapse
It has to be typed in the device tree, which hasn't hit AOSP yet, but should soon.
Sent from my GT-P1000
cdesai said:
It has to be typed in the device tree, which hasn't hit AOSP yet, but should soon.
Sent from my GT-P1000
Click to expand...
Click to collapse
oh, now i get this :good:
i was able to make a build tonight from aosp, waiting for my device to arrive & then ill be able to test. but as far as i could tell the output sizes were pretty on compared to the factory image files i extracted http://renzy.me/aoi
...just realized i didnt extract proprietary binaries.
Hello, Cdesai.
Thanks for your guide!
I will do my best to learn it.
so you say that you need to make the zImage into a boot.img (being a noob about this...) on my SGSII, I can flash zImages and boot.img, so I'm confused, lol
jrod091 said:
so you say that you need to make the zImage into a boot.img (being a noob about this...) on my SGSII, I can flash zImages and boot.img, so I'm confused, lol
Click to expand...
Click to collapse
i think it depends on how youre flashing. with the sgsii youre prob using odin/heimdall & it might just overwrite the kernel. flashing with fastboot might require the boot.img cause it contains a ramdisk image after the kernel & is writing a partition. thats just my guess at least, someone else might have a better/more accurate answer for ya
renzyyy said:
i think it depends on how youre flashing. with the sgsii youre prob using odin/heimdall & it might just overwrite the kernel. flashing with fastboot might require the boot.img cause it contains a ramdisk image after the kernel & is writing a partition. thats just my guess at least, someone else might have a better/more accurate answer for ya
Click to expand...
Click to collapse
yeah that's true, but for instance with HTC S-OFFed devices you don't even need to flash the boot.img....
cdesai said:
... To flash it, you need to make it into a boot.img, more on that later. when we have more sources.
Click to expand...
Click to collapse
you can extract the contents from the factory image & use getramdisk.py to get the ramdisk.img out of the current boot.img (or use this ramdisk.img)
then once youve compiled the kernel successfully, use mkbootimg from android_bootimg_tools.tar.gz to repack your boot.img.
if you want to just test...
fastboot boot [new-boot.img]
and flash if satisfied...
fastboot flash boot [new-boot.img]
just tested out if anyone wants some verification... screenshot
@cdesai, shouldn't we be using arm-eabi- instead of arm-linux-androideabi- as CROSS_COMPILE
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/
export PATH=$PATH:$(pwd)/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
Building with arm-linux-androideabi- causes issues with kernel modules... here's an example of such an issue https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/dzEIOVuxtEo
And the most updated kernel branch is android-exynos-manta-3.4-jb-mr1 not android-exynos-manta-3.4-jb-mr1-fr
Is there any chance of this becoming an OC kernel in the future?
craigacgomez said:
@cdesai, shouldn't we be using arm-eabi- instead of arm-linux-androideabi- as CROSS_COMPILE
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/
export PATH=$PATH:$(pwd)/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
Building with arm-linux-androideabi- causes issues with kernel modules... here's an example of such an issue https://groups.google.com/forum/?fromgroups=#!topic/android-kernel/dzEIOVuxtEo
And the most updated kernel branch is android-exynos-manta-3.4-jb-mr1 not android-exynos-manta-3.4-jb-mr1-fr
Click to expand...
Click to collapse
Yes, I couldn't get md4 and cifs modules to load with arm-linux-androideabi-4.6:
<3>[ 1250.492203] md4: unknown relocation: 27
<4>[ 1260.230901] cifs: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)
However, with this:
git clone https://android.googlesource.com/platform/prebuilt
export PATH=$PATH:$PWD/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
export CROSS_COMPILE=arm-eabi-
The modules load okay:
[email protected]:/mnt/shell/emulated/0 # lsmod
cifs 269223 0 - Live 0x00000000
md4 3442 0 - Live 0x00000000
(Now I have to work out why neither mount nor cifsmanager are working as expected...)
sam3000 said:
Yes, I couldn't get md4 and cifs modules to load with arm-linux-androideabi-4.6:
<3>[ 1250.492203] md4: unknown relocation: 27
<4>[ 1260.230901] cifs: Unknown symbol _GLOBAL_OFFSET_TABLE_ (err 0)
However, with this:
git clone https://android.googlesource.com/platform/prebuilt
export PATH=$PATH:$PWD/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin
export CROSS_COMPILE=arm-eabi-
The modules load okay:
[email protected]:/mnt/shell/emulated/0 # lsmod
cifs 269223 0 - Live 0x00000000
md4 3442 0 - Live 0x00000000
(Now I have to work out why neither mount nor cifsmanager are working as expected...)
Click to expand...
Click to collapse
I know the reason... busybox needs to be patched... i guess it's something new in 3.4.5 kernel... I haven't done the patch yet
https://github.com/OpenELEC/OpenELEC.tv/commit/f66041febdb07d13a158dab5da901d208cf4fff9
craigacgomez said:
I know the reason... busybox needs to be patched... i guess it's something new in 3.4.5 kernel... I haven't done the patch yet
https://github.com/OpenELEC/OpenELEC.tv/commit/f66041febdb07d13a158dab5da901d208cf4fff9
Click to expand...
Click to collapse
I had actually just got to the point of realising I could make it work by explicitly setting the unc path in mount command options. The missing patch would explain it.