Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ikm

Pages: 1 ... 10 11 [12]
166
Zaurus - pdaXrom / Playing Video on pdaXrom
« on: April 15, 2004, 08:27:40 am »
Quote
ikm

Have you actually done this? Are you able to run mplayer fullscreen? Do you have a compiled binary or ipk?

Yes. It works fullscreen and plays smoothly.

You can just grab the binary from the Debian project, it works.

http://ftp.us.debian.org/debian/pool/main/...2.1-6.1_arm.deb

It\'s in Debian .deb format though, you will have to have linux on the desktop to use either \'dpkg-deb -X fbset_2.1-6.1_arm.deb .\', or \'ar x fbset_2.1-6.1_arm.deb\' and then \'tar xfz data.tar.gz\'. Alternatively it maybe possible to install .deb with ipkg, but I would not recommend.

If somebody\'s willing to put that binary for download somewhere, I can send it. Or he can just extract it himself and put it somewhere

p.s. Beware that console would be screwed up too. It just screws up everything because everything is supposed to work in 640x480 only. The video plays fullscreen perfectly, either from X or from console. It just leaves a mess after itself =) Changing framebuffer to 640x480 right after mplayer exits would help, but not entirely.

167
Zaurus - pdaXrom / Kernel source
« on: April 14, 2004, 01:47:14 pm »
Quote
 
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

168
Zaurus - pdaXrom / Playing Video on pdaXrom
« on: April 14, 2004, 01:04:11 pm »
Quote
If someone could help us to find an issue for enable QVGA, it could be very useful.

It is very simple actually. It is supported out of the box by the Zaurus framebuffer device driver. You just need to know how to tell it about your needs

There is a standard tool to perform mode switching on framebuffer devices, it is called \'fbset\'. Pdaxrom includes a version of it, but unfortuately, the version supplied (from the busybox suite) is not configured right and so is quite useless.

It has to be recompiled to be useful. With normal \'fbset\', you just do

fbset -xres 320 -yres 240

or

fbset \'mode name\', where mode configurations reside in /etc/fb.modes

and it works

Pdaxrom developers, would you please turn on one option in your busybox configuration?  It\'s \"Linux System Utilities -] fbset -] Turn on fbset readmode support\". The tool would be useful then.

The other problem is that changing current video mode would screw up the running X server. And it has no use with X11 applications

I would actually very much enjoy if the pdaXrom X server supported mode switching via xrandr. ATI Imageon chip supports both 320x240 and 240x320 in hardware. We would have a nice fullscreen performance with games and video, that would be totally awesome!

169
Zaurus - pdaXrom / Kernel source
« on: April 14, 2004, 12:20:12 pm »
Quote
Quote

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!

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

Quote
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.

Quote
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.

Quote
Quote
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

:-)

170
Zaurus - pdaXrom / Kernel source
« on: April 14, 2004, 08:55:34 am »
Quote
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?

171
Zaurus - pdaXrom / Kernel source
« on: April 13, 2004, 02:30:58 pm »
Quote
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.

172
Zaurus - pdaXrom / Kernel source
« on: April 13, 2004, 10:35:44 am »
Quote
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.

Pages: 1 ... 10 11 [12]