stikonas has quit [Remote host closed the connection]
stikonas_ has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 272 seconds]
_whitelogger has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
vstehle has joined #linux-rockchip
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-rockchip
chewitt_ is now known as chewitt
JohnDoe_71Rus has quit [Ping timeout: 272 seconds]
levd has quit [Ping timeout: 265 seconds]
JohnDoe_71Rus has joined #linux-rockchip
<repk>
tuxd3v: it seems you booted the kernel fine
<repk>
[ 1.313643] ttyS2 - failed to request DMA
<repk>
[ 100.017779] random: crng init done
<repk>
its the tty that has issue
<repk>
maybe you are using wrong dtb
perr has joined #linux-rockchip
<repk>
tuxd3v: well I also get failed to request DMA. So yes your kernel booted fine, it is your rootfs that is the issue here.
chewitt has quit [Ping timeout: 258 seconds]
chewitt_ has joined #linux-rockchip
perr has quit [Remote host closed the connection]
perr has joined #linux-rockchip
chewitt_ is now known as chewitt
field^Zzz3 has joined #linux-rockchip
jaganteki has joined #linux-rockchip
stikonas has joined #linux-rockchip
perr has quit [Ping timeout: 272 seconds]
matthias_bgg has joined #linux-rockchip
field^Zzz3 has quit [Ping timeout: 272 seconds]
mazema has joined #linux-rockchip
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
<nomis>
I am trying to enable a wireless module (AP6255) on my tv box and right now have no real success. How can I debug the device tree for that? Can I check if the basic sdio communication is available and works?
<robmur01>
nomis: Broadcom-based AMPAK modules usually just need getting the enable GPIOs right to at least show up
<robmur01>
(possibly also the 32KHz clock, but that's typically on by default anyway)
<robmur01>
the rest is just decoding the BSP rfkill driver's GPIOs into what they actually mean on the module, to then translate to the upstream bindings
<nomis>
robmur01: it is perfectly possible that my setup of the sdio-bus is lacking. Do you know how I would test for its existance?
<nomis>
/sys/bus/sdio/ is there, but I don't really see any probimg messages or something like that.
<nomis>
where does "wifi_chip_type" get evaluated?
<robmur01>
(in this case upstream doesn't describe wl_wake_host as an out-of-band interrupt since it confuses the appropriate 6256S firmware (which *isn't* the one in linux-firmware))
<nomis>
(that was empty for me up to now)
<robmur01>
meh, best ignore that unless you have the exact BSP source your box vendor used (IIRC it doesn't mean all that much anyway) - the clock and gpio specifiers are what matters
<nomis>
as far as I can tell clock and gpio are now the same as in the devicetree I've scraped from the 4.14-kernel that was running on the device.
<robmur01>
double-check polarities? IIRC on another board with a 6330 at least one of the pins has its meaning inverted between downstream and upstream, so e.g. an active-low reset might need to become an active-high enable
<robmur01>
at worst you can usually dredge up the AMPAK datasheets and make sense of the GPIO-to-module-pin mappings with a multimeter and wiggling the GPIOs from userspace
<nomis>
bah, I am in a crappy mood today. Sorry if that shows.
<mps>
bah, also I'm. had a hope that kernel 5.7-rc4 will solve issue with rockchip-drm and/or mmc but no luck
<mps>
emmc*
<mps>
on chromebook, I mean
<mps>
except that 5.7-rc3 fried speakers on it :\
mazema has quit [Remote host closed the connection]
mazema has joined #linux-rockchip
mazema has quit [Remote host closed the connection]
mazema has joined #linux-rockchip
<tuxd3v>
repk, thanks for your impression on it
<tuxd3v>
I also think that maybe something else was wrong..
<tuxd3v>
I compiled a new kernel, but I am also trying to find a working rootfs, to debug tyhe problem
<tuxd3v>
repk, thanks a lot of your comment :)
<tuxd3v>
vagrantc is also on the smae opinion..
<tuxd3v>
I guess my rootfs is wrongly build or something missing..
<tuxd3v>
smae -> same
<repk>
tuxd3v: yes on the other hand I find the kernel is outputting very little info compare to default config one. Wondering what is your console level here
<repk>
tuxd3v: to test your kernel you could try init=/bin/sh in your command line. That would rule out kernel problem
<robmur01>
frankly, until the kernel log shows visible evidence that the waited-for root device has actually showed up, focus on that ;)
<tuxd3v>
the loglevel=6
<tuxd3v>
its ttyS2
<robmur01>
(or get rid of "rootwait" and see if it panics)
<tuxd3v>
repk, robmur01 , thanks I will try that and see if it helps to debug the problem :)
mazema has quit [Remote host closed the connection]
mayab76 has joined #linux-rockchip
ldevulder has quit [Ping timeout: 265 seconds]
ldevulder has joined #linux-rockchip
vicencb has joined #linux-rockchip
vicencb has quit [Client Quit]
<tuxd3v>
robmur01, repk , I just created another rootfs, same symptoms..
<robmur01>
also pissing about with the loglevel isn't exactly helping anyone - if you're trying to debug something, why suppress info and debug messages? They're *useful*!
<repk>
robmur01 isn't KERN_INFO supposed to be way more verbose ? And KERN_DEBUG only dynamically activated anyway ?
<repk>
I could be wrong here
<tuxd3v>
man...
<tuxd3v>
the device is mmcblk1 ...pufffffffff
<tuxd3v>
thats why it was waiting with rootwait
<tuxd3v>
but still I have some errors
<tuxd3v>
I don't have ethernet interface
<tuxd3v>
[FAIL] startpar: service(s) returned failure: rng-tools ... failed!
<tuxd3v>
rng-tools... doesn't the kernel has a TRNG driver for rk3399?
<tuxd3v>
I will use /dev/urandom in the mean time
vicencb has quit [Quit: Leaving.]
vagrantc has joined #linux-rockchip
field^Zzz3 has joined #linux-rockchip
<tuxd3v>
repk, robmur01 , thanks a lot for your inputs
<tuxd3v>
I was a lot lost already with so many attemps
<tuxd3v>
the rootwait, was a good catch :)
<tuxd3v>
also I gained some confidence with your inputs
<tuxd3v>
because you now some times when tings go wrong.. we start to suspect of a lot of things :)
<tuxd3v>
now I need to compile the ethernet driver
<tuxd3v>
or load it
<tuxd3v>
stmac, I believe for rockpro64?
<repk>
it should be loaded by the devicetree
<tuxd3v>
I have been playing with the jumper closer to emmc module, to boot from sdcard or emmc
<tuxd3v>
but it sometimes doesn't boot at all, wether from emmc or from sdcard
<tuxd3v>
I need to disconect it ald left it some 5-10 minutes disconected to then apply power and then ir will boot
<tuxd3v>
I don't know if you have the same problem or its only a problem with my board?
<tuxd3v>
repk, I was expecting that
<tuxd3v>
I am on kernel 5.6.10
<tuxd3v>
don't know if there are any developemnts further and I need to jump to mainline?
<robmur01>
repk: the normal default loglevel is 7 (info), and unless you're running a serial console at like 9600bps it doesn't really have an appreciable impact on boot time IME
<robmur01>
and even with dynamic debug enabled that only governs whether debug messages are emitted to the kernel log or not in the first place; the loglevel still controls whether they also get displayed on the console
<robmur01>
basically, if you can't get as far as being able to run dmesg, a quiet boot is the last thing you want ;)
<repk>
robmur01: ok I was off by one here. Though 6 was info. thx
jaganteki has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 265 seconds]
matthias_bgg has joined #linux-rockchip
vicencb has joined #linux-rockchip
matthias_bgg has quit [Remote host closed the connection]
<robmur01>
well, info itself is 6, but what goes to console is <loglevel, not <= loglevel