**** BEGIN LOGGING AT Tue Aug 04 02:59:57 2009
Aug 04 04:24:39 <stevecrozz> I need some help debugging a kernel module dependency here
Aug 04 04:24:56 <stevecrozz> lsmod tells me that the fuse module exists, but modprobe fuse gives me "Module fuse not found"
Aug 04 04:33:12 <Bartman007> stevecrozz: modprobe requires a modules.dep file to read dependencies from, have you generated one?
Aug 04 04:33:39 <stevecrozz> Bartman007: I've run depmod, but I'm not terribly familiar with it
Aug 04 04:34:04 <Bartman007> any particular reason you feel you need modprobe?
Aug 04 04:34:33 <stevecrozz> a package that I'm porting to openwrt complains with the following: fuse: device not found, try 'modprobe fuse' first
Aug 04 04:35:26 <Bartman007> we omit modprobe for space reasons, insmod should work fine in it's place
Aug 04 04:35:40 <stevecrozz> insmod tells me: insmod: a module named fuse already exists
Aug 04 04:36:02 <stevecrozz> why would this package (s3fs) not see the kernel module?
Aug 04 04:36:36 <Bartman007> maybe it was compiled incorrectly?
Aug 04 04:36:58 <stevecrozz> most likely, as I am the one working on compiling it correctly :)
Aug 04 04:37:26 <stevecrozz> is there something special I have to do to tell this package about openwrt's kernel modules?
Aug 04 04:39:30 <Bartman007> have you passed the proper CFLAGS/LDFLAGS/etc to it
Aug 04 04:39:52 <Bartman007> also, the site indicates it needs fuse 2.6 or later? are you running this on brcm-2.4?
Aug 04 04:40:11 <Bartman007> we only have fuse 2.5.3 packaged for brcm-2.4 IIRC.
Aug 04 04:40:27 <Bartman007> we have 2.7.4 for the 2.6 targets.
Aug 04 04:41:44 <stevecrozz> dang... you're right
Aug 04 04:41:50 <stevecrozz> could that cause this error?
Aug 04 04:42:58 <stevecrozz> I'm very close to having a working port of s3fs fuse filesystem with amazon s3 backend (cloud storage)
Aug 04 04:43:37 <stevecrozz> Bartman007: is there anything keeping fuse at 2.5.3 for this arch?
Aug 04 04:45:03 <Bartman007> good question, I'm not sure.
Aug 04 04:47:54 <Bartman007> hmm, as I suspected, it looks like fuse 2.6 and later dropped support for the 2.4 kernel: http://sourceforge.net/apps/mediawiki/fuse/index.php?title=OperatingSystems
Aug 04 04:49:10 <stevecrozz> dangit, well... is 2.6 an option for my brcm device?
Aug 04 04:49:55 <Bartman007> that's what the brcm47xx target is for, but wireless won't work unless you are using trunk (and even then support depends on which device)
Aug 04 04:50:55 <stevecrozz> this is my device: http://lithostech.com/openwrt-wifi-radio-part-1
Aug 04 04:52:22 <Bartman007> damn. the wl520gU uses a newer PHY that as far as I know is not supported.
Aug 04 04:52:25 <frogonwheels> stevecrozz: tell Bartman007 the error you got when you use insmod fuse
Aug 04 04:52:42 <frogonwheels> (which is the reason you were trying modprobe)
Aug 04 04:53:00 <stevecrozz> it was "insmod: a module named fuse already exists"
Aug 04 04:53:22 <Bartman007> because it is already loaded
Aug 04 04:53:23 <frogonwheels> .. nah .. wasn't there a dynamic link error? or did you already fix that?
Aug 04 04:53:42 <Bartman007> most likely s3fs can't find fuse becaue it is looking for a newer version? just a guess though
Aug 04 04:54:09 <stevecrozz> yeah... i wonder if an older s3fs might work, otherwise i have to find a new device
Aug 04 04:54:53 <Bartman007> xyn: ping
Aug 04 04:55:59 <stevecrozz> is there a good way to tell if its this version discrepancy that's causing my trouble?
Aug 04 04:58:37 <stevecrozz> hey Bartman007: do you have a 2.6 device you could test this package on?
Aug 04 05:03:30 <Bartman007> yeah, can you pastebin the makefile?
Aug 04 05:08:06 <stevecrozz> Bartman007: thanks, here ya go http://pastie.org/570718 , it's my first try so let me know if there's better ways to do stuff
Aug 04 05:10:39 <stevecrozz> it depends on a few libraries from the feeds, libxml2, libcurl, libuClibc++
Aug 04 05:13:43 <Bartman007> stevecrozz: sorry, this is going to have to wait until tomorrow, but I'll take a look at it. an emergency just came up.
Aug 04 05:13:57 <stevecrozz> its ok, ill come back and bug you again another day
Aug 04 05:15:16 <Bartman007> thanks, I'll start the compilation now, but I gotta run
Aug 04 05:29:30 <frogonwheels> oh dang.
Aug 04 05:30:13 <frogonwheels> I've got this Makefile to split apache up into modules (rather than static).  I've had it for ages...
Aug 04 05:30:45 <frogonwheels> .. and now (interestingly), the current version of apache doesn't build for me under x86 - but my modular version _does_
Aug 04 05:31:36 <frogonwheels> I've posted it to the list a couple of times... and Bartman007 was going to have a look at it a couple of times .  anybody interested in tackling it?
Aug 04 05:32:49 <frogonwheels> - it affects apr, apr-util   (adds a target to mysql as well) and of course adds 40+ packages to apache)
Aug 04 05:33:50 <frogonwheels> Also, the minimal footprint is smaller, and gives more flexibility for more complex systems.
Aug 04 09:07:55 <danage> [florian]: ping, pm?
Aug 04 09:15:27 <[florian]> danage: pong
Aug 04 10:51:08 <CIA-36> nbd * r17121 /trunk/target/linux/generic-2.6/files-2.6.30/drivers/net/ (. phy/ phy/ar8216.c phy/mvswitch.c): fix mvswitch/ar8216 tx path hooking for 2.6.30
Aug 04 10:51:13 <CIA-36> nbd * r17122 /trunk/target/linux/atheros/Makefile: set atheros default kernel version to 2.6.30.4
Aug 04 11:12:22 <CIA-36> lars * r17123 /trunk/target/linux/s3c24xx/patches-2.6.30/055-gta02-leds.patch: [s3c24xx] The gta02 vibrator driver is not meant to be build as module.
Aug 04 15:42:42 <Simon94> hi all
Aug 04 15:42:43 <Simon94> any
Aug 04 15:43:15 <Simon94> body. who can help to compile a redboot for my device?
Aug 04 15:43:49 <Simon94> its an surf@home2 aka possio px40. the cpu is a ixp425
Aug 04 16:51:48 <moonflux> xMff: not sure if you read the trac feed, your patch didn't fix bug 5356
Aug 04 16:52:36 <xMff> ?
Aug 04 16:53:13 <moonflux> see my comment at https://dev.openwrt.org/ticket/5356
Aug 04 16:53:18 <moonflux> ipv6 aliases do not work
Aug 04 16:54:21 <xMff> aliases != bug 5356 ;)
Aug 04 16:54:47 <xMff> will look later
Aug 04 16:54:51 <moonflux> well, they are one part for me :)
Aug 04 16:55:29 <moonflux> (I mean, they work theoretically, but obviously not the ipv6-loading)
Aug 04 16:55:34 <moonflux> thx for looking
Aug 04 17:07:30 <AndyI> hi All!
Aug 04 17:07:41 <Simon94> hi
Aug 04 17:12:57 <AndyI> [florian] Today you have a mood to help?
Aug 04 17:14:33 <groz> good morning juhosg :  That patch you gave me yesterday for ethernet macs, works like a treat
Aug 04 17:15:06 <groz> now I only have to fix the alignment on bin generation, so the jffs is properly found/mounted after the initial flash
Aug 04 17:15:10 <groz> without manually erasing
Aug 04 17:15:27 <groz> and i'll be at the point of 'no more problems that I am aware of'
Aug 04 17:15:51 <groz> gonna look at that alignment issue in a couple hours, got a few other things I have to do here first this morning
Aug 04 17:42:33 <juhosg> groz: ok, great. i will commit the mac address patch then
Aug 04 17:45:02 <CIA-36> juhosg * r17124 /trunk/target/linux/ar71xx/base-files/etc/preinit.arch: [ar71xx] init mac address on the WRT160NL board (thanks to Gerry Rozema for testing)
Aug 04 17:45:18 <groz> great
Aug 04 17:45:29 <groz> it gets the two eth macs
Aug 04 17:45:47 <groz> we will probably want to expand it, to get the mac for the wifi too
Aug 04 17:47:22 <groz> ju, i know you committed the ethernet setup stuff from hopscotch, did you also commit his stuff on trx parsing ?
Aug 04 17:49:22 <juhosg> hmz, this won't work from preinit.arch, because ath9k is not yet loaded at this time
Aug 04 17:49:27 <juhosg> you said that you are working on the trx parser, so i did not commit his version yet
Aug 04 17:49:32 <groz> ok
Aug 04 17:49:44 <groz> yah, we need to have a 'philosophy' talk when you have time
Aug 04 17:49:51 <groz> before any of that is commited
Aug 04 17:50:08 <groz> hmm, well, it seemed to come up ok on mine, i had correct mac addresses
Aug 04 17:50:18 <groz> guess I should flash fresh from a wiped one
Aug 04 17:50:21 <groz> and double check
Aug 04 17:50:47 <groz> make sure i haven't carried any of my kludge scirpts that were fixing that initially from nvram
Aug 04 17:50:59 <groz> using nvram utiility
Aug 04 17:52:20 <groz> oh, wait, i misunderstood you,
Aug 04 17:52:32 <groz> yes, it works for ether, but, i see why it wont for ath
Aug 04 17:52:58 * groz thought you meant it wouldn't work for the eth
Aug 04 17:53:29 <groz> so my main big queston on trx stuff, is there any overriding reason to go with single part vs multi part trx when generating bins
Aug 04 17:54:05 <groz> because ultimately, we need to match the bin creation scripts with the way the kernel stuff parses out how to find the squash
Aug 04 17:54:09 <groz> both must be kept in sync
Aug 04 17:54:23 <groz> so, either a single part trx, and then look inside the uimage header to find end of kernel
Aug 04 17:54:35 <groz> or multi part trx, and take the offset of squash from the trx header
Aug 04 17:55:28 <groz> I went the latter route simply because I knew the roadmap in that direction
Aug 04 17:55:43 <groz> but longer term, wondering if there's an overriding philisophical reason to go the other route
Aug 04 18:00:13 <juhosg> honestly, i would go with a static partition map to reduce the code size, but if the trx parser works, and does not break the support of other boards i can live with it
Aug 04 18:00:18 <Bartman007> groz: there is the eventual plan to move to a unified image format, where kernel+rootfs are packed together in a single file
Aug 04 18:01:11 <Bartman007> (for all/most targets)
Aug 04 18:01:31 <groz> yes, but the whole point of the trx header is so that the uboot stuff that's on board, will accept the bin file yes ?
Aug 04 18:01:42 <groz> uboot does check the flash on this one for the trx signature
Aug 04 18:01:45 <groz> before booting it
Aug 04 18:01:56 <groz> or flashing it
Aug 04 18:02:04 <Bartman007> oh, uboot checks the trx sig on boot?
Aug 04 18:02:15 <groz> on flash
Aug 04 18:02:18 <groz> when you flash tftp
Aug 04 18:02:25 <Bartman007> ah, ok.
Aug 04 18:02:29 <groz> with the 'upgrade' commoand from the console
Aug 04 18:02:36 <groz> then it writes it into flash, wth the trx header
Aug 04 18:02:46 <groz> and, it crc checks the partition prior to booting it
Aug 04 18:02:52 <groz> based on the crc in the trx header
Aug 04 18:03:02 <groz> exactly the same way the wrt54gl does
Aug 04 18:03:08 <groz> and i haven't tested this yet
Aug 04 18:03:10 <groz> but I will today
Aug 04 18:03:15 <groz> i believe, if the crc fails
Aug 04 18:03:21 <groz> it falls back to tftp upgrade mode
Aug 04 18:03:41 <groz> upgrade / recovery whatever you wanna call it
Aug 04 18:04:01 <groz> now, it's possibly to just use a single part trx
Aug 04 18:04:10 <groz> with the same image inside it, that goes to all other targets
Aug 04 18:04:30 <groz> then just change the code that hunts for start of squash to go into the uboot header instead of the trx header
Aug 04 18:04:45 <groz> because a bin file for this one, has both headers in it
Aug 04 18:04:48 <Bartman007> a single part trx would but it more in line with the other uboot based ar71xx boards, right?
Aug 04 18:04:50 <groz> first the pattern
Aug 04 18:04:52 <groz> then the trx
Aug 04 18:04:55 <groz> then the uboot
Aug 04 18:04:57 <Bartman007> s/but/put/
Aug 04 18:05:27 <groz> yes it would, and that's why i'm wondering if I should change this
Aug 04 18:05:27 <groz> so it uses the uboot header
Aug 04 18:05:28 <groz> and then we just wrap into a single part trx
Aug 04 18:05:29 <groz> so, once inside the trx header, all are identical
Aug 04 18:06:01 <groz> and in fact, one more thing I need to check
Aug 04 18:06:08 <groz> the current process of building a bin file for this one
Aug 04 18:06:13 <groz> first make the trx
Aug 04 18:06:16 <groz> then 'addpattern'
Aug 04 18:06:24 <groz> it's actually the pattern from addpattern that's checked
Aug 04 18:06:36 * groz wonders if just adding the pattern to a strait uboot image will work
Aug 04 18:06:42 <groz> and skip the trx part altogether
Aug 04 18:06:49 <groz> this is something I can check later today
Aug 04 18:08:24 <groz> when you tftp flash one of these from uboot, the first message is checking for the NL16 pattern in the header
Aug 04 18:08:30 <groz> next message, is checking the crc
Aug 04 18:08:39 <groz> then it says 'image is valid', and proceeds to flash
Aug 04 18:08:57 <groz> i have to check which crc it's actually checking, is it the one in the trx header, or, one in the uboot header
Aug 04 18:09:01 <groz> not sure, easy to check
Aug 04 18:10:53 <Bartman007> my preference would be to use the single part trx to wrap the image, and avoid just tacking the pattern on, hopefully less suprises that way if they change things down the line, but I'll leave the decision up to you and juhosg
Aug 04 18:12:28 <groz> yah, it's a case of 'as close as possible' to the others
Aug 04 18:12:42 <groz> but, make any changes required so the box will actually accept the bin file
Aug 04 18:13:04 <groz> i will experiment this afternoon
Aug 04 18:13:21 <groz> skip the trx altogether, make an image that has the NL16 pattern added directly to a uboot image
Aug 04 18:13:27 <groz> and see if the box will accept it, and boot it
Aug 04 18:13:55 <Bartman007> did linksys release the uboot sources?
Aug 04 18:14:02 <groz> yes
Aug 04 18:14:12 <groz> i have built em, but have not flashed em
Aug 04 18:14:15 <Bartman007> shouldn't it be easy enough to check in there?
Aug 04 18:14:21 <groz> but, one thing I learned, from the wrt54 lineup
Aug 04 18:14:28 <Bartman007> just diff them against upstream
Aug 04 18:14:32 <groz> dont really want to replace uboot in the boxes
Aug 04 18:14:59 <groz> because, as they do different board revisions, uboot will correctly identify and set up for the different revisions
Aug 04 18:15:08 <groz> ie, leave the 'as shipped' uboot on board
Aug 04 18:15:15 <groz> and you can _always_ get back to uboot
Aug 04 18:15:25 <groz> but if we start adding boot loaders
Aug 04 18:15:34 <groz> we can lose boxes real fast with a hardware refision
Aug 04 18:16:04 <groz> i'm also of the mindset, in the short term, 'if it works, it's good'
Aug 04 18:16:13 <groz> then medium / long term, can make it 'more like the others'
Aug 04 18:16:14 <Bartman007> no, I'm not implying adding a bootloader (though juhosg does have a 2nd stage uboot running on some boards) I'm just suggesting looking at the trx code in the uboot source to see what it checks.
Aug 04 18:16:46 <groz> yes, i'll get to that too, just this morning I'm sidetracked on getting some 'real work' done for a couple more hours
Aug 04 18:16:52 <groz> then I can play with this board again
Aug 04 18:17:13 <Bartman007> is your trip delayed, or have you already left?
Aug 04 18:17:32 <groz> haha, delayed, because, family showed up unexpectedly to visit this weekend
Aug 04 18:17:42 <groz> have not seen my sister and nephew for almost 2 years
Aug 04 18:17:50 <groz> so we spent 3 days visiting with sis
Aug 04 18:17:53 <groz> she left this morning
Aug 04 18:18:06 <groz> now I have to 'catch up' a bit, couple real work things to finish before trip can leave
Aug 04 18:18:16 <groz> probly try get out on wednesday morning now
Aug 04 18:18:42 <groz> but its more likely to be thursday some time
Aug 04 18:19:29 <groz> but, I do have the 3g modem working fine now on the nl box, so, I _will_ have a network connection on the road
Aug 04 18:19:53 * groz wonders how long it'll take the full tree to build on the netbook.....
Aug 04 18:20:18 <Bartman007> atom, celly, or via nano?
Aug 04 18:20:28 <groz> atom, asire one
Aug 04 18:20:53 <groz> these things are fun little puters actually, and getting sooooo cheap
Aug 04 18:21:16 <groz> walmart had em this weekend, $299, 1 gig ram, 160g hd, atom, 9 inch display
Aug 04 18:21:24 <groz> at that price, I almost bought one for a spare
Aug 04 18:21:53 <Bartman007> yeah, I've got an eee 900, with the celeron core. I'm definitely going to go for a 10-12 inch when I replace it, keyboard is just a tiny bit too small
Aug 04 18:22:19 <Bartman007> it also has a slow ass dirt mlc ssd, which can be agrivating at times
Aug 04 18:22:28 <groz> hehe, ya, but on mine, I find if I use it for an hour, I get used to the kb real quick
Aug 04 18:22:42 <groz> i got the 9 cell 7800mah battery for it off of ebay
Aug 04 18:22:55 <groz> it run 8+ hours on a battery charge, without using power saving modes
Aug 04 18:23:28 <groz> makes it fabulous to take along when I'm flying, 8+ hours battery, and the 3g modem
Aug 04 18:23:42 <groz> is great combination that way
Aug 04 18:23:57 <groz> if the airport has wifi, use that, if not, plug in the modem
Aug 04 18:24:16 <Bartman007> I'm largely trying to wait for the arm netbooks to come out, and then I'll decide if I grab one of those or a slightly larger x86 model
Aug 04 18:25:44 <Bartman007> but yeah, carrying a <1.5kg device+psu is so much more convenient than carrying my 2.5kg laptop + brick around
Aug 04 18:26:25 <Bartman007> and using both makes working on routers easier :)
Aug 04 18:26:59 <groz> that's why I got the extended life battery
Aug 04 18:27:11 <groz> i rarely take the power supply along if I'm going for only a day
Aug 04 18:28:21 <Bartman007> if this netbook had an atom processor and didn't suffer from several design flaws I probably wouldn't need to either
Aug 04 18:28:43 <Bartman007> (though I think the psu significantly lighter than the 9 cell batteries)
Aug 04 18:29:48 <Bartman007> but the eee 900 is a very poor design that drains 3% / hour (roughly) when in standby, and 8-10% / day when completely turned off
Aug 04 18:30:45 <nbd> ouch
Aug 04 18:30:46 <nbd> that sucks
Aug 04 18:32:02 * groz wonders how well bartmans psu works where there are no power plugs
Aug 04 18:32:16 * groz thinks the 9 cell battery works pretty good without wall power
Aug 04 18:32:48 <Bartman007> groz: I make tesla spin at 15krpm in his grave and capture the power output via induction.
Aug 04 18:33:04 <groz> ok, so, just contemplating the issue of trx / uimage formats etc, and I had a brilliant idea while drinking a coffee just now
Aug 04 18:33:12 <Bartman007> severing a trace to the battery fixes the issue, but that kills the standby voltage required to operate the power button, so you have to install a second power button (though several people have installed it under the existing power button so you just have to push it down for a few seconds)
Aug 04 18:33:17 <groz> how about his, what do you think juhosg
Aug 04 18:33:36 <groz> make the parser dependant on the NL16 header in flash, solves issue of other platforms
Aug 04 18:33:44 <groz> then, have it parse the uboot header first
Aug 04 18:33:57 <groz> then, _if_ the trx header is multi part
Aug 04 18:34:04 <groz> override using the values from trx
Aug 04 18:34:11 <groz> but if it's single part, just use from the uboot header
Aug 04 18:34:18 <groz> voila, simple solution, works in all cases
Aug 04 18:34:29 <groz> and it's only an extra 6 or so lines of code
Aug 04 18:35:43 <Bartman007> groz: oh, it stores the NL16 header in flash? I thought that on broadcom the addpattern/device header is stripped off of the image when written to flash
Aug 04 18:35:56 <groz> it is on broadcom
Aug 04 18:36:00 <groz> it's not on this one
Aug 04 18:36:09 <groz> uboot takes the entire bin image as sent via tftp
Aug 04 18:36:19 <groz> and writes it into flash, complete with the NL16 header
Aug 04 18:36:25 <groz> which adds an issue finding partitions
Aug 04 18:36:33 <groz> cuz everything is offset by 0x20 bytes
Aug 04 18:36:41 <groz> that stupid pattern header is pre-pended
Aug 04 18:36:57 <Bartman007> yay cybertan.
Aug 04 18:36:59 <groz> and, when flashing a virgin box from the web interface
Aug 04 18:37:08 <groz> that's what gets checked for accpeting the bin
Aug 04 18:37:19 <groz> the NL16 header
Aug 04 18:37:42 <groz> so, even if you build the trx with the -a for alignment
Aug 04 18:37:51 <groz> the second section is still off by 32
Aug 04 18:38:04 <groz> but i'm gonna try something here in a few minutes
Aug 04 18:38:14 <groz> just addpattern onto a uboot image, skip the trx part
Aug 04 18:38:22 <groz> and see if the box will accept and boot that
Aug 04 18:38:43 <groz> if so, we can make the whole trx part disappear
Aug 04 18:40:23 <juhosg> if we don't want to generate both kinds of trx images (single and multi part), why do we need this additional code in the trx parser?
Aug 04 18:41:17 <groz> just to be more flexible, in case we find a strong reason to change later
Aug 04 18:44:40 <juhosg> ok
Aug 04 18:44:49 <groz> but, i'm gonna dig a bit more
Aug 04 18:44:53 <groz> maybe this can all be moot
Aug 04 18:49:49 <groz> ok, so, i just quickly built an initramfs image
Aug 04 18:49:54 <groz> ran addpattern on it
Aug 04 18:50:02 <groz> uboot accepted it and is flashing
Aug 04 18:50:07 <groz> skipped trx completely here
Aug 04 18:50:14 <groz> will know shortly if it boots
Aug 04 18:51:00 <groz> Bytes transferred = 3784249 (39be39 hex)
Aug 04 18:51:00 <groz> load addr= 0x80060000
Aug 04 18:51:00 <groz> boot file= TEST.BIN
Aug 04 18:51:00 <groz> NetBootFileXferSize= 0039be39
Aug 04 18:51:00 <groz> Erase linux kernel block !!
Aug 04 18:51:01 <groz> From bf040000 To bf7dffff
Aug 04 18:51:03 <groz> Erase Flash from 0xbf040000 to 0xbf7dffff in Bank # 1
Aug 04 18:51:05 <groz> First 0x4 last 0x7d sector size 0x10000                                      125
Aug 04 18:51:07 <groz> Erased 122 sectors
Aug 04 18:51:09 <groz> Programming.........
Aug 04 18:51:11 <groz> Copy to Flash... write addr: bf040000
Aug 04 18:51:13 <groz> done
Aug 04 18:51:15 <groz> ar7100> boot
Aug 04 18:51:17 <groz> ## Booting image at bf04003c ...
Aug 04 18:51:19 <groz> Bad Magic Number
Aug 04 18:51:35 <groz> ok, so, uboot does want the trx header as well as the addapttern header, _and_ the uboot header
Aug 04 18:51:36 <groz> for this one
Aug 04 18:56:07 <groz> took the exact same kernel image, made a trx, then addpattern, sent by tftp, and now it boots fine
Aug 04 19:44:17 <[florian]> AndyIL: I have always helped you, I am doing this on spare time basis :)
Aug 04 19:55:14 <AndyIL> <[florian]> ok! I not the programmer.
Aug 04 19:55:15 <AndyIL> And it is very difficult to me to copy something seriously
Aug 04 19:57:34 <AndyIL> <[florian]> I cannot add support SPI flash! As the driver at loading hangs
Aug 04 19:58:53 <[florian]> AndyIL: did you add anything for bcm6332 to work?
Aug 04 20:00:07 <AndyIL> <[florian]> bcm6332=bcm6338
Aug 04 20:00:57 <[florian]> AndyIL: ok, bcm6338 does not use SPI, I will check register offsets for bcm6338
Aug 04 20:02:41 <AndyIL> <[florian]> Where this devil's register offset?
Aug 04 20:03:00 <[florian]> AndyIL: target/linux/brcm63xx/files/include/asm-mips/mach-bcm63xx/bcm63xx_regs.h
Aug 04 20:05:11 <AndyIL> <[florian]> More precisely
Aug 04 20:06:26 <[florian]> AndyIL: line 776
Aug 04 20:07:19 <[florian]> AndyIL: need to check this is correct for 6338
Aug 04 20:08:23 <AndyIL> <[florian]> ok! understand!
Aug 04 21:05:57 <CIA-36> florian * r17125 /trunk/target/linux/ar7/ (2 files in 2 dirs): [ar7] register watchdog only if enabled in hardware (#2378)
Aug 04 21:12:02 <AndyIL> [florian] about ar7 watchdog?
Aug 04 21:12:58 <[florian]> AndyIL: yes
Aug 04 21:14:32 <AndyIL> <[florian]> if pull-up resistor on line ea15 absent this register writable
Aug 04 21:31:27 <[florian]> AndyIL: ok, thanks!
Aug 04 21:33:53 <AndyIL> <[florian]> bit 4 in bootcr register writable
Aug 04 21:36:38 <AndyIL> <[florian]> about spi in first router SPI_INT_STATUS return 0 in second  return 1
Aug 04 21:38:07 <CIA-36> lars * r17126 /trunk/target/linux/s3c24xx/files-2.6.30/drivers/mfd/glamo/glamo-gpio.c: [s3c24xx] Fix typo.
Aug 04 21:52:41 <frogonwheels> Is there an acceptable way  (possibly in kernel/modules/*.mk) to get menuconfig to have an option to compile a certain module (ata-piix) into the kernel?
Aug 04 21:53:09 <groz> make kernel_menuconfig
Aug 04 21:53:33 <frogonwheels> groz:  I'm making a new target, and was trying to do it a bit nicer than that.
Aug 04 21:54:00 <groz> when i started with the new ones here
Aug 04 21:54:06 <groz> i started with initramfs kernels
Aug 04 21:54:20 <groz> took all the modules along I needed to get tyhings going from ramdisk
Aug 04 21:54:32 <groz> but i'm guessing, you need that module in order to get to the root file system ??
Aug 04 21:54:55 <frogonwheels> yep
Aug 04 21:55:13 <groz> here's what i did with an x86 box that I have, booting from sd card
Aug 04 21:55:21 <groz> it needed all the usb stuff to reach the root file system
Aug 04 21:55:25 <groz> initramfs kernel
Aug 04 21:55:33 <groz> then rootfs=/disk
Aug 04 21:55:38 <groz> as a kernel parameter
Aug 04 21:55:44 <groz> the initramfs startup scripts
Aug 04 21:55:50 <groz> will pivot onto that disk then
Aug 04 21:55:57 <groz> after loading modules from the initramfs
Aug 04 21:56:11 <groz> and waiting a short period for the actual disk to come available
Aug 04 21:56:18 <groz> if it doesn't come available in 10 seconds or so
Aug 04 21:56:27 <frogonwheels> groz:  it's sata.
Aug 04 21:56:30 <groz> then it continues in a failsafe mode directly from the initramfs
Aug 04 21:56:35 <frogonwheels> groz:  it will be quick :)
Aug 04 21:56:47 <groz> ok, compile everything in as modules from make menuconfig
Aug 04 21:56:51 <frogonwheels> ah
Aug 04 21:56:51 <groz> into an initramfs kernel
Aug 04 21:57:02 <groz> then give that kernel the rootfs=/dev/sd??
Aug 04 21:57:06 <groz> as a parameter
Aug 04 21:57:16 <groz> on my little x86 box that's how I do it
Aug 04 21:57:24 <groz> just enough in the initramfs, to get things up and going
Aug 04 21:57:31 <groz> the drawback to this method
Aug 04 21:57:46 <groz> it doesn't build a fully finished one size fits all image
Aug 04 21:57:59 <Bartman007> frogonwheels: currently the buildsystem doesn't handle situations like that too well. you can explicitly include the driver via your target/linux/foo/config-2.6.xx
Aug 04 21:58:19 <frogonwheels> Bartman007: it's a new x86 sub-target ..
Aug 04 21:59:09 <Bartman007> ah, same applies to a subtarget, as the purpose of a subtarget (vs a profile) is to allow a different kernel config
Aug 04 21:59:35 <frogonwheels> can it then exclude the kernel modules from being built?
Aug 04 22:00:32 <Bartman007> I think there is some logic to prevent them from being built (don't recall) but I do know that any packages that depend on that module won't be installable unless you force it
Aug 04 22:00:40 <frogonwheels> and where does that config go for sub-targets?
Aug 04 22:00:52 <frogonwheels> that's cool
Aug 04 22:01:33 <Bartman007> frogonwheels: take a look at the ixp4xx harddisk subtarget.
Aug 04 22:01:42 <frogonwheels> ta
Aug 04 22:01:42 <Bartman007> target/linux/ixp4xx/harddisk/config-default
Aug 04 22:02:39 <frogonwheels> ah!
Aug 04 22:02:43 <frogonwheels> click
Aug 04 22:03:28 <frogonwheels> I was actually using a 'Target Profile' .. presumably it's not possible to have a config for that - so I'll switch to it being a sub-target.
Aug 04 22:06:01 <frogonwheels> has anybody tried x86-64 bit?
Aug 04 22:07:16 <groz> not me
Aug 04 22:07:19 <happycube> i've compiled under it - didn't see a target tho
Aug 04 22:07:38 <frogonwheels> it seems to be a hidden option.
Aug 04 22:07:53 <frogonwheels> I think that might be stage 2 :)
Aug 04 22:08:17 <frogonwheels> I've got this nice new min-itx box.  think it might actually be more powerful than my desktop.
Aug 04 22:08:28 <frogonwheels> (box that is.. not the actual desk)
Aug 04 22:20:10 <Bartman007> frogonwheels: your desk is more powerful than your desktop computer?
Aug 04 22:20:22 <Bartman007> do you have photos?
Aug 04 22:20:32 <frogonwheels> lol
Aug 04 22:20:53 <frogonwheels> Bartman007: my soon-to-be-openwrt box is more powerful than my desktop
Aug 04 22:20:59 <frogonwheels> computer
Aug 04 22:21:36 <frogonwheels> with the caveat that it only has 1 pci slot :)
Aug 04 22:21:37 <Bartman007> frogonwheels: self-bootstrapping is possible, so you can then use the openwrt box to build openwrt.
Aug 04 22:22:20 <Bartman007> AFAIK it only works on x86 right now
Aug 04 22:22:22 <frogonwheels> Bartman007: I really should.  I've actually installed kubuntu on it on the hard drive.  I'm going to install openwrt on the Compact Flash
Aug 04 22:22:45 <frogonwheels> (it comes with a compact flash holder on board that hooks into the PATA ))
Aug 04 22:24:03 <frogonwheels> the only reason I'm not doing this straight away is the logistics of network and desktop realestate)
Aug 05 00:11:05 <AndyIL> [florian] ping
Aug 05 00:12:34 <AndyIL> [florian] You can add necessary structures for support SPI flash? For check?
Aug 05 00:18:52 <CIA-36> lars * r17127 /trunk/target/linux/s3c24xx/patches-2.6.30/015-mach-gta02.patch: [s3c24xx] mach-gta02: select extra gpio for glamo.
Aug 05 00:55:36 <fofware> xMff: around?
Aug 05 00:55:46 <xMff> fofware: yep
Aug 05 00:56:16 <fofware> hello xMff, this is the right address openwrt-commits@lists.openwrt.org if I want send a patch?
Aug 05 00:56:35 <xMff> no, openwrt-devel@... is the right one
Aug 05 00:56:42 <xMff> but you can create a ticket as well
Aug 05 00:57:08 <fofware> ok, and what can be more fast
Aug 05 00:57:27 <xMff> if you do both :)
Aug 05 00:57:34 <fofware> jejej
Aug 05 00:57:39 <fofware> thanks
Aug 05 00:57:43 <xMff> np
Aug 05 00:58:16 <fofware> so the address is openwrt-devel@lists.openwrt.org
Aug 05 00:58:22 <xMff> exactly
Aug 05 00:58:33 <fofware> thanks very much
Aug 05 00:58:56 <xMff> you should be subscriped there to be able to receive replies
Aug 05 00:59:17 <fofware> yep, I will
Aug 05 00:59:21 <xMff> ok
Aug 05 00:59:28 <fofware> thanks
Aug 05 02:21:35 <frogonwheels> hmm. how do I get the gcc configure target to be defined as 64bit for x86 ? Currently: --target=i486-openwrt-linux-uclibc   (REAL_GNU_TARGET_NAME)
Aug 05 02:22:14 <frogonwheels> .. there seems to be a x86_64 symbol in the openwrt configure, but not sure how that gets set..
Aug 05 02:24:02 <frogonwheels> hmm. that seems to be the key. Just need to get x86_64 to get triggered by the target I guess.. by editing target/Config.in and adding a rule?
Aug 05 02:26:13 <stevecrozz> Bartman007: poke
**** ENDING LOGGING AT Wed Aug 05 02:59:56 2009