Jump to content

BananaPi R2 (.csc mt7623 as new boardfamily)

chwe

By chwe
in New boards

 Share

Recommended Posts

chwe

chwe

Posted
  • Author
Posted
  On 7/27/2018 at 7:18 AM, frank-w said:

@chwe if you make changes which fixing problems in mainline please send me the patches si can include them in my repo

Expand  

 

Sure, I stepped down a littlebit with my BPi-R2 testings at the moment. There was/is a patchseries which should make it possible to define multiple CPU ports (https://lore.kernel.org/patchwork/patch/793311/). Unfortunately it never reached Linus tree and the patch doesn't apply at the moment. Maybe I'll have a look into it and see if this enhances the performance. 

Ryder.Lee

Ryder.Lee

Posted
Posted

Hello,

 

Add latest U-boot support for MT7623 SoC

 

Status:

I’ve already sent the first round patches for MT7623n,  and the most of the drivers are based on mainline Linux, like clock, timer, mmc, pinctrl, watchdog, power domain and DTS.

 

The following are the major differences between Linux and U-boot:

-modify the driver interface to adapt the U-boot DM framework.

-remove unneeded DT nodes as they don’t have proper drivers in U-boot yet.

-just add the basic functions (step-by-step) so that we can monitor the size.

-reuse ns16550.c but add a highspeed register for MediaTek UARTs.

 

The current progress:

-Boot from eMMC or SD card.

-ROM -> MediaTek preloder -> U-boot -> Linux

 

TODO:

-Ethernet

 

The patch sets:

-https://patchwork.ozlabs.org/project/uboot/list/?series=68601

 

How to build:

-make mt7623n_bpir2_defconfig; make

 

Ryder

1
chwe

chwe

Posted
  • Author
Posted

Great work! So we finally will end with upstream u-boot & mainline kernel. :) 

 

Applied patches on top of v2018.11rc1 without any failure. But got some errors during build 

scripts/kconfig/conf  --syncconfig Kconfig
.config:1066:warning: override: reassigning to symbol ENV_IS_NOWHERE
.config:1070:warning: override: reassigning to symbol BOOTDELAY
.config:1070:warning: symbol value '' invalid for BOOTDELAY

WARNING: unmet direct dependencies detected for EXT4_WRITE
  Depends on [n]: FS_EXT4 [=n]
  Selected by [y]:
  - ENV_IS_IN_EXT4 [=y] && !CHAIN_OF_TRUST [=n]
#
# configuration written to .config
#

WARNING: unmet direct dependencies detected for EXT4_WRITE
  Depends on [n]: FS_EXT4 [=n]
  Selected by [y]:
  - ENV_IS_IN_EXT4 [=y] && !CHAIN_OF_TRUST [=n]

 

'fixed' by: 

diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig
index a896d6a..642dc9f 100644
--- a/configs/mt7623n_bpir2_defconfig
+++ b/configs/mt7623n_bpir2_defconfig
@@ -49,5 +49,7 @@ CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_TIMER=y
 CONFIG_MTK_TIMER=y
 CONFIG_WDT_MTK=y
+CONFIG_FS_EXT4=y
+CONFIG_EXT4_WRITE=y
 CONFIG_LZMA=y
 # CONFIG_EFI_LOADER is not set

so I assume somewhere there's a 'selects' missing somewhere.  :) 

 

gave it a shot: 

U-Boot 2018.11-rc1-armbian (Oct 02 2018 - 21:11:30 +0200)

CPU: MediaTek MT7623 E3
DRAM:  2 GiB
MMC:   mmc@11230000: 0, mmc@11240000: 1
Loading Environment from EXT4... 
** Unable to use mmc 0:auto for loading the env **
In:    serial
Out:   serial
Err:   serial
Net:   Net Initialization Skipped
No ethernet found.

it will for sure need some adjustments (still the old bootscript from u-boot 2014 etc). I'll keep you updated. @frank-w might be interested as well here. 

frank-w

frank-w

Posted
Posted

I've seen also post from ryder.lee in bananapi.org-forum for uboot-patches and forked uboot-repo on github for testing it.

 

Have you got it booting a kernel from sd/emmc?

chwe

chwe

Posted
  • Author
Posted (edited)
  On 10/2/2018 at 7:51 PM, frank-w said:

Have you got it booting a kernel from sd/emmc?

Expand  

u-boot had to learn bootz and ext commands first. :P  

diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig
index 642dc9f..ce30e40 100644
--- a/configs/mt7623n_bpir2_defconfig
+++ b/configs/mt7623n_bpir2_defconfig
@@ -13,6 +13,7 @@ CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2"
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_BOOTMENU=y
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_XIMG is not set
@@ -25,6 +26,8 @@ CONFIG_CMD_READ=y
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_PING=y
+CONFIG_CMD_EXT4=y		
+CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y

but that's because armbian doesn't use fat for kernel and zImages instead of uImages.. 

Far away from 'automated' but yes boot up isn't much an issue:

  Reveal hidden contents

was just a quick and dirty test.. :P 

 

you can test it on https://github.com/chwe17/build/tree/mt7623 only dev kernel currently tested (btw. the gmac2 patch should be removed it never worked as expected), next is probably broken at the moment.. 

Edited by Tido
added spoiler, terrible long
1
Ryder.Lee

Ryder.Lee

Posted
Posted
  On 10/2/2018 at 7:45 PM, chwe said:

Great work! So we finally will end with upstream u-boot & mainline kernel. :) 

 

Applied patches on top of v2018.11rc1 without any failure. But got some errors during build 

scripts/kconfig/conf  --syncconfig Kconfig
.config:1066:warning: override: reassigning to symbol ENV_IS_NOWHERE
.config:1070:warning: override: reassigning to symbol BOOTDELAY
.config:1070:warning: symbol value '' invalid for BOOTDELAY

WARNING: unmet direct dependencies detected for EXT4_WRITE
  Depends on [n]: FS_EXT4 [=n]
  Selected by [y]:
  - ENV_IS_IN_EXT4 [=y] && !CHAIN_OF_TRUST [=n]
#
# configuration written to .config
#

WARNING: unmet direct dependencies detected for EXT4_WRITE
  Depends on [n]: FS_EXT4 [=n]
  Selected by [y]:
  - ENV_IS_IN_EXT4 [=y] && !CHAIN_OF_TRUST [=n]

 

'fixed' by: 

diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig
index a896d6a..642dc9f 100644
--- a/configs/mt7623n_bpir2_defconfig
+++ b/configs/mt7623n_bpir2_defconfig
@@ -49,5 +49,7 @@ CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_TIMER=y
 CONFIG_MTK_TIMER=y
 CONFIG_WDT_MTK=y
+CONFIG_FS_EXT4=y
+CONFIG_EXT4_WRITE=y
 CONFIG_LZMA=y
 # CONFIG_EFI_LOADER is not set

so I assume somewhere there's a 'selects' missing somewhere.  :) 

Expand  

 

I’ve taken a look at this but couldn't find any build warning on v2018.11 rc1 .

 

chwe

chwe

Posted
  • Author
Posted

just to clarify from: http://forum.banana-pi.org/t/add-latest-u-boot-support-for-bpi-r2-bpi-r64-not-yet/6938/2 since I'm not registered there and likely I'll not do it in the future. 

Patch one:

  On 10/2/2018 at 7:45 PM, chwe said:

fixed' by: 

diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig
index a896d6a..642dc9f 100644
--- a/configs/mt7623n_bpir2_defconfig
+++ b/configs/mt7623n_bpir2_defconfig
@@ -49,5 +49,7 @@ CONFIG_SYSRESET_WATCHDOG=y
 CONFIG_TIMER=y
 CONFIG_MTK_TIMER=y
 CONFIG_WDT_MTK=y
+CONFIG_FS_EXT4=y
+CONFIG_EXT4_WRITE=y
 CONFIG_LZMA=y
 # CONFIG_EFI_LOADER is not set

 

Expand  

was mandatory otherwise u-boot built with mt7623n_bpir2_defconfig crashed. 

 

  On 10/2/2018 at 9:18 PM, chwe said:

  

diff --git a/configs/mt7623n_bpir2_defconfig b/configs/mt7623n_bpir2_defconfig
index 642dc9f..ce30e40 100644
--- a/configs/mt7623n_bpir2_defconfig
+++ b/configs/mt7623n_bpir2_defconfig
@@ -13,6 +13,7 @@ CONFIG_DEFAULT_FDT_FILE="mt7623n-bananapi-bpi-r2"
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_BOOTMENU=y
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_XIMG is not set
@@ -25,6 +26,8 @@ CONFIG_CMD_READ=y
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_PING=y
+CONFIG_CMD_EXT4=y		
+CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y

 

Expand  

isn't mandatory for u-boot to build, but mandatory for armbian to boot since we don't use FAT partition for Kernels respective we don't use uImages for armhf. To my knowledge, it isn't needed for the 'BPi way' of image creation. 

 

Actually I don't know why CONFIG_FS_EXT4 and CONFIG_EXT4_WRITE are needed for a proper build, but since we need ext4 anyway here.. I don't care much. 

It might be related to https://github.com/armbian/build/blob/4a5325353675de7a7660f7846bb176e1dec6796c/lib/compilation.sh#L149-L158 :) 

malvcr

malvcr

Posted
Posted
  On 10/14/2018 at 1:24 PM, chwe said:

did you ever tried cryptodev for the R2. I think you had to compile openssl as well (as far as I now, there're some issues with openssls cryptodev implementation, but honestly never cared). Just out of curiosity.. :P I only gave it one shot back then cause the board had bigger issues than crypto in those days.

Expand  

 

Yes, this was my first attempt a lot of time ago.  However, as you describe, things in R2 were very unstable those days.  Also, cryptodev it is not an official part of the Kernel, so I prefer to use AF_ALG. (the only problem with these things is that the documentation it is horrible, inaccurate and incomplete ... you need to catch details from everywhere to understand what to do).  And you are right, it is necessary to recompile openssl for cryptodev ... but also to obtain the AF_ALG openssl driver (in openssl) and the module (for the kernel).  In general, openssl it is not prepared from factory to work with this type of extensions that are very important for some types of hardware as the R2.

 

In fact, AF_ALG works well, just that the corresponding modules are not included by default (I really don't know why).

 

My current efforts are related with why crytposetup can't use AF_ALG without the BPI kernel (there is something with the drivers).  But, although not so fast, LUKS works well on the R2 even without the hardware support.

chwe

chwe

Posted
  • Author
Posted

I'll split it.. cause IMO we go a way of topic here...  (last post from)

  On 10/15/2018 at 3:28 PM, malvcr said:

My current efforts are related with why crytposetup can't use AF_ALG without the BPI kernel

Expand  

 

 

which 'bpi kernel'? the 4.9 bsp, @frank-ws 4.14? If 4.9, well my interest is minor if nobody has a proper patchset for mainline.. I decided shortly after starting that I won't deal with the 4.9 kernel, the whole network part differs from their mainline implementation I had a lot of build errors and a kernel with no git history.. The only thing which looks sane to me is 4.19 (since LTS and support of MT7623 matured a lot.. there were changes in the network related stuff between 4.14 and 4.15 if I've it right in mind and I never want to deal with backports there.. Frank did or tried it and spend a lot of time to provide a kernel based on 4.14 - appreciated but to much efforts needed IMO, honestly the interest here was too low to put much efforts in it. Upstream U-boot needs some adjustments, basically it works/can work (it boots up, but I would need to write a proper bootscript and configure it properly :P), a default network config is there (all RJ45 bridged) MTKs crypto kernelmodules are there. As long as this is a 'one man show' development is slow cause I don't use the R2 productive and I don't have projects which rely on it. It would be nice to separate IoT nodes from the rest of my network (e.g. keep insecure thingies separated).  As long as nobody wants to contribute and test this will be AS IS. I may fix u-boot so that it properly boots into Linux and stick everything to 4.19. Hardware drivers for USB, SATA and network are there.. Wifi won't be there until its manilined (which likely never happens - and my interest in wifi is minor to port it). mPCI 'should' work (e.g. nothing suspicious in dmesg) HDMI is untested. 

  Reveal hidden contents

 

malvcr

malvcr

Posted
Posted

I am using frank-w 4.14.71 kernel (I had issues with even 4.14.69).  Located in the internal eMMc.

 

Why the R2 and no other machine?  I have several Orange, Raspberry, Banana, Parallella ... Arduino ...

 

The R2 it is not a perfect machine for many cases, but it works well in some applications.  I am trying to work it focused on some basic elements:

 

1) Two SATA ports from factory.

2) 2 GB RAM

3) 5 addressable (more than 100 Mbps) networking ports

4) ARMv7

5) .. maybe, the WIFI part ..

6) Crypto enhancements

7) Local eMMc storage

 

It has other "features", but that is my focus.

 

  • My SATA requirements must be "fast enough".  I could complement the shared SATA channel with a USB3 disk.  I am not really moving huge quantities of data constantly, mainly some data time to time.
  • Memory is important.  SinoVOIP made an R64 machine with only 1GB and I think it was a mistake.
  • You can do many things with those ethernet ports.  If I need a router or a switch I can buy a cheap one ... but when having the type of power this machine has behind, these ports acquire new life and they are not mere data access points.
  • ARM it is powerful, power friendly, complete.  I have been working with Intel and other platforms for decades, but when having ARM I don't need those monsters.  I prefer small well crafted diamonds.
  • WIFI ... it depends if you have the R2 exposed or not.  My environments are usually multi-computer ones and not always you need wireless there.
  • The Crypto part it is VITAL when dealing with secure scenarios.
  • The internal storage is a must.  I can't depend on SD cards; they are very fragile.  Of course, I can't burn the eMMc with swap and other similar things.

 

So ... now the 5 ports can have independent addresses.  Great!!!   But the crypto, sometimes work, sometimes not.  It is slow or fast, it is supported or not.  That part continues being very unstable for me.  In the while, I am working with AF_ALG and whatever the Kernel can bring me, but I think that this would improve in the future.  Can I help with that part?  .... let me know what can I do.  I have several R2 1.1 and 1.2 machines and one of them into production state with a customer.

chwe

chwe

Posted
  • Author
Posted
  On 10/18/2018 at 4:14 PM, malvcr said:

3) 5 addressable (more than 100 Mbps) networking ports

Expand  

Do you really achieve it in productive? The few iperf tests I did in the past were rather annoying and sometimes confusing..  See results in this thread..  I would be interested in some 'real' numbers here.

 

  On 10/18/2018 at 4:14 PM, malvcr said:

That part continues being very unstable for me.  In the while, I am working with AF_ALG and whatever the Kernel can bring me, but I think that this would improve in the future.

Expand  

Crypto 'should' be there with 4.14 but at least with 4.19 there should be an LTS which doesn't need any many backports (except wifi, which I'm not willing to patch in, there's a mPCI slot for those who want wifi on this board and I've a 3T3R wifi card which should run with the brcmsmac driver --> not tested yet!). That's why I decided to drop 4.14 fully. It simply didn't make much sense for me to stick to 4.14 as long as nobody uses it productive (I can fix my mistakes on my own board, so as long as I'm the only user, I don't need an LTS Kernel). I planed to stick stick next to 4.19 and Dev to mainline (cause the kernel isn't patched heavily this is possible, it's unlikely that patches will break that often) in the future.  

 

  On 10/18/2018 at 4:14 PM, malvcr said:

The internal storage is a must.  I can't depend on SD cards; they are very fragile.  Of course, I can't burn the eMMc with swap and other similar things.

Expand  

never had problems with SD-Cards.. I normally go for the qualitative ones and my SBCs don't get that much hammered (Armbians defaults help here as well). But yeah, It's simply not done yet. Need to be done but it wasn't of high priority yet. 

  On 10/18/2018 at 4:14 PM, malvcr said:

Can I help with that part?  .... let me know what can I do. 

Expand  

depends on your skills.. (e.g. bash, kernel, u-boot) :P Let me know in which topics you want to dive in and we will find some nice topics to solve. :) Currently 'under construction':

  • upstream u-boot (boots, but not yet automatically fires up the kernel - some parts of armbians buildscript are here in conflict), a recent bootscript is missing after the change to upstream - it worked back then with the 2014 u-boot but it was just a quick and dirty hack - upstream u-boot should be a good point to solve this properly. 
  • 'nand-sata-install' (not touched yet, I assume it will need some tweaking with the boot binaries)
  • thermals & opp (they look rather conservative and go down to 98MHz, first trip starts at 47°C). some testing would be needed if this can be enhanced.
  • testing, testing & testing. I simply have not the time (and spare equipment) to do it on my own (e.g. USB3 is only tested to the point it works, performance is untested, SATA worked back then but the SSD for those tests in now used productive and I don't have them spare just for testing). And I only own a 1.2 board, no idea how they differ. 
  • kernelconfig is 'it works' probably a bunch of stuff is missing yet (crypto stuff 'should' be there)

You've to build images on your own. Armbian doesn't offer Images nor do we offer kernel-updates over the repository (e.g. apt upgrade will only update ubuntu/debian related stuff, no u-boot, no kernel). This won't change in the near future until the bigger issues are solved. I don't prepare a PR of my fork into armbians Repo until I'm confident that the board isn't a 'troublemaker' (e.g. the support efforts for H6 are a nightmare cause it's IMO simply 'not ready yet' - this won't happen with mt7623 :)).  Even when everything is solved I don't guarantee official armbian-support, it's not only my decision and the fact that this is the only board with this SoC makes it a bit 'problematic' as well (support vs. effort to maintain it). But even when not, maintaining it 'out of tree' shouldn't be that hard (e.g. armbians buildscript allows to pack debs for kernel packages - fire up your own aptly or install them with dpkg -i works fine).  My mt7623 branch exists since June and it looks like the first time I've a merge-conflict, quite sure it's a trivial one and it will be fixed over the weekend (without even looking at it, there are only ~2 files where it can be.. :P). For sure it will be more fun if it's not longer a 'one man show'.. :) 

 

 

malvcr

malvcr

Posted
Posted

OK ... let me check the nand-sata-install first.  I was able to install in the emmc, so I have something to compare with.  Then the kernelconfig, in particular the crypto stuff ( I need to check Armbian style for not to break what can't be broken ).

I don't have experience with the uboot, but let me read a little.  This is an important think to learn :-)

 

 

malvcr

malvcr

Posted
Posted

I was reading the nand-sata-install script ... it seems very monolithic for me.  I will do something: 

1) Mininum quantity of changes for it to work on the R2 following Armbian standards.

2) A more modular approach to reduce the quantity of changes, make the process more clear and avoid side effects.

 

The second one will be just a "proposal" ... :-)

 

chwe

chwe

Posted
  • Author
Posted

nice. :)

 

so basically you'll need:

https://github.com/chwe17/build/tree/mt7623

that's the current 'armbian-alike' branch for the BPi-R2. Uboot, I assume you're not familiar enough to boot it manually? Those commands should help:

  On 10/2/2018 at 9:18 PM, chwe said: 
U-Boot> ext4load mmc 1:1 0x84000000 /boot/zImage 
5571072 bytes read in 279 ms (19 MiB/s) 
U-Boot> ext4load mmc 1:1 0x86000000 /boot/dtb/mt7623n-bananapi-bpi-r2.dtb 
26401 bytes read in 6 ms (4.2 MiB/s) 
U-Boot> setenv bootargs earlyprintk root="/dev/mmcblk1p1" rw rootfstype=ext4 rootwait 
U-Boot> printenv baudrate=115200 bootargs=earlyprintk root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait bootdelay=3 fdt_high=0xac000000 fdtcontroladdr=fffd0fe0 fileaddr=86000000 filesize=6721 loadaddr=0x84000000 Environment size: 193/4092 bytes 
U-Boot> bootz 0x84000000 - 0x86000000
Kernel image @ 0x84000000 [ 0x000000 - 0x550200 ]

 

Expand  

 

see comment ~10 comments ago (you could also load uInitrd was well, this would give you some freedom during boot - see in the old u-boot where it was hacky but actually working.. ;)https://github.com/chwe17/u-boot-mt/blob/f5916a4c6d0ad8acf0e9b8fe3f649425272f5e6a/include/configs/mt7623-bpi-r2.h#L361-L377).. This can be automated with not much efforts I guess.. but until weekend I won't have time for it.

 

  On 10/22/2018 at 1:28 PM, malvcr said:

2) A more modular approach to reduce the quantity of changes, make the process more clear and avoid side effects.

 

Expand  

 

If you plan to clean-up nand-sata-install, I assume you'll have some friends here, but before you start to do it, you might open a thread in the developers sub-forum or an github issue where you present your work. To make sure the right people read it. They might give you some hints ('clean up' nand-sata was discused quite often, but until now nobody had an idea or enough for a script which works good for all boards - which should be a goal for such a script, you may have a look into this one: https://github.com/armbian/build/pull/1129 it's also slightly touched there...

 

Just let me know when you struggle somewhere. :)  btw. UART access is a must during this stage.

malvcr

malvcr

Posted
Posted

Thanks for the references ... I am cloning the armbian-alike branch now.

 

Before starting on the developers area I will read a little and to order my mind to define what could be the best approach on this.

 

 

malvcr

malvcr

Posted
Posted

A question ... after installing and running thee script for compilation, I must choose a machine ... but the R2 it is not there.

 

Did I make a mistake or do I need to follow something special here? ( I suppose I forgot some parameter somewhere ).

 

-- by the way, I have a beautiful Parallella 16 that I wanted to use for neural network processing.  After the R2 I could try it to see how far it is from a normal Armbian distribution.

 

(p.s. I know the P16 was discarded early by somebody in Armbian, although it is a very interesting device)

 

chwe

chwe

Posted
  • Author
Posted

you've to checkout the mt7623 branch, cause I keep my masters branch similar to armbian, so that I can fetch whenever needed for other features branches. As soon as you build the first time there's file called 'config-default.conf' open it and edit LIB_TAG="mt7623". Then you'll build from this branch. keep in mind, if you create patches or edit stuff in the buildscript, checkout mt7623 as well.. otherwise your changes will be in master..

 

The reason is quite simple.. I also test stuff on other boards, and update my master is a branch as soon as it's not based on armbians master.

malvcr

malvcr

Posted
Posted

Ready, R2 image built ... this night I will check the image to see how it works.

 

By now, I will check the discussion about the writing to internal storage.

 

Also, before providing any changes, I will triple check.  I know your work it is very important :-)

 

chwe

chwe

Posted
  • Author
Posted
  On 10/27/2018 at 4:38 PM, malvcr said:

Also, before providing any changes, I will triple check.  I know your work it is very important :-)

Expand  

mistakes will happen. ;) And it's fine. We both will learn from those mistakes. Cause we work on an features branch more or less independent from Armbians repo, this can not affect the project. We don't crash anything in case something goes wrong. :) I won't yell to you in case a PR breaks things. :P If it happens, let's figure out what's wrong, revert that part and start again. 

malvcr

malvcr

Posted
Posted

I have been reading the script to write on the disk ... 

 

It really looks as a mixture of attempts.  For example, you have references to A10, A13, A20 and particular directories for them with some data, but the rk3328 it is wired in the script.

 

Also, why the openmediavault it is there?  I know some people at Armbian are very involved on that nice product, but openmediavault it is not Armbian and not always Armbian will be used to install an openmediavault product.

 

The script it is also difficult to follow because of all the wizardry on obtaining bits of information to define what to do and how to do it (in this moment not, but in my future proposal I will deal with this).

 

From my point of view, the right method is to let different parameter files (as was done with A10, A13 or A20), but depending on /etc/armbian-release LINUXFAMILY varible and, without any particular reference to any type of card or SOC inside the script.  Then, the script only would have the generic stuff and every address or particular direction would be in these parameter files.

 

Then there is the openmediavault.  That thing must be out of the script ... maybe within "optional" things that could or not be executed depending if they exist or not.  If you have openmediavault, then you add your sub-scripts, but if you don't have it, why to deal with that?

 

The last thing is about the static list for running services.  In my particular case, my first R2 it is not running these but other services, so that script it is useless.  The running services must be requested to the operating system, they can't be statically specified.  Maybe using lsof or something similar, let me check it ( if this becomes very complicated in the script, I can write some C or C++ tool for that).

 

--

Before making this to run with the R2, let me order it a little.  I don't like to work in a mine-field ;-) ...

 

chwe

chwe

Posted
  • Author
Posted
  On 10/28/2018 at 5:15 PM, malvcr said:

Also, why the openmediavault it is there?  I know some people at Armbian are very involved on that nice product, but openmediavault it is not Armbian and not always Armbian will be used to install an openmediavault product.

Expand  

you mean in customize-image.sh? OMV is there partly as an example how users can write their own customization scripts for Armbian. All official ARM based OMV images (except RPi) are based on Armbian (for RPi it's just a Armbian rootfs). Since all those Images are provided by @tkaiser who's also an Armbian maintainer it's somehow part of Armbian. Keep in mind, customize-image must be called during build, otherwise this stuff doesn't affect the build.

  On 10/28/2018 at 5:15 PM, malvcr said:

Before making this to run with the R2, let me order it a little.  I don't like to work in a mine-field ;-) ...

Expand  

if you plan to make major changes to the buildscript, I suggest you try to make them somehow independent from the adjustments for the R2, cause buildscript changes will affect all Armbian builds and we shouldn't mix up board bring up and major buildscript changes too much. Makes it harder to merge in case maintainers have concerns towards the changes you did in the buildscirpt. For sure, there are parts of the buildscirpt which would need some cleaning but those should be besides a board bring up. :)

 

Maybe you open an github issue with the suggested changes on Armbians repo for cleaning the script so that all maintainers can catch those changes.

 

  On 10/28/2018 at 5:15 PM, malvcr said:

The script it is also difficult to follow because of all the wizardry on obtaining bits of information to define what to do and how to do it (in this moment not, but in my future proposal I will deal with this).

Expand  

it needs some time, and to be honest I don't understand every part of it in detail. It's also grown over time. The script catches more than 50 boards and sometimes there are for sure better ways to solve it. Just keep in mind it must be working for all boards, not only the R2. :) I don't plan to fork the project. In case something isn't clear from script side, just let me know, I'll try to explain it as best as I can.

malvcr

malvcr

Posted
Posted
  On 10/28/2018 at 6:08 PM, chwe said:

you mean in customize-image.sh?

Expand  

Nop ... check /usr/sbin/nand-sata-install.sh

 

Line 19: 

[ -f /etc/default/openmediavault ] && echo '/srv/*' >>"${EX_LIST}"

Line 290

  Quote

    290         if [ $? -eq 0 -a -f /etc/default/openmediavault ]; then

    291                 echo -e '# >>> [openmediavault]' >> ${TempDir}/rootfs/etc/fstab

    292                 grep ' /srv/' /etc/fstab | while read ; do

    293                         echo "${REPLY}" >> ${TempDir}/rootfs/etc/fstab

    294                         mkdir -p -m700 "${TempDir}/rootfs$(awk -F" " '{print $2}' <<<"${REPLY}")"

    295                 done

    296                 echo -e '# <<< [openmediavault]' >> ${TempDir}/rootfs/etc/fstab

    297         fi

Expand  

 

That's the main nand-sata-install file without any OMV there.

 

I don't think this is an example as it is an integral part of the script.

 

I agree 100% with you in that major changes on these scripts can't be part of a bring up a particular machine.

 

  On 10/28/2018 at 6:08 PM, chwe said:

I don't plan to fork the project. In case something isn't clear from script side, just let me know, I'll try to explain it as best as I can.

Expand  

 

Yes, it has no sense to increase complexity on an already complex work.

 

Let me see ... my original plan was minimal changes.  I will work that way for R2, but I will also include the suggestions as a github issue.

There is an extra option.  After these two steps, I can develop a different nand-sata-install system "around" the Armbian base (without changing the already existing one).  If the community thinks it could be useful, it will be there.  In general the worst thing I could do is to promote another "systemd" psychosis .

 

chwe

chwe

Posted
  • Author
Posted
  On 10/28/2018 at 8:31 PM, malvcr said:

Nop ... check /usr/sbin/nand-sata-install.sh

Expand  

okay, but this part of the script gets only called when Armbian is 'converted' to a OMV (which can be done by armbian-config), we had such tweaks in the past also for DietPi (before they dropped images based on Armbian). OMVs storage mounting isn't default of armbian, and if they would call NAND-SATA install it would probably mess with their settings. Bringing up a generic NAND-SATA install would be nice, was discussed quite often but nobody had enough spare time and willingness to write it. ;) likely cause there are so many possibilities depending on the board you have (e.g. most boards can't directly boot from USB, so the bootloader has to stay on SD-Card, some have SPI, some have eMMC) all kind of funny configuration you've to catch. And it needs also to be up-gradable with apt-upgrade cause we deliver u-boot updates via apt...

 

  On 10/28/2018 at 8:31 PM, malvcr said:

There is an extra option.  After these two steps, I can develop a different nand-sata-install system "around" the Armbian base (without changing the already existing one).  If the community thinks it could be useful, it will be there.  In general the worst thing I could do is to promote another "systemd" psychosis .

Expand  

if you come up with an idea, and you can show somehow a basic 'concept' which is flexible enough for all kind of boards, I'm quite sure it's getting attention. Nand-sata has one job... so no chance to be a systemD... :lol:

 

chwe

chwe

Posted
  • Author
Posted

currently applied a ugly hack to my u-boot (https://github.com/chwe17/build/commit/1b60a94e8c625c50da369162344052753ed2e64a). It's nasty, it's not properly solved and I don't like it.. :D But for those don't want to deal with u-boot but get a clue what's working.. The board will boot without manual u-boot hacking.. (e.g. mostly the stuff from my u-boot plumbing work done in the bsp u-boot, it should try to boot from sd card first, and in case there's no SD-Card it should switch to eMMC - untested!)

  Reveal hidden contents

for whatever reason next is broken again... you've to build dev (EXPERT="yes" in config).  But hey, 4.19 fires up.. ;)

  

 ____                                  ____  _   ____  ____  
| __ )  __ _ _ __   __ _ _ __   __ _  |  _ \(_) |  _ \|___ \ 
|  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |_) | __) |
| |_) | (_| | | | | (_| | | | | (_| | |  __/| | |  _ < / __/ 
|____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|   |_| |_| \_\_____|
                                                             

Welcome to ARMBIAN 5.65 user-built Debian GNU/Linux 9 (stretch) 4.19.0-mt7623   
System load:   0.07 0.08 0.03  	Up time:       3 min		
Memory usage:  3 % of 2018MB 	IP:            192.168.0.66
CPU temp:      32°C           	
Usage of /:    6% of 15G    	

[ 0 security updates available, 4 updates total: apt upgrade ]
Last check: 2018-11-04 14:58

Last login: Sun Nov  4 14:58:44 2018

network with NetworkD works, rest is untested, but I assume..., well test it on your own.. :D

chwe

chwe

Posted
  • Author
Posted

network seems to be okay after change the cable: 

Testing download speed................................................................................
Download: 383.33 Mbit/s
Testing upload speed....................................................................................................
Upload: 333.16 Mbit/s

I avoid to test iperf.. quite sure it would give me results I can't explain.. :D

chwe

chwe

Posted
  • Author
Posted

@malvcr just for you I built openssl from git sources... To be clear, I didn't pay much attention towards crypto modules.. So you might have a look into kernelconfig in case something is missing here.. (took quite some time to build it.. :D ) 

opi@bananapir2:~$ openssl version
OpenSSL 1.1.2-dev
opi@bananapir2:~$ openssl speed -elapsed -evp aes-256-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256-cbc for 3s on 16 size blocks: 3530174 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 1104523 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 292382 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 74180 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 9312 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16384 size blocks: 4656 aes-256-cbc's in 3.00s
OpenSSL 1.1.2-dev  xx XXX xxxx
built on: Sun Nov  4 17:26:09 2018 UTC
options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread  -march=armv7-a -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc      18827.59k    23563.16k    24949.93k    25320.11k    25427.97k    25427.97k

and 

opi@bananapir2:~$ openssl speed -elapsed -evp aes-256-cbc -engine afalg
engine "afalg" set.
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-256-cbc for 3s on 16 size blocks: 76398 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 80277 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 79181 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 69533 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 34005 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16384 size blocks: 20658 aes-256-cbc's in 3.00s
OpenSSL 1.1.2-dev  xx XXX xxxx
built on: Sun Nov  4 17:26:09 2018 UTC
options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread  -march=armv7-a -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc        407.46k     1712.58k     6756.78k    23733.93k    92856.32k   112820.22k

just quick and dirty.. had to move libs manually cause I probably did something wrong.. but, seems to 'work' at least similar to your tests.

  

This are numbers without the "elapsed" parameter.

Without AFALG
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc      19085.03k    23572.74k    24949.59k    25405.82k    25430.70k    25438.89k

With AFALG
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc       6201.12k    22069.15k   133717.33k   353167.36k  3962119.31k  3391979.52k

I think CPU is still conservative by default.. and not allowed to clock above 1.3GHz (settings back in the time when I had no idea what works and what not.. :D this might change in the future)

malvcr

malvcr

Posted
Posted

AF_ALG has some CPU bounded limitations, because there is a big quantity of sequential operations must be performed before asking the "engine" to work each block.  Each time, it is important to fill a control block, to program the "socket" and to provide the IV (Interference Vector), something that usually you only do once when working with software encryption.

So, before 256 bit size, the overhead it is just too much to use AF_ALG.  Let me try something with my own software to encrypt and decrypt some data with different block sizes to compare numbers.  In fact, the problem with openssl is that you can's specify different block sizes when asking for encryption and decryption, so the testing numbers are just "evidence" but without any usage.  You can define different "buffer size", but that it is a different thing.

 

The problem with Cryptodev is that it is not an official kernel component (as AF_ALG).  But this is what we have on Linux.  Maybe a basic and clean encryption library capable of working directly with the hardware could be a better solution, but usually they are very cryptic.  You need some time to figure what is the right way to use them; this happens not only with AF_ALG (with a terribly confusing documentation), but also with Cryptodev, Botan, Openssl ..   what I do is to fight once and then to create my own standard interface.  Then, I just provide the parameters and things work.

 

 

Let me check this part carefully.  It is important, because with the R2 and Sinovoip kernel the AF_ALG didn't work as expected.  The ciphered material was undecipherable (so, something was wrong).  In that case I was forced to work with software encryption.  Then, here, there are two things to do:

 

1) To verify that it works and that it is compatible with any other AES implementation.

2) To check what effect the configuration can have in the algorithm speed.

 

This is important for me ... thanks for the extra test.  When I have something about this I will provide some feedback.  Anyway, let me try my own test also in an H2+ CPU ... it is supposed to work well there.

chwe

chwe

Posted
  • Author
Posted

There's some cleaning going on (just see the last commits). Currently the board will automatically boot into linux (so you don't have to deal with u-boot atm, it's an ugly hack but it works - didn't had time for a proper solution yet), network (at least on debian stretch) should work without issues. So build default/debian 9 and you should be able to to your tests.. At least for SD-Card boot, eMMC will need some tweaks (binaries e.g. preloader is anyway a mess currently let's see what happens there).. but for testing SD-Card should be fine. I'll give the CPU on demand back..  :PThe throttling points are so conservative.. it shouldn't harm the systems.. Maybe something for the next weekend (BBQ the board a bit to see what's possible in thermals). https://github.com/torvalds/linux/blob/4710e78940d8d957f24b8f085f961f1279f8fbff/arch/arm/boot/dts/mt7623.dtsi#L162-L184

 

  On 11/4/2018 at 10:06 PM, malvcr said:

Let me check this part carefully.  It is important, because with the R2 and Sinovoip kernel the AF_ALG didn't work as expected. 

Expand  

well it's mainline 4.19.1 if mainline doesn't work.. there's not much I can do.. The kernel is more or less a pure vanilla (expect some wifi drivers, but not for the onboard one.. I'm not willing to patch it into.. send me a PR if you want onboard wifi :lol:)

 

 

TonyMac32

TonyMac32

Posted
Posted

OK, I'm sure I'll find my head on a pike for the question, but, it looks like the hardware is at least acceptably made, correct?  No crazy errata to worry about?  And mainline support is likewise fairly mature for arn ARM SoC, correct?  And since this is a hardware bringup thread, I guess the question could be, is it worth to bring this up?  I see 3 people who can work and support if they are so inclined, and even the Mediatek guy.

 

It's a big question, because Igor does not need anything else to worry about, I'm getting my wind back with Amlogic and Rockchip after a long summer and can't learn another new SoC with all of it's fun oddities, etc.  I honestly don't think we need a new board of different architecture, but a lot of the work has already been done it seems.

 

If you want a laugh: https://www.newegg.com/Product/Product.aspx?Item=9SIAFK56SJ5438

 

BPi might want to check with those guys and see why they are trying to give them a bad name for being 10x more expensive than anyone else... :P

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept