TonyMac32

I have seen this done with the Tinker board by adding a SPI flash to the GPIO header: https://tinkerboarding.co.uk/forum/archive/index.php/thread-415.html I would assume it is quite similar

The board the K2 is based from, and so the board support package I started with, #defined ram size explicitly as 1 GB. For the other Amlogic board I have that ram size is detected at boot, so I didn't check on the K2.

Fixed RAM size

https://github.com/BayLibre/u-boot/tree/readme Read through this, it has eMMC install described as an option, although mine shows up as 3 devices, so I'm not as sure...

Until the build system makes new packages, you can take the https://github.com/armbian/build/blob/master/packages/blobs/meson/u-boot-nanopik2.bin and stuff it into your current SD card. Make sure your SD card is your SD card or you could wreck your host machine. <--- don't say I didn't warn you, some assembly required (seriously, don't overwrite your computer's boot sector) # sudo dd if=fip/u-boot-nanopik2.bin of=/dev/<your SD Card> conv=fsync,notrunc bs=1 count=444 # sudo dd if=fip/u-boot-nanopik2.bin of=/dev/<your SD Card> conv=fsync,notrunc bs=512 skip=1 seek=1 # sync

Given its development position not a lot of time has been put into it on our side. I believe some more mainline work is coming soon, so we'll be able to see in the coming months. Right now there are some bugs and lack of support from the 4.14/15 kernel.

Indeed it does, however the RK3328 is still not well supported. The kernel works, but not all of the peripherals on the device work/etc.

Yep, it's a complete PITA. It wants gcc-linaro-arm-none-eabi-4.8-2013.11_linux to compile. Otherwise it's relatively straightforward. ./mk gxl_libretech_cc and the resulting binaries are in the fip directory. I have to step myself through it periodically because I don't do it often. You ahve to make sure to add the compilers directory to the path.

For kicks try an image intended for a "p212" development board and see if it burns properly.

This is a u-boot issue I believe that I haven't gotten to fixing. Remember K2 is WIP, so it's not always on the top of the list. hopefully I can move these to a mainline u-boot sooner rather than later... [edit] Found it, the p201 board def I copied defines the RAM as 1 GB, fixing/testing quickly. _ _ _ _ ______ | \ | | __ _ _ __ ___ _ __ (_) | |/ /___ \ | \| |/ _` | '_ \ / _ \| '_ \| | | ' / __) | | |\ | (_| | | | | (_) | |_) | | | . \ / __/ |_| \_|\__,_|_| |_|\___/| .__/|_| |_|\_\_____| |_| Welcome to ARMBIAN 5.35 user-built Ubuntu 16.04.3 LTS 4.14.2-meson64 System load: 0.11 0.30 0.16 Up time: 3 min Memory usage: 13 % of 1850MB IP: 169.254.12.141 10.0.0.40 Usage of /: 20% of 30G [ 0 security updates available, 78 updates total: apt upgrade ] Last check: 2017-12-13 23:13 Last login: Thu Dec 21 02:15:11 2017 I'll get that updated in the build system.

Hello mattkosem, I have not yet attempted it, however, there is a different u-boot.bin between eMMC and SD. SD uses "u-boot.bin.sd.bin" where eMMC simply uses "u-boot.bin" But, that's not the whole story. At this point the bootloader could be written to the eMMC and should at least attempt to boot. The bootscript/etc need to point at the right device or else it will have no idea where to get the device tree/kernel/etc. You should have a u-boot button, I think this may be the method of entering the proper amlogic burning mode (to avoid continuously inserting/removing that eMMC. google the Amlogic usb burning tool and read up, it's not a tool without risk, the USB port that wakes up for me is the top-left, you will need a USB A to A cable, I made one. Now, my board does not have the boot button, I have a reset header instead (early board), so I can't try that directly. [edit] Using the "hurry up and plug it in afterr uboot launches method I've "nuked" the eMMC u-boot, so now I can try some different things, assuming I can get it to boot with the emmc plugged in (I got some strange bl checksum errors I'll have to look into)

I don't know to be honest. If so, and ARMv8 is a benefit assuming the bonus cores and higher clock speeds don't offset it. Remember the a53 is not a particularly powerful core, it's a power-saving core. I would say, as of today for ARMv8 boards I'm familiar with, that Le Potato is more stable/mature, tradeoffs include no USB3, and no Gigabit Ethernet. At risk of angering the benchmark gods, https://magazine.odroid.com/benchmark-results/ This is probably full of various holes, however the difference are large enough to demonstrate my point. I couldn't give you a good answer for which is more powerful for a given workload given just how different they are. (The C2 uses a quad-core a53 Amlogic SoC)

I can't give you much on the Rock64, development has been slow. In general I'd expect the a53 cores of the Rock64 to come in behind the 8-core HMP setup, unless memory bandwidth is significantly better on the Rock64 / you have 4GB and need it. Kernel support is far better for the XU4 at this point, IMHO.

Would it be possible to get someone to confirm a current "dev" image build is bootable? I'm not getting any UART output with SD inserted, my eMMC (my fault) at least ells me I broke it's contents. [edit] OK, the downloadable 4.4 boots, I'm building an unmodified Dev image (I was using a different kernel, shouldn't have broken u-boot though) to verify.

I have XU4 and Tinker and K2, I would also recommend XU4/HCx, for the simple fact that your application needs stable power more than a fancy GPU (unless of course you can actually use the GPU toward your ends) Keeping it cool is now your biggest concern, and that is something you can scale to your desire (I run PLEX and transcode on an XU4 and just for kicks water-cooled it)

Somewhat in line with the "users bring devs" statement, this is almost always a hindrance to users and strikes a negative tone. I don't worry about "dumb repeated questions", honestly we don't truly suffer from that as badly as we may like to believe sometimes, but more of actual hardware issues they refuse to recognize. Now, sometimes we've been known to take a tone that is extremely negative and discouraging to newer users. I came here for just the reasons you listed, user of some H3 boards and, when I got the Tinker Board, decided to try my hand at contributing. With some barriers to discussion/etc, I may not have felt it welcome or even appreciated to contribute, there is a prevailing attitude in the Linux world in general: "If you aren't smart enough to already know, I'm not answering your questions." If there's anything I think the RPi group has done, besides making cheap SBC's available in general terms, it's to reduce that ridiculous mindset somewhat. If you put up an entry fee, for lack of a better word, I think the $8-30 SBC folks aren't going to be extremely interested, and they are the primary advertisement for the project. If users bring devs, (example as noted) then users can bring value, if you support boards that you know have a certain audience in mind. A board with 4+ GbE ports, for example. No beginner is going to grab that board to be a desktop, for example. Targeting that board would typically mean getting the attention of more dev-biased users. A knock-off RPi-0, on the other hand, will only bring people who were trying to get a zero but couldn't find one or thinks they need a quad core to measure the temperature of their basement over I2C. I agree that most board mfg's see projects like this as either noise or free support. On the other hand, others see it as a valuable way to get some feedback on hardware/software/etc, and it is work they don't necessarily need to do, so it is value-added for them to provide boards/donations/etc. Some are far worse than others, and to be honest the products of the worst offenders rule them out of support long before their lack of contribution would. I agree in abstract terms. However, when going to the trouble of supporting something, it might be good to see if it's worthwhile. The RPi, for instance, really doesn't need another OS except in very specific situations such as OMV. Otherwise we're simply another image in a pile of images. I honestly don't believe the demand for an Armbian RPi image is very high for that reason. If a specific board's platform is rock solid and support is as simple as adding it's DT and kconfig to the pile, then certainly, add it. (The VIM will be in that category once the Amlogic gremlins get sorted, at present it seems the Amlogic documentation and drivers are simply a mess, so other than boards already supported I'd not recommend any new ones at present based on GX(L)(M) or the new AXG)

[2.875599] OF: /sound/simple-audio-card,codec: could not get #sound-dai-cells for /hdmi@ff980000 [ 2.875607] asoc-simple-card sound: parse error -22 [ 2.875630] asoc-simple-card: probe of sound failed with error -22 Well then.

Please provide the output link of armbianmonitor -u I haven't messed with sound on mainline yet, but I recall a sound-soc error in my dmesg, meaning there probably is something wrong .

I have a few things I'd like to "babble" about along those lines, however I think it would be best termed "philosophy of application". In this case there are a few things that may help, such as board config templates (what kernel options/etc are common as possible across all Armbian kernels/etc). I would say "freezing" would be preferable to "dropping". This project provides more than enough information to recompile kernels and add modules/make small changes/etc, there's no need for any of the devs to pull out a board with a cm of dust on it and risk starting an electrical fire when they plug it in and the capacitors have dried out [dramatization for effect] simply because one guy wants 'x' feature on 'y' board that hasn't been built in 'z' years. Reading over @botfap's post I agree, other than the RPi bits, like with the Tinker Board we'd constantly get the "But the Vendor OS can *insert something a *team* of professionals implemented that you weren't able to do in the 3-4 hours you put into this on an average night when nothing interferes*. Raspbian does everything you should and shouldn't do with one, a similar reality is why I haven't pushed a "community support" package for the Khadas VIM. All Meson GX/GXL (Amlogic S905(X)) boards are very nearly identical and can be supported very easily as a family, but Khadas already has a pile of fully capable OS images, I have no desire to "compete" with them by pushing a 66% or so capable Armbian branded image. RPi is the same sort of situation. We have a lack of metrics for what constitutes "ready" or "supported". Now, some requirements are difficult to make "hard requirements" But this goes back to the "matrix of what works" I proposed some time ago, if the hard requirements are met, and the board's aggregate support/capability is over let's say 75%, then it could be considered (arbitrary numbers). I won't pretend to be an impressive developer, but I am in automotive engineering, and my life revolves around gate reviews and processes. Keep it secret, keep it safe. There are, in my mind, two questions that must be asked before supporting anything: What does Armbian bring to the SBC and its users that the Vendor does/can not? This needs to be in "dumb user" terms. A board for watching cat videos is not an Armbian device. What does the SBC, it's vendor, and its users bring to Armbian that would be a benefit to the community? Will these users contribute? Will they donate? Will they spread the good word? Will the vendor contribute resources and will those resources outweigh the support effort for the device? In the case of the Pi, it is a cat video watching, Scratch programming, "ZOMG I AM 1337" type of board. I think in terms of a beginner Linux doodling machine it's fine. But it does not have any hardware capabilities that would benefit from Armbian in real terms. I'm sure the OMV images perform much better than if they weren't Armbian, but how much better is that when the hardware is so bad? I'm glad OMV and tkaiser were able to squeeze some water from the performance stone that is RPi, but to go that one extra step and have a general-purpose official Armbian-branded image would be stupid I think, the answer to the "Important Questions" would be as follows: We can make the Citroen 2CV go 5 km/hr faster, but it is still outrun in a 1978 Diesel Rabbit towing a trailer. The users would bring us exposure (probably bad when we're not as "friendly" (OS or devs) as Raspbian) and they would undoubtedly require more resources in support than we would gain in donations/contributions to continue the work on other boards. Botfap's situation is quite different, if funding were assured and the customer defined then support is quite different than with an "anybody can download it and complain" model of an open project like this.

It's possible. I don't have one, probably should look into getting one, and spend some time with it and the Rock64. Currently mainline isn't very exciting, so it needs the 4.4 kernel to truly operate properly.

Sounds easy enough, I'm guessing you'd bake in the command structure for Firmata?

Thank you for the feedback, I spent yesterday playing videos/movies/music/etc with the rockchip kernel on Armbian with no problems, I'll move over to mainline next I would guess that to be true but don't "know" in a legal sense, I found some various references that show people piping like this: flac -d filesname.flac -o - | aplay -D sysdefault:CARD=card

Indeed. I was playing with Linux on the HP Jornada 720 and the Mini 2440 from friendlyARM before the RPi was even a rumor. Oh, I forgot, I also have an ARM7TDMI board here somewhere...

If you want to do audio testing, the capability has always been there, but when I first tried it there was a lot of ugly (and potentially dangerous) noise on certain files/bitrates. See Sound was never disabled, you just had to do your homework to get it. Since I was trying to get a lot of other things working at the time I did not patch the suspect settings into the system for the fear of breaking things. You enable this at your own risk, once enough people with enough time show me enough evidence that all is well we can see about setting it up to work out of the box. My recommendation is to use a cheap speaker and keep the volume low, cycle through various bitrates and sources/programs before trusting it until we can be reasonably sure the Rockchip/PA demons have gone away. I have not yet tried this with Mainline or Armbian Legacy. At the moment I am experimenting with the Rockchip main 4.4 repo, this is extra super WIP for people who know it isn't going to work perfectly and can build their own: https://github.com/Tonymac32/build

I have a few other things I'm playing with, however I wanted to post a quick "for experimentation only" post: This is at your own risk, I take no responsibility for your ears or audio equipment. I would highly recommend testing this on a small speaker at low gain until we build some confidence. I have had good luck with an experimental 4.4 kernel (Rockchip-curated one, lots of bugs still) and will start trying to flip a few more switches on support wise. One of those is obviously sound. Tinker Board sound (to the jack) comes from a largely undocumented realtek USB codec, ALC4040, USB ID 481A. It has a group of subdevices, I assume for multi-channel use. Now, for some reason, device 0,0 is NOT the headphone jack. Device 0,2 is. PulseAudio's hardware discovery only seems to log the first one, leaving the others untouched and unselectable. tony@tinkerboard:/etc/pulse$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Audio [USB Audio], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: Audio [USB Audio], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Audio [USB Audio], device 2: USB Audio [USB Audio #2] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: rockchipminiarm [rockchip,miniarm-codec], device 0: ff890000.i2s-i2s-hifi i2s-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 So, time to do things "the wrong way" (If anyone knows how to do it the "right way" let me know, I'm just making it work for now. I would assume figuring out how to make PA enumerate it properly is the right answer, that's not what I'm doing here.) tony@tinkerboard:~$ cd /etc/pulse tony@tinkerboard:/etc/pulse$ sudo nano default.pa find the section that looks like ### Load audio drivers statically ### (it's probably better to not load these drivers manually, but instead ### use module-udev-detect -- see below -- for doing this automatically) #load-module module-alsa-sink #load-module module-alsa-source device=hw:1,0 #load-module module-oss device="/dev/dsp" sink_name=output source_name=input #load-module module-oss-mmap device="/dev/dsp" sink_name=output source_name=inp$ #load-module module-null-sink #load-module module-pipe-sink Then add to that section: load-module module-alsa-sink device=hw:0,2 sink_name=tinker_output and save. Now reboot for best results. You should see another "USB Audio" device, select it as your sink if it's not already selected. I haven't bothered making it the default device as yet. Now, for the warnings: I fully believe this to be a Rockchip problem, not an ASUS or Tinkerboard problem, but in the past when I've tested this I would, upon playing certain source material, get absolute garbage out of the output. Very loud and terrifying garbage. There have been a lot of changes to the clock system over the last year with Rockchip, assignments and improvements, so it is possible this has been remedied, so I am testing it again.