Misanthropos has quit [Read error: Connection reset by peer]
gch9812131 has quit [Read error: Connection reset by peer]
gch98121317 has joined #openwrt-devel
al has joined #openwrt-devel
Misanthropos has joined #openwrt-devel
Grommish has quit [Ping timeout: 256 seconds]
Tusker has joined #openwrt-devel
Grommish has joined #openwrt-devel
Grommish[M] has quit [Ping timeout: 258 seconds]
Grommish[M] has joined #openwrt-devel
<Tusker>
heya guys, I am trying to get OpenWRT running on a Synology NAS (mpc85xx cpu), and I am running into the usual problem of hanging after the Loading Device Tree line is printed. I am trying to get things working with CONFIG_DEBUG_LL and CONFIG_DEBUG_UART_PHYS=0xe0004500 but it seems like uboot isn't handing over control to Linux, at least from a serial point of view. Are there any tricks to debugging this problem ? Anything that would potentially be
<damex>
Tusker: could be flash issue because device tree is stored on flash?
Grommish[M] has quit [Read error: Connection reset by peer]
Grommish[M] has joined #openwrt-devel
Grommish[M] has quit [Client Quit]
dedeckeh has joined #openwrt-devel
aszeszo has quit [Quit: aszeszo]
<Tusker>
damex: I am manually issueing bootm 0x1000000 - 0x6000000, with the device tree and kernel loaded into those addresses
ivanich has joined #openwrt-devel
lep-delete is now known as Guest88073
Rene__ has quit [Ping timeout: 260 seconds]
Rene__ has joined #openwrt-devel
hsp has quit [Quit: WeeChat 2.9]
hsp has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
ivanich has joined #openwrt-devel
Borromini has joined #openwrt-devel
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
valku has quit [Quit: valku]
Ycarus has joined #openwrt-devel
decke has joined #openwrt-devel
Night-Shade has joined #openwrt-devel
rsalvaterra has joined #openwrt-devel
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
feriman has joined #openwrt-devel
Night-Shade has joined #openwrt-devel
aszeszo has joined #openwrt-devel
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dracos-Carazza_ is now known as Dracos-Carazza
feriman has quit [Quit: WeeChat 2.9]
feriman has joined #openwrt-devel
MatMaul has joined #openwrt-devel
xback has quit [Read error: Connection reset by peer]
nitroshift has joined #openwrt-devel
Borromini has quit [Ping timeout: 256 seconds]
[mbm] has quit [K-Lined]
karlp has quit [K-Lined]
matteo__ has quit [K-Lined]
matteo__ has joined #openwrt-devel
karlp has joined #openwrt-devel
Borromini has joined #openwrt-devel
gnustomp has quit [Ping timeout: 272 seconds]
<karlp>
Tusker: where did you get those addresses from? are you sure you don't have any overlaps? are you sure you don't have any kernel loading extracting over themselves?
<Tusker>
those addresses are what I use on a different PPC board. I have tried with an uncompressed kernel too, so extracting over itself shouldn't be an issue I don't think
gnustomp has joined #openwrt-devel
<Tusker>
I can try other addresses if you want... but, my feeling is that there is an issue with the device tree, but it's hard to debug without any output
<damex>
i have 3 gpio that get flipped when you plug in sfp module. any idea how to find which functionality they signal about?
<karlp>
I don't have any better answers, just know that getting those magic numers "wrong" or "not matching what the other end expects" can result in those sorts of failures.
<Tusker>
yeah, it is a bit of frustrating bit of development... I wish I could get mpc85xx urjtag or openocd support so that I can debug uboot... see what it is doing
<Tusker>
i have urjtag working to some degree for the p1020, it connects and can see the registers with boundary scan... but it was in uboot failure mode, so couldn't validate whether the memory reading functionality was actually working
Spr0cket has quit [Quit: x]
Spr0cket has joined #openwrt-devel
Spr0cket has quit [Changing host]
Spr0cket has joined #openwrt-devel
Spr0cket has joined #openwrt-devel
DragoonAethis has quit [Quit: No Ping reply in 180 seconds.]
<PaulFertser>
damex: oh, that looks like nice progress if you get sfp module name there. Does ethtool -m work now?
<damex>
PaulFertser: nope :(
<damex>
PaulFertser: now i need a way to trigger sfp fault :D
<damex>
to test other options
Darkmatter66_ has joined #openwrt-devel
mwarning has quit [Ping timeout: 265 seconds]
Darkmatter66 has quit [Ping timeout: 246 seconds]
<damex>
PaulFertser: problem is that we need to enable completely irrelevant options in kernel to get to CONFIG_SFP
<damex>
anyway, hopefully someone could point me to something that could help test sfp module gpios (3 of them)
meskal_ has quit [Quit: meskal_]
meskal_ has joined #openwrt-devel
meskal_ has quit [Remote host closed the connection]
<PaulFertser>
damex: you can use / in menuconfig and that will show not only the location of an option you're interested in but also the full list of what it depends on.
<damex>
PaulFertser: yeah, i did that. there is a dependency on either DSA or hardware that is not present on this platform.
<damex>
i did deeper and deeper checks of that dependencies and just enabled one of the ethernet controllers that will let me enable sfp support
<damex>
s/did/dig
<damex>
oh
stintel has quit [Remote host closed the connection]
<damex>
PaulFertser: i checked code - what you describe about actual supported servers with actual supported hardware where ethtoom -m ethX could return something reasonable - this is not the case with cavium due to cavium-octeon state in kernel. i checked their driver in staging tree and it is... bad. there is also no phylink. so message i get from sfp module is just a notification about sfp module and sfp module can't be tied to any adapter (phy/mii)
<damex>
without patching up (i.e. refactor/rewrite) octeon-ethernet driver.
<damex>
i think this is as much as 5.4 linux kernel support octeons
<damex>
i think its time to make a MR.
<damex>
does anyone know if it is possible to have subtarget with FPU while main target does not support it ?
<stintel>
damex: I don't see why not. bcm27xx has subtargets with arm vs aarch64 even
<damex>
stintel: oh sure
<damex>
i will go this way then
sergiomiguelrp has joined #openwrt-devel
shalzz has quit [Quit: Idle for 30+ days]
WiredLife has quit [Quit: Idle for 30+ days]
decke has quit [Quit: Leaving.]
linzst has joined #openwrt-devel
<damex>
uh... why there is octeontx target but no devices there?
Night-Shade has joined #openwrt-devel
feriman has quit [Quit: WeeChat 2.9]
Nick_Lowe has quit [Ping timeout: 246 seconds]
feriman has joined #openwrt-devel
Nick_Lowe has joined #openwrt-devel
victhor has joined #openwrt-devel
<rsalvaterra>
Hmpf… the SLOB allocator is still broken on Linux 5.4 (for ath79, at least).
tmn505 has joined #openwrt-devel
mwarning has quit [Ping timeout: 260 seconds]
feriman has quit [Read error: Connection reset by peer]
<rsalvaterra>
(Or so I think… I don't have another explanation for not being able to boot normally after a sysupgrade, but after failsafe/firstboot the system booted fine.)
gch981213 has joined #openwrt-devel
linzst has quit [Ping timeout: 258 seconds]
philipp64|work has quit [Ping timeout: 258 seconds]
<grift>
if thats true then should be easy enough to confirm with sysupgrade -F -n?
Borromini has joined #openwrt-devel
<grift>
wouldnt be surprised though, i mentioned here no long ago how fragile centralized ipc can be
<rsalvaterra>
grift: Sure, but I just had to reset two machines, I'm not going to test on the last production one. :P
philipp64|work has joined #openwrt-devel
<rsalvaterra>
I'm experimenting with the SLOB allocator on a 4/32 device. I knew it was broken on 4.14, but it got fixed meanwhile. That's how I stumbled upon this.
<grift>
will be interesting to see how that ubusd strategy play's out
lep-delete has quit [Read error: Connection reset by peer]
<grift>
although i guess shouldnt be a problem with such broad permissions on the socket 0666
lep-delete has joined #openwrt-devel
ds_shadof has quit [Ping timeout: 272 seconds]
ds_shadof has joined #openwrt-devel
lep-delete is now known as Guest88073
Guest88073 is now known as lep-delete
n4gi0s has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
linzst has joined #openwrt-devel
victhor has quit [Quit: Leaving]
victhor has joined #openwrt-devel
victhor has quit [Quit: Leaving]
victhor has joined #openwrt-devel
victhor has quit [Remote host closed the connection]
victhor has joined #openwrt-devel
victhor has quit [Quit: Leaving]
victhor has joined #openwrt-devel
ivanich has joined #openwrt-devel
ivanich has quit [Client Quit]
slh64 has quit [Quit: gone]
mwarning has joined #openwrt-devel
victhor has quit [Client Quit]
victhor has joined #openwrt-devel
slh64 has joined #openwrt-devel
ivanich has joined #openwrt-devel
ivanich has quit [Client Quit]
ivanich has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
<mwarning>
hi, how can I build all images of all targets at once?
victhor has quit [Quit: Leaving]
victhor has joined #openwrt-devel
<pkgadd>
you can't, the different targets are mutually exclusive
<pkgadd>
you can only build one after another, including changing the build configs inbetween
Ycarus has quit [Quit: Ycarus]
<pkgadd>
depending on how often you're going to use it, you may want to look into setting up a local buildbot instance - or some simpler orchestration
<pkgadd>
but neither of those can build multiple targets at once, they're merely starting multiple /independent/ build on multiple clients in parallel
philipp64|work has quit [Ping timeout: 260 seconds]