<sjoerd>
amstan: that was on a rock 2, but mmind00 gave me the winning tip that i simply missed turning on dma support for the mmc controller
markm has joined #linux-rockchip
VargaD has quit [Ping timeout: 264 seconds]
VargaD has joined #linux-rockchip
sunilmohan has quit [Ping timeout: 246 seconds]
sunilmohan has joined #linux-rockchip
gb_master has quit [Remote host closed the connection]
nashpa has quit [Ping timeout: 252 seconds]
nashpa has joined #linux-rockchip
<mmind00>
sjoerd: btw. for wifi on the firefly Michael Trimarchi did some experiments ... "[RFC PATCH] ARM: dts: rockchip: Add wifi support for firefly" (and my followups)
ssvb has joined #linux-rockchip
sunilmohan has quit [Ping timeout: 252 seconds]
sunilmohan has joined #linux-rockchip
ssvb has quit [Ping timeout: 246 seconds]
<sjoerd>
mmind00: hmmmm
<mmind00>
sjoerd: but that actually looks quite similar to what you have in your tree
<sjoerd>
it does doesn't it
<sjoerd>
but i don't see any fundamental difference apart from havinga subnode for the broadcom to setup its host wake interrupt
<sjoerd>
i already have the vmcc supply at vcc_io which is 3.3v so if i understaqnd things right the 'min 2v issue" shouldn't occur
<sjoerd>
or did i mix up vmcc and vqmmc
<sjoerd>
hmm cap-sd-highspeed; might make a diference
<mmind00>
sjoerd: no ... the firefly dts actually mixed them up
<mmind00>
sjoerd: vqmmc is the io-voltage ... so the 1.8V in most wifi cases
<mmind00>
sjoerd: while vmmc is the one supplying the card (the vbat_wl)
<sjoerd>
right and the wifi-supply in the io-domain should match vqmmc ofcourse so that's correct in my sbits as well
<mmind00>
yep
<mmind00>
btw. did you already tell me how far the wifi module actually gets?
<mmind00>
sjoerd: aka with the drive strength at its default value, my Minnie + Jerry also do detect the card, but are not able to connect to a network ... with the 8ma both can connect and Minnie can actually transfer stuff
<sjoerd>
not sure why it's trying the minimum frequency and the one i specified btw
<sjoerd>
mmind00: ooi do you know if it's possible to make these board not try booting from emmc first? (e.g. force SD first)
<mmind00>
sjoerd: only by not having a valid boot block on the emmc, I think
<mmind00>
the boot diagram in the trm looks quite strict
<sjoerd>
right, was hoping you know something not in the public documentation :)
<sjoerd>
that's a bit scary if you put a valid boot block on the emmc but not a functional one
<mmind00>
I wouldn't call that public documentation :-D ... in the worst case, I think the "normal" way is to short two pins of the flash/emmc to make the bootsequence use the next option
<sjoerd>
hehe
JohnDoe_71Rus has quit [Ping timeout: 255 seconds]
<sjoerd>
well that or maskrom mode is a bit more official
JohnDoe_71Rus has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
<c0d3z3r0>
hi guys, is there any way to use u-boot fatload on rk3188?
<mmind00>
sjoerd: I think that actually was a way to reach maskrom :-)
<mmind00>
never tried any of this yet ... on the boards the present bootloader was so far at least adequate for what I was doing
ssvb has joined #linux-rockchip
<sjoerd>
mmind00: heh yeah the firefly documentation says to short certain testpoints to get there
<sjoerd>
the rockchip ones seem quite special doubly so on emmc
<sjoerd>
as it looks like it doens't format it normally but pretends it's like nand
<mmind00>
sjoerd: yep, not sure how Simon Glass approaches this with his uboot work, but I guess the bootloader location is probably fixed, so you could also use a regular partition table
<sjoerd>
you can
<sjoerd>
but that doesn't help me to say tftp boot
<sjoerd>
or load the kernel from somethng else
<sjoerd>
i'll have a poke at sjg's u-boot patces
<mmind00>
yeah ... he does already provide firefly support, so the Rock2 should not create to much problems
<mmind00>
although network (dwmac or ethernet via usb adapter) seems to be missing still
<mmind00>
sjoerd: if I remember correctly you asked about where the mac address comes from ... I was just looking at some bcm nvram files, and it seems this is one possible source (there is a macaddr property in there)
<sjoerd>
mmind00: right but that's for the wifi chip
<sjoerd>
mmind00: and yeah no network yet, but dwmac is supported so it just needs to rockchip glue
<sjoerd>
oh the pmic is on the som, not on the baseboard
<sjoerd>
Oh, nice, on the som board there are 2 test pads, one carrying the FALSH0_DQS/EMMC_CLKO and one hooked up to ground
<sjoerd>
with a comment saying "Reserve PAD for Update."
<sjoerd>
guess shorting the clock signal should do the trick for moving past the emmc
<mmind00>
sjoerd: yep, I think they have this on most dev-boards nowadays ... the wifi remark was not meant for the current issue, but just because you asked yesterday or so and I just stumbled over it ;-)
dlezcano has quit [Ping timeout: 240 seconds]
<sjoerd>
yup shorting those makes the emmc unhappy
<sjoerd>
time to play with u-boot from SD then
pietrushnic`away has joined #linux-rockchip
pietrushnic`away is now known as pietrushnic
sunilmohan has quit [Ping timeout: 244 seconds]
Bludot has quit [Quit: Connection closed for inactivity]