<stdint>
bertje__, no actually, but you may have a try on the dwc2 reset patches
<bertje__>
@stdint thx, we already applied several of those patches to make the OTG port work properly in host mode… is there a patch that specifically deals with gadget issues?
<bertje__>
@stdint the weird thing is that uboot correctly uses the dwc2 as a peripheral, but the kernel does not … no interrupt is firing (uboot uses polling)
<bertje__>
@stdint it also seems like setting dr_mode has no effect, when we try to set it to peripheral
<stdint>
bertje__, I don't think it should happen, anyway, just have a try
<bertje__>
@stdint the OTG port works properly in host mode after we applied the reset patches
<bertje__>
@stdint but not in device mode
<stdint>
have you tried update your kernel
wzyy2_ has joined #linux-rockchip
<bertje__>
@stdint not yet, what mainline version do you recommend we try
<mmind00>
bertje__: I didn't follow that closely, but there seem to be some Synopsys people helping to investigate the issue he has
cini has quit [Ping timeout: 260 seconds]
<bertje__>
@mmind00 wondering where this “couldn’t set device mode” is coming from
<bertje__>
@mmind00 rockchip guys say on their side it is working but then they are not using mainline (?)
<mmind00>
bertje__: nope Rockchip themself are providing mainline patches, but do seem to use a 4.4 derivative as base-kernel for current devices
<bertje__>
@mmind00 i’m using 4.8 … would this be source of this problem?
<mmind00>
bertje__: and the dwc2 has seen quite some changes over the last kernel releases, so there is the possibility that something broke
<bertje__>
@mmind00 broke between 4.4 and 4.8 you mean?
<mmind00>
bertje__: don't know - haven't cared about device mode at all yet ... so maybe in a first step compare the logs from Francesco with your own, to see if its the same issue
cnxsoft has joined #linux-rockchip
tlwoerner has joined #linux-rockchip
tlwoerner has joined #linux-rockchip
<stdint>
anyway, I would confirm that later
<stdint>
bertje__, in my memory it works for me at 4.9
czerny has quit [Quit: Leaving]
wzyy2_ has quit [Ping timeout: 264 seconds]
wzyy2_ has joined #linux-rockchip
beeno has joined #linux-rockchip
lkcl has joined #linux-rockchip
beeno has quit [Ping timeout: 258 seconds]
<LongChair>
stdint: morning
<LongChair>
saw the mpp PR ? :)
beeno has joined #linux-rockchip
IgorPec has joined #linux-rockchip
<bertje__>
@stdint what board and chipset are you using and what .dts file?
<stdint>
firefly release
<lkcl>
stdint: hmmm... iinteresting. ok so i have the firefly booting again (4.9rc1 but that's ok)
<stdint>
lkcl, does the kernel I sent you not work?
<lkcl>
what i'd done is modify the u-boot sdram base frequency down to 200mhz in order to get my board booting
<lkcl>
stdint, one sec: the kernel's not the problem
<lkcl>
stdint: so, what i've established is: if you modify the sdram initial frequency to below 300mhz, neither my board *NOR* firefly will boot from external MicroSD.
<stdint>
it would causing a huge performance problem
<lkcl>
stdint: i'm not concerned about performance, i'm concerned (a) about power consumption and (b) actually booting :)
<lkcl>
sdram_params->base.ddr_freq = 290000000;
<lkcl>
if ((sdram_params->base.dramtype == DDR3 &&
<lkcl>
followed by USB-upload of u-boot, then that *does* work
<lkcl>
as long as the ddr_freq is set to around 280mhz or less
<lkcl>
BUT
<lkcl>
if i set even to 300mhz, i get this:
<lkcl>
Col detect error
<lkcl>
DRAM init failed!
<lkcl>
which, clearly, is bad.
<lkcl>
and indicates that the DDR3 RAM isn't stable.
<lkcl>
stdint: sooo... about the only thing left i can try at this point is to put on different lower-spec'd RAM ICs. lower top speed (800mhz, 1033mhz) and/or lower capacity.
<lkcl>
*sigh*
lkcl has quit [Remote host closed the connection]
stdint has quit [Ping timeout: 246 seconds]
lkcl has joined #linux-rockchip
stdint has joined #linux-rockchip
IgorPec has joined #linux-rockchip
<LongChair>
stdint : i also had another question regarding the RAM performance on tinker. Looks like when phh tested ram throughtput on his RH3288 device, he woudl have something like 1.1G/s, when tinker would have like 840M/s. According to you would that also be a clocking frequency issue or just that the Tinker RAM chip are crappy ?
<stdint>
none of them
<stdint>
I would suggest you having a try on gstreamer
<LongChair>
what would explain then memory bandwith differences ?
<LongChair>
and where do i get the latest gstreamer ?
wadim_ has joined #linux-rockchip
wzyy2_ has quit [Ping timeout: 246 seconds]
wzyy2 has joined #linux-rockchip
lkcl has quit [Ping timeout: 260 seconds]
mrjay has joined #linux-rockchip
<mrjay>
bertje__: just to confirm usb otg bug on rk3066
mrjay has quit [Client Quit]
<stdint>
LongChair, well at github
paulk-collins has joined #linux-rockchip
<LongWork>
stdint: i'll try to build gstreamer and check it
<LongWork>
still the memory performance difference is not related to gstreamer
<stdint>
yes, but I wonder whether you configure the kernel or u-boot properly
<stdint>
if you don't use the gstreamer to feed back the performance but using the ffmpeg
<stdint>
it would be hard to comparing
<LongWork>
i will try to get gst built in my debian
<LongWork>
i suppose there is no package already built ?
<stdint>
there is
<stdint>
but I am not sure about whether the latest is uploaded
<stdint>
I could send you one if you want
<stdint>
also the mpp
matthias_bgg has joined #linux-rockchip
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 268 seconds]
cnxsoft1 is now known as cnxsoft
lkcl has joined #linux-rockchip
bbelos has quit [Ping timeout: 240 seconds]
bbelos has joined #linux-rockchip
<LongWork>
sure
<LongWork>
a package would be nice
LongWork has quit [Quit: LongWork]
LongWork has joined #linux-rockchip
nighty has quit [Quit: Disappears in a puff of smoke]
wzyy2 has quit [Ping timeout: 240 seconds]
<lkcl>
stdint: i know what the problem is. i went to an 8-layer 1.2mm PCB, from a 6 layer *1.6* mm design. the impedance *HALVED* from 90 ohms to 50 ohms and that's more than enough to stop the DDR3 lines from working.
scelestic has quit [Ping timeout: 240 seconds]
<paulk-collins>
oh boy, I wouldn't want to be EE
<lkcl>
paulk-collins: :)
<lkcl>
i never said i was! don't tell no-one, paul.. :)
<paulk-collins>
haha
<paulk-collins>
(it's actually my course of studies)
<lkcl>
ah! then i seeerriously need your help
<paulk-collins>
I didn't say I'm good either ;)
<lkcl>
haha
<paulk-collins>
but yeah, I can try
<lkcl>
i have to make an effort to rescue this board
<lkcl>
at around 280mhz the DDR3 RAM can still run.
<lkcl>
push it to 300mhz and it falls over
<paulk-collins>
so bad impedance adaptation/matching?
<lkcl>
impedance of all the DDR3 tracks is 50 ohms, 3.5mil wide
<lkcl>
*sigh* yeahhh
<paulk-collins>
can't the dram controller be configured to match that specific impedance?
<lkcl>
this is all in PADS btw. by changing the dielectric constant to 2.2 i can get it up to 70 ohms
<lkcl>
i have _no_ idea!
<lkcl>
it didn't occur to me to even find out if that was possible
<paulk-collins>
yeah I think it's usually how it's done
<lkcl>
huh.
<paulk-collins>
not sure though, I just have vague memories of it
<lkcl>
hmmm... ok... sooo... let's take a look in the dram source for rockchip u-boot
<paulk-collins>
lkcl, some reading regarding allwinner: v
<lkcl>
that looks like it's the right sort of thing to mess with
<paulk-collins>
indeed
<lkcl>
no idea what the fuck i'm doing but hey
scelestic has joined #linux-rockchip
<paulk-collins>
:)
<lkcl>
ok apparently it's noodles-eating time. thanks paul. i have a line of enquiry that doesn't involve throwing out $1k's worth of hardware.
<paulk-collins>
neat!
<paulk-collins>
happy noodles-eating
<ayaka>
what do I miss?
<lkcl>
ayaka: lol - a bowl of noodles with coriander and bean-sprouts for one...
nighty has joined #linux-rockchip
<lkcl>
... oh and paul noted that it *might* be possible to recover this first board by changing the zqcr values in "arch/arm/mach-rockchip/rk3288/sdram_rk3288.c"
<ayaka>
I can't help much about the hardware
<ayaka>
that is why I suggest you coming here first
<ayaka>
but it would be fine to find out problem
<lkcl>
yeahh i know... but there are certain unavoidable hardware constraints that, in retrospect, i would still have to do the exact same thing anyway.
<lkcl>
we need to use FR4 (it's lower-cost), the PCB _has_ to be 1.2mm, and it _has_ to be 8 layer
<lkcl>
given that those constraints could not change even if i visited RC's HQ first...
<ayaka>
anyway a noodles with coriander looks like a Hakka style food in Taiwan
<lkcl>
ayaka: haha it was just something my partner marie made, we are in a reaaaally small room 4m x 4.5m nominally for students
<lkcl>
when i move back here next month it will be to a 3-room apartment for (gosh, shock) a whole $USD 400 (!!)
<lkcl>
sooo let's see if there's a TRM page for the memory controller...
<lkcl>
off of rockchip.fr...
<ayaka>
I am not sure, but if you have any problems just ask
<lkcl>
ayaka: i could really really do with some help picking the right settings for ZQ
afaerber has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
bertje__ has joined #linux-rockchip
paulk-collins has quit [Quit: Leaving]
ganbold has quit [Quit: This computer has gone to sleep]
<bertje__>
so we got the otg port on rk3288 working in device role
<bertje__>
we had to go to 4.10 mainline (we were on 4.8.1 mainline)
<bertje__>
on the firefly reload board it’s also important to disable the regulator for the OTG VBUS otherwise it won’t work in device mode
<bertje__>
the OTG_ID pin is pulled high on the firefly reload core module which means it is always in device mode, unless host mode has been set via dr_mode
twink0r has quit [Ping timeout: 268 seconds]
Ancient has quit [Ping timeout: 240 seconds]
twink0r has joined #linux-rockchip
Ancient has joined #linux-rockchip
sunxi_fan has quit [Ping timeout: 256 seconds]
sunxi_fan has joined #linux-rockchip
nighty has quit [Remote host closed the connection]