ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at | ML at
andoma has quit [Ping timeout: 260 seconds]
andoma has joined #linux-rockchip
lkcl has joined #linux-rockchip
nighty- has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
lkcl has quit [Ping timeout: 258 seconds]
vagrantc has quit [Quit: leaving]
zzarr has joined #linux-rockchip
beeno has joined #linux-rockchip
muvlon has quit [Ping timeout: 260 seconds]
muvlon has joined #linux-rockchip
BenG83 has quit [Quit: Leaving]
paulk-blaze has joined #linux-rockchip
lkcl has joined #linux-rockchip
BenG83 has joined #linux-rockchip
LongWork has quit [Quit: LongWork]
LongWork has joined #linux-rockchip
paulk-blaze has quit [Quit: Leaving]
tlwoerner has quit [Quit: Leaving]
paulk-collins has joined #linux-rockchip
lkcl has quit [Ping timeout: 258 seconds]
beeno2 has joined #linux-rockchip
beeno has quit [Ping timeout: 256 seconds]
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.
<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> ayaka: that is 100% not the source code they use on the image they distribute
<phh> FUZxxl: it is, just an older version
<FUZxxl> because it doesn't work correctly, but the code they distribute on the image does
<ayaka> no
<FUZxxl> phh: so ASUS is not in complicance with the GPL2
<ayaka> it should, I use that code to develop the tinker
<FUZxxl> ayaka: then tell me why I don't get any serial console output with that code?
<ayaka> FUZxxl, oh, in the developing time, we use uart2
<ayaka> but the asus change it to uart1
<FUZxxl> I had to patch the dts file for serial console output to go to the right place
<ayaka> it is ok to use the uart2
<ayaka> and I would suggest you to use the uart2
<FUZxxl> ayaka: this is not very useful because on the boards you can buy, UART2 is routed to a place where the user doesn't expect it
<ayaka> FUZxxl, why not
<ayaka> could you give me a picture
<FUZxxl> ayaka: the Tinker board is designed to be Raspberry Pi compatible.
<ayaka> yes it is
<FUZxxl> there, the UART with the system console is on pins 8 and 10 of the GPIO header
<FUZxxl> this is where uart1 is on the tinker board
<FUZxxl> so that's what u-boot should use
<ayaka> let me give you a picture
<FUZxxl> ayaka: uart2 is on pins 32 and 33, which isn't useful as it isn't compatible with existing hardware
<ayaka> FUZxxl, are those pins used in Picture?
<FUZxxl> ayaka: these are the pins where uart2 is
<ayaka> FUZxxl, what stop it being used?
<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]
JohnDoe_71Rus has joined #linux-rockchip
LongWork has quit [Quit: LongWork]
vickycq has quit [Ping timeout: 260 seconds]
vickycq has joined #linux-rockchip
BenG83 has quit [Ping timeout: 260 seconds]
BenG83 has joined #linux-rockchip
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 256 seconds]
stdint has quit [Ping timeout: 240 seconds]
stdint has joined #linux-rockchip
libv_ is now known as libv
beeno2 has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria]
tlwoerner has joined #linux-rockchip
lkcl has joined #linux-rockchip
lkcl has quit [Ping timeout: 264 seconds]
zzarr has quit [Quit: This computer has gone to sleep]
nighty has quit [Remote host closed the connection]
vagrantc has joined #linux-rockchip