03:36.10 | *** join/#arm-netbook Baybal (~baybal@S0106001e58392615.vs.shawcable.net) |
03:40.32 | *** join/#arm-netbook Baybal (~baybal@S0106001e58392615.vs.shawcable.net) |
07:34.55 | *** join/#arm-netbook SQlvpapir (~teis@188.177.95.62) |
10:49.16 | *** join/#arm-netbook lkcl (~lkcl@nat66.mia.three.co.uk) |
12:30.16 | fjp | bjdooks: I have Debian Installer running now, but getting spinlock recursion bug from dm9000. |
12:30.51 | fjp | I've tried cherry-picking some post-2.6.24 changes but they don't help. |
12:30.59 | fjp | is lost |
12:39.45 | fjp | Strange thing is that networking seemed to work fine with earlier custom kernels. |
12:52.34 | *** join/#arm-netbook ibot (ibot@rikers.org) |
12:52.34 | *** topic/#arm-netbook is ARM netbook GNU/Linux hacking - logs: http://ibot.rikers.org/%23arm-netbook |
12:55.53 | fjp | This seems to describe it: http://lists.openwall.net/netdev/2007/11/20/152 |
12:56.10 | fjp | But that's before .24 |
13:02.12 | fjp | Yay! The patch posted there (although probably not 100% correct) works for me. |
13:03.38 | fjp | I do get one 'NETDEV WATCHDOG: eth0: transmit timed out', but after that DHCP is OK and networking works. |
13:05.31 | fjp | And partman shows the two flash cards :-) |
13:07.02 | mnemoc | :D |
13:38.45 | fjp | lkcl: Looks like I'm going to get to keep the netbook :-) |
13:53.58 | lkcl | yeay |
14:09.31 | fjp | Ugh. |
14:09.47 | lkcl | fjp: checking the chitech disassembly, the dm9000_timeout function looks nothing like that |
14:09.56 | lkcl | i've alerted them to the problem. |
14:09.59 | lkcl | ugh? |
14:10.07 | lkcl | wassup? |
14:10.10 | fjp | Why the heck did I name the branches 2.4.27 and 2.4.33 instead of 2.6.24 and 2.6.33? |
14:10.29 | lkcl | i have no idea :) |
14:10.41 | lkcl | i um didn't want to say anything... |
14:11.18 | fjp | I think I'm going to have to fix that. |
14:18.29 | fjp | lkcl: Looks nothing like what? |
14:54.01 | bjdooks | fjp: weird, the dm9000 works fine for us |
14:54.43 | bjdooks | one of my devboards is using dm9000 to provide nfsroot |
15:03.46 | fjp | bjdooks: Yeah. Any idea what could be causing the initial watchdog timeout? |
15:05.00 | bjdooks | #1 cause of problems is bad io setup |
15:06.06 | fjp | Could be. We do have an iomem bit that isn't present with the ChiTech kernel. |
15:06.29 | fjp | 0000004a-0000004a : dm9000 |
15:06.33 | fjp | f7600300-f76fffff : dm9000 |
15:06.33 | fjp | <PROTECTED> |
15:06.44 | fjp | The first line is extra. |
15:07.16 | fjp | But after the initial timeout it works perfectly. |
15:10.39 | fjp | The spinlock issue still seems to be present in current mainline code though if there ever should be a watchdog timeout. |
15:11.09 | bjdooks | hmm, not seen a watchdog timeout in a while |
15:11.19 | bjdooks | the machine on my left is running 2.6.33 + -simtec patchset |
15:11.31 | fjp | See http://lists.openwall.net/netdev/2007/11/20/152 |
15:13.35 | bjdooks | i think that got fied by ensuring dm9000_init_dm9000 required the caller to hold the spinlock |
15:14.13 | fjp | But init calls dm9000_hash_table which still sets a spinlock |
15:14.49 | bjdooks | hmm |
15:30.05 | lkcl | fjp: the dm9000_timeout function in the chitech kernel looks nothing like the 2.6.24.7 dm9000.c that we have |
15:30.09 | lkcl | lunch |
15:34.06 | bjdooks | personally, don't care pre 2.6.32 |
15:34.53 | lkcl | bjdooks: interrupting lunch, so just a quick one: remember that chitech have those incorrect capacitor values and also the crossover with possible interference, and one person has reported that when charging, the dm9000 fails to operate correctly |
15:35.04 | lkcl | so i think it "works for you" because you followed the app notes correctl |
15:35.23 | lkcl | but, for people who _haven't_, the dm9000 goes slightly wonky, gets unhappy and resets. |
15:35.27 | lkcl | this is "recovery" |
15:35.39 | lkcl | it means that there is a _slim_ chance that the dm9000 will go wrong for you |
15:35.39 | fjp | Understand. But we're stuck with it a bit longer for this system. |
15:35.45 | lkcl | but for us it goes wrong _all_ the time. |
15:36.06 | lkcl | bjdooks: yes, but we'll catch up once we have completely stable code, all drivers working :) |
15:36.16 | fjp | But as I say, that spinlook issue looks to be still present in current mainline (.34-rc2) |
15:36.29 | fjp | spinlock even |
16:05.56 | lkcl | so yes, it would simply be a matter of time before someone's dm9000, even on a "working" system, hit a problem, crashed, timed out and blam |
16:07.20 | lkcl | bjdooks: btw, i negotiated with a company who are willing to sponsor the creation of an S5PC100-based SO-DIMM, with a license for ORCAD. |
16:08.08 | lkcl | do you think that you (or simtec officially) would be able to help, in return for rights to use+modify+distribute+etc. the resultant PCB designs? |
16:20.36 | mnemoc | lkcl: hi, please don't forget to mail me (and fjp) the business analysis you sent to mid-fun :) |
16:20.43 | lkcl | oh good grief |
16:20.58 | lkcl | oh wait - i know where it is: it's sent to legal@lists.gpl-violations.org |
16:21.01 | lkcl | i remember now. |
16:21.11 | lkcl | you can find it on lists.gpl-violations.org |
16:22.28 | mnemoc | lkcl is it supposed to be an attached pdf or something else? |
16:22.33 | lkcl | no, email |
16:23.35 | mnemoc | so you will make me read all the related threads :< .... ok |
16:23.54 | mnemoc | http://lists.gpl-violations.org/pipermail/legal/2010-March/thread.html |
16:37.21 | mnemoc | i have to admit the thread is good reading actually |
16:43.18 | mnemoc | http://news.gmane.org/gmane.law.gpl.violations.legal <--- much better ui |
16:47.30 | fjp | wonders if the whole approach is not too aggressive; especially taking Chinese culture into account |
16:48.39 | fjp | lkcl: I seriously doubt that that patch is needed for them if their timeout function is so different. |
16:49.07 | lkcl | well... |
16:49.09 | fjp | Also, the patch is far from ideal as it will run the init function without spinlock protection. |
16:49.15 | lkcl | ouch! |
16:50.56 | lkcl | i started out fine. the repeated stating of the "give us lots of money and we'll give you the code" position is what really did it, for me. |
16:51.12 | fjp | Hmm. But dm9000_open also calls _init without spinlock |
16:51.13 | lkcl | they made it clear that they hadn't read what i'd written. |
16:51.19 | lkcl | so... |
16:51.21 | lkcl | shrugs |
16:51.44 | fjp | Maybe best to forget about them for now and concentrate on backporting |
16:51.50 | lkcl | yes. |
16:52.13 | lkcl | that seems to work well - it takes them a good couple of days to translate / process what we write. |
16:52.26 | fjp | BTW, to check your code, wouldn't it make sense to compare disassembies of their and our kernels? |
16:52.44 | fjp | E.g. for current state of poweroff? |
16:56.10 | lkcl | i was thinking about doing that, but it's such a pain doing the disassembly that i was just going to use gcc -E if needed |
16:56.15 | lkcl | sorry gcc -s |
16:56.53 | fjp | thinks the patch is OK for now; if things go splat we'll find out soon enough |
16:57.34 | lkcl | it's taken several days to identify functions and data - eventually i wrote an IDC script which could turn 12,000 addresses into functions (!) |
16:58.08 | lkcl | yes. remember i did accidentally activate the poweroff GPIO in smdk6410_machine_init so i know it's correct :) |
16:58.40 | fjp | What we have currently doesn't work yet. |
16:58.52 | *** join/#arm-netbook SQlvpapir (~teis@188.177.95.62) |
16:59.31 | fjp | BTw, you know that you have to edit arch/arm/mach-s3c6410/mach-ctpc89e.c now, right? |
17:01.25 | lkcl | yes |
17:01.53 | lkcl | fjp: i'll check it again |
17:19.07 | SQlvpapir | lkcl, how do we tell the machine to boot from SD card instead of the nand? if I copied it to the SD card with dd as you suggested in your mail what do you expect to happen? |
17:23.18 | lkcl | there's a switch on the *underside* of the so-dimm |
17:23.20 | lkcl | flick it |
17:23.51 | lkcl | i _believe_ - the hypothesis is - that this is wired to the s3c6410 pin which says "please boot from mmc drive 1 instead of 0" |
17:23.54 | lkcl | simple as that |
17:23.58 | lkcl | but, it could be total shite. |
17:24.02 | lkcl | someone has to try |
17:24.50 | lkcl | if it's the case, then it is brilliant, because we can recover machines, and also begin reverse-engineering u-boot _without_ bricking the machine. |
17:25.17 | lkcl | is off shopping |
17:36.27 | fjp | Q is: how do you verify that it actually booted off the SD card instead of nand... |
17:37.24 | fjp | I think you'll have to change something on th SD card to be able to check. |
17:42.38 | bjdooks | the s3c6410 has a set of pins which are read at startup to determine boot mode |
17:54.42 | SQlvpapir | I noticed the screw near the SD card slot is missing |
17:55.04 | fjp | I have that! I had a loose screw in mine. |
17:55.33 | SQlvpapir | well what do you know :) |
17:55.52 | SQlvpapir | I found the appropriate screwdriver so I'm going in now |
17:56.32 | SQlvpapir | lkcl, since you had it open, are all the external screws the same? |
17:56.53 | fjp | No. Two are slightly longer. |
17:57.32 | SQlvpapir | ta |
17:57.32 | fjp | I'm not 100% sure, but I've used them in the outside back holes. |
17:57.40 | fjp | Would be nice if you could confirm. |
17:58.10 | fjp | outside rear I mean |
18:00.24 | SQlvpapir | hmm I'm not very good at this :p |
18:03.24 | SQlvpapir | lkcl, did you use force or did you 'pry' it open with a flat screwdriver? it seems to fit very good in the read (near screen hinges) |
18:05.18 | SQlvpapir | lkcl, maybe I missed something.. screws under the rubber standoffs? |
18:06.00 | fjp | SQlvpapir: You need to lift out the keyboard first. There are clips at the rear. |
18:07.26 | fjp | Then disconnect the keyboard; remove the three screws holding the plate below it; disconnect the touchpad; remove that plate. |
18:08.58 | SQlvpapir | fjp, can the tiny 3 'pins' holding the keyboard down near the screen be pushed in? |
18:09.19 | SQlvpapir | maybe I should get glasses |
18:09.55 | fjp | No. You just have to widen the gap a bit and nudge the keyboard up. |
18:10.02 | SQlvpapir | oh I see |
18:10.15 | SQlvpapir | just had success with brute force |
18:10.39 | fjp | Main thing is not to break off the clips... |
18:15.30 | SQlvpapir | amazing |
18:29.47 | SQlvpapir | a AAA battery is too big. I'll have to speak with my electronics guy to see what kind of capacity can be crammed in there |
18:31.21 | SQlvpapir | was surprised to see that there is no 2nd antenna cable for 3g |
18:32.25 | SQlvpapir | all I've got (not-in-use) is a 16gb sdhc card, will give it a try after the movie. |
18:36.57 | lkcl | SQLvpapir: yes be VERY careful removing the keyboard connector. |
18:37.41 | lkcl | SQlvpapir: if it's an SATA / PATA one it will not work. only USB devices will work. plus, there are some GPIO pins that are needed to be pulled to activate power to the PCI-e |
18:38.15 | lkcl | it's assumed that you're going to put a WIFI or a 3G modem in there, so to save power, they're left switched off |
18:55.54 | fjp | has kernel module udebs now |
18:56.28 | lkcl | fjp: just remembered: adam had the dm9000 disconnect whenever he connected power. from this i conclude that the capacitors lacking that bjdooks noticed are causing fluctuations, causing the dm9000 to crash, triggering the dm9000_timeout, BLAT, segfault, bye bye ethernet. |
18:56.55 | lkcl | so, there is some evidence to suggest that yes, their binary kernel has the same issue |
18:57.03 | lkcl | yaay, well done |
18:57.56 | fjp | I've noticed that eth0 is always slow to come up, even with the original kernel. |
19:03.38 | fjp | Hmm. We don't have the wireless driver in this kernel source, do we? |
19:06.52 | SQlvpapir | lkcl, I thought I broke it at first but its a different style than I'm used to |
19:07.03 | lkcl | what is? |
19:07.19 | lkcl | ohh, the clip on the keyboard connector? |
19:07.30 | lkcl | yes, there are two styles. |
19:07.42 | lkcl | this one's cheaper. |
19:07.50 | lkcl | BE VERY CAREFUL when pushing it back in. |
19:08.28 | lkcl | for the mouse one, i recommend you disconnect _both_ ends, then insert into the PCB first, and into the trackpad second. |
19:08.38 | lkcl | i think... |
19:08.51 | lkcl | yes. i believe you'll find it's easier that way round. |
20:54.41 | SQlvpapir | lkcl, my netbook is fitted with a chrontel 7026b-tf |
20:54.56 | SQlvpapir | where your picture has nothing |
20:56.04 | lkcl | woot! |
20:56.50 | SQlvpapir | just noticed |
20:56.56 | SQlvpapir | will upload picture in a bit |
21:00.16 | SQlvpapir | lkcl, only ~1mbit upload so please do not link to it in the mailing list ;) feel free to use the picture though http://dreijer.dk/~teis/20100322451.JPG |
21:01.36 | SQlvpapir | now I begin to wonder how many of the netbooks are equipped with what |
21:05.35 | SQlvpapir | maybe they simply ran out of the little fellas. thats the only difference I've been able to spot |
21:09.28 | SQlvpapir | fjp, ^^ |
21:10.15 | fjp | No idea. I haven't taken out the mainboard yet. |
21:14.00 | fjp | A 30 sec timeout is just enough for the eth0 watchdog timeout and to get DHCP. |
21:14.57 | mnemoc | a tv chip??? |
21:15.19 | fjp | is not that interested as he does not have a TV... |
21:16.19 | SQlvpapir | mnemoc, the datasheet sites link to is dead and there is not much info in the top20 list |
21:17.01 | SQlvpapir | but its supposed to be able to do 720p.. I'm hoping its either dvi or hdmi, but I dont really have a clue about that. |
21:17.09 | SQlvpapir | mnemoc, did you have a look inside yours? |
21:17.17 | mnemoc | not yet |
21:17.57 | mnemoc | i hope to have some time this weekend |
21:18.50 | SQlvpapir | mnemoc, note the difference above the sd card slot http://dreijer.dk/~teis/20100322451.JPG (takes 30s to load) http://lkcl.net/arm_systems/CT-PC89E/photos/IMG_3145.jpg |
21:19.31 | mnemoc | fjp: how much quota we got in alioth for the wiki? (to host pictures of the different boards) |
21:19.55 | fjp | mnemoc: No fixed quota. |
21:20.08 | fjp | But don't abuse the diskspace... |
21:20.32 | fjp | Better to upload reduced resolution/size images when possible. |
21:20.39 | fjp | And no duplicates. |
21:20.55 | mnemoc | fjp: sure.... but first the admin has to install and setup the wiki ;-) |
21:21.08 | fjp | Well, see my mail. |
21:21.21 | fjp | We already have wikis we can use elsewhere. |
21:21.32 | mnemoc | elinux? |
21:21.45 | fjp | Yes, and the standard Debian wiki. |
21:22.40 | fjp | If it's really wanted, fine. |
21:23.02 | fjp | But if we can do with a simple static page on alioth with links, that's fine too. |
21:25.14 | lkcl | SQlvpapir, is there an sdcard holder? |
21:26.38 | SQlvpapir | lkcl, huh? |
21:27.05 | SQlvpapir | sd(hc) card is working fine if thats the question |
21:28.04 | lkcl | sorry, simcard holder |
21:28.20 | lkcl | is there a simcard holder attached |
21:28.38 | SQlvpapir | will check in 5 |
21:29.55 | lkcl | ack. |
21:30.37 | SQlvpapir | nope nothing |
21:35.42 | fjp | Hmm. Installing using ext4 to a USB stick does not work: fs cannot be mounted; ext2 works fine |
21:36.09 | fjp | Could be that ext4 support in .24 isn't good enough. Or maybe something else. |
21:36.40 | fjp | But, it's installing. |
21:36.54 | fjp | Let's see if it wants to install the kernel from alioth... |
21:37.18 | mnemoc | ext4 started to be decent around .30 |
21:37.42 | mnemoc | the experimental flag was removed in .28 |
21:38.10 | fjp | But even with the last 2 upstream kernels there were still plenty of fixes. |
21:38.18 | mnemoc | and i still have panics in ubuntu/2.6.31 |
21:38.35 | fjp | So what FS should we use for now on SD card, given .24? |
21:38.53 | mnemoc | ext2 i would say |
21:39.17 | mnemoc | anything with journal will kill the card |
21:39.23 | fjp | Yes. That's what I was thinking. On small SD cards a journal does not really make sense. |
21:39.32 | fjp | Opinions vary about that. |
21:39.46 | fjp | Swap is advised against. |
21:40.03 | mnemoc | minize the writes as much as you can |
21:40.17 | mnemoc | minimize* |
21:40.23 | fjp | journal only causes many more writes with some tasks |
21:40.25 | fjp | Yes. |
21:40.33 | fjp | Need to tune logging as well. |
21:41.33 | fjp | I doubt the base system will fit on my 256MB USB stick.. |
21:42.05 | mnemoc | usb/sata ? |
21:42.58 | mnemoc | for development an external sata disk will do great |
21:43.13 | mnemoc | for real life... you will need to switch to emdebian anyway |
21:43.35 | fjp | Hmm. Could use my external USB hard disk maybe. |
21:43.36 | fjp | Yes. |
21:43.55 | mnemoc | you only need to *boot* from the SD |
21:45.20 | fjp | Yes. I'm planning to use the nand for a minimal / only and have the rest on the external SD card. |
21:47.45 | fjp | So, should I add emdebian by default to the sources.list? |
21:48.16 | fjp | Do they already have a squeeze archive? |
21:49.00 | mnemoc | http://www.emdebian.org/grip/ |
21:49.12 | mnemoc | "Grip is a light grip on Debian Squeeze" |
21:51.03 | mnemoc | if i were you (actually, if i would have time) i would use the normal debian and a usb/sata for storage/building and SD for swap until .33 is running and then debootstrap grip into the NAND |
21:54.34 | mnemoc | i actually have to find the time to do the same with my frelling gdium or the patchset from mandriva with get unusably old again (lastest is .29) .... with the difference that the gdium doesn't have a NAND but a 16GB usb stick |
21:55.57 | mnemoc | usign coreutils, full NLS and glibc in the chitech is kind of sucidal |
21:57.17 | mnemoc | i really need to get those patches in sync with the work lemote is doing |
21:58.02 | mnemoc | but at least a .deb of that .29 (instead of the current .24) |
22:00.38 | mnemoc | i want "spare" time! :'( |
22:29.19 | SQlvpapir | I dd'ed mmcblk0 to mmcblk1. the machine is still open but I'll wait with the switch-flipping until I've had some sleep |
22:41.06 | *** join/#arm-netbook lkcl (~lkcl@nat65.mia.three.co.uk) |