TonyMac32

Ok, I added a flash node inside the spi node for the flash with a driver that should work since the basic flash commands seem to be the same:
 
spi@ff190000 { compatible = "rockchip,rk3328-spi", "rockchip,rk3066-spi"; reg = <0x0 0xff190000 0x0 0x1000>; interrupts = <0x0 0x31 0x4>; #address-cells = <0x1>; #size-cells = <0x0>; clocks = <0x2 0x20 0x2 0xd1>; clock-names = "spiclk", "apb_pclk"; dmas = <0xb 0x8 0xb 0x9>; #dma-cells = <0x2>; dma-names = "tx", "rx"; pinctrl-names = "default"; pinctrl-0 = <0x30 0x31 0x32 0x33>; status = "okay"; w25q128@0 { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "winbond,w25q128", "jedec,spi-nor"; reg = <0x0>; spi-max-frequency = <40000000>; status = "okay"; }; };  
That gives me:
 
rock64@rock64:~$ dmesg | grep spi [ 1.172285] m25p80 spi32766.0: w25q128 (16384 Kbytes) rock64@rock64:/dev$ mtdinfo Count of MTD devices: 1 Present MTD devices: mtd0 Sysfs interface supported: yes rock64@rock64:/proc$ sudo flash_erase /dev/mtd0 0 0 Erasing 64 Kibyte @ ff0000 -- 100 % complete rock64@rock64:~$ sudo dd if=/dev/mtd0 of=test.bin status=progress 16642560 bytes (17 MB, 16 MiB) copied, 30.0011 s, 555 kB/s 32768+0 records in 32768+0 records out 16777216 bytes (17 MB, 16 MiB) copied, 30.4636 s, 551 kB/s So I guess something works...
 
Edit: The MTD device hangs at random points during write/read operations, I tried to create an ubi volume for testing purposes, but formatting the flash just hangs during the process...
 
root@rock64:/home/rock64# ubiformat /dev/mtd0 ubiformat: mtd0 (nor), size 16777216 bytes (16.0 MiB), 4096 eraseblocks of 4096 bytes (4.0 KiB), min. I/O size 1 bytes libscan: scanning eraseblock 4095 -- 100 % complete ubiformat: 1 eraseblocks are supposedly empty ubiformat: warning!: 4095 of 4096 eraseblocks contain non-UBI data ubiformat: continue? (y/N) y ubiformat: warning!: only 0 of 4096 eraseblocks have valid erase counter ubiformat: erase counter 0 will be used for all eraseblocks ubiformat: note, arbitrary erase counter value may be specified using -e option ubiformat: continue? (y/N) y ubiformat: use erase counter 0 for all eraseblocks ubiformat: formatting eraseblock 477 -- 11 % complete  
I tried to reduce SPI clock to 25Mhz bus still hangs at random points...

I think the idea of the quiz is more harmful than the quiz itself.  "Who are these guys to put barriers in the way?" etc.  In general it comes across as unfriendly, snobbish, unwelcoming.

I've run a couple small forums for Assembly Language programming/etc, I can say that no amount of quiz keeps out the machines.  And let's face it, do we want to make the bots smarter by feeding them harder puzzles?  Soon they will gain sentience. 

I think the idea of the quiz is more harmful than the quiz itself.  "Who are these guys to put barriers in the way?" etc.  In general it comes across as unfriendly, snobbish, unwelcoming.

I think the idea of the quiz is more harmful than the quiz itself.  "Who are these guys to put barriers in the way?" etc.  In general it comes across as unfriendly, snobbish, unwelcoming.

It has been 40 years since?   
 

Amazing clock increase, compared to stock 3.5Mhz 

I still have it, it's gotten so old it's actually a collectible by this point...

Well, if the under-powered hardware is the talking point, I used my TRS-80 model 100 portable as a linux terminal just to prove it could be done...

Wow!  I remember while working a co-op job in computer science in 1983, that one of my senior co-workers brought in one of those -- totally impressed me at the time

haha.. My dad was a reporter so he used his TRS-80 model 100 until like 1999 or 2000.   He'd always go back to it for writing his final copy.    "6 hours of battery life on 4 AA rechargeables" 

Well, if the under-powered hardware is the talking point, I used my TRS-80 model 100 portable as a linux terminal just to prove it could be done...

i always have to dig my electronic stuff out sadly.   I need more workbenches

https://sites.google.com/site/zberrysbc/
 
Is it worth it?  Assuredly not, but you can't help but smile if you have any sense of nostalgia.  It also doesn't help that the entire thing can be implemented in an FPGA, although that may actually turn out to be more expensive...

https://sites.google.com/site/zberrysbc/
 
Is it worth it?  Assuredly not, but you can't help but smile if you have any sense of nostalgia.  It also doesn't help that the entire thing can be implemented in an FPGA, although that may actually turn out to be more expensive...

Absolutely agree on that and was more talking about what happens in the future. In this specific case I see myself at fault since announcing to duplicate/recreate the thread and then not doing so timely. But fortunately we identified the issues quickly and those were fixed either internally or externally (thanks @Igorand Alasdair!).
 
But these issues should remind us that Armbian forum is not only used for internal discussion but also to have some impact on the outside (at least that's one of my uses, I still refuse to run my own thing/blog and try to collect knowledge here as part of a community to try to help letting the community grow).

Another update wrt upcoming ROCK64 board. It's still not decided whether Armbian will support this board anytime soon or at all but NAS results already look promising. USB3 performance is excellent (outperforming ODROID-XU4 easily) but currently we have discovered a few network issues while testing/evaluating the board (most probably we need to tweak so called TX/RX GbE delay settings).
 
But even without this tweak it already looks as follows:
 
These are the 'Enterprise network settings' (test size is 3GB and transmission block size 1MB):

These are 'Gigabit Ethernet' settings with just 300 MB filesize and 128KB blocksize:

It's pretty obvious that there's something wrong with network settings when we look at the sequential transfer speeds. Just compare with Pine64 above where USB2 storage is the bottleneck: there the test with 300 MB filesize runs entirely in RAM and Pine64 scores 66/78 MB/s write/read, with the Enterprise settings speeds drop down to storage performance: ~38MB/s in both directions. With ROCK64 all tests run entirely in RAM (I test with the 4GB model) and there's a significant drop in transfer speeds if we compare 1MB with 128KB blocksize.
 
My settings (TCP/IP offloading deactivated, eth0 IRQs on cpu3, USB3 IRQs on cpu2, performance governor, Receive Packet Steering enabled):
root@rock64:~# tail /etc/rc.local echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor for i in 1 2 3 ; do echo 4 >/proc/irq/$(awk -F":" "/xhci/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity echo 8 >/proc/irq/$(awk -F":" "/eth0/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity done echo 7 >/sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 >/proc/sys/net/core/rps_sock_flow_entries echo 32768 >/sys/class/net/eth0/queues/rx-0/rps_flow_cnt exit 0 root@rock64:~# cat /etc/network/interfaces.d/eth0 allow-hotplug eth0 iface eth0 inet dhcp offload-tx off offload-rx off hwaddress ether 42:40:08:16:da:2b The good news: This all is still WiP (work in progress) and I'm pretty confident that we see a performance boost in both directions soon (15-20 MB/s more each -- with Windows Explorer throughput numbers exceeding 100 MB/s should already be possible with appropriate OMV/Samba settings -- see here for an example and here for an explanation why Explorer performs better)

Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench:
I wasn't about to lie and clean it up before hand...
 

That's as good as it gets.  One of my (many) gripes.  Calling it "incomplete" is actually very kind.  It's crap.

Sure I can do that later today.

I have split 2 major support issues into their own threads, Bluetooth and Reboot.  I have gotten Bluetooth working on nightly builds of the default kernel, you need to use rtk_hciattach on every boot (add it to startup).  Next/dev kernels are still a work in progress.

some people mistook WIP to mean "WOW ITS PERFECT!"

Sent from my SM-G920V using Tapatalk

IMO this would make the forum look like a christmas tree with different colored tags and still won't stop people from posting things not really related to Armbian or in wrong forum sections.

I am expected to see Armbian running on mt7623n soc/bpi-r2 board.  
I have brought it with buildroot +  4.12 rc1 kernel with some dts pending patches in linux-mediatek tree.  
I will continue to add support to/maintain MT7623n and bpi-r2 board (of course, i mean it upstream).
 
But for upstream drivers, There is still some driver can't get support like hdmi, bt and wifi.  
For those temporary solutions, they should be able to be found though sinovoip 4.4 tree. 

That extra 10/100 ethernet seems like a good place to put an HDHomerun if you were running a TVHeadend server...

I've copied the same xenial mate into eMMC, tweak the /boot/extlinux/extlinux.conf to point to mmcblk1, and now it boot from eMMC.