Jens Bauer

UK Server deployed. Details PM'd

https://forum.armbian.com/index.php?/topic/3945-mmc-no-card-present-error-on-allwinner-boards
 

It should be 378. It's some time since 60GB was set  Everything is fine. Many new boards and Bionic as a test option on some ... with some cleaning and with some additional logic, this could be brought down. But its some work.

This is how I've currently set up my u-boot:
setenv bootcmd 'run boot_armbian' setenv boot_armbian 'run get_images; run set_bootargs; run load_script2; booti $kernel_addr $ramfs_addr $fdt_addr' setenv get_images 'tftpboot $kernel_addr $image_name; tftpboot $ftd_addr $ftd_name; run get_ramfs' setenv get_ramfs 'if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -; fi' setenv set_bootargs 'setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none nfsroot=$serverip:$rootpath $extra_params' setenv load_script2 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else echo "booting from SATA"; scsi scan; setenv boot_interface scsi; scsi dev 0:1; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' # A suggested, but untested SATA-boot (try MMC first, then USB, then SATA): setenv load_script3 'if test -e mmc 0:1 boot/boot.scr; then echo "... booting from SD-card"; setenv boot_interface mmc; else usb start; if test -e usb 0:1 boot/boot.scr; then echo "... booting from USB"; setenv boot_interface usb; else echo "booting from SATA"; setenv boot_interface scsi; scsi scan; scsi dev 0:1; fi; fi; if test -e $boot_interface 0:1 boot/boot.scr; then ext4load $boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' There might be typos, because I don't have any copy-and-paste from my serial terminal and in addition, load_script3 has not been tested, so it may contain errors as well.
-But you should get the idea; it's in fact just a tiny addition to armbian's default setup.

I've set up my local EspressoBIN with 18.04 Bionic (Armbian_5.44_Espressobin_Ubuntu_bionic_next_4.14.40.7z).
 
My impression is that it's very much like setting up Xenial and the same issues seem to be present.
I mention them in the order of importance.
1: #reboot sometimes hang, so does #poweroff. It would be great to get this fixed, because it would be a disaster if a device hangs on rebooting from remote (eg. the device is 200km away).
2: sudo apt-get update && sudo apt-get upgrade destroys the network setup. No network access is possible after doing this. I think a fix is important, because people would likely issue those commands.
3: Network seem to be configured slightly different than on Xenial; it seems I cannot configure a static IP on the WAN port (see my other post specifically on static IP). For now, I'll be using a static IP address on the br0, this works, so it's not the highest priority.
 
I definitely also need to write some good stuff.
 
1: 3Gbit JMB321 Port Multipliers work well with Xenial (and likely also Bionic); just remember to connect the boot device to SATA0 and there should be no problems.
2: 6Gbit JMB575 (StarTech) works great with Bionic (and likely also Xenial); again connect the boot device to SATA0.
 
 
For those, who want to boot "directly" from SATA, this is what I do on both boards; it's fairly easy and there are plenty of ways you can do it.
The first time, I just made a 'dd' from my SD-card's partition to my harddisk's partition. This works fine and the partition will be expanded when Armbian boots.
My preferred way, though, is to make a tarball of the unmodified SD-image's partition, boot my EspressoBIN from the SD-card and extract the files onto my desired partition. This gives me a different UUID from the SD-card, thus inserting the Armbian SD card won't confuse my boot-up sequence.
 
To create a tarball, this can be used (mounted as /mnt/sd) ...
cd /mnt/sd && sudo tar -cpzf /data/armbian-bionic-rootfs.tar.gz .
 
To extract onto your partition (mounted as /mnt/rootfs), this can be used ...
cd /mnt/rootfs && sudo tar -xpzf /data/armbian-bionic-rootfs.tar.gz -C .
 
Those will preserve permissions, timestamps and other attributes as necessary, but this will only happen if you're root, otherwise permissions will be messed up and you'll get a half-working system (quite useless).
 
I use a custom UUID on my own setup, so that I only need to set it once in u-boot. I highly recommend using UUID for identifying the boot device, especially is you use a port multiplier, because you never know if a USB-drive suddenly get /dev/sda instead of the drive you expect.
 
In your startup boot sequence, I recommend a 3-stage check ...
1: Check for SD-card (SD/MMC slot)
2: Check for USB-boot
3: Use a 'scsi scan; scsi dev $bootdev:$bootpart;' then check for your SATA-device here.
 
Personally I only have step 1 and 3, since I often mount my SD-card as a USB-drive when I do not want to boot from it.

For those who want to run at 1.2ghz, if you have not noticed you need this:
https://marc.info/?l=linux-arm-kernel&m=152941191324122&w=2

apt update & upgrade will also do
https://github.com/armbian/upload/commit/553477df85dfdd33810d1536409d62bd3a4cb789
 
Thanks.

If anyone is interested in lowering the heat from the board, I've used a 5.9V/3.8A switchmode power supply with great success.
A 5.2V/2A PSU should be enough, though - my PSU just happened to be 3.8A.
The Voltage range for the PSU should be above 5.2V and below 12.5V. There is an on-board 13V zener, this is in order to try and protect any attached harddisk from a spike.
As for current, anything above 2A should be fine. If you're planning on powering a 3.5 inch harddisk from the board, stick with a 12.2V PSU.
-If you're planning on using a 2.5 inch harddisk, you can run on low input voltage between 5.2V and 12.5V.
 
Personally, I'll be using 2.5 inch WD Red drives because they consume very little power.
I might also add a liquid cooler (cheap aluminum blocks from eBay and a silent <5dB, <6W, 0 .. 8L/min pump) - I hate noise.
Note: I have not had any crashes or other issues with my 2GB boards - not even while running the boards on a 12.25V PSU with a 3.5 inch harddisk; the cooling is likely not even necessary, as the boards will be installed in an always-cold room. If, however, I add the cooling, I'll run the pump slowly, so it'll likely use less than 1W anyway.

http://www.tomshardware.com/reviews/usb-3-uas-turbo,3215-4.html
 
USB Attached SCSI

Apparently yes
 
Not sure if it's a matter of a simple PCIe cable or not (it implies that's the case for "local networking" between two PC's, a PCIe switch for a network of more than two) but if you scroll down just past half way here, it mentions it
https://www.onestopsystems.com/blog-post/pcie-over-cable-goes-mainstream
 
The PCI Express bus has direct access to system memory, I don't see why either side of the point-to-point connection can't be the initiator.

Well, I'm surprised why people expect $anything from TV boxes. These things aren't for Linux enthusiasts but for clueless people that only buy numbers (8 CPU cores vs. 4 cores --> 8! 2 GB DRAM vs. 3 GB DRAM --> 3! $30 vs. $28 --> 28!). They have to look performant by specs while they have to be as cheap as possible for their target audience to buy them. Why does someone think both can work at the same time?
 
This means manufacturers don't have to take care about performance but only about cluelessness (use 8 cores even if it's totally useless since the competitors also use 8 cores now so you are not able to sell faster boxes with less CPU cores anymore in the markets where they make money, put recycled DRAM on the PCB and combine it with an u-boot that dynamically tunes DRAM clockspeed down until the box doesn't immediately crash so you as manufaturer can afford putting 3 GB crappy/slow DRAM on board since customers would never buy your box with 2 GB faster DRAM)
 
And then this kind of 'cheating' also happens everywhere. Don't know exactly how it works with Amlogic (since I consider all their SoCs not worth a look, might change if a dev board relying on Amlogic A113D appears) but I know how it's done with Allwinner and there it's easy: the 'board support packages' (BSP) TV box vendors get contains a kernel with a list of cpufreq operation points (that's the entire 'up to x.x GHz' thing) that does not need to have any relationship with reality (Allwinner sets 1536 MHz here for A64 as an example). Then there are other settings defining how voltage and clockspeed relates (DVFS) and then there's another settings defining thermal behaviour. The result is that the TV box will be marketed as 'up to 1.5GHz', the real settings already prevent everything above 1152 MHz and due to shitty thermal design of most boxes the SoC won't even see those 1.1GHz when running under constant load since already throttled down to less than 1 GHz. And their target audience is happy since in Android's CPU-Z and stupid benchmarks like Geekbench '4 cores @ 1536 MHz' is listed and that's all they care about,
 
IMO interesting read: https://www.cnx-software.com/2017/09/12/factory-price-of-some-tv-boxes-and-accessories/#comments

To secure top download speed around the globe, we need to have as many torrent seeders as possible. Currently we have dedicated seeders in: Estonia, Germany, Pakistan, Slovenia, Argentina, Singapore, USA, ... but we might be slower in China or Japan.
 
Prerequisite:
 
- Armbian or any Debian or Ubuntu based distribution (check instructions how to run armbian-config on a generic Debian/Ubuntu),
- 1TB of free space.

a) Installation with installing Transmission server
 
login and obtain superuser rights, execute armbian-config, select Software -> Softy, install Transmission server. (use space to confirm and enter to proceed with install)
   
Leave armbian-config and after a few minutes check your torrent server status with the following command:
transmission-remote -n 'transmission:transmission' -l and you should see some progress:
 

Note:
Torrent server installed this way is auto updating - it checks daily for new images, adds new and purge old ones.
 
 
 
b.) Installation to the existing Transmission server
 
You only need to install a cron job script that your client serve only most recent files.

Create file:
sudo nano /etc/cron.daily/seed-armbian-torrent with this content:
 
 
Change username(transmission) and password(transmission) if have something else than stock, save and exit, then run:
sudo chmod +x /etc/cron.daily/seed-armbian-torrent sudo /etc/cron.daily/seed-armbian-torrent Optional:
 
If you use GUI, you can install desktop front end for simple torrent server monitoring.
 
apt install transmission-remote-gtk Host: localhost
Username: transmission
Password: transmission

Confirm and click connect.
 
 
How to stop seeding torrents?
Remove cron job: sudo rm /etc/cron.daily/seed-armbian-torrent  
Remove torrents:  transmission-remote -n transmission:transmission -t all --remove-and-delete This command will remove all files on your torrent server! If you seed other stuff do a cherry pick.
 

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.

I use a BPI M1 as file server. I use 2.5i disk because it doesn't need 12V, don't make noise, is less cumbersome ... and if I want better access time I use an SSD !
 
So, in order to avoid problems, I power the disk directly, that is : not threw BPI and I power the BPI through the disk power connector. Soldering is not a problem : you can use screw terminals. But you need the connectors and be sure of your polarity !
 
My experience with powering 5V boards and accessories is that you must avoid multiple connectors interfaces. Micro USB is not top, but USB-A is still worse and in fact there are very few connectors able to deliver peak power reliably on 5V. I use a PSUs with voltage adjustment capability and screw terminals and for a server, I use as little connectors as possible and I don't power accessories (USB or HDMI adapter) threw the board : only so were I able to solve stability problems.
 
In fact, I have had so many problems that from now on I will only use soldering and screw terminals !

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.

That's great, so we won't have to ban @TonyMac32right now! Nice feedback from your side. Maybe creating a tutorial 'how to help the right way?' or something like that?  
 
I really wonder how the average forum joe today would react when being confronted with http://www.catb.org/esr/faqs/smart-questions.html

Actually, I remember noticing a few pages back in c-ray, 8-core performance was not scaling as expected, so the issue was already there as well. We were trying to test HMP at the time, that's why nobody thought about doing single-threaded tests.
 
Turning off little cores makes the frequency scaling behave like any 4-core S905 system, including single-core performance. That's the problem (bug?) here, that is, as long as all cores are online, the frequency gets lowered, even if just 1-2 cores are being used. 
 
@buvaluy Could you try the most obvious test, activating just one little core to see what happens? Provided you already have just 4 cores active, add one more:
echo 1 | sudo tee /sys/devices/system/cpu/cpu4/online  

I never called you a liar.  I was suggesting that making statements in BOLD like MORE THAN 12 VOLTS, WILL BE FRIED, WILL BE USELESS are not constructive.  I fend many comments from people who got back from the store with their shiny new DVM and immediately post "I JUST MEASURED MY POWER SUPPLY AND IT IS SUPPOSED TO BE 12 VOLTS AND IT IS 12.4312345 VOLTS!  I AM AFRAID!!"
 
I refrain from asking them not to post voltages to 6 digits and comfort them that 12 1/2 volts is fine.
 
I agree with you that it is silly to buy cheap, buy twice.  And that it is not wise to buy a cheap power supply.  That may be why I have a HP 6281A supply on the desk next to me powering my latest little board.
 
But, that does not mean I was suggesting you were telling a falsehood when I noted that modern computer equipment has a wider tolerance for input voltage than you indicated.  Due diligence and caution are justified.  Crappy power supplies are the bane of us all.  But can we please keep it to the level of appropriate caution and not try to entice uncertainty and doubt where not needed?
 
I bought a power brick a few years ago that provided 12V 2A and 5V 2A on a 4 pin molex plug.  I use it when I am running a hard drive on the bench with a usb->sata dongle.  I just checked and Amazon sells them for 15-20 USD.  Something like that might be a better choice for running a hard drive than combining two separate supplies, especially since that is what it is designed for.  There is nothing inherently wrong with using two supplies or using a regulator to drop 12V to 5V if you are handy and so inclined.  I just found it more convenient to have a single block plugged in to run power the drive instead of having two and a mess of wires to convert the outputs.

1. Download, unzip, burn image. Armbian_5.24_Amlogic-s905x_Ubuntu_xenial_3.14.29_desktop_20170118.img.xz
2. Replace the first section of recorded media 3 file ("zImage" "S905_autoscript" "S905_autoscript.cmd").
3. Add the file "/etc/fw_env.config"
4. Replace 2 file "/root/install.sh"  (Do not forget to set the permissions on the file install.sh to 755)   "/root/linux.img"
5. Try to start the system with the prepared media. If the system fails to start, copy it to the root (first) partition of the carrier of the correct dtb file (with the name "dtb.img").
6. After a successful system startup and initial setup, be SURE to check the operation of all necessary devices (Wifi , sound). If something doesn't work, you need to deal with the dtb data.
7. If launched from external media system works as You need, you can proceed to install to the internal memory. Pre-creates a copy of the internal memory. The procedure of backup may be different. You can use existing image scripts (ddbr_backup_*).
8. To run the installation process in for internal memory you need to run the terminal and execute "root" the command "sudo /root/install.sh" or to execute two commands "su -" (enter password of user "root") and "/root/install.sh".
 
https://yadi.sk/d/i8mKgFEi3BW24i
 
 
TO ALL.
Found an error in the script s905_autoscript , which does not use data from dtb in the internal memory (required manually copying the file). Loaded into the directory FIX the fixed version. You can download and replace in your images this script.

Collected for the current kernel. Try this file. If it works, I will include it part of the kernel source.
 
https://yadi.sk/d/ylvdnnIF3BgNtC

Hi,
 
I'm using it, so the answer is yes!

Hi dxs1,
Unfortunately my kernel will do nothing different for audio output.
 
the modules I have compiled are only for "midi sequencer" communication.  They have nothing to do with audio output.
 
Also, I could be mistaken but I'm pretty sure the amlogic drivers for sound output are already in the original kernel configuration, so that is likely not the cause of your issue.
 
I'm personally using this strictly for video/image output, so I have no experience with audio output on the S905X.
 
I would suggest creating a new thread, so that more people will see your thread title and can help with your problem.

I have tried to boot following images from SD Card
 
- Armbian_5.24_Amlogic-s905x_Ubuntu_xenial_3.14.29_desktop_20170127
- S9xxx_4G_ICEWM_MATE_XFCE_LXDE_LXQT_20170122
 
Result: HDMI screen remains black. 
 
My understanding is that a dtb.img specific to T95Z Plus device must be copied to the FAT partition.
 
I have managed to copy /dev/block/boot from T95Z Plus Android directory and renamed it to boot.img
(zipped and attached to this post as boot.img.tz95plus.zip)
 
Then I have downloaded split_bootimg.pl and used it with this boot.img
./split_bootimg.pl boot.img Page size: 2048 (0x00000800) Kernel size: 7419928 (0x00713818) Ramdisk size: 917780 (0x000e0114) Second size: 41699 (0x0000a2e3) Board name: Command line: Writing boot.img-kernel ... complete. Writing boot.img-ramdisk.gz ... complete. Writing boot.img-second.gz ... complete. I got these files: boot.img:            Android bootimg, kernel (0x1080000), ramdisk (0x1000000), second stage (0xf00000), page size: 2048 boot.img-kernel:     gzip compressed data, max compression, from Unix boot.img-ramdisk.gz: gzip compressed data, from Unix boot.img-second.gz:  Device Tree Blob version 17, size=41699, boot CPU=0, string block size=3307, DT structure block size=38336 Then, result of hexdump -C -v boot.img-second.gz | grep "d0 0d fe ed" is 00000000  d0 0d fe ed 00 00 a2 e3  00 00 00 38 00 00 95 f8  |...........8....|   How can I get the dtb.img from this point ?   Also, I ran dtc -I dtb boot.img-second.gz -O dts -o tz95plus.dtd I got this file: tz95plus.dtd: ASCII text (zipped and attached to this post as tz95plus.dtd.zip)    
boot.img.tz95plus.zip
tz95plus.dtd.zip

Hi all
 
Here is recipe I use to natively build S905/ordroid kernel. Note this is on gentoo so initramfs details differ from ubuntu practice.
**** BACKUP /boot /lib/modules /lib/firmware **** **** choose 4.9 gcc **** gcc-config aarch64-unknown-linux-gnu-4.9.4 . /etc/profile export ARCH=arm64 git clone https://github.com/150balbes/Amlogic_s905-kernel.git cd Amlogic_s905-kernel git checkout S905X  or git checkout odroid make clean make mrproper # S905X wget https://raw.githubusercontent.com/150balbes/lib/master/config/kernel/linux-amlogics905x-default.config cp -p linux-amlogics905x-default.config .config # odroid cp -p ../config-3.14.79-vegas95 .config make oldconfig make -j3 Image make -j3 modules make -j3 dtbs cp -p arch/arm64/boot/dts/*.dtb /boot/dtb/ make modules_install make install make firmware_install # S905X dracut --kernel-cmdline "root=LABEL=ROOTFS boot=LABEL=BOOT" initramfs-dracut-arm64-3.14.29 3.14.29 cp -p initramfs-dracut-arm64-3.14.29 initrd.img mkimage -A arm64 -O linux -T ramdisk -C none -a 0 -e 0 -n uinitrd -d initrd.img uInitrd # odroid dracut --kernel-cmdline "root=LABEL=ROOTFS boot=LABEL=BOOT" initramfs-dracut-arm64-3.14.79+ 3.14.79+ cp -p initramfs-dracut-arm64-3.14.79+ initrd.img mkimage -A arm64 -O linux -T ramdisk -C none -a 0 -e 0 -n uinitrd -d initrd.img uInitrd # install them in /boot unset ARCH=arm64 **** restore previous gcc **** gcc-config aarch64-unknown-linux-gnu-6.3.0 . /etc/profile  
depends on S905x or odroid your boot could look like
 
 S905x
aml_autoscript      amlogics905x_init.sh  config-3.14.29  dtb.img             s905_autoscript      s905.start          uInitrd aml_autoscript.zip  boot.bmp              dtb             initrd.img-3.14.29  s905_autoscript.cmd  System.map-3.14.29  zImage  odroid aml_autoscript        boot.bmp         dtb.img              s905_autoscript.cmd  uInitrd           zImage aml_autoscript.zip    config-3.14.79+  initrd.img-3.14.79+  s905.start           uInitrd-3.14.79+ amlogics905x_init.sh  dtb              s905_autoscript      System.map-3.14.79+  vmlinuz-3.14.79+ The script files come from Balbes distributions.
 

Desktop image releases will be only based on Ubuntu LTS - easier to support a LTS release when you have to provide additional packages for the HW acceleration stuff.
Server releases will be both Debian and Ubuntu, once Debian Stretch is released (probably in several months) Ubuntu Xenial will be more outdated compared to it in terms of package and default compiler versions, it's just currently the latest Ubuntu LTS release is newer than the latest Debian stable release.