nightseas
-
Posts
22 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by nightseas
-
-
18 hours ago, Igor said:
That is normal. AFAIK no network support within u-boot for now or not enabled.Good!
Really great work!
Is there any way to select specific version of ARMBIAN to build? 5.36 for example.
I could checkout the specific release tag, but the build scripts would always switch to master and build the latest version.
Thanks & BR.
-
I had a NanoPi NEO2 working well with ARMBIAN 5.34.171121.
After apt-get upgrade, ARMBIAN has been changed to ARMBIAN 5.37.171208 with below firmware update:
Get:1 http://beta.armbian.com xenial/main arm64 linux-dtb-next-sunxi64 arm64 5.37.171208 [25.0 kB]
Get:2 http://beta.armbian.com xenial/main arm64 linux-image-next-sunxi64 arm64 5.37.171208 [14.7 MB]
Get:3 http://beta.armbian.com xenial/main arm64 linux-u-boot-nanopineo2-next arm64 5.37.171208 [222 kB]
Get:4 http://beta.armbian.com xenial/main arm64 linux-xenial-root-next-nanopineo2 arm64 5.37.171208 [318 kB]Then the Ethernet port is no longer working. Kernel message shows MDIO register failure:
root@NEO2-ST0:~# dmesg | grep -i eth
[ 0.000000] psci: probing for conduit method from DT.
[ 1.661750] dwmac-sun8i 1c30000.ethernet: PTP uses main clock
[ 1.838435] dwmac-sun8i 1c30000.ethernet: PTP uses main clock
[ 1.838566] dwmac-sun8i 1c30000.ethernet: Will use external PHY
[ 1.944368] dwmac-sun8i 1c30000.ethernet: Chain mode enabled
[ 1.944381] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported
[ 1.944391] dwmac-sun8i 1c30000.ethernet: Normal descriptors
[ 1.944401] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported
[ 1.944412] dwmac-sun8i 1c30000.ethernet: COE Type 2
[ 1.944422] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported
[ 1.944984] dwmac-sun8i 1c30000.ethernet: Cannot register the MDIO bus
[ 1.945003] dwmac-sun8i 1c30000.ethernet: stmmac_dvr_probe: MDIO bus (id: 0) registration failedAny hack do I need on device tree or driver to make it work again?
BTW: Is there any way to select specific version of ARMBIAN to build? 5.36 for example. Even if I checkout the specific release tag the build scripts will always switch to master and build the latest version.
Thanks & BR,
Xiaohai Li
-
What about an universal lib which is totally decoupled from HW platform, and with functions (SPI, I2C, UART, GPIO) separated?
- It should be not only able to run on Allwinner SoCs, but also other
- No kernel driver hacking or physical register access, only based on Linux userspace interface
I did port the wiringPi last year. Both C and Python (Cython based) are supported.
The only customizing needed is to fill in the GPIO number map (standard Linux GPIO number) and device number (SPI1, ttyS2 etc.)
-
On 2017/8/28 at 8:38 PM, odlg said:
Hello
I have a Firefly RK3399 board and would like to test your build. Do you have downloadable images? Or do I need to setup a build env. Do you have flashing instructions?BR
Ole
You should better build your own image, with several configurations changed from rk3399-evb to firefly, such as dtb, uboot config...
-
14 hours ago, Myy said:
The command to build most of the Rockchip repositories with a debian folder seems to be :
dpkg-buildpackage -b -rfakeroot -us -uc
That said, I would still highly recommend taking the .so library from their repository, put it in a folder, regenerate the appropriate links quickly and test GLES programs by invoking them like this :
LD_LIBRARY_PATH=/path/to/the/library gles-programInstalling the new OpenGL ES libraries in /usr/lib could generate serious issues. Testing DRM/KMS OpenGL ES programs, like glmark2, from a real console (CTRL+ALT+F1), or from weston (Wayland), will generally be easier than trying from X11.
Thanks for the hints. Do I also need to install Rockchip DRM packages while testing glmark2?
-
On 8/16/2017 at 2:02 PM, yasko said:
@nightseas,
This is a good news about OpenCL and RK3399. It's interesting to see your results about OpenCV + OpenCL on RK3399.
I have found that ARM released their own Compute library . It supports both NEON and OpenCL and they claim that it has better performance than OpenCV.
I am also playing with RK3399 (Yundoo Y8) and was able to compile ARM compute library and I'm planning to do some perf tests.
Attached is the full OpenCV 3.3.0 + OpenCL perf test report except video test part, which failed probably because of corrupted GLES.
Just for your reference.
-
1 hour ago, Andro said:
Reading the above thread, is there any support for the Videostrong 6 core RK3399 board? Can Armbian run on that system?
I have made the initial support for RK3399. Currently working on GPU stuff.
-
On 8/8/2017 at 2:02 AM, Myy said:
Indeed. That's the main reason why I'm using DRM/KMS OpenGL ES code with the latest Rockchip libmali (with GBM support) to test the 3D drivers.
Now that glmark2 has incorporated my patches, it should be easy to compile and use on any board with working DRM and OpenGL drivers. You might want to give it a try. Compile it like this :
./waf configure --with-flavors=drm-glesv2 ./waf ./waf install # Not mandatory, you can execute the binary from its build folderThen
LD_LIBRARY_PATH=/path/to/mali/drivers glmark2-es2-drmYou'll certainly be limited to VSync, however the score on the crystal bunny and the (ugly) terrain should provide some good statistics on the GPU.
I tried to build libmali deb pack for RK3399 but failed. There's no instruction or guide, so I may need to ask Rockchip for help again.
Then I manually linked the lib in /usr/lib and destroyed the the desktop GUI. After some experiment the desktop was back but still could not test gles2 as you suggested.
The good news is, OpenCL works well. I'll do some OpenCV + OpenCL perf test and put the result here.
-
19 hours ago, YelloApple said:
I use Rockchip official repo...
THX for your uboot patch~
I have used your uboot from https://github.com/nightseas/rockchip-uboot/,but I can't find any SD card driver as well...
In uboot ,I have tried the command "mmcinfo" but no any SD card be found.
In linux, I have tried the command "ls /dev" but no any SD card node be found.
“dmesg” command does not have any information about the SD card node, I have used your uboot source to compile, whether the need to patch the kernel?
Update:
...
The driver works fine so that is not a like a software issue. I have tested the SanDisk Ultra 8GB/16GB C10 cards and seen no such error.
If the U-Boot shows no mmc1 device then it means the dwmmc controller doesn't detect anything, and I'm afraid there's something wrong with your hardware or SD card.
-
On 2017/8/11 at 8:36 AM, YelloApple said:
I have the same board...But it seems the sd card can't work too....Do you have any idea?
Which kernel are you using?
Kernel 4.4 from Rockchip official repo:
https://github.com/rockchip-linux/kernel
If it's mainline Kernel from kernel.org then which version is it?
Other 3rd-party repo?
There's a bug in the RK official u-boot, which is caused by missing dwmmc driver and leads to SD card boot failure.
https://github.com/nightseas/rockchip-uboot/commit/80b82a7ba084b36c4f4ffbe7b67ffe98ff349f21
-
14 hours ago, fossxplorer said:
Too bad this board isn't available anymore. I also get " is sorry that the baby is temporarily off the shelves, you can stroll around the other baby" like CNX-Soft reported.
I asked the owner about the stock. There are less than 100 boards in stock and I see the correct quantity in system now.
I'm not sure if I can help on ordering boards because of possible issues on China Customs (tax stuff), production quality or transportation damage.
Just don't have time to test all the boards.
-
On 8/4/2017 at 5:42 PM, Myy said:
Indeed, wzyy2 tend to prepackage the mali drivers in the rk-rootfs-build repository, but the one in the libmali repository seems to be updated more regularly. That said, if the drivers work, better not update them.
Too bad for ARM, since their DDK was more up to date (obviously) and incorporated all the techs possible. That said, they often say they won't provide the drivers for any board and then release them anyway a year later.
Now, it looks like the screenshot was eaten by a grue. (´・ω・` )
You might be interested by the new Rockchip wiki here. It has various information on how to compile or install certain Rockchip specific components on common distributions :
http://opensource.rock-chips.com/
This might help you if you're stuck with few things.
Well, the biggest problem is that the mali userspace lib from RK is not compatible to the xserver and desktop display infrastructure installed in ARMBIAN.
You have to install RK's xserver packs and also new desktop from some unkonwn source (maybe that's the Debian source under developing or source from RK).
I have faced it once when I was customizing a RK3288 board and I'm sure that it'll be still standing in my way. So Let me do some experiments and make as many functions work as I can.
-
On 8/4/2017 at 5:05 PM, Igor said:
Which patches do you use when building? Make sure you include at least those two:
Bug in boot script:setenv bootargs "earlyprintk root=${rootdev} rw console=${console} rootfstype=${rootfstype} loglevel=${verbosity} rootwait ${extraargs}"
Change this in config:CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not setThanks a lot for the hints.
I chose the Marvell 64-bit patch instead of RK3288 to replace compressed zImage with the binary Image.
Now Armbian 5.32 (Ubuntu 16.04 Desktop) is successfully running on my board.
I forked the repo and make my own commit to add the support for RK3399. You can find the changes to original repo here:
https://github.com/nightseas/armbian-build/
Know issues:
1. No GPU or VPU pack installed for now;
2. There's a binary tool from RK used to convert u-boot, which can't be packed into the u-boot deb because it's for x86_64. Means you can't update bootloader in a running Armbian.
Next step will be GPU and VPU userspace lib porting.
Screenshot of desktop, with CPU, temperature, and frequency:
-
Now the bootloader and kernel built with Armbian scripts are running.
But there's a strange issue, in which the ramdisk system can not mount rootfs partition on SD card (SanDisk Ultra 8GB Class10 Micro SD):
Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. Begin: Will now check root file system ... fsck from util-linux 2.27.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 rootfs: recovering journal rootfs: clean, 145627/219024 files, 636583/875520 blocks done. mount: mounting /dev/mmcblk0p1 on /root failed: No such device done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 No init found. Try passing init= bootarg. BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs)But the fsck.ext4 successfully operated the partition, and in the ramdisk system I was able to mount the system manually.
(initramfs) ls /dev/ ttyFIQ0 tty24 fuse network_latency rfkill tty25 vpu_service network_throughput mem tty26 rkvdec memory_bandwidth null tty27 ptmx mali0 port tty28 ttyS1 mmcblk1 zero tty29 ttyS3 mmcblk1rpmb full tty30 ttyS0 mmcblk1boot1 random tty31 ttyS2 mmcblk1boot0 urandom tty32 hwrng usbmon3 kmsg tty33 ram0 usbmon4 tty tty34 loop-control usbmon5 console tty35 loop0 usbmon6 tty0 tty36 loop1 input vcs tty37 loop2 i2c-9 vcsa tty38 loop3 hdmi_hdcp1x vcs1 tty39 loop4 fb0 vcsa1 tty40 loop5 vendor_storage tty1 tty41 loop6 dri tty2 tty42 loop7 pts tty3 tty43 zram0 fd tty4 tty44 net stdin tty5 tty45 ppp stdout tty6 tty46 usbmon0 stderr tty7 tty47 usbmon1 char tty8 tty48 bus block tty9 tty49 usbmon2 disk tty10 tty50 uinput rtc tty11 tty51 i2c-0 vcs2 tty12 tty52 rtc0 vcsa2 tty13 tty53 i2c-1 vcs3 tty14 tty54 i2c-4 vcsa3 tty15 tty55 mapper vcs4 tty16 tty56 vhci vcsa4 tty17 tty57 uhid vcs5 tty18 tty58 ashmem vcsa5 tty19 tty59 iio:device0 vcs6 tty20 tty60 snd vcsa6 tty21 tty61 mmcblk0 tty22 tty62 mmcblk0p1 tty23 tty63 cpu_dma_latency (initramfs) [ 27.588426] random: nonblocking pool is initialized (initramfs) (initramfs) (initramfs) mount -t ext4 /dev/mmcblk0p1 /root [ 43.477832] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) (initramfs) ls /root/ sys tmp usr lost+found media opt boot home proc selinux run var lib dev mnt bin root etc srv sbinThe boot scripts and full log are attached. Just ignore the eDP and SDIO WiFi errors, because they are not connected.
I guess I'll need to check the kernel config (also attached) then.
-
18 hours ago, Myy said:
Concerning OpenGL ES tests :
You might need to download one of these drivers in a folder, create the various libGLESv1_CM.so{,.1} libGLESv2.so{,.2} libOpenCL.so{,.1} libEGL.so{,.1} links to the libmali you downloaded and then set LD_LIBRARY_PATH when testing OpenGL ES little programs.
I might be missing a few file links...
So, if you downloaded libmali-midgard-4th-r13p0-gbm.so in /tmp/test-mali for example, this should do the trick :
cd /tmp/test-mali for link in libGLESv1_CM.so{,.1} libGLESv2.so{,.2} libOpenCL.so{,.1} libEGL.so{,.1}; do ln -s libmali-midgard-4th-r13p0.so $link; done LD_LIBRARY_PATH=/tmp/test-mali ./es2gearsChange es2gears by the name of that the OpenGL ES program binary you want to test of course.
Note that if /dev/mali0 is not read/writeable by your user, the OpenGL ES program might fail with a Mali Driver error message telling you that you do not have the right GPU. It's a permission issue in that case.
If you don't have a /dev/mali0, it's a driver integration issue however.
No Vulkan support for the moment, however. The ARM guys do not seem to have released any driver for the Firefly RK3399. (´・ω・` )
I just did some simple test and didn't know if it was in a correct way.
As I was using the rk-rootfs-build scripts, I assumed that the packs were working. Unfortunately, no time for further test.
Take a look at the deb packs here:
https://github.com/rockchip-linux/rk-rootfs-build/tree/master/packages/arm64/libmali
And actually ARM guys won't do anything for Firefly RK3399. Rockchip will, but only in there official repo.
Screenshot of es2gears test.
-
I'm starting to add RK3399 to Armbian, in my spare time.
Here's the board I got, RK3399 official EVB, which spent me 500CNY (~63EURO) on Taobao, quite cheap comparing to Firefly.
https://item.taobao.com/item.htm?spm=a1z09.2.0.0.1f30a53flpk7IA&id=554454257549&_u=31t0eea9a1c
Spec:
- Rockchip RK3399 (2xA72 + 4xA53, Mali T860 MP4)
- 4GBytes Dual channel LPDDR3 (64-bit in total)
- 8GBytes eMMC, Micro SD Slot
- USB 3.0 Type-A, USB Type-C (DP over Type-C), USB2.0, HDMI
- 1G Ethernet
- Raspberry Pi compatible 2x20 pin header
- Other interfaces: PCIe 2.0 x4, MIPI CSI & DSI, eDP, LVDS....
You can download Cadence OrCAD format schematic and Allegro format PCB files for free. It's open sourced and you'll also find BOM, gerber files ready for production.
http://opensource.rock-chips.com/wiki_Excavator_sapphire_board
I was able to build Linux 4.4 + Debian 9 with build scripts from Rockchip. And it looks like the OpenGLES and OpenCL are ready? (not fully tested). VPU still has some problem.
Will continue to update in this post...
-
2 hours ago, chwe said:
Armbian doesn't recommend dd to burn a image to sd cards cause it doesn't check integrity after writing the image to the SD-Card.
Yep, that's why I only put it as an alternative option. Maybe I should use the term "if you insist".
-
Hey guys,
I've written a brief guide of getting ARMBIAN running on ClearFog Base, hoping it will be helpful for new bees.
getting_started_with_clearfog_base.md
It's like a note of how I was managed to write images and to boot ARMBIAN from USB, eMMC, or SATA SSD. And some details of A388 SoC boot selection.
The guide is based on ARMBIAN 5.30 and ClearFog Base + A388 SoM with eMMC, and I believe that all the steps were verified, although I've tried several versions of ARMBIAN (both Deibian and Ubuntu) and got lots of boot failure.
If there's any mistake in the guide, or there's a better way getting things done, please make comments here.
Thanks & best regards.
-
On 2017/3/16 at 2:01 AM, tkaiser said:
And another RK3288 device, maybe doing a few things better (eg. barrel plug for DC-IN and not crappy Micro USB, no internal USB hub, mounting holes for large heatsink):
http://linksprite.com/wiki/index.php5?title=PcDuino9#Hardware_specifications
Well, my last attempt to deal with Linksprite's software was shocking
And it has 4GB dual-channel LPDDR3 by default, a small cortex-M4 MCU for board management or real time processing.
The real purpose of this board is not for SBC but micro blade server cluster.
that's why all connectors are placed to one side, as front panel in the future.
I was also planning a real open cluster project to DIY blade system with managed switch blade ( the SOM on clearfog could be a good start ), backplane power delivery and cooling control.
Just need more TIME. Ouch...
-
Mark this topic as solved since RK3288 has already been supported by Armbian.
I've talked to some cooperators of RK and it seems RK is officially contributing to the project ( not confirmed ), and they are willing to pay more attention to opensoure work.
Good good!
-
Hi,
Is there any plan fro Armbian to support Rockchip processors like RK3288 or RK3399? Any guide on how to port Armbian on them?
These processors have official support on GPU (both openCL and openGL ES), HW video codec (like H264 encoding and decoding with gstream), and also open-sourced Kernel 4.4.x. And most important thing is they are willing to support opensource community and fix their bugs continuously.
I've got a RK3288 proto board which was able to run Linux 4.4 + Debian with HW accelerated desktop and video playing, and it worked perfect. The only thing that troubled me is the Debian system that maintained by Rockchip is suck...
So I'm looking on the great Armbian now. I'll star to port it when I have time. But I'm here to ask if it's considerable to have Rockchip supported officially.
Hummingboard Pulse (iMX8Q) WIP
in Advanced users - Development
Posted
Cool! I was just wandering if there had an Armbian build for i.MX8M then I saw your post.
BTW: Do you know if there's any graphic support for i.MX8M? I'd like to try headless first and then move to HMI with LCD kiosk display.
Thanks & BR.