**** BEGIN LOGGING AT Fri Mar 02 03:00:00 2007 Mar 02 10:27:33 Could someone please explain to me how the target/linux//config/default file is created? Mar 02 10:27:51 I need to create this file for a new platform I am porting to. Mar 02 10:29:57 make kernel_menuconfig Mar 02 10:31:17 Does this automagically put the changes made into the target/linux//config directory? Mar 02 10:32:07 yes Mar 02 10:32:24 Thanks for the info. Mar 02 11:07:11 * armijn prods Kaloz Mar 02 11:07:30 * Kaloz pokes armijn Mar 02 11:08:11 eeps. Mar 02 11:08:28 Kaloz: any good news to report about the WRAP? Mar 02 11:08:39 it works Mar 02 11:08:59 I want to send some feedback to the guy that donated the device ;) Mar 02 11:09:31 should even work with squashfs now. (added that yesterday) Mar 02 11:09:45 but that's only tested in qemu, not on a wrap directly Mar 02 11:09:51 same image, though Mar 02 11:10:16 bottomline, I can report positive stuff Mar 02 11:10:16 good Mar 02 11:10:16 * armijn mails Mar 02 12:21:49 florian * r6454 /trunk/target/linux/au1000-2.6/ (config/default patches/011-mtx1_leds.patch): Add a LED driver for MTX-1 boards, yeah baby Mar 02 12:24:30 :) Mar 02 12:27:15 <[florian]> there is something I have not yet fixed Mar 02 12:27:34 <[florian]> suppose both leds are on, shutdown the power led, it shuts down the red led as well Mar 02 12:27:56 <[florian]> when the red led is on, green off and you want to put the green on, it shuts down the red as well :/ Mar 02 12:28:09 <[florian]> I must be applying the wrong mask on the GPIO line Mar 02 12:39:31 nbd * r6455 /trunk/package/base-files/files/ (etc/init.d/network sbin/ifdown): add support for if{down,up} -a and implement proper start/stop/restart for /etc/init.d/network Mar 02 12:39:54 [florian]: there you go :) Mar 02 12:43:07 <[florian]> nbd: thanks ! Mar 02 13:55:11 <[florian]> ejka: hi ! Mar 02 13:58:02 hi! Mar 02 14:42:17 <[florian]> ejka: thanks for your work on ar7 ! Mar 02 14:44:46 * ejka tries to find out how to enable networking in pspboot atm Mar 02 14:44:54 nbd * r6456 /trunk/target/linux/atheros-2.6/config/default: enable mini_fo on fonera Mar 02 14:48:01 <[florian]> ejka: have you started porting the dsl driver as well ? Mar 02 14:48:16 [florian]: no, not yet Mar 02 14:48:38 [florian]: I first need some prior reading Mar 02 14:49:30 i.e. I have some idea of what atm is, but I have no idea about dsl workings or linux atm stack Mar 02 14:49:46 [florian]: I'm doing the reading and serial cable preparation I need to do in order to have a go at porting the DSL driver on top of ejka's patches. Not sure I'll succeed though. Mar 02 14:51:28 btw, there is new nsp version available in http://mcmcc.bat.ru/acorp/gpl_source/Acorp_3.7.1B_GPL.tar.bz2 Mar 02 14:52:00 with things like slave usb driver Mar 02 14:59:48 ejka: Thanks. No USB on the router I'm playing with, so not sure there'll be much of use in there. Mar 02 15:06:29 nbd * r6457 /trunk/ (4 files in 3 dirs): add support for static routes - based on the patch from #1365 Mar 02 15:18:32 <[florian]> farnz, ejka you both are working on ar7 right ? Mar 02 15:18:42 Trying to. I'm not very good at it. Mar 02 15:19:15 <[florian]> ok, no problem, I am learning too :) Mar 02 15:20:02 ar7, and realtek 865x atm Mar 02 15:20:22 <[florian]> ah realtek too ? I have ported some code to the 2.6 kernel, but I am not sure it is working yet Mar 02 15:30:26 nbd * r6458 /packages/utils/screen/ (Makefile patches/100-cross_compile_fix.patch): fix screen compile error Mar 02 15:32:01 nbd * r6459 /trunk/include/package.mk: add EXTRA_CFLAGS variable support Mar 02 15:45:48 nbd * r6460 /trunk/package/broadcom-diag/src/diag.c: add SimpleTech SimpleShare NAS diag support (untested; based on patch from #1352) Mar 02 16:16:42 nbd * r6461 /packages/net/vsftpd/patches/04-compile_fix.patch: fix vsftpd compile error (#1409) Mar 02 16:17:36 pavlov * r6462 /trunk/docs/build.tex: minor doc changes Mar 02 16:23:40 Can someone tell me how I can prevent all of the generic-2.6 patches from being applied? Mar 02 16:24:03 Alternatively, is there an easy way to create a patch reversal? Mar 02 16:24:26 why? Mar 02 16:25:35 I am using udev as opposed to devfs, and I want to get rid of the devfs back-port stuff for my environment. Mar 02 16:25:59 just disable it in kernel config Mar 02 16:26:30 I have it working correctly if I just delete the 000 and 008 patches. Mar 02 16:26:59 the devfs backport will be nuked from openwrt soon Mar 02 16:27:09 waiting for kaloz to commit his work on mdev Mar 02 16:28:04 cool - Unfortunately I have a project breathing down my neck so I guess in the mean time I must just do a nasty hack Mar 02 16:30:18 nbd * r6463 /trunk/target/linux/x86-2.6/image/Makefile: copy the initramfs kernel to bin/ on x86-2.6 (fixes #1359) Mar 02 16:42:15 nbd * r6464 /trunk/ (4 files in 3 dirs): kernel build cleanup Mar 02 17:35:51 pavlov * r6465 /trunk/ (33 files in 33 dirs): commit profile support for base-files... patches still need to be done Mar 02 17:45:04 I am preparing some patches in order to add support for a new platform to WRT, as I do not have commit privelages on SVN. This platform will not be widely available yet, but it could become an interesting platform to developers. Mar 02 17:45:51 How frequently are patches of this nature comitted to SVN? Mar 02 17:47:23 Or am I wasting my time? My rationale is that I would prefer to have my code in the SVN so I do not have to keep on making deltas to my code. Mar 02 17:47:44 Bsed on core changes. Mar 02 17:49:29 <[florian]> hcg: which platform ? Mar 02 17:50:46 Core is an AT91RM9200 (ARM 920), custom router board with GPRS/EDGE/HSDPA support Mar 02 17:51:02 <[florian]> great, I am just working on that platform for a client :) Mar 02 17:51:19 <[florian]> since he did not want openwrt, I used buildroot, but this is another story ;) Mar 02 17:51:39 hcg: can you make a tarball of your work? i'd like to tkae a look Mar 02 17:52:09 I have a complete buildroot environment for the processor and have decided to move to openwrt Mar 02 17:52:37 I can give you access to my own SVN server if you would like that Mar 02 17:53:10 Of course, I could make a tarball too. Mar 02 17:55:36 nbd: Would you like a tarball of the additions I have made to OpenWrt or to my current working buildroot environment? Mar 02 17:55:44 the additions Mar 02 17:55:51 or make a diff Mar 02 17:56:16 Sure, I can make a diff, how should I send it to you? Mar 02 17:56:29 IP over Avian Carrier Mar 02 17:56:43 hcg: nbd nbd.name Mar 02 17:58:14 Uugh - I have just realised the latest code I have is in my own CVS repository. I will make a tarball. Mar 02 17:58:43 sorry, SVN repository Mar 02 17:59:22 I will put it up on an FTP server of mine and you can grab it from there Mar 02 17:59:32 ok, thanks Mar 02 18:01:14 I will let you know once it is ready. Mar 02 18:01:21 ok Mar 02 18:05:24 nbd: What may be an idea, just to get a look at the work I am doing, is if I send my target/linux/ tree? Mar 02 18:06:32 yeah Mar 02 18:10:27 Should be in your mail - 250k file... Mar 02 18:10:38 yeah, got it Mar 02 18:11:12 I would be really interested in your comments. Mar 02 18:13:46 Florian: How far have you got with the implementation? I am now on my second revision Mar 02 18:15:06 looks interesting Mar 02 18:15:14 but why did you override so much generic code Mar 02 18:15:24 functions.sh, boot script, etc... Mar 02 18:17:12 <[florian]> hcg: I was given the patch for a custom board based on 2.6.17, and the guy only wanted me to do the user-space stuff Mar 02 18:17:25 in functions.sh, the only override is the representation of the mtd devices - ATM with udev I am having them populated as /dev/mtdblock0 instead of /dev/mtdblock/0 etc. I guess I am being lasy not to force udev to create them in the latter format. Mar 02 18:18:29 florian: OK, so he already had the build tree. I understand. Mar 02 18:19:44 nbd * r6466 /trunk/package/base-files/files/etc/functions.sh: make find_mtd_part work without devfs Mar 02 18:19:52 hcg: there you go :) Mar 02 18:20:27 nbd: Boot script etc., we are bringing the board up, and at the moment I do not have part of the GPRS/EDGE/HSDPA backend, so I was wanting to get it up with very little extraneous stuff. Mar 02 18:20:59 it looks to me like you copied the broadcom stuff and used it as a template Mar 02 18:21:09 you could have left that out, the generic code does less stuff Mar 02 18:21:17 and probably works with your board Mar 02 18:21:56 I did indeed, but I am also still navigating the new build environment, so am learning a lot as I go along. Mar 02 18:22:26 yeah Mar 02 18:23:26 The only issue with the generic code still is the backport of devfs - I have my old buildroot env working perfectly with udev, so one of my main tasks was to get that out of the way. Mar 02 18:24:24 I have realised with Kamikase that there are lots of things that are not documented at all, so I am learning slowly by going to the source. Mar 02 18:24:40 feel free to ask questions when there's something that you don't understand Mar 02 18:24:54 of course we will also happily accept patches to stuff in docs/ :) Mar 02 18:25:04 I don't want to look like the dummy round here! Mar 02 18:25:43 I am certainly not a dummy though, I have been doing embedded Linux stuff since 2.0 kernels Mar 02 18:25:56 yeah Mar 02 18:26:34 I will feel free to ask, since you have volunteered that. Thanks a lot. Mar 02 18:27:16 :) Mar 02 18:27:38 I am off to dinner - will be back once I have thought of some intelligent questions :) Mar 02 18:27:54 ok Mar 02 18:58:11 nbd: From the code I sent you, would you conclude there is actually nothing intrusive which will break anything in the main tree? Mar 02 18:58:40 well, i don't know what you changed outside of target/linux Mar 02 18:58:49 but the platform support itself should not break stuff Mar 02 19:00:45 The only issues I have to resolve is to prevent the generic kernel patches 000 and 008 from being impleneted, otherwise, I must greate patch reversals for those two patches and I will be OK. All the rest I can do within my platform changes Mar 02 19:04:34 Mybe I should go ahead and create reversals for the devfs patches, and have those as the first 2 patches I run until kaloz commits the mdev stuff. Mar 02 19:08:35 There is one other modification I have done outside of target/linux, and that is in kernel-build.mk Mar 02 19:08:49 The code I added was: Mar 02 19:08:50 ifneq (,$(findstring vlink,$(BOARD))) Mar 02 19:08:50 KERNELNAME="uImage" Mar 02 19:08:50 endif Mar 02 19:09:45 which also should break nothing. Mar 02 19:10:47 you can probably override that variable from target/linux/vlink-2.6/Makefile as well Mar 02 19:12:53 Any hint as to how I would do that, or should I hit the source? Mar 02 19:14:08 just put KERNELNAME:="uImage" before the BuildKernel call Mar 02 19:14:18 Thanks. Mar 02 19:16:42 nbd: I am in a really inefficient mode at the moment because I have no svn commit priveliges. What I have done is to take a snapshot of OpenWrt this morning, and then put that into my own SVN, and I am updating against my svn. Of course the problem with this is that I will very quickly get out of sync with the main project, which I do not want to do, and I am sure I can contribute to the project overall. Mar 02 19:17:10 svn is really annoying when using multiple repositories Mar 02 19:17:40 Absolutely - I just cannot get multiple repositories to work. Mar 02 19:18:46 well i think it shouldn't be too much of a problem to get you svn commit access soon Mar 02 19:19:14 Is there any possibility you would give me commit access, as long as for the time-being (until approved that is) I only commit anything to a very restricted part of the tree (and that would be target/linux/vlink-2.6) Mar 02 19:20:17 i can't give you commit access. have to wait for mbm or Kaloz Mar 02 19:21:11 No problem. I can wait for them and discuss the merits/demerits. Mar 02 19:24:09 Any idea when they normally hang around on the IRC? Mar 02 19:24:53 depends Mar 02 19:25:28 probably not on a friday night you mean!? Mar 02 19:26:43 Actually, nbd, while I have you on the IRC, how heirarchical are the makefiles? Mar 02 19:26:58 I probably need to explain the question more Mar 02 19:27:59 If I define a variable in my top-level makefile, I assume this would persist and not be over-ridden down the line - is this a correct assumption? Mar 02 19:29:01 variables from the top-level makefile are not passed on unless you explicitly export them Mar 02 19:30:08 ... or put them on the make command line Mar 02 19:31:25 You mentioned above that I shoud place KERNELNAME:="uImage" just before the buildkernel call - I guess in this case, setting the variable just before the call sould override anything previously declared. Mar 02 19:31:58 it is declared in a makefile that is included from target/linux/*/Makefile Mar 02 19:32:16 so if you override it after the include statement but before the template call, it should work Mar 02 19:32:25 OK. Mar 02 19:32:28 because the template call itself generates the bulk of the makefile code Mar 02 19:32:32 Another one ... Mar 02 19:34:29 I noticed recently there was a change to the config handling within the target/linux/ directory in that previously, the file config was referenced by the Kernel buils, but now there is a direcory called config, and I notice all targets currently have a file therein call default. How does this revised mechanism work? Mar 02 19:35:21 we have a script config.pl which can separate and merge config files Mar 02 19:35:30 the common config options are in target/linux/generic-2.6/config-template Mar 02 19:35:47 config/default contains all variables that are different from the ones in config-template Mar 02 19:36:02 after unpacking the kernel sources, both are merged into the final .config Mar 02 19:36:26 and when you use the kernel_menuconfig target, then after running the kernel config, the config is automatically split again Mar 02 19:36:45 the reason why it is a directory is to make it possible for target profiles to override the kernel config Mar 02 19:39:22 OK now I understand. Very useful information, thanks. Mar 02 19:39:51 profiles changing the kernel config shouldn't be used too much, though Mar 02 19:40:05 because a target profile overriding the kernel config can not be built by the image builder Mar 02 19:40:36 OK, but also there are of course architecture reliant dependencies too. Mar 02 19:41:26 I must also say, I have not looked at the image builder at all. Mar 02 19:41:46 it is generated out of the buildroot and builds images just from the kernel image and the binary .ipk packages Mar 02 19:43:14 I need to still grasp the usefulness of the imagebuilder - being a source guy myself, I am sure it is a really useful tool, but I cannot grasp right now for me, the usefulness of it. Mar 02 19:43:25 there is a web frontend for it Mar 02 19:43:32 http://ds10.mine.nu:1337/ Mar 02 19:44:05 But to me right now it is useless because my source is not in the tree! Mar 02 19:44:22 yeah Mar 02 19:44:44 I am caught between a rock and a hard place. Mar 02 19:46:24 ? Mar 02 19:46:25 Right now, I have the proof of concept running for my device, I have it running from a revision about 3 weeks old, but I am reluctant to proceed before I have SVN commit rights because ... Mar 02 19:47:17 I hate having to try to merge 2 different SVN sources which is basically impossible to control. Mar 02 19:47:35 i think one thing you can do is clean up the base-files overrides Mar 02 19:48:45 and you could just maintain your changes as a patchset to openwrt Mar 02 19:48:51 that makes things easier Mar 02 19:48:53 A lot of the base-file overrides also resulted from my attempt to use udev instead of devfs. Mar 02 19:49:11 yes, i know Mar 02 19:49:17 but quite a few of them are also unnecessary Mar 02 19:49:32 with the commit that was announced above you no longer need the functions.sh change, for instance Mar 02 19:49:33 I know Kaloz is working on mdev support, but the question is when will that support be commited? Mar 02 19:50:06 i think i'll just start bugging him more Mar 02 19:50:16 it's not a big change, so we should be able to get it committed soon Mar 02 19:50:16 good idea Mar 02 19:50:47 the devfs patch is one of the main holdups why we're not on 2.6.20 yet Mar 02 19:50:58 we definitely don't want to carry that over to a new kernel version Mar 02 19:51:59 I agree wholeheartedly. Especially proting a new architecture - the backport means I need to modify every single driver I have written, and that is just a PIA Mar 02 19:54:35 I got around the devfs patch by removing patch 000 and 008 (which assumes 000 is in place), and then enabled udev and I also made a couple of patches in udev to support the device reporting correctly, and that was it. Job done. Mar 02 19:55:39 I also understand in the limited memory environments, you guys are looking to get rid of some of the udev bloat, which is why you are using mdev, and I agree for embedded systems this is great. Mar 02 19:56:42 Do you think Kaloz would like some contribution - I am really keem to get udev/mdev running ASAP Mar 02 19:57:30 kaloz said he has mdev running already, so it's just a matter of cleaning the last bits and committing it Mar 02 19:58:03 that sounds good. Mar 02 19:59:10 Where is kaloz? I would really like to chat with him about this. Mar 02 19:59:33 not here, otherwise he'd probably have said something already Mar 02 20:00:12 I was hoing he would chip in with something - hence my last post :) Mar 02 20:01:09 Damn, typical, when you need someone, they are not available! Mar 02 20:02:21 nbd: you have been a great help explaining a lot of stuff to me. I really appreciate it, and I hope I can contribute a lot to OpenWRT in the future. Mar 02 20:02:39 looking forward to it Mar 02 20:04:37 At the moment the only contrib will be in terms of the AT91RM9200, however, in the next few weeks/months, we will also be looking at the AVR/32 which looks like a really cool processor (includes a whole lot of DSP etc:)) Mar 02 20:05:15 sounds good Mar 02 20:07:28 <[florian]> ejka: have you got something booting for rtl865x ? Mar 02 20:07:46 Again, I am sorry to harp on about this, but I am an old fart - I have had a long discussion with you and we have discussed code, build environment, etc, but when I close this IRC chat I have no record of the chat at all as far as I am aware(being an old fart). Mar 02 20:08:26 hcg: that's why there's an archive :) Mar 02 20:08:40 Also, none of the people who were currently not logged onto IRC will have a record. Mar 02 20:09:24 How many people read the archive? Where is the archive available - please forgive me, I am a total newbie to IRC! Mar 02 20:10:42 loswillios: Where is the archive please? Mar 02 20:10:43 <[mbm]> don't expect anyone to read the irc logs Mar 02 20:10:53 <[mbm]> it's openwrt.org/logs Mar 02 20:11:13 mbm: That is what I expected. Mar 02 20:11:51 I followd the tips here and am doing now autologging Mar 02 20:12:27 with grep and stuff. Mar 02 20:13:28 mbm: I have just had a long chat with nbd about a port I am doing, and I am finding I am going sideways with the project without SVN commit privileges - and I would like to discuss this with you, if possible. Mar 02 20:25:47 nbd * r6467 /trunk/include/kernel-build.mk: fix an error in the kernel image related commit **** BEGIN LOGGING AT Fri Mar 02 21:50:13 2007 Mar 02 22:20:41 pavlov * r6468 /trunk/target/linux/ (35 files in 12 dirs): Mar 02 22:20:41 split out profile definitions from Makefiles Mar 02 22:20:41 structure is as follows: Mar 02 22:20:41 target/linux//profiles/.mk Mar 02 22:20:41 These files are included by a blob match in the target Makefile Mar 02 22:20:42 The files should be labeled based on their profile Name in the definition Mar 02 22:22:11 nbd * r6469 /trunk/include/target.mk: revert bogus target.mk change from [6465] Mar 02 22:31:47 nbd * r6470 /trunk/include/target.mk: set the PROFILE variable in target.mk appropriately Mar 02 22:44:10 hcg * r6471 /trunk/target/linux/vlink-2.6/: Added base Mar 02 22:48:09 hcg * r6472 /trunk/target/linux/vlink-2.6/test: Test file - please ignore Mar 02 22:49:09 <[mbm]> :P Mar 02 22:51:04 hcg * r6473 /trunk/target/linux/vlink-2.6/test: Deleting the test file Mar 02 22:54:51 nbd * r6474 /trunk/include/target.mk: final fix for the profile selection Mar 02 23:28:24 hm "restriction free hardware" Mar 02 23:28:30 * armijn reads new FSF thing Mar 02 23:29:59 it is kind of...well... Mar 02 23:30:01 high level Mar 02 23:30:10 I guess that captures it well enough Mar 03 00:40:13 pavlov * r6475 /trunk/target/linux/ (20 files in 20 dirs): make the rest of the structure for the targets that dont have profiles yet **** BEGIN LOGGING AT Sat Mar 03 01:07:02 2007 Mar 03 02:27:58 [florian]: ftp.imfi.kspu.ru/rtl/ **** ENDING LOGGING AT Sat Mar 03 02:59:59 2007