Kernel source

[doublec]

What kernel does the X11 ROM use? If I want to build the affix bluetooth stack I need the kernel source. Is it available? Or is it the standard sharp rom kernel sources? If so, what config options were used when building?

Chris.

[Anonymous]

http://www.cacko.biz/feed/kernel-patches/l....cacko.diff.bz2

configs:
arch/arm/def-configs/*-cacko

[doublec]

Great, thanks!

[doublec]

What original source was the patch applied to? Was it the 760 or the 860 kernel? So the steps for getting the full kernel source would be something like:
bzcat linux-2.4.18.tar.bz2 | tar xvf -
cd linux
bzcat ../patch-2.4.18-rmk7.bz2 | patch -p1
zcat ../diff-2.4.18-rmk7-pxa3.gz | patch -p1
bzcat ../linux-2.4.18-rmk7-pxa3-embedix-slc750-20030620-rom1_10.bz2 | patch -p1
bzcat linux.cacko.diff.bz2 | patch -p1

Except using the 860 kernel source in the second to last line? Is that correct?

[Richjn]

doublec

I would use the 860 source for any pxa based model.

The line second from last is the file name not the source name. Leave it as is.


Richard

[Ashley]

I\'m trying to hack some things of in the new rom. Now, I think I understand how partitioning works, and think I am able to patch kernel source and installer script in order to have only the root partition (with /home on it) to have no fragmentation at all in the precious nand flash.  Of course, it would take the whole space except smf.

But now, what kernel should I patch? I mean, I don\'t know the patches that were applied to the kernel of this rom. Even worse, the above referred patches are no longer available.

Any one knows what combination of sources+pataches+configs were used to build pdaxrom\'s kernel (1.0.5)? Can you tell me where I can find them?

Even more, don\'t you think we need ALL the sources and patches available? Are they? Where?
(Intend this as a wish of collaboration, a constructive critic)

Ash

[ikm]

I\'m trying to hack some things of in the new rom. Now, I think I understand how partitioning works, and think I am able to patch kernel source and installer script in order to have only the root partition (with /home on it) to have no fragmentation at all in the precious nand flash.
Ash

Actually, partitioning is just a matter of passing right parameters to the kernel. Or they can be compiled in. That\'s easy, but you will encounter quite a huge problem with the installer, as it is using Sharp\'s maintenance kernel, which is told to have two partitions. Their configuration is stored in the flash and can be changed (e.g. resize ability in installer), but there always are two partitions.

The fun is, the problem can be solved -- you can patch the flash somewhere where it contains the parameters that are passed to the kernel. This way it works. I have done it once, so it really works.

I can post precise details on how to do this (what to change and how) if anyone is interested.

[Ashley]

Yes, please. I knew the problem with Sharp\'s kernel. I\'ve thought a workaround of this, but haven\'t tried yet. However I have some doubts about parameters location (I\'ve found it, but not sure if I can change the right way).

So, please tell (me) more about your solution. And again, if someone can tell me where are the actual kernel sources, would make me happy ;-)

[treke]

doublec

I would use the 860 source for any pxa based model.

The line second from last is the file name not the source name. Leave it as is.


Richard

I\'ll second this. the 860  source maintains the drivers for the other pxa devices and includes some useful bug fixes.

[ikm]

Yes, please. I knew the problem with Sharp\'s kernel. I\'ve thought a workaround of this, but haven\'t tried yet. However I have some doubts about parameters location (I\'ve found it, but not sure if I can change the right way).

So, please tell (me) more about your solution. And again, if someone can tell me where are the actual kernel sources, would make me happy ;-)

Ok, here it is.

Usual warnings apply here: make a full backup before trying, do it on your own risk etc.

I can not guarantee that all I wrote below is absolutely correct, for I cannot test it at the moment. It should be close to the truth though
Note that you\'ll lose all the current contents of \'root\' and \'home\' of course.

You should use \'/sbin/nandlogical\' tool to perform read/write operations, with /dev/mtd1. That tool lives in the maintenance initrd, boot with pdaxrom installer and go shelling, you\'ll see it.

Do not use nandcp, as Sharp introduced a sort of hack to implement wear leveling with mtd1, so the physical offset would be different when it is accessed directly. For mtd1, use the \'nandlogical\' tool only.

The part of flash you need to modify lies at 0x209F4, it is 80 bytes long. NOTE that this applies to SL-C760 only, as I haven\'t tried it on other models. Maybe it is the same, or maybe not.

First, read that block using the \'nandlogical\' tool.
Do something like
# /sbin/nandlogical /dev/mtd1 READ 0x209F4 80 mtdparts

Be sure that the resulting file (mtdparts) is the same as the one I attached. It contains some data that is used to construct kernel parameters. We can tweak it. I attached tweaked result. Look inside and see what changed

Next, you put that modifications back, with the same \'nandlogical\' tool.

# /sbin/nandlogical /dev/mtd1 WRITE 0x209F4 80 mtdparts_tweaked

That\'s all. Next time you boot into maintenance mode, inspect /proc/mtd, and if everything was right, now there will be no \'home\' partition there, only the one big \'root\'. You\'ll need to erase it of course, as it no longer matches the original filesystem size.

These modifications do not neccessarily apply to the kernel that is used in normal boot mode. I do not know if the same data is used to construct kernel parameters for the normal kernel or not. You can always compile-in all the parameters to your kernel to be sure, or otherwise you can find it out yourself

Hope this helps.

Update: the attachments do not seem to work here, at least for me
Here go uuencoded files =)

begin 644 mtdparts
M)60``\"!M=&1P87)T<SUS:&%R<\'-L+6YA;F0Z-S$V.&M`,&LH<VUF*2P```!K
C0#<Q-CAK*\')O;W0I+\"TH:&]M92D````@6D%54E537U)%4T4`
`
end

begin 644 mtdparts_tweaked
M`&0``\"!M=&1P87)T<SUS:&%R<\'-L+6YA;F0Z-S$V.&M`,&LH<VUF*2P````M
C*\')O;W0I`\')O;W0I+\"TH:&]M92D````@6D%54E537U)%4T4`
`
end

Use standard \'uudecode\' tool to decode them. There should be no spaces in the \'end\' lines, or it might not eat it.

[Ashley]

Thank you very much ikm!

You should use \'/sbin/nandlogical\' tool to perform read/write operations, with /dev/mtd1. That tool lives in the maintenance initrd, boot with pdaxrom installer and go shelling, you\'ll see it.

Do not use nandcp, as Sharp introduced a sort of hack to implement wear leveling with mtd1, so the physical offset would be different when it is accessed directly. For mtd1, use the \'nandlogical\' tool only.

Agree. Was using it.

The part of flash you need to modify lies at 0x209F4, it is 80 bytes long. NOTE that this applies to SL-C760 only, as I haven\'t tried it on other models. Maybe it is the same, or maybe not.

I already found that, but my offset is not exactly the same (!). I also have a 760.

First, read that block using the \'nandlogical\' tool.
Do something like
# /sbin/nandlogical /dev/mtd1 READ 0x209F4 80 mtdparts

Be sure that the resulting file (mtdparts) is the same as the one I attached. It contains some data that is used to construct kernel parameters. We can tweak it. I attached tweaked result. Look inside and see what changed

Next, you put that modifications back, with the same \'nandlogical\' tool.

# /sbin/nandlogical /dev/mtd1 WRITE 0x209F4 80 mtdparts_tweaked

That\'s all. Next time you boot into maintenance mode, inspect /proc/mtd, and if everything was right, now there will be no \'home\' partition there, only the one big \'root\'. You\'ll need to erase it of course, as it no longer matches the original filesystem size.

These modifications do not neccessarily apply to the kernel that is used in normal boot mode. I do not know if the same data is used to construct kernel parameters for the normal kernel or not. You can always compile-in all the parameters to your kernel to be sure, or otherwise you can find it out yourself

If you read before that address you can find \'mainlinuxparam=\' followed by some other params and the mtdparts param. I think this command line applies to both kernels, because a bit later you can see \'maintelinuxparam=\' followed by more params (wich obviously apply only to the maintenance kernel), but there is no mtdparts param, so I presume mainte kernel uses both command lines.

Tip: I\'m hexediting systc760.dbk standard maintenance menu backup file, wich contain a WHOLE nand snapshot.

Hope this helps.

Update: the attachments do not seem to work here, at least for me
Here go uuencoded files =)

begin 644 mtdparts
M)60``\"!M=&1P87)T<SUS:&%R<\'-L+6YA;F0Z-S$V.&M`,&LH<VUF*2P```!K
C0#<Q-CAK*\')O;W0I+\"TH:&]M92D````@6D%54E537U)%4T4`
`
end

begin 644 mtdparts_tweaked
M`&0``\"!M=&1P87)T<SUS:&%R<\'-L+6YA;F0Z-S$V.&M`,&LH<VUF*2P````M
C*\')O;W0I`\')O;W0I+\"TH:&]M92D````@6D%54E537U)%4T4`
`
end

Use standard \'uudecode\' tool to decode them. There should be no spaces in the \'end\' lines, or it might not eat it.

Ok, I\'ll try your solution, it\'s easy and riskless (taking some cares, course). But according to cmdlinepart.c kernel source you are typing  a wrong mtdparts param. I\'m inspecting this code. It may work, despite some kernel error messages. Again, I\'m going to try.

I think boot process works this way: z boot loader reads root partiton size from PartitionInfo1 at 0x60000 (PartitionInfo2 is just a copy) (see http://www.h5.dion.ne.jp/~rimemoon/zaurus/...pic/nandmap.jpg), and updates kernel command line at each boot. So, modifiying PartitionInfo would be a better solution. I think fsro_resize tool from pdaxrom does this. But I\'m not sure how it does, how root partition size is specified. I don\'t have fsro_resize source code! The fact is that when you exceed 63MB root partition, kernel command line becomes wrong (?) and partition scheme falls down to the default specified in sharp_sl.c kernel source (30MB root, 27MB user !!). I don\'t know why this happens, maybe a bootloader bug or a fsro_resize bug.

So I insist, if someone knows where to find pdaxrom sources (kernel and tools) please tell me!

Ash.

[sashz]

Hallo!

sources there:

http://212.192.116.30/pdaXrom/src/

latest builder (patches inside builder) there:

http://212.192.116.30/pdaXrom/src/builder/

sharp utils replacement for sltime and fsro_resize there:

http://212.192.116.30/pdaXrom/src/survive-...e-1.0.0.tar.bz2

qt x11 setting utils there:

http://212.192.116.30/pdaXrom/src/x11rom-s...s-1.0.0.tar.bz2

bye,
sashz

[Ashley]

sashz!! At last!

Thank you!

Here they are. Now I\'m happy, and think many others would be...

Ash

[Ashley]

ikm, I\'ve just tried your tweak: did not work for me.
Now /proc/mtd tells there is a \"Partition_001\" with a size of 0xc800 !!!!!  No, home partition but also no root one!
Seems that wrong commandline fails. Nevertheless, thank you.
Now I\'m able to try many other things ;-)

[ikm]

ikm, I\'ve just tried your tweak: did not work for me.  
Now /proc/mtd tells there is a \"Partition_001\" with a size of 0xc800 !!!!!  No, home partition but also no root one!

Strange... it worked like a charm half a year ago
Now I feel interested. Have you got the same \'mtdparts\' file as the one I attached when you read it from flash with the given \'nandlogical\' command from the given offset?

What does \'dmesg\' say when you boot the maintenance kernel with the tweak applied? What kernel parameters are actually passed?

The whole idea of mine was very simple: as a kernel parameter, mtdparts is apparently built up concatenating the following strings:

1) \"mtdparts=sharpsl-nand:7168k@0k(smf),\" +
2) \"%d\" replaced by the root partition size +
3) \"k@7168k(root),-(home)\"

Now we put a zero instead of \"%d\" so the resulting string #2 is empty,
and change the last string from \"k@7168k(root),-(home)\" to just \"-(root)\".

As a result, new mtdparts parameter will look like
\"mtdparts=sharpsl-nand:7168k@0k(smf),-(root)\"

And it worked exactly as I expected. What do you think?

p.s. Thanks for the nand scheme!

p.p.s. I doubt it is correct to hexview \'systc760.dbk\' because, as I said, Sharp seem to have introduced some sort of wear leveling on \'mtd1\' (smf), so the physical offsets would drift when the data is changed. Not absolutely sure about this though, but it looks like this.

p.p.p.s. I just tried to perform the command I suggested before:

/sbin/nandlogical /dev/mtd1 READ 0x209F4 80 mtdparts

And got exactly the same thing as I attached before. I use factory default SYSTC760.DBK I downloaded from conics.net + pdaxrom 1.0.5 with 50MB root. And I did the very same thing half a year ago with just factory default nand and nothing else, and it was there at the same precise offset too. It should just work, shouldn\'t it?