On Feb 9, 2008 10:28 AM, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: > Hello, > > Sorry for the delay with processing this. > > > On Tue, 5 Feb 2008 00:49:29 +0100 > "Michal Panczyk" <[EMAIL PROTECTED]> wrote: > > > I am not sure how is defconfig generated for h5000 in angstrom, but > > Paul Sokolovsky announced an RFC on ths ML some time ago to generate > > defconfigs for linux-handhelds machines using defconfigman. > > Yes, that's how current defconfigs for linux-hh are maintained, and it > gave us lot of boon already. But as was announced, defconfigman is > interim solution until we switch to fully modular cross-device kernel. > So, to everyone who'd want to make big changes to defconfigman, I'd > recommend to work on that direction instead. > > > If it is > > not the desired way to generate them - let me know - I will just fill > > necessary kernel options to bugzilla. > > > > So I attach 3 files : > > h5000_fix_defconfigman.patch - which includes all the changes that I > > made, touching original files in minimal way > > > > h5000.conf and h5000_crossport.patch - including _alternative_ way to > > achieve the same result. > > Well, as always, "one patch - one change" way is appreciated. So, I'm > looking at the first patch mostly. > > > > > The difference is the style of changes in h5000.conf - the alternative > > way changes the structure of the file - every machine feature except > > for [machine.builtin] is in alphabetical layout. To me, it is clearer > > this way. > > Then, all machines would need to be changed, and I'd prefer to avoid > this as non productive investment of effort, per above. > > > Another thing, included in alternative files, are uncategorized kernel > > options, for which I did not find any proper place in structure of > > defconfigman file: options supporting buzzer and fingerprint scanner. > > There should be another feature put there - light sensor, but it does > > not come as an option in kernel. > > Well, that calls for [machine.other]. > > > Also some options were removed (commented out) as they no longer exist > > in the kernel. > > Can be just removed. > > > > > The kernel configuration file, generated using patched defconfigman, > > differs in better bluetooth support (HCI_UART built for kernel), > > proper sound options and finally usb-host and wifi (just the basic > > driver) built as modules. > > > > What this brings - generally bluetooth support (works when ), and some > > progress to get the sound working (I have play with alsamixer now, but > > I didn't manage to hear any sound.... yet). > > Well, Milan said it works well for him ;-). > > > > > Some more comments that may answer question coming after studding the > > changes : In [machine.flash] options > > #kernel.subsys.mtd.block=y > > MTD_BLKDEVS=y > > MTD_BLOCK=y > > _should_ mean the same, but defconfigman interprets > > kernel.subsys.mtd.block=y as modules and it is impossible to boot > > without kernel panic. > > This is related to recent change from Philipp Zabel: > http://defconfigman.svn.sourceforge.net/viewvc/defconfigman?view=rev&revision=428
Yes, you don't _need_ mtdblock to boot from flash at all. "root=/dev/mtdblock3" is wrong "root=mtd3" is right I'm not sure, but it seems the kernel tries to access the mtd device through the block device translation layer if you use the first option, which is not really what we want. The second issue, why kernel.subsys.mtd.block=y compiles the blockdev translation as modules is not quite clear to me. base.conf has "kernel.subsys.mtd.block ?= m" (this is distro policy), but if you force it to "y" in the machine file afterwards, shouldn't that value be overwritten (apart from the fact that you shouldn't do that in the first place)? > You gentlemen really should figure out what's required for flash boot, > and set those options once and avoid machine hacks. But that still > would be a loop on the way to heaven, as the right way to deal with > that is to have modular kernel with initramfs to boot it off anything > without carrying unneeded load in kernel. Agreed. > > GPIODEV_DIAGONAL works quite well - every key is supported in > > opposite to GPIODEV_KEYS2 where only power button is seen by the > > system (as /dev/input/input1) > > Again, keys2 (which becomes more and more candidate for renaming, I'd > say) were working for Milan. Maybe something uncommitted ;-(. diagonal > is deprecated, hopefully will be removed once we figure this issue out. > > > > > Sleeve support in current state is currently impossible - it breaks > > compilation when CPU_FREQ is selected (gcc mentions something about > > frequency change...) > > Yep, this is known (to me at least) issue. It also breaks building > cpufreq modular. Again, the only real solution is to go fully modular. > > > > > > > The changes I propose can close bugs: > > 2628: No audio driver (ak4535?) built for h5000, > > 3549: h5000 bluetooth support missing, > > and after some minor adaptation (categorize IPAQ_SAMCOP_FSI ) > > 3560: h5000 fingerprint scanner driver not compiled . > > > > If anyone has some comments, I will patiently listen to them.... > > So, h5000_fix_defconfigman.patch is committed, I'll refresh defconfig > in .dev, and I hope you'll prepare [machine.other] with the rest of > options, so we finally can spool all changes to stable as one batch. > > > Thanks! > > > > > Cheers > > Michal > > > > -- > Best regards, > Paul mailto:[EMAIL PROTECTED] > cheers Philipp _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
