arm-push

Then I think it's not working properly in 4.14.33. I did try adjusting the cpufrequtils file. e.g.: 200 to 1200. Frequency was shown as 1200 all the time, but I saw rapid transitions between a lower frequency and 1200 in the transition table. something wrong with it I guess. However I'm using the legacy ( 4.4 ) and frequency scaling is working in that kernel as expected.

But I thought DVFS is enabled in 4.14 path. see @Igor's post.

Marvel 88SE9215 works with the next branch. Anyway CPU frequency is not changing based on the load . It shows as 600 and not changing.

Thanks. I'm going to try it. Will provide an update once it's done.

Has anyone tried Marvel 88SE9215 with the mainline kernel? I'm using it on a bit old armbian version. Just checking before messing with the bin.

Are you running this without a heat sink?

@ebin-dev what's the latest from the enclosure project?

Then for the mPCIe use case, we will have to drill few holes in the top of the enclosure to attach a 4cm fan.

Thanks for the update @ebin-dev just out of curiosity, how is the heat dissipation of the card? tkaiser had mentioned here that this chip gets very hot. Will this need a small fan inside the enclosure?

Perfect. Thanks for the update @ebin-dev I'm also going to buy the same mpcie card soon, but waiting for your feedback on how it's going to work with espressobin.

@ebin-dev, have you received the controller or still waiting?

I'm using 5.37 now. built by myself. No network issues.

I was going to buy that. But bought the ASM one because it was the cheapest one. I should've thought more seriously about the "Buy cheap, buy twice" slogan.

@tkaiser sorry about that. I have missed it. This is for the default kernel. Also the card has been updated with the firmware. http://sprunge.us/DKIT from dmesg | grep ahci

I have another SD card which has the default kernel. So I rebooted from it and still get the same error. root@espressobin:~# uname -a Linux espressobin 4.4.96-mvebu64 #14 SMP PREEMPT Sun Nov 5 01:06:18 CET 2017 aarch64 aarch64 aarch64 GNU/Linux I do not get any issues when I connect my WD red or WD Blue hard disks directly to the espressobin sata port. I tried them on both default and next kernels. So I think this issue is not relevant to the bug you are referring to. This should be something related to the mini PCIe card.

1. ASM1061 printed on the chip 2. I'm powering up the board and the disks using a MEAN WELL RID-50A 54W 5V 12V power supply. (This time I'm using only one disk. It's connected to the card) Hard disk is powered directly from the power supply. it's not powered by the on-board molex connector. 3. It's not even mounted. I'm getting the trace when I try to mount the disk smartctl output, 4 & 5. yeah. it's a cheap one ordered from AliExpress 6. Unfortunately I was too late. I ordered this a few weeks ago and received it today.

Getting an error once I attach disk. I have posted the information here

I attached a Mini PCIe to 2 Ports SATA 3.0 III Expansion Card to my espressobin. (ASM1031) Once a disk connected to it, I'm getting this kernel error. Tried to debug using objdump, but I do not know how to extract vmlinux from "vmlinuz-4.14.2-mvebu64" file vmlinuz-4.14.2-mvebu64 command shows the kernel is MS-DOS executable, MZ for MS-DOS. lspci output, trace,

Thanks @tkaiser yeah, It's a ASM061. I don't expect much from it. My main disk already attached to the on board SATA port. Other disks which I'm going to use for backup purposes will be attached to this.

No, I'm not going to use all the 4 ports. Not going to implement RAID as well. Actually what I ordered has only 2 SATA ports. I attached the 4 SATA ports image to give you an idea about the requirement. I actually have a IcyDock enclosure for hard disks. I have removed the original fan and attached a noctua fan to it to reduce the noise. Therefore in my scenario, I need to connect the SATA cables coming out from the espressobin enclosure to the IcyDock SATA ports

Yes, I thought about that as well. Since this has not hit production yet, I'm trying to push ebin-dev to consider this option so we will not need additional work on the enclosure.

The expansion card will be like this. Instead of keeping the enclosure open all the time, it would be great if we could have an additional hole in a slide plate which can be covered by a hole cover cap or something similar to that.

This is good news.

Wow. This is very nice. From my experience I can also agree with you that the passive cooling of the CPU and the topaz switch by thermal coupling to the metal housing gives the best result. This is very nice. When I built my casing, I used copper shims between the enclosure and the SoCs. As I remember, you cannot just mount the enclosure on top of the SoCs as the soldering joints touch with the enclosure, so you need something in between the enclosure and the SoCs. What is your method? I would love to buy an enclosure. A Suggestion, I'm planning to attach a Mini PCIe to SATA 3.0 Expansion Card to the board. This will be a common use case for a NAS. It's great if you could consider another model where there will be (a) hole/holes to pass SATA cables in to the enclosure so that cables can be plugged in to the expansion card. Thanks.

I tried to set a static IP using armbian-config. It configured /etc/network/interfaces file instead of the file in /etc/systemd/network. When this happened, br0 had 2 IPs, which were set by systemd DHCP and /etc/network/interfaces static IP I guess. Anyway commenting out /etc/network/interfaces and setting the correct values in /etc/systemd/network/10-br0.network worked for me.