jock

Members
  • Content count

    92
  • Joined

  • Last visited

About jock

  • Rank
    Advanced Member

Recent Profile Visitors

467 profile views
  1. jock

    RK3288 Media Testing Script

    Oldies but goodies: a made a quick demo with my smartphone (sorry for the bad quality) of Quake2 running on rk3288 using GL4ES. The game works really well, it is totally playable and there are no issues of any sort
  2. jock

    RK3288 Media Testing Script

    Thanks Myy, got devfreq to work thanks to your patch and enabling it in kernel configuration. Now effectively I see that the regulator supplies 0.950v when it is in its lower power state (100 Mhz), which is nice for power consumption and thermal headroom. I should have practically no issues with power supply, my board is a tv box with its own 2A PSU and barrel connector. I know the SoC is quite power hungry by the way, so I'm keeping the CPU part at lower frequencies (~ 1Ghz) The current governor is simple_ondemand, but I notice that it has difficulties in properly interpreting the gpu load: during glmark-es2 the frequency rises only when there are scenes which are shader-intensive (like the refracting bunny), but during "real" workloads (like quake3) it stays at lowest power state.
  3. jock

    RK3288 Media Testing Script

    Maybe this? Also I'm wondering if the mainline mali driver has some code for reclocking/dvfs. Maybe @Myy can answer to the question. Looking at the voltage of the regulator exposed by the kernel in /sys/class/regulator/regulator.7/microvolts sys/class/regulator/regulator.7 (probably different on other machines, look into directories for ffa30000.gpu-mali symbolic link) it is always fixed to 1.0 volts, so I guess that the GPU is not being pushed at maximum speed even during load. Regulator #6 instead is dedicated to the CPU and it changes accordingly to the frequency changes. I mean, testing quake3 in full-hd at maximum detail and it is totally playable, but it would be nice to push the thing to its limits to see what it can do
  4. jock

    RK3288 Media Testing Script

    @JMCC I'm playing a bit with GL4ES, it works like a charm (trying quake1 and quake3), you should include it in your script. I had to export LIBGL_ES=2 and LIBGL_COPY=1 variables but then it works very well!
  5. jock

    How to utilize OpenGL|ES

    Yes, there is a system that keeps track of kernel changes and recompiles the modules, try to check for DKMS Also notice that the kernel module you built is just a "bridge" between the hardware and the userspace sofware (the whole kernel is, in abstract, a thing like this). The kernel driver does not do anything valuable without the proper userspace drivers (ie: EGL/OpenGL/OpenGL ES libraries, given as BLOBs, referred in the original article you mentioned). To "play with shaders" you have to write some code which uses OpenGL ES and EGL libraries (ie: the userspace blob drivers), which in turn use the kernel module you built, which in turn talks to the hardware. Take a look to es2tri.c example from mesa project, it is the basic for setting up and playing with shaders, but be aware that being profitable in such field requires a lot of base knowledge, and Mali userspace drivers are quite stubborn to work with! If you just want to "play with shaders", I may suggest you an Ubuntu installation on a common x86 computer with an AMD or Intel graphic card which has full opensource drivers and you usually have not to worry about compiling drivers and tinkering with the kernel
  6. jock

    U-boot v2018.05 and RK3288 not working?

    @TonyMac32 I experienced the absymal performance too with dev kernel (4.18), maybe it is related to this? (I don't see the 0007-... patch applied to dev kernels, I'm currently building the kernel but can't test it till evening. edit: tried the 4.18.0-rc4 kernel with the patch and it seems to work!) In the meantime I give up v2018.05 and go back to working v2018.03, don't want to lose time on an issue which has already been fixed in later u-boot revisions...
  7. jock

    [Solved] SDRAM parameters

    Is it possible to change the configuration parameters from the device tree or is embedded in the compile configuration? I took a fast look into u-boot sunxi device trees but did not found anything valuable
  8. jock

    [Solved] SDRAM parameters

    It would be delicious if you would mind to share what kind of soc your custom boards sports, otherwise you are making this even more difficult.
  9. This is the way I set the GPIO at boot time in u-boot &pinctrl { u-boot,dm-pre-reloc; pinctrl-names = "default"; pinctrl-0 = <&power_led>, <&pwr_hold>, <&host_vbus_drv_en>, <&otg_vbus_drv_en>; . . . leds { power_led: power-led { rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_pull_up>; }; }; . . . } As you can see, with the pinctrl-names you can define various pin configurations (here just one, named default). pinctrl-0 is bound to the default and is applied when the driver wants to put the pins in that configuration; in this particular case it applies the configuration to 4 GPIO pins: power_led, pwr_hold, host_vbus_drv_en and otg_vbys_drv_en. power_led, as described above, will turn the GPIO pin 2 of bank 7 to pull-up. You may decide to put it always high, low, pull-down, or none to leave it floating. You can also group more pins together. PS: I'm sorry if the jargon is not proper, but you may consult the kernel documentation about the pin controller device tree bindings to be more compliant, but I hope I gave you the gist. The reference patch I extracted those bits is here
  10. jock

    U-boot v2018.05 and RK3288 not working?

    I'm using the SPL binary from rockchip which initializes the SDRAM, and it correctly provides the initialization strings. When u-boot kicks in the serial became totally mute. Something happens because u-boot is responsible for the power led and it is actually turned on, but then just hangs at some point without providing any info. I also tried u-boot v2018.03 and v2018.07-rc3 and both of them work fine with the same compiler and the same config file.
  11. jock

    U-boot v2018.05 and RK3288 not working?

    Mmmh, so I guess it's my problem exclusively Thanks a lot for sharing, gotta go find what the hell happened
  12. jock

    Adding support for MK39 from Rikomagic

    Writing parts to the eMMC is easy task, rockchip provided rkdeveloptool for such eMMC jobs. You can find it cloning the rockchip-linux repository from here. rkdeveloptool is inside tools directory where you can also find parameter_gpt.txt file, which can be fed into rkdeveloptool to write the default GPT partition table on the eMMC. u-boot has to be placed at sector 0x40, the zImage kernel should be placed at sector 0x8000 and if you got some rootfs you have to place it at sector 0x40000. This is all written inside parameter_gpt.txt, you can check it out to be sure. This is all my guessing, I actually never tried it so can't be sure it really works but at least it is a direction. Also there are so many other variables like device trees, uboot and kernel configurations... Armbian works a bit differently. It uses mainline u-boot configured to find all the necessary booting files (kernel, initramfs, device trees, ...) from the first ext4 partition on the media. Still I suggest you to do all the experimentation on a sdcard instead of the internal eMMC, mostly because the flash memories have a limited number of write cycles and also because swapping sdcards is much faster than uploading each time the data via USB My work on rk3288 is here, where you can also find a mini-guide on rkdeveloptool
  13. jock

    Adding support for MK39 from Rikomagic

    I have no experience with rk3399, but I ported armbian to a tv box with rk3288 and I used mainline u-boot, which is used by armbian too. Something important to let my device boot from eMMC was to create a real partition table (either DOS/MBR or GPT) containing a single partition with type "Linux Filesystem" (fdisk partition type 0x83). But I stress again that this is true for mainline u-boot. I don't know if the same applies to rockchip u-boot, which may stick to their "default" GPT partition table described on the open source documents. To give you some hints, this is my actual partition table on the SD card which boots armbian on my tv box: Welcome to fdisk (util-linux 2.27.1). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/mmcblk0: 14.9 GiB, 16021192704 bytes, 31291392 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x28364f79 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 8192 30978463 30970272 14.8G 83 Linux you should replicate the same on your eMMC. However I suggest you to do all the experiments on a SD card and then, when things work well, transfer start to experiment with eMMC. I guess rk3399 has the maskrom mode working the same as other rockchip socs.
  14. jock

    U-boot v2018.05 and RK3288 not working?

    Got it. I was concerned I made some mistake due to my particular device. It's confortable to know I'm not the only one experiencing some kind of issues. Thanks, I hope I will have the chance to look into soon
  15. U-boot is always a great source of amusement, did anyone try that combination? Just yesterday got v2018.05 in, and it just does not work. I don't get any serial from u-boot SPL, do I don't know what is happening. I compiled it with #define DEBUG, and still no serial output at all. At last I downloaded latest mainline u-boot (v2018.07-rc2) from github, applied manually the patches, complied and it worked. It seems something very specific for v2018.05 and rockchip/rk3288