Re: [Zaurus-devel] 2.6.33-rc1: good news
On Wed, Jan 13, 2010 at 12:08:05AM +0100, Stanislav Brabec wrote: > Martin Jansa wrote: > > On Tue, Jan 12, 2010 at 01:36:31PM +0100, Stanislav Brabec wrote: > > > > > > Note: I sent a patch to the kernel that fixes PROM layout and introduces > > > two partitions in PROM: Boot PROM System and EN-JP DB3. > > > > With 2.6.32-rc3 I don't see that 2nd PROM partition and didn't noticed > > any special Kconfig option for that (in case someone wanted to make your > > change optional) > > Patch was not yet applied. You can apply it from the list. Maybe I will > re-send and add config option. Yes config option could be usefull for those depending on same mtd numbering as was in older kernels. > In fact, the partition called "Boot PROM Filesystem" is a DB3 file that > contains English-Japanese dictionary. I guess that there is no Boot PROM > Filesystem, but a bootloader. It is invisible in current kernels. With your patch and physmap in kernel its as expected dev:size erasesize name mtd0: 0070 0080 "Boot PROM System" mtd1: 006c 0080 "EN-JP Data File" mtd2: 0070 4000 "smf" mtd3: 0050 4000 "root" mtd4: 0040 4000 "home" ANG r...@zjama ~ $ dd if=/dev/mtdblock1 of=en-jp.dict.dbf bs=1024 6912+0 records in 6912+0 records out Lets see if I can learn JP a bit from it :). > I can only guess why designers decided to place translation dictionary > to the fast and expensive mask-programmable PROM. -- uin:136542059jid:martin.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
Ok, I can finally confirm all works 'as before'. Was just a matter of adding CONFIG_MTD_PHYSMAP=y Stanislav, I don't know how much useful that dictionary could be...it doesn't seem worth breaking the partition order, though ;) Thx Andrea ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
Martin Jansa wrote: > On Tue, Jan 12, 2010 at 01:36:31PM +0100, Stanislav Brabec wrote: > > > > Note: I sent a patch to the kernel that fixes PROM layout and introduces > > two partitions in PROM: Boot PROM System and EN-JP DB3. > > With 2.6.32-rc3 I don't see that 2nd PROM partition and didn't noticed > any special Kconfig option for that (in case someone wanted to make your > change optional) Patch was not yet applied. You can apply it from the list. Maybe I will re-send and add config option. In fact, the partition called "Boot PROM Filesystem" is a DB3 file that contains English-Japanese dictionary. I guess that there is no Boot PROM Filesystem, but a bootloader. It is invisible in current kernels. I can only guess why designers decided to place translation dictionary to the fast and expensive mask-programmable PROM. Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
On Tue, Jan 12, 2010 at 01:36:31PM +0100, Stanislav Brabec wrote: > Andrea Adami wrote: > > Hello Stanislav, > > > > > Unfortunately I have a fresh report from JaMa about wrong... > > > > BTW this was on Spitz. So the question is: does the prom appear > > somewhere in /proc/partitions? I could not find it on say mtd3... > > It should (I don't have the latest vanilla just now). And > using /proc/mtd it could be identified. I can confirm that 2.6.32+ kernels pushed to OE didn't have physmap enabled, that's why the mtdN naming was different than with 2.6.26 With physmap as module sharpsl in kernel I can see 4th partition and I except that it will be named mtd0 as before if i add physmap to kernel instead as module. ANG r...@zjama ~ $ cat /proc/mtd dev:size erasesize name mtd0: 0070 4000 "System Area" mtd1: 0050 4000 "Root Filesystem" mtd2: 0040 4000 "Home Filesystem" mtd3: 006c 0080 "Boot PROM Filesystem" > > > Kernel makes no guarantee of partition order. It depends on order of > > > evaluation. If both drivers (PROM, NAND) are in modules, it can vary > > > even across reboots. > > > > Ok, so what to do? Patch the kernel? > > It is more generic problem. It seems that kernel does not guarantee > order of devices. The order changed even for CF slots: In 2.6.26 > internal slot was listed first. Now external slot is listed first. This i can confirm too, without any CF (or just wifi card in CF slot) I have microdrive as hda, with CF is CF named as hda and and microdrive wasn't detected by kexecboot kernel at all (probably kexecboot bug?). If I boot system from uSD then I see CF card as hda and microdrive as hdc. > The same problem affects keyboard (kernel with CE-RH2 remote support > enumerates touchscreen differently. > > > How do other boards with NOR and NAND do? > > Modern devices use OneNAND or similar and don't need any PROM. With a > single MTD, numbers are stable. > > But this is critical problem only for boot. In the user space, there is > a lot of chances to prevent it (udev, mount by ID). > > > Imho we should respect the factory layout and keep kernel in mtd1. > > Note: I sent a patch to the kernel that fixes PROM layout and introduces > two partitions in PROM: Boot PROM System and EN-JP DB3. With 2.6.32-rc3 I don't see that 2nd PROM partition and didn't noticed any special Kconfig option for that (in case someone wanted to make your change optional) > So it would not be possible. Either mtd0 or mtd2. > > SharpROM$ cat /proc/mtd > dev:size erasesize name > mtd0: 006b 0002 "Filesystem" > mtd1: 0070 0002 "smf" > mtd2: 02b0 0002 "root" > mtd3: 04e0 0002 "home" Regrards and thanks to all kernel hackers for increased interest in Zaurus support! -- uin:136542059jid:martin.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
> Stanislav Brabec > http://www.penguin.cz/~utx/zaurus Stanislav, thanks for the long explanations! We'll retry the all-static in kernel way, lets's hope it produces deterministic results. >root at zaurus:~# modprobe physmap Ah.. actually I think my config lacks physmap...he >In the last case, I am not sure, whether external CF may be hda1 fort >spitz. Well, JaMa had strange issues: CF card OR internal HD was found. Not the two together. Needs further debug. Thanks Andrea ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
Andrea Adami wrote: > > But this is critical problem only for boot. In the user space, there is > > a lot of chances to prevent it (udev, mount by ID). > ... > > So it would not be possible. Either mtd0 or mtd2. > > ok, so the only issue could be with pre 2.6.30 kernels / userspaces ? No. It is generic. It depends on the .config and order of drivers load (it should be stable if it is compiled into kernel and arbitrary for modules). Before my patch[1]: kernel in mtd0 or mtd1 After my patch: kernel in mtd0 or mtd2 > With patched kexecboot I got now get : > > Got device '/dev/mtdblock0' (31, 0) of size 7Mb > Probing /dev/mtdblock0 > FS could not be identified > Can't detect FS type > Got device '/dev/mtdblock1' (31, 1) of size 53Mb > Probing /dev/mtdblock1 > + FS on device is jffs2 > Got device '/dev/mtdblock2' (31, 2) of size 68Mb > Probing /dev/mtdblock2 > + FS on device is jffs2 > Got device '/dev/mmcblk0' (179, 0) of size 489Mb > Probing /dev/mmcblk0 > FS could not be identified > Can't detect FS type > Got device '/dev/mmcblk0p1' (179, 1) of size 486Mb > Probing /dev/mmcblk0p1 > + FS on device is ext2 > Can't read next device line > Found 3 items > + processing 0: angstrom > + processing 1: angstrom > + processing 2: angstrom > * maximum priority 0 found at 0 > + [angstrom > /dev/mtdblock1 jffs2 53Mb] > + processing 1: angstrom > + processing 2: angstrom > * maximum priority 0 found at 1 > + [angstrom > /dev/mtdblock2 jffs2 68Mb] > + processing 2: angstrom > * maximum priority 0 found at 2 This list indicates: - NAND support loads first, PROM support is not (yet) loaded (for example NAND support in kernel and PROM support as module or so). > + [angstrom > /dev/mmcblk0p1 ext2 486Mb] > load_argv: /usr/sbin/kexec, -l, --command-line=root=/dev/mtdblock2 This is the last partition of NAND. > What will happen booting a 2.6.26 kernel? > In fstab we have: > rootfs / autodefaults1 1 > How will be translated "mtdblock2 (31, 2) of size 68Mb" ? rootfs or /dev/root should be converted to the partition from the kernel command line. Is there available "boot by ID" feature? It may work across all 2.6 kernels. You may have a problem, because the new kernel may see a different partition number. > Finally, I'd like to fix the recipes of kexecboot and nandlogical in > order to respect the new layout. > Perhaps with some version-checking logic? Partition numbering depends on: - kernel version - kernel .config (what is compiled into kernel and what as module) - If both NAND and PROM support are in modules, then it is unpredictable. In worst case heuristic may help: grep kernel (2.6) for strings: "Boot PROM Filesystem" found: NAND smf=mtd1 NAND root=mtd2 NAND home=mtd3 "Boot PROM System" found: NAND smf=mtd2 NAND root=mtd3 NAND home=mtd4 [1] "Boot PROM Filesystem" nor "Boot PROM System" found: NAND smf=mtd0 NAND root=mtd1 NAND home=mtd2 "System Area" not found: Kernel cannot boot from NAND (e. g. hdd boot) In the last case, I am not sure, whether external CF may be hda1 fort spitz. If yes, the same problem affects internal HDD detection. (The order of CF slots changed sometimes after 2.6.26.) > Happily updater.sh relying on 2nd 2.4 kernel still works vanilla. Yes. [1]http://lists.infradead.org/pipermail/linux-arm-kernel/2009-October/002697.html I am not sure, whether it was accepted. If not, I plan to resend it. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
> But this is critical problem only for boot. In the user space, there is > a lot of chances to prevent it (udev, mount by ID). ... > So it would not be possible. Either mtd0 or mtd2. ok, so the only issue could be with pre 2.6.30 kernels / userspaces ? With patched kexecboot I got now get : Got device '/dev/mtdblock0' (31, 0) of size 7Mb Probing /dev/mtdblock0 FS could not be identified Can't detect FS type Got device '/dev/mtdblock1' (31, 1) of size 53Mb Probing /dev/mtdblock1 + FS on device is jffs2 Got device '/dev/mtdblock2' (31, 2) of size 68Mb Probing /dev/mtdblock2 + FS on device is jffs2 Got device '/dev/mmcblk0' (179, 0) of size 489Mb Probing /dev/mmcblk0 FS could not be identified Can't detect FS type Got device '/dev/mmcblk0p1' (179, 1) of size 486Mb Probing /dev/mmcblk0p1 + FS on device is ext2 Can't read next device line Found 3 items + processing 0: angstrom + processing 1: angstrom + processing 2: angstrom * maximum priority 0 found at 0 + [angstrom /dev/mtdblock1 jffs2 53Mb] + processing 1: angstrom + processing 2: angstrom * maximum priority 0 found at 1 + [angstrom /dev/mtdblock2 jffs2 68Mb] + processing 2: angstrom * maximum priority 0 found at 2 + [angstrom /dev/mmcblk0p1 ext2 486Mb] load_argv: /usr/sbin/kexec, -l, --command-line=root=/dev/mtdblock2 rootfstype=jffs2 rootwait console=ttyS0,115200n8 console=tty1 noinitrd debug, /mnt/boot/zImage No network is detected, disabling ifdown() exec_argv: /usr/sbin/kexec, -e, -x Uncompressing Linux... What will happen booting a 2.6.26 kernel? In fstab we have: rootfs / autodefaults1 1 How will be translated "mtdblock2 (31, 2) of size 68Mb" ? Finally, I'd like to fix the recipes of kexecboot and nandlogical in order to respect the new layout. Perhaps with some version-checking logic? Happily updater.sh relying on 2nd 2.4 kernel still works vanilla. Regards Andrea ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] corgi_ts
Yuri Bushmelev wrote: > > Interesting :-). Is it still possible to buy this kind of remote > > control somewhere / does anyone have any extra / ... I guess it should > > be quite easy to make one...? > > You can make it yourself. Here is manual in german: > http://www.relei.de/zaurusfernb.html There is an incorrect value in the table. To Rene Kommzu: Could you fix marked values, please? Correct resistor values for CE-RH2 (serial connection of resistors): R1 330 Ohm Stop R2 470 Ohm Play/Pause R3 680 Ohm Next Song R4 910 Ohm Volume Up R5 1.5 kOhm Previous Song R6 3.3 kOhm Mute R7 10 kOhm Volume Down<-- Resistances (for serial connection): And in table Testwerte zwischen Pin "GND und Key" please also correct: T7 17190 Ohm <-- -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
Andrea Adami wrote: > Hello Stanislav, > > > Unfortunately I have a fresh report from JaMa about wrong... > > BTW this was on Spitz. So the question is: does the prom appear > somewhere in /proc/partitions? I could not find it on say mtd3... It should (I don't have the latest vanilla just now). And using /proc/mtd it could be identified. > > Kernel makes no guarantee of partition order. It depends on order of > > evaluation. If both drivers (PROM, NAND) are in modules, it can vary > > even across reboots. > > Ok, so what to do? Patch the kernel? It is more generic problem. It seems that kernel does not guarantee order of devices. The order changed even for CF slots: In 2.6.26 internal slot was listed first. Now external slot is listed first. The same problem affects keyboard (kernel with CE-RH2 remote support enumerates touchscreen differently. > How do other boards with NOR and NAND do? Modern devices use OneNAND or similar and don't need any PROM. With a single MTD, numbers are stable. But this is critical problem only for boot. In the user space, there is a lot of chances to prevent it (udev, mount by ID). > Imho we should respect the factory layout and keep kernel in mtd1. Note: I sent a patch to the kernel that fixes PROM layout and introduces two partitions in PROM: Boot PROM System and EN-JP DB3. So it would not be possible. Either mtd0 or mtd2. SharpROM$ cat /proc/mtd dev:size erasesize name mtd0: 006b 0002 "Filesystem" mtd1: 0070 0002 "smf" mtd2: 02b0 0002 "root" mtd3: 04e0 0002 "home" -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] corgi_ts
Hello! > > I wrote a part of resistive_keypad driver[1], but did not finish it. > > Interesting :-). Is it still possible to buy this kind of remote > control somewhere / does anyone have any extra / ... I guess it should > be quite easy to make one...? You can make it yourself. Here is manual in german: http://www.relei.de/zaurusfernb.html -- Yuri Bushmelev ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
Hello Stanislav, > Unfortunately I have a fresh report from JaMa about wrong... BTW this was on Spitz. So the question is: does the prom appear somewhere in /proc/partitions? I could not find it on say mtd3... > Kernel makes no guarantee of partition order. It depends on order of > evaluation. If both drivers (PROM, NAND) are in modules, it can vary > even across reboots. Ok, so what to do? Patch the kernel? How do other boards with NOR and NAND do? Imho we should respect the factory layout and keep kernel in mtd1. Andrea ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
Andrea Adami wrote: > Unfortunately I have a fresh report from JaMa about wrong > /proc/partitions starting with mtd0 System Area :/ Kernel makes no guarantee of partition order. It depends on order of evaluation. If both drivers (PROM, NAND) are in modules, it can vary even across reboots. Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
