TonyMac32

Indeed you need to write fip/u-boot.bin at the second block (512bytes)

I haven't looked too deeply into the compatibility/resource footprint, but for some HMI environments I like tiling managers https://awesomewm.org/

I added to the site new images 5.87 for N2 with kernel 5.1 which already have the necessary scripts to start the activation of multi-boot (n2_autoscript) and start the system from USB (boot.scr).
If activation is already done, then after burning the image to USB media, you do not need to add\change anything. When you connect to N2 in the USB stick, the system automatically starts up. By the way, I checked the fast USB 3.0 flash drive on N2 , the speed is higher than the SD card. And when using USB-SSD , much faster than eMMC.
 
 
p.s.
After comparing the operation of the system with eMMC and with a good USB-SSD, I concluded that eMMC is not needed for N2 at all.

Here's a first draft of the patches I pulled from bbrezillon tree : https://github.com/Miouyouyou/RockMyy/tree/SplittingPatchesForVPU/patches/kernel/v5.1/VPU
These are applied against mainline v5.1-rc5 kernels, and have been tested with Kwiboo's FFMPEG and a standard MPV.
 
I'll try to test them, and adapt them, against v5.1 releases tomorrow. Then I'll re-arrange them and do a release of RockMyy.
 
I'll then generate a FFmpeg package with Kwiboo's patch, using Kwiboo's tree, since bbrezillon's one doesn't integrate udev /dev/video node detection.
 
And *then* I'll give the whole thing to test to @TonyMac32, who loves testing random VPU patches for Tinkerboards.

I'm holding off until the DDR4 support is working in mainline, this board would be in the same unfortunate state as the RockPi 4/etc. once the u-boot is working properly we can get rk3399 all put into one happy family and get the support fixed.

The connector is a mini-spox connector, I'd say I'd make you one, but I think shipping would be an issue. ;-)

Sent from my Pixel using Tapatalk

That fixed it!  Thanks so much for your quick response; that was fantastic.
 
Regards,
 
Dianne.
 

Cool.  2 different people reached out to HardKernel about a board for me, so I have one coming.

Cool.  2 different people reached out to HardKernel about a board for me, so I have one coming.

BTW, seems like the Lima driver has been accepted for 5.2. Looking forward to seeing it released 

Tested upgrade/downgrade in all directions. Works, kernels updated ... 

My machine is making images again, so I will also start working through these.

Sent from my Pixel using Tapatalk

Soon to appear interesting device S9xxx . If you are interested, I will try to negotiate with the management of the company to send you samples.
 
PS According to preliminary information, it should be a very interesting device.

Via hackaday

Sent from my Pixel using Tapatalk

Just as a tipp
https://github.com/arne48/tinkerboard_io

Via hackaday

Sent from my Pixel using Tapatalk

To be clear I've gone through the heat rates and power losses through the electric vehicle power chain, and in a mountainous region using coal generation a Tesla gets 25 MPG.

Never forget that electrical generation is external combustion turbine, 40% efficiency. Then go through the grid, then the massive losses during charging, and the losses by simply sitting in the driveway in the cold. A new Toyota 4 cylinder gas engine can do that.

There is potential in electric vehicles, and I like the technology, but as an engineer with experience in energy storage and power distribution, it isn't mature enough to push yet, it very clearly causes as many problems as it solves, even in the most optimistic vision.

Sent from my Pixel using Tapatalk

going through the links spotted something for @martinayotte (and maybe @TonyMac32)
 
https://github.com/archlinuxarm/PKGBUILDs/pull/1691/commits/dfe2881b2eaf32a5b2289005c675888345684fd7#diff-2347b909a334e35e45d31e5bb4961a3f
 
there's a a patchset for upstream u-boot for the ram part.. as OP says it's not running stable.. but at least they got upstream u-boot up.. maybe worth a look as well.. to clean the rk u-boot mess asap.

@Myy I pushed some updated kernel branches to my linux-rockchip repo today that may help you get the vpu driver running.
 
Earlier this week I sent out my ffmpeg V4L2 request API hwaccel as RFC on ffmpeg-devel mailing list, see http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242316.html
Important device tree and clk patches have already been merged or is queued for v5.1/v5.2.
 
If you apply both of these two patches on top of v5.0.7 you should have a kernel with working vpu mpeg-2 driver for rk3288, rk3328 and rk3399:
https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-hdmi-sound.patch - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list + my hdmi sound and cec patches
https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-vpu-v2.patch - contains all v4l2 related media tree patches merged/queued for v5.1/v5.2 + Ezequiel rockchip vpu v2 patchset + my additions for rk3288 and rk3328
 
If you do not care for hdmi sound or cec improvements you can instead use the fromlist patch:
https://github.com/Kwiboo/linux-rockchip/compare/v5.0.7...rockchip-5.x-fromlist.patch - contains all mmind/for-next patches merged/queued for v5.1/v5.2 + few patches from mailing list
 
For mali kernel driver I recommend https://github.com/Kwiboo/mali-rockchip/commits/utgard-r9p0, see below how I build it:
 
make_target() { kernel_make -C $(kernel_path) M=$PKG_BUILD/driver/src/devicedrv/mali \ MALI_PLATFORM_FILES=platform/rk/rk.c GIT_REV="" \ EXTRA_CFLAGS="-DCONFIG_MALI400=1 -DCONFIG_MALI450=1 -DCONFIG_MALI470=1 -DMALI_FAKE_PLATFORM_DEVICE=1 -DCONFIG_MALI_DMA_BUF_MAP_ON_ATTACH -DCONFIG_MALI_DT" \ CONFIG_MALI400=m CONFIG_MALI450=y CONFIG_MALI470=y CONFIG_MALI_DMA_BUF_MAP_ON_ATTACH=y CONFIG_MALI_DT=y \ modules } makeinstall_target() { kernel_make -C $(kernel_path) M=$PKG_BUILD/driver/src/devicedrv/mali \ INSTALL_MOD_PATH=$INSTALL/$(get_kernel_overlay_dir) INSTALL_MOD_STRIP=1 DEPMOD=: \ modules_install }  

Of course ! Starkbier can be dangerous if drank too fast ...
I've maybe one hidden somewhere here :

Remember the Amlogic blobtastrophy. Your board may never have hit 1.9 GHz.

Sent from my Pixel using Tapatalk

Kever Yang from Rockchip told me they will eventually upstream the DDR4 support in u-boot. We need to wait for some time.

This could be old news, but my plex update today threw a message out on the console (apt upgrade) that official armv7 and armv8 packages are available.  This should be a pretty solid performance boost for most of us I would imagine, the old packages were fro armel NAS boxes.  Testing it out on my XU4.

https://github.com/armbian/build/commit/d11511ab2d1490a57c02e25a8eb324159de9ba79
 
So 1.8, 1.64, 1.49

Okay, I'm trying (again) this week-end. So the Randy-Li patch not including VPU Decoder v1 for RK3288 chips, I've giving up on it at the moment.
I'm retrying the Ezequiel patch, with Kwiboo additions, now trying to understand how the V4L2 request thing work, and why when using the v4l2-request-test tester, the driver sends back a "Invalid request" response...