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
<dsont>
hey guys
<dsont>
I get this error
<dsont>
im trying to flash a update.img onto rk3188
<dsont>
on ubuntu 14.10
<dsont>
./upgrade_tool
<dsont>
and it doesn't see my devices
<dsont>
any thoughts?
<dsont>
I'm installing windows XP in a vm
npcomp has joined #linux-rockchip
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
Bludot has joined #linux-rockchip
RayFlower_ has quit [Read error: Connection reset by peer]
ssvb has joined #linux-rockchip
RayFlower_ has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 255 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 250 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
levd1 has quit [Remote host closed the connection]
levd has joined #linux-rockchip
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 245 seconds]
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
<karlp>
if upgrade tool doesn't see your devices, I would suspect udev rules
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
cnxsoft has joined #linux-rockchip
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
<naobsd>
Astralix: u-boot can be flashed to NAND, 3.0 kernel booted from u-boot on NAND can use NAND
<naobsd>
dsont: try sudo upgrade_tool. if it works, you need to add some line to udev rule
<naobsd>
Astralix: about Boot Sequence page on wiki, do you have any evidence about "rk31xxnand_ko.ko.3.0.8+, rk31xxnand_ko.ko.3.0.36+" ?
<naobsd>
Astralix: do you have any evidence about "there are these kernel modules: rknand_ko.ko.3.0.8+ and rknand_ko.ko.3.0.36+. These kernel modules are SoC generic." too?
levd has quit [Remote host closed the connection]
levd has joined #linux-rockchip
markm_ has joined #linux-rockchip
<naobsd>
Astralix: and please point the code which does "The Linux kernel modified by RockChip will first try to load a SoC and Linux kernel version generic rknand_ko.ko module. If this fails it tries next the generic module name with the kernel version appended: rknand_ko.ko.<kVer>."
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
<naobsd>
dsont: if you have SDK configured for your Fenix and/or you have complete image for it, I think you don't need to make backup
<naobsd>
dsont: if you really need same images flashed to your device, you may ask it to your friends
<naobsd>
dsont: anyway, trying "rooting" is absolutely not needed to try new firmware on rockchip device. it's only for noobs.
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
<ganbold_>
naobsd: what is the memory start address of rk3288 (without counting u-boot load address)? do you have any idea?
<naobsd>
physical start address? it should be 0x0
<naobsd>
ganbold_: see Adding bank:0000000000000000(0000000080000000) line in boot message
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
Tony__ has joined #linux-rockchip
dsont has quit [Read error: Connection reset by peer]
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
ferric has quit [Ping timeout: 256 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 244 seconds]
RayFlower_ has quit [Quit: RayFlower_]
cnxsoft1 has joined #linux-rockchip
levd1 has quit [Remote host closed the connection]
levd has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 264 seconds]
Danukeru has joined #linux-rockchip
Danukeru has quit [Client Quit]
Tony__ has quit [Ping timeout: 264 seconds]
Danukeru has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 250 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 244 seconds]
Bludot has quit [Quit: Connection closed for inactivity]
levd has quit [Remote host closed the connection]
levd has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 245 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 244 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 265 seconds]
<ganbold_>
naobsd: http://pastebin.ca/2897854 maybe need to know what gpio pins give power to usb, I hope rk3288 gpio is same as rk3188
else- has quit [Ping timeout: 255 seconds]
<naobsd>
ganbold_: about vbus, gpio0 14 for host, gpio0 12 for otg, need to be high
<naobsd>
ganbold_: and uhub on host root uhub, gpio8 3 reset pin need to be high
<naobsd>
I'm not sure about grf for rk3288
<naobsd>
grf is at 0xff770000
<naobsd>
gpio0@ff750000 gpio8@ff7f0000
<ganbold_>
ok, I will check those later
mcan is now known as mrcan
<naobsd>
ganbold_: ehci is not used on firefly
<naobsd>
btw uhub3 is found, pin config seems ok
mrcan is now known as mcan
<ganbold_>
so ehci is not needed then?
<ganbold_>
what are host1, host2 ports?
AstralixNB1 has quit [Ping timeout: 250 seconds]
* ganbold_
bbl, have to get kids from school
<naobsd>
physical host ports on firefly is 4-port uhub ports on 2nd dwcotg
Astralix1 has quit [Ping timeout: 250 seconds]
mcan is now known as mrcan
mrcan is now known as mcan
levd has quit [Remote host closed the connection]
levd has joined #linux-rockchip
levd has quit [Ping timeout: 244 seconds]
levd has joined #linux-rockchip
selfbg has joined #linux-rockchip
Astralix has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
AstralixNB has quit [Client Quit]
Astralix has quit [Read error: Connection reset by peer]
Astralix has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
AstralixNB has quit [Read error: Connection reset by peer]
Astralix has quit [Write error: Connection reset by peer]
Astralix has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
levd1 has joined #linux-rockchip
<Astralix>
naobsd: u-boot: I just cloned your git and tried u-boot on RK3188 (rock) to get the new Android 4.4.4 started. I see that there is a description thatt states that u-boot-rk3188-miniall.bin can use NAND.
levd has quit [Ping timeout: 244 seconds]
<Astralix>
This was new to me but at the first run, it didn't work. The resulting Loader just inits DDR but does not start USB anymore. I need to bring the rockk into MASK-ROM mode later this day.
<Astralix>
naobsd: I assume that you need separate Loaders and rknand.ko as I got them as separate files from the Loader developer of RK.
<Astralix>
I think he would not send me extra files if they are obsolete
<Astralix>
And with every version of Loader.bin he sends me a different set of rknand.ko, that abviously differ in size
<Astralix>
nabsd, I did read it, but yesterday it was too late for me to read it again
<naobsd>
Astralix: RKxxxxLoader_miniall.bin and uboot.bin can be made by make rk30xx
<Astralix>
can we please first go through the list of open questions, then go into the details
<naobsd>
Astralix: this is not new, it's not my change. it's provided as RK u-boot
<naobsd>
now I'm talking about NAND support on kernel loaded from u-boot
<Astralix>
Yes, may be. Something here wnet wrong and the u-boot doesn't start USB and it doesn't detect NAND. It just loads DDR
<Astralix>
However, I will check that later
<naobsd>
it's supported, it works, confirmed on RRs
<naobsd>
"u-boot doesn't start USB" what are you talking about? I'm talking about NAND
<Astralix>
naobsd, I think so, I believe you, it was late, I may have missed a step, so I check again LATER
<naobsd>
USB is not necessary to use NAND
<naobsd>
please give me detail if it doesn't work on your environment
<Astralix>
If you change Loader to u-boot on nand you need to areas nand and reflash all partitons
<Astralix>
if you cannot access usb HOW DO YOU GET PARTITIONS ON NAND
<Astralix>
can you please stop just throwing sentences at me?
<Astralix>
There was a question about uboot from a guy, who I cannot tell how much knowledge he has
<Astralix>
Would you advise a guy to just flash a self build uboot to a stick of which you cannot see if he can be brought to MASK ROM?
<naobsd>
if you flashed miniall.bin as loader, miniall loader enables OTG, then you can flash parameter and uboot.img
<Astralix>
naobsd: There was a possible newbie why might kill his hardware
<naobsd>
I don't recommend to use u-boot for everyone
<Astralix>
I was not shure if he can handle uboot and with a loader installed there is no need to use uboot
<Astralix>
So I DIND'T TOO
<naobsd>
but "u-boot doesn't support NAND" is not true at all
<naobsd>
again
<Astralix>
At that time I was NOT SURE if it supports NAND or not, so I strongly recommended him NOT to use uboot
<naobsd>
if you flashed miniall.bin as loader, miniall loader(this is not u-boot) enables OTG, then you can flash parameter and uboot.img(this is u-boot)
<Astralix>
Cant you read this: I WAS NOT SURE!
<Astralix>
Again: AT THAT TIME I WAS NOT SURE
<Astralix>
I got it!
<Astralix>
It can use NAND
<Astralix>
Again: Here it doesn't work
<Astralix>
Again: Yes I might have made a mistake
<Astralix>
Who cares!
<naobsd>
if you flashed u-boot(uboot.img) after miniall flashed, u-boot may not enable OTG by some reason, but you already have u-boot on NAND
<Astralix>
So If you like to support, the support, but actually you are just keeping me from beeing productive
<naobsd>
what I said is give me detail
<Astralix>
I dont flash uboot
<Astralix>
I won't flash your uboot
<Astralix>
I have latest greatest Loader directly from RK
<Astralix>
It works like a charm
<Astralix>
Again: I don't have time, I DO IT LATER
<naobsd>
why you cannot accept explanation from others?
<naobsd>
I just explained about u-boot
<Astralix>
(09:26:33) Astralix: However, I will check that later
<Astralix>
(09:27:12) Astralix: naobsd, I think so, I believe you, it was late, I may have missed a step, so I check again LATER
<naobsd>
I just explained.
<naobsd>
I never said "do it now"
<Astralix>
As you like repeating me, I did it for you
Astralix has left #linux-rockchip [#linux-rockchip]
<naobsd>
you can re-read log later
<naobsd>
but I may not able to explain later
<naobsd>
so I explained ust now
<naobsd>
very strange
<naobsd>
everyone in here know "don't expect reply soon"
<naobsd>
I just explained info about u-boot for RK
<naobsd>
you can read/try it later
AstralixNB has quit [Read error: Connection reset by peer]
Astralix has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
<naobsd>
Astralix: please read log again carefully _later_. I just explained about u-boot and miniall loader. I never force to do it immediately. I never force to flash u-boot for newbie
<naobsd>
I just explained what I know, as usual
<naobsd>
I need more detail to solve problem, as usual
<naobsd>
that's all
<AstralixNB>
I just did one single trail
<AstralixNB>
And it didn't work, that is no problem and I will find the issue
<AstralixNB>
I never stated that ubot in general doesn't work
<ganbold_>
naobsd: ok, so I will remove ehci from dts for now
<AstralixNB>
I just said that it doesn't work yesterday night on one board
<naobsd>
I never said "you said u-boot doesn't work in general"
<AstralixNB>
And it is too early to help me, as I didn't really tried to check what has happened
<naobsd>
why I wanted detail is to help you, but I never said "do it immediately".
<naobsd>
if saying "give me detail" means "do it now", I cannot speak
<naobsd>
maybe I should add _later_ for every my words...
<naobsd>
ganbold_: I'm not sure that there is any rk3288 board which uses ehci
<naobsd>
ganbold_: personally I want to try, but there is no port/pins on firefly
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 256 seconds]
mcan is now known as mrcan
mrcan is now known as mcan
<AstralixNB>
different thing, naobsd... If I have some little fixes to the firefly Android and kernel, where to put them?
<ganbold_>
naobsd: maybe u-boot can give power to usb
<AstralixNB>
gangbold_ what is the specific problem to EHCI?
<ganbold_>
as naobsd said ehci is not hooked to physical port in firefly
<AstralixNB>
Ok, so it is not driver related
<AstralixNB>
naobsd, you collected these different version of uboot, but you did not unify them, correct?
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 256 seconds]
apritzel has joined #linux-rockchip
hipboi_ has quit [Ping timeout: 256 seconds]
levd has joined #linux-rockchip
<ganbold_>
naobsd: what is connected to uhub?
levd1 has quit [Ping timeout: 244 seconds]
hipboi_ has joined #linux-rockchip
levd1 has joined #linux-rockchip
cnxsoft1 has quit [Ping timeout: 256 seconds]
levd has quit [Ping timeout: 264 seconds]
nighty^ has joined #linux-rockchip
<AstralixNB>
naobsd, the sd-version of u-boot, does it work exactly like "eMMC"?
cnxsoft has joined #linux-rockchip
dugz has joined #linux-rockchip
<ganbold_>
Root mount waiting for: usbus1
<ganbold_>
ugen1.3: <USB 2.0> at usbus1
<ganbold_>
umass0: <USB 2.0 Flash Disk, class 0/0, rev 2.00/1.00, addr 3> on usbus1
<ganbold_>
umass0:0:0: Attached to scbus0
<ganbold_>
umass0: SCSI over Bulk-Only; quirks = 0x4100
<ganbold_>
Trying to mount root from ufs:/dev/da0 []...
<ganbold_>
mountroot: waiting for device /dev/da0 ...
<ganbold_>
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
<ganbold_>
da0: <USB 2.0 Flash Disk 5.00> Removable Direct Access SCSI-2 device
<ganbold_>
warning: no time-of-day clock registered, system time will not be set accurately
<ganbold_>
now need to make uart driver work, it is somehow not working
<naobsd>
well
wildea01 has joined #linux-rockchip
<naobsd>
AstralixNB: if you want to send feedback to firefly, post patch to web forum or send email
<ganbold_>
usb_alloc_device: setting up USB template failed maybe the USB template module has not been loaded
<ganbold_>
ugen0.2: <Unknown> at usbus0 (disconnected)
<ganbold_>
interesting, what is attached to ugen0.2?
<AstralixNB>
I asked about the procedure in their forum.
<naobsd>
AstralixNB: but I don't think "add support for rk3188 to 3.10 kernel" is useful for them
<AstralixNB>
I am not sure if I like to regularly update 10 different repos
levd has joined #linux-rockchip
<naobsd>
AstralixNB: u-boot rk30/31 is dirty, it needs more work to unify rk30/rk31 branches
<AstralixNB>
Yes, I saw that when crawling through the code
<naobsd>
AstralixNB: u-boot rk30/31 and rk32 are based on different u-boot version, more difficult to unify
<naobsd>
ganbold_: which uhub? "naobsd: what is connected to uhub?"
<AstralixNB>
I think there is an issue with the kernel compression format
<naobsd>
AstralixNB: I don't know how u-boot "eMMC" version work, what you expect?
<AstralixNB>
The 4.4.4 kernel for firefly uses a different compression than the older versions. So the Loader kannot find an uncompress the kernel. but I need to reproduce and verify this first.
<ganbold_>
uhub2: <vendor 0x1a40 USB 2.0 Hub MTT, class 9/0, rev 2.00/1.00, addr 2> on usbus1
<ganbold_>
uhub2: MTT enabled
<AstralixNB>
naobsd, If I flash u-boot to SD, it should behave like an eMMC... Can I use upgrade_tool to write partitions?
<naobsd>
ganbold_: I think linux dwcotg driver has some rk3288 specific code
levd1 has quit [Ping timeout: 265 seconds]
<ganbold_>
naobsd: anyhow I can see now usb stick, so now have to make uart work
<ganbold_>
naobsd: it mounts and it goes to userland, where simple console driver is not working there
<naobsd>
AstralixNB: as far as I know u-boot for rk doesn't uncompress kernel. linux kernel compression add self uncompression code to kernel binary
<naobsd>
AstralixNB: I know u-boot support some (un)compress algorithm in general context
<AstralixNB>
We'll see, I run a second test with u-boot now
<AstralixNB>
However, you asked several questions this night
<AstralixNB>
Did you get the info about different versions of Loader and rknand.ko?
<AstralixNB>
RK is very restrictive about nand algo information, but they gave me lot of latest nand drivers.
<AstralixNB>
So even they never exactly told me that RK30 and RK31 needs different Loaders and kernel modules, I assume it is so, as they are delivered as different files every time.
<AstralixNB>
For the loading mechanism
<naobsd>
AstralixNB: well, basically, access to flash media via OTG is routed to boot media, if bootmedia is NAND(loader is loaded from NAND), access via OTG is to NAND, if bootmedia is eMMC, access via OTG is to eMMC, if bootmedia is SD, access via OTG is to SD, and so on
<naobsd>
AstralixNB: but SD is unstable on my RR, I don't use upgrade_tool to update images on SD
<AstralixNB>
Ok... I try NAND first
<AstralixNB>
I can see that the uboot just does "make rk30xx" but produces code that is named "RK3188Loader..."
<AstralixNB>
That is a mess
<naobsd>
because it's configured for RK3188
<naobsd>
if you use branch for rk3066, it will be RK3066...
<AstralixNB>
yes, I thought that
<naobsd>
AstralixNB: about rknand.ko, I don't have rk31xxnand_... and any ver2 rknand_ko.ko.<kVer>
<naobsd>
AstralixNB: all I have(found on net) is rk30xxnand_ko.ko.(kver) for rk3066 and rk3188
<AstralixNB>
Wait
<naobsd>
AstralixNB: same for both ver1 and ver2
<AstralixNB>
I had already detailed that in a discussion with someone who was writing wiki
<AstralixNB>
There are two different Loaders, one for 30xx and one for 31xx
<naobsd>
what you explained to him is now written on wiki, so I'm asking you about it
<AstralixNB>
Then there are different kernel modules for each kernel version
<naobsd>
I'm not talking about loader
<naobsd>
I know loader is different for rk3066 and for rk3188
<AstralixNB>
yes, but the modules differ for kernel version, and they differ for loader 1.x or Loader 2.x
<naobsd>
and I only have common rk30xxnand... for both rk3066 and rk3188 and for both ver1 and ver2
<AstralixNB>
but not for Loader RK31xx or 30xx
<naobsd>
I know different modules are available for different kernel version (3.0.8 and 3.0.36) too
<naobsd>
what I'm asking is
<AstralixNB>
I have strong doubts about using same rknand.ko written for loader 1.x to be used on loader 2.x and vice versa
<naobsd>
I cannot find rk31xxnand_ko.ko.(kver) for rk3188
<naobsd>
I cannot find rknand_ko.ko.(kver) for ver2
<AstralixNB>
I explained that weeks ago
<naobsd>
I _know_ kernel module for loader ver1 and kernel module for loader ver2 are different
<AstralixNB>
With every new Loader version I get new (and different) rknand.ko versions
<naobsd>
it's not what I'm asking
<AstralixNB>
I bet this has a reason, but RK does not add a version to the module
<AstralixNB>
There are no different rknand.ko based on SOC but only on Kernel
<naobsd>
I know there is rk30xxnand_ko.ko.(kver) for _ver2_, not rknand.ko.(kver)
<naobsd>
can you give me rk31xxnand_ko.ko.(kver) for ver1 loader and rknand.ko.(kver) for ver2 loader?
<naobsd>
former must not work on rk3066, later must work on any Rockchip SoC, right? (if kver is matched, of course)
<AstralixNB>
-rw-rw-r-- 1 astralix users 544658 Aug 13 00:14 nand patch v2.5 for rk3066 and 3188.zip
<AstralixNB>
-rw-rw-r-- 1 astralix users 201038 Aug 13 00:14 RK3188Loader(L)_V2.16_erase_all.bin
<naobsd>
for me, rk30xxnand._ko.ko.(kver) for loader ver1 works both rk3066 and rk3188, and rk30xxnand._ko.ko.(kver) for loader ver2 works both rk3066 and rk3188
<AstralixNB>
This is a not so old Loader package I got from RK
<AstralixNB>
As you can see, different Loader per SOC, different kernel module per kernel version
<AstralixNB>
If you now
<naobsd>
sorry, I cannot find rk31xxnand_ko.ko.(kver) and rknand.ko.(kver)
<AstralixNB>
compare these kernel modules to older versions, you see that they difffer a lot in size
<AstralixNB>
there is no rk31xxnand and rk30xxnand. I have seen them in old version 1 Loader combinations, but for Loader 2.x there is only one left
<naobsd>
can you give me rk31xxnand_ko.ko.(kver) for ver1 loader?
<naobsd>
all I know is rk30xxnand_ko.ko.(kver) which can be used for both rk3066 and rk3188
<AstralixNB>
Do you really want me to scan our 500 different images for Tablets to find this file, that I have seen 1.5 Years ago?
<naobsd>
AstralixNB: ah, sorry, no need to read it now
<naobsd>
AstralixNB: please read it later
<naobsd>
AstralixNB: reader who want to use loader ver1 have to find rk31xxnand_ko.ko.(kver)
<naobsd>
AstralixNB: reader who want to use loader ver2 have to find generic rknand.ko.(kver)
<AstralixNB>
This is not, what I exactly wrote him
<naobsd>
I see
<AstralixNB>
But at the time, where these changes where made, three people where writing at the same page
<naobsd>
then, when you have time, can you tell me detail? I'll update wiki
<naobsd>
anyway now I confirmed that's not what you explained, I can delete them
<AstralixNB>
It is probably more easy to understand if we just forget the very old days and tell the simple matrix:
<naobsd>
thank you for your confirmation, sorry for bothering you
<AstralixNB>
no problem. If we can stick to the techniks and do not disassemble words, it is fine for me
<AstralixNB>
As you want the page to be easy to understand, even for newbies, we should keep the simple matrix:
<AstralixNB>
Loader differs per SOC, module differs per kernel version.
<naobsd>
I know simple matrix, 1. use rk30xxnand_ko.ko.(kver) for loader ver1 for loader ver1 device, it works both rk3066 and rk3188
<naobsd>
2. use rk30xxnand_ko.ko.(kver) for loader ver2 for loader ver2 device, it works both rk3066 and rk3188
<AstralixNB>
That is the only issue we might have... RK did not version the rknand file name
<naobsd>
that's all. I can find these 4 modules in rk3188 SDK, don't worry.
<AstralixNB>
So you cannot see if a rk30nand.ko is too old to work reliably with version 2 Loaders
<AstralixNB>
So I would recommend to write a note in the wiki, that the user should try to backup or use Loader and modules of same age.
<naobsd>
yes, it should be labeled clearly "it's for verX!"
<naobsd>
anyway it can be found, it's better than mentioning things which cannot be found quickly
<AstralixNB>
But RK doesn't do this and moreover if you cat /proc/rknand there are several different "modules" of the module that have different versions
<AstralixNB>
This module <-> Loader hassle is mostly a problem if you custom rom building, as these builders often copy boot or system images from one device to a different one.
<AstralixNB>
So for these guys it is important to understand, that it can result in problems
<AstralixNB>
If you build Systems from current SDKs it is not a problem,as the SDK contains the right and matching loader <-> rknand. combination
<naobsd>
I can find modification in android init, but cannot find in linux kernel
<AstralixNB>
Yes, I pick the code for it
<AstralixNB>
But I need to do some official work here now.
<naobsd>
AstralixNB: you picked? what I understand from wiki is modification is done in RK kernel, not your kernel
<naobsd>
AstralixNB: yes, please do your work now
<naobsd>
AstralixNB: sorry for adding _later_ to my questions
<AstralixNB>
:)
<AstralixNB>
I have seen this kernel-version auto-append in many tablet kernels, but I cannto tell you, if this had been added by some OEMs or by RK themselfes.
<AstralixNB>
But we have seen this in different systems from different OEMs
<naobsd>
if it's not generic code, at least not in our kernel repo, it should be explained "it's only available for some specific kernel binary"
<AstralixNB>
I have seen two different approaches to auto-select the modules
<AstralixNB>
one was in initrd script and it fetches the kernel version from uname command.
<AstralixNB>
Then there was a kernel that did this in MTD but only one, as far as I remember.
<AstralixNB>
Later they modified the module loader of the kernel to try the modprobe [name] first, and if it fails it auto-tries [name].[kver]
<naobsd>
AstralixNB: what I have most interest is description on _our_ wiki explains about kernel in _our_ repository
<naobsd>
AstralixNB: description about other kernel should be explained "it's not true for our kernel"
<naobsd>
AstralixNB: so what I want to know is "it's true or not" for _our_ kernel. please tell me pointer for that code _later_
levd has quit [Remote host closed the connection]
<naobsd>
if no one can find it in our kernel repo, I'll mark that description "it's not true for our kernel"
levd has joined #linux-rockchip
<AstralixNB>
ok, i check, if it is available in our kernel too
<AstralixNB>
which one do you refer as our kernel?
<naobsd>
but if it's implemented in very specific file, only name/path of file is enough
<naobsd>
I can check myself if path is very clear
<naobsd>
ganbold_: if you can please post your progress on firefly :)
<naobsd>
ganbold_: it seems really nice!
<ganbold_>
need to get uart work, then it would be full :)
Astralix has quit [Quit: Leaving.]
AstralixNB has quit [Read error: Connection reset by peer]
AstralixNB has joined #linux-rockchip
Astralix has joined #linux-rockchip
<rperier>
hi all, did you test firefly with lastest mainline ? I will port it to meta-rockchip this evening and try to deploy a linux kernel on it to test what works or does not work
<rperier>
and send patches If I find bugs of course
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 264 seconds]
hipboi_ has quit [Ping timeout: 244 seconds]
<AstralixNB>
rperier, has anyone sent a rk3188-radxarock_defconfig and matching dts to mainline till yet?
else- has joined #linux-rockchip
<rperier>
AstralixNB: there are not defconfig yet in mainline for rockchip, afaik. However you can find one in Heiko's repository
<rperier>
this is the one I use in meta-rockchip (modified a bit)
<AstralixNB>
I know that there is one her and one there and a different one here too
<AstralixNB>
I would like to collect a working one and pass it to mainline
dugz has quit [Quit: Tanto longe e gratias nam omne le pisce!]
<AstralixNB>
I am using mmind00 version too, but I have read here about other people trying other things... So I'd like to collect a working version as a starting point.
<mmind00>
AstralixNB: I don't think passing to mainline will work before somebody implements the stdout-path in the dw-serial ... and of course it could only be a generic rockchip_defconfig
<mmind00>
AstralixNB: people trying to submit board-specific defconfigs get regularly shouted at ;-)
<AstralixNB>
Yes, I agree. There should be only a rockchip_defconfig
<AstralixNB>
However the rk3188-radxarock1.dts should be created
<AstralixNB>
We should at least collect one for the community and make it available
hipboi_ has joined #linux-rockchip
<AstralixNB>
If you try to start mainlining you need to copy and search and copy and ask and search so much...
<AstralixNB>
And mostly for things that already exist, you just cannot see them
<mmind00>
"radxarock1"? you mean "radxarock-classic" and "radxarock-pro" right?
<AstralixNB>
something like this
<mmind00>
as there is already a radxarock dts in the kernel
<AstralixNB>
We have radxarock-preview, radxarock-light, radxarock-pro
<AstralixNB>
And soon we'll have probably a radxarock2-*
ganbold_ has quit [Ping timeout: 255 seconds]
eebrah_ has quit [Remote host closed the connection]
eebrah has joined #linux-rockchip
ganbold_ has joined #linux-rockchip
RayFlower_ has joined #linux-rockchip
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
eebrah has quit [Quit: Lost terminal]
<AstralixNB>
naobsd, the uboot uses the same helper-images as the Loader?
ganbold_ has quit [Remote host closed the connection]
ganbold_ 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
<naobsd>
existing radxarock dts should be good for ES/Lite2013/Full/Pro/Lite. if there is a problem, anyone can send patch freely. no problem for community
<rperier>
mmind00: when you talk about stdout-path, what do you have in mind ? passing all kernel cmd line in the dts file including the uart console to use ?
<rperier>
I thought that it was supported by dw-serial, apparently not, as you said...
<naobsd>
AstralixNB: what is "helper-images"? as you san see there are non-unified branches, binaries are not unified too.
<mmind00>
rperier: when I looked the last time, it didn't look like it was supported ... the underlying problem is, you cannot hardcode "console=/dev/ttyS2" in the commandline of the dts, nor in a future generic rockchip_defconfig
<naobsd>
btw I want to include more options from multi_v7_defconfig to my defconfigs
<rperier>
even if it is in the dts of the board itself ?
<rperier>
I am not really documented about stdout-path and cmdline handling in the dts, I would need to read a bit about it
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
levd has quit [Remote host closed the connection]
levd has joined #linux-rockchip
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
RayFlower_ has quit [Quit: RayFlower_]
dlezcano has quit [Ping timeout: 244 seconds]
dlezcano has joined #linux-rockchip
<AstralixNB>
naobsd, with helper-images I menat the ddr, usb and nand.bin parts that need to be flashed to certain sectors or addresses, depending on the media you are using
<naobsd>
AstralixNB: please see tools/rk_tools/, there are SoC specific files, but it's not bootmedia specific
<AstralixNB>
??
<AstralixNB>
This is not what I wanted to know
<AstralixNB>
But is ok, I figure it out myself
<naobsd>
what you asked is about "same helper-images?"
<naobsd>
helper-images are same if it's for same SoC regardless of boot media configuration
<naobsd>
helper-images are different if it's for different SoC
<naobsd>
this is my answer
RayFlower_ has joined #linux-rockchip
<naobsd>
if you wanted to ask "is that same (compared to something)?", please tell me (something) part too
<naobsd>
ah, sorry, I don't force you to do it now
<naobsd>
I just explained what I talked
<naobsd>
please ignore
selfbg has quit [Quit: Leaving]
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
<mmind00>
rperier: yep ... ttyS2 is a "linux-specific" device in a generic option where linux,stdout-path references the actual uart devicetree-node
<rperier>
oh I see... as the devicetree specification is also used by other projects than linux, it makes sense, yes
<naobsd>
I'm not sure dts can be shared
<naobsd>
for example, RK 3.10 dts and mainline dts are incompatible...
RayFlower_ has quit [Read error: Connection reset by peer]
RayFlower_ has joined #linux-rockchip
<mmind00>
naobsd: that is just because the 3.10 does not conform to standards ... you cannot just invent devicetree bindings for drivers, there is a standardized process with quite strict reviews just for the binding-specification alone
cnxsoft has quit [Quit: cnxsoft]
<naobsd>
mmind00: I'm not sure about devicetree standard, I know there are docs under Documentation/, is that not Linux specific?
<naobsd>
mmind00: ah, I know some properties have linux, prefix
<mmind00>
naobsd: while most of the bindings are created with the linux kernel development, the devicetree maintainers actually try to make sure, that they are generic and usable for other OSes too
<naobsd>
mmind00: ah, I see, thanks
<naobsd>
surely dts description seems to be implementation independent...
<naobsd>
btw GPL file is difficult to use *BSD...
<mmind00>
naobsd: that is exactly the reason dts files get converted to provide two licenses
<naobsd>
probably currently only FreeBSD support both rockchip & dts...
<AstralixNB>
I already saw this yesterday, when I tried getting RK3188 running in kernel 3.10
<AstralixNB>
dts are a bit messy, not even tabulators / inlining are correct
<AstralixNB>
And the bindings do not match
<naobsd>
mmind00: btw, about 2 power source for SD related thing on firefly
<naobsd>
mmind00: how should I write dts? abuse vqmmc-supply for 2nd supply?
<naobsd>
mmind00: or define "always-on" for 2nd?
<mmind00>
naobsd: the second supply actually _is_ the vqmmc-supply ... i.e. the one that needs to get switched between 3.3 and 1.8V to reach some of the higher speeds
<naobsd>
mmind00: well, 2nd supply, vccio_sd it not routed to SD slot
<naobsd>
mmind00: it's routed to rk3288. is it really vqmmc-supply?
<naobsd>
well
<naobsd>
mmind00: is that used for lines such as data?
<naobsd>
I'm not sure which lines can be 1.8v :(
<naobsd>
I see
<naobsd>
I have no knowledge for now
<AstralixNB>
This setup is pretty much messed up...
<AstralixNB>
VCC_SD and VCCIO_SD where messed up. So VCC_SD is connected and switched from VCC_IO (3.3V)
<AstralixNB>
But VCCIO_SD ist connected to the SDMMC0_VDD port of SOC
<naobsd>
mmind00: the reason I'm confusing is, for eMMC, there is set of pins named vccq on eMMC device side
<naobsd>
mmind00: so I thought vqmmc-supply is used for power supply which is connected to device
<AstralixNB>
And what I said about the messed up connection is obviously true as in the original RK schematics of the RK3288 developer kit, the connections are as stated above
<AstralixNB>
VCC_SD is a swirched VCC_IO
<AstralixNB>
but resistors are pulled to VCCIO_SD
<naobsd>
mmind00: anyway I don't have enough knowledge, I follow your suggestion
<AstralixNB>
naobsd, you might still ignore me, but yes, following mmind00's suggestion is the only way that it might work.
<naobsd>
ignore?
<AstralixNB>
I checked the schematics and scanned for the connections, pulled the reference schemtaics from RK, just to be exactly sure, what I tell you, and that all just for you :)
<AstralixNB>
Result: If the schematic is true and it is connected as printed there, the TFcard will not work in high speed modes
<AstralixNB>
So you can just nail it down to normal speed and set fixed supplies.
<mmind00>
AstralixNB: I don't follow you here, the sdmmc0_vdd pin is described as "SDMMC0 Digital IO Power Supply", which is the supply that needs to get switched for UHS purposes
<naobsd>
I read your message and I thought you explained what I know, so I didn't say "you're right/wrong"
<AstralixNB>
Yes, but the terminations must be pulled to VCCIO_SD
<AstralixNB>
However reading "maximum value is" can be read as one should stay below, so 10k is less then 50k. But if it is a good choice to set them to the minimum allowed value...
<AstralixNB>
naobsd, you might check here once in a while