nighty- has quit [Quit: Disappears in a puff of smoke]
lkcl has joined #linux-rockchip
BenG83 has quit [Ping timeout: 246 seconds]
nighty has joined #linux-rockchip
BenG83 has joined #linux-rockchip
<nashpa>
FUZxxl: there are some wrong defaults in v2017.03 but it can be made to work, I've successfully booted mainline U-Boot on Firefly 2 nights ago
<nashpa>
question for the people on this channel: has anyone tried to enable HYP mode in U-Boot and/or PSCI? Any war stories?
<FUZxxl>
nashpa: interestingly, Rockchip's U-Boot doesn't boot at all on the Tinkerboard before a commit that reverted b3d2861e.
<nashpa>
FUZxxl: things I've done: CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y, CONFIG_SPL_OF_PLATDATA=n, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=n
<FUZxxl>
nashpa: okay; I'm not very knowledgeable about U-Boot
<nashpa>
and applied the spl: Add spl_early_init() series (Simon Glass posted a v4)
<FUZxxl>
I can upload the changes I made to rk's vendor tree to github and you can see where the differences are
<nashpa>
FUZxxl: it uses Kconfig, like the kernel. look into doc/README.rockchip
BenG83 has quit [Ping timeout: 246 seconds]
<FUZxxl>
nashpa: I also had to patch api/api_storage.c for CONFIG_API to work (which I need for FreeBSD)
<nashpa>
FUZxxl: I don't have a tinkerboard nor access to my Firefly right now, so not sure how I can help
<nashpa>
FUZxxl: but if you do a 'make ARCH=arm CROSS_COMPILE=<your_cross_prefix> tinker-rk3288_defconfig in U-Boot directory
<nashpa>
FUZxxl: and then 'make ARCH=arm CROSS_COMPILE=<your_cross_prefix> nconfig' (or menuconfig, whatever you like) you can search for the strings I've given you (minus the CONFIG_ part)
<FUZxxl>
and then?
<nashpa>
FUZxxl: and make sure that they are at the values I've given
<nashpa>
then 'make ARCH=arm CROSS_COMPILE=<your_cross_prefix> -j<nr_cpus>'
<nashpa>
that will build your u-boot.bin and spl/spl-uboot-dtb.bin
<FUZxxl>
interestingly, rockchip's vendor tree has CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y and that works just fine
<nashpa>
yes, that means they don't use the BOOTROM to load u-boot
<nashpa>
they use U-Boot's SPL code to do that
<FUZxxl>
yeah
<nashpa>
might work, haven't managed to make it work for me
BenG83 has joined #linux-rockchip
<nashpa>
anyway, if you want to follow my method, after build finishes, put an SD card in your machine and then look at the command shown in doc/README.rockchip after #define CONFIG_ROCKCHIP_SPL_BACK_TO_BROM
<FUZxxl>
yes, I did all of that
<FUZxxl>
Rockchip's vendor tree compiles and works, mainline U-Boot doesn't
<nashpa>
adjust to match your setup and (in my case) "it just worked" (tm)
<nashpa>
mainline u-boot doesn't compile?
<FUZxxl>
nashpa: mainline u-boot compiles but doesn't run
<nashpa>
FUZxxl: did you try with my instructions? Who knows.... it might work?
<FUZxxl>
as in, doesn't give any output and doesn't boot Linu
<FUZxxl>
nashpa: the only thing I didn't do was setting CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR to n
<FUZxxl>
perhaps I should try that but I don't see why it should work
<FUZxxl>
I suspect that there is some patch missing in the mainline that makes U-Boot work in the vendor repository
<nashpa>
go in arch/arm/mach-rockchip/rk3288-board-spl.c (mainline U-Boot) and right at the top #define EARLY_UART
<nashpa>
FUZxxl: I have a couple of TV boxes with RK3288 and at least one of them works with the Firefly build of mainline U-Boot
<nashpa>
FUZxxl: the way I understand it is that when you select CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y that means SPL is going to return to BOOTROM and it lets it continue to load the main U-Boot
<FUZxxl>
I am not sure
<FUZxxl>
I can confirm that this option is used in the variant that works
<nashpa>
FUZxxl: but that main U-Boot has to be right after the SPL image, so CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y (or whatever the default value is) makes SPL expect that the U-Boot is at some offset
<nashpa>
FUZxxl: I know!! I'm suggesting that with mainline U-Boot you they the *other* method, which is to let BOOTROM load the SPL and main U-Boot
<FUZxxl>
strange
<nashpa>
FUZxxl: I have succeeded recently on 2 RK3288 boards, but you are not obliged to do so
<nashpa>
FUZxxl: you are welcome to try the vendor method and hack it until it works on mainline if that is what you want
<FUZxxl>
okay
<FUZxxl>
hm... perhaps I should try to request the U-Boot patches ASUS applied in the image they distribute.
<FUZxxl>
After all, U-Boot is GPL licensed so I have a right to get the source.
<nashpa>
mainline U-Boot has a board called tinker-rk3288, not sure if that is ASUS one or some other ODM
<FUZxxl>
nashpa: that's the ASUS board
<FUZxxl>
this configuration compiles and work in the vendor tree but not in mainline u-boot
<nashpa>
FUZxxl: right, I don't know how well maintained that board is
<nashpa>
FUZxxl: given that I've had to hack around the default configuration shipped by v2017.03 U-Boot tells me that Rockchip maintainers in U-Boot have not been paying attention this release cycle
<FUZxxl>
that makes sense
<nashpa>
FUZxxl: seriously, if you want to give mainline U-Boot a go the least you can do is '#define EARLY_UART' in rk3288-board-spl.c
<nashpa>
FUZxxl: maybe even put a 'printascii("FUZxxl was here\n");' around line 184 in that file, after debug_uart_init(); call and before #endif
<FUZxxl>
okay
<nashpa>
FUZxxl: with the spl/u-boot-spl.bin flashed at offset 64 on your SD card, you should at least have a message
<FUZxxl>
I found something: the patches vendor u-boot added to get the tinker board running are based off v2017.03-rc3
<nashpa>
FUZxxl: that would start you
<FUZxxl>
so perhaps it isn't too difficult to integrate them into the mainline.
<nashpa>
FUZxxl: yeah, best of luck
<ayaka>
I don't asus tinker is any special to the other board
<FUZxxl>
how high are my chances of getting source code when requesting code for the U-Boot build used by ASUS?
<FUZxxl>
ll
<ayaka>
it have already on the github
<FUZxxl>
ayaka: oh yeah, where?
<ayaka>
unless you want the ugly u-boot used for android
<FUZxxl>
these are not the pins where a raspberry pi user expects the system console to be
<FUZxxl>
the raspberry pi user expects the system console (including u-boot output) to be on pins 8 and 10
<ayaka>
FUZxxl, I don't care about RPi
<FUZxxl>
where uart1 is
<FUZxxl>
ayaka: then don't advertise this thing as compatible!
<ayaka>
blame the ASUS
<FUZxxl>
ayaka: so, you're not interested in making this useful. Great!
<ayaka>
I don't like RPi from the beginning
<FUZxxl>
ayaka: obviously, the choice of which uart to use must be important to the user, otherwise the image distributed by ASUS wouldn't have u-boot changed to have the console output go to uart1
<ayaka>
I will like to install a yocto system on it not the debian
<FUZxxl>
are there any other patches that aren't in the source tree but in the debian image?
<ayaka>
no
<FUZxxl>
well okay
<ayaka>
but I know it is able to use uart1 from beginning
<ayaka>
let me have a check for you
<FUZxxl>
thank you
<ayaka>
FUZxxl, no new release. but I saw the patch change both config.h and dts
<FUZxxl>
what did they change in config.h?
<ayaka>
num of uart
<FUZxxl>
ok
<FUZxxl>
ayaka: thank you for your help. I've finally managed to get FreeBSD to boot (though it crashes immediately)
<ayaka>
wow, FreeBSD can run in arm now
<FUZxxl>
ayaka: is it planned to commit these patches to mainline U-Boot o we can boot the tinker board from mainline u-boot?
<FUZxxl>
ayaka: freebsd supports arm for years now. Porting it to the rk3288 is going to be fun though (I am very unexperienced)
<FUZxxl>
it does run on the rk3188, so maybe the amount of extra code needed isn't too much.
<ayaka>
well, I have not used freebsd for many years
<FUZxxl>
ayaka: is there anything specific I have to pay attention to?
<ayaka>
I don't know what do you mean
<FUZxxl>
ayaka: is there any special thing I need to know when trying to port the kernel to the rk3288 SoC?
<ayaka>
I hear there is limit of the dma range
<ayaka>
it would crash at the booting time
<FUZxxl>
ok
<ayaka>
if you don't want to get the hw video support
<ayaka>
nothing special
<FUZxxl>
ok
<FUZxxl>
I don't think the Mali GPU is supported by FreeBSD at all
<ayaka>
also the video encoder/decoder
<FUZxxl>
ayaka: you should publish the patches you used to switch the uart as these are shipped on the TinkerOS image and publication is thus required by the GPL2.
<ayaka>
I am not in charge of it
<FUZxxl>
okay
<ayaka>
I am sure it will be released
<ayaka>
but not by me, I have not touch it for a long tie
<FUZxxl>
okay. Thank you for your help.
lkcl has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Remote host closed the connection]