**** BEGIN LOGGING AT Wed Jul 06 02:59:57 2011 Jul 06 03:20:13 build #47 of ar71xx is complete: Failure [failed compile_6] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/47 Jul 06 03:28:12 ^ ltq-tapi roasted quite a few builders Jul 06 04:05:09 cshore * r27468 /packages/lang/perl/patches/200-host-libc-dir-moved-debian+derivatives.patch: [packages] lang/perl: Fixed finding libm and friends due to Ubuntu 11.04 and Debian 6 (Wheezy) using arch dirs for system libraries instead of /usr/lib and /lib. Patch by Andy Doughertry, submitted by Jan. Thanks\! Jul 06 05:51:29 hi Jul 06 05:51:53 so I am trying to port my board to Openwrt... I am working on the kernel Jul 06 05:51:59 I will be using 2.6.37 Jul 06 05:52:14 can somebody confirm me that openwrt does it like this: Jul 06 05:52:25 - gets 2.6.37 from the git Jul 06 05:52:47 - applies all the target/linux/generic/patches-2.6.37 patches Jul 06 05:53:03 - applies my board specific patches Jul 06 05:53:10 is this the order? Jul 06 06:02:04 yes, except that it doesn't get the kernel from git Jul 06 06:02:08 it downloads kernel tarballs Jul 06 06:05:42 oh ok Jul 06 06:05:56 what about the kernel config? Jul 06 06:07:30 merged between target/linux/generic/config-2.6.37 + your kernel config + add-ons based on kernel module config Jul 06 06:09:28 so in my case I will start with a full kernel config that I use on my board, but openwrt will need something more for its own options Jul 06 06:10:22 so I am not sure how to proceed there Jul 06 06:14:41 what you can do is copy a full config to your target dir, run make kernel_oldconfig, which lets openwrt strip it down to only the delta against the default config Jul 06 06:15:16 and then you hand-edit the resulting file, throwing out everything that should be reverted to the openwrt defaults Jul 06 06:15:23 and then run make kernel_oldconfig again Jul 06 06:15:43 after that you have a minimal set of platform specific config items Jul 06 06:15:45 easy to maintain Jul 06 06:17:05 I will have to try and see what happens Jul 06 06:17:31 what about an initranfs that most likely openwrt uses? Jul 06 06:17:40 will that be added automatically? Jul 06 06:30:06 cshore * r27469 /trunk/package/firewall/files/lib/core_rule.sh: [package] firewall: fix udp rules for tcpudp proto rules using src_port and dest_port after modification by the parsing of the tcp rule Jul 06 06:30:27 yes Jul 06 06:30:31 that's part of the automatic config overrides Jul 06 06:30:39 you don't have to worry about that in the platform config ata all Jul 06 06:39:14 cshore * r27470 /trunk/target/linux/brcm63xx/profiles/200-GW6X00.mk: [brcm63xx] profiles: GW6X00: fixed inclusion of both wl and wlc wireless tools...should be just wlc Jul 06 06:39:17 cshore * r27471 /trunk/target/linux/brcm63xx/Makefile: [brcm63xx] Makefile: fixed inclusion of kmod-leds-gpio as a module (breaks Image Generator) - the module is built into the kernel. Jul 06 06:39:42 so nbd, at the end of the process I should endup with a kernel and a rootfs image that I can flash on my board on the correct offsets Jul 06 06:40:19 yes, depending on what you put in target/linux//image/Makefile Jul 06 06:40:44 is there a list of possible options? Jul 06 06:40:58 I have a 128MB NAND Jul 06 08:08:42 juhosg * r27472 /trunk/tools/firmware-utils/src/buffalo-tag.c: tools/firmware-utils: allow to create buffalo tags w/o hw version Jul 06 08:08:43 juhosg * r27473 /trunk/tools/firmware-utils/src/ (buffalo-lib.h buffalo-tag.c): tools/firmware-utils: allow to create buffalo image from two files Jul 06 08:08:44 juhosg * r27474 /trunk/target/linux/ramips/image/Makefile: ramips: create factory image for the WHR-G300N board Jul 06 08:08:45 juhosg * r27475 /trunk/tools/firmware-utils/ (Makefile src/buffalo-tftp.c): tools/firmware-utils: add yet another buffalo tool Jul 06 08:08:49 juhosg * r27476 /trunk/target/linux/ramips/image/Makefile: ramips: create tftp image for the WHR-G300N board Jul 06 08:08:51 juhosg * r27477 /trunk/target/linux/ramips/base-files/etc/diag.sh: ramips: use the 'router' LED for diagnostic on the WHR-G300N board Jul 06 08:08:52 juhosg * r27478 /trunk/target/linux/ramips/base-files/etc/diag.sh: Jul 06 08:08:53 ramips: add diag support for RT-N15 and PWH2004 Jul 06 08:08:53 Also sort the board names alphabetically. Jul 06 08:15:57 hi nbd, can you confirm that my kernel needs to have a partition called "rootfs" for OpenWRT to run correctly? Jul 06 08:16:09 or some other name? I am pretty confused Jul 06 08:16:51 if you don't call it rootfs, then the kernel command line needs to specify the right boot device for it to find it Jul 06 08:17:06 if you call it rootfs, it finds it automatically, that usually makes things easier Jul 06 08:17:18 so we tend to call the partition 'rootfs' on all of our platforms Jul 06 08:17:33 also, if it's called that way, the squashfs/jffs2 split works automatically Jul 06 08:17:38 though i guess that does not apply to NAND flash Jul 06 08:17:44 since squashfs won't work directly on mtd there Jul 06 08:19:24 I do not think I will use the squashfs/jffs2 split Jul 06 08:19:45 simply because there should be enough space for most activities on a 128MB nand Jul 06 08:20:05 what would you recommend on such a sized NAND? We have good experience with UBIFS Jul 06 08:20:12 I never got YAFFS to work Jul 06 08:20:27 JFFS2 is good, works decently Jul 06 08:20:28 ubifs sounds good Jul 06 08:20:41 so OpenWRT has a ubifs "option"? Jul 06 08:20:41 i'd recommend sticking with that Jul 06 08:20:48 it's part of the kernel Jul 06 08:21:00 and i think we have the tools for it as well Jul 06 08:21:17 if not, it should be easy to add Jul 06 08:21:43 ok but... at first I'll try jffs2 I think it's just easier Jul 06 08:22:14 then after things begin to work I will for sure try out the UBI stuff Jul 06 08:23:07 cshore * r27479 /packages/libs/avahi/Makefile: (log message trimmed) Jul 06 08:23:07 [packages] libs/avahi: fixed mutating libavahi/avahi-daemon. The package was Jul 06 08:23:07 producing a package avahi which required dbus if libavahi-dbus-support was Jul 06 08:23:07 selected (even as module), and without dbus if that package was not select. Jul 06 08:23:08 This has been fixed so that there are now dbus versions of the binary packages Jul 06 08:23:08 and non-dbus versions of the ones that can be without dbus, so that the smaller Jul 06 08:23:09 platformas can still have avahi without dbus, and those who want the dbus avahi Jul 06 08:24:17 now, I have the following issue: I start building my kernel by checking out a particular tag of ST's git repository Jul 06 08:24:29 this kernel is based upon 2.6.37 Jul 06 08:24:41 I then need to apply some patches to it for my specific board Jul 06 08:25:01 I was suggested to make a patch that goes from 2.6.37 vanilla -> ST's tag Jul 06 08:25:08 and then some more patches for my board Jul 06 08:25:11 yes Jul 06 08:26:14 but in reality I would need to make a patch from a 2.6.37 with OpenWRT generic patches -> to ST's tag Jul 06 08:26:22 am I correct? Jul 06 08:26:25 no Jul 06 08:26:30 the generic patches are applied first Jul 06 08:26:41 so you just rebase the diff between vanilla and ST on top of the openwrt patches Jul 06 08:28:40 mh Jul 06 08:30:16 are you suggesting to start OpenWR's build system to download a 2.6.37 and apply the generic patches, then ask git to rebase? Jul 06 08:30:24 no Jul 06 08:30:49 I am sorry :( be patient with me, I did not understand then. Jul 06 08:31:00 with rebase i mean make a patch from vanilla to ST, and just make it work on top of the generic openwrt patches Jul 06 08:31:11 so that afterwards you have generic openwrt + st Jul 06 08:31:17 and then your own patches on top of that Jul 06 08:31:45 oh ok, should be straightforward Jul 06 08:31:50 yep Jul 06 08:34:20 ok vanilla-ST is a 2.1MB patch Jul 06 08:34:26 I have it Jul 06 08:34:31 ouch Jul 06 08:34:35 what did they put in there? Jul 06 08:34:50 maybe you can trim it a little Jul 06 08:34:59 support for some SoCs and several drivers Jul 06 08:35:07 ah, ok Jul 06 08:35:10 so nothing intrusive? Jul 06 08:35:17 hopefully not Jul 06 08:35:26 they do not tend to add "features" to kernels Jul 06 08:35:30 do you want me to take a look? Jul 06 08:35:44 sure, if you are so kind Jul 06 08:35:56 do you want me to send you the patch via...? Jul 06 08:36:04 either http or email Jul 06 08:36:09 http is usually faster for me Jul 06 08:36:21 sure gimme a minute Jul 06 08:38:10 http://lnx.manoweb.com/patch-v2.6.37_lsp-3.1.0.xz Jul 06 08:38:22 303kB Jul 06 08:43:16 let me know if you are able to download it etc Jul 06 08:45:40 already looked through it Jul 06 08:45:44 should be mostly fine Jul 06 08:45:52 for some reason it contains some treewide typo fixes Jul 06 08:46:05 hm... for example? Jul 06 08:46:16 but other than that it seems to be limited to touching ST specific stuff or infrastructure related to it Jul 06 08:46:29 don't have examples Jul 06 08:46:35 yes that is what I was expecting Jul 06 08:46:37 ok Jul 06 08:46:42 just something that i noticed while quickly scrolling through the code Jul 06 08:46:52 it touches lots of unrelated files Jul 06 08:46:57 but only changes comments and printk messages Jul 06 08:47:02 no real code changes Jul 06 08:47:18 so now, I need to make possible that patch to apply on top of OpenWRT generic stuff Jul 06 08:47:22 so whenever you get any conflict with openwrt changes, you can probably just drop the relevant section from that patch Jul 06 08:47:24 how do you suggest me to proceed? Jul 06 08:47:31 yes thanks Jul 06 08:47:34 though there should be few conflicts Jul 06 08:47:44 so for fixing up this patch, you should just use quilt Jul 06 08:47:51 since the openwrt build system already sets up the kernel tree using quilt Jul 06 08:50:02 I have never used quilt. Do you think I can first try "by hand" or it is imperative to use quilt? Jul 06 08:52:15 diff by hand is usually quite messy for large patches Jul 06 08:52:26 quilt is not hard to learn and it makes it much easier for you to handle conflicts if there are any Jul 06 08:53:29 I should really learn it Jul 06 08:53:58 nbd: finished the version bump of PPP to 2.4.5... now off to bed. Jul 06 09:10:15 nbd * r27480 /trunk/package/mac80211/patches/542-ath9k_always_enable_fastclock.patch: ath9k: always enable fast clock for 5 ghz regardless of the eeprom setting Jul 06 09:10:33 nbd * r27481 /trunk/package/mac80211/patches/550-ath9k_mmic_verify.patch: ath9k: fix reliability issues with TKIP MIC verification Jul 06 09:10:49 nbd * r27482 /trunk/package/mac80211/patches/560-ath9k_rx_stop.patch: ath9k: fix some more "DMA failed to stop in 10 ms" issues on AR913x (#9654) Jul 06 09:24:55 nbd, for now I am experimenting a bit. I have created target/linux/SPEAr/ and taken the Makefile as an example from the kirkwood platform, that uses a similar version of ARM Jul 06 09:25:26 I have put the 001-lsp-3.1.0.patch in patches Jul 06 09:26:44 I have configured the system with make menuconfig... Jul 06 09:27:03 now in theory I could do a make V=99 to see if the patches are applied correctly? Jul 06 09:28:26 downloading 2.6.37 ... Jul 06 09:28:44 comcast' good tonight 2.2MB/s Jul 06 09:28:59 uncompressing... Jul 06 09:29:24 applying generic patches Jul 06 09:30:05 generic/821-usb_serial_endpoint_size.patch fails :( Jul 06 09:30:55 I retry with 2.6.37.6 Jul 06 09:31:38 and now of course my big patch does not apply! Jul 06 09:37:09 build #56 of cobalt is complete: Failure [failed compile_6] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/56 Jul 06 09:37:14 so I removed patch 821 and 950 and it patched correctly Jul 06 09:37:18 now it's compiling Jul 06 09:37:33 ah I forgot my board specific patches Jul 06 09:47:42 it's compiling a lot of stuff, I still need to work on the config also Jul 06 10:04:01 florian * r27483 /trunk/target/linux/generic/patches-2.6.39/ (260-geode-mfd.patch 261-geode-mfd2.patch): [kernel] refresh 2.6.39 geode patches Jul 06 10:04:32 florian * r27484 /trunk/target/linux/brcm63xx/ (4 files in 2 dirs): [brcm63xx] move board_HW553 inside the ifdef ..BCM6358 .. endif block Jul 06 10:13:09 kaloz * r27485 /trunk/target/linux/generic/patches-3.0/980-update_arm_machtypes.patch: [generic/3.0]: replace the cut down machtype with the full one, as we support a lot of not-yet-upstreamed stuff Jul 06 10:17:54 kaloz * r27486 /trunk/target/linux/cns3xxx/patches-3.0/100-laguna_support.patch: [cns3xxx]: we have an up-to-date mach-type file now Jul 06 10:40:29 blogic * r27487 /trunk/package/uboot-lantiq/ (14 files in 5 dirs): fix lantiq uboot to build lzma compressed bootloaders for eval kits Jul 06 10:40:40 blogic * r27488 /trunk/package/uboot-lantiq/ (4 files in 4 dirs): add support for gigaset SX76X to uboot-lantiq Jul 06 10:40:50 blogic * r27489 /trunk/target/linux/lantiq/ (2 files in 2 dirs): fixes mtd maps for lantiq easy50712 and easy50601 evalkit. without this patch mini_fo/jffs caused the uboot to be overwritten on firstboot Jul 06 10:44:43 nbd, before you told me "copy a full config to your target dir, run make kernel_oldconfig, which lets openwrt strip it down to only the delta against the default config" Jul 06 10:45:24 so now I am copying a "working" .config to target/linux/SPEAr/config-default ?? Jul 06 10:45:34 is this what you meant nbd ? Jul 06 10:59:59 alesan: yes Jul 06 11:01:40 ok... I did it and I run make kernel_oldconfig in the openwrt root directory... Jul 06 11:02:10 yes Jul 06 11:02:21 now the config-default should be much smaller Jul 06 11:02:21 where should I expect to find the "stripped down, delta against the def. config"? Jul 06 11:02:32 config-deafult <-- that file ;) Jul 06 11:03:07 yes Jul 06 11:03:08 ok Jul 06 11:03:15 yes it's smaller indeed Jul 06 11:03:26 then nbd continued: Jul 06 11:03:39 and then you hand-edit the resulting file, throwing out everything that should be reverted to the openwrt defaults Jul 06 11:04:23 I am not quite sure what he meant here, now that I am trying to follow his recommendations Jul 06 11:04:57 what should I remove basically? Jul 06 11:05:17 some modules are handled via package/kernel/ Jul 06 11:05:33 yes...? Jul 06 11:05:45 so, if in "make menuconfig" you want to be able to select USB, then your config-default should not have CONFIG_USB=< Jul 06 11:05:48 so, if in "make menuconfig" you want to be able to select USB, then your config-default should not have CONFIG_USB=y Jul 06 11:06:13 if your config-default has a CONFIG_USB=y then the kernel modules for usb wont be able to override this Jul 06 11:06:53 ok but... how do I know what I may want to remove? Jul 06 11:07:02 hehe Jul 06 11:07:09 pastebin your config-default please Jul 06 11:07:13 lets have a look Jul 06 11:07:19 basically stuff like drivers mainly Jul 06 11:07:31 all drivers that should later be able to work via modules should be removed Jul 06 11:07:40 blogic, I will paste the "reduced" one Jul 06 11:07:45 only those drivers you need statically linked should be in there Jul 06 11:07:55 yes, the reduced one is what we need to look at Jul 06 11:07:57 after the first make kernel_oldconfig Jul 06 11:07:59 is that ok? Jul 06 11:08:02 yes Jul 06 11:08:09 ok give me a second Jul 06 11:08:28 of course Jul 06 11:08:33 brb, need to get a drink Jul 06 11:09:30 http://pastebin.com/FU7FEC33 Jul 06 11:10:13 do you need USB at boottime ? Jul 06 11:10:22 otherwise i would remove all the CONFIG_USB stuff Jul 06 11:10:28 same goex for CONFIG_INPUT Jul 06 11:10:50 if you have no SPI flash i would remove that aswell Jul 06 11:11:08 ONFIG_KEYBOARD_ATKBD=y Jul 06 11:11:10 ;) Jul 06 11:11:19 CONFIG_IP_PNP=y Jul 06 11:11:19 CONFIG_IP_PNP_BOOTP=y Jul 06 11:11:19 CONFIG_IP_PNP_DHCP=y Jul 06 11:12:34 well OK I will need to check the config because it has a lot of crap that is not needed Jul 06 11:12:36 :) Jul 06 11:12:58 blogic, do you think for the first experimental run, can I keep it like this? Jul 06 11:13:11 yes Jul 06 11:13:14 once I know OpenWRT works on this board, I will do the fine work Jul 06 11:13:20 blogic: i see you have commited sx763 uboot :) Jul 06 11:13:25 luka12345|wiik: noo Jul 06 11:13:26 wait Jul 06 11:13:31 it only half works Jul 06 11:13:41 the ethernet stops working after a few packets Jul 06 11:13:49 i am trying to fix it just now Jul 06 11:14:05 luka12345|wiik: the adm6996I uses a 26Mhz clock and not 25Mhz Jul 06 11:14:10 i think this might be the problem Jul 06 11:14:15 oh - so OpenWRT also supports U-Boot I need to build a custom U-Boot (and XLoader) for this board too Jul 06 11:14:33 blogic: you mean problems with tftp? Jul 06 11:14:35 alesan: yes, you can build uboot Jul 06 11:14:38 luka12345|wiik: yes Jul 06 11:14:43 alesan: package/uboot-* Jul 06 11:14:44 .) Jul 06 11:15:01 i have also simmilar problems Jul 06 11:15:08 which are ? Jul 06 11:15:21 i can not get the image via tftp every time Jul 06 11:15:49 sometimes i have to retry like 10 or 20 times Jul 06 11:16:19 but the interface stays up Jul 06 11:16:19 yes Jul 06 11:16:42 for me the first 5-10 packets work then it stalls Jul 06 11:17:00 luka12345|wiik: i will continue later today Jul 06 11:17:03 ok Jul 06 11:17:08 i need to think of a solution Jul 06 11:17:28 getting close though ;) Jul 06 11:17:44 took me a while to get the switch working Jul 06 11:17:54 and it seems its not fuly working yet ;) Jul 06 11:18:43 can i use the this uboot to be chain loaded? Jul 06 11:18:58 for tftf i use tricke to limit tftfd trafic Jul 06 11:18:59 http://monkey.org/~marius/pages/?page=trickle Jul 06 11:19:05 *tftp Jul 06 11:19:25 it help's sometimes Jul 06 11:19:28 nope Jul 06 11:19:52 this loader has a small lzma stub that then decompresses the real uboot and runs it from ram Jul 06 11:19:59 doing so the full binary is only 64k Jul 06 11:20:05 (incl the https server) Jul 06 11:20:10 *http Jul 06 11:20:32 an https server for U-Boot? Jul 06 11:20:42 http Jul 06 11:20:55 failsafe ui Jul 06 11:21:05 lets you use http to upload a owrt image Jul 06 11:21:14 ok, so U-Boot has an http server??? Jul 06 11:21:19 ahah fantastic Jul 06 11:21:24 not per default Jul 06 11:21:28 you will have to teach me how to do that :) Jul 06 11:21:32 but we have patches inside owrt Jul 06 11:21:40 sure Jul 06 11:21:51 when you get that far that your uboot compiles and boots let me know Jul 06 11:22:06 I'll go to bed now it's a bit late here Jul 06 11:22:26 bye Jul 06 11:22:40 tomorrow I will test if the newly compiled OpenWRT kernel and RootFS work, or not Jul 06 11:22:43 bye thanks! Jul 06 11:23:06 what is it called in uboot the remote console that you can connect to uboot remotely? Jul 06 11:23:26 i think uboot has that kind of functionality... Jul 06 11:23:31 hmmm Jul 06 11:23:32 not sure Jul 06 11:23:51 netconsole? Jul 06 11:23:59 i think so yes Jul 06 11:24:13 kernel has a module called netconsole Jul 06 11:24:44 i think that can be inside uboot as well Jul 06 11:26:46 blogic: how come that lantiq guys are so interested in openwrt? Jul 06 11:28:18 no idea Jul 06 11:28:21 ask them Jul 06 11:33:46 luka12345|wiik: it looks like the danube needs to generate a 25Mhz clock for the switch to synchronize Jul 06 11:33:49 Port 5 Receive Clock Inputin MII Mode Jul 06 11:33:51 MII_RXDV and MII_RXD[3:0] are synchronous to the rising Jul 06 11:33:54 edge of this clock. It is free running 25 MHz clock in 100M Jul 06 11:33:56 mode and 2.5 MHz clock in 10M mode. Jul 06 11:34:01 this is what the datasheet says for pin 72 of the adm6996 Jul 06 11:34:29 and looking at the uboot source, the 25Mhz signal is generated, but in CLK_OUT2 Jul 06 11:34:39 i will try CLK_OUT0/1 later Jul 06 11:38:09 ok Jul 06 11:38:23 i really need a oscilloscope, the digi analyzer is not enough to hunt down clock signals ;) Jul 06 11:39:08 however pin 72 is low Jul 06 11:39:18 so there is no refclock Jul 06 11:39:32 which makes sense assuming the error behaviour we see Jul 06 11:39:40 ok ... more later Jul 06 12:00:22 luka12345|wiik: can you mail me the arteep.bin ? Jul 06 12:00:24 i lost it Jul 06 12:01:00 also i would suggest we drop the last secotr where we store it and use a static buffer instead Jul 06 12:01:34 and then we need to also make the nvram work ootb with owrt and then its only usb that is an open issue Jul 06 12:01:39 unless i forgot something Jul 06 12:02:42 you mean to read mac addres from siemens nvram ? Jul 06 12:03:30 yes Jul 06 12:03:36 there is a patch for it Jul 06 12:04:00 i would like to get it all done and merged this week Jul 06 12:04:22 here is that arteep.bin Jul 06 12:04:23 https://sx76x-openwrt-danube.googlecode.com/svn/trunk/wlan/arteep.bin Jul 06 12:05:03 thx ! Jul 06 12:06:29 but can u-boot read from siemens nvram and from its default nvram? because kernel addres is missing inside that nvram Jul 06 12:07:22 u-boot will use a random mac for now Jul 06 12:07:42 and use a static addr for the secotr behind nvram for the kernel Jul 06 12:09:58 so kernel will not use mac addres from string in nvram? Jul 06 12:10:17 it will be done like in other lantiq targets? Jul 06 12:10:26 yes Jul 06 12:10:33 ok Jul 06 12:10:34 it does nto really matter what mac the uboot uses Jul 06 12:10:40 i agree Jul 06 12:10:54 and it makes the uboot code cleaner and faster Jul 06 12:11:09 the arteep.bin should be next to the mac Jul 06 12:11:10 ok Jul 06 12:11:31 so that rootfs_data can be aligned at the end Jul 06 12:12:26 arteep.bin can go in a static buffer inside the mach-gigasx76x.c file imho and save a full flash sector Jul 06 12:13:18 but how will madwifi know where it is located in flash? Jul 06 12:13:38 or you are talking about ath5k? Jul 06 12:13:54 both Jul 06 12:13:57 i will patch them Jul 06 12:13:58 ;) Jul 06 12:14:00 http://pastebin.com/aRfuheCG Jul 06 12:14:55 i like the 3.0 part :) Jul 06 12:15:24 is this sx763? Jul 06 12:15:31 because: machine : EASY50712 Eval Board Jul 06 12:16:28 no Jul 06 12:16:31 its the eval kit Jul 06 12:17:30 the original siemens board still comes with 2.4 kernel Jul 06 12:17:44 cool stuff :D Jul 06 12:20:35 blogic: i dont understand this 'we need to also make the nvram work ootb with owrt' Jul 06 12:21:04 well, you mailed me patches and i need to merge them Jul 06 12:21:14 if mac is not going to be string in nvram Jul 06 12:21:23 than this is not necessary Jul 06 12:21:45 well Jul 06 12:21:51 where will linux get it from then ? Jul 06 12:21:57 linux needs to read it from nvram Jul 06 12:22:12 the boxes have a mac printed on the lable and we need to make it use that mac Jul 06 12:23:17 ok, so it's not like in the other lantiq targets Jul 06 12:23:26 wait a sec, ill give an example Jul 06 12:25:30 ok Jul 06 12:25:34 brb telephone rings Jul 06 12:26:08 in target/linux/lantiq/patches-2.6.39/200-mach-arv45xx.patch lines 278-282 Jul 06 12:26:11 ok Jul 06 12:26:21 you can see there mac is not a string Jul 06 12:26:40 and my patch converts a string first... Jul 06 12:27:07 i did not see the string stuff in lantiq Jul 06 12:42:45 its in the kernel Jul 06 12:45:45 i mean there is a kernel function for the conversion Jul 06 12:52:12 kaloz * r27490 /trunk/target/linux/generic/patches-3.0/430-mtd_myloader_partition_parser.patch: [generic/3.0]: fix myloader patch, thanks KanjiMonster Jul 06 12:59:15 kaloz * r27491 /trunk/target/linux/generic/ (5 files in 5 dirs): [generic]: fixup mtd refresh and co. Jul 06 13:01:45 kaloz * r27492 /trunk/target/linux/ (7 files in 4 dirs): refresh patches Jul 06 13:07:32 kaloz * r27493 /trunk/target/linux/ixp4xx/ (24 files in 2 dirs): [ixp4xx]: add 3.0 support Jul 06 13:45:12 blogic * r27494 /trunk/package/ltq-tapi/Makefile: Jul 06 13:45:12 Lantiq TAPI driver also build for other platforms Jul 06 13:45:12 thanks Matthias Buecher Jul 06 16:50:29 juhosg * r27495 /trunk/target/linux/ramips/image/Makefile: ramips: fix buffalo image generation Jul 06 17:31:14 blogic * r27496 /trunk/target/linux/lantiq/ (39 files in 5 dirs): [lantiq] get ready for 3.0 Jul 06 19:06:12 blogic * r27497 /trunk/package/ltq-tapi/Makefile: ltq-tapi is not xway specific Jul 06 19:06:23 blogic * r27498 /trunk/package/ (ltq-tapi/Makefile ltq-vmmc/Makefile pjsip/Makefile): ltq-tapi/vmmc were build on none lantiq targets due to bad builddepends of pjsip Jul 06 19:07:12 i hope this wont break again Jul 06 19:24:47 * Chocky wonders who to abuse about glibc today Jul 06 19:32:15 https://dev.openwrt.org/ticket/9483 ahem Jul 06 19:35:13 * Chocky pokes xmff for luck Jul 06 19:47:22 hi Jul 06 19:47:37 I am trying to port my board to openwrt Jul 06 19:47:50 I've compiled a kernel and I have the following issues: Jul 06 19:48:16 what is the default console OpenWRT wants to use? Jul 06 19:48:42 in my case I have to pass console=ttyAMA0,115200 from the bootloader otherwise I won't see any output message Jul 06 19:48:57 second, when booting, one of my partitions on the NAND is: Jul 06 19:49:08 0x000000800000-0x000008000000 : "rootfs" Jul 06 19:49:14 but immediately after I get a: Jul 06 19:49:25 mtd: partition "rootfs" set to be root filesystem Jul 06 19:49:26 split_squashfs: no squashfs found in "nand" Jul 06 19:51:59 the console which Linux uses can be a bit convoluted. But approximately, for loading an initramfs, it's set from bootloader, from image loaded from flash, it should be set in kernel command line. That's configured in the depths of openwrt Jul 06 19:52:24 as to rootfs, it's looking for squashfs there. Isn't that obvious/ Jul 06 19:52:28 ? Jul 06 19:52:30 if I specify "rootfstype=jffs2" it kind of works Jul 06 19:53:06 Chocky, well why is it looking for squashfs when I used a jffs2 image Jul 06 19:53:12 alesan: you need to add the magic for it work Jul 06 19:53:27 alesan: it tries to do a minifo overlay Jul 06 19:53:36 whihc makes no sense on nand Jul 06 19:53:42 these days, openwrt uses squash R/O root + jffs2 for overlay. Not sure about pure jffs2 these days Jul 06 19:54:05 blogic: why not? Jul 06 19:54:18 because on nand you should use ubi Jul 06 19:54:29 blogic, UBI is the next step Jul 06 19:54:34 now I want to keep things simple Jul 06 19:54:49 add rootfstype=jffs2 then Jul 06 19:55:02 blogic, ok Jul 06 19:55:13 now, what about the console? I do not get one :( Jul 06 19:55:31 I can only see the boot messages but then I do not have access to a "userspace" console Jul 06 19:55:42 if you understand what I mean there Jul 06 19:55:57 you want to look at /etc/inittab Jul 06 19:56:08 that defines the busybox/user space login console Jul 06 19:57:22 hm Jul 06 19:57:33 in fact it's hardcoded to ttyS0 I think Jul 06 19:57:42 exactly Jul 06 19:57:57 so you need a version for your system Jul 06 19:58:48 unless I am terribly mistaken, if it specified "con" instead of "ttyS0" it would just use Linux console Jul 06 19:59:02 could be Jul 06 19:59:17 I don't know busybox init in detail Jul 06 19:59:27 in any case the correct one is ttyAMA0 Jul 06 19:59:44 is there a place in OpenWRT configuration where I can set this? Jul 06 19:59:46 perhaps senor wants to give it a sensible name in the kernel Jul 06 19:59:57 senor? Jul 06 20:00:15 look at other systems which specify their own inittab. They have etc/inittab in their files Jul 06 20:00:25 Senor = sir in Spanish. Jul 06 20:00:50 actually, that's a wiggly over the N, but YKWIM Jul 06 20:01:59 my question was different, I am a bit surprised there is no way to specify an alternate console in openwrt Jul 06 20:02:09 but anyway I will try to find an example Jul 06 20:02:15 well, it's not really Jul 06 20:02:24 but is there any good reason for such a funky serial port name? Jul 06 20:03:13 I do not know, this is a driver for the serial ports in this SoC, they were simple ttySX before but when we merged it upstream the kernel guys wanted us to use an existing driver that has that naming Jul 06 20:03:21 openWrt is far from perfect. I can tell you that much. and what you are suggesting would involve busybox picking up boot commands. I'm not sure if that's desirable Jul 06 20:03:34 um Jul 06 20:03:40 sorry , um = hm Jul 06 20:03:56 you could patch it in openwrt too. Or just alternate inittab as you are doing Jul 06 20:03:57 no I am not asking for a boot option, but when OpenWRT is built is could use a variable with the console name Jul 06 20:04:10 well, inittab is really that variable Jul 06 20:04:19 I will see what is easier and done by other similar targets Jul 06 20:04:28 give me some minutes ;) Jul 06 20:05:50 moo Jul 06 20:05:56 what is the platform? Jul 06 20:05:58 on another note... under "image configuration" I would like to setup a default "DHCP" network setup Jul 06 20:06:18 it's ARM926EJ Jul 06 20:06:22 armv5 Jul 06 20:06:32 ST SPEAr SoC Jul 06 20:06:48 yes, perhaps. I think the thinking there was that's LAN side config, where DHCP might not always make sense Jul 06 20:06:50 not quite sure what you mean by "what is the platform" Jul 06 20:07:05 well I only have one ethernet here Jul 06 20:07:06 that's close enough Jul 06 20:07:15 yes, that's common. And it's really a WAN port Jul 06 20:07:28 submit a patch ;-) Jul 06 20:07:38 for what, the patch? Jul 06 20:07:51 in "LAN Protocol" I specified "dhcp" hopefully it will work Jul 06 20:07:59 yes, ok Jul 06 20:08:53 you're lucky. I'm trying to handle 3 platforms at once Jul 06 20:10:07 I am doing this with one hand while holding my 6mo baby with the other Jul 06 20:10:18 who is doing the most difficult one ;) ?? Jul 06 20:10:21 ooh, the one up game! Jul 06 20:10:42 I only have a single LED and push button as an interface Jul 06 20:10:51 I have to program in assembly. Jul 06 20:10:57 and I'm a blind paraplegic Jul 06 20:11:44 I am not sure where you are going with this discussion Jul 06 20:11:51 actually, the LED bit is kind true on this bufallo Jul 06 20:11:51 buffalo Jul 06 20:12:00 no where useful Jul 06 20:13:07 what is the product you are making? Jul 06 20:18:25 * Chocky pokes blogic Jul 06 20:18:39 jffs2 not ready yet; using ramdisk Jul 06 20:18:41 JFFS2 notice: (477) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xre. Jul 06 20:18:41 switching to jffs2 Jul 06 20:18:41 jffs2 not ready yet; using ramdisk Jul 06 20:18:42 what's going on? Jul 06 20:18:58 it's stuck using ramdisk Jul 06 20:24:31 so setting inittab to /dev/ttyAMA0 kind of works - I get a login shell - but I cannot see init messages Jul 06 20:25:04 in short, it seems part of the boot sequence is not available Jul 06 20:25:23 very strange, there is something that I do not quite get here Jul 06 20:26:16 florian * r27499 /packages/libs/elfutils/ (4 files in 2 dirs): [package] elfutils: package libelf and libdw, update to 0.152 Jul 06 20:28:10 but otherwise OpenWRT seems to be running ;) Jul 06 20:28:14 :o Jul 06 20:29:18 now what? Jul 06 20:29:29 <[florian]> alesan: check that your kernel also has console=ttyAMA0 on the command-line Jul 06 20:29:50 [florian], it has it, without it it wouldn't display anything during boot Jul 06 20:30:36 [florian], by the way thanks for the help the other day, I wouldn't be able to be at this point without you (and Kaloz and nbd and blogic yesterday night) Jul 06 20:31:04 <[florian]> glad to see that you have your device booting Jul 06 20:31:17 there is still quite some work to do anyway Jul 06 20:31:18 * Chocky pokes someone about jffs2 Jul 06 20:31:50 Chocky: "JFFS2 notice: (477) jffs2_build_xattr_subsystem: complete buildin..." is a sane message not an error Jul 06 20:31:57 sure Jul 06 20:32:08 but why does it get stuck and never start using jffs2 Jul 06 20:32:36 it was working before. either it's something about this hardware, or perhaps more likely, I broke something Jul 06 20:32:48 now... I would like to compile in some good software package in my rootfs Jul 06 20:33:17 there was a way to get in a comprehensive list of programs right? Jul 06 20:33:24 make menuconfig Jul 06 20:33:28 yes? Jul 06 20:33:40 in make menuconfig I do not think I see the comprehensive list... only the "base" one Jul 06 20:33:48 make sure you update your feeds Jul 06 20:34:01 I remember something like that Jul 06 20:34:15 blogic: older build is ok, so I broke something. wonder what Jul 06 20:35:10 I remember there was a make target to download and make a list of software available Jul 06 20:35:14 what was it? Jul 06 20:35:18 to the wiki! Jul 06 20:35:24 it's on the basic build page Jul 06 20:35:38 make package/symlinks perhaps? Jul 06 20:35:43 no Jul 06 20:35:47 to the wiki! Jul 06 20:36:30 http://wiki.openwrt.org/doc/howto/build Jul 06 20:40:09 * Chocky pokes! Jul 06 20:40:13 * Chocky pokes blogic Jul 06 20:44:14 * Chocky sobs Jul 06 20:49:12 ./scripts/feeds update -a Jul 06 20:49:18 ./scripts/feeds install -a Jul 06 20:49:22 make menuconfig Jul 06 21:02:40 cshore: ping Jul 06 21:04:28 blogic: pong? Jul 06 21:05:10 sorry Jul 06 21:05:17 [florian]: is responsible not you :D Jul 06 21:05:27 moo Jul 06 21:05:38 yes, what is wrong with my jffs2? Jul 06 21:10:00 Chocky: when you foiund out, let us know :D Jul 06 21:10:08 wah Jul 06 21:10:13 * Chocky sobs Jul 06 21:13:46 Chocky: did you update feed? Jul 06 21:13:48 *feeds Jul 06 21:13:53 ./scripts/feeds update -a Jul 06 21:13:53 ./scripts/feeds install -a Jul 06 21:13:53 make menuconfig Jul 06 21:14:07 perhaps not recently Jul 06 21:14:17 do it Jul 06 21:14:19 then svn up Jul 06 21:14:19 wah Jul 06 21:14:25 then make menuconfig Jul 06 21:14:26 save Jul 06 21:14:34 make dirclean Jul 06 21:14:35 slow down there, caption obvious Jul 06 21:14:35 make Jul 06 21:14:45 it's IRC Jul 06 21:14:46 firstly, don't patronize me. Jul 06 21:14:47 it won't vanish Jul 06 21:15:03 secondly, the latest SVN pulls a new GCC, which doesn't build Jul 06 21:15:17 although it might if I did a complete clean. But I think it might not even produce a working system Jul 06 21:15:26 what target are you compiling for? Jul 06 21:15:33 rt3883 Jul 06 21:15:37 and you can just select the version of GCC to use in menuconfig Jul 06 21:15:42 no, they removed it Jul 06 21:15:47 give me a little credit, please Jul 06 21:15:54 I just reverted that bit Jul 06 21:16:46 Advanced Configuration options (for developers) --> Toolchain Options Jul 06 21:16:55 am I talking to myself? Jul 06 21:17:29 I specifically require the 4.3.3-cs version. That was *just* removed from SVN. Jul 06 21:18:05 ok, I'm on Target System Jul 06 21:18:07 what do I select Jul 06 21:18:19 why are you patronizing me? Jul 06 21:18:31 alrighty, screw you then Jul 06 21:18:37 maybe you should slow down, and listen a little to what I'm doing instead of guessing Jul 06 21:18:44 screw you too. PS. I love you Jul 06 21:18:57 just give me the target to select so I can compile for the same board Jul 06 21:18:59 I'm happy to update my package feeds, but I'd prefer to know why Jul 06 21:19:26 you can't. It's not in OpenWrt yet Jul 06 21:19:41 * Olipro facepalms Jul 06 21:19:53 * Chocky facepalms Olipro too Jul 06 21:20:18 can we step back a second, from the top? Jul 06 21:21:07 should I be able to git clone openwrt and packages and then do: cd openwrt ; ln -s ../../packages/foo/bar to include bar ? Jul 06 21:21:13 so, where was I. Jul 06 21:21:40 ok, so for my platform, the jffs2 stuff used to work. Either I broke something, or something changed in SVN recently. Perhaps updating packages will do it Jul 06 21:21:53 but right now, it never starts using jffs2/overlay. just stuck with a ramfs setup. Jul 06 21:21:55 LetoTo: ./scripts/feeds update Jul 06 21:22:01 LetoTo: ./scripts/feeds install bar Jul 06 21:22:30 ok so far? Jul 06 21:24:11 * Chocky gives olipro a big wet kiss Jul 06 21:24:19 Chocky: paste a bootlog Jul 06 21:24:36 un momento Jul 06 21:24:51 if your target isn't in OpenWRT Jul 06 21:25:02 then what environment setup do you have exactly? Jul 06 21:25:56 the patches haven't been submitted to upstream OpenWrt yet. It is OpenWrt. That's beyond my immediate control, but juhosg did the port. Jul 06 21:26:09 ah Jul 06 21:26:28 it's ramips with a rt3883 processor Jul 06 21:26:38 blogic: thanks. Jul 06 21:28:02 let me try this build first. 5 mins Jul 06 21:28:30 i am of now Jul 06 21:28:34 nitey Jul 06 21:28:34 of what? ;-) Jul 06 21:32:42 http://pastebin.com/8C7Gmqsq notice how br-lan etc isn't created. it's stuck somewhere in the boot sequence Jul 06 21:37:31 hm Jul 06 21:47:06 * Chocky wiggles everyone Jul 06 21:49:12 * Chocky reverts stuff Jul 06 21:51:01 hm Jul 06 21:51:02 no use Jul 06 22:11:08 so is there a way to tell openwrt to expect a JFFS2 rootfs instead of the squashfs split? Jul 06 22:11:28 without having to pass a command line to the kernel... Jul 06 22:14:45 jow * r27500 /trunk/package/firewall/ (4 files in 2 dirs): Jul 06 22:14:45 [package] firewall: Jul 06 22:14:45 - solve scoping issues when multiple values are used, thanks Daniel Dickinson Jul 06 22:14:45 - ignore src_port/dest_port for proto icmp rules, ignore icmp_type for non-icmp rules Jul 06 22:14:45 - properly handle icmp when proto is given in numerical form (1, 58) Jul 06 22:14:45 - support negated icmp types Jul 06 22:25:45 ok Jul 06 22:26:10 the answer is that mini_fo got turned off in my kernel. I made a custom change elsewhere, perhaps it got lost somehow. Jul 06 22:26:42 so, is there a bug there? dunno. Perhaps openwrt boot should have complained about something. Jul 06 22:51:34 moo Jul 07 02:56:01 cshore * r27501 /trunk/package/base-files/files/ (etc/preinit lib/preinit/02_default_set_state): Jul 07 02:56:02 [package] base-files: preinit: Fixed sourcing of diag.sh in /etc/preinit. This Jul 07 02:56:02 caused errors due to frequent use of /proc/cpuinfo to determine board name to Jul 07 02:56:02 pick led layout. Now diag.sh (which only defines set_state and any helper Jul 07 02:56:02 functions) is sourced by a proper preinit function during preinit_main, which is Jul 07 02:56:02 after /proc has been brought up, unlike in /etc/preinit **** ENDING LOGGING AT Thu Jul 07 02:59:56 2011