| 01:08.32 | *** join/#edev gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net) |
| 02:17.21 | *** join/#edev redb1ue (i=star@ppp221.109-253-207.mtl.mt.videotron.ca) |
| 03:02.34 | *** join/#edev drockwell (n=harry@80-41-95-155.dynamic.dsl.as9105.com) |
| 03:03.38 | *** part/#edev drockwell (n=harry@80-41-95-155.dynamic.dsl.as9105.com) |
| 03:07.38 | *** join/#edev davidc___ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 03:19.14 | MonMotha | my god windows sucks |
| 03:19.19 | MonMotha | the library management...it's horiible |
| 03:29.02 | davidc___ | anyone really familiar with arm jtag around? |
| 03:57.50 | *** join/#edev EvilDevil_ (n=miau@p54A6D9E6.dip.t-dialin.net) |
| 05:30.50 | *** join/#edev [1]gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net) |
| 06:33.06 | *** join/#edev chouimat (n=dieu@kde/developer/chouinard) |
| 09:30.40 | *** join/#edev bd2 (n=ufo@81.222.177.146) |
| 09:45.24 | *** join/#edev redb1ue (i=star@ppp168.108-253-207.mtl.mt.videotron.ca) |
| 11:21.38 | *** join/#edev redb1ue (i=star@ppp160.108-253-207.mtl.mt.videotron.ca) |
| 12:00.06 | *** join/#edev gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net) |
| 12:06.23 | *** join/#edev [1]gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net) |
| 12:31.33 | *** join/#edev tuxmaniac (n=aanjhan@60.254.67.17) |
| 12:32.05 | *** join/#edev gandhijee (n=gandhije@mail.win-ent.com) |
| 12:43.30 | *** join/#edev GPSFan (n=kenm@12.10.255.248) |
| 12:43.30 | *** mode/#edev [+o GPSFan] by ChanServ |
| 12:50.35 | *** join/#edev prpplague (n=billybob@72.22.146.214) |
| 12:52.04 | chouimat | morning |
| 13:26.11 | jbevren | yawn. |
| 13:26.12 | jbevren | hehe |
| 13:30.17 | prpplague | whats up with sf.net this morning |
| 13:30.45 | jbevren | do you need to ask? |
| 13:30.46 | jbevren | its sf.net |
| 14:30.32 | jbevren | hmm |
| 14:30.34 | jbevren | 260002146088 |
| 14:30.39 | jbevren | its x86, but still kinda neat |
| 14:30.49 | jbevren | (ebay ID there) |
| 14:32.41 | prpplague | ahh interesting that is neat |
| 14:38.44 | jbevren | google images has lots of interior pictures |
| 14:39.01 | jbevren | and there are m0n0wall installation howtos |
| 14:39.32 | jbevren | looks like 3 82559 NICs |
| 14:43.14 | chouimat | jbevren: which board? |
| 14:43.29 | jbevren | chouimat: nokia ip110 desktop router/firewall |
| 16:18.55 | *** join/#edev ChanServ (ChanServ@services.) |
| 16:18.55 | *** mode/#edev [+o ChanServ] by irc.freenode.net |
| 16:18.55 | *** mode/#edev [-o jbevren] by ChanServ |
| 16:51.54 | *** join/#edev tuxmaniac (n=aanjhan@60.254.67.17) |
| 17:08.46 | *** join/#edev T0mW (n=Tom@24.238.68.20.res-cmts.sth.ptd.net) |
| 17:10.13 | jbevren | ok where the f/ck did eth1 go |
| 17:10.20 | jbevren | udev officially sucks |
| 17:13.45 | prpplague | and not in a good way |
| 17:14.24 | jbevren | eth0 becomes 'eth' |
| 17:14.28 | jbevren | eth1 goes missing |
| 17:14.37 | jbevren | and a new 'eth_temp' ethernet interface, that is invalid, appears |
| 17:14.50 | jbevren | this borders on retardation |
| 17:14.58 | jbevren | what's wrong with eth0 and eth1 |
| 17:15.02 | prpplague | i'm so close to getting the final stamp of approval on this |
| 17:15.09 | jbevren | what's worng with not fixing what isnt broke |
| 17:15.12 | jbevren | prpplague: cool |
| 17:15.27 | jbevren | now that it's cool, what is it youre getting approval for? :D |
| 17:15.35 | prpplague | hehe |
| 17:15.40 | prpplague | the os for this handheld |
| 17:15.46 | jbevren | cool :) |
| 17:18.58 | prpplague | jbevren: got a few little procfs items driving me nuts |
| 17:19.05 | *** join/#edev catastrop (n=catastr0@d14-69-178-65.try.wideopenwest.com) |
| 17:19.43 | prpplague | hmm |
| 17:19.44 | prpplague | i wonder |
| 17:19.58 | prpplague | what is the earliest part of the kernel you can call proc_mkdir |
| 17:40.17 | *** join/#edev redb1ue (i=star@ppp213.108-253-207.mtl.mt.videotron.ca) |
| 17:50.40 | jbevren | find out when proc gets started? hehe |
| 17:51.04 | jbevren | it'd be interesting actually, to see a call trace for linux as it boots |
| 17:51.12 | jbevren | that way you know what gets done when |
| 17:51.21 | jbevren | I"d guess though, once drivers start loading, proc is ready |
| 17:52.44 | prpplague | jbevren: i was able to put in in the machine specific init |
| 17:52.51 | prpplague | jbevren: so it looks to be pretty early |
| 17:54.38 | T0mW | "the check is in the mail" |
| 17:59.41 | *** join/#edev bd2 (n=ufo@81.222.177.146) |
| 18:01.33 | prpplague | T0mW: ? |
| 18:01.52 | T0mW | nm |
| 18:05.04 | youam | any ideas why my kernel does not output any messages after "Freeing init memory: 80K" when trying to boot over serial console on an arm box? |
| 18:06.35 | jbevren | because its not freeing the init memory? |
| 18:06.38 | prpplague | youam: uh could be a million things |
| 18:07.31 | prpplague | youam: did you enable kernel debugging and put some printascii commands into your printk.c |
| 18:07.31 | youam | prpplague: yes |
| 18:07.44 | youam | <PROTECTED> |
| 18:07.48 | youam | <PROTECTED> |
| 18:08.04 | prpplague | and? |
| 18:08.14 | youam | run_init_process is just a wrapper for execve(init_filename, argv_init, envp_init); with /init as the first two args |
| 18:08.19 | youam | [ 52.510000] going to execute '/init' |
| 18:08.45 | prpplague | hehe you didn't tell me much |
| 18:08.49 | youam | and that's it, nothing more; though my init should say something... |
| 18:09.02 | prpplague | youam: i don't think you have actually enable all of the debugging you need |
| 18:09.15 | prpplague | youam: are you sure you added printascii to your printk.c ? |
| 18:09.51 | youam | prpplague: actually, i didn't. sorry. i thought you meant something like the printk's i did |
| 18:23.07 | dfarnsworth | youam, are you using a known good initramfs? |
| 18:25.56 | youam | dfarnsworth: not really. i did try one which works for me under i586 (of course recompiled against arm), and the initrd from d-i for netwinder, which works according to http://david.thg.se/n2100/ |
| 18:27.06 | youam | dfarnsworth: but even then, shouldn't the kernel or the initrd tell me *something*? i mean, if the binary is b0rked, i'd expect the kernel to tell me instead of just doing nothing. if it's not, it should work... |
| 18:27.48 | dfarnsworth | youam, most likely, the init program is running, but console output isn't working. |
| 18:28.09 | jbevren | good point. Are /dev/console and /dev/ttyS0 present? |
| 18:28.23 | youam | prpplague: okay, i enabled printascii, it doubled the volume of output' messages, but nothing of any value... |
| 18:29.59 | MonMotha | it's possible that it switched to a different console after that point since that's when a userspace is started |
| 18:30.12 | dfarnsworth | put a breakpoint in sys_open to see if init is running enough to try to open /dev/console |
| 18:30.24 | dfarnsworth | a breakpoint or a printk |
| 18:31.21 | youam | dfarnsworth: i'm going to try that next |
| 18:32.59 | youam | dfarnsworth: hm. i don't have to do that |
| 18:33.12 | youam | <PROTECTED> |
| 18:33.12 | youam | <PROTECTED> |
| 18:33.15 | youam | <PROTECTED> |
| 18:33.33 | youam | 'sys_dup() 1' is printed, the if-case isn't |
| 18:33.52 | dfarnsworth | k |
| 18:34.10 | jbevren | hrm so the kernel boots but init doesnt get going? |
| 18:34.41 | youam | device files are present in the initramfs source, though i'm not sure right now if cpio even has the ability to store device files |
| 18:34.47 | youam | jbevren: yes |
| 18:34.56 | jbevren | using busybox? Static or dynamic? |
| 18:35.05 | youam | static busybox |
| 18:35.10 | jbevren | ponderous |
| 18:35.16 | jbevren | should be a win-win heh |
| 18:35.40 | jbevren | try init=/bin/busybox sh |
| 18:35.50 | jbevren | (or does that work on init=) |
| 18:36.35 | jbevren | I'm wondering if the link from /sbin/init to /bin/busybox is right |
| 18:36.49 | jbevren | oh, it'd say it cant open init, wouldnt it |
| 18:37.26 | youam | jbevren: there's a link form /init to /bin/busybox, it works under i586 and the kernel says it's trying /init, so that should be okay |
| 18:38.16 | jbevren | not to be insulting, but youre sure youre not using x86 binaries in the arm tree? |
| 18:38.47 | youam | /tmp/rootrd/init: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped |
| 18:38.55 | agaffney | darn :P |
| 18:38.56 | jbevren | cool |
| 18:39.10 | youam | hm. could this be an endianness-problem? |
| 18:39.11 | jbevren | ls -ld /tmp/rootrd/init |
| 18:39.27 | jbevren | lsb's right |
| 18:39.28 | youam | lrwxrwxrwx 1 youam youam 15 2006-06-28 18:02 /tmp/rootrd/init -> bin/busybox-rrd |
| 18:39.45 | prpplague | hmm, i don't think you can pass args like that for init= |
| 18:39.50 | jbevren | prpplague: i was unsure |
| 18:39.58 | jbevren | youam: that's a tough one |
| 18:40.10 | jbevren | it doesnt help that the kernel's not good about printing loading errors for init :) |
| 18:40.17 | dfarnsworth | putting a printk into sys_write should tell you if init is running. |
| 18:40.26 | jbevren | df: good idea |
| 18:40.34 | youam | i don't think so, to, but as busybox does the right thing under i586 i doubt *that*'s the problem here |
| 18:40.37 | prpplague | youam: you should have a link in the rootfs for linuxrc->/bin/busybox |
| 18:40.52 | youam | prpplague: only if it's an initrd, but it's an initramfs |
| 18:41.11 | prpplague | youam: applies for any rootfs type |
| 18:41.26 | prpplague | youam: busybox is designed to start a specific operating when called as linuxrc |
| 18:41.43 | prpplague | youam: i.e. the same as telling it /bin/busybox sh |
| 18:42.35 | jbevren | prpplague: actually, the kernel looks for linuxrc, init, sbin/init |
| 18:42.50 | jbevren | although, thats a good sanity check |
| 18:42.57 | prpplague | jbevren: that is correct |
| 18:43.09 | prpplague | jbevren: i never assume anything when doing a board bringup |
| 18:43.09 | youam | already trying |
| 18:43.22 | jbevren | I replied before I read your further comment on bb behavior when called as 'linuxrc' |
| 18:44.54 | youam | adding the symlink linuxrc -> bin/busybox doesn't change anything |
| 18:46.05 | youam | next try: figure out where sys_write is and how to add printk's |
| 18:47.44 | jbevren | lxr.linux.no is nice :) |
| 18:47.53 | jbevren | tells you where things are with ease |
| 18:48.38 | youam | grep is nice, too :) (fs/read_write.c) |
| 18:53.06 | youam | <4>going to execute '/init' |
| 18:53.09 | youam | <4>sys_write: fd -1, size_t 98 |
| 18:53.30 | youam | and one more, and that's it. not really much data... |
| 18:53.36 | dfarnsworth | that fd ain't good |
| 18:53.37 | youam | oh! |
| 18:53.43 | youam | wait a sec... |
| 18:53.53 | jbevren | <PROTECTED> |
| 18:54.24 | youam | right now it's writing lots of data on fd 3 and 4, in chunks of <<100 byte |
| 18:54.50 | dfarnsworth | init is running, there's just no console output |
| 18:55.43 | youam | hm. it's *still* writing &-) |
| 18:55.51 | T0mW | lovely, gcc-4.02 -Os will create trashy Thumb code |
| 18:56.12 | jbevren | youam: It may well be booting up heh |
| 18:56.34 | jbevren | it'd be interesting to be able to see PIDs |
| 19:01.57 | youam | . o O ( did i say it's still writing in chunks between 7 and 70 byte? ) |
| 19:03.29 | *** join/#edev catastrop (n=catastr0@d14-69-178-65.try.wideopenwest.com) |
| 19:06.37 | MonMotha | T0mW: but is it small? |
| 19:07.20 | T0mW | <sigh> |
| 19:07.32 | T0mW | ~lart MonMotha |
| 19:08.56 | MonMotha | you did ask it for size optimizations |
| 19:09.09 | MonMotha | though going into thumb mode may be a bit extreme... |
| 19:09.15 | MonMotha | especially if it sucks at taht |
| 19:11.31 | T0mW | Well, -O0 generates good Thumb code, -Os builds code that does not perform the same operations. e.g. I have a function which writes a series of data elements into a file on the SD card. with -O0 it works correctly, while -Os mangles the file contents (missing / truncated data) |
| 19:11.50 | T0mW | both -O0 and -Os are Thumb |
| 19:12.14 | MonMotha | oh, ok |
| 19:12.24 | MonMotha | in that case, I'd say the compiler is probably broke |
| 19:12.29 | T0mW | again |
| 19:12.30 | MonMotha | n |
| 19:12.52 | MonMotha | I thought you meant that -Os was going into thumb mode without you asking |
| 19:12.59 | T0mW | no |
| 19:13.01 | MonMotha | and doing an only mediocre job at code creation |
| 19:13.10 | T0mW | I realise I wasn't clear on that, :) |
| 19:13.30 | MonMotha | do you know why the -Os code is breaking? |
| 19:14.27 | MonMotha | -Os can get pretty hardcore on removing "dead" code, reordering things, etc. If you're talking directly to an SD card (especially if you're bit banging on GPIOs) it may just be reordering things that can't actually be or mucking up timing |
| 19:15.16 | T0mW | running the SPI there, but you may be onto something. I'll selectively set -O0 on some of the mmc hardware files |
| 19:15.57 | MonMotha | something else that may help is declaring certain things as volatile |
| 19:16.15 | MonMotha | that pretty much clues the compiler in to the fact that you really don't want those things optimized |
| 19:16.52 | MonMotha | my concern would be that if there is a small error in your code that -O0 may break in the future |
| 19:17.59 | T0mW | good point about the volatile, this is the first large scale project written under gcc. So, I am probably running into coding issues related to the "gcc philosophy". |
| 19:18.47 | MonMotha | gcc does some odd things sometimes. If you can spot where things are going sour in the disassembly, you might be able to trace that back to a minute error in your code (probably a missing volatile) |
| 19:19.01 | MonMotha | I had to do that on an HC12 project I worked on |
| 19:21.06 | T0mW | I don't usually use -Os, but I could not get the LPC2138 (512K flash) chips and had to substitute the LPC2136 (256K Flash). Now I am trying to cram +280K of code inside of 200K |
| 19:22.02 | MonMotha | ah |
| 19:22.14 | MonMotha | how much of a difference is -Os making? |
| 19:24.13 | T0mW | MonMotha: AHA! it is in the hardware section. I wonder if -Os is optimizing the IOPIN selects for the MMC chip select. |
| 19:24.26 | *** join/#edev dijenerate (n=dijenera@216.110.117.35) |
| 19:25.23 | T0mW | -Os == 165984 bytes and -O0 == 209848 bytes |
| 19:25.37 | MonMotha | ok, so that is significant |
| 19:25.46 | T0mW | there is a lot of ascii text in this program |
| 19:26.08 | MonMotha | T0mW: do you have a bunch of statements very near each other that twiddle the IOPINs? |
| 19:26.12 | T0mW | yeah, worthwhile doing the -Os, otherwise the program won't fit |
| 19:26.15 | MonMotha | it may be optimizing them out |
| 19:36.30 | T0mW | wtf |
| 19:36.51 | T0mW | ah |
| 19:37.14 | T0mW | this is a race of some kind |
| 19:46.02 | *** join/#edev FireEgl (i=Atlantic@Atlantica.IRCNut.Com) |
| 19:47.26 | T0mW | MonMotha: it is in the "hardware twiddler" |
| 19:48.19 | MonMotha | ok, that could also cause problems |
| 19:48.31 | MonMotha | and debugging race conditions is ALWAYS fun... |
| 19:49.38 | T0mW | I think to zero in on the affected function, quickly, would be to create a new source file, compile as -O0 and try moving various functions in / out of that file from the affected source |
| 19:50.13 | MonMotha | that might owrk |
| 19:50.15 | T0mW | heh, or just leave that source compiled as -O0 |
| 19:50.21 | T0mW | it is not that big |
| 19:50.31 | T0mW | maybe couple of K |
| 19:51.03 | MonMotha | yeah, though again I'd worry about future breakage |
| 19:51.22 | MonMotha | I guess if time is an issue now, then that's a valid solution |
| 19:51.40 | T0mW | I am, but this is a demo board, to interest the customer in purchasing the design: smoke -n- mirrors anyhow... |
| 19:52.02 | MonMotha | gotcha |
| 19:52.39 | T0mW | MonMotha: I'll put a pragma '#warning "this file does not work with -Os"' |
| 19:52.46 | T0mW | :D |
| 19:52.56 | MonMotha | nice |
| 19:53.04 | MonMotha | at least you'll know where it's breaking again in the future |
| 19:53.13 | MonMotha | perhaps put in some comments about what you found |
| 19:58.39 | jbevren | bah |
| 19:58.43 | jbevren | who needs documented code |
| 19:58.48 | jbevren | obfuscation for teh win |
| 19:59.56 | MonMotha | jbevren: write the firmware for a device entirely in assembly and tell me that |
| 20:00.05 | jbevren | monmotha :) |
| 20:00.09 | MonMotha | my assembly is usually about 75% comments |
| 20:00.14 | jbevren | MonMotha: mine too |
| 20:00.18 | MonMotha | C is usually about 15-25% |
| 20:00.30 | jbevren | MonMotha: I feel sorry for the crew that disassembled the commodore firmware |
| 20:00.40 | *** join/#edev FireEgl (i=Atlantic@Atlantica.IRCNut.Com) |
| 20:00.50 | jbevren | afk lunch :) |
| 20:16.01 | T0mW | MonMotha: does "while ((REG_8 volatile) SSPSR & SSPBSY);" look right to you? |
| 20:20.38 | MonMotha | SSPBSY may need to be volatile as well |
| 20:20.40 | MonMotha | depends on what it is |
| 20:20.59 | MonMotha | I'm surprised that those aren't already declared as volatile |
| 20:21.02 | T0mW | was wondering if the "REG_8 volatile" cast was correct |
| 20:21.08 | MonMotha | oh |
| 20:21.11 | MonMotha | I think you can do that |
| 20:21.12 | T0mW | syntax wise |
| 20:21.23 | MonMotha | I usually just go make sure the declaration includes the volatile keyword |
| 20:21.35 | MonMotha | I presume REG_8 is typedef'd to u8 or similar? |
| 20:21.42 | T0mW | yeah |
| 20:22.01 | MonMotha | I think that's a legal cast |
| 20:22.13 | MonMotha | one of the beauties of C is that you can typecast anything to anything |
| 20:22.18 | MonMotha | the question is if it makes sense :) |
| 20:23.09 | T0mW | yessir, that is the question, heh. I'll find out soon enough |
| 20:27.23 | prpplague | uh anyone familiar with usb host stuff? |
| 20:27.40 | prpplague | our hardware has done something i'm not sure is correct |
| 20:27.57 | prpplague | he's done three usb host sockets connected to only one controller |
| 20:28.08 | prpplague | i don't think the s3c2410 supports that |
| 20:28.29 | T0mW | lol |
| 20:28.53 | T0mW | nothing like having a little bus contention |
| 20:29.10 | MonMotha | is it sad that my home network is more reliable than the cable company? |
| 20:29.17 | MonMotha | prpplague: you can't do that |
| 20:29.20 | MonMotha | they make "hub on a chip" |
| 20:29.24 | MonMotha | use one of those |
| 20:29.31 | MonMotha | then you can also tell which port is which |
| 20:30.39 | prpplague | MonMotha: yea, thats what i thought |
| 20:31.37 | MonMotha | that said, if you can guarantee that only one port will ever be physically connected and they're electrically near each other, it should still work |
| 20:31.44 | MonMotha | it violates the USB spec, of course |
| 20:31.54 | MonMotha | despite its name, USB isn't physically a bus |
| 20:48.38 | prpplague | hehe, just got off the phone with the hardware guy |
| 20:49.04 | prpplague | hehe, they are just providing pads for the three different locations to mount the usb host connector |
| 20:51.21 | MonMotha | ok, that's somewhat reasonable |
| 20:51.30 | MonMotha | are these USB2.0? |
| 20:51.32 | MonMotha | or just 1.1? |
| 20:51.39 | MonMotha | well, full speed, not high speed |
| 20:51.44 | MonMotha | I guess you can do 2.0 at full speed only |
| 20:52.13 | prpplague | MonMotha: 1.1 |
| 20:52.32 | MonMotha | ok, then you should be fine |
| 20:52.46 | MonMotha | at high speed, transmission line effects become very apparent and you can't always get by with that kind of thing |
| 20:52.57 | prpplague | MonMotha: yea |
| 21:52.55 | T0mW | here's a problem: I may go back to working on a W2 basis for a year. Wonder what salary to ask for? |
| 21:53.46 | *** part/#edev EvilDevil (n=miau@p54A6D9E6.dip.t-dialin.net) |
| 21:53.54 | *** join/#edev EvilDevil (n=miau@p54A6D9E6.dip.t-dialin.net) |
| 22:44.47 | *** join/#edev prpplague (n=dave@72.22.147.70) |
| 22:45.06 | prpplague | CP|Home: ping ping ping |
| 22:45.14 | prpplague | CP|Home: 3 ping alarm |
| 22:45.20 | prpplague | CP|Home: are you alive or what? |
| 22:54.44 | *** join/#edev gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net) |
| 22:59.16 | *** join/#edev gandhijee (n=gandhije@c-24-147-213-182.hsd1.ma.comcast.net) |
| 23:03.27 | *** join/#edev redblue (i=star@ppp047.109-253-207.mtl.mt.videotron.ca) |
| 23:07.05 | prpplague | wheeeee |
| 23:07.16 | prpplague | big rulling in the sco vs. ibm case |
| 23:14.31 | chouimat | AAAAAA! |
| 23:17.03 | chouimat | prpplague: url |
| 23:19.14 | agaffney | chouimat: http://www.groklaw.net/article.php?story=20060628175203644 |