Re: [Zaurus-devel] 2.6.33-rc1: good news
Andrea Adami wrote: > 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 ;) Me too, but this dictionary was always visible, just with a bad description. It seems to be a file in DB-3 format, so it should not be hard to digg into it and write a simple application: On 2.6.26: r...@zaurus:~# file -s /dev/mtd0 /dev/mtd0: DBase 3 data file (1031668283 records) Well, number of records looks incorrect, but it may be endian change problem. The real addition is the bootloader partition. It has not a big value, except: - You see everything you can see. - People who want to copy their PROM contents for emulator, don't have to patch kernel to be able to do 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
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] 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] 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
Re: [Zaurus-devel] 2.6.33-rc1: good news
Unfortunately I have a fresh report from JaMa about wrong /proc/partitions starting with mtd0 System Area :/ 2 options: my defconfigs are bad (I hope) or there is a bug ... Cheers 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
Hello, still lacking the rom partition in mtd0. Partitions count is wrong (kernel in mtd0). I would hope the corgi OOB/BBT are ok... And about MMC, I suppose I'm doing something wrong because if I exchange the SD card and reScan the kexecboot menu removes the old entries but doesn't list the new ones (are not yet in /proc/partitions ?) Strangely I had report that on spitz these two issues are unknown! I updated the kernel config for spitz/akita with minor edits of c7x0 defconfig: if this one is fine on c3xxx (the rom is listed in mtd0 and SD cards are detected on rescan), then it would be a corgi specific problem. http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/kexecboot/linux-kexecboot-2.6.32+2.6.33-rc3 Thanks in advance for testing 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:
> well, I reply to myself:
>
> in sharpsl-flash.c we had:
>
> static struct mtd_partition sharpsl_partitions[1] = {
> <-->{
> <--><-->name:<-><-->"Boot PROM Filesystem",
> <-->}
> };
This was a map for PROM, and it was incorrect! "Boot PROM Filesystem" is
in fact EN-JP DB3 file-partition (at least for spitz). I fixed it for
spitz.c, but not for other models. Note that it will change numbering of
partition (it is not stable anyway and depends on order of modules
load).
>
> Now in corgi.c we have:
>
> static struct mtd_partition sharpsl_nand_partitions[] = {
> <-->{
> <--><-->.name = "System Area",
> <--><-->.offset = 0,
> <--><-->.size = 7 * 1024 * 1024,
> <-->},
> <-->{
> <--><-->.name = "Root Filesystem",
> <--><-->.offset = 7 * 1024 * 1024,
> <--><-->.size = 25 * 1024 * 1024,
> <-->},
> <-->{
> <--><-->.name = "Home Filesystem",
> <--><-->.offset = MTDPART_OFS_APPEND,
> <--><-->.size = MTDPART_SIZ_FULL,
> <-->},
> };
And this is a map for NAND.
> Same in spitz.c
For spitz.c (borzoi and terrier, probably also spitz), reads for NAND
and PROM works - *_nand_platform_data is correctly filled.
All the partition mapping (map, possibly badblock pattern (BBT) and
ecc_layout (OOB)) has to be completely moved from map files to platform
definition.
For flash memories using a standard format, BBT and OOB are filled by
the MTD driver, but for some reason, some of Zaruses (e. g. borzoi and
terrier, maybe more) use non-standard NAND structure. If you don't
define it, you'll fail to read NAND (well, reading from NAND works
correctly, but kernel thinks, that checksum in the OOB area are
incorrect and the block is bad). Symptoms: NAND errors reported in
syslog.
Note: Even spitz and borzoi have different NAND OOB structure.
See my mails:
Zaurus: Fix PROM partition table for spitz
Zaurus: Fix NAND Flash OOB layout for Borzoi
And Pavel's patch:
2.6.32-rc7: compile regression on spitz
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
well, I reply to myself:
in sharpsl-flash.c we had:
static struct mtd_partition sharpsl_partitions[1] = {
<-->{
<--><-->name:<-><-->"Boot PROM Filesystem",
<-->}
};
Now in corgi.c we have:
static struct mtd_partition sharpsl_nand_partitions[] = {
<-->{
<--><-->.name = "System Area",
<--><-->.offset = 0,
<--><-->.size = 7 * 1024 * 1024,
<-->},
<-->{
<--><-->.name = "Root Filesystem",
<--><-->.offset = 7 * 1024 * 1024,
<--><-->.size = 25 * 1024 * 1024,
<-->},
<-->{
<--><-->.name = "Home Filesystem",
<--><-->.offset = MTDPART_OFS_APPEND,
<--><-->.size = MTDPART_SIZ_FULL,
<-->},
};
Same in spitz.c
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
> > 1) lack of sharpsl-flash (mtdblock1) I mean PROM on mtd0 and kernel in mtd1 > how can I revive it and have root in mtd2 and a second jffs2 image on mtd3 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
Hi, testing 2.6.33-rc3 on corgi, with limited configuration for kexecboot. Kexecbooy fails with >2.6.30 kernels , with open flash: No such device. I found out in the code the reason: we hardcode some mtd readings...see issue #1 Issues not present fin 2.6.26 found so far: 1) lack of sharpsl-flash (mtdblock1) Well, I discovered the map sharpsl-flash.c was removed (http://lists.infradead.org/pipermail/linux-mtd/2009-April/025186.html) how can I revive it and have root in mtdblock2? 2) no suspend (dunno resume ;) 3) sd card is not detected after eject/reinsert (the reScan code in kexecboot) Possibly my defconfig ( http://tinyurl.com/yckax6l ) is sub-optimal...I'm open to all suggestions :) 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
Hi! >Can you share the config you used for spitz? >I tried rc1 last week and rc2 yesterday (as 2nd stage kernel as well as >linux-kexecboot), but still have issues with framebuffer/lcd (slowly going >to all white WSOD or quickly all black - like backlight/lcd turned off). >When it booted a bit farther, then it failed because of missing rtc0 node >when tried to sync clock - CONFIG_RTC_HCTOSYS was enabled, without this >option it hangs there too :/. >And in rc2 i wasn't able to compile pxafb without attached patch. This works for me, 2.6.33-rc1. If it does not compile in -rc2, please scream 'regression' on lkml and l-a-k, so that it gets fixed. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.33-rc1 # Fri Dec 18 21:17:00 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_MTD_XIP=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set # CONFIG_TINY_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # # Kernel Performance Events And Counters # CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_BLOCK=y CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # CONFIG_INLINE_SPIN_TRYLOCK is not set # CONFIG_INLINE_SPIN_TRYLOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK is not set # CONFIG_INLINE_SPIN_LOCK_BH is not set # CONFIG_INLINE_SPIN_LOCK_IRQ is not set # CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set CONFIG_INLINE_SPIN_UNLOCK=y # CONFIG_INLINE_SPIN_UNLOCK_BH is not set CONFIG_INLINE_SPIN_UNLOCK_IRQ=y # CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_READ_TRYLOCK is not set # CONFIG_INLINE_READ_LOCK is not set # CONFIG_INLINE_READ_LOCK_BH is not set # CONFIG_INLINE_READ_LOCK_IRQ is not set # CONFIG_INLINE_READ_LOCK_IRQSAVE is not set CONFIG_INLINE_READ_UNLOCK=y # CONFIG_INLINE_READ_UNLOCK_BH is not set CONFIG_INLINE_READ_UNLOCK_IRQ=y # CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set # CONFIG_INLINE_WRITE_TRYLOCK is not set # CONFIG_INLINE_WRITE_LOCK is not set # CONFIG_INLINE_WRITE_LOCK_BH is not set # CONFIG_INLINE_WRITE_LOCK_IRQ is not set # CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set CONFIG_INLINE_WRITE_UNLOCK=y # CONFIG_INLINE_WRITE_UNLOCK_BH is not set CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set # CONFIG_MUTEX_SPIN_ON_OWNER is
Re: [Zaurus-devel] 2.6.33-rc1: good news
Hi, Can you share the config you used for spitz? I tried rc1 last week and rc2 yesterday (as 2nd stage kernel as well as linux-kexecboot), but still have issues with framebuffer/lcd (slowly going to all white WSOD or quickly all black - like backlight/lcd turned off). When it booted a bit farther, then it failed because of missing rtc0 node when tried to sync clock - CONFIG_RTC_HCTOSYS was enabled, without this option it hangs there too :/. And in rc2 i wasn't able to compile pxafb without attached patch. Regards, On Sun, Dec 20, 2009 at 8:43 AM, Pavel Machek wrote: > > Not only it boots on spitz, it suspends/resumes too. Obviously more > testing is needed, but... good news so far. > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > ___ > Zaurus-devel mailing list > Zaurus-devel@lists.linuxtogo.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel > pxafb_platform_data_access.patch Description: Binary data ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
