OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: doublec on January 14, 2004, 07:04:38 pm
-
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.
-
http://www.cacko.biz/feed/kernel-patches/l....cacko.diff.bz2 (http://www.cacko.biz/feed/kernel-patches/linux.cacko.diff.bz2)
configs:
arch/arm/def-configs/*-cacko
-
Great, thanks!
-
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?
-
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\'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
-
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.
-
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 ;-)
-
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.
-
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.
-
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 (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.
-
Hallo!
sources there:
http://212.192.116.30/pdaXrom/src/ (http://212.192.116.30/pdaXrom/src/)
latest builder (patches inside builder) there:
http://212.192.116.30/pdaXrom/src/builder/ (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 (http://212.192.116.30/pdaXrom/src/survive-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 (http://212.192.116.30/pdaXrom/src/x11rom-settings-1.0.0.tar.bz2)
bye,
sashz
-
sashz!! At last!
Thank you!
Here they are. Now I\'m happy, and think many others would be...
Ash
-
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, 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?
-
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?
Yes.
What does \'dmesg\' say when you boot the maintenance kernel with the tweak applied? What kernel parameters are actually passed?
Kernel command line: console=ttyS0 root=/dev/ram0 mtdparts=sharpsl-nand:7168k@0k(smf),51200-(root) ZAURUS_UPDATE=/etc/update/update_sd
That\'s what I expected before try it, so I said it would be a wrong command line.
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)\".
Hey, where is \"%d\"? I have three zeroes before \"k@7168k(root),-(home)\" even in the original state! How can you avoid bootloader to paste the root partition size?
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.
Yes, that caused my offset difference. Despite of that, seems to be a reliable snapshot.
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?
Have you domesticated your bootlader?
Ash
-
Hallo!
sources there:
http://212.192.116.30/pdaXrom/src/ (http://212.192.116.30/pdaXrom/src/)
latest builder (patches inside builder) there:
http://212.192.116.30/pdaXrom/src/builder/ (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 (http://212.192.116.30/pdaXrom/src/survive-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 (http://212.192.116.30/pdaXrom/src/x11rom-settings-1.0.0.tar.bz2)
bye,
sashz
although the pdaXrom.org site is fast -- I am mirroring this to zaurus.spy.org/feeds/cacko/
Scott
-
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?
Yes.
Good!
What does \'dmesg\' say when you boot the maintenance kernel with the tweak applied? What kernel parameters are actually passed?
Kernel command line: console=ttyS0 root=/dev/ram0 mtdparts=sharpsl-nand:7168k@0k(smf),51200-(root) ZAURUS_UPDATE=/etc/update/update_sd
That\'s what I expected before try it, so I said it would be a wrong command line.
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)\".
Hey, where is \"%d\"? I have three zeroes before \"k@7168k(root),-(home)\" even in the original state! How can you avoid bootloader to paste the root partition size?
It\'s not right there, it is slightly before. First two bytes of the resulting \'mtdparts\' snapshot. My mtdparts_tweaked have a zero instead of \'%\', and that\'s how it works. You must have overlooked it.
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?
Have you domesticated your bootlader?
Yep, that was fun. I just looked inside the original updater.sh and noticed that it should begin with \'#!/bin/sh\'. The obfuscation looked like a direct byte-to-byte mapping. Now you can just keep the first string intact, then add the same string with the first two symbols removed, and you get a nice script:
#!/bin/sh
/bin/sh
:-)
-
ikm, sorry me, I didn\'t realised about the trailind %d. Now I\'ve done things right and IT WORKS!!!!
ONLY THE ROOT PARTITION FILLING THE WHOLE NAND!!! At last!!
Thank you!!
Now, I must install the rom, but making /home to be on root. I can do this using just console, but I think I\'ll try to edit installer.sh, so more people can do that easily.
But before that I\'m going to try my own solution. I\'ll tell if it works.
I have been inspecting fsro_resize source and I think it does it good (sorry sashz, for doubting about you), so the bug must be in the boot loader. Now I understand how PartitionInfo1&2 store partitions. I just had an endianness problem. :evil:
Ash
-
Hey! We have cross-replied!
-
My solution does not work
I have tried to specify the root partition size in MB instead of KB, hardcodding PastitionInfos ROFS size and editing mtdparts command line.
May be I mistaken something, may be anyone want to try it. In my tests, the bootloader fails the same way it does when you resize to more than 63MB with cacko installer: it does not generate any mtdparts= param !!!! Damn bootloader!! :evil:
Hopefully, we have ikm\'s solution. It is perfect for me, is just what I looked for: no home partion at all, full space for root.
Now let\'s try to automate it...
Ash
-
Hopefully we have ikm solution. It is perfect for me, is just what I looked for: no home partion at all, full space for root.
Now let\'s try to automate it...
It\'s very easy to automate, one nandlogical call to get the block, one cmp to ensure the block is right, and another nandlogical call to put the modified version back -- and then reboot, reformat and install
Requires some work in the installation scripts though, if that is the question =)
Would be nice if the pdaxrom team embrace the idea and include the thing in their next version of rom