<robimarko>
QCA patched in 256MB support later but that disables features left and right to make it work
<fioriceta>
sounds like it needs to be optimised tbh
<hitech95>
isnt int cool when the device private struct looses its data in uboot?
<linusw>
fioriceta: what I think about Rust is on a 10 year timeline from now, not for like, merge tomorrow. It does make things a bit safer, it doesn't stop you from dividing by zero.
<fioriceta>
cpp support would actually be better
<fioriceta>
rust's syntax is literally unreadable
Danct12 has quit [Ping timeout: 480 seconds]
<linusw>
fioriceta: that's just like, your opinion man ;)
<fioriceta>
only those crazy people from the US insist on rust shit
<linusw>
fioriceta: I think it is a non-US gut reaction to anything that uses marketing to achieve mindshare, which I kind of agree with.
<fioriceta>
no, but rust is unreadable for sure
<fioriceta>
you'd have to be `mentally ill` to even consider it
<fioriceta>
I mean, look at the issue trackers for rust stuff
<fioriceta>
why not dlang/cpp?
<fioriceta>
tbh, if more stuff gets rewritten in rust, why even touch mainline?
<linusw>
fioriceta: CPP was tried in the past in the kernel and had to be tossed out, because it generated too unpredictable struct layouts (especially vtables)
<fioriceta>
yeah, I know, the ABI is a clusterfuck
<linusw>
Yeah it has never been fixed really
<KanjiMonster>
didn't stop broadcom from adding it back so they could use CPP for their atm driver
<fioriceta>
oh, that driver...
<fioriceta>
yeah, I think I've also seen huawei do the same thing
<fioriceta>
KanjiMonster: did you figure out a way to jtag the dsl core?
<KanjiMonster>
never tried to
<fioriceta>
I couldn't get it to show up as a tap
<KanjiMonster>
also I don't think I have a board that exposes it
<fioriceta>
I think they turned off jtag for that stuff
<KanjiMonster>
it's a mips32 core though
<fioriceta>
nah, in the verilog...
<KanjiMonster>
at least on mips 63xx, no idea about arm
<KanjiMonster>
just like the FAP thingies are also mips cores IIRC
<fioriceta>
well, it's a 160mhz core
<fioriceta>
yeah, gfap is
<KanjiMonster>
so in theory you could have a lot more CPU power available, you just need to expose it somehow ;)
<fioriceta>
yeah, that was my thought as well
<KanjiMonster>
though I'm not sure if linux is prepared for that, as the fap/dsl cores may have different memory maps of devices. and I wouldn't be surprised if they lack a TLB
<kabel>
you can see that there is ethernet-phy at MDIO address 0x7, the switch at address 0x10 (and it's internal PHYs are not listed, but they should be on addresses 0x0-0x4 or 0x1-0x5 ot something like that)
* russell--
is seeing bad cell counts for flash partitions on cudy x6 with 22.03: http://sprunge.us/hCbr1v
<Ansuel>
well i have to do some tests on my device first... MDIO_MASTER_EN if set discconnect the external MDC passthrough to the internal PHYs. By doing this in theory we should be able to keep your setup and not need to use the mutex for the mgmt eth (since everything is handled by eth and no MDIO access is needed to write to the switch regs)
<Ansuel>
tests I have to do on my device is: keep MDIO_AMSTER_EN set and sett if it works correctly. (again this work only for mgmt eth as for the legacy mdio way we still need the external mdio to access the switch)
<russell-->
ah, someone can't do hex math
<Ansuel>
nobody can
<Ansuel>
we have 10 finger not 16
<Habbie>
i still cannot get over 0xA being an even number
<Habbie>
and 0xC
* russell--
also having trouble finding the problem in git history, wrong values in 22.03 binary, but ... not in the git history afaict, tries building a fresh firmware
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
<Ansuel>
kabel thing is that from your finding "Connecting the MDIO bus pins onto an oscilloscope, I was able to see
<Ansuel>
that the MDIO bus was active whenever a request to read/write an
<Ansuel>
internal PHY register was done via an management ethernet frame."
<Ansuel>
this should not be the case as when we access the internal phy we enable MDIO_MASTER and that should disconnect the internal MDC from the external one
<kabel>
and where is that written? My QCA8337N data sheet says for the MDIO_MASTER_EN register only this: 1 = Use MDIO master to configure PHY register. MDC is changed to internal MDC to PHY.
<kabel>
this means that the switch's MDIO bus starts to act as a master instead of a slave
<kabel>
but it doesn't say anything about disconnecting from the external pins
<Ansuel>
sooo the finding in those comments are wrong? they are very old info that were notice when the driver was proposed upstream
<kabel>
the comment says that the MDC passthrough is disconnected. That makes sense, since you don't want the MDC from CPU to interfere with the MDC from the switch
<russell-->
aha! i'm running v1 firmware on a v2 device, with less flash, apparently
<kabel>
but the comment does not say anything about the MDIO pin
rua is now known as Guest1935
rua has joined #openwrt-devel
<kabel>
I measured the MDIO pin on the oscilloscope, the MDC pin is not accessible on my board, it is inside the PCB
<kabel>
but the MDIO pin had activity everytime I triggered PHY transfer via ethernet frame
<kabel>
adding the lock fixes the bug I experienced
* russell--
can't do version math
Guest1935 has quit [Ping timeout: 480 seconds]
<KanjiMonster>
version math is complicated, with the exra ~ and + rules
<russell-->
my error was v1 != v2
rua is now known as Guest1936
rua has joined #openwrt-devel
<Ansuel>
kable ok! I will leave some comments in the patch so we can discuss there but yep locking seems to be the only solution...
Guest1936 has quit [Ping timeout: 480 seconds]
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<russell-->
turns out, the v2 firmware works much better on v2 hardware
<russell-->
luckily, bdinfo was backed up and restoration was possible
<hitech95>
I'm, facing an issue thet is bending my mind. the follow call "do_div(priv->pll_clk_rate, sck_l + sck_h + 2);" is editing the pll_clk_rate value. it is defined as a u32 so its not a pointer....
<hitech95>
how is that possible!?
<robimarko>
Where is that being used?
<hitech95>
robimarko, uboot in the SPI driver that is driving us mad
<hitech95>
the pll is modified and goes back to zero after few calls
<robimarko>
hitech95: Not really as its modifying the global struct member
<robimarko>
To the macro its just a plain u32
<hitech95>
yea that is a big issue, the clocks of the SPI are divider by 4 each time... Probaly we have to copy the value before calculating the wait period then
<hitech95>
How the hell did meditek not have seen the issue...
<hitech95>
yea but they pushed to uboot so they mest have tested it no?
<hitech95>
that commit has been pushed to openwrt to!
<fioriceta>
never trust vendors
<hitech95>
that patch remnove the workaround that reset the pll on each transaction
<hitech95>
we vae spent weeks on finding why two devices were not working the same.. and now we discovered this...
<robimarko>
Funnily that commit is in their U-boot as well
philipp64 has quit [Quit: philipp64]
<hitech95>
I still dont get how a u32 is passed as an pointer tho... Maybe ist just me that is not getting the C magic. (Mainly Web dev here)
<robimarko>
Why should it be passed as a pointer?
rua has quit [Quit: Leaving.]
<robimarko>
The struct you are passing is global to the driver
<hitech95>
yea but I dont get how the value is modified inside the do_div method. isnt the value priv->pll_clk_rate copied before passing it to he function?
<hitech95>
uhm... the type of priv->pll_clk_rate is u32*? I've thought that the "->" is a pointer dereference for the field.
<tomn>
i think hitech95 means, how does do_div modify its argument, and the answer is: because it's a macro, which is just a text substution, so writing do_div(a, b) has the same effect as writing `a = a / b`, no matter what a or b is
<tomn>
(sorry to barge in...)
<hitech95>
tomn, ohhh so its not a standard method
<fioriceta>
the biggest issue with openwrt is that there needs to be a higher barrier to entry
<tomn>
no
<tomn>
hitech95: yeah exactly, have a look at the definition i posted, and maybe have a read about how macros work if you haven't already
<hitech95>
tomn, that its now clear. it now makes perfectly sense.
<tomn>
:)
<hitech95>
I've missed that part about the macro
<russell-->
include/div64.h
rua has joined #openwrt-devel
minimal has joined #openwrt-devel
<KanjiMonster>
hitech95: do_div() is a special macro to avoid GCC trying to link to libcc 64-bit division functions when building for 32 bit
valku has joined #openwrt-devel
Danct12 has quit [Remote host closed the connection]
<hitech95>
KanjiMonster, yep, got it! For some reason (information bias probably) I've thought that that was a standard method call and not a macro.
Danct12 has joined #openwrt-devel
<hitech95>
whith this solved now I have to figure out why my device self distructed after the thrird reboot :D
tidalf has quit [Remote host closed the connection]
<Ansuel>
2 boots are enough
tidalf has joined #openwrt-devel
<hitech95>
Ansuel, yea espèecially 2 from initramfs and one from flash then uboot exploded. I'm waiting for the clamp to relash it..
<hitech95>
*especially
<hitech95>
Dam I hate switching keyboards.
ptudor has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
<Tapper>
Hi Ansuel: If I flash a new build of master on my r7800 do I have to redo my configs?
<Ansuel>
forum is your friend... yes as you wont have the compat bit set
<Tapper>
Ansuel OK thanks.
<Tapper>
Ansuel It's just set as a dumb ap anyway.
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
zer0def has quit [Ping timeout: 480 seconds]
tidalf has quit [Remote host closed the connection]
<Ansuel>
so if i backport a series that had 5 patch i would use 700-01 700-02 700-03
<hitech95>
got it, so if I have a fix for a wrong patch 101-03-patch-name.patch how should I call it?
<hitech95>
Ansuel, in my specific case I want to create a patch to fix 101-03-spi-mtk_spim-get-spi-clk-rate-only-once.patch so that I can also push it back to u-boot so I wondering what prefix to use :D
<Ansuel>
is the patch a backport or a custom one?
<hitech95>
custom one, in it will have to be mainlined
<hitech95>
right now the sPI controller is broken :(
<Ansuel>
if it's custom you can both edit that one directly (and update the tag) or just add a new one (you can ignore the numbering of the series just add the next number after the last patch in the 100 order)
<hitech95>
Uhm the original patch is a backport tho
<hitech95>
it that is what you ment
<Ansuel>
if it's a backport than adding a new one is the only way
<Ansuel>
(backport should never be modified)
<hitech95>
got it so I'll go with the next 1XX number available then :D
<hitech95>
I hate quilt I keep editing the files directly :(
Kevinjil has quit [Remote host closed the connection]
<Ansuel>
why you hate quilt ?
<hitech95>
I wust go with "nano myfile.c" instead of "quilt edit myfile.c" its just me beeing dumb
<hitech95>
yes I'm a bad person I use nano
<fioriceta>
quilt is really easy to use...
robimarko has quit [Remote host closed the connection]
tidalf has quit [Remote host closed the connection]
tidalf has joined #openwrt-devel
dangole has joined #openwrt-devel
dgcampea has quit [Remote host closed the connection]
<linusw>
KanjiMonster: sent a v2 and now a v3 of the patch, after realizing that tcpdump shows very nicely what happens inside the frames and 1536 is indeed the max frame size.