**** BEGIN LOGGING AT Mon Nov 02 02:59:57 2020
Nov 02 03:19:26 <FirstTimer_NoTim> Hello. After lots of trial and error I have finally made the (surprisingly) tiny patches that are needed to support a comfast cf-e538 (ramips board). It builds by selecting the device in menuconfig + make defconfig. While I am very happy, I really would like to submit that. BUT it seems that there is another steep learning curve involved. I am
Nov 02 03:19:26 <FirstTimer_NoTim> running a bit out of energy at this point and am looking for some hand-holding and then follow https://openwrt.org/submitting-patches
Nov 02 03:23:22 <panchen> hello.I send a patch about fixing memory leak on usrteam-ssl project to openwrt-devel@lists.openwrt.org。where I can Tracking process。。
Nov 02 03:25:02 <FirstTimer_NoTim> @panchen : "Patches sent to the Development mailing list can be followed on Patchwork at ​https://patchwork.ozlabs.org/project/openwrt/list/. " does that help?
Nov 02 03:28:24 <panchen> FirstTimer_NoTim Thanks, I find it.
Nov 02 03:58:52 <Tusker> I'm currently working on porting OpenWRT to a mpc8544ds based Synology NAS, and so far have got gdb remote debugging via JTAG, but I am having issues getting the kernel started.  As far as I can see in the BT, it is failing around the TLB init process, but that's not my area of expertise.  does anyone know how to debug TLB issues with PowerPC ?
Nov 02 04:00:41 <Tusker> i can't get the breakpoints to stop at useful places, though have managed to step through __early_start, but it's pretty low level stuff
Nov 02 04:04:17 <Tusker> anyone have any good ideas? :)
Nov 02 04:05:38 <FirstTimer_NoTim> @Tusker - I can't help, but it might be useful to provide more background. Which version of OpenWRT are you compiling? What options do you use? It seems that there is support for the board mpc8544ds  - so I would have assumed that you should be able to get it to boot further than you describe
Nov 02 04:08:29 <Tusker> FirstTimer_NoTim: you'd think that it would be simply just turning on the mpc8544ds support and it would boot, but it doesn't seemt to want to.  I am compiling with trunk, and it is pretty much the default options for mpc85xx.  I have previously attempted to boot using the standard DTS, and have tried to create a custom one to get it to boot.
Nov 02 04:10:50 <FirstTimer_NoTim> I found that I could extract the DTS from the firmware for my device using binwalk and then a hexeditor (DTB magic number is D0 0D) then using dtc to convert it back
Nov 02 04:11:14 <Tusker> yeah, I did that too, it doesn't boot with the old DTS either
Nov 02 04:11:58 <FirstTimer_NoTim> tbh, I only got mine to boot when I tried another devices DTS - even though I was certain I did translate all of the original DTS correctly
Nov 02 04:12:17 <FirstTimer_NoTim> But yours is failing much too early
Nov 02 04:12:59 <FirstTimer_NoTim> I found working with openWRT is a steep learning curve + you have to navigate all the outdated information
Nov 02 04:13:52 <Tusker> yeah, it is pretty tough getting your head around it all sometimes
Nov 02 04:17:37 <FirstTimer_NoTim> I spent days (and my device already ran on a modified openWRT in the first place) on getting the DTS right. I would probably be quicker now with a second device from that company, but it was a slow, frustrating and not very rewarding experience
Nov 02 04:18:19 <Tusker> yeah, big time, having JTAG debugging support via gdb is very useful though, at least I can see where the failure is
Nov 02 04:18:38 <Tusker> before I had the JTAG support, it was such trial and error
Nov 02 04:18:54 <Tusker> failed == "something is wrong"
Nov 02 04:19:57 <Tusker> taught me quite a bit about the kernel internals though, trying to step through it
Nov 02 04:32:55 <FirstTimer_NoTim> @tusker I wish you all the best of luck getting it to boot.
Nov 02 04:34:19 <Tusker> thanks :)
Nov 02 05:15:34 <damex> Tusker: is there some log boot log? could you provide a detail about uboot environment (printenv ?)? what are other commands available (help command) you might be able to extract uboot device tree in some cases? there might be dts inside uboot too but shouldn't differ too much against one firmware have.
Nov 02 05:16:21 <damex> >  at least I can see where the failure is
Nov 02 05:16:25 <damex> where does it fail though?
Nov 02 06:14:07 <Tusker> damex: no boot log at all, it stops before console is setup in the kernel
Nov 02 06:14:50 <damex> Tusker: what about bootlog before that?
Nov 02 06:15:07 <damex> you have uart/jtag access and can see uboot boot log and etc?
Nov 02 06:15:12 <Tusker> I have extracted the factory DTS already, but it doesn't work either (it is from 2.6.x so pretty old)
Nov 02 06:15:25 <Tusker> i have uart and jtag access and can see the bootlog from uboot only
Nov 02 06:15:35 <damex> can you show it?
Nov 02 06:15:51 <damex> and please show the kernel config you did for it
Nov 02 06:16:01 <Tusker> sure, hang on
Nov 02 06:17:38 <Tusker> https://termbin.com/uqv23
Nov 02 06:18:20 <Tusker> factory dmesg - https://termbin.com/c0vj
Nov 02 06:18:42 <Tusker> factory dts - https://termbin.com/qunq
Nov 02 06:19:03 <Tusker> uboot printenv - https://termbin.com/bdei
Nov 02 06:21:42 <damex> Tusker: how did you assemble the kernel ? did you strip anything or patch it?
Nov 02 06:22:15 <damex> i.e. for octeons there was long needed workaround for stripping notes or kernel won't boot
Nov 02 06:23:22 <damex> Tusker: can you do factory full boot log?
Nov 02 06:23:45 <Tusker> modified DTS - https://termbin.com/nei4
Nov 02 06:24:21 <Tusker> sure, hang on
Nov 02 06:25:04 <damex> > clock-frequency = < 0x00 >;
Nov 02 06:25:56 <Tusker> that's what the facctory has in it's DTS, so I just copied
Nov 02 06:26:52 <Tusker> https://termbin.com/30ug for the full boot log
Nov 02 06:26:55 <Tusker> for factory
Nov 02 06:26:58 <FirstTimer_NoTim> To chime in - I saw uboot source that had the comment that this is to be set by uboot
Nov 02 06:27:09 <FirstTimer_NoTim> (clock-frequency that is)
Nov 02 06:27:37 <FirstTimer_NoTim> (for your specific board)
Nov 02 06:28:21 <damex> uboot from 2008 :>
Nov 02 06:33:56 <Tusker> maybe in kernel 2.6, it sets it manually, but in 5.4.x it doesn't ?
Nov 02 06:37:29 <Tusker> is that clock-frequency setting available in /proc somewhere ?  /proc/cpuinfo shows clock        : 1066.560000MHz
Nov 02 06:38:03 <damex> it is cpu frequency, not serial
Nov 02 06:42:32 <Tusker> yeah, /proc/cpuinfo shows that frequency
Nov 02 06:53:33 <damex> Tusker: i can't find info who handles the interrupts. interrupt-parent = < 0x01 >; no phandle like that
Nov 02 06:53:56 <damex> lots of entries use that
Nov 02 06:54:16 <damex> but when i check upstream device trees they don't specify interrupt parrent at'all
Nov 02 06:56:01 <damex> but clock-frequency for serial in upstream dts is 0 so should be fine
Nov 02 06:56:12 <damex> https://github.com/torvalds/linux/blob/master/arch/powerpc/boot/dts/fsl/pq3-duart-0.dtsi that one is included
Nov 02 06:56:47 <Tusker> so you think rebuild without interrupt-parent ?
Nov 02 06:57:15 <damex> you can try, it does not hurt to try.
Nov 02 07:05:13 <Tusker> looks like interrupt-parent = <&mpic>; and interrupt-parent = <&i8259>; are used in some of the includes, so 0x1 should refer to &mpic I imagine ?
Nov 02 07:07:29 <Tusker> linux,phandle = < 0x01 >;
Nov 02 07:17:05 <damex> Tusker: yeah
Nov 02 07:17:22 <damex> it is easier to understand when you use labels :)
Nov 02 07:17:46 <Tusker> OK, no change on the boot console, still blank
Nov 02 07:18:30 <Tusker> let me try again with memory reg = <0x00 0x00> and see whether uboot actually fills it out
Nov 02 07:21:26 <damex> Tusker: maybe try to add chosen {} node with stdout-path to &serial0 or which one is actually exposed
Nov 02 07:26:49 <damex> Tusker: offsets are different between stock and owrt you boot. stock booting kernel from a different offset
Nov 02 07:27:12 <damex> might be irrelevant
Nov 02 08:00:33 <Tusker> damex: yeah, i saw it booting from 0xa vs 0xc
Nov 02 08:03:19 <Tusker> I will try with 0xa
Nov 02 08:10:47 <Tusker> no difference with 0xa, let me try and trace with jtag
Nov 02 08:16:50 <Tusker> CONFIG_KERNEL_START and CONFIG_PAGE_OFFSET ?
Nov 02 08:29:31 <Tusker> well, it actually still boots with 0xc, something in the openwrt build system is setting back to 0xc
Nov 02 11:25:04 <ynezz> aparcar[m]: FYI https://bugs.openwrt.org/index.php?do=details&task_id=3424
Nov 02 11:41:50 <blocktrron> ynezz: also ran into this issue. any thoughts about reverting this for now?
Nov 02 12:25:46 <stintel> https://twitter.com/samykamkar/status/1322671073893126144
Nov 02 12:27:58 <rsalvaterra> stintel: Just don't let the system load NAT helpers automatically. ;)
Nov 02 12:32:03 <rsalvaterra> And a "2.6.36.4brcmarm+" kernel is not only long in the tooth, but also heavily modified, for sure. Wake me up when it's reproduced in vanilla upstream.
Nov 02 13:09:21 <nitroshift> rsalvaterra, not to mention it's an ancient kernel, 2.6
Nov 02 13:10:34 <Namidairo> i checked the nearest 3.x broadcom image and didn't find the offending module so
Nov 02 13:10:35 <Namidairo> there's that
Nov 02 13:25:54 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 02 13:31:14 <f00b4r0> am I correct in understanding that 'wifi down' and 'wifi up' actually modify the config, i.e. write to permanent storage when invoked?
Nov 02 13:32:19 <olmari> f00b4r0: I don't see what actual settings those 2 commands would change
Nov 02 13:37:31 <f00b4r0> olmari: the set_wifi_*() functions confused me. But I see now they appear to be deadcode
Nov 02 13:41:31 <elmo26> sry for the noob question. how do write the uci get and set commands for the option ipaddr in network -> config interface 'lan' -> option ipaddr?
Nov 02 13:43:14 <grift> try `uci show network` to see what the syntax is elmo26
Nov 02 13:43:35 <elmo26> oh
Nov 02 13:43:40 <elmo26> thanks :D
Nov 02 14:34:50 <karlp> is there any config knob to change teh timestamp that files are written as?
Nov 02 14:35:02 <karlp> trying to cause a bigger jump in time when ntp syncs just after boot,
Nov 02 14:37:07 <dangole> blocktrron, ynezz: i'm lookig at the opkg issue. it's non-trivial to revert as IB now depends on that change (which was supposed to address a bug which previously broke kmod feeds)
Nov 02 14:40:51 <karlp> alternatively, anyone know where the timestamp on the rootfs is set? I  know it gets set to ~build time, somewhere, but not sure where? I've looked for any use of touch -r, but not seeint anything obvious
Nov 02 14:43:33 * karlp resets his pc clock and rebuilds.
Nov 02 14:47:17 <stintel> I vaguely remember this is linked to the last git commit
Nov 02 15:58:19 <zorun> yes, it's the date of the latest git commit IIRC
Nov 02 16:01:09 <karlp> setting my desktop clock backwards was a trainwreck. I'm currerntly rebuilding with export SOURCE_DATE_EPOCH="somethign" and hoping it "does the right thing", but not finding much about it :)
Nov 02 16:02:47 <zorun> karlp: looks like this is done in scripts/get_source_date_epoch.sh
Nov 02 16:03:27 <karlp> oh look, a version.date file
Nov 02 16:03:59 <karlp> I love finding undocumented features. :)
Nov 02 16:04:40 <karlp> and, is that actually ignoring the env var if it's already set?
Nov 02 16:04:46 <jow> anyone looking into the opkg regression?
Nov 02 16:05:08 <jow> apparently someone managed to break the one thing it is supposed to do - installing dependencies
Nov 02 16:05:41 <jow> nvm, just read backlog
Nov 02 16:10:19 <jow> dangole: if you look into fixing the opkg issue, please try removing the multi-pass parsing (SF_NEED_DETAIL related code)
Nov 02 16:11:47 <dangole> jow: still on it. opkg is incredibly messy, i wouldn't have ever touched that voluntarily. apparently that pkg_hash_fetch_unsatisfied_dependencies() is consuming some parts of the pkg_t which has been passed to it :( duplicating that is also non-trivial as it's a cascade of (partially recursive) pointers...
Nov 02 16:13:00 <jow> yes, the solver code is hard to understand, partly due to the extremely verbose code dealing with pkg_t collections
Nov 02 16:13:11 <jow> vectors in their lingo
Nov 02 16:13:36 <dangole> jow: once i find a way that checking for unresolvable dependencies would not destroy the pkt_t we'd have liked it to check...
Nov 02 16:13:58 <jow> iirc you can simply iterate it with a for loop
Nov 02 16:14:12 <jow> whrre does it consume it?
Nov 02 16:14:47 <jow> pkg_hash_fetch_unsatisfied_dependencies() ?
Nov 02 16:17:31 <dangole> i think i figured it out
Nov 02 16:18:03 <dangole> pkg_hash_fetch_unsatisfied_dependencies marks packages once it checked them to avoid redundant checks. we got to clear those marks after calling it
Nov 02 16:18:41 <jow> yep
Nov 02 16:20:50 <jow> hm, seems we can also save some more memory by collapsing some abstract_pkg struct members into bit fields
Nov 02 16:21:13 <jow> dependencies_checked uses an int type to save a bool
Nov 02 16:21:45 <jow> state_status and state_flag use an enum each while they only need two or three bits
Nov 02 16:22:49 <dangole> jow: if i'd start to take a general look at 'things to improve' in opkg, it'd end up being a complete rewite
Nov 02 16:23:31 <jow> https://pastebin.com/W6PNJh3K
Nov 02 16:25:33 <dangole> ok, adding bit lengths to the field in that struct is not a lot of effort while (hopefully) significantly reducing memory resource needs...
Nov 02 16:26:20 <jow> should reduce it from 12 (28) byte to just two
Nov 02 16:26:30 <jow> *24
Nov 02 16:27:01 <jow> but gcc specific due to type mixture
Nov 02 16:40:33 <dangole> jow: ok, i think i fixed that dependency issue. clearing those check-marks after pkg_hash_fetch_unsatisfied_dependencies() did the trick.
Nov 02 16:42:38 <dangole> jow: now trying with the bitlength of those fields in abstract_pkg reduced like you suggested
Nov 02 16:47:21 <dangole> jow: i guess we'd need __attribute__((__packed__)) as well for the size reduction to take effect, right?
Nov 02 16:47:57 <dangole> (on the cost of increased CPU consumption for unaligned access, at least on some platforms in my understanding)
Nov 02 16:54:12 <damex> we need help with someone else reviewing the PR/MR https://github.com/openwrt/openwrt/pull/3531 two people reviwed it and two people tested it. it does not seem to be enough to add a new device?
Nov 02 17:03:23 <dangole> jow, ynezz, blocktrron: push a fix to opkg.git
Nov 02 17:07:42 <aparcar[m]> Thanks for fixing this
Nov 02 17:16:39 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 02 17:17:47 <jow> dangole: hm yes, possible that packed attribute is needed
Nov 02 17:26:21 <f00b4r0> dangole: ISTR some archs will spew console messages on unaligned accesses
Nov 02 17:28:28 <f00b4r0> bitwise ops on struct bitfields shouldn't require __packed__ if the bitfield is defined within the struct, iirc
Nov 02 17:28:49 <f00b4r0> not that I have any idea what code you're touching, I know better than to dig into opkg ;>
Nov 02 18:04:40 <Grommish> damex: If you've corrected anything that was mentioned, ask what else needs to be done.  adrianschmutzler understands not ever device has a large test base :)  Esp the mips64/octeon line :D
Nov 02 18:05:02 <damex> Grommish: everything is fixed. we just need one more reviewer
Nov 02 18:06:14 <Grommish> Eh?  I mean.. I can build it out, but I can't test it.. Why does x number of reviewers need to be for the unpopular targets ;p
Nov 02 18:06:53 <Grommish> damex: I want to have a serious conversation with you about building Ubiquiti targets
Nov 02 18:07:25 <damex> everything that adrianschmutzler asked for - is fixed. we also fixed all the cosmetic issues we could and compatibility issues that might have been there. everything looks great from mine and lemmi point of view. that build is also being used daily.
Nov 02 18:07:26 <Grommish> damex: How flexible are you with the Ubiquiti line?
Nov 02 18:09:45 <damex> Grommish: what exactly do you want to know? i am using their switches in office/datacenters for management and also routers sometime is being used in office ;)
Nov 02 18:10:00 <Grommish> Check the dm
Nov 02 18:25:09 <rsalvaterra> dangole: I marked my OWE patch as accepted and delegated to you, since you applied it. I'm not sure if it's the correct procedure, though.
Nov 02 20:06:56 <dangole> jow, f00b4r0: please have a look at this: https://termbin.com/cdmv
Nov 02 20:07:51 <f00b4r0> dangole: I'm not sure I would code it that way, but it's possible the compiler will be smart enough
Nov 02 20:08:25 <f00b4r0> typically I'd union within the struct say an int and the desired bitfield. This way you shouldn't face alignment issues, and you shouldn't need the __packed__ which I'm pretty sure will cause problems
Nov 02 20:08:41 <aparcar[m]> adrianschmutzler: Do you have an idea for a minimal list of required metadata information for newly added devices?
Nov 02 20:13:09 <f00b4r0> dangole: without looking at the type definitions and how this is used throughout the code, it's hard to make smart suggestions tbh. Grouping members by type (e.g. pointers together) would avoid extra padding already
Nov 02 20:15:46 <dangole> did some sizeof() testing. without any changes sizeof(struct abstract_pkg) == 56. when adding the field lengths like jow suggested it becomes 48 bytes. with __attribute(__packed__) it is further reduced to 42 bytes.
Nov 02 20:16:01 <dangole> (on 64-bit systems)
Nov 02 20:16:45 <f00b4r0> the extra 4 bytes are probably padding between the bitfield and the next pointer
Nov 02 20:17:11 <f00b4r0> 6 bytes
Nov 02 20:17:13 <f00b4r0> gee I'm tried
Nov 02 20:17:18 <f00b4r0> tired :/
Nov 02 20:18:04 <f00b4r0> if my assumption is correct, I would move the bitfield at the end of the struct
Nov 02 20:18:14 <f00b4r0> having unaligned pointers is going to be a disaster on several platforms
Nov 02 20:18:53 <dangole> f00b4r0: good point
Nov 02 20:19:44 <f00b4r0> something like this https://pastebin.com/KvM51dS5
Nov 02 20:20:05 <f00b4r0> assuming of course the last pointer isn't used for variable space allocation
Nov 02 20:20:51 <f00b4r0> if pkg_state_status_t and pkg_state_flag_t don't expand to some integer type, the compiler will probably choke
Nov 02 20:22:39 <f00b4r0> also note that if this structure is used in an array of sorts, you'll definitely want to preserve the padding anyway
Nov 02 20:23:08 <dangole> f00b4r0: i guess that 6 bytes savings with __packed__ will always screw up platforms if we have an array of that which is then not sizeof(void*) aligned...
Nov 02 20:23:26 <dangole> f00b4r0: you just said it :)
Nov 02 20:23:44 <f00b4r0> yup :)
Nov 02 20:25:38 <dangole> f00b4r0: thanks for lending your eyes for this, pushed it now
Nov 02 20:25:45 <dangole> *your tired eyes ;)
Nov 02 20:27:44 <f00b4r0> yw :)
Nov 02 20:28:04 <f00b4r0> i'll be signing off now. ttyl
Nov 02 21:07:56 <aparcar[m]> are there DTS entries for RTCs?
Nov 02 21:15:43 <dangole> aparcar[m]: yes, RTCs (both in-SoC as well as I2C-connected ones) are represented in DTS.
Nov 02 21:16:54 <aparcar[m]> dangole: thanks
Nov 03 02:37:56 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
**** ENDING LOGGING AT Tue Nov 03 03:00:33 2020