**** BEGIN LOGGING AT Sun Jan 21 03:00:03 2007 Jan 21 03:27:33 hi there Jan 21 03:28:06 anybody there knowing how to crosscompile a kernel 2.6 for armv5tel? Jan 21 03:29:17 doch: take a look at org.openembedded.dev/packages/linux Jan 21 03:29:58 there are .bb files for various kernels there Jan 21 03:30:28 doch: Setup MACHINE and bitbake one of the .bb files Jin^eLD mentioned Jan 21 03:32:33 oh thanx, i`ll have a look at that Jan 21 03:34:36 is there a dev topleveldomain? Jan 21 03:36:31 ah ok found it Jan 21 03:48:57 ok, now i didnt find the right .bb, i was looking for a 2.6.16 for a pxa270 zaurus, do you know which ARCH i would have to give the kernel "make" for a armv5tel ? Jan 21 04:06:23 oh its just arm Jan 21 04:08:39 doch: actually you would just have to select an appropriate MACHINE in your OE configuration and build the .bb file Jan 21 04:09:31 'night everyone Jan 21 04:15:39 ok thanx for the tips, i'll better have a deeper look at bitbake instead of tryin to build the kernel without it, n8 Jan 21 07:07:10 RP: It's coming together....it's about as long as it was before but I hope it's more understandable....perhaps I need another pass Jan 21 07:07:21 RP: I mean perhaps I should take another pass... Jan 21 07:07:43 RP: I'll let you know ;-) (waiting for compile, bored) Jan 21 08:25:48 RP: ok, newer version of the patch is posted to the list Jan 21 08:41:29 03koen 07org.oe.dev * r003e2629... 10/ (1 packages/linux/linux-ezx_2.6.16.13.bb): linux-ezx: update to ezx8 Jan 21 08:59:07 good morning all Jan 21 08:59:07 03koen 07org.oe.dev * rdb7cdbcc... 10/ (1 packages/linux/linux-ezx_2.6.16.13.bb): linux-ezx 2.6.16: also apply RPs xscale cache workaround Jan 21 09:05:13 morning psokolovsky Jan 21 09:05:52 Hi! Jan 21 09:26:24 03koen 07org.oe.dev * ra6d3725b... 10/ (1 packages/linux/linux-ezx/defconfig-a780): linux-ezx: update a780 defconfig Jan 21 09:30:15 koen, last evening a see (and touch) a nokia N800 ... really nice ... Jan 21 11:56:27 JustinP: I've replied with some comments. Its better each time :) Jan 21 11:57:56 Does perl build for you guys? Jan 21 11:58:11 Laibsch: It does in poky... Jan 21 11:58:15 I cannot compile it for oz-unstable Jan 21 11:58:23 RP: OK, thanks. Jan 21 13:34:57 hi, all! Jan 21 13:35:42 How could I add out-of-tree conf firectory in local.conf (to search for machine files there)? Jan 21 13:48:28 slapin_nb: Just creat conf/machines and place the file in there Jan 21 13:49:31 RP, I mean out-of-tree - where could I place it? Jan 21 13:50:01 slapin_nb: Your local.conf file is out or tree? Jan 21 13:50:45 (and it lives in a conf directory?) Jan 21 13:50:52 I have oe...... dir, and build/conf/local.conf in different paths Jan 21 13:51:15 slapin_nb: So create build/conf/machine and place the machine conf file in there Jan 21 13:51:26 thanks! Jan 21 13:52:14 mickeyl: ping Jan 21 15:29:50 Morning Jan 21 15:30:10 How do I define PREFERRED_PROVIDER_virtual/db-native? Jan 21 15:30:45 db3-native is failing to build when I'm trying bitbake gpe-image Jan 21 15:45:22 nvmd, found it in the wiki Jan 21 16:04:33 re Jan 21 16:46:40 RDEPENDS are not built, right? One has to either build them explicitly or also DEPENDS on them, correct? Jan 21 16:47:23 Laibsch: it depends Jan 21 16:47:34 LOL Jan 21 16:47:50 do not DEPEND them Jan 21 16:48:07 images/meta say to build RDEPENDS automatically Jan 21 16:49:38 iirc it is BUILD_ALL_DEPS Jan 21 16:49:46 but I'm getting rusty Jan 21 16:50:05 zecke: Well, the reason I ask is that there are a couple of RDEPENDS in ./packages/angstrom/angstrom-gpe-image.bb but they did not get built and thus compilation broke. Jan 21 16:50:16 I am looking for how to fix it. Koen? Jan 21 16:50:31 http://www.openembedded.org/bonsai/query/description/BUILD_ALL_DEPS/ Jan 21 16:55:17 Laibsch: maybe these RDEPENDS can't be resolved? Jan 21 16:55:41 but don't put them into DEPENDS Jan 21 16:55:57 if bitbake wants to download something from a site that's done (in this case libxml2 from xmlsoft.org), but you've found the gz somewhere else.. Jan 21 16:56:11 How can you get bb to accept that the file is already available? Jan 21 16:56:37 e.g. you have a foo.tar.gz in ${DL_DIR} Jan 21 16:56:44 yes Jan 21 16:56:45 then touch foo.tar.gz.md5 in the very same dir Jan 21 16:56:50 ah, thanks Jan 21 16:57:07 CM: is libxml2 unfetchable? Jan 21 16:57:17 So it seems Jan 21 16:57:24 Connecting to xmlsoft.org|194.199.20.115|:21... failed: Connection timed out. Jan 21 16:57:34 CM: just now? or since a couple of days? Jan 21 16:57:44 First time i tried today Jan 21 16:57:44 CM: e.g. check tomorrow and then please file a bug report Jan 21 16:58:08 It's just been for 1h now, but I'll check tomorrow Jan 21 16:59:32 zecke: thanks, compiling libxml2 now Jan 21 17:01:23 zecke: I believe you are right. It seems the names are wrong. Jan 21 17:50:51 RP: yeah, I was thinking along the same lines. Have the keyboard driver use the remote's switch state if it exist, or have the remote take over the switch state from the keyboard if loaded. Jan 21 17:51:18 RP: of course, the problem with this being a module at all is that there's no way for us to know for sure if this device is inserted in order to load the module.... Jan 21 17:52:59 RP: if the keyboard's "insert" check is true then you definately have a headphone and not a remote, but if it doesn't show something inserted then you might have a remote and, as far as I've been able to figure, there's no fool-proof way to know, at any specific time, whether the remote is inserted. (i.e. on module insertion it's impossible to know if the remote is inserted or not. I'll try to look at the Sharp code again to see if anyth Jan 21 18:03:38 philippe: did you build h3800 angstrom imaghe with 2.6 kernel? Jan 21 18:18:16 * yacc wonders, is there a machine config for a dbox2? Jan 21 18:24:58 zecke: ./packages/angstrom/task-angstrom-x11.bb defines the package angstrom-x11-base-depends. angstrom-gpe-image.bb DEPENDS on angstrom-x11-base, but task-angstrom-x11 needs to be built. This is not done automatically, it seems. Is task-angstrom-x11 still no candidate for DEPENDS? Or should angstrom-x11-base etc. in DEPENDS be replaced with task-angstrom-x11? Jan 21 18:25:43 What are all the different branches for? *wonder* Jan 21 18:26:16 Laibsch: just sounds like the gpe image is wrong? Jan 21 18:26:30 "the gpe image"? Jan 21 18:26:47 Laibsch: I don't know :) Jan 21 18:27:09 what do you mean? angstrom-gpe-image.bb? Jan 21 18:27:30 Yes, I suspect that there is something that is not correctly defined there. Jan 21 18:27:39 I was trying to verify this. Jan 21 18:28:07 Laibsch: if it depends angstrom-x11-base and this does not exist, then angstrom-gpe-image.bb is wrong? At least this I what I would guess Jan 21 18:28:45 Yes, I assume so. Jan 21 18:28:56 At least building the image fails. Jan 21 18:29:07 I will see what koen has to say. Jan 21 18:33:33 hi all Jan 21 18:33:46 likewise: *waves from oirschot* Jan 21 18:34:23 koen: you are in the US atm? Jan 21 18:34:48 zecke: no, near Eindhoven Jan 21 18:34:57 I passed thru Son & breughel an hour ago Jan 21 18:35:03 hehe Jan 21 18:35:22 koen: you are at the base? Jan 21 18:35:36 if all goes well I'm gonna pickup the OE server this week Jan 21 18:35:42 likewise: no, in a B&B Jan 21 18:37:28 * likewise waves back Jan 21 20:10:25 03justinp 07org.oe.oz354x * rb21b0528... 10/ (6 files in 4 dirs): gizmod: add gizmod Jan 21 20:10:28 03justinp 07org.oe.oz354x * rb9bb6df9... 10/ (3 files in 3 dirs): gizmod: add patch to disable bmp to avoid GLIB/GTK autoconf errors Jan 21 20:10:33 03justinp 07org.oe.oz354x * r1255fbe0... 10/ (1 packages/gizmod/gizmod_2.3.bb): gizmod: package script Jan 21 20:10:35 03justinp 07org.oe.dev * r98112dc4... 10/ (7 files in 4 dirs): gizmod: add gizmod Jan 21 20:12:03 JustinP: It we could detect it for certain, that would make life easier Jan 21 20:12:23 JustinP: Do the values from the ADC differ when plugged in compared to when not plugged in? Jan 21 20:21:22 RP: ADC? Jan 21 20:21:37 you mean the get_remocon_raw() value? Jan 21 20:21:54 I checked for that last night and I don't think it did...I'll check again, though Jan 21 20:31:07 JustinP: I mean the value from the max1111 chip Jan 21 20:31:42 The MAX1111 is an ADC, the remote control puts a voltage onto the wire, the ADC converts to a number. Each button provides a different voltage... Jan 21 20:37:26 RP: yep, hence the problem figuring out what it means. I'll do another test. Jan 21 20:38:19 forgot for a minute what ADC stood for.... Jan 21 20:52:05 RP: I grabbed the value from the ADC on module insert and it's always 255, whether or not the remote is inserted Jan 21 20:56:14 RP: trying another way Jan 21 21:01:08 JustinP: The GPIO might also make a difference... Jan 21 21:02:25 RP: I think the only thing you can tell is the difference between remote and phones with GPIO set Jan 21 21:02:48 RP: as the remote is open circuit when no buttons are pressed Jan 21 21:02:53 XorA|gone: We just need to have a way of finding if its present or not... Jan 21 21:03:23 RP: is the insert seperate from the ADC Jan 21 21:03:28 insert IRQ Jan 21 21:04:45 XorA|gone: hard to say... Jan 21 21:06:35 It looks like the HP detect and the AK interrupt are two seperate ones... Jan 21 21:07:45 Im figuring when phones are plugged in they will give an ADC reading of almost zero Jan 21 21:08:02 XorA|gone: ah....didn't think of that difference Jan 21 21:08:19 XorA|gone: I'm cleaning up the code and trying to test this right now Jan 21 21:08:48 XorA|gone: problem I'm facing is that I haven't seen a difference between remote inserted and rmeote not inserted... Jan 21 21:09:19 JustinP: I couldnt see guessing at the hardware thats there how you could Jan 21 21:09:48 yeah.... Jan 21 21:10:05 but the Sharp ROM did it....at least I seem to remember it did Jan 21 21:10:20 it's working sort-of right now, but not 100% Jan 21 21:11:41 JustinP: Which interrupt are you using? We have two, 116 (HP_IN) and 13 (AK_IN). They might just happen to provide different information if we're lucky Jan 21 21:12:39 * XorA|gone suspects phones will give a HP_IN and AK_IN on insertion, remote will only give HP_IN Jan 21 21:12:46 hmmm Jan 21 21:12:53 JustinP: It might just be a case of switching spitzkbd to use HP_IN (probably my mistake from the past) Jan 21 21:13:09 ok, module shows 255 whether or not remote it inserted but 0 always when headphones are inserted Jan 21 21:13:34 RP: ok, I'll try switching spitzkbd.c Jan 21 21:25:29 * JustinP reboots his Z Jan 21 21:30:24 holy moly Jan 21 21:30:28 yep, that did it Jan 21 21:30:53 detects both normal headphones and the remote Jan 21 21:31:12 now we can use the combination of both interrupts to signal insertion of the remote device as well :-) Jan 21 21:31:38 AK=1&HP=1 == headphone, AK=0&HP=1 == remote Jan 21 21:31:59 I'll remove all of that crazy insert/eject code from my module driver, it will make it *much* simpler Jan 21 21:32:06 (well, comment out for testing0 Jan 21 21:33:46 JustinP: Excellent. So we should just need to s/AK_IN/HP_IN/ in the keyboard driver and all will be well... Jan 21 21:35:36 Ok, any way to use OE with a dreambox 7000? Jan 21 21:36:16 yacc: I should know the answer, but I don't Jan 21 21:36:55 zecke: ross loves insane.bbclass ;-) Jan 21 21:37:25 hehe, is he running away with it and finishing it? *crosses my fingers* Jan 21 21:37:31 RP: yep, that's what I did. I realize this can be dealt with later, but is it possible to cause the remote driver to be inserted automatically when AK=0&HP=1? Jan 21 21:37:45 or is he in favor of insanity and discordia in general? Jan 21 21:37:56 zecke: I've suggested he should. His first change was to make the errors fatal :) Jan 21 21:38:32 RP: fatal, like randomly rm -rf something? Jan 21 21:38:41 zecke: bb.fatal Jan 21 21:38:57 this reminds me I should fix local.conf.sample Jan 21 21:39:01 to use bb.fatal Jan 21 21:39:01 As in you will fix the build to continue :) Jan 21 21:39:29 so what did it uncover? the heuristic of .so stuff is pretty bad for plugins :} Jan 21 21:39:54 JustinP: Good question. We need some way to signal that to userspace really... Jan 21 21:40:10 zecke: He's busy finding out ;-) Jan 21 21:40:24 hehe Jan 21 21:40:35 back to my CrackFS Jan 21 21:41:26 zecke: does that support pipes :-) Jan 21 21:41:34 zecke: Somehow I dislike strongly the ideo of buying a new box :( Jan 21 21:42:19 RP: could we send another switch from spitzkbd perhaps? remote vs phone? Jan 21 21:42:22 XorA|gone: it is a stupid uni assigment. I call it crack FS becuase I wanted to use Hashes for everyhting, Hash of Hash of Hash Jan 21 21:42:28 RP: so we'd have "inserted" and "type" basically Jan 21 21:42:43 yacc: http://www.openembedded.org/filebrowser/org.openembedded.dreambox/conf/machine Jan 21 21:42:47 zecke: combining hash and crack in one pipe gotta be bad :-) Jan 21 21:42:52 JustinP: The switch events will be hard to get into mainline :-/ Jan 21 21:43:09 XorA|gone: it is in the spirit of jffs2. vs. logfs Jan 21 21:43:23 RP: hmmm....well, we could do that now and figure out the right way to do it later...or you could let me know how it should be changed ;-) Jan 21 21:43:28 zecke: 600,7020 and 7025, but no 7000 :( Jan 21 21:43:39 RP: udev usually handles insertion of modules, right? how could it be triggered? Jan 21 21:43:44 XorA|gone: but hashes of hashes, was too complicated for my lazynes. So I went of and implemented CrappyFS Jan 21 21:43:58 yacc: you don#t happen to know if 7000 and 7020 are compatible? Jan 21 21:44:35 zecke: for the oesf luser your should right super cramfs where you just dont bother to check if a block is already allocated Jan 21 21:44:48 JustinP: Using modaliases Jan 21 21:44:50 zecke: youd get some impressive compression ratios that way Jan 21 21:45:14 hehe Jan 21 21:45:16 zecke: they are basically compatible, the 7020 just got more RAM (96/64MB) and Flash (32/8MB). Jan 21 21:46:02 zecke: the OE 7020 image is rumored to be 10MB big. Jan 21 21:46:03 yacc: ah so, just give it a try Jan 21 21:46:27 yacc: probably, just remove some stuff you don't need. E.g. midnight commander Jan 21 21:46:57 zecke: how do I do that? Jan 21 21:47:08 JustinP: The normal methods won't help us... Jan 21 21:47:27 yacc: get this 'master' makefile which will setup everything for you (don't know if this is current) Jan 21 21:47:55 yacc: http://www.openembedded.org/repo/org.openembedded.dreambox/packages/images/dreambox-image.bb Jan 21 21:48:10 yacc: and you can edit this file and remove tuff you don't want/need Jan 21 21:48:16 yacc: until the image is small enough :) Jan 21 21:48:27 RP: so normally a generic device is created by, say, a bus, and udev picks that up and inserts a module for it, right? Yeah, that wouldn't fix this...unless spitzkbd created the input dev and udev used the name to insert and module.... Jan 21 21:50:54 JustinP: For things like a CF card, the pcmcia id is encoded into a modalias and modprobe is then called with the modalias and searches for matching drivers Jan 21 21:51:18 yeah CrapFS is done, off to be now Jan 21 21:51:32 yacc: you have the luck that tmbinc hangs around here Jan 21 21:51:37 'night zecke Jan 21 21:52:13 another week of Windows Mobile hacking ahead :} Jan 21 21:53:36 ug Jan 21 21:53:42 RP: ok, well I'll take your word for it and leave it alone for now. Once I have this craziness about inserting/removing removed I'll send you another rev Jan 21 21:54:18 Crofton: it is not that bad Jan 21 21:54:54 Crofton: 1.) make it work on linux, valgrind 2.) compile it with cross mingw and valgrind using wine 3.) copy it into the vmware and make it work on wince :) Jan 21 21:55:13 yacc: i do Jan 21 21:55:29 :) Jan 21 21:55:29 yacc: so what was your question? ;) (sorry, i could just read the backlog, but.. ) Jan 21 21:55:58 do you do valgrind with -O0? Jan 21 21:56:06 JustinP: It could be as simple as a call to request_module("sharpsl_rc"); :) Jan 21 21:56:15 Crofton: no, most of the time not Jan 21 21:56:35 I was just going through the man page and it suggested doing it that way Jan 21 21:57:05 yacc: i doubt you'll will be able to make an OE image into 6MB. (if you do that, we'll hire you ;). However, you could use either compact flash or HDD, and boot from there. Jan 21 21:57:08 RP: :-) it's that simple, huh? I'll try that in a few minutes Jan 21 21:57:12 zecke: I'm now worried about you ;-) Jan 21 21:57:17 Crofton: I never did it that way. Some things might be more easy to understand but it is pretty good with -O2 and Os already Jan 21 21:57:17 yacc: (an OE image which still runs enigma, that's it.) Jan 21 21:57:27 JustinP: I suspect you can't call that from IRQ context but you need to work that out... Jan 21 21:57:28 tmbinc: damn! Jan 21 21:57:52 RP: perhaps from a timer that the IRQ sets up? Jan 21 21:58:12 JustinP: timers are also IRQ like context Jan 21 21:58:44 RP: ah....well, I'll try it and see if it bails and go form there Jan 21 22:10:52 JustinP: You can't call that from an IRQ context. Its going to need a workqueue Jan 21 22:11:02 MACHINE_EXTRA_RRECOMMENDS defines modules to load? Jan 21 22:11:16 Crofton: install into the image Jan 21 22:11:44 hmm the module is installed, Jan 21 22:11:56 in this case ohci_hcd Jan 21 22:12:05 but I have to modprobe by hand Jan 21 22:13:43 RP: ok, I'll look into it. Newest version will be coming your way in a few minutes once I make sure it compiles and works as expected. Jan 21 22:14:31 RP: no more switch/case and only 1 check for non-key :-) Jan 21 22:17:14 JustinP: Sounds good :) Jan 21 22:19:24 What's the approved way of *removing* features from DISTRO_FEATURES? (i.e. I want to base MokoSlug on Angstrom, but I want to generate the smallest possible rootfs size, so I want to remove wifi, irda, etc from DISTRO_FEATURES for this particular image) Jan 21 22:20:39 rwhitby: We've talked about a -= variable but we don't have such a thing yet Jan 21 22:20:44 I know I can simply redefine DISTRO_FEATURES - is there a way to remove the ones I don't want, but allow for the possibility of Angstrom defining other features in the future that I still pick up automatically? Jan 21 22:21:01 ok, thx Jan 21 22:21:03 RP: heh, now the state function is about the same length as the probe function ^_^ Jan 21 22:21:04 rwhitby: I'm afraid there is no way to handle that atm Jan 21 22:21:18 JustinP: As it should be :) Jan 21 22:22:31 RP: ok, new version up (r2) and e-mail sent. I'm off for some food. Jan 21 22:24:17 RP: I'm looking for advice on how to structure a new "distro" (using the term loosely, not "DISTRO=" necessarily, so that koen doesn't jump on my terminology) Jan 21 22:24:52 I want to use OE to produce a flashable 8MB image for the NSLU2, which supports using the nslu2 as a server companion for the new OpenMoko phone. Jan 21 22:25:16 rwhitby: Based loosly on Angstrom? Jan 21 22:25:27 I don't want to preclude using the same tasks and such on other targets, but the overriding constraint is that the final rootfs should fit on the nslu2 internal flash. Jan 21 22:25:51 RP: yes - not based on SlugOS, based on Angstrom. Jan 21 22:26:12 (i.e. so that packages and so for are fully compatible, and people can just use the standard angstrom feeds) Jan 21 22:26:41 rwhitby: In that case, I'd include the angstrom core files but set your own version of DISTRO_FEATURES Jan 21 22:27:15 rwhitby: Group things you change compared to angstrom for ease of maintainance and you'll just have to watch for changes :-/ Jan 21 22:27:18 My first inclination was to write "mokoslug.conf", and just require the angstrom 2007.1 conf, then override DISTRO, DISTRO_NAME, etc (including DISTRO_FEATURES and DISTRO_EXTRA_RDEPENDS) Jan 21 22:27:42 That sounds like the best you can do atm Jan 21 22:28:11 i.e. it's angstrom, with a different name (not to try and take credit away from Angstrom, but to make sure that Angstrom doesn't get blamed by any mistakes I make), and with less stuff included by default. Jan 21 22:28:24 It seems reasonable to me... Jan 21 22:28:37 At the moment, Poky is binary compatible with Angstrom too :) Jan 21 22:28:56 The two have pinched things off each other throughout development :) Jan 21 22:29:04 rwhitby: Sounds like I should try to find a nslu2 in sweden ;) Jan 21 22:29:32 I'm also looking to use mokoslug as the means for me to work out how to redo SlugOS properly too. Jan 21 22:29:55 (i.e. re-frame the SlugOS features like sysconf and so forth in ways that can be used by other distros) Jan 21 22:30:21 rwhitby: Sounds like a good aim and useful for both sides :) Jan 21 22:31:16 RP: and then I was thinking that anything which is "moko"-related, (rather than related to constraining things to fit on an nslu2) would be in a new task-mokoserver (or something like that) - is that the way I should be thinking? Jan 21 22:32:21 Is there any plan to move the >10 items in DISTRO_EXTRA_RDEPENDS (which seem to be required for a working base system) into task-base? Jan 21 22:32:24 rwhitby: The task packages are for groups for specific things like a GUI system like opie or gpe, a purpose like a mythtv box so yes, that would fit Jan 21 22:32:46 What does DISTRO_EXTRA_RDEPENDS say atm? Jan 21 22:33:10 look in angstrom-2007.1.conf (right at the end of the file) Jan 21 22:33:28 things like sysvinit, update-modules, netbase, etc Jan 21 22:34:06 I guess we should define a new feature to contain these, some kind of base system feature that the distro can select Jan 21 22:34:22 03mickeyl 07org.oe.dev * reae07a58... 10/ (1 classes/scons.bbclass): scons.bbclass: override installation prefix Jan 21 22:34:26 03mickeyl 07org.oe.dev * r54d4c3d2... 10/ (3 files in 3 dirs): add chibitracker, an SDL based Impulse Tracker clone Jan 21 22:34:38 One interesting policy would be a set of mini utils like busybox vs full ones for example and that would be distro policy Jan 21 22:35:00 tmbinc: I do have a hdd and an USB stick, plus a NFS server. Why 6MB? Jan 21 22:35:18 Some of the mod utils should be triggered by a DISTRO modules feature (and the exact packages triggered by a 2.4 or 2.6 kernel) Jan 21 22:36:24 rwhitby: The other option would be to override the standard DISTRO features in angstrom itself based on the machine (nslu2) Jan 21 22:36:59 RP: yeah, but what about a "fooslug" image for the nslu2 which wants a completely different set of constrained features? Jan 21 22:37:32 i.e. the combination of "angstrom-based" and "nslu2" does not specify a single solution Jan 21 22:37:33 rwhitby: So the issue is a particular image type not wanting features... :-/ Jan 21 22:38:31 i.e. a task-nas based 8MB image might have different things in it compared to a task-mokoserver based 8MB image, but both could be angstrom-based and on the nslu2. Jan 21 22:39:04 (btw, I'm using ixp4xxle as the machine, rather than nslu2, to make sure that it stays compatible with what angstrom is doing) Jan 21 22:40:16 rwhitby: The problem is task-base is a package generated from DISTRO_FEATURES and its not meant to change from one image to the next. Its meant to be a core set of packages, always wanted Jan 21 22:40:55 RP: understood and agreed. Jan 21 22:42:14 rwhitby: Have a look at http://svn.o-hand.com/view/poky/trunk/meta/packages/tasks/task-oh.bb?rev=1106&view=markup Jan 21 22:42:27 rwhitby: This is what poky sits on top of task-base Jan 21 22:43:08 rwhitby: The images select from that pool of packages, depending on the contents of the image desired Jan 21 22:43:53 the thing is that "angstrom" defines a "superset" of the features that are required for a derived distro. this is not a problem for angstrom (assuming it is designed for a specific target set of applications), but does make it hard to create a "smaller" distribution which is closely based on Angstrom (again, not Angstrom's fault) Jan 21 22:44:24 rwhitby: So the problem isn't so much DISTRO_FEATURES but the extra RDEPENDS? Jan 21 22:45:05 well, I need to override both, rather than setting some "meta-features" which restrict those default settings in Angstrom. Jan 21 22:45:42 I guess I'm trying too hard to use Angstrom as the basis for a derived distribution, and expecting things that it hasn't been designed to handle. Jan 21 22:46:29 rwhitby: Going back to the origianl problem, we don't have a -= operator so you need to override the options rather than removing them Jan 21 22:46:50 Since its only a couple of variables, that's not really that bad :) Jan 21 22:47:47 What does concern me is that the standard angstrom config is never going to fit on a nslu2 and it should ideally work. This suggests it should be angstrom itself parring down the image contents for certain machines Jan 21 22:47:49 agreed - none of this is a problem, but I don't want to make the same mistakes again as I did with SlugOS, so I'm carefully checking my assumptions as I go. Jan 21 22:48:31 I guess the above is the root of the problem. I'd like to talk to Koen about that... Jan 21 22:48:36 RP: yes, but there are ixp4xxle machines with 16MB of flash, on which Angstrom will fit. Jan 21 22:48:51 so it's not a processor-based problem, but a board-based problem. Jan 21 22:49:11 So this is why the nslu2 machine exists? Jan 21 22:49:42 well, the nslu2 originally existed cause I was not confident enough with OpenEmbedded to do anything more general than exactly what was required for the nslu2. Jan 21 22:50:14 yacc: because that's whats left in the flash if you subtract bootloader and a bit of free space for the settings Jan 21 22:50:38 tmbinc: Can I boot from the hdd/usb? Jan 21 22:50:38 when koen started angstrom support for xscale, he added ixp4xxle as the supported machine type for angstrom (which makes sense, cause there are lots of ixp4xx devices that are not nslu2s) Jan 21 22:51:04 (including the loft board, which can have lots of flash and ram) Jan 21 22:51:14 rwhitby: But you made the perfect case for an nslu2 machine above - it only has 8MB flash Jan 21 22:51:50 If you can treat machines identically, we only need one machine. If a given device has unique characteristics, it needs its own machine Jan 21 22:52:19 Obviously we need to minimise the number of machines but if there is a good reason for one to exist, so be it Jan 21 22:53:26 An example of seperate machines was corgi shepherd and husy which are all now c7x0. The reason was the 2.4 kernel was different for every device, we can now run the same kernel on them all Jan 21 22:55:04 yacc: not directly. you could store the kernel in flash Jan 21 22:56:29 RP: so what I hear you saying is that I should add nslu2 overrides to angstrom to pare it down to the absolute minimum which will boot an nslu2, and then use task-foo additions to that rootfs to create derived distributions. Jan 21 22:56:59 rwhitby: Ideally, yes Jan 21 22:57:21 ok, I'll run that past koen before implementing it Jan 21 22:57:39 (koen owns angstrom, right?) Jan 21 22:58:08 koen is certainly its lead maintainer and should be consulted about how best to do this Jan 21 22:58:22 yeah, that's what I meant :-) Jan 21 22:58:37 RP: thanks for your counsel. Jan 21 22:58:49 rwhitby: Hopefully it makes sense ;-) Jan 21 22:59:25 rwhitby: My core idea is that a given machine should build correct images whichever distro you choose. If it doesn't something is either wrong with the machine setup or the distro Jan 21 22:59:49 I accept some distros will intentionally only support certain machines in reality ;-) Jan 21 23:01:18 I guess the thing I'm not clear on is whether "Angstrom" is an "abstract distro" which is designed to be "subclassed", or whether there is another level between base OE and Angstrom which I should be using instead (i.e. a binary-compatible abstract distro which both Angstrom and Poky are derived from) ? Jan 21 23:03:16 rwhitby: Its not designed to be subclasses as such, that is new territory but thats not to say it can't be subclassed :) Jan 21 23:03:46 rwhitby: My question is really why are you having to subclass these bits as fixing the standard one might be better? Jan 21 23:04:53 tmbinc: Any idea if the whole boot/start process for the Dreambox is documented somewhere? (E.g. I've got the impression that my DM7000 boots always the same kernel and Dreamflash just decides the rootdevice?) Jan 21 23:05:07 RP: I guess it depends on what the stated aim of Angstrom is. If it is designed for PDAs, then it will be an uphill battle for me to "fix" the standard one (as nothing is broken with respect to its design intent). Jan 21 23:06:20 rwhitby: If its building for a PDA, it could be PDA specific. If its not building for a PDA why not make it not specific to a PDA. I dare say koen would welcome you as the nslu2 machine maintainer in angstrom Jan 21 23:06:29 If it is designed as a "meta distribution" from which targetted distros for things like PDAs vs routers vs nas vs phones can be "subclassed", then I fully agree that I should be fixing the standard one Jan 21 23:07:08 rwhitby: Are you subscribed to angstrom-dev? We should discuss this on the mailing list Jan 21 23:07:59 I want to stay as aligned as possible with the general OE development thrust, but do not want to be bashing my head against a wall (or having arguments with people) just because the thing I am trying to do is not aligned with the "vision" of what I am trying to align with :-) Jan 21 23:08:17 rwhitby: I see angstrom as being an example in OE of how to do things right. I don't see why that can't include supporting both pdas and routers and phones Jan 21 23:08:53 At the moment pdas are well represented so its leaning that way. Personally, I'd welcome someone from the router side to make it work well on routers too Jan 21 23:09:22 I don't know if my views are 100% what koen's or others are, hence we need to talk on the mailing list and discuss it Jan 21 23:09:37 * rwhitby subscribes to angstrom-dev Jan 21 23:10:29 rwhitby: Let me know what you're subscribed and I'll send a mail... Jan 21 23:11:07 (The full address is angstrom-distro-devel@linuxtogo.org) Jan 21 23:11:16 ah, I was already subscribed :-) Jan 21 23:20:22 RP: looks like I'd need to do both nslu2le and nslu2be machine types (or at least name the one that I support like that so I don't exclude someone else doing the other later) Jan 21 23:20:58 RP: or is there a more general way of selecting machine endiannes for machines which can support both? Jan 21 23:21:30 rwhitby: There is no more generic way. I think you're unique in having both and a choice :} Jan 21 23:22:18 Any ideas on how to do it in a more generic way (rather than having both -le and -be versions of machine files) ? Jan 21 23:23:09 rwhitby: Create conf/machine/include/nslu2.inc and require that in the two machine files? Jan 21 23:23:27 yeah, we've done that part already. Jan 21 23:23:34 rwhitby: Or define some kind of variable globally perhaps for endianness? Jan 21 23:24:00 MACHINE_ENDIAN? Jan 21 23:24:11 yes. I'd want to have the nslu2le.conf file simply be a single variable setting and then include a common file. Jan 21 23:24:35 (or you could set MACHINE_ENDIAN in your local.conf for instance) Jan 21 23:24:53 I'd accept adding MACHINE_ENDIAN to local.conf Jan 21 23:25:34 (The help text to state it only functions for machines that support it which is currently only the nslu2 or whatever) Jan 21 23:25:46 yacc: the images contain a cramfs partition which contains the kernel Jan 21 23:26:00 yacc: there are several "boot managers" which try to boot different images without using their kernel. Jan 21 23:26:08 yacc: that's of course a very bad idea. Jan 21 23:28:02 tmbinc: So what is the good idea? Jan 21 23:30:34 yacc: knowing what to do - i.e. using the kernel which corresponds to the drivers, i.e. the most recent ones. as it seems that you want to build your own image (using OE), just take the kernel+drivers from the most recent image (or just use the dbox2 cvs buildscripts to build/download them). then maybe patching the kernel to boot from HDD. put the kernel into a cramfs, and flash it Jan 21 23:30:39 yacc: and put the OE stuff to HDD Jan 21 23:39:37 RP: Shall I send an RFC to oe-devel about MACHINE_ENDIAN? Jan 21 23:39:51 rwhitby: Yes, good idea Jan 21 23:40:11 Do you prefer "el/eb" or "le/be" ? Jan 21 23:40:27 le/be Jan 21 23:40:36 Historically, ARCH_BYTE_SEX has been "le/be", but "el/eb" would be more useful for simply appending to the "arm" string ... Jan 21 23:40:57 I get confused when I see el/eb :-/ Jan 21 23:41:05 that's a good enough reason :-) Jan 21 23:41:56 sent Jan 21 23:57:16 rwhitby: check you mail Jan 21 23:59:06 um byte sex Jan 22 00:07:51 OT: a short movie mocking Kim Jong Il and his secret agent buying something from China: http://www.youtube.com/view_play_list?p=EE52D9ED01495685 Jan 22 00:14:30 nite all, sweet dreams Jan 22 00:26:26 'night all Jan 22 00:29:30 RP: sleep well Jan 22 01:11:26 tmbinc: Guess there is no such thing like a real bootloader that can select different kernels on the dreambox? Jan 22 01:15:18 yacc: feel free to port the 7020 secondstage. its sources are in a cvs somewhere **** ENDING LOGGING AT Mon Jan 22 02:59:58 2007