<naobsd>
the fact is, u-boot can be loaded from NAND, and loaded u-boot cannot access NAND because NAND driver is missing from u-boot code
<naobsd>
if you want to access NAND from u-boot, you have to use RK miniall loader, and u-boot must be configured as "2nd loader"
<naobsd>
"2nd loader" == loader loaded from "uboot" partition from miniall loader
<AstralixNB1>
yes
<AstralixNB1>
this is state of today.
<AstralixNB1>
This is why I never again will buy any rockchip device that has NAND
<naobsd>
if you want to talk about future thing, then I just say "everything is possible if you can everything"
<naobsd>
you can write your own DDR init code, you can write your own NAND access code, you can put them into u-boot and make it everything open
<AstralixNB1>
Ok, the DDR Init code would be a nice thing to do, but the NAND... probably we use NAND as raw device and put ubifs on top
<AstralixNB1>
And ready you are
<naobsd>
but I cannot find any reason that you try to say objection to my explanation about "current state" :(
<AstralixNB1>
Oh, I guess that was just one of our language complications.
<AstralixNB1>
you know that happens from time to time
<AstralixNB1>
we're both non native english speakers...
<AstralixNB1>
I still would love to see uboot on all RK3xxx and I try to find a way for that
<naobsd>
when you're explaining something "the fact in future", please say so
<naobsd>
we basically talk "current" thing
<AstralixNB1>
yes. I said I don't understand why this an that cannot be... in fact I meant, that I do understand why it is, but not why it cannot be.. in future :)
<AstralixNB1>
Yes the reason this might happen is, that german grammar and english grammar and japanese grammer and chinese grammer are different
<naobsd>
I never said it cannot be in future while talking about the fact about current
<naobsd>
I just talk about the topic
<AstralixNB1>
so the way words are arranged creates different message for you as receiver as it was meant from me as sender
<naobsd>
it sounds like
<naobsd>
if I said "LCDC on RK3188 is not supported on mainline yet"
<naobsd>
you understand "LCDC on RK3188 never be supported even in future"? I cannot believe
<AstralixNB1>
no
<AstralixNB1>
I in that case I would have understood, that it is not available right now, but may be these days
<naobsd>
if I talk about "current" thing, it's no more than current thing.
<naobsd>
please don't say "it's not true", please say "it will not be true in future"
<AstralixNB1>
I guess that leads too much into detail
<AstralixNB1>
I said something about not true, as we talked abut the chain of loaders.
<AstralixNB1>
And if you take it serius, the DDR code is already a loader
<AstralixNB1>
+but that doesn't matter as we all have to see it as a binary blob
<naobsd>
"currently" DDR code is not part of u-boot
<naobsd>
it's part of "loader"
<AstralixNB1>
that is not completely correct, as the uboot does have this blob inside and boots without any miniloader
<naobsd>
what you said "it's in u-boot", not "it will be able to implement in u-boot in future"
<AstralixNB1>
I did not flash any kind of miniloader into the boot section of the MMC
<naobsd>
AstralixNB1: no no no no no no no
<naobsd>
AstralixNB1: if you flashed RK32xxx_uboot.bin, it has DDR init blob AND u-boot
<naobsd>
DDR init blob is flashed to eMMC sector#68, and u-boot is flashed to sector#92 or #100 or somewhere (depend on size of DDR init and header value in sector#64)
<naobsd>
it's the fast, it's very clear, you can confirm by reading eMMC sectors
<naobsd>
fast -> fact
<AstralixNB1>
aha! That is one interesting information!
<AstralixNB1>
Now we are at thee details :)
<naobsd>
not now
<naobsd>
it was explained several times here, and written on wiki
<AstralixNB1>
However, it is too late for me to get into that kind of stuff again today...
<naobsd>
and there is source code
<AstralixNB1>
I need to go to bed :)
<naobsd>
please don't say objection for everything I explained
<naobsd>
with evidence
<AstralixNB1>
what is objection?
<naobsd>
<AstralixNB1> that is not completely correct, as the uboot does have this blob inside and boots without any miniloader
<naobsd>
for example.
<AstralixNB1>
used translate, got it
<naobsd>
?
<naobsd>
it's not matter of mis-translation
<AstralixNB1>
the meaning of objection
<naobsd>
and it's not only "once"
<naobsd>
objection == say "no"
<naobsd>
ok?
<AstralixNB1>
The problem was, that RK doesn't do the things like all the other SOC manufacturers do it
<naobsd>
maybe I'm wrong about use of "objection"
<AstralixNB1>
no, objection means that you, at least partly, not follow my arguments
<AstralixNB1>
So you're right
<AstralixNB1>
But that doesn't mean that I am not right too
<AstralixNB1>
However, normally "any" SOC loads a loader code that provides an SRAM image, and the SRAM image inits something, that then again load the rest of the loader
<AstralixNB1>
This is for freescale and others
<naobsd>
if you're right, please point me which file in u-boot has DDR init code for RK
<naobsd>
I'm talking about RK!!!!
<AstralixNB1>
RK now has a crippled DDR init code that is loaded separately from the uboot.
<AstralixNB1>
Yes but talking about Rk doesn't help to get the things right
<naobsd>
and RK load code to SRAM 1st, then init DRAM, then load "big loader" to DRAM, I never say it's wrong!!!!
<AstralixNB1>
You're talkign about the state we have, I just have the opinion, that this state is not good as it is complicated
<naobsd>
no
<AstralixNB1>
So I showed how others do it and how it is usual to do it
<naobsd>
I'm talking about "current" loader because you talked about it!!!
<naobsd>
sigh
<AstralixNB1>
yes, and I told you the the way it works is awefull and not hacker friendly as many many others do it in the original and better way
<naobsd>
<AstralixNB1> that is not completely correct, as the uboot does have this blob inside and boots without any miniloader
<naobsd>
<AstralixNB1> I did not flash any kind of miniloader into the boot section of the MMC
<AstralixNB1>
If we only talk about what we have, we never find a idea how to make it better
<naobsd>
you say these message was not about RK?
<naobsd>
hey
<naobsd>
I can talk about what is good for future
<AstralixNB1>
yes, so I learned that the ddr image is in uboot, but it is not part of uboot, what is totallys different than many other normal uboot solutions take it
<naobsd>
why are you trying to make me nooob?
<AstralixNB1>
no i dont
<naobsd>
why you cannot say "I was wrong"?
<AstralixNB1>
I already told few lines above, that I learned that the DDR init code is not in ubbot
<AstralixNB1>
it is shipped separately wen it is flashed
<AstralixNB1>
äSo I already agreed tzhat I got something new and obviously was wrong before
<naobsd>
why you say "I'm talking about future" "I'm talking about other SoC" when I pointed your misunderstanding about RK?
<AstralixNB1>
And I told you that this misunderstand came from the fact that RK is doing same things totally different as all the others that I read in uboot
<AstralixNB1>
cause I assumed that if 100 other manufactuerrs do it the normal way, RK would do it the same way too
<AstralixNB1>
But I was wrong, if you insist to have this words in this sentence
<naobsd>
ok, RK is wrong
<AstralixNB1>
RK again did something very normal and very easy in a complicated and hidden and uncomfortable way
<naobsd>
and I'm wrong too because I only talk about "current state"
<AstralixNB1>
Hmm, you can see it like this or not... RK isn't too wrong, as this system works.
<AstralixNB1>
You're not wrong as you correctly stated the status quo
<naobsd>
I couldn't understand when you talked about "current state", only something about "future" and/or "standard way on other SoC" can be "right answer" of your talk
<naobsd>
I'm sorry
<AstralixNB1>
AAnd hopefully I am not too wrong as I have these standard procedure running on thousands of systems I developed a few years ago
<naobsd>
I tried to help you
<naobsd>
but I was wrong, sorry.
<_andrew_>
Heh, this is all very confusing... so the firefly has NAND _and_ eMMC?
<naobsd>
I have to eat breakfast, later
<naobsd>
_andrew_: firefly has eMMC only
<naobsd>
later
<AstralixNB1>
OMG (facepalm!!)
<AstralixNB1>
_andrew_ firefly has only eMMC
<AstralixNB1>
and the current uboot we all use on RK SOC does support booting from eMMC as initial bootloader.
<AstralixNB1>
There is no need to use miniroot and other tricks to flash a loader
<AstralixNB1>
The other discussion was something ... ah ... about internal details of uboot and how it starts up the system.
<AstralixNB1>
And the whole thing was about that I was wrong how th current uboot works, as I made assumptions from earlier work I had done.
<AstralixNB1>
And after learning that it works different, I just expressed my unhappiness about this way it is working...
<AstralixNB1>
however... time for bed as it wass 1h ago.. cu later guys.
<AstralixNB1>
_andrew_ just flash the current supplied uboot to firefly and it will work. #
<AstralixNB1>
If you like to try mainline kernel, you need to use an older uboot, 2014.04 as that doesn't have that bug with the MMU init.
<_andrew_>
Currently running: U-Boot 2014.10-RK3288-01-g0933ad2 (Dec 11 2014 - 17:23:34)
<AstralixNB1>
but naobsd posted something about that yesterday, so check the logs
<_andrew_>
It works with old and new u-boot here...
<AstralixNB1>
yep, ther is a 2014.10-xxx-01, I compiled a 2014.10-xx-02 that works fine too but I didn't test mainline with it.
<AstralixNB1>
wwith firefly images or with mainline?
<_andrew_>
Mainline was also working on the older 2.16 version as shipped, maybe that's not _that_ old...
<_andrew_>
linux-next + plus some patches
<AstralixNB1>
Afaik mmind00 told about that there was a bug in early and in some lateer versions. So it could be that you need one out of the middle
<AstralixNB1>
However it looks like you can use any version to start original images but only some to start mainline too
<AstralixNB1>
so if mainline doesn't show up, just exchangte the loader and try again
<_andrew_>
I did have a couple of his for_broken_bootloaders patches
<AstralixNB1>
with eMMC you don't have to format the whole memory every time you replace the loader
<_andrew_>
But I'm not using them with this newer u-boot.
<AstralixNB1>
you have broken patches?
<_andrew_>
I've never formatted the whole thing. Only updated individual partitions...
<_andrew_>
Broken patches?
<AstralixNB1>
with NAND you often had to format the whole thing as the loader was responsible for FTL and ECC too. But eMMC does this internally so you can replace the loader but the ECC/FTL stays thze same
<AstralixNB1>
_andrew_: I did have a couple of his for_broken_bootloaders patches
<naobsd>
_andrew_: if you applied patches for for_broken_bootloaders, you can use (probably)any loader include shipped/prebuilt in sdk
<AstralixNB1>
I assumed you had some code to add some features to the uboot?
<_andrew_>
I'm only doing this on the Firefly, which doesn't have NAND right?
<AstralixNB1>
right. there is no nand
<naobsd>
_andrew_: if you drop those patches, you need to use patched u-boot like as mine
<naobsd>
_andrew_: that's all
<AstralixNB1>
Ah, the thing from mmind00
<_andrew_>
I haven't messed with u-boot, until I just updated it today.
<AstralixNB1>
ok, mmind00 provided a link to a patch that may ship you arund that MMU init problem in the kernel#
<_andrew_>
I was using ARM-decompressor-Flush-tlb-before-swiching-domain-0 and rockchip-enable-timer7-on-rk3288-platforms-for-broke
<_andrew_>
But not now, not sure I needed them before either but they looked useful...
<AstralixNB1>
however as there are several loaders available that work and someone already approved that mainline boots with one of them, just try to find that one.
<AstralixNB1>
I'll check tomoroow
<naobsd>
_andrew_: my u-boot binary has fix for timer7
<_andrew_>
naobsd: Dunno, but I'm not using that patch any more and I haven't noticed any difference.
<AstralixNB1>
yes, _andrew_ just follow naobsd, he leads you through to the right loader
<AstralixNB1>
gnight!
<_andrew_>
Heh, I already have the kernel booting. Even before updating u-boot.
<naobsd>
_andrew_: you said you're using my u-boot, so you don't need patches for mainline kernel
<_andrew_>
Yeah, that's why I dropped those two I mentioned.
<naobsd>
_andrew_: you said you applied pacthes for broken loader, so you could boot mainline kernel before updating u-boot
<_andrew_>
Ah, no I didn't say that.
<naobsd>
_andrew_: mmu patch is not applied in my u-boot yet. but I'm sure linux-next 20141211 or so can boot
zombu2 has joined #linux-rockchip
<naobsd>
<_andrew_> linux-next + plus some patches
<_andrew_>
That certainly seems to be the case.
<naobsd>
<_andrew_> I did have a couple of his for_broken_bootloaders patches
<naobsd>
sorry, my message was not clear
<naobsd>
you need patch to kernel or you need patch to u-boot, not both
<naobsd>
you applied kernel patch before u-boot updating, ok
<naobsd>
you're using patched u-boot and drop kernel patches, ok
<_andrew_>
I'm using your u-boot, you mentioned earlier and a kernel _without_ the MMU and Timer patches.
<naobsd>
sorry, eating breakfast...
<naobsd>
_andrew_: yes, it's same for me too
<naobsd>
I'll apply mmu patch to u-boot anyway
<_andrew_>
I did have to disable cpufreq to avoid kernel oopses. and the console is being spammed with
<_andrew_>
rtc-hym8563 0-0051: no valid clock/calendar values available
<_andrew_>
rtc rtc0: read_time: fail to read
<_andrew_>
But it does boot up into Fedora 20
<_andrew_>
And that's only using the eMMC and no SD card.
<naobsd>
oops? when I tried on firefly beta, it just hanged at 1.4GHz
<naobsd>
I'll try to see what happen on new firefly...
<naobsd>
anyway I think limit max to 1.2GHz will work
<_andrew_>
Is that set in the device tree?
c0d3z3r0 has quit [Ping timeout: 256 seconds]
<AstralixNB1>
everything of what you described above is set in the device tree files.
c0d3z3r0 has joined #linux-rockchip
<_andrew_>
operating-points =
<AstralixNB1>
frequnecies, voltages to the differnt parts of the SOC and speeds of clocks
<_andrew_>
Looks like a set of frequencies and voltages.
<_andrew_>
Hmm
<AstralixNB1>
yes. but as 3.10 ff kernel already has parts of this implemented, you can try to adjust the mainline dts files accordingly
levd has joined #linux-rockchip
<_andrew_>
What's the risk of causing damage if you muck it up?
<AstralixNB1>
yes, I would be carefull about core and DDR voltages
<naobsd>
you may change cpufreq setting under /sys/ (if it's not too late)
<AstralixNB1>
but I haven't read all datasheets so I cannot tell how the DDR will react if it gets more than 1.8V ore 2.3V (not sure about the values)
<_andrew_>
Well, it works with cpufreq disabled for now, so I'll maybe leave it be
<naobsd>
_andrew_: I see, no problem
<AstralixNB1>
Yes, that is what I wanted to say. Just remove the extreme values if unsure or switch off cpufreq.
<naobsd>
I'll leave here soon, later
<AstralixNB1>
Or copy the values from firefly repo
<AstralixNB1>
ok, again, good night
<_andrew_>
Heh, this time, maybe!
<naobsd>
AstralixNB1: if you're really sure there is extreme values in dts in _mainline_, please point it
<naobsd>
we're talking "current" mainline!
nighty-_ has quit [Quit: Disappears in a puff of smoke]
<naobsd>
I have to send firefly to ganbold, bye
<_andrew_>
Bye
naobsd has quit [Quit: Page closed]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 240 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 240 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 255 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
cnxsoft has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 258 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 256 seconds]
_andrew_ has quit [Quit: I'll be back]
levd has quit [Quit: levd]
Astralix1 has joined #linux-rockchip
Astralix has quit [Ping timeout: 250 seconds]
AstralixNB has joined #linux-rockchip
AstralixNB1 has quit [Ping timeout: 250 seconds]
luke-jr_ is now known as Luke-Jr
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-rockchip
akaizen has quit [Ping timeout: 250 seconds]
akaizen has joined #linux-rockchip
akaizen_ has joined #linux-rockchip
akaizen has quit [Read error: Connection reset by peer]
naobsd has joined #linux-rockchip
FreezingCold has quit [Quit: Out]
FreezingCold has joined #linux-rockchip
RayFlower has joined #linux-rockchip
FreezingCold has quit [Remote host closed the connection]
FreezingCold has joined #linux-rockchip
FreezingCold has quit [Remote host closed the connection]
FreezingCold has joined #linux-rockchip
FreezingCold has quit [Remote host closed the connection]
FreezingCold has joined #linux-rockchip
mrcan has joined #linux-rockchip
mrcan_ has joined #linux-rockchip
mrcan has quit [Ping timeout: 264 seconds]
FreezingCold has quit [Ping timeout: 240 seconds]
RayFlower has quit [Read error: Connection reset by peer]
mrcan_ has quit [Remote host closed the connection]
mrcan__ has joined #linux-rockchip
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
bengal has joined #linux-rockchip
bengal has joined #linux-rockchip
bengal has quit [Changing host]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
mrcan__ is now known as mrcan
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Quit: RayFlower]
gb_master has joined #linux-rockchip
jas-hacks has joined #linux-rockchip
<jas-hacks>
Is is possible to flash RK32800Loader_xxx.bin using linux instead of using the Windows tools?
<naobsd>
jas-hacks: use upgrade_tool
<jas-hacks>
thxs just found it, does uboot get packaged inside the loader bin?
<naobsd>
well
<naobsd>
if you're using loader binary file which uses u-boot (e.g. RK3288Loader_uboot_V2.17.02.bin), yes, u-boot is in the binary
<naobsd>
sorry, I'll away soon
<jas-hacks>
naobsd: np
gb_master has quit [Remote host closed the connection]
akaizen_ has quit [Read error: Connection reset by peer]
jas-hacks has left #linux-rockchip [#linux-rockchip]
akaizen has joined #linux-rockchip
Danukeru has quit [Remote host closed the connection]
Danukeru has joined #linux-rockchip
akaizen has quit [Read error: Connection reset by peer]
richi_ has joined #linux-rockchip
richi_ has quit [Client Quit]
akaizen has joined #linux-rockchip
RayFlower has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
nighty-_ has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
bengal has quit [Ping timeout: 245 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
gb_master has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
gb_master has quit [Remote host closed the connection]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
_andrew_ has joined #linux-rockchip
c0d3z3r0 has quit [Ping timeout: 250 seconds]
c0d3z3r0 has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
ganbold_ has quit [Ping timeout: 264 seconds]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
ganbold_ has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
zombu2 has quit [Read error: Connection reset by peer]
zombu2 has joined #linux-rockchip
npcomp_ has joined #linux-rockchip
cosm_ has joined #linux-rockchip
BorgCuba has joined #linux-rockchip
irsol_ has joined #linux-rockchip
amstan_ has joined #linux-rockchip
_whitelogger_ has joined #linux-rockchip
srao___ has joined #linux-rockchip
mrueg has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
Danukeru has quit [*.net *.split]
<BorgCuba>
is there any difference between the rk3066 (plain) and the "a" variant?
ssvb has joined #linux-rockchip
Luke-Jr has quit [Ping timeout: 265 seconds]
VargaD has quit [*.net *.split]
nighty-_ has quit [*.net *.split]
irsol has joined #linux-rockchip
nighty-_ has joined #linux-rockchip
Luke-Jr has joined #linux-rockchip
markm_ has joined #linux-rockchip
dlezcano_ has joined #linux-rockchip
ojn_ has joined #linux-rockchip
ojn_ has quit [Changing host]
srao___ has quit [Changing host]
srao___ has joined #linux-rockchip
VargaD has joined #linux-rockchip
<karlp>
haven't been able to find out myself, but would also like to know the answer :)
Danukeru has joined #linux-rockchip
<BorgCuba>
karlp, just read your post on linux mainline (for x5 mini)
<karlp>
on a bit of a hiatus at th emoment, sorry,
<karlp>
have you got one too?
<karlp>
I havnet' figured out the control pin for usb power yet, not ethernet, but I traced the pin for power on the lan8720a, needs more time, got busy on other things :)
<BorgCuba>
no x5 mini, but some rk3066 hdmi stick. it reads "Netxeon MK806 V30" on the pcb
<karlp>
yeah, I have a stick or two as well, was going to get the x5 mini up first, then start working on the others.
<karlp>
I don't have factory source for any of them unfortunately
<karlp>
ok, if you'r eon 0.8 release, it's a little different
<karlp>
instead of -f target/stm32f0x.cfg, use -f target/stm32f0x_stlink.cfg
<karlp>
(I think)
<karlp>
oop, sorry, worng eindow...
FreezingCold has joined #linux-rockchip
<BorgCuba>
only cortex-m instead of -a ;-)
<BorgCuba>
I did a board using the f103
JohnDoe_71Rus has joined #linux-rockchip
mmind00 has quit [Quit: No Ping reply in 180 seconds.]
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
<BorgCuba>
btw (dts), where is RK_GPIOn (n=0,1,2...) defined?
zombu2 has joined #linux-rockchip
zombu2 has quit [Changing host]
ganbold_ has joined #linux-rockchip
<rperier>
karlp: ping
<rperier>
If I remember correctly you have better electronics skills than me :)
<rperier>
I have just a simple question (I just want to be sure that what I plan to do is safe)
<rperier>
I plan to use UART0 on the rock. For that I plan to use extension header J8 (on the left on the board), then : pin 1 for GND, pin 13 for UART0_RX and pin 14 for UART0_TX, nothing is wrong ? I am not sure about the right GND I need to use :/