| 02:27.55 | *** join/#htc-linux psokolovsky (n=psokolov@ip.85.202.124.214.dyn.sub-9.broadband.voliacable.com) |
| 05:39.50 | *** join/#htc-linux rejon (n=rejon@64-121-195-22.c3-0.sfpo-ubr4.sfrn-sfpo.ca.cable.rcn.com) |
| 05:40.30 | *** part/#htc-linux rejon (n=rejon@64-121-195-22.c3-0.sfpo-ubr4.sfrn-sfpo.ca.cable.rcn.com) |
| 05:48.23 | *** join/#htc-linux Kmarc (i=kari@markos.biz) |
| 08:06.59 | *** join/#htc-linux apt (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 08:06.59 | *** topic/#htc-linux is HTC LINUX ! check also -> http://handhelds.org/moin/moin.cgi/HTC_2dPhones | http://wiki.xda-developers.com/index.php?pagename=BlueangelResearch | http://gnulinux.biz/files/ LOGS: at http://ibot.rikers.org/%23htc-linux/ |
| 09:07.11 | *** join/#htc-linux pleemans (n=peter@d51A5E421.access.telenet.be) |
| 09:17.07 | *** join/#htc-linux sylvain (n=sylvain@APuteaux-154-1-37-13.w83-199.abo.wanadoo.fr) |
| 10:39.48 | *** join/#htc-linux LunohoD (n=alex@e180122079.adsl.alicedsl.de) |
| 11:45.03 | *** join/#htc-linux seishin_ (n=seishin@e177184201.adsl.alicedsl.de) |
| 12:03.48 | *** join/#htc-linux apt (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 12:03.48 | *** topic/#htc-linux is HTC LINUX ! check also -> http://handhelds.org/moin/moin.cgi/HTC_2dPhones | http://wiki.xda-developers.com/index.php?pagename=BlueangelResearch | http://gnulinux.biz/files/ LOGS: at http://ibot.rikers.org/%23htc-linux/ |
| 13:10.51 | *** join/#htc-linux booba (n=booba@81.56.252.135) |
| 13:15.50 | *** join/#htc-linux jeanseb (n=jeanseb@88.164.32.155) |
| 13:19.59 | *** join/#htc-linux psokolovsky (n=psokolov@ip.85.202.124.214.dyn.sub-9.broadband.voliacable.com) |
| 15:17.53 | *** join/#htc-linux rob_w (n=bob@p85.212.183.227.tisdip.tiscali.de) |
| 15:24.04 | *** join/#htc-linux BabelOued (n=Fabrice@lun34-2-82-238-28-28.fbx.proxad.net) |
| 16:33.11 | *** join/#htc-linux lamikr (n=chatzill@aragorn.kortex.jyu.fi) |
| 16:41.58 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
| 16:59.48 | *** part/#htc-linux sylvain (n=sylvain@APuteaux-154-1-37-13.w83-199.abo.wanadoo.fr) |
| 17:52.37 | *** join/#htc-linux g3gg0_ (n=g3gg0@ppp-88-217-1-178.dynamic.mnet-online.de) |
| 17:58.36 | *** join/#htc-linux pH5 (n=ph5@e178225001.adsl.alicedsl.de) |
| 17:58.47 | *** join/#htc-linux dullard (n=jim@adsl-static-1-30.uklinux.net) |
| 18:02.13 | *** join/#htc-linux goxboxlive (n=goxboxli@9.80-202-160.nextgentel.com) |
| 18:54.56 | *** join/#htc-linux rob__w (n=bob@p85.212.182.185.tisdip.tiscali.de) |
| 18:55.26 | lkcl | allo darlins |
| 19:07.59 | psokolovsky | Hi! |
| 19:08.24 | psokolovsky | goxboxlive: acking upgrade of universal kernel in OE.dev to -hh2? |
| 19:10.54 | goxboxlive | Yes i saw that you had done that. I did it localy when you renamed the handhelds-pxa to linux-handhelds. It works. It should also be corrected in the angstrom.conf file. |
| 19:11.24 | psokolovsky | goxboxlive, ok, thanks |
| 19:33.57 | lkcl | bizarre! mmc now works... i think you're right about 10 second delay, asylumed. |
| 19:34.29 | lkcl | basically, i believe it might be that if mmc is initialised early enough in the hardware detection (in some random order of course) then by the time it comes to a root mount, you're ok. |
| 19:34.45 | lkcl | but if (like i have - and probably you too) there are only a few devices to initialise at boot-up... |
| 19:34.53 | lkcl | gonna try that 10 second delay thing... |
| 19:38.47 | psokolovsky | lkcl, that's pretty strange, I'd say. sable uses asic3_mmc, right? |
| 19:39.38 | lkcl | yep |
| 19:39.59 | lkcl | i just ssh'd in, via my nfs root-mount |
| 19:40.17 | lkcl | and manually mounted the partition |
| 19:40.23 | lkcl | and it worked |
| 19:40.35 | psokolovsky | lkcl, 10sec is way too much. try 1 sec. but I didn't hear about such issue with h1910, h3900, h4000, hx4700 |
| 19:41.00 | lkcl | but - at kernelboot root=/dev/mmcblk0p2 rootdelay=3 it dont work |
| 19:41.25 | lkcl | btw have small baby so ty[ing one-handed :) |
| 19:42.28 | psokolovsky | ;-) |
| 19:43.01 | psokolovsky | lkcl, can you try RamdiskRescue next sweet day and report how it goes? |
| 19:44.48 | lkcl | arse! 10 sec not ok either |
| 19:45.21 | lkcl | something really weird goin on |
| 19:45.28 | psokolovsky | lkcl, the problem in sth else. |
| 19:45.54 | psokolovsky | lkcl, are sure you don't have extra stuff around asic3 SD controller? |
| 19:46.02 | psokolovsky | for example, h3900 has |
| 19:46.13 | lkcl | que? clueless |
| 19:46.20 | lkcl | this is rev-eng... |
| 19:46.39 | psokolovsky | h3900 has extra clock control via asic2 |
| 19:46.44 | lkcl | hmmm i wonder if card needs reinserting |
| 19:46.50 | lkcl | yeh i noticed |
| 19:47.08 | lkcl | i justlooked 30m ago @ |
| 19:47.10 | psokolovsky | reinserting works every 2nd time for me ;-) |
| 19:47.18 | lkcl | h3900_mmc.c |
| 19:47.38 | psokolovsky | btw, h3900 in CVS doesn't work at it, conversion is still pending |
| 19:52.00 | psokolovsky | lol |
| 20:16.52 | pH5 | lkcl: now if only haret could load the kernel via nfs... |
| 20:27.09 | lkcl | oh yeh - good point. well - that shouldn't actually be too difficult. |
| 20:27.58 | lkcl | fucking hell the touchscreen device i hacked together works |
| 20:28.14 | lkcl | does anyone know of any test programs hmm hexdump? |
| 20:31.15 | lkcl | does this look reasonable for a raw dump from ts0? |
| 20:31.19 | lkcl | 0000000 0001 0000 0000 0e8c 0000 0000 0000 020c |
| 20:31.19 | lkcl | 0000010 0001 0000 0000 04c8 0000 0000 0000 24d0 |
| 20:31.19 | lkcl | 0000020 0001 0000 0000 1e90 0000 0000 0000 22dc |
| 20:34.18 | psokolovsky | yep |
| 20:34.48 | lkcl | bloody hell. |
| 20:35.29 | lkcl | well that was quick. all i did was copy the htcuniversal_ts.c then look at h4700_ts.c and use a direct GPIO pin (115) instead of the asic3 gpio (which the universal uses) |
| 20:37.05 | *** join/#htc-linux cr2 (n=konversa@crpl22.physik.uni-wuppertal.de) |
| 20:37.08 | lkcl | wow. i nearly have enough to run the opie/familiar thing - esp. if i mount it over nfs instead... |
| 20:37.14 | lkcl | allo cr2. welcome to the party |
| 20:37.32 | cr2 | good evening. 30min for some asocial behavour :) |
| 20:37.37 | lkcl | i got udc and touchscreen working on the thingy. |
| 20:37.42 | lkcl | hurrah! |
| 20:37.43 | cr2 | great. |
| 20:37.51 | psokolovsky | lkcl, did you keep schedule of the port? woudl be nice to know how much time it took |
| 20:37.51 | lkcl | that kind of asocial? |
| 20:38.11 | lkcl | yep. http://wiki.xda-developers.com/index.php?pagename=SableProgress |
| 20:38.13 | lkcl | not a lot :) |
| 20:38.22 | cr2 | lkcl: porting linux to nice shiny m$ pdas. |
| 20:39.05 | cr2 | lkcl: MTYPE is autodetected. 64M is hardcoded for wince5 pdas. |
| 20:39.27 | lkcl | mwahahaha |
| 20:39.36 | cr2 | sp your startup.txt is too big. |
| 20:40.02 | cr2 | Kevin2 has written some code to get rid of startup.txt completely. |
| 20:40.17 | cr2 | if you link the kernel to haret. |
| 20:40.40 | lkcl | cr2: ph5 suggested doing an nfs client in gnuharet to load the kernel :) |
| 20:40.47 | cr2 | lkcl: what about the touchscreen ? |
| 20:41.10 | cr2 | i wonder why do you need nfs ? does asic3_mmc work ? |
| 20:41.48 | lkcl | touchscreen works fine! |
| 20:42.18 | lkcl | asic3_mmc only works _after_ booting up in nfs |
| 20:42.36 | lkcl | it doesn't work as a root device - not even after putting in a delay of 10 seconds (rootdelay=10) |
| 20:42.37 | cr2 | weird. |
| 20:42.51 | cr2 | you don't need any delays on universal. |
| 20:43.11 | cr2 | on blueangel the current code does not detect the ro status. |
| 20:43.36 | cr2 | there is an asic3 gpio for that, contrary to all other asic3 pdas. |
| 20:43.41 | lkcl | oh great |
| 20:44.09 | cr2 | do you have a SD ro gpio ? |
| 20:44.16 | lkcl | i found the sdcard asic3 gpio |
| 20:44.20 | lkcl | no idea... |
| 20:44.25 | cr2 | btw, which ts driver did you take ? |
| 20:44.28 | lkcl | brb - keep talking... |
| 20:44.32 | lkcl | htcuniversal_ts.c |
| 20:44.33 | psokolovsky | cr2, so, we really need to look towards asic3_mmc/tmio_mmc integration and having handlers for all the stuff |
| 20:44.40 | cr2 | you mean SD card detect gpio ? |
| 20:45.35 | cr2 | psokolovsky: hi. agreed. it seems that all htc pdas have the SD detect gpio, but we ignore it on all devices. |
| 20:45.43 | psokolovsky | Hi! ;-) |
| 20:45.53 | psokolovsky | ok |
| 20:45.54 | cr2 | maybe because of the root on SD . |
| 20:46.20 | psokolovsky | I'm sure that r/o is detected on h4000 |
| 20:46.25 | lkcl | yep sdcard detect |
| 20:46.37 | psokolovsky | i mean, it *is* detected ;-) |
| 20:46.48 | psokolovsky | sure it is detected on hx4700 |
| 20:47.11 | cr2 | ok. but the SD ro gpio seems to be available only on blueangel. |
| 20:47.33 | lkcl | noticed some weird stuff in hx4700 about cken |
| 20:47.58 | cr2 | psokolovsky: is it possible to do 'rmmod asic3_mmc' on hx4700 ? |
| 20:48.19 | psokolovsky | cr2, never tried ;-) |
| 20:48.20 | cr2 | lkcl: which cken bit ? |
| 20:48.29 | lkcl | 1sec... |
| 20:49.03 | cr2 | psokolovsky: i have tried on blueangel (root=/dev/ram0) and it did not succeed. |
| 20:49.13 | cr2 | lkcl can tell us too. |
| 20:49.38 | psokolovsky | noted |
| 20:49.42 | cr2 | if it works on sable. |
| 20:49.45 | cr2 | ok. |
| 20:51.09 | lkcl | ok whatwhatwhat? what am i doing? :) |
| 20:51.22 | lkcl | am i making an initrd, then? |
| 20:51.50 | cr2 | lkcl: if you mount SD from the ramdisk, can you umount it and call 'rmmod asic3_mmc' ? |
| 20:52.15 | cr2 | will it whine about some platform_* missing or unavailable ? |
| 20:52.37 | lkcl | babyfeeding will try later cr2 |
| 20:52.38 | cr2 | i forgot the details. tried it 1 year ago ;) |
| 20:52.41 | cr2 | ok. |
| 20:52.43 | lkcl | back 30mins |
| 20:52.55 | psokolovsky | cr2, btw, just yesterday pH5 raised q's that asic3_base is not a proper platform_device/driver |
| 20:53.06 | pH5 | ack, that has to be fixed. |
| 20:53.13 | lkcl | shes doing small bird impressions... |
| 20:55.14 | cr2 | non-ipaq devices need to create a real #ifdef mess in the headers to compile asic3_base as a module. |
| 20:56.33 | cr2 | i have once tried it, but gave up later. if the asic3 "child devices" comes through, it will be a good idea to have asic3_base as a module. |
| 20:58.28 | psokolovsky | cr2, we need to clean up all asic3 stuff. like, standardize what we use - gpio #'s or bitmasks, etc |
| 20:58.40 | cr2 | psokolovsky: it seems that on universal the asic3 is reset by egpio bit, which is controlled by *_core driver. i can see a deadlock potential here. |
| 20:59.05 | psokolovsky | well, possibly |
| 20:59.31 | cr2 | yes, it's true. the asic3 gpio api is also strange at times. |
| 21:00.46 | psokolovsky | cr2, I want to add thru-numbering to it (gpio 0-63) |
| 21:01.06 | cr2 | + dynamic base ?? |
| 21:01.29 | cr2 | it makes a lot of trouble with the platform_* structs. |
| 21:01.32 | psokolovsky | cr2, what you mean? irq base? |
| 21:01.40 | cr2 | is it really dynamic ? |
| 21:02.08 | psokolovsky | cr2, base address is fully adjustable by paltform_data passed in |
| 21:02.16 | cr2 | you have "fixed" pxa gpios and then the "board" gpios, so asic3 gpios are at 120+ something |
| 21:02.21 | psokolovsky | cr2, irq base is fully dynamic, right |
| 21:02.40 | psokolovsky | cr2, well, that's CPU and other HW-dependent ;-) |
| 21:03.03 | psokolovsky | cr2, we just need to provide asic3 api calls which will hide that |
| 21:03.07 | cr2 | ok, but it prevents hardcoding the asci3 touchscreen irq & things. |
| 21:03.54 | psokolovsky | cr2, no hardcoing, please! ;-) |
| 21:03.55 | cr2 | i mean, does the asic3gpioa0 have the same number through all devices ? |
| 21:04.08 | psokolovsky | cr2, only passing stuff via platform_data |
| 21:04.25 | psokolovsky | cr2, number of what? |
| 21:04.25 | cr2 | "hardcoding" as in passing stuff via platform_data ; |
| 21:04.49 | psokolovsky | cr2, "hardcoding" as hardcoding in drivers ;-) |
| 21:05.23 | cr2 | well. let's say, you have your ASIC3_MMC interrupt on asic3. how do you put it in the platform_data ? |
| 21:05.36 | cr2 | i have such problem for the acx100, for example. |
| 21:06.10 | psokolovsky | cr2: see h4000 as sample |
| 21:06.15 | cr2 | it forces the creation of htcuniversal_acx.ko driver (mainly) only to init the irq. |
| 21:06.49 | cr2 | looking. |
| 21:07.05 | psokolovsky | cr2, platform_data, plarform_resources has everything need to pass *constants* |
| 21:07.27 | psokolovsky | cr2, if you need device-specific handler, well, they need to live somewhere |
| 21:07.44 | cr2 | <PROTECTED> |
| 21:07.52 | psokolovsky | Yeah! |
| 21:07.55 | cr2 | it's a pxa irq, not asic3. |
| 21:08.13 | psokolovsky | need asic3's? sorry! |
| 21:08.35 | psokolovsky | then you need to init id dynamically, using code (oh, I guess that's how you do it anyway ;-) ) |
| 21:08.46 | cr2 | but does your asic3 GPIOA0 have the same number on HTC FOOBAR ? |
| 21:08.56 | cr2 | yeah, that's true. |
| 21:09.15 | psokolovsky | gpios *numbers* are the same. interrupts for them, no |
| 21:10.01 | cr2 | <PROTECTED> |
| 21:10.13 | cr2 | is it the same on all pxa devices ? |
| 21:11.19 | pH5 | cr2: It would be nice to know asic3_irq_base at compile time, then it wouldn't be important whether it's equal for all devices |
| 21:11.57 | psokolovsky | cr2: it is got from kernel, by dynamically allocating irq range. so, it's not the same (even if you wil find that for any specific kernel version it is teh same) |
| 21:12.13 | psokolovsky | pH5, are you sure about that? |
| 21:12.23 | psokolovsky | (would be nice) |
| 21:12.39 | cr2 | ok, but is it really necessary ? |
| 21:12.51 | cr2 | to make things so complex. |
| 21:13.02 | psokolovsky | what? dynamic base? |
| 21:13.12 | cr2 | yes. |
| 21:13.18 | psokolovsky | ask whoever did that. who that was pb? I guess, he had his reasons... |
| 21:13.22 | pH5 | btw, does anybody have an example of a module that installs a chained irq handler and removes it again when it is unloaded? Is this even possible? |
| 21:14.17 | cr2 | pH5: good question. it should be possible in theory. why not ? |
| 21:14.42 | pH5 | I tried to copy what asic3_base or locomo do, but I can't compile it as a module. |
| 21:14.43 | psokolovsky | cr2, pH5: what about having same kernel for all devices? will static irq bases work? |
| 21:15.18 | cr2 | all pxa devices ? |
| 21:15.33 | psokolovsky | cr2, yes, for starters ;-) |
| 21:16.40 | cr2 | asm/arch-pxa/irqs.h is such a mess, so the static board_irq_base is really a minor evil. |
| 21:16.58 | cr2 | it really hurts the eye to look there ;) |
| 21:17.34 | cr2 | #elif defined(CONFIG_IPAQ_HANDHELD) || \ |
| 21:17.38 | cr2 | <PROTECTED> |
| 21:17.42 | cr2 | <PROTECTED> |
| 21:17.42 | cr2 | <PROTECTED> |
| 21:17.42 | cr2 | <PROTECTED> |
| 21:17.43 | cr2 | <PROTECTED> |
| 21:17.43 | cr2 | <PROTECTED> |
| 21:17.43 | cr2 | #define NR_IRQS (IRQ_BOARD_START + 72) |
| 21:17.58 | cr2 | I have added the CONFIG_HTC_ASIC3 |
| 21:18.10 | cr2 | imho, it should be the only one. |
| 21:18.41 | psokolovsky | well, I guess, worth to write an RFC for that to kernel-discuss and carefully consider that |
| 21:23.05 | cr2 | /* |
| 21:23.05 | cr2 | <PROTECTED> |
| 21:23.05 | cr2 | <PROTECTED> |
| 21:23.05 | cr2 | <PROTECTED> |
| 21:23.59 | cr2 | there are irqs hardcoded by others ;) |
| 21:25.01 | cr2 | #define NR_IRQS (IRQ_BOARD_START + 72) |
| 21:25.08 | pH5 | cr2: but there are no irqs defined for any of those machines that were added in the hh.org version of that file? |
| 21:25.30 | cr2 | i guess there are not that many people who can explain the 72 number here, anyway. |
| 21:25.45 | cr2 | pH5: i think it remained from earlier times. |
| 21:26.12 | cr2 | but having the fixed asic3_irq_base will simplify a lot of driver code. |
| 21:28.28 | cr2 | pH5: does your spi-api compliant tsc2046 driver work ? |
| 21:29.54 | cr2 | <PROTECTED> |
| 21:30.28 | cr2 | i guess i know who has made the life simple for himself :) |
| 21:32.51 | pH5 | cr2: no need to make things even more complicated, as long as there is no other device using the same xilinx cpld as an irq source :) |
| 21:33.04 | pH5 | cr2: I didn't even look at the spi driver again... |
| 21:33.33 | pH5 | Last thing I know was I couldn't make the spi layer do 24bit transfers. |
| 21:33.43 | cr2 | SA1111, locomo, magician CPLD - they just don't belong to asm-arm/arch-pxa/irqs.h |
| 21:33.45 | cr2 | ok. |
| 21:34.46 | cr2 | but it's a remnant from the times when sa11x1 was the only "companion" chip. |
| 21:35.02 | pH5 | cr2: I agree, and if there is a cleaner way that has a chance to be accepted by upstream, I'd be most happy to follow it. |
| 21:35.58 | pH5 | Currently I'm more concerned about the suspend/resume hangup in the cpld driver, though. |
| 21:36.03 | cr2 | imho, you should 100% follow the asic3 way. it's just a similar CPLD. |
| 21:37.00 | cr2 | are you doing all the same steps as wince ? |
| 21:37.12 | cr2 | on suspend/resume. |
| 21:41.45 | pH5 | regarding the CPLD memory-mapped registers, I think yes. there doesn't seem to be any masking/unmasking or deactivating going on. |
| 21:42.07 | pH5 | the CPLD irq's are used as wake-up sources, after all. |
| 21:42.09 | cr2 | do you have a pxa gpio to reset it ? |
| 21:42.20 | pH5 | cr2: no such thing. |
| 21:42.23 | cr2 | ok. |
| 21:42.45 | cr2 | so why does it cause problems ? |
| 21:43.55 | pH5 | good question :) it hangs somewhere during suspend. most probably it is my fault, I just don't know it yet. |
| 21:44.36 | pH5 | <PROTECTED> |
| 21:44.36 | pH5 | <PROTECTED> |
| 21:44.57 | pH5 | shouldn't platform_get_resource be used for that? |
| 21:45.21 | cr2 | it's a hack, that's true. |
| 21:45.45 | cr2 | pdev->resource[N] is fishy anyway. |
| 21:46.04 | cr2 | maybe it's better to #ifdef N with some meaningful name. |
| 21:46.08 | pH5 | platform_get_resource_by_name then |
| 21:47.02 | cr2 | i wish there was a good documentation on the platform_*something things with a _good_ example. |
| 21:47.52 | cr2 | we are spending a lof of time trying to fight the problems here. |
| 21:48.38 | pH5 | base/platform.c ;) |
| 21:48.56 | pH5 | actually, it looks like the only driver that references a resource byname is net/smc91x.c |
| 21:57.54 | lkcl | i _did_ make the asic3 stuff a module over 3 years ago, by making it all function-based instead of macro-based |
| 21:59.43 | lkcl | ok. where was i. |
| 22:01.08 | pH5 | WARNING: "irq_desc" [arch/arm/mach-pxa/magician/magician_cpld.ko] undefined! |
| 22:01.37 | pH5 | I get this when I try to compile it as a module, same for set_irq_flags and __set_irq_handler. |
| 22:01.55 | cr2 | lkcl: asic3_mmc |
| 22:02.17 | cr2 | pH5: grep :) |
| 22:02.26 | pH5 | That's in modpost |
| 22:02.29 | lkcl | oh yeh. gonna try an initrd. |
| 22:02.36 | pH5 | when I compile it into the kernel it works. |
| 22:03.07 | pH5 | (until I try to suspend) |
| 22:04.35 | cr2 | ./include/asm-arm/mach/irq.h:void set_irq_flags(unsigned int irq, unsigned int flags); |
| 22:04.59 | lkcl | can anyone remember how i used to do initrds? :) |
| 22:05.09 | lkcl | did i ever document it? |
| 22:05.24 | cr2 | ./arch/arm/kernel/irq.c:EXPORT_SYMBOL_GPL(set_irq_flags); |
| 22:05.58 | lkcl | http://wiki.xda-developers.com/index.php?pagename=HimalayaStandaloneGPEWithoutSD |
| 22:06.04 | lkcl | i think ... err... |
| 22:06.07 | cr2 | lkcl: take an existing one for the universal , mount -o loop and change to your taste. |
| 22:07.43 | lkcl | it seems i used to have a boat-load of stuff that i .tgz'd... |
| 22:07.55 | cr2 | pH5: EXPORT_SYMBOL_GPL(irq_desc); |
| 22:08.00 | lkcl | holy cow it was a hell of a lot of stuff.. |
| 22:08.04 | pH5 | cr2: exactly. and the module is GPL, so why the error in modpost? |
| 22:08.25 | lkcl | about 300mb as a .tgz! |
| 22:08.41 | lkcl | oops i just run /home out of space... |
| 22:08.42 | cr2 | pH5: strange. |
| 22:09.32 | cr2 | pH5: what symbols do you have in vmlinux ? |
| 22:11.37 | pH5 | c01e6040 D irq_desc |
| 22:11.37 | pH5 | c001baa0 T set_irq_flags |
| 22:11.37 | pH5 | c0056b38 T __set_irq_handler |
| 22:12.12 | cr2 | that's strange. |
| 22:18.27 | lkcl | what fs type is your ramdisk, cr2? |
| 22:19.28 | pH5 | cr2: yay, thanks for helping out. |
| 22:19.51 | pH5 | set_irq_flags et al are only exported in the handhelds.org kernel |
| 22:19.53 | pH5 | :-/ |
| 22:21.54 | lkcl | ok got it doesn't matter (auto-detected after i gunzip'd it) |
| 22:22.52 | lkcl | initrd boot, off we go.... going red |
| 22:23.04 | cr2 | lkcl: ext2 |
| 22:23.05 | lkcl | oops! |
| 22:23.09 | lkcl | no ram0 device... |
| 22:23.46 | cr2 | ramdisk compiled in ? |
| 22:23.58 | cr2 | initrd support ? |
| 22:25.24 | lkcl | um nope! |
| 22:25.54 | lkcl | ha ha |
| 22:27.46 | cr2 | that should be initramfs in the not so distant future :) |
| 22:27.56 | lkcl | let's try that again.... |
| 22:27.59 | lkcl | blue... |
| 22:28.01 | lkcl | red... |
| 22:28.20 | lkcl | heave, heave... hmmm.... |
| 22:28.38 | lkcl | oh. ah. did i actually copy the files over? |
| 22:29.35 | lkcl | kernel panic no filesystem could mount root, tried ext3 ext2 cramfs msdos vfat ntfs romfs |
| 22:29.48 | lkcl | unable to mout root fs on unknown-block(1,0) |
| 22:29.51 | lkcl | whatever _that_ is |
| 22:30.03 | lkcl | but i _do_ have udc :) |
| 22:30.08 | cr2 | 1,0 is /dev/ram0 |
| 22:30.18 | lkcl | hurrah. ok... hmm... |
| 22:30.33 | cr2 | haret statup.txt ? |
| 22:31.12 | lkcl | 1sec... |
| 22:31.31 | lkcl | set KERNEL zImage |
| 22:31.32 | lkcl | set INITRD initrd26.gz |
| 22:31.32 | lkcl | set CMDLINE "root=/dev/ram0 rw console=tty0 init=/linuxrc ramdisk_size=14436 keepinitrd mem=64M boot_mmc=y" |
| 22:31.32 | lkcl | boot2 |
| 22:32.16 | cr2 | should be ok. |
| 22:32.58 | lkcl | default ramdisk option was 16 and 4096 |
| 22:33.07 | cr2 | i wonder why is it not booting without the ramdisk directly from the SD. |
| 22:33.11 | cr2 | yes, that's ok. |
| 22:33.32 | lkcl | well to be honest i don't care if the initrd works. |
| 22:33.46 | lkcl | but so far the only thing working is nfs! |
| 22:34.16 | lkcl | gotta go soon - this will be tomorrow's problem. |
| 22:35.27 | cr2 | ok. till later, i must sleep to :) |
| 22:35.28 | lkcl | gottagobye |
| 22:35.28 | cr2 | good night. |
| 22:40.40 | pH5 | 'night all |