-
Posts
154 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Community Map
Everything posted by Xalius
-
The first embedded system I was learning to program MCUs on (around 1999) was Atmel's AVR STK500... good times with AT90S1200, AT90S8535...
-
When I was at University for EE we had to get HP48/49/50 for the RF design lectures because one of the professors wrote all his tools for them... now I mostly use an emulator on my phone to carry the HP50 around with me
-
They recently added some u-boot patches for dram config on RK3328 to the BSP repo and promised to release SPL soon. The first step would be to see if ATF built from source works in contrats to the binary we have now, or wait for the SPL to arrive and do all at once... @TonyMac32, is there a complete schematic of Tinkerboard somewhere? I looked at the one from the ASUS download section but it seems incomplete?
-
I use the minimal image atm from ayufan's github repo and that works so far, I have removed the eMMC module from the board atm. https://github.com/ayufan-rock64/linux-build/releases/download/0.2.1/xenial-minimal-rock64-0.2.1-29-armhf.img.xz The partition scheme comes right out of the rootfs build scripts from RK...
-
I have a short update on the latest patches RK sent to BSP upstream. As of this morning we have a Rock64 image that doesnt lock up anymore after 20 minutes and ayufan found a hotfix for the GbE issues by turning off tx-offloading (no TX/RX paramters tuned yet) and that seems to work well at least for him (930Mbit both directions) with one CPU core loaded since integrity calculations are now done on the CPU. Currently we boot the 2GB and 4GB with one firmware loader at 768Mhz DRAM frequency. The u-boot patches to autodetect DRAM size seem to work so far, havent heard back from someone with a 1GB board yet. RK also should push a DRAM init blob for 933Mhz soon... https://github.com/ayufan-rock64/linux-build/releases - new images and deb packages for system upgrade
-
Yeah I am following the mainlining process for some time now, and some new things went into 4.12.x , we'll see at what pace that continues. As for the documentation there are only the datasheets (SOC+RK805), Part 1 of the user manual and the schematics right now. Tl is trying to get the Part 2 of the user manual released, but I am not sure what is actually in there. RK just today provided some more patches for the 4.4.x BSP, maybe the Rock64 can now stay up longer than 20 minutes :-) On the hardware front Tl was looking for last suggestions regarding schematic changes or board layout changes, I think the plan is to go into production as soon it is confirmed that 933Mhz DRAM works on all three (1/2/4GB) variants... @TonyMac32 I can ask Tl if he can send you a board sample if you like
-
HP50G!! Will update my post with a photo later...
-
Why not look at your boot process first? You could start by running systemd-analyze blame and see what takes how long on your system to boot... systemd-analyze can also plot nice graphs of your boot process... http://pastebin.ubuntu.com/24916964/ for example output from my Thinkpad Further running systemd-analyze critical-chain gives you hints where your boot process is delayed the most... https://wiki.archlinux.org/index.php/Improving_performance/Boot_process
-
:-)
-
While I am pretty content now with the performance of Chromium after all the tweaks that were applied, I never heard of qupzilla before and am testdriving that on my Pinebook atm. It seems a bit more capable compared to the other lightweight options like Midori.
-
Do not forget to actually lift the BT reset GPIO, on the Pine64 that is done via 'rfkill unblock all' or 'rfkill unblock xxx' otherwise the uart of the BT part will not answer and you just get a 'sync timeout' from the firmware loader...
-
Pine64 uses the same RTL8723BS module and we got BT working more or less reliably now. There are some versions of the BT firmware loader floating around (Iwfinger, hadess, ...) but NextThingCo seems to have the latest version for the RTL8723DS, which also works with CS and BS though... Check out: https://github.com/ayufan-pine64/linux-build/blob/master/Makefile#L49 - build the rtk_hciattach firmware loader, loads FW over UART and attaches it to the BT stack https://github.com/ayufan-pine64/linux-build/tree/master/package/root/lib/firmware/rtlbt - needed firmware files https://github.com/ayufan-pine64/linux-build/blob/master/package/root/etc/systemd/system/rtk-hciattach.service - systemd service
-
Thanks for the info! One more github to keep track of :-) We'll see how ayufan's first Android experiments turn out, but even on AW A64 / Pine64 Android 6/7 ran pretty well @1080p after some tweaking, a lot better than the SDK based stock images at least, 4K for video playing is more or less possible, but acccelerated 3D with Mali400 not so much... as far as I could see all of those RK3328 Android boxes run on an older 3.10.x kernel too instead of 4.4.x... At the moment there is a very early Debian image for Rock64 based on https://github.com/rock64-linux and ayufan already set up his CI magic to build consistent images at https://github.com/ayufan-rock64 , https://github.com/ayufan-rock64/linux-build/releases , https://jenkins.ayufan.eu/job/linux-build-rock-64/ . One issue we ran into is that there seems to be a problem with DRAM settings for Rock64 atm, the image is not running stable at least on the 4GB board, probably because the DRAM settings are from either the 1GB or 2GB board and RK has not yet released the u-boot spl and dram init code for RK3328, there are only two miniloaders with either 333Mhz or 768Mhz DRAM settings...
-
Hi, can you make a photo of your setup? It's a bit hard to discuss ESD or EMI otherwise, e.g. how is your wiring done and are cables detachable or not, can you just enclose the whole solution or is access required... etc...
-
The situation for hardware video acceleration at least for the 4.4.x BSP looks a lot better compared to Pine64 if you look at Rockchip's open source github, but since I havent got my prototype yet and also haven't anyone seen booting Linux images so far I am only cautiously optimistic.