Jump to content

Banana Pi M2+ H5


@lex

Recommended Posts

I just received this sample sent by Nora Lee (Foxconn). I have put here the H3 and H5 side by side.

I have been told it is pin to pin compatible so basically same pinctrl config would work, right? Let's find out, will try to build an Image with legacy and mainline and check out what we have here.

Hey, don't expect a technical overview here. :)

 

image.thumb.png.734ce72e0e74d768403d31aacec17f37.png

Link to comment
Share on other sites

1 hour ago, @lex said:

I have been told it is pin to pin compatible so basically same pinctrl config would work, right?

 

Just look at Orange Pi Zero Plus 2: same PCB, one batch with H3 in the reel, the other batch H5. Due to software incompatibility use cases and usability of the two variants differ a lot (and I personally have not the slightest idea why 'we' started here to support the H5 variant at all since IMO no reasonable use case exists -- H3 variant with legacy kernel + Mali and video acceleration is something different)

 

So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right?

Link to comment
Share on other sites

On 12/21/2017 at 7:19 PM, tkaiser said:

So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right?

Well, i think it is about use case too. We can draw some highlights / differences  here (you can correct me if wrong or missed info) :

* (m2+ h5) x (opiz2+h5)

* Dram: 1 GB (m2+ h5) x 512 MB (opiz2+h5)

* HDMI output x HDMI Output

* Gbps + AP6212A1 x AP6212A1

* BT x BT

* Reversed CSI pins x Reversed CSI pins (that means you need their sensor if you want a cheap camera or customize your sensor, more expensive)

* eMMC: 8GB x 8GB

* mali: ? x ? (i have read some where some user/developer got it working in fb, can't remember exactly)

* price: ? x good

* availability: ? x now

 

If you ask me which one i prefer (H3 or H5) i don't hesitate to say: H5 (unless you need mali). And you need 1 GB of Dram to have a Browser experience.

Regarding design flaw (voltage regulator) i can't comment, maybe it was a decision made  due to BSP availability at the time, good or bad? who knows and they have the resources to "fix"  the mistake if they want to. If we take for example the recent release of the BSP with kernel 4.4 that has no voltage regulator support we can infer this PCB (with H3) has some "advantages" and can run 4.4. Maybe AW release H5 BSP with missing voltage regulator support too (haha).

 

Ok then, my first try with legacy (used u-boot and rootfs from OPIz2+H5 i had laying around here), was very promising but finally hit a wall, u-boot works and kernel boots fine but for whatever reasons SD card was not recognized when trying to mount /dev/mmcblk1p2 and i get freeze at this point (obviously).

BT have some errors indicating it is really a AP6212A1.

 

If I can't find a workaround for the SD card freeze will move on to kernel 4.14.y.

If someone have any hint for the SD card issue, please let me know.

Edited by @lex
update info
Link to comment
Share on other sites

5 minutes ago, @lex said:

(m2+ h5) x (opiz2+h5)

 

Sorry, I was not talking about a comparison of those two boring boards but referenced the Xunlong board just as a starting point wrt software situation. For my use cases OPi Zero Plus 2 regardless which SoC is used is uninteresting anyway and it's more or less the same with M2+ since overpriced. Software situation with Allwinner is a constant mess and I gave up on them already. If Allwinner boards cost less than 15 bucks they're worth a look for IoT purposes or lowend NAS but for everything else (except camera maybe) there are better alternatives in the meantime. Disclaimer: only talking about my use cases.

 

Final note: 'eMMC: 8GB x 8GB' -- at least on the OPi Zero Plus 2 I shortly tested with there was amazingly fast eMMC (40/80 MB/s write/read) and at least on my BPi M2+ is the slowest eMMC I've ever encountered (6.5 MB/s write, I forgot the read 'speed' already). So depending on the use case (eg. expecting 'class 10' performance which would require at least 10 MB/s sequential write) it's always necessary to look a bit closer since on the majority of Allwinner boards the eMMC is slow crap (Xunlong being the notable exception but even they replaced fast eMMC on some Orange Pi in the meantime with slow one which is somewhat understandable given the constant rise of BOM costs for flash memory)

 

Link to comment
Share on other sites

Disabling eMMC i was able to boot up to maintenance console but not without some tweaks, trial and error.

U-boot needs some work and kernel too.

 

eMMC definitely is not the same as of OpiZ2+H5.

Will try 4.14.y when time permits as i see mainline can deal with eMMC...

 

Link to comment
Share on other sites

Little update, after revising eMMC pin config and fixing my mistakes i have now eMMC working.

Some hiccups on hdmi output , Light Display Manager  failed to start with some funny messages, possibly wrong configuration. Gbps is working but wifi still need some attention, i don't have any  working Android fex file to base my findings so it is just trial and errors here.

 

If you want me to run and test eMMC, put the command here and i try to grab the results.

 

Link to comment
Share on other sites

sudo ../iozone/iozone3_471/src/current/iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
 

    Iozone: Performance Test of File I/O
            Version $Revision: 3.471 $
        Compiled for 64 bit mode.
        Build: linux-arm 
    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                 Vangel Bojaxhi, Ben England, Vikentsi Lapa,
                 Alexey Skidanov.
    Run began: Sun Dec 24 17:58:38 2017
    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 102400 kB
    Record Size 4 kB
    Record Size 16 kB
    Record Size 512 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: ../iozone/iozone3_471/src/current/iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     6361     6615    14036    14049    12156     6488                                                                
          102400      16    19014    19470    30827    30886    28293    19009                                                                
          102400     512    28949    29231    44031    44004    43835    28428                                                                
          102400    1024    29138    29254    44116    44125    44007    28721                                                                
          102400   16384    29878    29202    44358    44373    44386    29386                                                                
iozone test complete.

 

Link to comment
Share on other sites

8 hours ago, @lex said:

iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

 

It's a good idea to not rely on those iozone numbers made with just a test size of 100MB but to also test with at least twice the amount of DRAM. If numbers differ significantly you can throw above numbers away (at least that's what I'm doing regularly when benchmarking since 'benchmarking gone wrong' is rule and not exception :) ):

iozone -e -I -a -s 3000M -r 16384k -i 0 -i 1

(if it's the same eMMC as on their other boards you'll end up with write 'performance' below 7 MB/s)

Link to comment
Share on other sites

5 hours ago, tkaiser said:

It's a good idea to not rely on those iozone numbers made with just a test size of 100MB

 

iozone -e -I -a -s 3000M -r 16384k -i 0 -i 1

 

Some Observations:

governor: interactive and if governor is with performance the board runs all the time with 1008 Mhz and i get small (very small) increase. and running all the time with 1008 Mhz the Temp is around 63 C (no heatsink or active cooler)

If Wifi and BT are in use the numbers differ a tidy bit for the worse. Used PSU 5v 2.0A.

    Iozone: Performance Test of File I/O
            Version $Revision: 3.471 $
        Compiled for 64 bit mode.
        Build: linux-arm 
    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                 Vangel Bojaxhi, Ben England, Vikentsi Lapa,
                 Alexey Skidanov.
    Run began: Mon Dec 25 07:33:15 2017
    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 3072000 kB
    Record Size 16384 kB
    Command line used: ../iozone/iozone3_471/src/current/iozone -e -I -a -s 3000M -r 16384k -i 0 -i 1
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
         3072000   16384    12962    12838    23028    23117                                                                                  
iozone test complete.

 

The question:  Benchmarking eMMC with frequency can shorten its life and/or reduce writing speed until it dies?

Link to comment
Share on other sites

15 minutes ago, @lex said:

governor: interactive and if governor is with performance the board runs all the time with 1008 Mhz and i get small (very small) increase

 

Usually we use 'ondemand' in Armbian (interactive is only useful on some sunxi legacy kernels) but apply the following tweaks: https://github.com/armbian/build/blob/751aa7194f77eabcb41b19b8d19f17f6ea23272a/packages/bsp/common/etc/init.d/armhwinfo#L82-L94

 

So the eMMC on this board is not that slow as on earlier board revisions (I had the opportunity to verify this recently since I let f3write/f3read run yesterday and the tool reported an average write speed of just 6.3MB/s on my BPi M2+). And what you observed is only some form of eMMC internal caching. As soon as the amount of data is small enough write speeds are high just to drop after some time. Easy to test for by combining two benchmark runs:

iozone -e -I -a -s 3000M -r 16384k -i 0 ; iozone -e -I -a -s 100M -r 16384k -i 0

The 2nd iozone call will report the real write speed without any caching involved. And similar effects can be observed with small/cheap SSDs too (I've 5 small 120 / 128 GB here lying around just for testing, four show write performance of +300 MB/s but slow down to as low as low as 60 MB/s after a certain amount of data has been written, only my most recent one, a Transcend TS120GMTS420, is able to retain write performance of +500 MB/s regardless how much data will be written).

 

And of course every write to flash media shorten its life but the FTL (flash translation layer) takes care of wear leveling to evenly spreads writes across flash cells so the most important thing to have in mind is 'write amplification'. And yes, on most flash media a performance degradation happens after total amount of data being written exceeding the storage capacity since now the FTL (controller) without TRIM has no clue which pages contain data and which not and starts to move around unused data as part of garbage collection and wear leveling (that's why quality SD cards can be considered the better choice than eMMC since with those SD cards you can use SD association's SD Formatter after some time and send an ERASE CMD38 to the device which restores factory performance -- see last 3 paragraphs here)

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines