<naobsd>
Astralix: I see. such kind of drive service sometimes dead due to transfer limit
<naobsd>
Astralix: this is one of the reason I made mirror, but my mirror also has transfer limit
<Astralix>
My Baidu download limit is reached long time ago
<Astralix>
I have a request pening at the sponsor of our server
<Astralix>
but he is in xmas holidays too, I guess
<Astralix>
However we chould add a working parameter file to that SDK
<naobsd>
anyway, as far as I know, firefly team did/are doing their work well. I think it's not perfect, but seems good for me
<naobsd>
in pad branch, RKTools/windows/AndroidTool/AndroidTool_Release_v2.33/rockdev/rk3288-3.10-uboot-data1G.parameter.txt
<Astralix>
ok, I searched by -- find . -name "parameter"
<Astralix>
As in older SDKs it was available with that name
<Astralix>
This should be added to the wiki
<naobsd>
in master branch, there is RKTools/rk3288-3.10-uboot-data1G.parameter.txt too
<naobsd>
it's just default/sample
<naobsd>
it may not be "optimized" for your image
<naobsd>
if you need "firefly" version (made by firefly team), there are firmware image
<naobsd>
but they will be "optimized" for their firmware image
<naobsd>
Astralix: I'm not firefly person, please write any request to their forum
<Astralix>
yes, after I succeeded to extract or create a working version
<Astralix>
So, then let's boot
<Astralix>
That parameter doesn't work...
field^Mop has quit [Ping timeout: 264 seconds]
<Astralix>
And with this parameter installed, that I extracted from the Android 4.4 image, uboot doesn't start normal
<Astralix>
So upgrade_tool doesn't accept it anymore
<Astralix>
hmm... upgrade_tool RD doesn't work, but you have to reboot by power-cycle and all works fine again!
<Astralix>
Ok, jas-hacks: I can say that pad version of Android 4.4.4 is working here
<Astralix>
naobsd, the behaviour of the system was quite strange on the first trial of reset, however, with the extracted parameter file it works.
<naobsd>
jmcneill: oh I didn't have idea that usging decrement timer with ~
<naobsd>
jmcneill: I guess clocklander() can be run while reattach/init a9tmr, is it safe?
markm_ has quit [Ping timeout: 244 seconds]
<naobsd>
jmcneill: probably I'm wrong, need to understand more about timer things...
<naobsd>
jmcneill: on boot, a9tmr_init_cpu_clock() is not called on other APs, right? then, if it's called on all cores after freq update, will it generates x4 interrupt?
<naobsd>
sorry, I have to go out today
<naobsd>
jmcneill: I'll try latest code later
naobsd has quit [Quit: Page closed]
cnxsoft has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 250 seconds]
FreezingCold has joined #linux-rockchip
Astralix1 has joined #linux-rockchip
Astralix has quit [Ping timeout: 250 seconds]
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft1 has joined #linux-rockchip
<FergusL>
cnxsoft1: any chance you heard about a Bay Trail development board to come out anytime soon ?
GriefNorth has joined #linux-rockchip
<cnxsoft1>
Not yet, but looking into it
ganbold_ has joined #linux-rockchip
<cnxsoft1>
Actually MinnowBoard MAX is a bay trail development board.
<cnxsoft1>
But using an Industrial SoCs, instead of a tablet SoCs
cnxsoft1 has quit [Quit: cnxsoft1]
cnxsoft has joined #linux-rockchip
naobsd has joined #linux-rockchip
faddat_ has joined #linux-rockchip
faddat has quit [Ping timeout: 240 seconds]
<naobsd>
jmcneill: I see about per-cpu init, thanks
<naobsd>
jmcneill: sorry for bothering you
gb_master has joined #linux-rockchip
gb_master has quit [Client Quit]
<rperier>
hi all
jas-hacks has joined #linux-rockchip
<jas-hacks>
naobsd: I suggest setting @5, @6, @7,@11 to always-on for the act8846. I looked at the vga driver in android they seem to be setting the regulators when probed. The regulators remain on until the driver is unloaded. @5 & @11 seem to be used by HDMI.
<naobsd>
jas-hacks: any video-output related unit are not exist in rk3288-firefly.dts for mainline _yet_.
<jas-hacks>
naobsd: ah, ok.
<naobsd>
jas-hacks: it will be used when consumer is added
<jas-hacks>
mmind00_: I can see that drm edid is reading edid from my monitor so that part seems to be working.
<Astralix1>
So you might still discover problems communicating to SD/MMC even voltage is 3.3V now.
<naobsd>
jmcneill: sorry, I said about my time :)
<jmcneill>
oops DCDC4 not LDO4
<Astralix1>
If you want ot step over 10..12MHz on data bus, termination gets critical and if the GPIOs are not set correctly, the problems increase with speed
<jmcneill>
3.3V seems to have done the trick
<jmcneill>
ld0: 4-bit width, bus clock 48.000 MHz
<Astralix1>
congrats
mrueg has quit [Ping timeout: 250 seconds]
mrueg has joined #linux-rockchip
jas-hacks has left #linux-rockchip [#linux-rockchip]
cnxsoft has quit [Quit: cnxsoft]
GriefNorth has quit [Quit: WeeChat 1.0.1]
GriefNorth has joined #linux-rockchip
bengal has joined #linux-rockchip
curlymo has joined #linux-rockchip
<curlymo>
any os dev's here?
<jmcneill>
depends what you mean by that
<curlymo>
i want to be able to run a custom compiled kernel and initramfs from my SD card
<curlymo>
thereby bypassing the NAND as much as possible
<jmcneill>
i'm doing that with netbsd on my rk3188 board
<jmcneill>
uboot + kernel + rootfs on sd
<curlymo>
i'm using a radxa rock pro, but can't get it to work
<curlymo>
can you maybe guide me through it if it is rk3188 compatible?
<jmcneill>
sure
<jmcneill>
can't be much help with linux but i can walk you through the process i did for netbsd
<jmcneill>
two offsets need to be written, kernel and initrd
<jmcneill>
for netbsd case i don't have an initrd, but naobsd says they both have to be valid, so i just wrote the kernel to both locations to appease the bootloader
<jmcneill>
the board i'm working on is very similar
<curlymo>
i finally want to port XBian
<curlymo>
already running on a Raspberry Pi, Hummingboard and Cubox-i
<curlymo>
i also compiled u-boot myself. Do you know if i should use u-boot.in or RK3188Loader_miniall.bin?
<naobsd>
curlymo: for SD? then u-boot.bin. please see gen.sh
<curlymo>
yep just sd, will try
<naobsd>
jmcneill: int error = act8846_set_voltage(ctrl, 3300, 3300); <- error is unused
<curlymo>
i'm now at the point i can generate the idb_sector_0.enc idb_sector_1, FlashData.bin (from hex) and FlashBoot.bin (custom compiled) on the fly
<curlymo>
next step will be a customized parameters.img
<curlymo>
parameters is rkcrc -p right?
<naobsd>
curlymo: please see gen.sh
<curlymo>
just want to know if that information is correct
<curlymo>
as i said, tried everything at least ones, but not in the correct combination
<curlymo>
about the parameters, the CMDLINE is just plain kernel cmdline parameters right? If so, why do we need the initrd and mtdparts in there?
<curlymo>
and the KERNEL_IMG should always point to 0x60408000?
<naobsd>
I don't know what you tried, but there is no "combination". u-boot-rk3188.zip just work
<curlymo>
(i tried the custom kernel i generated with the steps from the radxa website and that didn't work, so the rest also didn't. I just couldn't be sure what the exact issue what)
<curlymo>
what = was
<naobsd>
curlymo: if you need initrd, you need initrd in CMDLINE. if you need mtdparts, you need mtdparts in CMDLNE
<naobsd>
curlymo: you can change address in KERNEL_IMG if you really need
<curlymo>
is there good documentation about the parameters file?
<naobsd>
there is doc in Android SDK, but I'm not sure it's "good"
<curlymo>
as long as it contains correct info
<curlymo>
back to the initramfs? Does it has to be inside the kernel? Because the second kernel dd is kernel+initramfs image?
<naobsd>
curlymo: it depends how kernel works
<naobsd>
curlymo: at first please specify "kernel" you're talking
<jmcneill>
oh i get that even without urtwn plugged in, huh
<naobsd>
curlymo: working kernel source is provided from radxa
<jmcneill>
i suppose the port is still powered up
<naobsd>
jmcneill: ah, sorry, I remembered that I removed CRU_CLKSEL_CON11_MMC0_PLL_SEL(_MASK)
<jmcneill>
hm radxarock.dts sets vdd_hdmi to 2.5V
<jmcneill>
lets try that
<naobsd>
I think clk src should be selected by CRU_CLKSEL_CON10_PERI_PLL_SEL
<naobsd>
and I forgot to do it...
<naobsd>
lets try
<jmcneill>
nope still disconnect event
<curlymo>
ok one more, in the parameters file, the KERNEL_IMG is defined as 0x6040800. Is that because the kernel.img is placed in 0x2000+0x6000 (0x8000)?
<naobsd>
curlymo: no, KERNEL_IMG is entry address on ram
<curlymo>
so the addresses match by accident?
<jmcneill>
how do they match?
<curlymo>
the 0x60400000 could be a base_addr with the 0x2000+0x6000 as the respective address from that base
<jmcneill>
you said load addr was 0x6040800
<curlymo>
that missed a trailing 0
<jmcneill>
i see, well i suppose if there are other partitions to load, and you load them in order, and they are fixed sizes, it might make sense to load them at the same offsets
<naobsd>
see mtdparts for dd offset
<jmcneill>
i plan on eventually using 0x80000000 for netbsd load addr
<jmcneill>
(related to 2GB support, don't ask..)
<curlymo>
so if i want to change the load address i change the mtdparts
<naobsd>
curlymo: no
<curlymo>
but i indeed see the addresses match
<naobsd>
curlymo: mtdparts is layout for flash storage, KERNEL_IMG is ram address
<curlymo>
i understood
<curlymo>
but if i want to flash kernel at 0x2000+0x2000 i need to change the mtdparts to 0x00008000@0x00002000
<curlymo>
confirmed by testing it
<curlymo>
now i at least understand why i need mdtparts :)
jmcneill has quit [Quit: Leaving]
bengal has quit [Ping timeout: 244 seconds]
<curlymo>
just wondering, at what location does your first partition start @netbsd
<curlymo>
i tried creating a ext2 partition @81920 but it seems to overwrite my sdcard layout we made before