<shahid__>
do i need to make the changes as specified in the firefly wiki page
<stdint>
shahid__, the upstream kernel use a different way to enable spi
<stdint>
the way firefly does is really ugly method
<shahid__>
Ok.
<shahid__>
So you want me to download the mainline kernel and the spi drivers in menuconfig
<shahid__>
?
<shahid__>
So you want me to download the mainline kernel and ENABLE the spi drivers in menuconfig
<stdint>
if you use the mainline kernel, it would be more easily for this solution
<shahid__>
?
<stdint>
it only need to enable spi driver module, set those pins to spi and enabled the spi node in dts
<stdint>
which board do you use?
dlezcano has joined #linux-rockchip
<shahid__>
i am using Firefly-RK3288 High-Performance Platform
<shahid__>
not the reloaded one
<stdint>
the release one have been supported long time
<shahid__>
when you say mainline kernel, do you mean the kernel source code from kernel.org?
<stdint>
yep\
<shahid__>
and which version of kernel source code should i download?? The latest stable kernel is 4.7.2
<indy>
stdint, miqi arrived
<stdint>
shahid__, it is okay
<stdint>
indy, good
<indy>
stdint, looking at rk3288 pinout it has also boundaryscan jtag, but even firefly has not it fitted, nice is it has etm trace data on lvds, which are not exposed on miqi
<stdint>
I don't use the lvds panel but eDP
<shahid__>
stdint, i will try with the mainline kernel, thanks
<stdint>
shahid__, you are welcome
wens has quit [Remote host closed the connection]
wens has joined #linux-rockchip
wens has quit [Ping timeout: 260 seconds]
wens has joined #linux-rockchip
shirasaka-hazumi has quit [Remote host closed the connection]
huawei has joined #linux-rockchip
vickycq- has joined #linux-rockchip
vickycq has quit [Ping timeout: 244 seconds]
afaerber has joined #linux-rockchip
<indy>
stdint, do i need something to enable jtag on sdemmc data pins? or it is enabled in uboot?
<stdint>
indy, not so sure, it could be enabled in the maskrom
<naobsd>
it seems there is auto jtag/sdmmc switching function controlled by CD pin
<naobsd>
I don't know detail, but linux mainline disables it explicitly, so I assume it's enabled by default
<stdint>
I should call those IC guys for the detail
<stdint>
as they are not the same building as I, I never meet them
<naobsd>
and I don't know jtag can work with _any_ board, or there is requirement for board design
<naobsd>
by the way how about miqi? should I get it too? ;)
<indy>
naobsd, yes, it takes few weeks, but you can order it from mqmaker.com
<naobsd>
btw I already have several rk3288 boards
<indy>
naobsd, does any of that board exposes lvds pins (etm trace data) or bsjtag_* pins?
<stdint>
indy, why do you use lvds? it is even not the mipi time but eDP
<naobsd>
I need to check schematics (or you may do it)
<indy>
firefly exposes lvds, but not boundary scan jtag
<indy>
stdint, i do not use lvds, but on lvds pins is in func2 trace_data
<jacob_>
It's not easy to enable jtag
<jacob_>
troublesome.
<jacob_>
1.u-boot GRF_SOC_CON0[bit 12] cannot set bit as 0
<jacob_>
3. from hardware side you have to remove the pull ground resistance of sdmmc_det pin or float or pull up.
<jacob_>
4. enable the voltage of sd card 3.3v
premoboss has joined #linux-rockchip
<stdint>
jacob_, check your mail, the mali is ready
<mmind00>
isn't the jtag part of the bigger coresight? Someone could try to set up the kernel coresight support for Rockchip Soc at some point. The jtag pins also have their own pinmux, so ideally they could also just be enabled using regular pinctrl and not have automatic functions work behind the backs of pinctrl and clock framework :-)
utente_ has joined #linux-rockchip
premoboss has quit [Ping timeout: 255 seconds]
<stdint>
not so sure, I don't find this in TRM
<stdint>
but in former chip, it is DAPLITE Technology not CoreSignt
<mmind00>
independent of coresight, jtag should be able to be set up using regular pinmux I'd think
<stdint>
yes it should be, but the trace data are not
<indy>
mmind00, yes, jtag in this context is just hw part of coresight external debug
wadim_ has quit [Quit: Leaving.]
wadim_ has joined #linux-rockchip
<wadim_>
I have problems attaching a debugger to a rk3288. I can only read the TAP ID. But I am not able to halt the CPU or see any registers.
<wadim_>
Has someone here experience with debugging rk3288 socs?
<stdint>
wadim_, would you use the OpenOCD?
<wadim_>
No, I am using a Lauterbach debugger with trace32
<stdint>
the trace32 should work good for it
<stdint>
have you tried to disable the watchdog?
<wadim_>
Are there any special registers which enables access to the DAP? besides grf_force_jtag in GRF_SOC_CON0
<wadim_>
Well, no WD is still active. But this could be my problem
<stdint>
then I can't help, sorry
<wadim_>
thanks anyway
nighty has quit [Quit: Disappears in a puff of smoke]
paulk-nyan-big has joined #linux-rockchip
<indy>
wadim_, with openocd i'm loosing control in many cases, when soc executes kernel (beaglebone black for example)
<indy>
wadim_, trace32 has diag command, what it prints?
<indy>
jacob_, what you wrote above is rk3288 generic or is it for miqi?
nighty has joined #linux-rockchip
paulk-nyan-big has quit [Quit: Leaving]
<indy>
stdint, what is name of module needed to get emmc, i have loaded dw_mmc but i don't see internal emmc
<stdint>
indy, have you configured it in dts?
<indy>
i use upstream vanilla kernel (4.8-rc4), using rk3288-miqi.dtb
<indy>
but ending in dracut shell (using fedora rawhide)
<wadim_>
TRM says PMU0 is at 0xFFBB1000. All registers are wrong
<indy>
which trm?
<wadim_>
the rk3288 reference manual
<indy>
wadim_, any link?
<indy>
wadim_, you can access debug registers in 3 ways - co-processor, memory mapped registers (addresses from TRM) and external debug (trace32,openocd,... via jtag)
<indy>
wadim_, you must use addresses from diag 3411 output for trace32 not those from trm. these addresses you can use in code executed on core
* vagrantc
wonders if either of the two USB ports on the veyron-speedy are also OTG ports or if the OTG port is hidden inside somehwere
<vagrantc>
hard to figure out which of the janky pieces isn't working with rockchip.usb_uart ...
afaerber has joined #linux-rockchip
sunilmohan has joined #linux-rockchip
sunilmohan_ has quit [Ping timeout: 265 seconds]
<mmind00>
vagrantc: on my mickey + jerry one of them comes from the OTG-capable dwc2-controller ... so I'd guess on speedy it will be the same
<mmind00>
vagrantc: i.e. the rk3288 has 3 usb controllers ... 1 ehci used for the camera and 2 dwc2 supplying the two external ports
<vagrantc>
wasn't too confident in the cconnection with the usb serial cable i cut up
<mmind00>
vagrantc: why did you cut up a usb-serial cable? Or maybe I'm misreading something
<vagrantc>
just a usb cable
* vagrantc
is so used to typing "usb serial adapter" it just happens sometimes
<vagrantc>
mmind00: what voltage signal does it use? 5v? 3.3v? 1.8v?
<mmind00>
vagrantc: every other Rockchip board uses 3.3V and I'm also using 3.3V voltage levels on my jerry
<vagrantc>
figured it was worth asking
* vagrantc
digs around in /sys to see if that will tell me which port is the otg port
<mmind00>
vagrantc: every time I re-setup my usb-uart (once in a while when especially jerry is acting up), I also always get the rx+tx attached the wrong way
<vagrantc>
might need to find a beefier usb cable, the wires on the one i tried are so thin, could easily just be bad connections
<mmind00>
vagrantc: that as well happens to me every time ... trying the wrong one first
<vagrantc>
so, the matrix of ways this can go wrong has many dimensions :)
<mmind00>
vagrantc: if the rockchip.usb_uart option is enabled, attaching usb devices to that port won't work anymore, so you can just try with an usb stick :-)
<vagrantc>
mmind00: you just add that option, or do you have to do something like =1 on the commandline?
<vagrantc>
ah, boot with the option enabled, and then see which ports are no longer working?
<mmind00>
vagrantc: I always have rockchip.usb_uart=y, but I think that isn't actually necessary
<vagrantc>
mmind00: which ttyS does it typically seem to use? ttyS2 ?
<mmind00>
vagrantc: correct
<vagrantc>
thanks for the debugging hints
<vagrantc>
shouldn't be harmful to a usb device plugged into it?
<mmind00>
vagrantc: I don't think so ... at least I hadn't any problems yet when attaching a device after forgetting to disable the usbuart again ;-)
<vagrantc>
ok, port identified...
<vagrantc>
on variable down...
<vagrantc>
one
<vagrantc>
in theory, this is a really awesome feature :)
<mmind00>
vagrantc: :-)
gb_master has joined #linux-rockchip
gb_master has quit [Remote host closed the connection]
paulk-collins has quit [Ping timeout: 240 seconds]
<vagrantc>
wow, well, i've not got a stable enough connection to usefully use it yet, but probably some loose wire was working well enough to repeatedly accidenally send a sysreq request
<vagrantc>
wahoo, boatloads of gibberish
<mmind00>
vagrantc: just to make sure ... you have a regular usb cable plugged into speedy, cut open the other side and attached GND + white + greed wires to a uart (converter) that is then connected to your host side, right?
<vagrantc>
mmind00: skipped the ground ... but otherwise, yes ... though the connections are so loose, it's pretty tenuous
<vagrantc>
this is when i invoke freinds with soldering skills
<vagrantc>
but at least i know it's working now, and how to get it to work
<mmind00>
vagrantc: hehe ... I can relate to that issue :-) ... for my cable I used a connector that doesn't require soldering and provides me with a standard 0.1inch spaced connector ... then using jumper wires to connect over to the usb to ttl converter on the other side
<vagrantc>
yes, that sounds much nicer
<vagrantc>
well, my jury-rigging skills must be working out...console!