1 1
chwe

BananaPi R2 (.csc mt7623 as new boardfamily)

Recommended Posts

Proposal to introduce a new BOARDFAMILY based on MT7623n SoCs. The only (widely) available board currently is the BananaPi R2 build by Sinovoip. I 'tried' to clean and split their BSP into different repos to make it usable for armbians Buildscript. The 'initial' work is done and built images boot up (with some additional work).

 

r2-6.jpg

(found one on http://www.banana-pi.org/r2.html - hidden in the 'gallery photos' which looks like the revision I have)

Spoiler

1749157-n0.jpg

(I don't found a actual picture of my revision of the board, the battery connector was removed and the powerconnectors for SATA are 5V only, so 12V rails are there but connectors on it are only GND and 5V - I probably make a picture of my board to replace this one)

 

 

Some specs (and just to be clear here, this is not a in-depth description about performance of those interfaces, there are more experienced people for benchmarking interfaces etc. don't hang me when there's a mistake in the description :P):

  • MT7623n (ARM Cortex-A7 quad core)
  • GbE over MTK7530 (1x "wan" 4x "lan")
  • 2x USB 3.0 and 1 USB 2.0 otg port
  • 2x SATA over asm1061
  • (up to) 2 mPCIE interfaces (one populated as mPCIe, the other is muxed with USB3 - you've to disable USB if you want to use it - never tested)
  • Hardware NAT & cryptoDEV (also none of them is tested in my builds made with armbians Buildscript)
  • wifi/bluetooth combo-chip (b/g/n / 4.1)
  • HDMI
  • Powering over 12V barrel jack

 

Pros:

  • relatively cheap (~90$ Aliexpress)
  • Metal case and 4G modem available (I dont' own both - so must be considered as 'not working' at the moment)
  • 2x2 MIMO WiFi should be possible over mPCIE (as before I didn't test it)
  • MT7623 gets relatively good upstream support by Mediatek in mainline
  • There is a 4.14.y Kernel (currently at 4.14.42 - so it seems to be quite up-to-date) maintained by 'Frank-W' which gets frequently updates and patches from upstream are back-ported (more experienced kernelhacker have to decide if he does it in a sane way or not, that's over my skills)  See https://forum.armbian.com/topic/7296-bananapi-r2-csc/?do=findComment&comment=55245 
  • the board has some nice features either as a NAS or a routerboard (I know about the concerns of mixing router with NAS capabilities and I didn't benchmark one of this features - better let people benchmark it which know what they're doing :P).
  • It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki. There are still things wrong inside (e.g. the board-picture shows a battery connector but it was removed in the newer revisions of the board, still a lot of stuff linked to sources not provided by them self e.g. description of 'how network is implemented), but at least it's not that messy than their former 'gitbook' documentation. Frank-W provides a independent wiki where he documents his efforts and what works with his builds. 

 

Cons:

  • u-boot is based on a v2014.04 rc1 together with some Mediatek additional stuff with further modification by Sinovoip (and in the end by me which doesn't make things much better). Some cleanup is done (not pushed to github since it's early WIP and I only push it when it works 'somehow' reliable, it fools me quite often cause I'm definitively not a 'experienced' u-boot hacker - cause it's a bit outdated a lot of things changed to upstream and I've to google a lot of stuff to get things working).
  • There are 3 binary blobs needed to boot into U-boot (see picture) and I still don't understand fully what they're doing (as said I'm not a u-boot hacker :Dhttp://fw-web.de/dokuwiki/lib/exe/detail.php?id=en%3Abpi-r2%3Astorage&media=bpi-r2:boot-structure.png fetch.php?media=bpi-r2:boot-structure.pn the 'Preloader' differs between eMMC and SD-card, so this needs for sure some 'additional work' for something like nand-sata-install. The 'Headers' are in fact two files (one seems to have he size it should, the other one is to big and get's partly overwritten by the 'preloader', so no idea how sane this is) and it seems that they set some variables to env in u-boot (I simply overwrite them to ensure that they don't do insane things and the board is booted with a bootscript sitting in /boot/boot.scr (currently wip - doesn't work every-time)
  • During compilation of u-boot there are some warnings (I didn't care cause in the end the board boots into u-boot so this warnings are of minor interest to me - it would be possible to build u-boot based on v2014.04 upstream with huge patching, as it is done for a yocto-build by Wolfgang Tolkien here, but his is currently adjusted to yocto and will need some rework to make it usable for Armbian - nevertheless, without the help of Wolfgang, this thread would never came up he gave me a lot of hints here and there to deal with u-boot)
  • There is no kernel defconfig for the R2 nor mt7623n SoC upstream (as far as I understand frank-w made a defconfig based on a 4.9 kernel, based on the evb board - so give him the credits for doing a lot of the hard work :)), nevertheless an 'mt7623n-next/dev.config' needs some adjustments.  I think, I pickt more or less all of the SoC relevant drivers after 'a few attempts'... :lol:
  • Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' (I didn't care about the drawbacks yet) works yet. Probably this needs some adjustments in builddebb (at the moment this is done by hand with 'cat zImage *.dtb > zImage-dtb ). U-boot 'should' be capable of booting a with a separate dtb file but it doesn't... :P  The EVB can also be booted with FIT images but this seems also not work on the BPi, maybe it's related to the binaries, maybe I got fooled by u-boot once again (it happened a lot). I simply don't know.
  • From a support point of view: This board has a bunch of features which people will mix together (from router/NAS/'home cloud' up to HDMI capabilities) for a relative affordable price, so 'less experienced' people will buy it, will mess with it and will ask here a bunch of questions when we decide to build images or have it as .csc in armbians repo. Cause it will introduce a new boardfamily (probably *.csc only at the moment) this board doesn't get any kernel updates until the maintainers decide to add it to armbians apt server and if we do, it's more than csc and people will expect 'some support'.
  • I only did the 'initial work' so, a lot of kernel module adjustments, u-boot cleanup and enhancements are needed to build useful 'Armbian images' and to be clear: I'm not willing nor able to do all this work alone. In case no serious developer is willing to join this 'clean up' party, we should not add this board to .csc cause it will end similar to the OPi-2g-IoT where people ask from time to time for support whereas nobody works actively to enhance the Images. 
  • No LTS-Kernel due to 4.14 has a lot of back-ports inside which might mess up things in case a other member of the same SoC will join the boardfamily.
  • Edit: just in case somebody asks, as far as I know HDMI is not working yet on 4.14 and only usable with the 4.4 BSP kernel, I played some days with it, tried to fix things, I failed, I got headache from the BSP-Kernel and decided to drop it fully. From my side, there will be no efforts in the BSP Kernel to get it working. If someone wants to deal with it, there's a 'kernel only' repo on my github fully 'unmaintained' not patched and currently not available as buildoption. I think people who are able to fix issues for this kernel are able to add it as buildoption but I decided to not deal with it.

 

So to summarize, what's done, what works and what's not working (everything not mentioned here must be considered as not working!):

  • Next Kernel (4.14.y) builds without issues, the devicetree blob is attached after its manually (mount image --> cat zImage *dtb > zImage-dtb) Will not longer be supported by my builds.
  • U-Boot was slightly adjusted so that it is capable of booting zImages, is able to handle ext4 FS & getting it's bootscript from /boot/boot.scr. This needs still some rework for accessing eMMC due to not working 100% reliable with freshly built Images (the first boot is done by manual u-boot commands, probably due to something gone wrong with the bootscript, after recompilation of boot.cmd onboard, the board boots up automatically without manual u-boot hacking)
  • SATA devices are recognized, ETH was only tested once and didn't work (I guess, some adjustments in NM are needed or I missed something, cause the board is mostly connected only via UART during testing I didn't spend much attention to it (this might be a goal as soon as the board boots up reliable even on the first run).
  • Onboard wifi will for sure not work, cause I don't pack the driver binaries to it (I don't care about wifi yet, and there are IMO more important things to fix before I even set onboard wifi to my 'issues list'). Will most likely never be supported due to 'mainline only' and I will not implement an android wifi driver into the mainline kernel.
  • dmesg (for next) spies some errors related to USB (xhci-mtk 1a1c0000.usb: fail to get vbus), this was solved upstream, from what I see frank-w applied the patch too for his 4.14-main branch but it seems to not work properly yet on my builds. Maybe I missed some 'USB quirks' for a kernelcommand, maybe I missed a module or something else - I didn't read all the posts related to it and I don't follow all the stuff on BPis forum to get informations. Keep in mind, I'm not super experienced and this is early WIP (I fully understand why the maintainers don't want to waste much time with new SoCs, it's a bunch of work and if it's not well documented things are even worse).
  • Dev (Linus master branch) will not be properly packed due to changes in builddebb (a slightly adjusted mt7623n-dev.config based on frank-w 4.16 defconfig is there but completely untested, it build's without fails but I never booted a dev image - wouldn't be surprised that it will not boot). 4.17.0-rc7 based on multi_v7_defconfig slightly adjusted to bring up the device but still a lot of 'clean up' needed.

 

Disclaimer: 

If you're smart enough, you'll find part of this initial work on GitHub (if not, it's probably better that you don't play with it, cause it's only initial, and Images built with this configuration must be expected as early experimental, for testing purposes only). Some of the adjustments living only on my buildmachine as patches and aren't pushed upstream yet (call it lazy, call it I want avoid that unexperienced people clone the repo build images and complain that they don't work as expected, I don't care)...  Every support question related to 'why is *random feature* not working' will be happily ignored. I'll share my experience only with people who want to contribute to enhance things at the moment not to use it for 'home' ore 'productive' use-cases (it's a way to early for that). 

 

It's not armbian, it's just a Image created with armbians buildscript at the moment: :P 

Spoiler

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


Welcome to ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.14.42-mt7623n 
System load:   0.30 0.09 0.03   Up time:       0 min
Memory usage:  2 % of 2013MB    IP:
Usage of /:    28% of 3.5G

 

 

 

This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian. Some Initial work is done (we don't need any FAT partition anymore, we can start the board with bootscripts) and some current limitations (appended device tree blob, binary blobs for boot, u-boot needs cleanup etc.). I think with the initial work I did, a new 'board bring up' (as the socialists in germany would say `Ergebnisoffen` :P open-ended) make sense. In case it ends like the last BPi R2 board bring up thread, where people were more focused on personal insults, and people start to throw dirt to each other, I'll remove all the work I did on GitHub and close this thread! You've been warned! Some initial work is done but more is needed before I'll even consider to send a PR to Armbians repo. I would be really disappointed when somebody fork my initial work and puts then 'Armbian for BPi R2' on some services like google-drive or mega (if you want to enhance the support for it, just send PRs to the repo, it helps nobody if you make some 'experimental' builds based on the initial work and give them to inexperienced users to test, the images are simply not ready yet).

 

So happy discussion (with valid arguments)... :)

Edited by chwe
colored text was added later.

Share this post


Link to post
Share on other sites
14 hours ago, chwe said:

It seems that Sinovoip starts to clean up their GitBook mess by switching to a wiki

 

A 'new' wiki? The product pictures show early board revs from over one year ago that never got sold (showing one SATA port as optional, different SATA power ports, different layout of WAN/LAN ports, battery connector that is of no use, DC-IN is labeled '12V/2A' while it reads directly below '5 volt @2A via DC Power and/or Micro USB (OTG)'). Is this technical documentation or a joke?

 

I started reading this section http://wiki.banana-pi.org/Banana_Pi_BPI-R2#Hardware_spec but already stopped after 7 lines of which 4 are wrong (more than 50%):

  • 'Quad-code ARM Cortex-A7' -- copy&paste as usual from their forum
  • 'Two SATA 2.0 Port (USB-to-SATA bridge)' -- as far as I know that's not USB but PCIe based and an ASM1061 (providing SATA 3.0)?
  • 'MTK6625L chip' -- does not exist
  • 'resolutions up 1920x1200' -- according to SoC manual it's 1920x1080 instead

So unfortunately still no technical documentation but just the careless 'copy&paste gone wrong' weirdness this SinoVoip employee is 'famous' for. Still zero progress :-(

 

Share this post


Link to post
Share on other sites

 

On 5/23/2018 at 10:05 AM, tkaiser said:

A 'new' wiki? The product pictures show early board revs from over one year ago that never got sold (showing one SATA port as optional, different SATA power ports, different layout of WAN/LAN ports, battery connector that is of no use, DC-IN is labeled '12V/2A' while it reads directly below '5 volt @2A via DC Power and/or Micro USB (OTG)'). Is this technical documentation or a joke?

If that's the only mistake in my starter,  well than I probably didn't did much wrong.. :P Compared to the Gitbook, the wiki seems to be a way more readable.. It's to that spot new, that I didn't notice it before..  It's somehow readable, there's for sure space for improvements but I prefer one wiki page per board over 100 gitbook slides so for me this is an improvement..

 

On 5/23/2018 at 9:44 AM, Ryder.Lee said:

Thanks for the great efforts.  All the HDMI stuff has been sent to mainline but it still under review.

https://lkml.org/lkml/2018/5/7/843

Thanks for sharing.. It's somewhere on my 'look into list' shortly before internals wifi cause not of much interest for my purposes at the moment. There are obviously more issues to solve to improve my current builds. As far as I understand, due to NDAs there will be no chance that you can release the sources of HEAD440, HEAD512b and the preloader right?  Armbians write uboot platform function of the buildscript works quite well, and those images boot (at least into u-boot without issues, it still needs some housekeeping for the kernel but that's under rework. It looks like the following:

	dd if=PI-R2-HEAD440-0k.img of=$2 bs=440 seek=0 count=1 status=noxfer > /dev/null 2>&1
	dd if=BPI-R2-HEAD1-512b.img of=$2 bs=512 seek=1 status=noxfer > /dev/null 2>&1
	dd if=BPI-R2-preloader-2k.img of=$2 bs=1k seek=2 status=noxfer > /dev/null 2>&1
	dd if=u-boot.bin of=$2 bs=1k seek=320 status=noxfer > /dev/null 2>&1

but if I've a look into the files:

-rw-rw-r-- 1 opi opi     1536 May 13 14:19 BPI-R2-HEAD1-512b.img
-rw-rw-r-- 1 opi opi      440 May 13 14:19 BPI-R2-HEAD440-0k.img
-rw-rw-r-- 1 opi opi    91996 May 13 14:19 BPI-R2-preloader-2k.img

HEAD1-512b doesn't fit, and gets mostly overwritten by the preloader... It works, and I don't see anything going wrong but can you explain what HEAD-512b exactly does? I guess it sets some env variables for u-boot cause even when I remove them fully from the boardconfig file in u-boot, they're still there... How are those HEAD files generated, is there a chance to generate them by our own and when not, can you provide a head which is cleaned up (I don't need any variables set by a binary, I set them happily by my self with the boardconfig or via bootscript :)). 

Next question about those binaries: 

BPI-R2-preloader-2k.img
BPI-R2-720P-2k.img
BPI-R2-2k-SD-20180320.img
BPI-R2-1080P-2k.img

can you explain the differences between all those 2k preloaders? I guess 720p/1080p relates to HDMI, is this just during bootup? (in case yes, I don't care) At the moment I use 'BPI-R2-preloader-2k.img' and it works.. what's the difference between this one and the more recent one 'BPI-R2-2k-SD-20180320.img'?

 

And the last question I have... Can you comment this one:

On 5/22/2018 at 8:15 PM, chwe said:

Currently load a kernel with 'Flattened Device Tree blob' (CONFIG_OF_LIBFDT) does not work (Wolfgang reported similar problems for his yocto builds with the R2, but it should/does work with his evb board) and only 'appended device tree blob to zImage' works

So, the SoC, u-boot and a similar board is capable for flattened dtb. Every attempt I tried with not appended device tree blobs failed.. The DTB is recognized,  u-boot 'knows' that it's there e.g. 

BPI-IoT> bootz 0x84000000 - 0x83000000
bootm flag=0, states=1
Kernel image @ 0x84000000 [ 0x000000 - 0x5d1680 ]
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
bootm flag=0, states=700
   Loading Device Tree to ffff4000, end fffff430 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

'Uncompressing Linux... done, booting the kernel.' is to my knowledge not a u-boot message (to my knowledge the last u-boot message you get is Starting kernel ...) but then, it gets silent.. Some adjustments for your kernel config:

 

CONFIG_DEBUG_UART_PHYS=0x11004000

CONFIG_DEBUG_UART_VIRT=0xf1004000

 

Cause compared to the evb board R2 standard debug uart sits on UART2 not UART0, otherwise the device gets silent with starting kernel ... So by correcting this I got one message more.. but it's still not solved.. I would prefer to have kernel and DTB separated and 'it should be possible' cause a similar board (according to Wolfgang the  evb is able whereas the bpi not). 

Share this post


Link to post
Share on other sites
50 minutes ago, chwe said:

Compared to the Gitbook, the wiki seems to be a way more readable

 

But unfortunately the contents still are no technical documentation but simply random nonsense. I mean, a board vendor designs a board with a SoC capable of 3 PCIe Gen2 lanes. One lane is used to attach the usual ASM1061 PCIe SATA controller providing 2 SATA 3.0 ports. And this stuff ends up in the boardmaker's own wiki described as

  • USB attached (wrong)
  • SATA 2.0 (wrong)
  • with only one SATA port populated on the PCB while the other is optional (wrong)

While this board maker clearly doesn't support his own hardware with such stunts it also means we can not trust in anything written there. It's not a technical writer providing information/documentation filling that wiki but someone doing funny copy&paste jobs assembling random words and numbers to meaningless sentences describing nothing. No progress at all :(

 

I hope you call the BOARDFAMILY mt7623 later. As far as I know at least ACT POWER plans to release another MT7623 device focused on NAS use case soon and maybe they're willing to support their own hardware and provide technical documentation.

 

Edit: At least some of this nonsense has been corrected in the meantime. But that's not how it works. A board maker should not need random community members to spot the really obvious mistakes in his 'technical documentation' but provide correct information in the first place. That's just bizarre. I mean what's the purpose of telling users a device can be powered by 12V/2A and 5V/2A (even through Micro USB) on the same page? Why not simply starting to take care of correct information and providing technical documentation that we can rely on?

Share this post


Link to post
Share on other sites
On 5/23/2018 at 1:27 PM, tkaiser said:

I hope you call the BOARDFAMILY mt7623 later. As far as I know at least ACT POWER plans to release another MT7623 device focused on NAS use case soon and maybe they're willing to support their own hardware and provide technical documentation.

I really don't care about naming for the BOARDFAMILY yet... :lol: There are two SoCs, the mt7623a and the mt7623n. According to Mediateks 'marketing page':

Quote

Moreover, MT7623N also supports audio bit stream input from HDMI and SPDIF, which is a key function in the growing HTiB segment. The hardware-based NAT engine with QoS embedded in MT7623N transporting the audio/video streams in higher priority than other non-timely services also enriches the home entertainment application. The 1k SFQ separating P2P sessions from audio/video ones so that MT7623N guarantees the streaming service. MT7623N also implements 10/100/1000 Ethernet RGMII and TRGMII interfaces, while MT7623A embedded a 5-ports Giga switch with an extra RGMII

if we can support both chips with one config.. fine would it make easier to maintain it.. If they differ to much, IMO we should have two config files.. But I don't think about the 'endproduct' as long as more important issues aren't solved, might be related to my background, but every-time I try to solve eveything with something I think it's a smart solution I got fooled (not only related to SBCs, it's also they way science works).  So, my 'roadmap' looks like the following:

  1. reliable boot.scr that works on the first boot & further u-boot clean up (there are a bunch of functions defined in the boardconfig file from the 'bootmenu' which was there before, since this menu is fully removed (I don't like it, we don't need it, it's a way to 'static' for my purposes - I'm far away from calling my solution 'smart' but at least I can change things from linux with /boot/boot.cmd without recompilation of u-boot everytime and it drove me nuts to get 'this feature', as said I'm not an experienced u-boot hacker and 'source' only works if you load it into the right adress, it fools you if you don't do it 'right'). E.g.
    ext4load mmc 1:1 0x83000000 /boot/boot.scr
    source 0x83000000
    
    didn't work.... but
    
    ext4load mmc 1:1 0x84000000 /boot/boot.scr
    source
    
    worked

    due to somewhere before there was something like: 

    /* RichOS memory partitions */
    #define CONFIG_SYS_DECOMP_ADDR              0x80008000
    #define CONFIG_SYS_LOAD_ADDR                0x84000000
    #define CONFIG_SYS_IMAGE_HDR_ADDR           CONFIG_SYS_LOAD_ADDR
    
    /* Linux DRAM definition */
    #define CONFIG_LOADADDR			            CONFIG_SYS_LOAD_ADDR

    That said, I hope that someone knowing u-boot ~2014 well enough can give me some hints to clean things up.. or Sinovoip decides to help cleaning up u-boot.. The bootmenu does just look wrong/useless to me.

  2. get rid of the annoying 'appended device tree blob to zImage' (I don't like it, it seems to be not necessary due to evb board with the same SoC doesn't need it)
  3. testing interfaces - the only one I'm interested at the moment are ETH, SATA and USB (and then mPCIe), I don't care about HDMI nor pinheader nor internal wifi (if someone cares, fine fix it test it send PRs). I don't care about benchmarking those interfaces (that's for the people who do benchmarking always wrong or for those who do care about proper benchmarking - I don't want to be one of the first group and I've neither the equipment nor the experience to be in the second group, so let other people do this...)
  4. find a somehow 'armbian-like' kernel config (so that modules we have activated on most next/dev images are here too and people do not get fooled that this is the only board where *random kernel module* isn't there

1&2 are for me of most importance.. 3 to the point that those interfaces work and 4.. hmm I still hope that others join the 'party' otherwise I might bring it only to the point where it's usable for me (and with some nasty hacks, making it usable for me would probably be an easy task -  but I'm looking for a solution which is easy to maintain in case this SoC gets support by armbian and therefore I try to avoid nasty hacks)... 

On 5/23/2018 at 10:05 AM, tkaiser said:

'MTK6625L chip' -- does not exist

the chip is called mt6625ln if I saw this right (getting 'eye cancer' by reading such tiny tiny labels).. 

Share this post


Link to post
Share on other sites

A small follow up:

-USB dmesg error is gone,  due to (once again thank to frank-w):

On 5/22/2018 at 8:15 PM, chwe said:

xhci-mtk 1a1c0000.usb: fail to get vbus

CONFIG_REGULATOR_FIXED_VOLTAGE=y

 

so, USB devices get recognized:

[  253.503520] usb 3-1: new high-speed USB device number 2 using xhci-mtk

-general-packaging-4.17-dev.patch was applied to dev kernelbranch and packs the kernel as expected (didn't test the image yet).

-Flattened device trees still fail with more or less every combination which comes to my  mind (uImage/zImage). That's normally the last message I get... 

mt7623-uboot > setenv bootargs console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait coherent_pool=4M audit=0
mt7623-uboot > ext4load mmc 1:1 0x84000000 /boot/dtb/mt7623n-bananapi-bpi-r2.dtb
33841 bytes read in 44 ms (751 KiB/s)
mt7623-uboot > ext4load mmc 1:1 0x86000000 /boot/uInitrd
4789596 bytes read in 705 ms (6.5 MiB/s)
mt7623-uboot > ext4load mmc 1:1 0x83000000 /boot/zImage
6100568 bytes read in 874 ms (6.7 MiB/s)
mt7623-uboot > bootz 0x83000000 0x86000000 0x84000000
bootm flag=0, states=1
Kernel image @ 0x83000000 [ 0x000000 - 0x5d1658 ]
## Loading init Ramdisk from Legacy Image at 86000000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4789532 Bytes = 4.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 84000000
   Booting using the fdt blob at 0x84000000
bootm flag=0, states=700
   Loading Ramdisk to ffb6e000, end fffff51c ... OK
   Loading Device Tree to ffff4000, end fffff430 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

-the first cleaned up bootsequence is a bit faulty.. but I think it's just something obvious I missed.. bpi r2 boardconfig is separated from evb board, so in case a second board works with the same u-boot (to my knowledge all u-boots for mt-7623 SoCs are based on a 2014.04 and nobody tried to bring MT u-boot  support to upstream). 

Share this post


Link to post
Share on other sites

Last update for today... I compiled a kernel with earlyprintk (not set by default, and I think I lost it somehow when I messed around with kernelconfigs...) So it panics quite early with:

 

bootargs:

earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait coherent_pool=4M audit=0

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.43-mt7623n (root@Buildmachine) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5 SMP Thu May 24 00:19:20 CEST 2018
[    0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Bananapi BPI-R2
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] [WMT-CONSYS-HW][W]reserve_memory_consys_fn: name: consys-reserve-memory, base: 0xffe00000, size: 0x100000
[    0.000000] OF: reserved mem: initialized node consys-reserve-memory, compatible id mediatek,consys-reserve-memory
[    0.000000] cma: Reserved 64 MiB at 0xfb800000
[    0.000000] Unable to handle kernel paging request at virtual address 3fff4000
[    0.000000] pgd = c0004000
[    0.000000] [3fff4000] *pgd=00000000
[    0.000000] Internal error: Oops: 5 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.43-mt7623n #5
[    0.000000] Hardware name: Mediatek Cortex-A7 (Device Tree)
[    0.000000] task: c0f071c0 task.stack: c0f00000
[    0.000000] PC is at fdt_check_header+0xc/0x80
[    0.000000] LR is at __unflatten_device_tree+0x80/0x2d4
[    0.000000] pc : [<c091f818>]    lr : [<c06fdce0>]    psr: 600000d3
[    0.000000] sp : c0f01ed0  ip : c0f01ee0  fp : c0f01edc
[    0.000000] r10: 00000000  r9 : c104f0e4  r8 : 00000000
[    0.000000] r7 : c0e3ddfc  r6 : 3fff4000  r5 : c0e5db54  r4 : c0fba4f0
[    0.000000] r3 : 00000000  r2 : c104f0e4  r1 : 00000000  r0 : 3fff4000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment none
[    0.000000] Control: 10c5387d  Table: 8000406a  DAC: 00000051
[    0.000000] Process swapper (pid: 0, stack limit = 0xc0f00218)
[    0.000000] Stack: (0xc0f01ed0 to 0xc0f02000)
[    0.000000] 1ec0:                                     c0f01f14 c0f01ee0 c06fdce0 c091f818
[    0.000000] 1ee0: c0e1e58c c0e1e148 ffffffff c0e3ddfc c0e5db54 c0f06ec0 fff00000 c0ffa154
[    0.000000] 1f00: efffce80 fffff000 c0f01f34 c0f01f18 c0e3f088 c06fdc6c 00000000 c0f01f28
[    0.000000] 1f20: c012e374 c0f08488 c0f01fac c0f01f38 c0e03c34 c0e3f050 ffffffff 10c5387d
[    0.000000] 1f40: ffffffff 8000406a 80000200 c0bb9e24 c0c80000 c0f0bde8 c0fc8990 c0f28fd8
[    0.000000] 1f60: c0bb8414 c0f01fa4 c0f01f84 c0f01f78 c017e32c c017cfcc c0f01f9c c0f01f88
[    0.000000] 1f80: c017dc90 00000000 00008200 c0f03c40 ffffffff 8000406a 410fc073 00000000
[    0.000000] 1fa0: c0f01ff4 c0f01fb0 c0e00ae4 c0e033d0 00000000 00000000 00000000 00000000
[    0.000000] 1fc0: 00000000 c0e6ba28 00000000 c0fc8794 c0f03c58 c0e6ba24 c0f08600 8000406a
[    0.000000] 1fe0: 410fc073 00000000 00000000 c0f01ff8 8000807c c0e00a80 00000000 00000000
[    0.000000] [<c091f818>] (fdt_check_header) from [<c06fdce0>] (__unflatten_device_tree+0x80/0x2d4)
[    0.000000] [<c06fdce0>] (__unflatten_device_tree) from [<c0e3f088>] (unflatten_device_tree+0x44/0x54)
[    0.000000] [<c0e3f088>] (unflatten_device_tree) from [<c0e03c34>] (setup_arch+0x870/0xc8c)
[    0.000000] [<c0e03c34>] (setup_arch) from [<c0e00ae4>] (start_kernel+0x70/0x3c4)
[    0.000000] [<c0e00ae4>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.000000] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903000)
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x50/0x58 with crng_init=0
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

 

Any help is appreciated.. 

Share this post


Link to post
Share on other sites

From what I understand so far.. U-boot sits at the beginning of memory, defined in

#define CONFIG_SYS_TEXT_BASE		        0x81E00000

means that as soon as I start to load my stuf in >0x81E00000, I 'should be save'. The rest of u-boot is leveled to the highest available memory (or the highest u-boot can initialize)..

And the kernelpanic is related to, u-boot is moving around my dtb so that the kernel does not longer find it and therefore struggles due to not getting its information from the dtb. (written like a noob, but I'm not a u-boot hacker... :D). 

From what I think I understand (partly), everything between, SYS_TEXT_BASE and SYS_MALLOC_LEN should be save for Linux. right? :P 

And now.. the part which is confusing or 'not that clear'. So this is the u-boot confing related part for memory:

/**********************************************************************************************
 *                                          Memory
 **********************************************************************************************/
/* Memory layout */
/* DRAM definition */
/* 
 * Iverson 20140521 : We detect ram size automatically.
 *      CONFIG_SYS_SDRAM_SIZE define max uboot size.
 *      The max size that auto detection support is 256MB.
 */
#define CONFIG_NR_DRAM_BANKS		        1
#define CONFIG_SYS_SDRAM_BASE		        0x80000000

/* Code Layout */
//#define CONFIG_SYS_TEXT_BASE		        0x80000000
#define CONFIG_SYS_TEXT_BASE		        0x81E00000

/* Uboot definition */
#define CONFIG_SYS_UBOOT_BASE		        CONFIG_SYS_TEXT_BASE
#define CONFIG_SYS_UBOOT_MAX_SIZE           SZ_2M
#define CONFIG_SYS_INIT_SP_ADDR             (CONFIG_SYS_TEXT_BASE + \
                                                CONFIG_SYS_UBOOT_MAX_SIZE - \
                                                GENERATED_GBL_DATA_SIZE)

#define CONFIG_SYS_MALLOC_LEN               SZ_32M

/* RichOS memory partitions */
#define CONFIG_SYS_DECOMP_ADDR              0x80008000
#define CONFIG_SYS_LOAD_ADDR                0x83000000
#define CONFIG_SYS_IMAGE_HDR_ADDR           CONFIG_SYS_LOAD_ADDR

/* Linux DRAM definition */
#define CONFIG_LOADADDR			            CONFIG_SYS_LOAD_ADDR

/*
 * For booting Linux, the board info and command line data
 * have to be in the first 64 MB of memory, since this is
 * the maximum mapped by the Linux kernel during initialization.
 */
#define CONFIG_SYS_BOOTM_LEN	            0x4000000

So, my u-boot can initialize half of a memorychip (there are 4x512MB on the board),  up to 0x81E00000 and over (256MB-32MB=)224MB is used by u-boot so, better don't mess in this area as long as u-boot controls the hardware. The kernel itself has (according to the comment here) to be in the first 64MB (between 0x81E00000 and 0x85E00000 - I'm really bad in converting numbers.. :P), the FDT can be slightly over it. 0x86000000) and we give it some 'save space' means, 0x86000000 - 0x86080000 = 512kB which should be more than enough for a DTB, currently its:

mt7623-uboot > ext4load mmc 1:1 0x83000000 /boot/dtb/mt7623n-bananapi-bpi-r2.dtb
33841 bytes read in 49 ms (673.8 KiB/s)

 and over this there is space for uInitrd (0x86080000 - 0x87F80000) cause over 0x87F80000, the place is resvered by U-Boot with CONFIG_SYS_MALLOC_LEN. Are some of those env variables 'generic', means a normal u-boot should clearly understand what they are for  (e.g bootm_size etc.)? I found a example here:

#define DEFAULT_LINUX_BOOT_ENV \
        "loadaddr=0x82000000\0" \
        "kernel_addr_r=0x82000000\0" \
        "fdtaddr=0x88000000\0" \
        "fdt_addr_r=0x88000000\0" \
        "rdaddr=0x88080000\0" \
        "ramdisk_addr_r=0x88080000\0" \
        "scriptaddr=0x80000000\0" \
        "pxefile_addr_r=0x80100000\0" \
        "bootm_size=0x10000000\0"

or do I have to dive into this definition file and do a lot of comparing with mine? So adjusted to mine, this would mean:

#define DEFAULT_LINUX_BOOT_ENV \
        "loadaddr=0x82000000\0" \
        "kernel_addr_r=0x82000000\0" \
        "fdtaddr=0x86000000\0" \
        "fdt_addr_r=0x86000000\0" \
        "rdaddr=0x86080000\0" \
        "ramdisk_addr_r=0x86080000\0" \
        "bootm_size=0x10000000\0"

and a bit later I had to make some space for scriptaddr (e.g another 512kb --> 0x82000000 - 0x82080000 and set kernel_addr_r to 0x82080000).. 

 

I guess most of those questions can only be found out by testing.. :P  but just to get a clue if I think in the right direction... To avoid:

22 hours ago, chwe said:

every-time I try to solve eveything with something I think it's a smart solution I got fooled

 

  • Edit: better put script near to fdt_addr, due to,  don't need the lower space as long as it is properly loaded right? hmmmm... questions over questions... :lol:

Share this post


Link to post
Share on other sites

Sometimes... You've to try it.. :lol:

Welcome to the flattened device tree.... (I don't post the whole bootlog, but it comes into login screen) :rolleyes:

mmc1 is available
mt7623-uboot > setenv bootargs earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0
mt7623-uboot > setenv loadaddr 0x82000000
mt7623-uboot > setenv kernel_addr_r 0x82000000
mt7623-uboot > setenv fdtaddr 0x86000000
mt7623-uboot > setenv fdt_addr_r 0x86000000
mt7623-uboot > setenv rdaddr 0x86080000
mt7623-uboot > setenv ramdisk_addr_r 0x86080000
mt7623-uboot > setenv bootm_size 0x10000000
mt7623-uboot > ext4load mmc 1:1 ${fdtaddr} /boot/dtb/mt7623n-bananapi-bpi-r2.dtb
33841 bytes read in 67 ms (493.2 KiB/s)
mt7623-uboot > ext4load mmc 1:1 ${kernel_addr_r} /boot/zImage
6091368 bytes read in 870 ms (6.7 MiB/s)
mt7623-uboot > ext4load mmc 1:1 ${rdaddr} /boot/uInitrd
4789600 bytes read in 699 ms (6.5 MiB/s)
mt7623-uboot > bootz ${kernel_addr_r} ${rdaddr} ${fdtaddr}
bootm flag=0, states=1
Kernel image @ 0x82000000 [ 0x000000 - 0x5cf268 ]
## Loading init Ramdisk from Legacy Image at 86080000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4789536 Bytes = 4.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 86000000
   Booting using the fdt blob at 0x86000000
bootm flag=0, states=700
   Loading Ramdisk to 8fb6e000, end 8ffff520 ... OK
   Loading Device Tree to 8fb62000, end 8fb6d430 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.43-mt7623n (root@Buildmachine) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5 SMP Thu May 24 00:19:20 CEST 2018
[    0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Bananapi BPI-R2
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] [WMT-CONSYS-HW][W]reserve_memory_consys_fn: name: consys-reserve-memory, base: 0xffe00000, size: 0x100000
[    0.000000] OF: reserved mem: initialized node consys-reserve-memory, compatible id mediatek,consys-reserve-memory
[    0.000000] cma: Reserved 64 MiB at 0xfb800000
[    0.000000] percpu: Embedded 17 pages/cpu @eed99000 s38476 r8192 d22964 u69632
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 522303
[    0.000000] Kernel command line: earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1990528K/2096124K available (9216K kernel code, 771K rwdata, 2816K rodata, 1024K init, 563K bss, 40060K reserved, 65536K cma-reserved, 1244156K highmem)
...
[  OK  ] Started LSB: Start NTP daemon.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux 9 bananapir2 ttyS0

bananapir2 login:

Thank you @zador.blood.stained. :) 

Share this post


Link to post
Share on other sites

A shortly update:

U-Boot is fixed to a level where I decide, that it isn't worth to put more efforts in at the moment... Bootorder:

  1. tries to boot with bootscript sitting in /boot/boot.scr (tested works)
  2. in case there is not bootscript or the script fails --> uInitrd, zImage, dtb in armbians default folders and if there is no uInitrd (or it isn't 'sane') it boots with zImage and dtb only.
    booargs=earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0

     

Memory adressing:

~62MB for the kernel

512kB for boot.scr

512kB for DTB

32MB for uInitrd

Don't know how 'sane' those settings are, but it should be more than enough... :P 

 

In case someone wants for whatever reasons uImages with flattened device tree, you can place a bootscript in mmc 1:1 /boot/boot.scr and do whatever u-boot is able to do.  Every boot without a boot.scr will set some default bootargs (earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0), in case you test a build and those bootargs aren't correct for you (especially root=/dev/mmcblk0p1 and rootfstype=ext4) better interrupt the boot (you've a 3 seconds timeframe for doing that, and set proper bootargs for your boot to avoid fooling your kernel.. :P earlyprintk is enabled by default when you use my config file and it's set to the right serial-console for the R2

CONFIG_DEBUG_UART_PHYS=0x11004000

CONFIG_DEBUG_UART_VIRT=0xf1004000

(earlyprintk will be silent without proper settings here, and the currently available defconfig sets them false, probably cause it's based on the evb board, where UART0 is used as debug, whereas the R2 uses UART2 for it)

There is currently no 'preboot logic' for to decide if mmc 1 (SD-card) or mmc 0 (eMMC) should be initialized and u-boot expects ext4 FS ,  but cause all load commands and all calls to mmc_number/partition are done with variables, such a 'preboot-logic' shouldn't be that hard to implement. It's flexible enough but I didn't implement it yet. We're far away for a 'nand-sata-install' implementation and therefore there it's to early to care about such a implementation. As far as I see it at the moment such a 'preboot logic' wouldn't need any rework of the 'bootlogic' (but who knows, u-boot fooled me more than once... :P). There are still a bunch of warnings during build of u-boot but none of them seems to be 'harmful'. 

As long as u-boot doesn't bother me anymore or not behaves as it should, I wont clean it up more that it is now.. eMMC is not on my 'priority list' so don't expect that care much about it in the near future It's somewhere between HDMI and onboard wifi and I don't care about both 'features'... :P Just to point it out. I will not look into HDMI as long as those patches aren't available in Linus tree. If someone else writes a proper patch to implement it earlier fine, I'm not willing to do it (and I don't have a spare HDMI display to test it, so someone else has to test it too.. :P). 

 

799 bytes read in 34 ms (22.5 KiB/s)
Running boot/boot.scr from: mmc 1:1 using boot/boot.scr
## Executing script at 85f80000
33841 bytes read in 47 ms (703.1 KiB/s)
4789617 bytes read in 695 ms (6.6 MiB/s)
6091360 bytes read in 864 ms (6.7 MiB/s)
Booting boot/zImage boot/uInitrd boot/dtb/mt7623n-bananapi-bpi-r2.dtb from: mmc 1:1 using bootargs=initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0 loglevel=1
bootm flag=0, states=1
Kernel image @ 0x82000000 [ 0x000000 - 0x5cf260 ]
## Loading init Ramdisk from Legacy Image at 86080000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4789553 Bytes = 4.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 86000000
   Booting using the fdt blob at 0x86000000
bootm flag=0, states=700
   Loading Ramdisk to 8fb6e000, end 8ffff531 ... OK
   Loading Device Tree to 8fb62000, end 8fb6d430 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
...
...
...
[  OK  ] Reached target Login Prompts.
[  OK  ] Started LSB: Start NTP daemon.
[  OK  ] Reached target Multi-User System.
[  OK  ] Reached target Graphical Interface.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux 9 bananapir2 ttyS0

bananapir2 login:

Next steps:

  • Network (mostly untested, but as far as I know, it doesn't connect automatically to my router)
  • Kernelconfig should be adjusted to have something 'armbianalike'

As soon as network works 'reliable', I hope that others step in for discussion & testing. I think we reach than a point where most of the 'interesting features' (USB, SATA, Network) are there, so usage as NAS or 'Routerboard'.

At the moment, desktop is disabled, and might be disabled until someone deals with HDMI.

 

[off topic] Still don't think that I'm a experienced u-boot hacker... But arrogant enough to call my self a u-boot plumber now... :lol:

18959188.jpg

 

 

Share this post


Link to post
Share on other sites

Adjusted network so that ETH works now.. :) 

Bridged all interfaces together similar to how it is done for the Espressobin in the beginnings (it might need further adjustmens, since bridging all devices might not be what people want by default). Cause U-boot works reliable and my 'fake FDTI' starts to die slowly I'm happy that I don't need longer the UART console by default (only when things fail, so I should find one of my other USB-UARTS soon, cause I expect that this will happen soon. :P) ...

 

Edit:

(and yeah, there's a shitty 4GB card in it.. I flash a lot of Images at the moment and they work reliable enough for testing)

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


Welcome to ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.14.44-mt7623n 
System load:   0.01 0.03 0.04   Up time:       15 min
Memory usage:  2 % of 2013MB    IP:            192.168.0.52
Usage of /:    29% of 3.4G

 

root@bananapir2:~# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.52  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::6c62:cdff:fe97:b263  prefixlen 64  scopeid 0x20<link>
        ether 6e:62:cd:97:b2:63  txqueuelen 1000  (Ethernet)
        RX packets 1997  bytes 154397 (150.7 KiB)
        RX errors 0  dropped 50  overruns 0  frame 0
        TX packets 492  bytes 47847 (46.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Still a issue towards MAC adress:

[    0.625742] mtk_soc_eth 1b100000.ethernet: generated random MAC address 3e:68:21:75:f7:f2

so, when using DHCP on your router, the IP will not be stable... 

Share this post


Link to post
Share on other sites

Just to be clear here, I'm horrible in 'benchmarking' (and if I did something wrong, let me know) but I think the current network settings sucks due to horrible performance (probably have to blame my self due to insane network settings?)...

 

at the moment I've 3 boards on my router. A tinker (192.168.0.45) , a HC1 (192.168.0.57) and the R2(192.168.0.56). As soon as the R2 sends, performance is slow as hell (sudo cpufreq-set -r -g ondemand). Set to performance didn't change much, still slow as hell..

 

Tinker set as server, first 1 time from my HC1, then 3 times from the R2, and then send from tinker to the R2 where it's not full GbE (didn't set gov to performance on the tinker) but more or less ok-ish (the cables might not be the 'best one' but if the R2 is set as server it shows that more should be possible and it's not only the cable or do I miss something?)

opi@tinkerboard:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.0.45 port 5001 connected with 192.168.0.57 port 53252
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.07 GBytes   917 Mbits/sec
[  5] local 192.168.0.45 port 5001 connected with 192.168.0.56 port 52706
[  5]  0.0-10.2 sec  61.0 MBytes  50.2 Mbits/sec
[  4] local 192.168.0.45 port 5001 connected with 192.168.0.56 port 52708
[  4]  0.0-10.0 sec  71.4 MBytes  59.8 Mbits/sec
[  5] local 192.168.0.45 port 5001 connected with 192.168.0.56 port 52710
[  5]  0.0-10.3 sec  41.2 MBytes  33.6 Mbits/sec
^Copi@tinkerboard:~$ iperf -c 192.168.0.56
------------------------------------------------------------
Client connecting to 192.168.0.56, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.45 port 52888 connected with 192.168.0.56 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   996 MBytes   835 Mbits/sec

If I run iperf -c 192.168.0.57 -t 60 from the R2 with gov = performance it doesn't look that CPU is the bottleneck.. 

root@bananapir2:/sys/devices/system/cpu/cpu0/cpufreq# armbianmonitor -m         Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq

18:26:41: 1196MHz  0.00   0%   0%   0%   0%   0%   0%
18:26:46: 1196MHz  0.00   0%   0%   0%   0%   0%   0%
18:26:51: 1196MHz  0.00   0%   0%   0%   0%   0%   0%
18:26:56: 1196MHz  0.00   1%   0%   0%   0%   0%   0%
18:27:01: 1196MHz  0.00   0%   0%   0%   0%   0%   0%
18:27:06: 1196MHz  0.00   0%   0%   0%   0%   0%   0%
18:27:12: 1196MHz  0.00   1%   0%   0%   0%   0%   0%
18:27:17: 1196MHz  0.00   1%   0%   0%   0%   0%   0%
18:27:22: 1196MHz  0.00   1%   0%   0%   0%   0%   0%
18:27:27: 1196MHz  0.00   0%   0%   0%   0%   0%   0%
18:27:32: 1196MHz  0.08   1%   0%   0%   0%   0%   0%
18:27:37: 1196MHz  0.15   1%   0%   0%   0%   0%   0%
18:27:42: 1196MHz  0.22   0%   0%   0%   0%   0%   0%
18:27:47: 1196MHz  0.19   1%   0%   0%   0%   0%   0%
Time        CPU    load %cpu %sys %usr %nice %io %irq
18:27:52: 1196MHz  0.17   1%   0%   0%   0%   0%   0%
18:27:57: 1196MHz  0.16   0%   0%   0%   0%   0%   0%
18:28:02: 1196MHz  0.14   0%   0%   0%   0%   0%   0%
18:28:07: 1196MHz  0.13   0%   0%   0%   0%   0%   0%
18:28:12: 1196MHz  0.12   0%   0%   0%   0%   0%   0%
18:28:17: 1196MHz  0.11   0%   0%   0%   0%   0%   0%
18:28:22: 1196MHz  0.10   0%   0%   0%   0%   0%   0%^

And it doesn't look like something goes (horrible) wrong with packets drops:

root@bananapir2:~# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.56  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::6811:7aff:fe5e:4c98  prefixlen 64  scopeid 0x20<link>
        ether 6a:11:7a:5e:4c:98  txqueuelen 1000  (Ethernet)
        RX packets 4622354  bytes 6621845374 (6.1 GiB)
        RX errors 0  dropped 311  overruns 0  frame 0
        TX packets 1700891  bytes 2144695574 (1.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

So to the network experts here: How can we fix that? Can it be related to my quick & dirty approach bridging all wired interfaces together? Or is something else fishy... 

Share this post


Link to post
Share on other sites

a shortly: 

  • GbE still sucks and the current network defaults may need some rework anyway (getting it's IP via DHCP doesn't work on firstrun)
  • There are a bunch of generic drivers missing (my el cheapo 2.5'' USB3 enclosure isn't recognized, whereas it's no problem to access it from every other Armbian kernel I use... :P after adding some other generic mass storage drivers at least the cheap USB stick gets properly recognized... Anyone a clue what's needed for a 'Innostor IS621' USB-Sata drive to work? :D Cause the stick will suck in performance anyway, there's no chance to determine how fast USB is at the moment.. (it get's recognized as SuperSpeed USB but it's a 20$ 64GB noname stick, not worth to test something with it)... 
  • I got fooled by the dev kernel... booted it once just for fun.. Cause debug UART is on UART2, I expected that in bootargs console=ttyS2, actually this was never true for Franks 4.14 Kernel, as soon as you switch to a 'unpatched mainline' (that's what dev is) the console gets silent as soon as ttyS is initialized.  Rebooted probably to early and messed up something so that the FS was corrupted. I could see that setting bootargs to ttyS2 will work but the Image was too much corrupted to bring it up. So we need to patch either franks kernel to the default behavior or patch mainline to franks behavior (I prefer to patch mainline cause I think most other boards will have debug UART on UART0, similar to the reference board, but dev kernel has no priority for me)
  • CPU temperatures aren't accessible yet (probably also a missing module or 'not working' yet).

So for anyone want to join the party. USB-UART is a must, not only a 'makes things easier'.. 

Share this post


Link to post
Share on other sites

It seems that the backport (which was needed) to 4.14 has still issues towards network. e.g.

[    0.984999] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ethernet@1b100000/mdio-bus/switch@0[0]' - status (0)

I found some informations towards those issue:

http://forum.banana-pi.org/t/running-native-openwrt-with-4-14-20-kernel-on-bpi-r2/4973/6

 

I'm quite sure that I don't have 100% sane network settings yet but cause informations towards network issues are spread in various spaces and I'm not willing search through all those sources to get the informations I need. I call all the persons related to this board (e.g. @garywang @Ryder.Lee)

  • Why does iperf performance suck?
  • Is the issue (eth0/eth1 doesn't show up) properly solved on a 4.14 kernel?
  • I read that a lot of backport efforts where needed due to changes in 4.15, do they work properly?

In case not or not sure, I might consider to stick next to the upcoming 4.17 kernel (and dev to linus master) which might break a lot of the work done by frank-w to bring things up which he implemented before it reaches upstream. This would also mean that onboard wifi will most likely never work cause I've no interest patching this into a upstream kernel and if someone else does it, it has to be reviewed properly what I'm also not willing to do. That's not against frank-w 4.14 kernel, I think he puts a lot of efforts in it to bring the device up and running but I'm not able nor willing to search through all forum posts and wikis and other informationsources to get a clue what's working with 4.14 and whats not working (or not working as I expect). Not having a LTS kernel which works properly would be a major drawback. 

Share this post


Link to post
Share on other sites
12 hours ago, chwe said:
  • [ 0.984999] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ethernet@1b100000/mdio-bus/switch@0[0]' - status (0)

 

Please take a look at this https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ee7e16b66a766e8f922aafe5edf9353b9f37a424

 

BTW, I will suggest you to use the latest kernel v4.17 to fix some network problem.

Share this post


Link to post
Share on other sites
12 hours ago, Ryder.Lee said:

BTW, I will suggest you to use the latest kernel v4.17 to fix some network problem.

Already done yesterday.. Started as you somewhere suggested in the BPi forum with multi_v7_defconfig and throwout out everything I think it's not necessary (e.g. drivers for other SoCs) and activated (most of) the things which are needed for the R2 (e.g. MMC driver is not default, pmic etc.). Seems to boot without major issues now (I had some in the beginning, but those are gone).   

I think, I'll remove next from the buildoptions and  keep it as dev only until 4.17 gets stable. It doesn't make sense to deal with two 'mainline' kernel whereas one has backports & forward ports from the bsp (e.g. internal wifi) and a lot of R2 related adjustments. If this board gets armbian support and a second mt7623 board will come, we had to do a lot of adjustments in the 4.14 kernel to get both somehow equal supported (@TonyMac32 deals with such issues for the tinker/miqi where similar but different seems to be painful and I'm not patient enough to deal with such issues). Cause 'router-capabilities' is one of the 'most interesting features of this board I don't see any reason to stick to a kernel where this feature doesn't work 'properly'. So 4.14 buildoption will be removed from my repo soon.

 

For 4.17.0-rc7 (not pushed upstream):

  • adjusted bootscript works
  • USB3 mass storage works (I don't show numbers, throttling happens with larger iozone exercises without active cooling without a case and according to others, my 'test ssd' is limited to write speeds ~100MB/s  and read ~490MB/s. I'm not willing to take the Samsung SSD out of my buildmachine just to benchmark the USB)
  • SATA works 
  • sane network configuration is still missing
  • kernel config has a bunch of not needed drivers in it due to starting from multi_v7_defconfig (partly kicked out unneeded stuff, but still a lot of things which I missed). BTW @Ryder.Lee does Mediatek plan to push something like mediatek_defconfig upstream (similar to suxi_defconfig)? This also means that probably a lot of armbians defaults for mainlinekernels are missing.
So now for armbians network experts.. I hope one of you is willing to explain how I can implement sane settings for this board. Our default for configuration is network-manager (due to average user has problem to set-up wifi properly with /etc/network/interfaces). I'm still not 100% familiar how network-manager, network.d and /etc/network/interfaces interact together. Maybe someone is willing to give me a short insight? More or less every 'tutorial' I found claimed to purge network-manager as soon as you play with interfaces which is a no-go due to network manager is part of armbians default and I don't want to break 'standard behavior' (just to avoid support questions like 'why does nmtui not work properly on the R2?').
From the hardware-side, R2 should look like the following:
 
http://www.fw-web.de/dokuwiki/doku.php?id=en:bpi-r2:network:start (once again, thanks to @frank-w, his wiki is one of the few sources where informations are collected, @Sinovoip, it would make sense to describe this briefly in your wiki too, there's a link to franks wiki but you'd better hope that he never removes his wiki, otherwise people are simply lost due to lack of information - counting on someone else, who describes in his wiki how your hardware works whereas your documentation only links to his wiki doesn't look like a 'sane business model' to me)
fetch.php?media=bpi-r2:network:gmac.png 
and the current (upstream) devicetree looks like the following:
&eth {
	status = "okay";

	gmac0: mac@0 {
		compatible = "mediatek,eth-mac";
		reg = <0>;
		phy-mode = "trgmii";

		fixed-link {
			speed = <1000>;
			full-duplex;
			pause;
		};
	};

	mdio: mdio-bus {
		#address-cells = <1>;
		#size-cells = <0>;

		switch@0 {
			compatible = "mediatek,mt7530";
			#address-cells = <1>;
			#size-cells = <0>;
			reg = <0>;
			reset-gpios = <&pio 33 0>;
			core-supply = <&mt6323_vpa_reg>;
			io-supply = <&mt6323_vemc3v3_reg>;

			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				reg = <0>;

				port@0 {
					reg = <0>;
					label = "wan";
				};

				port@1 {
					reg = <1>;
					label = "lan0";
				};

				port@2 {
					reg = <2>;
					label = "lan1";
				};

				port@3 {
					reg = <3>;
					label = "lan2";
				};

				port@4 {
					reg = <4>;
					label = "lan3";
				};

				port@6 {
					reg = <6>;
					label = "cpu";
					ethernet = <&gmac0>;
					phy-mode = "trgmii";

					fixed-link {
						speed = <1000>;
						full-duplex;
					};
				};
			};
		};
	};
};

Is it a good idea to define those interfaces via network.d? Similar to the espressobin (e.g. eth 0, wan lan0-lan3,), whereas wan is configured as DHCP by default and lan0-lan3 are configured as vlans? /etc/network/interfaces wouldn't need any adjustments from armbians default (having  source /etc/network/interfaces.d/* in the first line). Any hint where my thinking is fundamentally wrong is appreciated doing 'serious' network configuration wasn't something I did in the past and mixing this things between network.d /etc/network/interfaces and network-manager doesn't make it easier to understand. Who is Hugh Hefner and who are the House Bunnies inside the 'network mansion'? :rolleyes::lol:

Share this post


Link to post
Share on other sites

I guess my question is, what is the board for, really?  Also, should we expect this level of "uniqueness" from any other boards using this SoC?  I don't have this board to poke at, but my goodness...

Share this post


Link to post
Share on other sites

R2.jpg.facc9d21d691cf719d74abe2da6a39cb.jpg

 

oops, that's the other *fruit-pi* boardmaker..  :ph34r:

 

2 hours ago, TonyMac32 said:

I guess my question is, what is the board for, really?

hmm, if this would be 100% clear, I think 'more serious developers' would work to bring up the SoC and therefore also this board for armbian... As @tkaiser said multiple times, mixing router with NAS might be not the best idea. So it could be either a NAS (I think there are other boards in the pipe with similar/better performance/price, e.g. RK3399 based ones) or a Routerboard (there are others, e.g. ClearFog but those are a bit pricier). So at the moment, I can't give you a perfect answer to this one.. 

 

2 hours ago, TonyMac32 said:

Also, should we expect this level of "uniqueness" from any other boards using this SoC? 

As soon as other boards are announced and their sources are available, we will see how much they differ from this one...  I don't have any insider informations what others plan.. Having a LTS Kernel was a nice idea but it seems that 4.14 was to early to get what you want out of it.  From what I see on lkml, mediatek works quite hard to clean up the 7623.dtsi and 7623-bananapi-bpi-r2.dts (https://lkml.org/lkml/2018/2/23/176). If they aren't any other Routers/SBCs interested in bringing up a board based on this SoC, they wouldn't put so much effort in doing this. 

Correct me if I'm wrong but as far as I understand @Ryder.Lee is a Mediatek employee (responsible for the R2 on mediateks side) and @garywang is part of sinovoip and the 'counter-part'.  Everything upstream related to the SoC/Board is done by Mediatek and Sinovoip provides their LEDE, ubuntu etc. images). Btw. @Nora Lee on the product page, there's a 

Quote

OS: Android,Ubuntu,Debian,Bananian

 

Bananian Linux is no longer under active development, and for sure, they never supported the R2 (they supported the R1, but different story...). You also announced LEDE support on multiple pages/forum but this is missing on the product page... 

 

The SoC looks interesting to me and even if this doesn't get merged to armbian it is/was (sometimes) fun/frustration to deal on this level of development and I learned a lot out of this funny/frustrating 'project'.  IMO, bringing up the mt7523 boardfamily makes only sense when other boards are widely available based on this SoC. Otherwise, maintaining the support over time (forum & kernel) wouldn't be worth the efforts. 

On 5/22/2018 at 8:15 PM, chwe said:

This thread should give the maintainers and interested people a clue what's needed to get this board up with armbian

  • u-boot - partly/mostly fixed (I would expect that other boards will be based on the same 2014.04 u-boot 'hopefully' with not that much "uniqueness" on u-boot related stuff e.g. ram)
  • kernel -  on going (looks good so far)
  • binary blobs for booting - still mysterious (and I hope that @Ryder.Lee or @garywang will enlighten us a bit).

Share this post


Link to post
Share on other sites
11 minutes ago, chwe said:

mixing router with NAS might be not the best idea.

 

OK.  I have an idea, but it's one that honestly a dual NIC board (Rock64 with expansion board, etc can do, and that's hook up my HDHomerun to a TVHeadend server directly, keeping their traffic off of the main network.  To use both of the ones I have 3 adapters would be good. 

 

Possibly to play overseer on a small cluster of boards?  Seems an academic use at best though.  Still, it does seem interesting

Share this post


Link to post
Share on other sites

Todays shortly:

On 5/29/2018 at 3:58 PM, chwe said:
  • sane network configuration is still missing
  • kernel config has a bunch of not needed drivers in it due to starting from multi_v7_defconfig (partly kicked out unneeded stuff, but still a lot of things which I missed). BTW @Ryder.Lee does Mediatek plan to push something like mediatek_defconfig upstream (similar to suxi_defconfig)? This also means that probably a lot of armbians defaults for mainlinekernels are missing.

wouldn't say it's 100% satisfying but I'm okay to do it similar to the EspressoBin:

  • network.d controls now all interfaces and they're bridged to br0 per default (wip)
  • kernelconfig got some generic stuff as module
  • 4.14 was dropped & bootscript adjusted to mainline behavior

For the responsible persons from Sinovoip/Mediatek @Lion Wang @garywang @Nora Lee @Ryder.Lee:

There are still questions where you're in charge! And to make it more clear, I'll not send a pull request proposing that the SoC and the board gets any sort of support until those questions are answered (it seems that you follow the content, cause obviously there's a actual boardpicture on your productpage now - but bananian is still as supported OS there which is wrong ;)):

  • On 5/29/2018 at 8:31 PM, chwe said:

    binary blobs for booting - still mysterious (and I hope that @Ryder.Lee or @garywang will enlighten us a bit).

     

  • On 5/23/2018 at 12:41 PM, chwe said:

    It looks like the following:

    
    	dd if=PI-R2-HEAD440-0k.img of=$2 bs=440 seek=0 count=1 status=noxfer > /dev/null 2>&1
    	dd if=BPI-R2-HEAD1-512b.img of=$2 bs=512 seek=1 status=noxfer > /dev/null 2>&1
    	dd if=BPI-R2-preloader-2k.img of=$2 bs=1k seek=2 status=noxfer > /dev/null 2>&1
    	dd if=u-boot.bin of=$2 bs=1k seek=320 status=noxfer > /dev/null 2>&1

    but if I've a look into the files:

    
    -rw-rw-r-- 1 opi opi     1536 May 13 14:19 BPI-R2-HEAD1-512b.img
    -rw-rw-r-- 1 opi opi      440 May 13 14:19 BPI-R2-HEAD440-0k.img
    -rw-rw-r-- 1 opi opi    91996 May 13 14:19 BPI-R2-preloader-2k.img

    HEAD1-512b doesn't fit, and gets mostly overwritten by the preloader... It works, and I don't see anything going wrong but can you explain what HEAD-512b exactly does? I guess it sets some env variables for u-boot cause even when I remove them fully from the boardconfig file in u-boot, they're still there... How are those HEAD files generated, is there a chance to generate them by our own and when not, can you provide a head which is cleaned up (I don't need any variables set by a binary, I set them happily by my self with the boardconfig or via bootscript :)). 

    Next question about those binaries: 

    
    BPI-R2-preloader-2k.img
    BPI-R2-720P-2k.img
    BPI-R2-2k-SD-20180320.img
    BPI-R2-1080P-2k.img
    

    can you explain the differences between all those 2k preloaders? I guess 720p/1080p relates to HDMI, is this just during bootup? (in case yes, I don't care) At the moment I use 'BPI-R2-preloader-2k.img' and it works.. what's the difference between this one and the more recent one 'BPI-R2-2k-SD-20180320.img'?

     

     

I do understand that you may not fully describe how those blobs work due to NDAs but you can describe the differences between the various 2k preloaders and why I should use the one or the other. Whats the difference between those preloaders? And a use this one for SD and this one for eMMC doesn't count. Why are there so many? Does the 720P/1080P preloader make a difference later or only during boot? What is BPI-R2-HEAD1-512b.img for? It obviously doesn't need to be fully on a Image cause I override ~2/3 of it and it still works... :rolleyes: But it seems to not work (on SD-Card) without - this looks just not sane to me. It's hacky and I prefer to have a 'more clean' solution (and IMO a requirement to share it 'in good faith' with others). Those binaries or part of your u-boot code sets default bootargs (and if it's in u-boot it self then it's on a place where it should not be, cause I cleaned the 'boardconfig.h' from everything related to bootmenu etc.). See snippet from serial boot:

dev_num = 1
***size=4096, offset=1577059840, blk_start=3080195, blk_cnt=8
*** Warning - bad CRC, using default environment

bootargs = board=bpi-r2 earlyprintk console=tty1 fbcon=map:0 console=ttyS0,115200 vmalloc=496M debug=7 initcall_debug=0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
Net:   mtk_eth
Uip activated

I can overwrite this stuff but I don't like it cause it confuses people, those bootargs will never be true for armbian or my images so it's just garbage on the bootconsole... 

 

Share this post


Link to post
Share on other sites
On 5/29/2018 at 9:58 PM, chwe said:

BTW @Ryder.Lee does Mediatek plan to push something like mediatek_defconfig upstream (similar to suxi_defconfig)? This also means that probably a lot of armbians defaults for mainlinekernels are missing.

 

 

You can use this defconfig https://github.com/objelf/linux-lima/blob/mediatek-lima-4.16-rc5/arch/arm/configs/mediatek_v7_defconfig

 

We do have plans to add mediatek_v7_defconfig in the future for for arm32 but I can't give you any roadmap for that since it mostly falls under the spare time work.

 

At most I can guarentee that this board's functionality will be added gradually in upcoming days.

Share this post


Link to post
Share on other sites
On 5/31/2018 at 5:41 AM, Ryder.Lee said:

some thoughts when going over this...

https://github.com/objelf/linux-lima/blob/73f8fb376942e1cb30f7fac1cc08620363a3db0b/arch/arm/configs/mediatek_v7_defconfig#L203 

could be potential risky when giving it to endusers...

 

https://github.com/objelf/linux-lima/blob/73f8fb376942e1cb30f7fac1cc08620363a3db0b/arch/arm/configs/mediatek_v7_defconfig#L167 

something the 'enduser' for sure not wants... 

 

both might be helpful during development testing.. but potential harmful on productive use cases..  So, I'll stick to a (adjusted) multi_v7_defconfig. I prefer opt-in for such 'features' rather than opt-out (going through the whole defconfig to see what's important, and what comes from dev usage seems to be an easy way that I miss something).

 

So todays (not so) shortly:

  • The kernel got a bit more clean-up  (far away from perfect.. but 'workable')
  • Few things where added but not tested (e.g. mtk's IR driver,  some network stuff, onewire driver etc.)
  • On 5/23/2018 at 1:27 PM, tkaiser said:

    I hope you call the BOARDFAMILY mt7623 later. As far as I know at least ACT POWER plans to release another MT7623 device focused on NAS use case soon and maybe they're willing to support their own hardware and provide technical documentation.

    done.. :P If it fools us with a mt7623A board, well we will see what happen...

  • Network works now on firstboot with network.d and all interfaces bridged

    opi@bananapir2:~$ sudo ifconfig
    br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 192.168.0.66  netmask 255.255.255.0  broadcast 192.168.0.255
            inet6 fe80::1041:37ff:febb:72db  prefixlen 64  scopeid 0x20<link>
            ether 12:41:37:bb:72:db  txqueuelen 1000  (Ethernet)
            RX packets 2330  bytes 214325 (209.3 KiB)
            RX errors 0  dropped 53  overruns 0  frame 0
            TX packets 1742  bytes 346533 (338.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet6 fe80::c4b5:1dff:fe77:bdda  prefixlen 64  scopeid 0x20<link>
            ether c6:b5:1d:77:bd:da  txqueuelen 1000  (Ethernet)
            RX packets 2631  bytes 323319 (315.7 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 1794  bytes 371359 (362.6 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device interrupt 207
    
    lan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether c6:b5:1d:77:bd:da  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lan1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether c6:b5:1d:77:bd:da  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lan2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether c6:b5:1d:77:bd:da  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lan3: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether c6:b5:1d:77:bd:da  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 9  bytes 840 (840.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 9  bytes 840 (840.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    wan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            ether c6:b5:1d:77:bd:da  txqueuelen 1000  (Ethernet)
            RX packets 2631  bytes 275961 (269.4 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 1742  bytes 346533 (338.4 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

     

  • iperf still sucks but I start to trust that something is fishy here... e.g. 

    opi@bananapir2:~$ speedtest --simple --server xxxx
    Ping: 14.18 ms
    Download: 480.44 Mbit/s
    Upload: 298.84 Mbit/s
    opi@bananapir2:~$ speedtest --simple --server xxxx
    Ping: 15.857 ms
    Download: 517.29 Mbit/s
    Upload: 298.57 Mbit/s
    opi@bananapir2:~$ speedtest --simple --server xxxx
    Ping: 14.526 ms
    Download: 488.41 Mbit/s
    Upload: 286.70 Mbit/s

    against a server near to my hometown looks ok-ish, whereas iperf in the local network completely sucks:

    opi@bananapir2:~$ iperf3 -c 192.168.0.45
    Connecting to host 192.168.0.45, port 5201
    [  4] local 192.168.0.66 port 52802 connected to 192.168.0.45 port 5201
    [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
    [  4]   0.00-1.00   sec  3.55 MBytes  29.8 Mbits/sec  143   32.5 KBytes
    [  4]   1.00-2.00   sec  3.23 MBytes  27.1 Mbits/sec  128   33.9 KBytes
    [  4]   2.00-3.00   sec  1.04 MBytes  8.76 Mbits/sec  100   33.9 KBytes
    [  4]   3.00-4.00   sec  1.04 MBytes  8.76 Mbits/sec  100   33.9 KBytes
    [  4]   4.00-5.00   sec  1.04 MBytes  8.76 Mbits/sec  100   33.9 KBytes
    [  4]   5.00-6.00   sec  3.72 MBytes  31.2 Mbits/sec  164   33.9 KBytes
    [  4]   6.00-7.00   sec  1.04 MBytes  8.76 Mbits/sec  100   33.9 KBytes
    [  4]   7.00-8.00   sec  1.04 MBytes  8.76 Mbits/sec  100   33.9 KBytes
    [  4]   8.00-9.00   sec  1.04 MBytes  8.76 Mbits/sec  100   33.9 KBytes
    [  4]   9.00-10.00  sec  3.72 MBytes  31.2 Mbits/sec  164   33.9 KBytes
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bandwidth       Retr
    [  4]   0.00-10.00  sec  20.5 MBytes  17.2 Mbits/sec  1199             sender
    [  4]   0.00-10.00  sec  20.3 MBytes  17.0 Mbits/sec                  receiver
    
    iperf Done.

    as said:

     

    On 5/23/2018 at 2:28 PM, chwe said:

    I don't care about benchmarking those interfaces (that's for the people who do benchmarking always wrong or for those who do care about proper benchmarking - I don't want to be one of the first group and I've neither the equipment nor the experience to be in the second group, so let other people do this...)

    Cause it seems now that I'm one of the 'first group', I decided to stop taking care whats wrong with the setup/tests I'm doing and why something is fishy here... All tests were done with gov. performance, so let others deal with it.

  • For whatever reason I killed once again mass storage for my external HD. It worked once during 4.17 kernel testing.. but I killed it once again (and I didn't test usb mass storage after every change in kernelconfig)... The memory stick still works.. but the shitty 'Innostor IS621' decided to bother me.. Let's see if I'm patient enough to dig into it and see whats wrong (from what I remember, I got it to the point where the CPU had to throttle when doing heavy stuff with files on USB3 but, I can't test it with the current kernelconfig.. :D ).. 

  • We have now CPU temperature in userspace :thumbup:
     ____                                  ____  _   ____  ____
    | __ )  __ _ _ __   __ _ _ __   __ _  |  _ \(_) |  _ \|___ \
    |  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |_) | __) |
    | |_) | (_| | | | | (_| | | | | (_| | |  __/| | |  _ < / __/
    |____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|   |_| |_| \_\_____|
    
    
    Welcome to ARMBIAN 5.45 user-built Debian GNU/Linux 9 (stretch) 4.17.0-rc7-mt7623
    System load:   0.00 0.04 0.03   Up time:       11 min
    Memory usage:  3 % of 2018MB    IP:            192.168.0.66
    CPU temp:      40°C
    Usage of /:    4% of 29G

    and therefore also in armbianmonitor:

    opi@bananapir2:~$ sudo armbianmonitor -m
    Stop monitoring using [ctrl]-[c]
    Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
    
    17:47:42:  748MHz  0.00   2%   0%   0%   0%   1%   0% 40.0°C  0/7
    17:47:47:  748MHz  0.00   1%   0%   0%   0%   0%   0% 39.3°C  0/7
    17:47:52:  748MHz  0.00   1%   0%   0%   0%   0%   0% 39.3°C  0/7
    17:47:58:  748MHz  0.08   1%   0%   0%   0%   0%   0% 39.2°C  0/7
    17:48:03:  748MHz  0.07   1%   1%   0%   0%   0%   0% 39.2°C  0/7^C

    and a thumb test thinks this could be more or less accurate.. 

  • Installed kernel headers and build 'cryptodev' from their github cause the 1.9 version from their downloadpage seems to be broken. A short test (gov. performance) showed that it 'should work':

    opi@bananapir2:~/cryptodev-linux/tests$ ./speed
    Testing NULL cipher:
            Encrypting in chunks of 512 bytes: done. 844.41 MB in 5.00 secs: 168.88 MB/sec
            Encrypting in chunks of 1024 bytes: done. 1.69 GB in 5.00 secs: 0.34 GB/sec
            Encrypting in chunks of 2048 bytes: done. 3.37 GB in 5.00 secs: 0.67 GB/sec
            Encrypting in chunks of 4096 bytes: done. 4.91 GB in 5.00 secs: 0.98 GB/sec
            Encrypting in chunks of 8192 bytes: done. 7.70 GB in 5.00 secs: 1.54 GB/sec
            Encrypting in chunks of 16384 bytes: done. 11.10 GB in 5.00 secs: 2.22 GB/sec
            Encrypting in chunks of 32768 bytes: done. 14.38 GB in 5.00 secs: 2.88 GB/sec
            Encrypting in chunks of 65536 bytes: done. 16.90 GB in 5.00 secs: 3.38 GB/sec
    
    Testing AES-128-CBC cipher:
            Encrypting in chunks of 512 bytes: done. 112.04 MB in 5.00 secs: 22.41 MB/sec
            Encrypting in chunks of 1024 bytes: done. 222.83 MB in 5.00 secs: 44.57 MB/sec
            Encrypting in chunks of 2048 bytes: done. 404.75 MB in 5.00 secs: 80.95 MB/sec
            Encrypting in chunks of 4096 bytes: done. 640.49 MB in 5.00 secs: 128.10 MB/sec
            Encrypting in chunks of 8192 bytes: done. 943.69 MB in 5.00 secs: 188.73 MB/sec
            Encrypting in chunks of 16384 bytes: done. 1.24 GB in 5.00 secs: 0.25 GB/sec
            Encrypting in chunks of 32768 bytes: done. 1.47 GB in 5.00 secs: 0.29 GB/sec
            Encrypting in chunks of 65536 bytes: done. 1.61 GB in 5.00 secs: 0.32 GB/sec

    with ~50% higher numbers as @garywang published (okt 17) in the bpi forum (whatever this means, I don't care at the moment). A question for @zador.blood.stained, could we build cryptodev with chroot in 'family_tweaks()' in case this SoC gets supported by armbian? Do you think this is a sane approach or should we avoid such stuff and the users have to do it on their own (installing headers, build the lib. and take care that it is done in a sane way). I think it could also be achieved with the boardspecific part of Armbianconfig but there are 'serious devs' needed to decide which way is best for the project. 

  • There's still some 'unfinished business' towards those binary blobs, so a frankly reminder @Lion Wang @garywang @Nora Lee & @Ryder.Lee. If you don't want to explain those questions, I see no reason to spend much more time with this board. It works (mostly), I showed that it could be integrated into armbians buildscript in a more or less sane way and I think we're on a 'ok-ish' starting point for further optimizations. But if there's no interest from your side, I don't see a reason to care about optimizations nor pushing it into armbian nor convince the maintainers that they should do...

In case someone wants to have a look into 'armbianmonitor -m' (e.g. @tkaiser:P)... There you go: http://ix.io/1c7C I'm sure, you'll find a bunch of things which are 'not good' (yet).. Feel free to comment it, but I might need help to fix it. And as long as the point above isn't properly answered, it might not be of 'high priority'... 

I might spend some time with u-boot once again, try to integrate armbianEnv.txt (boot.cmd works but aEnv.txt might be a bit more 'userfriendly') and probably play a little bit with network (e.g. vlan etc) but more for my own interest than to fix things..

From this point here, there won't be much updates anymore until a discussion starts about pro/cons to support the board/SoC and the issues discussed above. Proof of concept is here, not perfect but for 'bringing up a new SoC the first time' I think, it isn't that bad... :P :lol:

Share this post


Link to post
Share on other sites
21 minutes ago, chwe said:

A question for @zador.blood.stained, could we build cryptodev with chroot in 'family_tweaks()' in case this SoC gets supported by armbian? Do you think this is a sane approach or should we avoid such stuff and the users have to do it on their own (installing headers, build the lib. and take care that it is done in a sane way). I think it could also be achieved with the boardspecific part of Armbianconfig but there are 'serious devs' needed to decide which way is best for the project. 

Do we really need it? AF_ALG is present in new kernels, works with newer openssl versions out of the box and gives +/- the same if not better performance compared to cryptodev AFAIK.

Share this post


Link to post
Share on other sites
6 minutes ago, zador.blood.stained said:

Do we really need it?

I've no idea... :lol: You know kerneldevelopment a way better to make a proper decision..  I think most of the stuff to try such things is there:

https://github.com/chwe17/build/blob/1bcd9bbd7e5453ef92982add9fb7f2759df11693/config/kernel/linux-mt7623-dev.config#L5578-L5605

so everyone having the board can build, compare, 'benchmark', and test what's the better decision..  I won't do it until I need it and it affects me (already spend 'some' time to polish things which I don't care really much).  It would be boring if everything works perfect out of the box... :P 

 

IMO we need answers (from sinovoip) and discussion here... 

Share this post


Link to post
Share on other sites
On 5/27/2018 at 1:05 AM, chwe said:

I got fooled by the dev kernel... booted it once just for fun.. Cause debug UART is on UART2, I expected that in bootargs console=ttyS2, actually this was never true for Franks 4.14 Kernel, as soon as you switch to a 'unpatched mainline' (that's what dev is) the console gets silent as soon as ttyS is initialized.  Rebooted probably to early and messed up something so that the FS was corrupted. I could see that setting bootargs to ttyS2 will work but the Image was too much corrupted to bring it up. So we need to patch either franks kernel to the default behavior or patch mainline to franks behavior (I prefer to patch mainline cause I think most other boards will have debug UART on UART0, similar to the reference board, but dev kernel has no priority for me)

 

Hi,

 

i changed Uart (Uart2=>ttyS0) and MMC (SD=0,emmc=1) from mainline to make my kernels compatible with official images (defined my images same way).

 

i see some definitions...maybe they can be used to define which uart is used for debug-uart without changing the order in dts(i)

aliases {
	serial2 = &uart2;
};

chosen {
	stdout-path = "serial2:115200n8";
};

btw. 2nd gmac, hdmi, poweroff and some other stuff is working now in (my) 4.14...hnat is ported, but i don't know if it is working due to a "strange" test (cpu-interrupts increasing)

Share this post


Link to post
Share on other sites
1 hour ago, frank-w said:

btw. 2nd gmac, hdmi, poweroff and some other stuff is working now in (my) 4.14.

did you ever measured performance with the second gmac.. And is this a forward port of the 4.9 network stuff or do they got this properly working with the DSA-Driver? I took a break from development for the R2 for a while due to crappy networkperformance with mainline and the DSA driver (and cause of the good weather here.. :P). I like the idea of those DSA-drivers but it seems that it does need some work to get it properly working.

 

Btw.: in case you're interested to build your images with armbians buildscript I can bring back your 4.14 kernel into my fork. I dropped it due to 'bad network performance' but mainline doesn't seem to perform much better here and cause that's a 'oneman-show' for this board at the moment, I wasn't confident to maintain two kernels, but in case you want join the party well it would make sense to have your 4.14 kernel back. :) 

Share this post


Link to post
Share on other sites

Have not tested performance yet, because my freetime is also limited. I also have only a 12mbit adsl internet-connection where this should not be limited by 2nd gmac :)

as i read 4.17 fixes some network-issues....but which/how? @ryder.lee will these ported to 4.14 or can you show me the patches? Currently hang on porting the gmac-patch to 4.18 file dsa2.c which is completely changed with 4.15 (not only new functions). Here i need some help from anybody who knows the new dsa-core. Wifi-driver is already ported (no changes compared to 4.16 where only timers changed).

 

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

 

Share this post


Link to post
Share on other sites
On 7/9/2018 at 1:27 AM, chwe said:

did you ever measured performance with the second gmac.. And is this a forward port of the 4.9 network stuff or do they got this properly working with the DSA-Driver? I took a break from development for the R2 for a while due to crappy networkperformance with mainline and the DSA driver (and cause of the good weather here.. :P). I like the idea of those DSA-drivers but it seems that it does need some work to get it properly working.

 

 

If you really care the throughput you could try to adjust irq_affinity or rps.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
1 1