stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 240 seconds]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
maze-BUG has quit [Ping timeout: 264 seconds]
maze-BUG has joined #linux-rockchip
maze-BUG has left #linux-rockchip [#linux-rockchip]
kaspter has quit [Ping timeout: 258 seconds]
kaspter has joined #linux-rockchip
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 260 seconds]
camus1 is now known as kaspter
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 246 seconds]
camus1 is now known as kaspter
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-rockchip
vstehle has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
indy has joined #linux-rockchip
kevery1 has joined #linux-rockchip
stefan_ has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
vicencb has joined #linux-rockchip
mayab76 has joined #linux-rockchip
ldevulder__ has joined #linux-rockchip
ldevulder_ has quit [Ping timeout: 264 seconds]
ldevulder__ is now known as ldevulder
klokken has quit [Ping timeout: 240 seconds]
klokken has joined #linux-rockchip
Leepty has joined #linux-rockchip
stikonas has joined #linux-rockchip
<topi`>
is there somewhere a good wiki for 3288? I have a spare Radxa Rock2 here, but the radxa pages are outdated
<topi`>
I guess the ASUS tinkerboard stuff is up-to-date
<topi`>
can we use extlinux to load kernel on rk3288?
robmur01 has joined #linux-rockchip
<DuClare_>
I thought syslinux was x86 only..
<mps>
DuClare_: syslinux yes, but u-boot can use same config file, i.e. extlinux.conf
<DuClare_>
Oh, sure
<DuClare_>
Then you use u-boot to load kernel
<DuClare_>
:)
<mps>
yes, I prefer extlinux.conf on all my arm machines
<mps>
actually, we made it by default in alpine linux
<mps>
except raspberries ;P
<DuClare_>
Yeah well, I'm doing embedded stuff that might boot from something like 16MB flash.. I prefer simple hardcoded bootscript with no filesystem dependencies
<DuClare_>
:)
<topi`>
ok, so how can I create a SDcard with a working U-boot on it? for rk3288?
<topi`>
I guess I should try compiling one myself... with some board files for rock2 included.
<mps>
understandable ofc. but we are distro and want to add more flexibility for users
<topi`>
do we have any distros that would support booting on rock2 rk3288 out-of-the-box?
<topi`>
I remember compiling U-boot is a tedious task
<DuClare_>
buildroot makes it pretty simple
stikonas_ has joined #linux-rockchip
<topi`>
I'll try that
<DuClare_>
There are at least two rk3288 defconfigs in mainline buildroot tree
<DuClare_>
.. which may or may not work with your board
<DuClare_>
But u-boot tends to be one of the simpler things to get started with
<topi`>
the only way is to try out
<topi`>
I guess setting up DDR3, mmc controller and serial port would be enough
<topi`>
the differences probably come from which mmc lines are going where on the mainboard etc
stikonas has quit [Ping timeout: 272 seconds]
tlwoerner has quit [Ping timeout: 256 seconds]
<topi`>
what would be a suitable defconfig name for the kernel that buildroot builds?
<robmur01>
compiling U-Boot is tedious? I should be just "make rock2_defconfig && make"
<topi`>
I see no rockchip_defconfig anywhere in the 5.7 kernel tree
<robmur01>
*It
<robmur01>
for the kernel you probably want multi_v7_defconfig
<robmur01>
(no idea about buildroot, I just build stuff manually)
<DuClare_>
topi`: If you use one of the existing buildroot defconfigs, they should specify the name of the in-tree dts
<DuClare_>
E.g. rk3288-tinker.dts if you're using asus_tinker_rk3288_defconfig
<DuClare_>
(Look for rk3288* under arch/arm/boot/dts/ if you want more examples)
<topi`>
configuring buildroot is daunting. I wanted it to build the linux kernel, and now "no kernel device tree source specified"
<topi`>
ok, I guess I'll enter "rk3288-rock2-square.dts" right there.
<nomis>
hm, some days ago someone pointed me to the uboot reset code that reacts to the saradc "reset" button. I am unable to find it again.
<nomis>
found it: arch/arm/mach-rockchip/boot_mode.c
nlhowell has quit [Ping timeout: 260 seconds]
* robmur01
remembers mainline's original recovery key behaviour of deleting itself from eMMC - hilarious, but not overly practical
<robmur01>
I hope it's got cleverer since then...
<nomis>
uh, nice. :)
<topi`>
now buildroot is finished and I have some items in output/target, rootfs.tar, u-boot-spl.bin, u-boot.bin and zImage
<topi`>
how should I write u-boot-spl.bin and u-boot.bin to a SD card so that the rk3288 will load them?
<topi`>
I've only got experience from i.MX6 boot, there you'll have to write the SPL with some weird offset into the beginning of raw SD disk
<robmur01>
topi`: there are some instructions in U-Boot's README.rockchip, but personally I always find myself referring back to Rockchip's own wiki: http://opensource.rock-chips.com/wiki_Boot_option
tlwoerner has joined #linux-rockchip
<topi`>
is ATF needed for rk3288 boot?
<robmur01>
not usually - the standard RK3288 setup is the crusty old 32-bit way of running Linux in Secure SVC with no real firmware at all
<topi`>
ok let's see what happens if I put some magic bytes into the SDcard...
<DuClare_>
topi`: Check the rk3288 based configs under buildroot
<DuClare_>
and those boards' dirs
<DuClare_>
You'll find genimage.cfg probably
<DuClare_>
Which generates sdcard.img
ldevulder_ has joined #linux-rockchip
<DuClare_>
(called from post-image.sh or such)
<topi`>
yeah plenty of genimage.sh's there
<topi`>
maybe asus/tinker could be used for this Radxa board
ldevulder has quit [Read error: Connection reset by peer]
<topi`>
image = "u-boot-spl-dtb.img" ... how does this differ from u-boot-spl.img?
<topi`>
I thought only the kernel uses .dtbs
<DuClare_>
Nah u-boot needs to know about devices too
<topi`>
only u-boot-spl.bin found in output/images...
<topi`>
I wonder how to make that? clearly it depends on the kernel being built. but I did that.
nlhowell has joined #linux-rockchip
<DuClare_>
BR2_TARGET_UBOOT_SPL_NAME defines which spl images are copied from uboot build
<robmur01>
note that U-Boot has its own set of DTs, independent of Linux
<DuClare_>
On my end, u-boot-spl.bin and u-boot-spl-dtb.bin are the same file
<DuClare_>
So it doesn't matter but vyasa & tinker define spl_name to be spl/u-boot-spl-dtb.bin
<DuClare_>
(Mind you I'm on a somewhat oldish branch)
<topi`>
Ok let me see what happens
<topi`>
tinker does have a genimage.sh, but rock2 does not, so it seems to me tinker has proper support in buildroot
<topi`>
this is a veeeery old U-boot (from the emmc android image)
robmur01 has quit [Quit: Leaving]
robmur01 has joined #linux-rockchip
<topi`>
Unable to boot:backup
<topi`>
try to start rockusb
<topi`>
I assume this means that it can't find U-boot? but the SPL seems to do its job.
<topi`>
maybe the uboot also requires treatment from mkimage?
<DuClare_>
I think that message is from rockchip's bootloader, not u-boot spl
<robmur01>
for the BSP flow there is no SPL, anything that says "U-Boot" is the main stage already - if it doesn't get further than that it probably can't find the magic "partitions" that the Android kernel, recovery, etc. bits are packaged in
<DuClare_>
topi`: emmc has priority over sdcard btw
<DuClare_>
Soo you might wanna wipe it or short the clock to ground or something, if you want to boot from sdcard
warpme_ has joined #linux-rockchip
<topi`>
I see, but if that would be true, why didn't it just boot from emmc, which has a working uboot
<topi`>
after inserting the SDcard, it sure seems to try to boot from it
<topi`>
robmur01: seems you're right, it finds the same uboot
<topi`>
DDR Version 1.00 20141007 <-- where does this msg come from?
<topi`>
SPL or the RK bootrom?
<DuClare_>
RK bootloader
<topi`>
I see no message that would indicate it has jumped to the SPL
<topi`>
it jumps directly to U-boot
<DuClare_>
Yeah so you're still booting whatever you got on emmc?
<topi`>
probably
<robmur01>
that's the "miniloader", the binary blob equivalent of SPL that does DDR init and loads and calls the a magically-packaged u-boot.bin
<DuClare_>
Right, that's the name
<topi`>
what's the best way to wipe it? using some Linux version of rktools?
<DuClare_>
rkdeveloptool might work
<robmur01>
if you can boot *something*, the just dd zeros to the first 1MB of the eMMC
<DuClare_>
That works too
<topi`>
I can boot to andriod, but cannot break that boot :)
<robmur01>
otherwise, get it into maskrom mode (e.g. short the eMMC clock) and poke it with rkdeveloptool over USB
<robmur01>
rockusb mode (i.e. what you usually get with the 'recovery' button) is annoying in that it won't let you mess with the IDB loader (i.e. miniloader or SPL) area directly
<topi`>
but the chip certainly won't listen to the rkflashtool unless the recovery button is pressed, right?
<stefan_>
you can enter uboot and type rockusb 0 mmc 0 instead
<nomis>
It seems that returning to the rom bootloader on the rk3328 somehow depends on configusing CONFIG_ROCKCHIP_BOOT_MODE_REG in USB. I am not sure, what value should I configure it to?
<topi`>
ok but how should I bake the SDcard to be ready for booting? it seems the uboot.bin needs to be mkimage'd and then written to offset 16384 with dd
<topi`>
it's tricky to get the Recovery mode to work. I'm pushing the buttons, but am not getting the special RK usb device (vendor 2207) on my virtualbox's lsusb
<nomis>
topi`: the hardcore way to enter the cpu boot mode is to short the clock-Pin of the emmc to gnd.
<nomis>
depending on your hardware there is a jumper or testpad for that somewhere probably.
JohnDoe_71Rus has joined #linux-rockchip
<topi`>
yes, the pad is visible. I did short it. it didn't boot to android any more :)
<topi`>
but still no sign of the 2207 usb vendor on lsusb
<nomis>
in that state (and without SD-Card inserted) the CPU should show up as usb device when you connect the OTG-Port to your computer.
<topi`>
I guess I should bring a real PC and not a macintosh
<DuClare_>
re. mkimage, you want to use that on u-boot-spl-dtb.bin, not on u-boot proper
<topi`>
there's always some issues in routing the USB through to the virtualbox
<topi`>
DuClare_: ok, thanks
<nomis>
topi`: mhm, yeah. that might be an issue.
<topi`>
maybe I can force it to boot from SD by shortcutting the emmc
<topi`>
there are decent instructions on Radxa's wiki on how to do that
<DuClare_>
As for u-boot proper, I think you just append the bin to the spl image you got from mkimage
<DuClare_>
.. that's what I do anyway
<topi`>
so.. it's kind of a "fat SPL" in a sense?
<topi`>
I'll try that as well
<DuClare_>
Mm I'm not sure what that's supposed to mean. It's spl followed by u-boot proper; spl loads the latter :)
<DuClare_>
But anyway, even without u-boot proper you should get a message on serial port when spl loads
<topi`>
I wonder how SPL finds the right offset from the media
<robmur01>
by knowing that it's 0x4000 ;)
<topi`>
I wrote the "rabian" image to a SDcard and now am finally in Linux
<DuClare_>
:>
<topi`>
but it's ancient, from year 2015. so I guess I want to compile a newer uboot?
<robmur01>
yup, now from the crusty old Linux you can dd the new U-Boot to eMMC and bootstrap yourself
<topi`>
yeah, I'm dd'ing /dev/zero to emmc right now
<topi`>
this board has been sitting in the dust probably for 5 years
<topi`>
but it seems many vendors offer industrial boards based on the rk3288 so it makes for an interesting study.
<DuClare_>
What are you studying?
<topi`>
the chip itself doesn't feel slow at all
<robmur01>
(once you have mainline U-Boot running it's then beautifully simple to use the "gpt" and "ums" commands to flash the rest of your boot/root filesystem from a host machine)
<topi`>
DuClare_: we create industrial applications for our clients
<topi`>
robmur01: is this documented somewhere? maybe better look up a uboot wiki
<DuClare_>
I still think it's easier to just wipe the emmc and work with an sdcard until everything works but ymmv
<DuClare_>
(Mainly because I hate messing with proprietary usb tools when I mess up the bootloader or something..)
<topi`>
the kernel provided with rabian is very chatty... dmesg is flooded with stuff
<robmur01>
DuClare_: that's the point, U-Boot's USB OTG mass storage emulation is anything but proprietary :D
<DuClare_>
Aha
<topi`>
I wish the device had SPI
<topi`>
then just flash a decent UBOOT on that SPI and be done with it
<DuClare_>
robmur01: Doesn't help if you messed up your u-boot :)
<DuClare_>
topi`: Nothing wrong with booting from emmc
<DuClare_>
Works just like spi, only faster
<DuClare_>
:)
<stefan_>
What is required for booting from SPI
<stefan_>
I am trying that, but failing
<stefan_>
After I programm the SPI and do a software reboot it works, it boots from SPI
<topi`>
I'd say SPI is more reliable than emmc
<stefan_>
but after hardware reboot it does not boot
<topi`>
maybe it tries a different boot path first?
<robmur01>
AIUI SPI boot on Rockchip seems to be a whole other nightmare due to the image packing being all different
<stefan_>
Well I used rockchip ddr and miniloader spinor binaries
<stefan_>
and put them into single one with mkimage
<stefan_>
and flashed that to the beginning of the flash
<stefan_>
and I am trying to flash uboot.img and trust.img to the flash also
<topi`>
boot-3.10.0: Android bootimg, kernel (0x60408000), ramdisk (0x62000000), s
<topi`>
econd stage (0x60f00000),
<topi`>
why are these guys using an Android bootimg? with uboot? makes no sense.
<DuClare_>
topi`: Was there something specific you needed to know about the rk3288?
<DuClare_>
Just wondering
<robmur01>
"makes no sense" is pretty much the slogan for vendor BSPs :D
<DuClare_>
Yep..
stefan_ has quit [Quit: Konversation terminated!]
lkcl_ has joined #linux-rockchip
lkcl has quit [Ping timeout: 260 seconds]
<nomis>
not sure what is going on, but the saradc-driver in u-boot does not seem to work for my rk3328-based board :-(
<robmur01>
ooh, cool, there's even an "adc" command for the poking with :)
<nomis>
uh, I need to enable that.
<robmur01>
IIRC not everything uses the same resistor values, so it's possible that the threshold might be above KEY_DOWN_MAX_VAL
<nomis>
I have printed out the raw values and I get 1022 regardless of the key being pressed or not.
<robmur01>
I forget, did it work in Linux?
<nomis>
yes, it did.
Leepty has quit [Read error: Connection reset by peer]
<nomis>
(just checked - it still does :)
<robmur01>
hmm, rockchip_dnl_key_pressed() assumes channel 1, which seems to match most references in RK3288 and RK3399 DTs, but the RK3328 reference design uses channel 0
<nomis>
oh.
<nomis>
yeah, that is wrong.
<robmur01>
might have a play with this on my box later...
<nomis>
I need to overload that function then in a boardspecific file I guess. Or make this channel configurable
<nomis>
ok, changing the channel to 0 helps. Thanks for that.