Jens Bauer

I don't think I'll be able to donate 200 Euro this month, but I'll send an initial donation, so you at least can have an extra cup of coffee or tea. In around a month, I might be able to send a little more, though; in total, it should be able to cover one 16GB module. Hopefully a few others will see this and add to the pool. Looks like a fairly good purchase.

That's great. - now you have a connection faster than mine. That should help quite a bit. That probably means the best way I can contribute is to send a donation (which I've scheduled for the beginning of next month - I wish I could send more, but a small donation can help too). Is it possible for you to add RAM to your build-system - if so, what's the price of the maximum module size that can be added ?

High compression ratio is a good thing when Igor only has a 10Mbit line. I'm very much thinking that optimizing those developer's systems who works with it daily has the highest priority. -Of course, it's important to have a fast build system in general, but everyone have different platforms anyway, so like you say, a long time is a relative term. But if the developers who contribute to git regularly can get a speedup, I think it would help them from avoiding stress and (some) frustration. Does that mean that if I set up my system to use btrfs, that it would affect armbian builds in a negative way ? Answer accepted. If I come up with any other junk-ideas, I'll post them - if just one of them is helpful, it's worth it.

I know Zador mentioned that, but I find that it doesn't hurt much to have tools optimized by default on your daily-work machine - except from that any need for optimization of the compression in the scripts won't be noticable that way.

I'm only 1/3rd through the reading. These ideas might not be usable, but I'll dump them here anyway... While reading the first thread, I kept thinking about the parallel compressors (I've been using them for more than a year). pigz, pbzip2, pxz, plzip. I've rebuilt tar, so it uses the parallel versions by default. -So if compression takes a long time and you don't have a parallel tar yet, I recommend building one. It doesn't always produce the exact same results for the same files; sometimes the archives use a few more bytes, sometimes they even use less than the non-parallelized version, but I've tested the archives and they're completely valid, even though the size differ. (in fact it should be possible to make a fairly simple "dist"-tar script, which could copy the image to a random-picked TV-box that will do the actual compression and then feed the compressed result back to the script; then the "dist"-tar script's parent could run in the background and upload the data when they get back). -I very much second using btrfs (I already use it myself). I wonder if an overlayfs can be of any use (eg. a "temporary file system" for a quick-clean perhaps - or some sandboxing).

It will take a while before I can try it (perhaps more than 6 months before I can go to the place where the R1 is), so you'll need to be patient. My "disappearance" has been there already when my Mac died. For a month I've had to suffer from using an old 3GHz dual core P4 with 1GB RAM (not much fun when waiting half a minute to several minutes for the screen to redraw after moving a window - that's just one of the many 'too-slow' problems - even a CubieBoard2 can do better).

This might be close to be off-topic, but I think this is the closest forum for this thread. Since I read that Igor asked if we know any build-farm services (clouds like Amazon's EC3 or the like), I've been thinking about private build farms. I imagine that Igor does not have a large build farm (perhaps some boards are contributing with distcc). Thomas, what is your setup for building Armbian ? (I imagine that you may have a stronger setup). Other developers, please chip in too. What's been in my mind for a while, is to make a low-cost farm, which would perform well and make things easier and quicker for the Armbian team. There's a lot of maintaining of the source code, so I doubt there's time for expanding compile-clusters. So my idea is that first of all, I get that ubuntu Xenial running on a 64-bit intel CPU is the minimum requirement for a build-master. That is due to some of the tools that Armbian uses. If those tools were able to run on an ARM-based architecture, it would be easier for me to find a good build-master for Armbian (I'm going to use MacchiatoBIN for my own builds). The slaves would most likely be MiQi boards as they perform better than even the S912 competitors (but they also use more electricity). Finally I plan to use solar power to assist in paying the bill. When all is set up, I think it would be very useful to add external build slaves as well (such as every developer's build slaves, so that distcc can do the job as quickly as possible. I know that more isn't always better; it depends on the connection speeds and the speeds of the slaves, latencies and a lot of other things. -Still the goal is to get an almost 'free' build farm, which is able to build Armbian on its own (so if you're on a non-intel platform (such as PowerPC or ARM), then you will be able to make your own builds anyway by using my build-master. On the other hand, if you have a 64-bit intel machine, then it would probably be beneficial to use that as a build-master, because local is usually faster than remote. It can use the compile-cluster for compiling, but the intel-only tools could be run locally. I might not be able to succeed in all this; it's an expensive project and I have many higher priorities than making a build-farm; but if things go my way, I might be able to move the priorities around (I certainly want to). Maybe I'll be able to start out with a few MiQi boards and no build-master and then expand over time.

That is so annoying. -But please make sure that it actually is the CPU that needs to be blamed and not the RAM-speed. I'd like to see a comparison of a TV-box having DDR4 RAM installed against one that has DDR3 RAM installed - I wonder if it makes any difference at all. (Since this is a S912 thread I've restricted myself from comparing to other CPU vendors, but it seems that Amlogic is not the most interesting vendor anymore).

Putting myself in Jin's shoes, I think I would probably not be able to make support for pfSense. Fortunately for me, Jim is more experienced than I am, so while it might be difficult or even very unlikely, it's still not impossible. -OK, I will not get my hopes up. OpenWRT is not bad router firmware either. -But know this: If pfSense ever becomes available for ARM-based devices, I will make the switch (pun intended). I was about to say: "Then I will do it!". But if it means I'll magically disappear, I don't know anymore. -I have nothing to lose by trying. At the moment, my R1 is packed down in some cardboard box somewhere 200 km from where I live, because I didn't even succeed in getting it to boot Armbian from the MicroSD card. I certainly have several 0603 resistors of value 2K2 (and I believe other values would do as well; perhaps all the way up to 10K, but let's just keep it at 2K2). -If it can outperform my DIR-655 (which I do not expect), then I will use it as firewall+router and make it possible for software running on other devices to blacklist IP-addresses automatically (by using attack-traps).

If the switch is really bridged by default, then I ofcourse hope they made a strapping-option too. -But if they haven't made an option, it should still be possible to expose a few traces and make a 'green-wiring' using the 2K2 resistor. It would definitely be worth it. The only reason I didn't already purchase the ExpressoBIN is that a mPCIe 1Gbit Ethernet card would cost just as much as the device itself. But if I can get the ExpressoBIN with 2GB RAM and modify the default setting of the switch so it's not bridged at startup, then I'll certainly do it. I wonder if it can match my D-Link DIR-655 (which I bought used) in performance! -Having the switch bridged is an advantage if you use the ExpressoBIN as NAS, though. Connect all 3 ports to your switch and you may be able to gain some speed if your NAS is accessed by multiple clients at the same time. Link Aggregation probably won't give you any extra speed, though, since all the ports are connected to a single 1Gbit Ethernet port on the CPU, but you'd have to try it and compare the results with having only a single port connected.

I explicitly asked GlobalScale and they replied that it was bridged by default. Please correct me if the ExpressoBIN is indeed not bridged by default as this is a very important piece of information. -But even if the switch is bridged by default, it's still possible to add an extra Ethernet port, without board modification, so the ExpressoBIN can be used as firewall+router. But what you're saying is that if the ExpressoBIN (or any other router) is using a Topaz switch, the error can be fixed by (maybe cutting a trace and) adding a resistor ? -That would also mean that if I can get my R1 to boot Armbian, I would be able to use it as a router by fixing that problem ... I value the information you've provided me with very much; thank you.

Since pfSense is about to be supported on the Armada 385, the foot is already in the door. While the 385 is not the 3700 nor the 8040, there will be similarities in how the hardware is made (since a company does not change hardware design "overnight"); this will give driver implementation on those platforms a little further help. I'm not saying it will be easy, just that once pfSense runs on one Armada based system, the next Armada based system suddenly seem a whole lot closer. Marvell seem to understand that communities are important. The fact that they even link to SolidRun from their Web-site is a sign that they're not as "closed" as they used to be. If the Armbian and MacchiatoBIN+ExpressoBIN+WaderBIN communities can convince Marvell that they need to release some information on how to use their hardware, I think Marvell would consider it. That happens ... I'll try not to go further off-topic, though. I'm looking forward to reading your posts on the subject.

Spot on. -But I still wonder why they didn't just put a smaller, more power-saving Cortex-M core inside (they already have the license). The CPU would most likely not be so busy, once it's set up the peripherals.

I'm sorry that I've been a little "imprecise". Marvell made a Topaz switch PHY, which is an IC (not a completely assembled device; just the component). Inside the PHY is a bunch of goodies, such as DMA and peripheral controller logic, but they also added a CPU core, ROM and RAM. The CPU core is using today's technology, which means it can run a lot faster than the the CPUs we had in the 80's. Eg. smaller circuitry, smaller component = shorter paths, lower voltages = shorter transitions times, etc. All resulting in the thing is being able to be clocked at higher frequencies. -But remember, since Marvell made their own implementation, they would also be able to optimize the different stages in the CPU. You could compare it with making your own CPU on an FPGA - or even emulating a CPU on a 4 GHz intel (or even ARM) processor; it would be possible to run the Z80 code much quicker. -Sadly, if you purchase the Topaz PHY, you can't just start putting your own Z80 code into it, so forget about upgrading your Spectrum.

No, unfortunately I haven't gotten any of their products (yet), but that could certainly change. -But I've known about pfSense for a long time - and I plan on installing it on the MacchiatoBIN once I purchase it. (I even believe that many "gamers" know pfSense, since it has excellent performance). Actually I think I've seen the SG-1000 a while ago. -Unfortunately for me, I live outside the US, which means purchasing from there can be a problem. 1: If you're out of luck that day, the item is returned straight to the sender. One reason can be that you're not registered with the government for import. 2: If you're lucky, the purchased item gets through customs and you're billed an additional 0.25 * (item-price + shipping price). If that price exceeds $175, then it's multiplied further by a number between 1.00 and 1.25 (usually 1.05, but it depends on what kind of item you've purchased). The item is held until you pay, but the web-site which handles the payments is only compatible with very few Web-browsers.

Of course it is. I guess the reason I don't think about doing that is the "messy cables". Actually I was thinking about after "retiring from the one job", it can be "used for the other". -But to tell the truth, I will be combining a router+firewall and nas on my private network at home. The reason for this is that I usually don't have a lot of disk-access while I'm having a lot of network traffic. I will also be using the same box as a build-master (controlling a bunch of slaves). -Again this will be the primary reason for getting the MacchiatoBIN I'm talking about here. The "router+firewall" and "NAS" will just be the board's "relaxation jobs". That indeed looks promising! -When I saw the title, I first expected a joke, but was positively disappointed. Such a board / box running pfSense would be a small killer-board (as long as they make sure it works, but it seems they do have both development and testing skills). I particularly like the line: "We also believe everyone should be able to afford it."

What would you say, if I told you that you can actually purchase a recently manufactured board today, which runs Linux and has a 200MHz Z80 connected directly to a Gbit Ethernet ? In fact you might soon be able to run Armbian on it. It's the ExpressoBIN. Yes, yes, it's powered by a Marvell Armada CPU and the Z80 is inside the Topaz switch, but still it's impressive that they use Z80 and not a Cortex-M3 or Cortex-M4 for this (They do use 320MHz Cortex-M3 in some of their SATA controllers, though). -But I really find it impressive that the 10MHz Z80 is still selling today; it's sold at a higher price than a Cortex-M3 (STM32F103) running at 72 MHz - see Farnell or Newark!

Sorry to say this: No, it has the same problem as the Lamobo-R1: The WAN and LAN ports are bridged until the network is initialized; this allows attackers to reach inside your LAN and spread spam-bots or other bot-nets in your LAN if you use the R1 or R2 as a firewall+router. Purchasing the R1 was a mistake. I've spent so much time trying to get it to do at least something, but no luck. It's in a different location from where I am located right now; packed down in a box somewhere. -Perhaps I can use the power supply for something, but that's all. I've given up on it.

So far, CubieBoard2 is my favourite. It's running as a NAS, Web-server and other servers. I even connected two harddisks via a port-multiplier (though I know I shouldn't, as it's possible I'll get my data corrupted). It's not extremely fast either, but gets the job done and does not use much power. Sometimes I also give it 'background jobs', such as letting it download files for me in order to keep the load on my desktop computer down. Sometimes I build Cortex-M code on the CubieBoard2, so I can quickly stress-test the code (qa). Also I like this board, because it was easy to get it working with Linux (compared to Lamobo-R1 and CS918). As mentioned elsewhere, I'm thinking about purchasing either a bunch of MiQi boards or Yoka-KB2 TV-boxes. Those would be used for a build-farm (cluster-compiling - see MiQi for more info about making a low cost build farm). If I end up getting the TV-box, I'll get those with 3GB DDR4 RAM (it has Gbit Ethernet). I also plan on getting a MacchiatoBIN as a 'build-master', since it has 2 x 10Gbit Ethernet and can be used as both a router and a NAS.

I think it's even more amazing that the Z80 still sells!! I've seen Z80 clock frequencies up to 200 MHz (Marvell), so even the 20MHz is quite low.

I've seen that Armbian support for ExpressoBIN is on its way. The CPU on this board is made by Marvell, who are experts in high-performance CPUs and buses (SATA, PCIe, ...) Personally I expect this board to be a great choice for a NAS, but as this board has the exact same problem as Lamobo-R1 (the 'LAN' and 'WAN' Gbit ports are bridged), it's not a good choice for a router+firewall unless you add a WAN port on the MiniPCIe and keep the 3 bridged switch-ports on the LAN side.

This information is indeed very useful! 4 x 1.5 + 4 x 1.0 (10) ... against 4 x 2 GHz (8) . Remembering there's a small loss of speed due to things that requires single-threading/tasking ... That's close to 4x2 against 8 x 1; but if compiling/building software, the speed gain will probably be more noticable. -But I do believe that there *is* a performance gain; or perhaps a 'responsiveness gain'. (Eg. the PC I'm using at the moment sometimes stalls while moving the windows, typing or when moving the mouse. After several seconds (up to a minute), the window wil move or the mouse arrow will move). Having multiple cores can in those cases make the computer/device more responsive. That I don't know, but I remember reading a while back, that it was only possible to run at 4x2 GHz or 8 x 1 GHz. This means that someone must have done something to improve it. I've been battling with myself about whether I should purchase a bunch of MiQi devices for a build-farm or a bunch of Yoka-boxes (I will be purchasing a MacchiatoBIN as build-master either way).

I came across "Peer-to-peer technical support", today and noticed there were "101 topics".

Quite nice indeed - and a very low power usage. -How fast do the cores run ... 8 x 1 GHz or 4 x 2 GHz + 4 x 1 GHz ?

I'm interested in an update (as I might want to purchase a Yoka KB2 with 3GB DDR4 RAM): Did you solve the static IP problem completely, or do you need to use a dynamic IP still ? How do the latest images work with the Yoka KB2 ?