| 00:19.29 | *** join/#edev redblue (i=star@ppp141.110-253-207.mtl.mt.videotron.ca) |
| 00:31.40 | ce_geek | Across the wire? |
| 00:42.12 | *** join/#edev redblue (i=star@ppp029.109-253-207.mtl.mt.videotron.ca) |
| 00:50.22 | *** join/#edev redblue (i=star@ppp038.110-253-207.mtl.mt.videotron.ca) |
| 01:07.57 | *** join/#edev nhoman (n=homann@89.100.83.14) |
| 01:18.25 | *** join/#edev redblue (i=star@ppp050.110-253-207.mtl.mt.videotron.ca) |
| 02:02.14 | *** join/#edev redblue (i=star@ppp033.109-253-207.mtl.mt.videotron.ca) |
| 02:15.52 | *** join/#edev landley (n=landley@63.97.171.100) |
| 02:15.52 | *** mode/#edev [+o landley] by ChanServ |
| 02:21.28 | *** join/#edev redblue (i=star@ppp035.110-253-207.mtl.mt.videotron.ca) |
| 03:39.44 | ce_geek | YAAAAAAAAY got Hello World working. |
| 03:40.25 | ce_geek | I scp'd it over and everything. |
| 03:40.37 | ce_geek | Through the ethernet device |
| 03:40.41 | ce_geek | which is exciting. |
| 03:40.55 | sunrunner20 | *integrity |
| 03:45.16 | ce_geek | Why? |
| 03:46.18 | sunrunner20 | website :) |
| 03:46.43 | ce_geek | ok |
| 03:46.55 | ce_geek | Speaking of web, I'd love to play with boa. |
| 03:46.56 | ce_geek | I should do that. |
| 03:47.02 | sunrunner20 | boa? |
| 03:47.06 | sunrunner20 | oh |
| 03:47.08 | ce_geek | boa is a tiny web server |
| 03:47.14 | sunrunner20 | yea |
| 03:47.19 | ce_geek | Hammer development board > thesis and midterm exam |
| 03:47.32 | ce_geek | But thesis and midterm are a bit more urgent at the moment :( |
| 04:27.59 | *** join/#edev redblue (i=star@ppp072.108-253-207.mtl.mt.videotron.ca) |
| 04:39.18 | *** join/#edev redblue (i=star@ppp075.108-253-207.mtl.mt.videotron.ca) |
| 05:04.44 | *** join/#edev KazaLite (n=kazaLite@203.215.177.97) |
| 06:25.18 | *** join/#edev harpal (n=harpal@124.125.76.195) |
| 06:28.32 | *** join/#edev flyback_ (n=user@24.131.197.176) |
| 06:40.49 | *** join/#edev dijenerate (n=dijenera@72.51.68.184) |
| 07:27.07 | *** join/#edev KazaLite (n=kazaLite@203.215.180.205) |
| 07:35.35 | *** join/#edev Shingoshi (n=shingosh@c-67-169-195-234.hsd1.or.comcast.net) |
| 08:08.53 | KazaLite | :'( |
| 08:09.09 | KazaLite | build root says: |
| 08:09.10 | KazaLite | find project_build_mipsel/project/root/usr/lib -name '*.a' -delete |
| 08:09.10 | KazaLite | find: invalid predicate '-delete' |
| 08:09.10 | KazaLite | make: *** [target-devfiles] Error 1 |
| 08:09.15 | KazaLite | :'( |
| 08:28.23 | SpeedEvil | Youve' not got gnu find |
| 08:28.29 | SpeedEvil | what does find --version say |
| 08:29.05 | SpeedEvil | you can change -delete to '-exec rm \{} \;' (without quotes) |
| 08:53.27 | KazaLite | in which file should i make this change? |
| 08:54.14 | KazaLite | the error message i pasted earlier was from buildroot. |
| 08:54.49 | KazaLite | i've find utility on my machine.... |
| 08:58.21 | KazaLite | and how to copy rootfs on hard drive?... i have rootfs as my_rootfs.mipsel.ext2.gz on my machine i can mount it on any directory....but how to transfer it on target hard drive? |
| 08:58.52 | KazaLite | by gunzip my_rootfs.mipsel.ext2.gz i get my_rootfs.mipsel.ext2, so should i just copy my_rootfs.mipsel.ext2 to target hard drive? |
| 09:03.14 | SpeedEvil | Whatever is call9ing find |
| 09:03.28 | SpeedEvil | -delete on find is a gnuisnm |
| 09:09.36 | *** join/#edev harpal_ (n=harpal@124.125.76.195) |
| 10:10.18 | *** join/#edev lyakh (n=lyakh@p57BD2770.dip0.t-ipconnect.de) |
| 10:16.25 | *** join/#edev hw_ (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 13:02.55 | *** join/#edev lyakh (n=lyakh@p57BD2770.dip0.t-ipconnect.de) |
| 13:15.39 | *** join/#edev T0mW (n=Tom@70.44.162.232.res-cmts.sth.ptd.net) |
| 13:21.18 | *** join/#edev chouimat (n=dieu@r2351064.cidc.net) |
| 13:37.55 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 13:41.22 | chouimat | hi prpplague |
| 13:41.30 | prpplague | greetings |
| 14:13.29 | *** join/#edev sunrunner20 (n=jamesdoe@70.104.23.241) |
| 14:18.12 | MothaWork | now, does anybody have any idea why my 8-bit NAND device would most of the time, but not always, identify itself as 16-bits? |
| 14:19.37 | prpplague | MonMotha: no, that seems very odd |
| 14:19.51 | prpplague | MonMotha: does that nand device support 16bit operations? |
| 14:20.34 | MothaWork | not that I'm aware of |
| 14:20.53 | MothaWork | it's a Micron part. Has the 08 where the width goes, and nothing in this family has a 16 bit equivalent. |
| 14:21.33 | prpplague | MonMotha: sure its not on your controller side that is miss identifing the part? |
| 14:21.35 | MothaWork | does it on several boards (and if I replace it with a different part number, it works fine) |
| 14:21.48 | MothaWork | and I managed to google one other instance of somebody using the part, and they have the same problem |
| 14:21.58 | prpplague | ug |
| 14:22.03 | MothaWork | it identifies a 1Gb part correctly |
| 14:22.03 | prpplague | which micron part? |
| 14:22.14 | MothaWork | MT29F8G08MAA |
| 14:22.36 | MothaWork | I don't have a full datasheet, but near as I can tell, it's just a MLC version of the 29F8G08 |
| 14:22.39 | prpplague | interesting |
| 14:22.59 | MothaWork | it was dropped on the board as a substitute for the 29F2G08 since all my quick-ship distributors were out of stock on that part |
| 14:23.04 | prpplague | we had planned on using micron for our new handheld, but we got some "weird" problems with it as well |
| 14:23.26 | MothaWork | I happened to have two left of the 2Gb version, and when I (painstakingly, by hand) replaced the 8Gb parts with those, it worked just fine again |
| 14:23.44 | MothaWork | Micron is all I can easily get in small quantity. Samsung just isn't interested in the volumes I have |
| 14:23.49 | *** join/#edev ce_geek (n=ce_geek@roger-blanchette-4.umelst.maine.edu) |
| 14:23.57 | MothaWork | and those are pretty much your options for large NAND devices |
| 14:23.59 | prpplague | MonMotha: yea, we had to purchase some large spools |
| 14:24.12 | MothaWork | I only need 200 of these in the end |
| 14:24.24 | MothaWork | this is a low-volume companion to a higher volume product |
| 14:25.29 | MothaWork | the signature byte of the part is one bit wrong - the one that makes it x16 instead of x8. Of course, it's hooked up using the x8 pinout, which doesn't line up with the x16 pinout |
| 14:25.44 | MothaWork | so I can't even think that the part is coming up in some sort of x16 mode |
| 14:26.38 | prpplague | MonMotha: i wonder if the reset cycle is too short and you are getting problems |
| 14:26.49 | MothaWork | what's even stranger is that *every once in a while*, it'll identify using the correct stuff, be detected as 8 bits, and then everything works |
| 14:27.11 | T0mW | noise on supply bus? |
| 14:27.34 | MothaWork | that's possible, I guess |
| 14:27.36 | T0mW | ring / overshoot on signals? |
| 14:27.39 | MothaWork | and damn well impossible to debug |
| 14:27.48 | MothaWork | I don't have the equipment to check for ring/overshoot |
| 14:28.06 | T0mW | coulbe be state machine is borked due to outside factors such as noise. |
| 14:28.30 | MothaWork | I just find it odd that it would still identify with the correct manufacturer and the part ID correct except for one bit |
| 14:28.43 | *** join/#edev sjhill (n=sjhill@real.realitydiluted.com) |
| 14:28.43 | *** mode/#edev [+o sjhill] by ChanServ |
| 14:29.23 | T0mW | It might also be bus timing, slow down a bit (one wait state) and see if anything changes |
| 14:29.25 | MothaWork | as much as I'd like to check the high-speed characteristics of this board, I just don't have the equipment |
| 14:29.48 | MothaWork | well, I'll have to ask my software guy to do that |
| 14:29.52 | MothaWork | I attempted to look at the NAND code and got lost |
| 14:30.00 | MothaWork | it's a port into our bootloader from the Linux kernel |
| 14:30.20 | ce_geek | prpplague: Just for fun last night before I left the lab at about midnight I wrote "Hello World!" with no trouble. |
| 14:31.14 | MothaWork | I also wouldn't put it beyond the NAND controller on this uC to simply be buggy |
| 14:31.18 | MothaWork | every other piece of hardware on it is |
| 14:31.50 | MothaWork | it just seems to be a very, very strange failure to get a single bit out of whack |
| 14:32.06 | MothaWork | and have it work just fine on a similar device |
| 14:32.15 | prpplague | ce_geek: that is great!! |
| 14:32.25 | prpplague | ce_geek: feeling much better with the environment now? |
| 14:32.53 | T0mW | problem is that with fast parts, the bus rise-fall slew rates become a signficant factor in the overall timing. You don't see this with slower parts, 5..8ns of rise time on a chip select is nothing when you have a 150ns access time |
| 14:33.22 | T0mW | When you get into faster parts, then the rise/fall slew becomes very signficant |
| 14:33.33 | prpplague | MonMotha: your nand controller have a seperate clock control for the nand i/o timming? |
| 14:33.47 | MothaWork | prpplague: I have absolutely no idea |
| 14:33.55 | prpplague | MonMotha: ahh |
| 14:34.09 | MothaWork | T0mW: the bus timings of the two parts are the same |
| 14:34.13 | ce_geek | prpplague: yep yep, when I have time to spend with it, it's quite fun. |
| 14:34.18 | MothaWork | now, it could be that I'm out of spec and it just happens to work on one but not the other |
| 14:34.39 | prpplague | MonMotha: most SoC's have a prescallers for each of the controllers, much see if you can test at a lower clock |
| 14:34.43 | T0mW | heh |
| 14:34.49 | MothaWork | prpplague: the NAND controller on here is so poorly documented that I'm not sure how it works |
| 14:34.52 | ce_geek | prpplague: It seems like xmodem is sort of a pain in the ass, and it doesn't take a whole lot longer to use OpenOCD. Should it be easier to use apex and xmodem if I want to move just a kernel or a filesystem than it is to use OpenOCD? |
| 14:34.58 | MothaWork | I'd probably have as much luck reading the linux kernel headers |
| 14:35.29 | T0mW | MothaWork: prove it by stretching the timing, be more generous, then you can rule out possible bus timing isses. |
| 14:35.55 | prpplague | ce_geek: its all relative, i've been using a bootloader with xmodem for so long, i really don't notice it |
| 14:36.19 | prpplague | MonMotha: ahh |
| 14:36.23 | T0mW | signal conditioning is trickier, you would need a fast scope to look at them. |
| 14:36.42 | MothaWork | T0mW: and that's the equipment I lack |
| 14:36.55 | MothaWork | I have requested said equipment, but said equipment is very expensive |
| 14:36.56 | ce_geek | prpplague: Did you receive the tiny beginnings of the document I'm working on? |
| 14:36.57 | T0mW | ... and use an ANALOG scope, screw DIGITAL |
| 14:37.24 | ce_geek | T0mW, Awe c'mon. :) I love our digital scopes. I hate the newer ones though :-/ |
| 14:37.32 | T0mW | heh |
| 14:37.37 | ce_geek | T0mW: I like being able to store stuff and download data. |
| 14:37.40 | MothaWork | T0mW: wouldn't sample/hold make this a LOT easier? |
| 14:37.55 | MothaWork | I have an analog scope at home, but it isn't fast enough for this |
| 14:38.06 | MothaWork | well, it MIGHT be fast enough for the NAND (certainly not the SDRAM) |
| 14:38.09 | T0mW | seems you can see more of noise probs with just a 100mhz analog than N-Megasampled digital scope |
| 14:38.23 | MothaWork | well, my digital one here is 1Gsps |
| 14:38.28 | MothaWork | only 100MHz analog bandwidth |
| 14:38.45 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 14:38.45 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 14:43.57 | prpplague | ce_geek: sorry no, did you email it to me? |
| 14:44.17 | ce_geek | prpplague: Yeah. |
| 14:44.27 | prpplague | ce_geek: what address? |
| 14:44.31 | ce_geek | prpplague: I used the same address I used to send you contact info. I assumed that was it. |
| 14:44.40 | prpplague | ce_geek: yea, that was it |
| 14:44.50 | prpplague | ce_geek: spam filter must have gotten it, can you resend? |
| 14:45.19 | ce_geek | prpplague: Sure. Just keep in mind it's just the beginnings :) |
| 14:45.25 | prpplague | ce_geek: np |
| 14:45.28 | *** join/#edev steliosk (n=Stelios@79.131.65.61) |
| 14:45.32 | ce_geek | prpplague: I'll send a link to the file instead of adding as an attachment. |
| 14:45.43 | prpplague | ce_geek: ahh ok |
| 14:45.57 | prpplague | ce_geek: i've got to go to the lab area to do some prototyping, bbiab |
| 14:46.26 | ce_geek | prpplague: Sure. |
| 14:46.43 | Dr{Who} | i would love to see it too ce. |
| 14:54.50 | *** join/#edev RobotGuy (n=robotguy@dsl093-038-072.pdx1.dsl.speakeasy.net) |
| 14:59.07 | Dr{Who} | one note you can add if you didnt yet is that openocd recent versions dont work and maybe a note that we will look into that. |
| 15:07.43 | ce_geek | Dr{Who}: Will do!. Basically what I have is a skeleton, it's full of notes to myself and such. Even though it's got a long ways to go, feedback like that is very useful. I'll be more specific about which sections I consider to be complete as time goes on as well. |
| 15:08.01 | ce_geek | Dr{Who}: SVN is taking forever to upload to my host :(. I'll post a link in a second. |
| 15:08.06 | Dr{Who} | sounds perfect.. are you keeping it in wiki format? |
| 15:09.07 | MothaWork | this is getting really annoying to debug |
| 15:09.33 | ce_geek | Dr{Who}: :( Not at the moment. I'm using Latex to typeset it, mostly because I'm writing my thesis in Latex right now so I'm just in a Latex mode. I realize that a wiki format would be more conducive, but i think in the interest of me actually producing the document, it's best for me to do it this way for now, and perhaps assist with wiki-ifiying it later. I hope that is acceptable. |
| 15:09.34 | MothaWork | and the only reason I care at all is because I'm concerned that it may actually apply to the specified (2Gb) part, too, but it just isn't coming up |
| 15:09.42 | ce_geek | http://www.yessah.net/repos/hammer_board/hammer_doc.pdf |
| 15:09.57 | Dr{Who} | ya thats fine.. |
| 15:11.36 | ce_geek | Dr{Who}: I haven't done wiki stuff in a while. How easy is it to insert figures with captions and figure numbers so it's easy to reference them? |
| 15:12.24 | Dr{Who} | not too bad. |
| 15:13.02 | Dr{Who} | you do have to upload them seperatly though. |
| 15:13.18 | prpplague | Dr{Who}: what aspect of recent releases of openocd does not work? |
| 15:13.36 | MothaWork | AT91C_SMC_DBW_WIDTH_THIRTY_TWO_BITS <--- For those of you who like REALLY LONG SYMBOLS |
| 15:14.09 | Dr{Who} | they changed some of the directives or commands that are in the .ocd file beyond that its possible other issues exist. |
| 15:14.27 | T0mW | MonMotha: :/ |
| 15:14.34 | prpplague | Dr{Who}: ok, then thats not a very accurate statement |
| 15:14.40 | prpplague | Dr{Who}: its the ocd script that does not work |
| 15:14.45 | MothaWork | T0mW: the sad part is that there are longer ones... |
| 15:14.48 | Dr{Who} | hmm |
| 15:15.03 | T0mW | MonMotha: hurray for global search n replace |
| 15:15.03 | MothaWork | whoever wrote this code obviously had and really liked to use an autocomplete |
| 15:15.04 | Dr{Who} | i would say the provided ocd file is not compatible with newer releases |
| 15:15.14 | prpplague | Dr{Who}: yea |
| 15:15.31 | Dr{Who} | yes. but its possible other issues exist. I was still not able to flash even after translating the commands |
| 15:16.17 | RobotGuy | The ocd script that comes with Hammer does work. |
| 15:16.17 | Dr{Who} | but thats still a tbd and not confirmed.. |
| 15:16.40 | RobotGuy | Ahh, nwer releases. |
| 15:16.46 | RobotGuy | s/nwer/newer/ |
| 15:16.58 | Dr{Who} | hehe silly bot |
| 15:17.10 | Dr{Who} | : c ) but not you robotguy.. the perl bot |
| 15:17.17 | RobotGuy | Ha ha |
| 15:17.23 | RobotGuy | Silly bot, kix are for trids! |
| 15:22.31 | ce_geek | prpplague: Sent |
| 15:23.01 | ce_geek | Dr{Who}: Did you get a chance to glance at that? |
| 15:23.08 | Dr{Who} | sure did |
| 15:23.12 | Dr{Who} | looks good.. i like it |
| 15:23.29 | ce_geek | Good good. It will be better when things are a bit more organized and notes to myself are replaced with useful material. |
| 15:23.54 | ce_geek | I tend to like to be a bit verbose just to include as much detail as I can, but that takes time to get completed :-/ |
| 15:24.26 | ce_geek | That file will change as I work on it. That's my subversion repository. |
| 15:27.11 | prpplague | ce_geek: got it thanks |
| 15:28.05 | ce_geek | prpplague: Good good. Maybe bookmark the link or keep it somewhere, I'll just update that file so if I need to show you something or whatever it'll be in the same place. |
| 15:28.24 | prpplague | will do |
| 15:29.59 | RobotGuy | I have modified some of the buildroot .mk files in packages to force stuff to go where I want it. :) |
| 15:36.35 | RobotGuy | I am just tweaking my oen build scripts now. |
| 15:38.22 | RobotGuy | oen=own, sheesh, keyboard needs to go back to school to learn how to spell. |
| 15:41.03 | ce_geek | RobotGuy: Stupid keyboard. |
| 15:45.06 | RobotGuy | Back in a bit - need to get some food. |
| 15:48.28 | MothaWork | prpplague: you think that failure to RESET a NAND device could cause the behavior I'm seeing? |
| 15:48.33 | MothaWork | upon power-up, that is |
| 16:00.35 | Dr{Who} | ok im a bit confused.. same kernel just different busybox and init script as well as a little larger initrd and i am unable to mount /dev/mtdblock1 |
| 16:01.10 | Dr{Who} | mount -t jffs2 /dev/mtdblock1 /mnt/boot/ |
| 16:01.16 | *** join/#edev kajaca (n=rakhus@32.136.154.213) |
| 16:01.16 | Dr{Who} | jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0xdd1b instead |
| 16:01.30 | steliosk | hi all ! |
| 16:01.49 | steliosk | Has anyone ever bought a mac address block from ieee ? |
| 16:02.59 | Dr{Who} | i have used developer blocks.. but never gone for a block no. |
| 16:07.29 | Dr{Who} | i would say its a bit confusing how exactly the JFFS2 part/dev mtd1 is created. |
| 16:11.14 | Dr{Who} | nothing in the flashing or openocd stuff seems to be involved. my only guess so far is the driver itself formats the flash if it sees it is empty or full of nulls? |
| 16:16.29 | *** join/#edev ico2 (n=ico2@modem-3437.chameleon.dialup.pol.co.uk) |
| 16:30.05 | *** join/#edev jdav_gone (n=james@d75-157-13-250.bchsia.telus.net) |
| 16:33.02 | sunrunner20 | http://www.astro.ufl.edu/~ken/crash/ |
| 16:33.04 | sunrunner20 | that |
| 16:33.11 | sunrunner20 | is pure awsomeness |
| 16:34.32 | sunrunner20 | well |
| 16:34.49 | sunrunner20 | as long as you didn't want that data back :) |
| 16:46.09 | prpplague | MonMotha: yea i've seen weird things happen when the reset spec isn't met |
| 16:48.49 | *** join/#edev kazaLite (i=danishJa@116.71.168.190) |
| 16:50.04 | Dr{Who} | prpplague. where is the partitioning of the flash defined i think my increase of my init may have messaed that up too? |
| 16:50.51 | prpplague | Dr{Who}: in the mach definition file, the section you were asking about .size on the other day |
| 16:51.22 | Dr{Who} | so part of apex? |
| 16:56.08 | *** join/#edev emil|k (i=emil@f054013043.adsl.alicedsl.de) |
| 16:58.28 | ce_geek | Dr{Who}: I think .size is a parameter in the kernel source. |
| 16:59.06 | ce_geek | Dr{Who}: http://www.elinux.org/Hammer_How_to_build_Kernel is that what you're talking about? |
| 17:00.09 | ce_geek | Dr{Who}: (From my xchat logs): the size should be calculated like this: bootloader(256k)+kernel(1024k)+ramdisk(2048k)=0x340000 |
| 17:02.35 | Dr{Who} | interesting. |
| 17:04.27 | Dr{Who} | ok so to change size of our initrd root filesystem we have to adjust apex as well as a small kernel mod. |
| 17:04.59 | ce_geek | I don't know much about apex :-/ |
| 17:05.27 | Dr{Who} | well if we dont modify apex then it wont copy over the entire image to the kernel memory prior to starting the kernel |
| 17:05.47 | ce_geek | Ah. |
| 17:07.31 | Dr{Who} | in the init of a linux kernel. the boot loader be it apex or others will copy the initrd file from some storage device be it flash or the hard drive directly into "RAM" at a location the kernel will be expected to look the kernel will then upzip this or use it as a compressed filesystem to mount it and use it as a root filesystem |
| 17:08.19 | ce_geek | Okay, that helps. |
| 17:09.29 | Dr{Who} | normaly no kernel change is needed to adjust this size. but this is different because the kernel ??? needs to understand this filesystem more directly as it is very tuned to the board? so it knows where to mount stuff? |
| 17:09.46 | Dr{Who} | lots of i dont knows there. |
| 17:11.16 | ce_geek | Dr{Who}: Hopefully prp can provide some input when he's got a minute :-/ |
| 17:11.24 | Dr{Who} | ya looks like the mtd partitioning is hard coded into the kernel |
| 17:11.28 | Dr{Who} | mtd_partition tct_hammer_mtd_partitions |
| 17:11.53 | Dr{Who} | probably normal for such hardware. this flash stuff is very board specific. |
| 17:12.34 | ce_geek | Yeah. Understanding that a bit better is one of my objectives for this project and the associated documentation. |
| 17:13.27 | ce_geek | Dr{Who}: I think the next thing I need to do is get some software running so I can demonstrate multiple processes running on the hammer. I figure if I get Boa webserver running and maybe something else that would be interesting. |
| 17:13.52 | ce_geek | Basically I just want interesting output for "top" :) |
| 17:14.05 | ce_geek | Well, because my professor wants to see it too. :) |
| 17:15.31 | Dr{Who} | did u get helloworld.c built yet? |
| 17:15.40 | ce_geek | Dr{Who}: Yup! That was cake. |
| 17:15.47 | Dr{Who} | cool. |
| 17:15.57 | ce_geek | Heh, I was an idiot and put it in /mnt/flash in the root filesystem.... wondered why it wasn't there when I flashed the new rootfs over. |
| 17:16.28 | ce_geek | As another exercise, I tested to see if I could scp it over. That worked well too. Dropbear didn't provide support for sftp though. |
| 17:16.34 | Dr{Who} | : c ) i think.... that if we removed the erase command from the flashing config it would stay |
| 17:16.40 | Dr{Who} | but that erease wipes it all out. |
| 17:18.27 | Dr{Who} | down side is if you dont erase full and you adjust sizes of initrd or other mejor stuff you could have issues. |
| 17:19.01 | Dr{Who} | but i think the erase is not needed if you just update say your rootfs and it does not grow beyond the size you are setup for. |
| 17:19.36 | Dr{Who} | my guess is still that jfs2 will wipe / format the partition / mtd device if it has zero's |
| 17:20.10 | Dr{Who} | normaly you would have to partition a device prior to use.. i would say that the the kernel driver for jffs2 must deal with this automagicly. |
| 17:20.34 | Dr{Who} | because i see no point where this partition is actualy formatted |
| 17:20.57 | ce_geek | Once I understand this stuff a bit better, hopefully I can draw some memory maps / diagrams that help illustrate it too. |
| 17:21.33 | Dr{Who} | that would be very helpfull. hopefully my talking aloud is helping harvest good questions. |
| 17:21.39 | Dr{Who} | if not ill shudup : c ) |
| 17:21.42 | ce_geek | I'm deliberately avoiding it right now because I've got to do some memory maps and address decoding logic for the 68000 on this take-home midterm due next week, and I don't want to get confused. |
| 17:21.55 | ce_geek | No, it's helpful, because when I have time to focus on it I can go back and read my logs. |
| 17:22.00 | *** join/#edev emil|k (i=emil@f054014155.adsl.alicedsl.de) |
| 17:22.03 | Dr{Who} | cool. |
| 17:24.26 | Dr{Who} | so in a nutshell. to adjust sizes we have to adjust the boot loader so it knows where stuff is and then also adjust the kernel so it also knows this. |
| 17:25.52 | Dr{Who} | ya that fixed it. |
| 17:25.58 | Dr{Who} | it now mounts correctly. |
| 17:29.17 | Dr{Who} | i guess on thing that would be good is to make the distinction from this and say a normal boot from a hard drive. how it differs.. a linux booting from say syslinux boot loader understands the geometry by looking at partitions on the drive etc. same with the kernel. but with flash devices and jffs2 we dont waste room for such things so you need to tell your kernel and bootloader where stuff is.. |
| 17:29.56 | Dr{Who} | not sure if thats a good analogy but it seems close. |
| 17:30.44 | CosmicPenguin | its a terrible analogy |
| 17:30.52 | Dr{Who} | : ( |
| 17:34.16 | MothaWork | prpplague: that's what I figured |
| 17:34.31 | MothaWork | I'm not sure if it's being reset properly or not. Difficult to tell from our codebase (and I didn't write it) |
| 17:40.16 | CosmicPenguin | you don't want to make an anology to to a PC because the PC booting process is so broken |
| 17:40.29 | CosmicPenguin | it puts your mind down the wrong path |
| 17:40.36 | prpplague | MothaWork: any way to tack on a manual reset button to the nReset line of just the nand flash? |
| 17:40.43 | Dr{Who} | hmm |
| 17:41.32 | Dr{Who} | i think well at least for me its good to know how a hard drive boot or cf disk etc differes from say a flash boot. this is a learning curve issue. |
| 17:42.10 | Dr{Who} | and broken.. ok well im sure it could be better but broken? how is that relevent.. it is what it is. |
| 17:42.54 | MothaWork | prpplague: this NAND flash does not have a reset line |
| 17:42.57 | MothaWork | you have to reset it by software |
| 17:43.04 | MothaWork | however, I just hacked in a reset, and it seems to work, now |
| 17:43.26 | prpplague | MothaWork: okie dokie |
| 18:01.32 | *** join/#edev kazaLite (n=danishJa@116.71.165.155) |
| 18:10.31 | *** join/#edev ico2 (n=ico2@modem-3437.chameleon.dialup.pol.co.uk) |
| 18:19.51 | *** join/#edev lyakh (n=lyakh@p57BD2770.dip0.t-ipconnect.de) |
| 18:29.38 | kazaLite | hi |
| 18:29.52 | kazaLite | here is the problem im facing regarding my root file system: http://rafb.net/p/3QtTbl41.html |
| 18:30.06 | prpplague | CosmicPenguin: looks like my enc28j60 driver is finally making it into the kernel, - http://kerneltrap.org/mailarchive/git-commits-head/2008/1/29/644309 |
| 18:31.11 | ds2 | congrats ;) |
| 18:31.25 | prpplague | kazaLite: most likely your busybox is incorrectly compiled |
| 18:31.55 | prpplague | ds2: of course claudio really cleaned it up for 2.6 |
| 18:32.05 | kazaLite | ummm................ |
| 18:32.39 | ds2 | prplague: but still, you are getting it into mainline... it is hard enough to do it for one of the sub trees (ARM, etc) |
| 18:32.43 | kazaLite | prpplague: but can you see if im doing anything wrong in the info that i've provided? |
| 18:33.36 | kazaLite | i mean is this the correct way how things should be down? like i mentioned how i take rootfs to target hard drive and inittab file? |
| 18:33.44 | kazaLite | down == done |
| 18:34.13 | prpplague | kazaLite: it can be done that way |
| 18:34.51 | kazaLite | much of reliefe..... as i could not find even a single document on the internet telling how to do these things |
| 18:36.01 | kazaLite | do you have any rootfs built for mipsel? was just thinkg to get one and try to see whether my kernel is all fine or not:P |
| 18:36.23 | prpplague | kazaLite: sorry no, you should probably look at using buildroot |
| 18:36.25 | ds2 | tried looking at the openwrt54 folks? |
| 18:36.35 | ds2 | they should have some kind of mipsel rootfs |
| 18:36.55 | kazaLite | ds2: who should have? |
| 18:37.08 | ds2 | kazaLite: the openwrt project |
| 18:37.14 | ds2 | the WRT54 is a mips core |
| 18:37.45 | kazaLite | i see |
| 18:40.06 | MothaWork | so prpplague: floating ground pin == bad? :) |
| 18:40.16 | MothaWork | amazingly, it doesn't seem to cause any problems |
| 18:40.25 | ds2 | MothaWork: they are bad only if they float to the wrong state :P |
| 18:41.19 | prpplague | MothaWork: doh |
| 18:42.47 | ce_geek | I hate floating pins. |
| 18:43.00 | ce_geek | Especially when it's because my breadboard is messed up, and it appears connected by really isn't. |
| 18:43.38 | ce_geek | Well, it's usually user error.... the insulation gets pushed in or some such garbage. |
| 18:43.45 | ce_geek | :-/ |
| 18:44.19 | ce_geek | Really cool when something is floating whackily enough that when you get close to it, stuff starts working, then you step away and voodoo starts to happen. |
| 18:44.27 | ds2 | i hate bit rot in #if DEBUG sections |
| 18:52.24 | prpplague | MonMotha: weird problem with one of my usb hub designes |
| 18:52.35 | MothaWork | ds2: this is the ground pin for a device, not just an input |
| 18:52.39 | MothaWork | it has another ground |
| 18:52.51 | prpplague | MonMotha: the devices that get attached to the the hub don't seem to un-enumerate very quickly after being unplug |
| 18:53.39 | MothaWork | sadly, the USB hub stuff is not something I understand very well |
| 18:53.43 | MothaWork | haven't ever had to really deal with it |
| 18:53.51 | prpplague | ahh |
| 18:55.05 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 19:03.21 | *** join/#edev DrZimmerman (n=theo@tbaumgartner.broker.freenet6.net) |
| 19:07.54 | kazaLite | prpplague: may be it has to deal with your pulldown logic? |
| 19:08.27 | kazaLite | if you lose pullup, you quickly go for being unenumerated at host side |
| 19:09.32 | kazaLite | also there is no *standard* way to notify disconnection... |
| 19:11.25 | prpplague | kazaLite: yea thats what i'm looking at now, i'm using the standard 15k |
| 19:11.33 | prpplague | kazaLite: might try bumping it to 20k |
| 19:12.33 | kazaLite | prpplague: cannot recommend things very specific to hardware design...i've been writting usb drivers for Nucleus Plus |
| 19:13.46 | kazaLite | how long have you been in hardware designing? and in usb hardware designing? |
| 19:31.43 | prpplague | i've been doing hardware and software embedded systems for awhile |
| 19:31.48 | prpplague | not specific to usb |
| 19:42.04 | *** join/#edev ico2 (n=ico2@modem-3437.chameleon.dialup.pol.co.uk) |
| 19:42.07 | kazaLite | very cool |
| 19:46.35 | *** join/#edev ico2 (n=ico2@modem-3437.chameleon.dialup.pol.co.uk) |
| 19:52.52 | MothaWork | I would just like to take this opportunity to mention that flat flex cables suck |
| 20:10.28 | *** join/#edev ico2 (n=ico2@modem-3437.chameleon.dialup.pol.co.uk) |
| 20:44.08 | davidc__ | MothaWork: whats wrong with flat flex? |
| 21:29.47 | prpplague | davidc__: its flat like your head! |
| 21:31.34 | MothaWork | davidc__: everything :) |
| 21:31.39 | MothaWork | they aren't flat, and they don't flex |
| 21:41.12 | *** join/#edev roxfan (n=dunno@229.221-200-80.adsl-dyn.isp.belgacom.be) |
| 21:59.02 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 21:59.02 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 23:04.40 | *** join/#edev bbradley (n=bbradley@82-32-35-42.cable.ubr05.azte.blueyonder.co.uk) |