**** BEGIN LOGGING AT Thu Jun 04 03:06:25 2020 Jun 04 03:08:34 build #382 of apm821xx/nand is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/382 blamelist: Rosen Penev , Tomasz Maciej Nowak , Tobias Schramm , Florian Eckert , Johann Neuhauser neuhauser.de>, ?lvaro Fern?ndez Rojas , DENG Qingfang , Paul Spooren , Sungbo Eo , Michael Heimpold , Adrian Schmutzler , Alexey Dobrovolsky , Sven Roederer , Thomas Albers Jun 04 03:08:34 , Sergey Ryazanov , Petr ?tetiar , Eneas U de Queiroz , Tim Harvey Jun 04 03:09:46 build #400 of ramips/rt3883 is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/400 blamelist: Rosen Penev , Tomasz Maciej Nowak , Tobias Schramm , Florian Eckert , Johann Neuhauser neuhauser.de>, ?lvaro Fern?ndez Rojas , DENG Qingfang , Paul Spooren , Sungbo Eo , Michael Heimpold , Adrian Schmutzler , Alexey Dobrovolsky , Sven Roederer , Thomas Albers Jun 04 03:09:46 , Sergey Ryazanov , Petr ?tetiar , Eneas U de Queiroz , Tim Harvey Jun 04 03:59:28 build #395 of mvebu/cortexa72 is complete: Failure [failed kmodconfig] Build details are at http://buildbot.openwrt.org/master/images/builders/mvebu%2Fcortexa72/builds/395 blamelist: Rosen Penev , Tomasz Maciej Nowak , Tobias Schramm , Florian Eckert , Johann Neuhauser neuhauser.de>, Tim Harvey , ?lvaro Fern?ndez Rojas , Paul Spooren , Sungbo Eo , Michael Heimpold , Adrian Schmutzler , Alexey Dobrovolsky , Sven Roederer , Thomas Albers Jun 04 03:59:28 , Sergey Ryazanov , Petr ?tetiar , DENG Qingfang , Eneas U de Queiroz Jun 04 04:00:45 build #389 of mediatek/mt7622 is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/389 blamelist: Rosen Penev , Tomasz Maciej Nowak , Tobias Schramm , Florian Eckert , Johann Neuhauser @it-neuhauser.de>, Tim Harvey , ?lvaro Fern?ndez Rojas , Paul Spooren , Sungbo Eo , Michael Heimpold , Adrian Schmutzler , Alexey Dobrovolsky , Sven Roederer , Thomas Albers Jun 04 04:00:45 , Sergey Ryazanov , Petr ?tetiar , DENG Qingfang , Eneas U de Queiroz Jun 04 04:02:00 build #390 of cns3xxx/generic is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/cns3xxx%2Fgeneric/builds/390 blamelist: Rosen Penev , Tomasz Maciej Nowak , Tobias Schramm , Florian Eckert , Johann Neuhauser @it-neuhauser.de>, Tim Harvey , ?lvaro Fern?ndez Rojas , Paul Spooren , Sungbo Eo , Michael Heimpold , Adrian Schmutzler , Alexey Dobrovolsky , Sven Roederer , Thomas Albers Jun 04 04:02:00 , Sergey Ryazanov , Petr ?tetiar , DENG Qingfang , Eneas U de Queiroz Jun 04 06:41:24 ynezz: the nomosphere builder appears to be out of disk space Jun 04 06:47:06 f00b4r0: pong Jun 04 07:09:16 hmmmz. I'm trying to figure out how I can make patches for this merge commit in net-next: 626ceee334f94852a1864b54d376290298cf9e4c Jun 04 07:18:02 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=626ceee334f94852a1864b54d376290298cf9e4c Jun 04 07:18:49 I have a T1042 SoC using that VSC9953 switch and this might help me getting the thing to work under OpenWrt Jun 04 07:19:32 stintel: in general there is a lot of movement inside the DSA subsytem and the API at least a year ago was not very stable Jun 04 07:19:50 backporting drivers tended to require either api backport int he driver or the subsystem Jun 04 07:20:30 it would just be local for now. maybe you are suggesting I use an external kernel tree instead for my playing around? Jun 04 07:23:55 try it out Jun 04 07:24:04 it might work on our v5.4 Jun 04 07:24:17 there were only 3 new versions so the delta might not be too big Jun 04 07:24:39 I see Jun 04 07:24:54 interesting...libupnp is apparently trash Jun 04 07:25:01 I might try with external kernel tree (next-next) first Jun 04 07:25:13 mangix: big suprise Jun 04 07:25:23 this device is a WatchGuard Firebox M200. T1042 with 8x1Gbe Jun 04 07:25:24 API takes an interface and only listens on IPv4 Jun 04 07:25:58 I need to test this on malta again. Jun 04 07:26:10 they're becoming available on the 2nd hand market and to me looked like an interesting architecture Jun 04 07:26:32 I have a subtarget of mpc85xx that boots on it Jun 04 07:26:39 You nutty ppl! Jun 04 07:26:48 you got DSA on mvebu! Jun 04 07:26:48 but the network part... I am scratching my head =) Jun 04 07:27:01 It's been so long!!!! HAPPINESS! Jun 04 07:28:00 also had to patch out some assembly code from musl to stop it from crashing userspace, as it has no altivec (no lvx stvx and these are hardcoded) Jun 04 07:28:08 thagabe: why? DSA is slower. lol Jun 04 07:28:29 granted, the mvebu devices are quite capable Jun 04 07:28:51 isn't dsa kernel based"? Jun 04 07:28:57 shouldnt it be faster Jun 04 07:29:37 lol no. the only difference is that it's upstream. leas maintenance burden. Jun 04 07:30:33 huh i was fairly sure DSA was in kernel space Jun 04 07:30:59 swconfig is as well. Jun 04 07:31:03 DSA as it is right now is a complete trainwreck Jun 04 07:31:08 in the first place I am interested to benchmark if this thing is faster than APU2 Jun 04 07:31:28 sure it might be nice once you got it set up Jun 04 07:31:36 but integration in openwrt is non existent Jun 04 07:31:51 configuration is a complicated, highly device dependent inconsistent mess Jun 04 07:33:27 I do remember that being mentioned Jun 04 07:37:09 ynezz: those two cmake patches are probably worthless for now. Jun 04 07:38:18 I experimented by placing a default CMAKE_BINARY_SUBDIR and see what fails. Jun 04 07:39:07 blogic: you really are on fire with ath11k :-) Jun 04 07:58:20 xback: ;) Jun 04 07:59:40 xback: getting the hostapd series to go along ready just now Jun 04 08:00:02 still need to figure out how to best handle TIM/AID mapping Jun 04 08:00:12 you only have 1 TIM IE when doing multiple bssid Jun 04 08:00:21 so all APs share a common aid space Jun 04 08:00:40 however aid0/1 needs to be unique to the VAP as it is used for b/mcast Jun 04 08:07:59 rmilecki: is there a specific reason why the "firmware" scheme (with mtd splitter) is not implemented on nand devices? It seems it would work on routerboards, I'm wondering if there's something I should know before I embark on this implementation? Jun 04 08:53:17 f00b4r0: current sysupgrade procedure doesn't allow a dynamic mtd partition being used as ubi. Jun 04 08:53:40 gch981213: yes, I know this would need to be fixed, hence my asking first if there's some good reason not to do it that way :) Jun 04 08:57:50 f00b4r0: ubi is used for wear-levelling. if you write the underlying mtd devices directly, you are writing the same blocks every time. Jun 04 08:58:36 gch981213: aren't we doing that for kernel anyway? Jun 04 08:59:00 I think hardcoding kernel partition size is a serious drawback that's going to bite us eventually as the kernel keeps growing Jun 04 09:17:57 ubi volumes need to simply be created as dynamic Jun 04 09:18:14 that way they will "dynamically" grow upon a sysupgrade if the size is not enough Jun 04 09:18:27 our sysupgrade code already handles that afaik Jun 04 09:19:04 blogic: I'm not sure how that would fix the kernel partition sizing problem? Jun 04 09:19:21 (which is the problem I'd like to address) Jun 04 09:19:59 is the kernel inside the ubi ? Jun 04 09:20:02 no Jun 04 09:20:04 that's the point. Jun 04 09:20:10 ah ok, that is not good either way Jun 04 09:20:22 does the bootloader support ubi ? Jun 04 09:20:40 kernel should be in a ubi partition Jun 04 09:20:50 no Jun 04 09:20:54 the bootloader does not support ubi Jun 04 09:21:00 hmpf Jun 04 09:21:07 I want to avoid this: https://github.com/openwrt/openwrt/blob/8f40ee1630354c855768dcf0036b38b3004ec25f/target/linux/ath79/dts/ar7100_mikrotik_routerboard-4xx.dtsi#L154 Jun 04 09:21:15 aware of the issue Jun 04 09:21:24 which is bound to hurt. Jun 04 09:21:58 i naively thought a top level firmware partition (like we do on NOR devices) would be a better way to handle that Jun 04 09:22:00 :) Jun 04 09:23:44 blogic: should I forget the idea? Jun 04 09:24:46 there is nothing i can think of Jun 04 09:26:23 f00b4r0: how is the bootloader loading kernel, does it just skip the bad nand blocks? Does it use OOB data to check what block is bad and what is not? Jun 04 09:26:30 ok. But would a top level firmware partition on NAND devices be NACKd on principle? And if not, any idea of how to split the underlying rootfs? Does it even make sense to dynamically allocate ubi? Jun 04 09:26:58 PaulFertser: excellent question. The bootloader is a black box. Jun 04 09:27:14 all we know is, it wants an ELF binary packed in yaffs. Jun 04 09:28:00 f00b4r0: I think this is to be determined. Probably it has a hardcoded limit for kernel size too and so dynamic partitions do not make much sense anyway since NAND is big enough and it's not too much of a waste to just allocate the maximum for the kernel? Jun 04 09:28:29 Unless you know how bad blocks are to be treated then I guess you can't implement a reliable sysupgrade procedure. Jun 04 09:28:36 there's no evidence of such a limit. At least there isn't on NOR devices and they use the same bootloader. Jun 04 09:28:59 OK, but the bad blocks question is still essential I guess? Jun 04 09:29:11 I suppose. I know next to nothing about NAND :) Jun 04 09:29:26 f00b4r0: i'm not sure what do you mean, my NAND has "firmware" and it splits it into "linux" (kernel) and "ubi" Jun 04 09:29:30 [ 5.517501] Creating 3 MTD partitions on "brcmnand.0": Jun 04 09:29:31 [ 5.522654] 0x000000000000-0x000020000000 : "firmware" Jun 04 09:29:41 ah! Jun 04 09:29:49 rmilecki: which device is that? Jun 04 09:29:56 bcm53xx Jun 04 09:29:59 * f00b4r0 needs to take a look at dts and sysupgrade routines Jun 04 09:30:00 f00b4r0: we already have a mtdsplit driver for kernel/ubi I believe? Jun 04 09:30:15 well I missed it then Jun 04 09:30:33 the only problem is that current sysupgrade code can't handle a dynamic ubi partition. Jun 04 09:30:44 f00b4r0: NAND is a whole different beast. Because some blocks there are bad right from the factory, and some blocks get bad over the years. Sometimes OOB data is used for ECC only, and there's a dedicated bad block table somewhere, sometimes OOB data has flags telling the software if the block is bad (from the factory or during the lifetime). And the bootloader needs to be treated everything in Jun 04 09:30:50 the same way as all the other software on the same board does. Jun 04 09:30:57 gch981213: well I suppose rmilecki's device is sysupgradable? :) Jun 04 09:31:04 rmilecki: that's all cool when the bootloader understands ubi. Jun 04 09:31:49 sorry, I see you mean splitting exactly the way f00b4r0 wants, so ubi is irrelevant Jun 04 09:31:52 my bootloader doesn't undestand UBI, that's why it's separated partition followed by "ubi" Jun 04 09:32:06 (kernel is separated partition that is) Jun 04 09:32:12 Yes, I misread Jun 04 09:32:28 yuck. bcm53xx dtses live as patches? Jun 04 09:33:08 f00b4r0: bcm53xx has alsmost all dts upstreamed Jun 04 09:33:14 sysupgrade part: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/bcm53xx/base-files/lib/upgrade/platform.sh;h=40b2ef67be5b9c1f2a0cfbdf1717f0747d148e75;hb=HEAD#l335 Jun 04 09:33:48 above is for Seama format Jun 04 09:33:54 for more generix TRX format: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/bcm53xx/base-files/lib/upgrade/platform.sh;h=40b2ef67be5b9c1f2a0cfbdf1717f0747d148e75;hb=HEAD#l290 Jun 04 09:34:33 also check how i create image with "linux" (kernel) partition: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/bcm53xx/image/Makefile;h=b3ec1e99a28fdbfed0d27f6a343228d2d1efd095;hb=HEAD#l68 Jun 04 09:34:38 How are bad blocks in kernel partition treated by the bootloader on those broadcom devices? Jun 04 09:34:58 PaulFertser: when flashing, bootloader skips bad blocks Jun 04 09:35:07 PaulFertser: same for reading obviously Jun 04 09:35:15 rmilecki: thanks. Looks non entirely trivial (since I don't know these image formats) but at least it suggests it can be done Jun 04 09:35:24 if blocks turns bad during lifetime it may go quite wrong Jun 04 09:35:50 I guess a verification step for kernel is needed then? Jun 04 09:36:31 CFE (bootloader) uses checksum over specified data length, we set length to cover kernel partition data Jun 04 09:36:34 So that sysupgrade reflashes it again if some of the blocks went bad during the process. Or is it automated already? Jun 04 09:36:41 so it should detect checksum mismatch Jun 04 09:36:55 what happens next depends on vendor specific bootloader configuration Jun 04 09:37:24 PaulFertser: sysupgrade just does "mtd write" for kernel partition which AFAIR also just skips bad blocks Jun 04 09:37:39 PaulFertser: and sysupgrade also updates UBI volume ofc Jun 04 09:38:23 rmilecki: I mean I'd expect a block to go bad right after erasing so mtd write is supposed to handle that somehow. Jun 04 09:38:23 in my case routerboot expects a yaffs-encapsulated kernel. AIUI yaffs provides checksuming Jun 04 09:38:54 PaulFertser: i don't remember when kernel marks block as bad Jun 04 09:39:47 f00b4r0: so you should probably have firmware with yaffs partition followed by UBI partition Jun 04 09:40:07 then use some mtdsplit driver than can detect it and create both partitions Jun 04 09:40:26 call the later partition "ubi" and let OpenWrt's UBI auto-mounting feature handle the rest Jun 04 09:40:57 *nod* Jun 04 09:41:04 then there's the sysupgrade bits to adjust Jun 04 09:41:41 right, make platform.sh overwrite yaffs2 partition and then update UBI volume Jun 04 09:41:51 well Jun 04 09:41:58 but that wouldn't solve the size problem, would it? Jun 04 09:42:02 It seems that despite being dynamically created, bcm53xx still uses a fixed 4m kernel partition anyway? Jun 04 09:42:08 if you cant move the head of the ubi volume, that is Jun 04 09:42:21 f00b4r0: right, see gch981213's msg above Jun 04 09:42:36 so the dynamic partitioning is purely cosmetic? Everything is still hard coded? :P Jun 04 09:42:55 bcm53xx kernel is 2 MiB or so, but to make sure, every updated kernel can still fit there, we always reserve 4 MiB for it Jun 04 09:42:56 * f00b4r0 - emotional rollercoaster ;P Jun 04 09:43:15 rmilecki: ok so there's absolutely no point in doing this dynamically? :) Jun 04 09:43:39 that would be very tricky Jun 04 09:43:44 to move UBI's head when needed Jun 04 09:43:56 no but I mean, what's even the point of having an mtd splitter with the scheme you describe? Jun 04 09:44:12 kernel partition is always 4M. That can be set in DTS, period. Jun 04 09:44:52 that would be slightly less generic, but yes, you could do that Jun 04 09:44:56 lol Jun 04 09:44:58 ok Jun 04 09:45:26 i don't believe project-specific hardcoded partitions layout should be upstreamed in DTS in Linux's kernel Jun 04 09:45:44 well I see, no need to bang my head against that wall I guess. We'll just set the kernel partition to be some large value (say 8-16MB) and be done with it Jun 04 09:46:35 it won't be the worst thing you can do, so sure Jun 04 09:46:49 i love upstreaming my work, so I always look for generic solutions Jun 04 09:46:51 rmilecki: well the alternative is to use a yaffs filesystem for the whole thing, but AIUI it's not exactly an option for openwrt? Jun 04 09:47:10 vendor devices use yaffs Jun 04 09:47:16 i wouldn't use yaffs on NAND more than it's needed Jun 04 09:47:21 UBI is definitely better idea Jun 04 09:47:23 heh Jun 04 09:47:33 but the bootloader doesn't support ubi. Conundrum Jun 04 09:47:41 ok thanks for the input, now I know where I stand :) Jun 04 09:47:47 yaffs + UBI then Jun 04 09:48:12 rmilecki: *nod*. But that's still not really good from a wear-levelling perspective Jun 04 09:48:17 yaffs with kernel, so bootloader can boot it, then UBI as it's up to kernel to boot user-space from it Jun 04 09:48:37 sure, ideally bootloader should support UBI Jun 04 09:48:51 alternatively we could pack kernel+ubi within yaffs :> Jun 04 09:48:52 * f00b4r0 runs Jun 04 09:49:02 just reading kernel from yaffs shouldn't easily wear your flash though Jun 04 09:49:18 rmilecki: no. I'm more concerned about repeated upgrades tho. Jun 04 09:49:41 quick unrelated question just in case you'd know the answer: Jun 04 09:50:15 I'm trying to find in the build process which step produces /build_dir/target-mips_24kc_musl/linux-ath79_*/vmlinux.elf Jun 04 09:50:23 which is the kernel I'd like to pack in my initramfs Jun 04 09:50:40 and looking at the output of V=s I can't find how it gets there Jun 04 09:51:15 grep -R elf include/* Jun 04 09:51:24 found this: include/kernel-defaults.mk: $(KERNEL_CROSS)objcopy $(OBJCOPY_STRIP) -S $(LINUX_DIR)/vmlinux $(KERNEL_BUILD_DIR)/vmlinux$(1).elf; \ Jun 04 09:51:28 check it Jun 04 09:51:47 doh. I was again looking at the wrong place Jun 04 09:51:48 thanks! Jun 04 09:51:51 yw Jun 04 09:52:33 I wonder if for the NAND devices it makes sense to consider using secondary bootloader which would be small, support UBI, telnet and TFTP recovery and would rarely be written. Jun 04 09:52:59 and secure. of course :3 Jun 04 09:53:16 Yes. Same u-boot but with sane defaults. Jun 04 09:53:31 it's not u-boot Jun 04 09:53:51 and good luck writing a bug-free bootloader like that :) Jun 04 09:54:40 But u-boot can be used as a second-stage bootloader instead of the Linux. And it can then load DTS properly and use it and pass it to the kernel etc. Jun 04 09:54:59 and then we can have a single image for all devices :) Jun 04 09:56:54 Doesn't sound really infeasable unless I'm missing something. Jun 04 09:57:26 it doesn't. It was on my todo list, until I was told single images are bad Jun 04 09:58:48 side question, and speaking of hard limits Jun 04 09:59:00 there is a hard limit in the size of binary routerboot can tftp boot Jun 04 09:59:19 and we're hitting it nowadays with kernel+initramfs on routerboards. Jun 04 09:59:31 initramfs is necessary for first install Jun 04 09:59:56 my question is: would it be acceptable to build a tiny install initramfs instead of the complete image (which is unbootable as of now)? Jun 04 10:00:35 xback: ^ by the way. More data points on that when you read this Jun 04 10:01:29 by "tiny install initramfs" I mean the kernel _and_ the fs would have to be smaller (so more bare) Jun 04 10:01:51 which means the kernel and the fs would be different from what is on the sysupgrade file Jun 04 10:02:01 and I don't know if that's ok. Jun 04 10:09:00 What would be the alternative approach? Something maintained out of tree that would be doing essentially the same? The problem is that current system doesn't support generation of several different rootfs files for a single target I guess. Jun 04 10:10:33 maybe it's time to work on that? Jun 04 10:14:56 btw, are LuCI-less initramfs images (snapshots) too big too? Jun 04 10:19:12 Because there were discussions about making buildbots produce both variants for release versions too. Jun 04 10:21:04 f00b4r0: I think you can't use that vmlinux.elf because dtb needs to be appended after kernel binary code, not after that elf file. Jun 04 10:24:07 having a more sane second stage loder is no possibility? Jun 04 10:24:22 something posing as kernel but chainloading something that understands ubi etc. Jun 04 10:24:50 does anybody know how to configure NVRAM parameters on USB brcmfmac devices? Jun 04 10:25:13 My end goal (on an OpenWRT custom board) is to enable 3 wire BT coexistence to avoid interference between a BCM43143 and a third party radio (a Silabs EFR32) Jun 04 10:25:28 Unfortunately the firmware binaries that come with the brcmfmac driver all have coexistence disabled =( Jun 04 10:25:39 it seems that for SDIO devices, the driver loads a firmware AND a set of parameters from an nvram file Jun 04 10:25:54 but for USB devices, only the firmware is loaded and the firmware binary is supposed to already have the nvram parameters merged in the USB firmware image Jun 04 10:26:19 Cypress (which now owns Broadcom devices) confirmed this, but they don't provide the tools for merging (unless you buy millions of devices!) Jun 04 10:26:36 so I was wondering whether there is some FOSS way of doing this? Jun 04 10:31:40 maybe ask someone at candelatech how they can now "distribute" (?) different firmware/drivers (-ct) that they modified for Qualcomm / ath10k wireless devices Jun 04 10:34:00 matteosilex: comment in usb.c suggests that NVRAM can be uploaded with firmware: Jun 04 10:34:01 const u8 *image; /* buffer for combine fw and nvram */ Jun 04 10:34:07 i'm not saying it's true Jun 04 10:34:09 also isnt Cypress now Infineon -since end of may/june this year Jun 04 10:34:10 but maybe? Jun 04 10:34:54 https://www.infineon.com/cms/en/about-infineon/press/press-releases/2020/INFXX202004-049.html complete cypress aquisistion Jun 04 10:35:48 jow: all DSA boards in OpenWrt supports tags, so all we need is a GUI of VLAN filtering on bridge interfaces. Jun 04 10:36:27 dengqf6: before we can have a gui we need an ui... and a config :) Jun 04 10:36:45 Looking at brcmfmac43143.bin suggests that nvram is appended at the end, and the whole file is a valid TRX image. Jun 04 10:36:54 jow: second stage loader is currently lzma-loader Jun 04 10:36:55 plntyk: I'm not sure I follow what you mean with "asking candelatech how they do it for ath10k devices"... They're different devices Jun 04 10:37:24 f00b4r0: just theoretically thinking, what about some uboot flavor that also does lzma/xz ? Jun 04 10:37:24 and it seems that it's quite buggy. Also on memory constrained boards, multiple chainloading require more memory space and this in turn can run into issues Jun 04 10:37:36 instead of lzma-loader Jun 04 10:37:46 That's what I was suggesting :) Jun 04 10:37:47 rmilecki: if you look below in the code, that combining is never done for USB devices Jun 04 10:37:51 gch981213: *sigh*. That elf file is what the bootloader wants to boot Jun 04 10:37:59 matteosilex: you can try repacking the TRX though Jun 04 10:38:05 jow: In previous swconfig, does uci call swconfig directly or call kernel API? Jun 04 10:38:05 matteosilex: right, because .bin already have NVRAM combined Jun 04 10:38:10 matteosilex: as noted by PaulFertser Jun 04 10:38:25 so if NVRAM is in plain text in .bin you can just repace it Jun 04 10:38:37 dengqf6: swconfig is triggered by /etc/init.d/network and the swconfig util consumes /etc/config/network uci natively Jun 04 10:39:01 matteosilex, the ath10k-ct is the same hardware - just running different firmware/softwarestack , https://www.candelatech.com/ath10k.php Jun 04 10:39:06 dengqf6: I guess for vlan filtering we would want that to be part of netifd Jun 04 10:39:09 jow: that's what I have/had in mind too, but I'm concerned about mem issues. Bear in mind for instance that we /don't know/ where routerboot tftp routines copies data in RAM Jun 04 10:39:09 mentions NDA Jun 04 10:39:34 so we could be crapping over ourselves any time (and I think that's exactly what happens on recent images which are "too big") Jun 04 10:40:07 jow: yup, and call kernel netlink instead of `bridge vlan` so we don't have to ship `ip-bridge` Jun 04 10:40:35 jow: the safe alternative would be a multi stage tftp boot: you'd tftp a secondary loader, start it Jun 04 10:40:46 and that secondary loader would then tftp the final image Jun 04 10:40:59 having full control over the secondary loader we can then lift all non-physical limits Jun 04 10:41:26 but of course that's not exactly a user-friendly scenario, especially in the case where you don't have serial over the hardware. Jun 04 10:42:17 rmilecki: the NVRAM is not plaintext in the bin, it's converted to a binary format somehow (Cypress said so) but I don't know how Jun 04 10:42:27 note that AIUI this is more or less what routeros does in its netinstall procedure: if I read the doc correctly, the bootloader tftp's a piece of code that then request data from a network fileserver and writes it to flash. Jun 04 10:42:30 matteosilex: it is plain text Jun 04 10:42:41 matteosilex: take a look and see for yourself Jun 04 10:43:29 Zero-terminated ASCII strings Jun 04 10:43:52 gch981213: https://lore.kernel.org/patchwork/patch/1048949/ <- this seems to suggest that it is possible to append dtb to elf kernel? Jun 04 10:44:39 Probably there's no checksum even (only in the TRX for the whole combined file) Jun 04 10:45:23 f00b4r0: the kernel can be built to load dtb after either elf or bin, but not both. Jun 04 10:45:37 gch981213: ok then we want the former Jun 04 10:46:40 f00b4r0: you'll need a whole new subtarget just for that, or you could try to package elf from bin like lzma-loader. Jun 04 10:46:51 we already have a subtarget, luckily :) Jun 04 10:48:01 i want to do away with lzma-loader. It's not working for us and I suspect it's not even doing what we think it does Jun 04 10:49:18 PaulFertser: ouch, I trusted Cypress on that... mistake. Jun 04 10:49:24 (specifically, LZMA_TEXT_START seems to not affect the final link, if I get this right) Jun 04 10:53:13 matteosilex: first thing would be to try patching the mac address I'd say. You'll see if it worked right away. Jun 04 11:04:51 matteosilex: the first trx "partition" looks kinda odd though. But it is TRX and you need to recalculate crc32 after changing nvram but that's probably about it. Jun 04 11:05:59 matteosilex: just all the data from offset 12 Jun 04 11:07:03 oh, that's very useful information Jun 04 11:08:19 jow: there is not enough disk space, so it's 25GB tmpfs for each builder Jun 04 11:08:43 jow: probably some cron job, need to take a look, have it on TODO list :] Jun 04 11:10:27 /home/petr/openwrt-buildslave/nomosphere-dock-02 tmpfs size=25G Jun 04 11:10:47 25G 16G 10G 61% /home/petr/openwrt-buildslave/nomosphere-dock-02 Jun 04 11:13:56 matteosilex: take a look at otrx.c sources, they're quite understandable (and you'll see a familiar name there). Since it verifies the file as valid TRX it means it calculates CRC in the same way. So I'd just patch the file and then would let it recalculate the CRC. Jun 04 11:14:38 PaulFertser: ahah, did you write the tool? Jun 04 11:14:39 matteosilex: it prints the sum upon mismatch Jun 04 11:14:44 matteosilex: no, rmilecki did Jun 04 11:14:54 matteosilex: that's probably what cypress meant by "it's binary" Jun 04 11:15:21 matteosilex: and then you just patch the checksum manually in the trx header (offset 8) Jun 04 11:15:22 annoying that a Cypress FAE would be that misleading... Jun 04 11:15:45 matteosilex: give it at try now since you have the hardware. Just change the MAC, fix CRC and see if the card boots. Jun 04 11:15:52 I'm on it! =) Jun 04 11:16:28 matteosilex: possibly just not knowledgeable enough. they edit a text file then a magic tool "makes a binary" for them Jun 04 11:16:51 matteosilex: otrx can be even use to repackage partitions Jun 04 11:16:53 (I'll have to build otrx, though, because I build OpenWRT for Allwinner A13, and otrx depends on BRCM being the target, so I don't get it in my build =) Jun 04 11:17:05 matteosilex: i didn't check if NVRAM is part of partition 1 or separated trx partition Jun 04 11:17:13 * f00b4r0 learns MIPS ISA - looks nice Jun 04 11:17:20 rmilecki: yes, but in this case the TRX looks odd, the 0th partition has "bc 09 06 00" offset... Jun 04 11:17:25 matteosilex: you can do "otrx extract file.bin -1 foo.bin", modify it, then, build trx again Jun 04 11:17:29 did you reverse the TRX format or is it documented somewhere? Jun 04 11:17:48 For the reference, I'm talking about https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/brcm/brcmfmac43143.bin Jun 04 11:18:14 So the CRC is valid but list of partitions is odd. Jun 04 11:18:46 So to play safe I'd tweak it manually as little as possible Jun 04 11:20:00 PaulFertser: it has weird partitions order indeed Jun 04 11:20:10 but offsets look ok Jun 04 11:20:20 The logic in otrx doesn't like it though Jun 04 11:20:33 Apparently you assumed they should be in order Jun 04 11:20:48 PaulFertser: offsets look like: 0x000609bc 0x00000018 0x0000031c Jun 04 11:21:03 it may be so Jun 04 11:23:20 81, not 18 Jun 04 11:24:32 Hi people what's going on with mvebu? I was going to bo a build to test dsa and now I see this. https://github.com/openwrt/openwrt/pull/3074 Jun 04 11:24:44 mips is single branch-delay-slot, right? Jun 04 11:24:49 build* Jun 04 11:24:58 matteosilex: otrx for the host is built along with all the firmware utils, shouldn't depend on the target? Jun 04 11:29:09 rmilecki: matteosilex: http://paste.debian.net/1150096/ (fix for partition extraction) Jun 04 11:32:22 PaulFertser: mmm... I don't have it in staging_dir/host/bin Jun 04 11:33:04 matteosilex: gcc ./package/utils/otrx/src/otrx.c -o otrx Jun 04 11:45:37 haha, it fixes but not quite, the third partition has no limit so the result file has wrong length. Jun 04 11:49:35 matteosilex: after doing "truncate -s 394912 fw3.bin" I'm able to pack trx to something very similar to the original file with "otrx create j.bin -b 0x81 -f fw2.bin -f fw3.bin -f fw1.bin" Jun 04 11:51:24 matteosilex: but I still would recommend to just patch crc manually instead Jun 04 11:52:23 For the first test Jun 04 11:53:05 * rmilecki agrees Jun 04 12:21:42 packages feeds: what is the criteria to update PKG_RELEASE ? thanks Jun 04 12:22:03 if I just want to change the PKG_REV ? Jun 04 12:27:32 if you change the rev, reset release to 1 Jun 04 12:28:06 changes to a makefile that do not change the REV need a release + 1 update so that opkg knows it needs to update even if the REV did not change Jun 04 12:28:19 like a fix to a init.d script only would require a release+1 update Jun 04 12:54:10