[gnarlyc]

If anyone with kernel hacking experience would like to help me out, I'd really appreciate it. I'm looking at one of two repos to use as a base right now, but maybe there's a better one somewhere.

https://github.com/tom3q/spica-2.6.38
https://github.com/C...enMod/cm-kernel

My thinking that I should spend my time working on getting a kernel newer than 2.6.29 to work. Feel free to disagree. I'm still very much learning, but I do have a good start and kind of know my way around. (Learning is fun!)

I can test kernels at will due to the hard work done by RobertBrownNZ and others in this thread - http://www.slatedroi...omething-else/.

So far, I've looked in /dev on a running WPDN and grabbed the list of devices, looked at the kernel logs to see what is initiated in there, cloned both of those repos, and compiled them successfully. Neither would boot 'out of the box', but I expected as much. They were recognized by the bootloader as valid images though. I used the s3c6400_defconfig and compiled with the uImage option, since it appears that our kernel is in that format.

I'll actually clone one or more of those repos to my github profile soon, so we will have an accessible repo to work with.

Any thoughts?

This post has been edited by randomblame: 05 May 2012 - 03:51 PM

[RobBrownNZ]

There's also the samsung tree in the android repo, just in case you don't have enough source code yet

http://android.git.k...nel/samsung.git

It seems that the .config isn't built in (it's /proc/config.gz isn't it?). Thanks for nothing, Pandigital.

Anyway, I'd be really keen to see some progress in this area. I'll be watching with interest (and, knowing me, sticking my oar in )

This post has been edited by RobBrownNZ: 24 March 2011 - 03:47 PM

[gnarlyc]

RobBrownNZ, on 24 March 2011 - 03:46 PM, said:

There's also the samsung tree in the android repo, just in case you don't have enough source code yet

http://android.git.k...nel/samsung.git

It seems that the .config isn't built in (it's /proc/config.gz isn't it?). Thanks for nothing, Pandigital.

Anyway, I'd be really keen to see some progress in this area. I'll be watching with interest (and, knowing me, sticking my oar in )

Thanks for the link! I'm looking for a good place to start that will enable us to get this working with the least amount of work. That one looks promising.

No, the .config isn't there. See, Pandigital wants us to learn more by having to reverse-engineer as much as possible. We wouldn't learn anything if they just gave it to us! They are just acting in our best interests.

[browntiger]

have you seen this config

http://code.google.c...el/.config?r=19

This post has been edited by browntiger: 25 March 2011 - 06:34 AM

[Mark Adams]

gnarlyc, on 24 March 2011 - 05:51 PM, said:

Thanks for the link! I'm looking for a good place to start that will enable us to get this working with the least amount of work. That one looks promising.

No, the .config isn't there. See, Pandigital wants us to learn more by having to reverse-engineer as much as possible. We wouldn't learn anything if they just gave it to us! They are just acting in our best interests.

LOL. They've gone above and beyond in their "concern" for our educational experience IMO.

[Netham45]

Have you had any success with this?

I'm going to try my hand at it, just waiting for the TTL adapter I ordered to arrive.

[gnarlyc]

Netham45, on 12 April 2011 - 02:45 PM, said:

Have you had any success with this?

I'm going to try my hand at it, just waiting for the TTL adapter I ordered to arrive.

Honestly, I've only spent a few hours on it. I have too many things going on at once, but my C class will be over in early May. That will free up some time and has already helped me to understand what's going on a lot better. I will get back to it though. If you make any progress, let me know. I've forked the 2.6.38 Spica kernel and started from there. There's a def config for the smdk64xx in there. It compiles just fine. Of course, it doesn't boot. It's a lot smaller than the stock kernel, so I'm sure it's missing some needed things...

[RobBrownNZ]

It'd be interesting for you to post the boot output from the spica kernel here, so we can compare against the wpdn one.

(I'm assuming that it gets past "uncompressing the kernel" and the kernel actually starts executing. If not then we've got bigger problems )

[gnarlyc]

RobBrownNZ, on 13 April 2011 - 06:42 PM, said:

It'd be interesting for you to post the boot output from the spica kernel here, so we can compare against the wpdn one.

(I'm assuming that it gets past "uncompressing the kernel" and the kernel actually starts executing. If not then we've got bigger problems )

I'll try and flash it again this weekend and see. If I remember correctly, the bootloader found the kernel image and then hung up. Now, I have not been able to enable the YAFFS fs via the .config file, so that might be the issue there. It seems to me that would be important.

I've cut and pasted the YAFFS config options from a .config for my phone's kernel and made sure that 'misc file systems' were enabled. I've also double checked the Kconfig in fs/ and everything seems right. What I need to do is start over, make these changes, and commit them to the github repo (https://github.com/g...yc/spica-2.6.38) so that you all can see them. It's probably something 'simple'.

(Oddly enough... My PDN is back together and I'm using it to read a book. I know, it's strange, but I'll fix the situation this weekend.)

This post has been edited by gnarlyc: 14 April 2011 - 05:44 AM

[RobBrownNZ]

To get YAFFS2 to show up, you need to enable "Memory Technology Device (MTD) support" in the "Device Drivers" section, and under that you need "Caching block device access to MTD devices". It'll also need OneNAND support of some kind.

If you get the "uncompressing the kernel" message but nothing after that, then I think the kernel's not really booting at all. Once again I seem to remember some oddity with load addresses, might be worth looking into.

Please add your .config to github. I've cloned your repo, and I'm quite keen to play with this

This post has been edited by RobBrownNZ: 15 April 2011 - 07:26 AM

[gnarlyc]

RobBrownNZ, on 15 April 2011 - 07:25 AM, said:

To get YAFFS2 to show up, you need to enable "Memory Technology Device (MTD) support" in the "Device Drivers" section, and under that you need "Caching block device access to MTD devices". It'll also need OneNAND support of some kind.

If you get the "uncompressing the kernel" message but nothing after that, then I think the kernel's not really booting at all. Once again I seem to remember some oddity with load addresses, might be worth looking into.

Please add your .config to github. I've cloned your repo, and I'm quite keen to play with this

I used arch/arm/config/s3c6400_defconfig as a base. I pushed my modified version to the root folder, which does allow it to compile but doesn't have all of the needed options enabled.

It's nice to hear that you want to take a stab too. I can certainly use any help.

[terminander]

Have you guys tried the kernels from Mini6410. They support 256megs, Yaffs2 and Onenand. Since they supply the sources, you could pull the kernel conf (speed is slower). They also have sources for GingerBread.

http://www.minidevs.com/

[gnarlyc]

RobBrownNZ, on 13 April 2011 - 06:42 PM, said:

It'd be interesting for you to post the boot output from the spica kernel here, so we can compare against the wpdn one.

(I'm assuming that it gets past "uncompressing the kernel" and the kernel actually starts executing. If not then we've got bigger problems )

Here's my output:

Quote

## Loading init Ramdisk from Legacy Image at 50ffffc0 ...
ramdisk start = 0x51000000, ramdisk end = 0x5102756c
Transferring control to Linux (at address 50008000) ...

Starting kernel ...

machid:1626, address of boot params:0x50000100

It just hangs there. I recompiled with mtd, onenand, and yaffs.

Of course, with a working kernel, it goes past that.

Quote

## Loading init Ramdisk from Legacy Image at 50ffffc0 ...
ramdisk start = 0x51000000, ramdisk end = 0x5102756c
Transferring control to Linux (at address 50008000) ...

Starting kernel ...

machid:1626, address of boot params:0x50000100
Uncompressing Linux.................................................................................................................................. done, booting the kernel.
[ 0.000000] Linux version 2.6.29 (fsysky@fsysky) (gcc version 4.2.2) #0 Mon Jan 24 18:22:16 UTC 2011

When I use a zImage instead of a uImage, I get this. So, I'm pretty sure that it needs a uImage. (That's what I figured any way, but it's nice to play around and see the difference.)

Quote

get_format
-------- 0 --------
Wrong Image Format for bootm command
ERROR: can't get kernel image!

I wonder if I'm missing an offset or something instead of an option in the kernel .config?

This post has been edited by gnarlyc: 16 April 2011 - 10:02 AM

[gnarlyc]

terminander, on 15 April 2011 - 06:43 PM, said:

Have you guys tried the kernels from Mini6410. They support 256megs, Yaffs2 and Onenand. Since they supply the sources, you could pull the kernel conf (speed is slower). They also have sources for GingerBread.

http://www.minidevs.com/

Nice. I'll take a look.

[gnarlyc]

I wonder if it's one of these?

Quote

#
# Kernel Features
#
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000

#
# Boot options
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=ttySAC0,115200 root=/dev/ram init=/linuxrc initrd=0x51000000,6M ramdisk_size=6144"

This post has been edited by gnarlyc: 16 April 2011 - 10:11 AM

[RobBrownNZ]

The kernel command line should be "console=ttySAC1,115200 root=/dev/ram0 rw ramdisk=1024 init=/init". That's supplied by U-Boot, but I wonder if the built-in command line overrides it?

[glyff]

Any progress on this? Have you guys moved discussion of this somewhere else?

[gnarlyc]

glyff, on 10 May 2011 - 05:10 PM, said:

Any progress on this? Have you guys moved discussion of this somewhere else?

No, and no.

My final exam for my class was this morning. So, I should be able to jump back in to this and the other kernel that I'm helping with/working on (Droid Eris)... (Assuming that my PDN will boot, but that's another story. I know. I know.)

[randomblame]

## Loading init Ramdisk from Legacy Image at 50ffffc0 ...
ramdisk start = 0x51000000, ramdisk end = 0x5102756c
Transferring control to Linux (at address 50008000) ...

Starting kernel ...

machid:1626, address of boot params:0x50000100

haha that's where I'm at too trying to move forward. Thought I'd bump this old thread because there is some useful info in here

*uboot passes kernel arguments along and so far in my experiments it looks like it's best to leave the kernel cmd line empty and let uboot do it's thing.

there is a limit to the size of an uncompressed zimage - the ramdisk image is what should be used as an initrd

Look at your Image file in the boot folder after you've compiled if it's bigger than 6mb your zImage/uImage will be too big to work and uboot will say "error out of size"

This post has been edited by randomblame: 11 February 2012 - 11:58 AM

[randomblame]

Might be making some progress. I think that the tty console setting isn't working it's not outputting kernel messages to the serial link which is why it's "stuck" here:
## Loading init Ramdisk from Legacy Image at 50ffffc0 ...
ramdisk start = 0x51000000, ramdisk end = 0x510276f3
Transferring control to Linux (at address 50008000) ...

Starting kernel ...

machid:1626, address of boot params:0x50000100

my last compile goes to that and then the screen goes all groovy purple with lines which leads me to believe that the kernel does take control

makefile.boot specifies the correct params address and zreladdr
zreladdr-y := 0x50008000
params_phys-y := 0x50000100

This post has been edited by randomblame: 11 February 2012 - 12:47 PM