adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
rsalvaterra has quit [Quit: Leaving.]
MichaelOF has quit [Quit: Konversation terminated!]
Tapper has quit [Ping timeout: 240 seconds]
Tapper has joined #openwrt-devel
hbug___ has joined #openwrt-devel
hbug__ has quit [Ping timeout: 240 seconds]
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
FirstTimer_NoTim has joined #openwrt-devel
panchen has joined #openwrt-devel
<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
<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
woshty has quit [Ping timeout: 268 seconds]
<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。。
panchen has quit [Remote host closed the connection]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tusker has joined #openwrt-devel
<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 ?
victhor has quit [Ping timeout: 240 seconds]
<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
<Tusker>
anyone have any good ideas? :)
<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
<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.
<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
<Tusker>
yeah, I did that too, it doesn't boot with the old DTS either
<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
<FirstTimer_NoTim>
But yours is failing much too early
<FirstTimer_NoTim>
I found working with openWRT is a steep learning curve + you have to navigate all the outdated information
<Tusker>
yeah, it is pretty tough getting your head around it all sometimes
MichaelOF has joined #openwrt-devel
<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
<Tusker>
yeah, big time, having JTAG debugging support via gdb is very useful though, at least I can see where the failure is
<Tusker>
before I had the JTAG support, it was such trial and error
<Tusker>
failed == "something is wrong"
<Tusker>
taught me quite a bit about the kernel internals though, trying to step through it
Shallanger has quit [Ping timeout: 265 seconds]
<FirstTimer_NoTim>
@tusker I wish you all the best of luck getting it to boot.
<Tusker>
thanks :)
MichaelOF has quit [Quit: Konversation terminated!]
<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.
<Tusker>
so you think rebuild without interrupt-parent ?
<damex>
you can try, it does not hurt to try.
goliath has joined #openwrt-devel
<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 ?
<Tusker>
linux,phandle = < 0x01 >;
nitroshift has joined #openwrt-devel
ivanich has joined #openwrt-devel
<damex>
Tusker: yeah
<damex>
it is easier to understand when you use labels :)
<Tusker>
OK, no change on the boot console, still blank
<Tusker>
let me try again with memory reg = <0x00 0x00> and see whether uboot actually fills it out
<damex>
Tusker: maybe try to add chosen {} node with stdout-path to &serial0 or which one is actually exposed
Borromini has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
<damex>
Tusker: offsets are different between stock and owrt you boot. stock booting kernel from a different offset
Acinonyx_ has quit [Ping timeout: 264 seconds]
<damex>
might be irrelevant
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
<Tusker>
damex: yeah, i saw it booting from 0xa vs 0xc
damex has quit [Ping timeout: 256 seconds]
Borromini has quit [Quit: Lost terminal]
<Tusker>
I will try with 0xa
black_ant has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
<Tusker>
no difference with 0xa, let me try and trace with jtag
<Tusker>
CONFIG_KERNEL_START and CONFIG_PAGE_OFFSET ?
rsalvaterra has joined #openwrt-devel
<Tusker>
well, it actually still boots with 0xc, something in the openwrt build system is setting back to 0xc
<rsalvaterra>
stintel: Just don't let the system load NAT helpers automatically. ;)
<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.
<f00b4r0>
am I correct in understanding that 'wifi down' and 'wifi up' actually modify the config, i.e. write to permanent storage when invoked?
<olmari>
f00b4r0: I don't see what actual settings those 2 commands would change
<f00b4r0>
olmari: the set_wifi_*() functions confused me. But I see now they appear to be deadcode
samantaz_ has joined #openwrt-devel
elmo26 has joined #openwrt-devel
<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?
samantaz has quit [Ping timeout: 268 seconds]
<grift>
try `uci show network` to see what the syntax is elmo26
<elmo26>
oh
<elmo26>
thanks :D
daregap has quit [Quit: daregap]
dangole has joined #openwrt-devel
andi- has quit [Remote host closed the connection]
andi- has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
Grommish has joined #openwrt-devel
<karlp>
is there any config knob to change teh timestamp that files are written as?
<karlp>
trying to cause a bigger jump in time when ntp syncs just after boot,
<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)
<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
Nick_Lowe has joined #openwrt-devel
* karlp
resets his pc clock and rebuilds.
MichaelOF has joined #openwrt-devel
<stintel>
I vaguely remember this is linked to the last git commit
linzst has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
feriman has quit [Ping timeout: 260 seconds]
<zorun>
yes, it's the date of the latest git commit IIRC
<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 :)
<zorun>
karlp: looks like this is done in scripts/get_source_date_epoch.sh
<karlp>
oh look, a version.date file
rsalvaterra has quit [Ping timeout: 256 seconds]
<karlp>
I love finding undocumented features. :)
<karlp>
and, is that actually ignoring the env var if it's already set?
<jow>
anyone looking into the opkg regression?
<jow>
apparently someone managed to break the one thing it is supposed to do - installing dependencies
<jow>
nvm, just read backlog
rsalvaterra has joined #openwrt-devel
Shallanger has joined #openwrt-devel
<jow>
dangole: if you look into fixing the opkg issue, please try removing the multi-pass parsing (SF_NEED_DETAIL related code)
<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...
<jow>
yes, the solver code is hard to understand, partly due to the extremely verbose code dealing with pkg_t collections
<jow>
vectors in their lingo
<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...
<jow>
iirc you can simply iterate it with a for loop
<jow>
whrre does it consume it?
decke has quit [Quit: Leaving.]
<jow>
pkg_hash_fetch_unsatisfied_dependencies() ?
<dangole>
i think i figured it out
<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
<jow>
yep
<jow>
hm, seems we can also save some more memory by collapsing some abstract_pkg struct members into bit fields
<jow>
dependencies_checked uses an int type to save a bool
elmo26 has quit [Ping timeout: 245 seconds]
<jow>
state_status and state_flag use an enum each while they only need two or three bits
<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
<dangole>
ok, adding bit lengths to the field in that struct is not a lot of effort while (hopefully) significantly reducing memory resource needs...
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jow>
should reduce it from 12 (28) byte to just two
<jow>
*24
Nick_Lowe has joined #openwrt-devel
<jow>
but gcc specific due to type mixture
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<dangole>
jow: ok, i think i fixed that dependency issue. clearing those check-marks after pkg_hash_fetch_unsatisfied_dependencies() did the trick.
<dangole>
jow: now trying with the bitlength of those fields in abstract_pkg reduced like you suggested
<dangole>
jow: i guess we'd need __attribute__((__packed__)) as well for the size reduction to take effect, right?
<dangole>
(on the cost of increased CPU consumption for unaligned access, at least on some platforms in my understanding)
Shallanger_ has quit [Quit: Leaving]
Shallanger has joined #openwrt-devel
<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?
philipp64|work has joined #openwrt-devel
<dangole>
jow, ynezz, blocktrron: push a fix to opkg.git
<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
<damex>
Grommish: everything is fixed. we just need one more reviewer
<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
<Grommish>
damex: I want to have a serious conversation with you about building Ubiquiti targets
<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.
<Grommish>
damex: How flexible are you with the Ubiquiti line?
linzst has quit [Quit: Leaving]
<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 ;)
<Grommish>
Check the dm
<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.
nast has quit [Quit: leaving]
nast has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
n4gi0s has quit [Ping timeout: 246 seconds]
n4gi0s has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
csrf has joined #openwrt-devel
victhor has joined #openwrt-devel
Shallanger has quit [Remote host closed the connection]
MichaelOF has quit [Quit: Konversation terminated!]
<f00b4r0>
dangole: I'm not sure I would code it that way, but it's possible the compiler will be smart enough
<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
<aparcar[m]>
adrianschmutzler: Do you have an idea for a minimal list of required metadata information for newly added devices?
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<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
<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.
<dangole>
(on 64-bit systems)
<f00b4r0>
the extra 4 bytes are probably padding between the bitfield and the next pointer
<f00b4r0>
6 bytes
<f00b4r0>
gee I'm tried
<f00b4r0>
tired :/
<f00b4r0>
if my assumption is correct, I would move the bitfield at the end of the struct
<f00b4r0>
having unaligned pointers is going to be a disaster on several platforms
<f00b4r0>
also note that if this structure is used in an array of sorts, you'll definitely want to preserve the padding anyway
Nick_Lowe has quit [Client Quit]
<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...
<dangole>
f00b4r0: you just said it :)
<f00b4r0>
yup :)
<dangole>
f00b4r0: thanks for lending your eyes for this, pushed it now
<dangole>
*your tired eyes ;)
<f00b4r0>
yw :)
<f00b4r0>
i'll be signing off now. ttyl
Nick_Lowe has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
Ycarus has quit [Quit: Ycarus]
<aparcar[m]>
are there DTS entries for RTCs?
<dangole>
aparcar[m]: yes, RTCs (both in-SoC as well as I2C-connected ones) are represented in DTS.
<aparcar[m]>
dangole: thanks
Nick_Lowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]