Jump to content

Armbian customization

chradev

By chradev
in Allwinner sunxi

 Share

Recommended Posts

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I have tested all above staff (SDC/eMMC support/booting and slow Ethernet fix) on U-Boot v2016.01 and v2016.05-rc1.

Tests done are very simple and fast to detect rough defects onlu.

 

The results are:

U-Boot ver.        eMMC support      SDC/eMMC boot       slow Ethernet (Olimex patch)

2015.10             yes                       yes                            fixed (100-150 Mbits/sec do not comply with previous test!!!)

2016.01             yes                       yes                            not fixed (scp speed less than 1 MBytes/sec)

2016.03             Not tested at all. It did not boot on Lime2 (maybe on other A20 boards as well).

v2016.05-rc1     yes                       yes                            fixed (iperf speed 700-900 Mbits/sec)

 

Best regads

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I decided to continue with my Armbian (5.07 from git) customization effort using latest U-Boot v2016.05-rc1, Kernel 4.5.1.

There you are the messages taken while booting from SD card prepared with 'dd' an without any modifications afterwards.

 

U-Boot:

 

  Reveal hidden contents

 

 

Console:

 

  Reveal hidden contents

 

 

dmesg:

 

  Reveal hidden contents

 

 

In addition to A20-Olimexino-Lime2-eMMC (HW rev. E) board there are:

In addition to the standard Armbian staff following packages are installed and configured at build time:

mc pmount dnsutils dnsmasq nginx-full

Additional packages installed from none Debian sites:

  • Node.JS (v. 4.4.3) incl. a few npm packages - at build time from customization script
  • PRI Monitor v. 2.10 - at first run

PRI Monitor is also customized to work with A20/AXP209 and integrated in nginx web server based on Armbian forums.

System is configured to boot from either eMMC or SD card if present. SSD has 2 EXT4 partitions for data and system.

Network configuration is like a router with WAN on native Ethernet interface and LAN on USB-LAN and USB-WiFi adapters in bridge.

DHCP and DNS services are accessible only from LAN while and web one from both interfaces. Iptables is used to manage network access.

 

Total power consumption (in idle state) is 470mA@5.25V and 240mA@5.18V passes through PMU up to maximal 9.2W (DC-IN) and 6.7W (PMU).

The most power hungry devices are USB-LAN adapter (more than 160mA) and GBit ethernet PHY (more than 60mA) in system idle state.

CPU and PMU temperatures measered at open box was 43.5°C/26.5°C (in idle) up to 58.2°C/58.2°C (at extreem load incl. battery charge).

 

No system hangs are observed except in closed box case with system load (not always maximal).

The best performance results measured (with U-Boot 2015.10 and Kernel 4.4.6) are:

  • 980Mbps GBit LAN throughput
  • 48/90 MB/s SSD R/W speed
  • 10 hours (all HW staff) and 16 hours (without USB-LAN) life on battery in idle state

 

It will be nice if somebody while looking around catch some unusual case or problem and share it or any thought.

 

Best regards

Chris

1
chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

Trying to unify booting process with searching for bootable device in given order I take from U-Boot its environment variables:

 

  Reveal hidden contents

 

and seamed to have everything for what I am needing of.

Only priority list has to be modified after my wishes:

boot_targets=scsi0 usb0 usb1 fel mmc0 mmc2 pxe dhcp

On the other hand I found following script:

part uuid ${devtype} ${devnum}:${bootpart} uuid
setenv bootargs console=${console} root=PARTUUID=${uuid} rw rootwait

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
    if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      bootz ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

if load ${devtype} ${devnum}:${bootpart} 0x48000000 /boot/uImage; then
  if load ${devtype} ${devnum}:${bootpart} 0x43000000 /boot/script.bin; then
    setenv bootm_boot_mode sec;
    bootm 0x48000000;
  fi;
fi

Having everything to recognize and boot Linux Kernel with or without initram. Even will do it by PARTUUID

 

Of course some more parameters to kernel command line have to be added but the main functionality looks for me o.k.

 

Any thoughts?

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

After adjusting of boot script and some experiments I succeed to unify the boot from SATA, USB, SDC and eMMC (in that order)

The boot script is:

if load ${devtype} ${devnum}:${distro_bootpart} 0x00000000 /boot/.verbose; then setenv verbosity 7; else setenv verbosity 1; fi
part uuid ${devtype} ${devnum}:${distro_bootpart} uuid
setenv bootargs console=${console} root=PARTUUID=${uuid} rw rootwait loglevel=${verbosity} ${extended_bootargs}

if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /boot/zImage; then
  if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /boot/dtb/${fdtfile}; then
    if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      bootz ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

if load ${devtype} ${devnum}:${distro_bootpart} 0x48000000 /boot/uImage; then
  if load ${devtype} ${devnum}:${distro_bootpart} 0x43000000 /boot/script.bin; then
    setenv bootm_boot_mode sec;
    bootm 0x48000000;
  fi;
fi
# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

On eMMC and SD cards modify following / add variables:

from: boot_targets=fel mmc0 mmc1 scsi0 usb0 pxe dhcp
to  : boot_targets=scsi0 usb0 fel mmc0 mmc2 pxe dhcp
new : extended_bootargs ....

where 'fel' is responsible to chose whether to boot from SD/MMC or eMMC.

 

Preparation of boot device / partition(s) includes:

  • fdisk /dev/sdX
    • delete old partitions
    • make new partition(s)
    • make boot the bootable partition (very important)
    • only one partition can be bootable or firs one will be booted from
  • use rsync or other method to copy files to newly created boot partition
  • if use 'dd' to clone disk
    • use fdisk /dev/sdX to
      • make the boot bootable partition (very important)
      • change the disk identifier
    • change boot partition UUID: tune2fs /dev/sdb1 -U 'uuidgen'
  • adjust /etc/fstab to correspond with device will be installed as '/' (UUID can be used as well)
  • for disabling to boot from given USB or SATA device partition make it none bootable

U-Boot messages at booting from eMMC:

 

  Reveal hidden contents

 

 

U-Boot messages at booting from SD/MMC device:

 

  Reveal hidden contents

 

 

U-Boot messages at booting from USB Flash device:

 

  Reveal hidden contents

 

 

U-Boot messages at booting from SATA SSD device:

 

  Reveal hidden contents

 

 

Not clear for now or not working as expected:

  • How to write environment variables to the Armbian image at the build process
  • /etc/fstab record of '/' as /dev/mmcblk0p1 in case of swapping eMMC and SD/MMC device order
    could be committed or the only way is to use partition UUID
  • If partition UUID has to be used for /etc/fstab record of '/' should it be written at build time
  • resize of partition if USB (maybe SATA as well) disk is prepared with 'dd' does not happen

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

While testing boot from different devices I found that U-Boot 2016-05-rc1 cannot write to eMMC.

After modifying environment variably command 'saveenv' fail and data was not written to eMMC.

The same case for SD/MMC is finished successfully.

 

Any ideas where to search and how to fix the problem?

 

Best ragards

Chris

chradev

chradev

Posted
  • Author
Posted

Because of problem to save environment variables to eMMC at run-time or to modify them and save at build time I prepare a patch for modifying the order of boot targets as follow:

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 8f11eb9..ac8ae47 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -465,11 +465,11 @@ extern int soft_i2c_gpio_scl;
 	"fel "
 
 #define BOOT_TARGET_DEVICES(func) \
+	BOOT_TARGET_DEVICES_SCSI(func) \
+	BOOT_TARGET_DEVICES_USB(func) \
 	func(FEL, fel, na) \
 	BOOT_TARGET_DEVICES_MMC(func) \
 	BOOT_TARGET_DEVICES_MMC_EXTRA(func) \
-	BOOT_TARGET_DEVICES_SCSI(func) \
-	BOOT_TARGET_DEVICES_USB(func) \
 	func(PXE, pxe, na) \
 	func(DHCP, dhcp, na)

to fit my requirements.

 

U-Boot will try first to boot from SATA then from USB and finally will invoke FEL which will boot from eMMC or SD/MMC if inserted.

Boot order can be changed at run-time without modifying u-boot environment by changing of SATA and USB partitions boot flag.

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

The phase of boot procedure unification is finished and tested on 2x A20-Olinuxino-Lime2-eMMC (HW rev. E) boards with customized Armbian 5.07, U-Boot 2016.05-rc1 and Kernel 4.5.2:

  • prepared image successfully boot from SATA, USB, SD/MMC and eMMC at given priority
  • procedure for preparation of all boot devices is tested and work well (see attached file)
  • it was found a problem to write in eMMC (from U-Boot only) at the one of the boards (maybe HW related)

 

GBit Ethernet performance was measured (by iperf) for following Lime2 boards:

Board IP  ...83    ...190   ...75'   ...75"
    Opt.    eMMC     eMMC      4GB      4GB
 HW rev.       E        E        C        C
     Max  917,00   831,00   750,00   920.00
 Average  898,36   786,45   707,09   890.55
  StdDev   15,07    39,14    21,17    25.74
     Min  872,00   717,00   676,00   850.00

Coincidence or not but the board with slower (12%) Ethernet has a problem to write in eMMC.

The board with HW rev. C has 21% lower or the same Ethernet performance at 2 different tests.

 

It may be helpful for someone to know additional current drawn at different Ethernet modes:

 100 Mbps idle - reference
 100 Mbps  max - +70mA
1000 Mbps idle - +70mA
1000 Mbps  max - +240mA

The next step is is to make use of GPIO in U-Boot to force booting from eMMC and moving to read-only rootfs on it.

 

Best regards

Chris

Armbian-Customization.pdfFetching info...

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I try to use a button connected between GND and GPIO PB18 (ID=50) which is pulled up on Lime2-eMMC.

The idea is to force booting from eMMC when the button is pushed at boot.

 

I have also connected 2x LEDS to GPIOs PC23 (ID=87) and PC23 (ID=88).

I have modified boor.cmd as follows:

if gpio input 50; then gpio set 87; setenv devtype mmc; setenv devnum 0; setenv distro_bootpart 1; else gpio set 88; fi
part uuid ${devtype} ${devnum}:${distro_bootpart} uuid
echo Booting ${devtype} ${devnum}:${distro_bootpart} UUID=${uuid}
if load ${devtype} ${devnum}:${distro_bootpart} 0x00000000 /boot/.verbose; then setenv verbosity 7; else setenv verbosity 1; fi
setenv bootargs console=${console} root=PARTUUID=${uuid} rootfstype=ext4 rw rootwait panic=10 loglevel=${verbosity} ${extended_bootargs}

if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /boot/zImage; then
  if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /boot/dtb/${fdtfile}; then
    if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
      bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      bootz ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

if load ${devtype} ${devnum}:${distro_bootpart} 0x48000000 /boot/uImage; then
  if load ${devtype} ${devnum}:${distro_bootpart} 0x43000000 /boot/script.bin; then
    setenv bootm_boot_mode sec;
    bootm 0x48000000;
  fi;
fi
# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

and everything works fine except first if statement.

I expect when the button is not pushed (gpio input value is 1) to be run 'then' case but it is really running 'else' case:

...
Scanning scsi 0:1...
Found U-Boot script /boot/boot.scr
1314 bytes read in 39 ms (32.2 KiB/s)
## Executing script at 43100000
gpio: pin 50 (gpio 50) value is 1
gpio: pin 88 (gpio 88) value is 1
Booting scsi 0:1 UUID=aa89ba3d-01
...

and when the button is pushed (gpio input value is 0) backward but it is really running 'then' case:

...
Scanning scsi 0:1...
Found U-Boot script /boot/boot.scr
1314 bytes read in 39 ms (32.2 KiB/s)
## Executing script at 43100000
gpio: pin 50 (gpio 50) value is 0
gpio: pin 87 (gpio 87) value is 1
Booting mmc 0:1 UUID=e1604232-01
...

Can somebody explain this behavior?

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Thanks Zador,

 

This explains observed behavior. Unfortunately, fast search on Internet did not help me enough.

 

In addition to above implementation I plan to to add Linux daemon or event listener so the button pushing will invoke system reboot.

In case of short button push the system will simply reboot.

If the button is pushed long enough (until boot script is executed) U-Boot will boot from eMMC for system maintenance.

 

Next step is to make eMMC rootfs read-only.

 

Any references for the best way to be done?

 

Best ragards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

Meanwhile I have made some measurement of consumption and temperatures regarding HDMI monitor usage.

 

On the attached image:

  • In the beginning HDMI interface is active but monitor is switched off.
  • The monitor was switched on for an hour (11:45-12:45).
  • After that the monitor is switched off and at 17:30 system was restarted which deactivates HDMI interface.

 

Some figures can be found here.

 

Best regards

Chris

post-904-0-66623300-1461697969_thumb.jpg

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

There you are init.d script I wrote for creating and activating of a daemon for clean rebooting the system when user button is pushed:

 

  Reveal hidden contents

 

It also control 2 LESDs and if the firstrun script is still running avoiding to interrupt it.

If the button is pushed for a longer time (till U-Boot checks it) the system will boot from eMMC or SD/MMC if inserted.

 

There is a dirty fix (sleep 30) of the problem to recognize if firstrun is going on in the very beginning.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

I am not sure that performance is better because both NAND and eMMC are connected via 8-bit bus to CPU but the kernel supports currently only for 4-wire one for eMMC and SD/MMC.

 

I did not made any performance measures because NAND is not supported in mainline kernel for now.

tkaiser

tkaiser

Posted
Posted
  On 5/4/2016 at 12:11 PM, chradev said:

I am not sure that performance is better because both NAND and eMMC are connected via 8-bit bus to CPU but the kernel supports currently only for 4-wire one for eMMC and SD/MMC.

 

I did not made any performance measures because NAND is not supported in mainline kernel for now.

 

As far as I can tell no one did real performance measurements so far. Everyone is focused on laughable sequential transfer speeds and forgets random i/O. Also Olliver's performance numbers he posted here I'm not able to deal with. 'Sequential dd test' without knowing the used block size is pretty useless since performance when testing with bs=1 or eg. bs=1M will differ by magnitudes.

 

It would already help if you could use the iozone call as outlined here and add the results there. :) Thx

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

  On 5/4/2016 at 12:11 PM, chradev said:

I am not sure that performance is better because both NAND and eMMC are connected via 8-bit bus to CPU but the kernel supports currently only for 4-wire one for eMMC and SD/MMC.

 

I did not made any performance measures because NAND is not supported in mainline kernel for now.

 

As Olliver Schinagl wrote to me:

ChR wrote: 
In my opinion 8-bit access to eMMC is broken in Allwinned A20 or in the mmc driver.

Olliver wrote:
Nah, it's not broken. But Allwinner 'forgot' to map the mmc controller pins to the mux and thus the additional 4 bits are not on the actual pins. It is sad and wasn't necessary, I'm sure it's just a small over sight, which is costing us performance now. But we get a big improvement by using the latest 4.6-rc1+ kernel by using HS-DDR mode. In my early tests I saw 40 MB/s read and 17 MB/s write speeds. It would be nice to imagine what the additional 8 bits would have brought us, but alas.
As I said however, the Lime2 PCB brings out all 8 bits and if we ever get a pin-compatible A40, there is a chance it will have 8 bit emmc. The Lime2 does not have 1.8 3.3 switcher on the vqmmc lines however, but I am not sure if we need this at all for higher speeds.
If 8 bit would give us double the bandwith, it could be we'd get 80 MB/s/40 MB/s in theory, but I think that's already beyond the current chip anyway.
Comparing it to the current NAND chips, which top ou at 4MB/s read if memory serves me, eMMC makes the boards quite capable

On the other hand following the advice of Olliver Schinagl I managed to get working driver configured to use 8-bit bus but real access was 4-bit  (eMMC is mmc1 below):

  Reveal hidden contents

 

Some results form performance tests done by me can be found in attached file.

 

Best regards

Chris

eMMC-RW-speed.pdfFetching info...

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

Here you can find raw data from iozone test of 4BG eMMC on A2-Olinuxino-Lime2-eMMC:

  Reveal hidden contents

and the info printed from mmctest script:

  Reveal hidden contents

 

For reference here you can also find the info and the speed test results of 4GB SD card class 10:

  Reveal hidden contents

 

and 60GB SATA SSD:

  Reveal hidden contents

 

Best regards

Chris

1
chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I try to measure eMMC performance using the patch from Olliver Schinagl against development kernel 4.6.0-rc6 and succeed to setting it up in lib.config as:

KERNELBRANCH=v4.6-rc6

But the patch is oriented to add new dts file named:

/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts

My question is how and where to setup Armbian to use the new board device tree?

 

Best regards

Chris

Igor

Igor

Posted
Posted

Add patch to userpatches/kernel/sunxi-dev 

 

I assume you are using DEV branch.

 

There are more options - you can create a new u-boot config and declare DTB there or in boot.scr since we don''t need to have different u-boot. A hack to u-boot that it chooses this DTB if eMMC is detected ? :)

chradev

chradev

Posted
  • Author
Posted

Hi Igor,

 

  On 5/10/2016 at 5:56 PM, Igor said:

Add patch to userpatches/kernel/sunxi-dev 

 

I assume you are using DEV branch.

 

There are more options - you can create a new u-boot config and declare DTB there or in boot.scr since we don''t need to have different u-boot. A hack to u-boot that it chooses this DTB if eMMC is detected ? :)

 

I use dev branch and put the new patch in userpatches/kernel/sunxi-dev.

The new patch create a new device tree source file named sun7i-a20-olinuxino-lime2-emmc.dts and add it to Makefile be compiled.

 

Unfortunately, I cannot find a way to add new board lime2-emmc without modifying Armbian code base.

 

Is there such a way or I have to modify Armbian code base for adding the new board?

And if so where and what I have to add as a staff for the new board?

 

I prefer to add completely new board named lime2-emmc with all needed configuration staff instead of patching other board staff.

 

Best regards

Chris

1
chradev

chradev

Posted
  • Author
Posted

Thanks Igor,

 

  On 5/10/2016 at 6:25 PM, Igor said:

Ahaa, ok.

 

You will need to add to our code, this is not user defined yet.

 

https://github.com/igorpecovnik/lib/blob/master/config/boards/lime2.conf

Use this, copy and rename and use different u-boot config + DTB and uboot config patch. That should do.

 

I will try and will update you.

I expect to have better solution for Lime2-eMMC board for dev branch.

 

BTW kernel 4.6 is very close to release.

If it is happened in next week or so could we expect to migrate next Armbian branch to it?

 

Best regards

Chris

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 5/10/2016 at 6:48 PM, chradev said:

BTW kernel 4.6 is very close to release.

If it is happened in next week or so could we expect to migrate next Armbian branch to it?

Even if it will be released soon, it won't be declared "stable" for 1-2 weeks after the release.

 

  On 5/10/2016 at 6:25 PM, Igor said:

https://github.com/igorpecovnik/lib/blob/master/config/boards/lime2.conf

Use this, copy and rename and use different u-boot config + DTB and uboot config patch. That should do.

Since lime2-emmc still can boot from SD and eMMC is not removable, IMO it should be handled in u-boot via patch (like declaring new variable if board has eMMC) or in nand-sata-install script (by tweaking DTB path in boot script).

Igor

Igor

Posted
Posted

Thanks for your effort too.

 

  Quote

 

BTW kernel 4.6 is very close to release.

If it is happened in next week or so could we expect to migrate next Armbian branch to it?

 

I am rather conservative on those upgrades since lot's of boards share one kernel and if one board fails, we need to explain, apologize and rush to provide an update. If we wait a week or more it become much less stressful. One long time idea still need to be realized some day - daily / weekly dev builds in repository.

 

@Zador

OK, that's even better.

chradev

chradev

Posted
  • Author
Posted

Thanks Igor and Zador,

 

  On 5/10/2016 at 7:08 PM, Igor said:

Thanks for your effort too.

 

 

I am rather conservative on those upgrades since lot's of boards share one kernel and if one board fails, we need to explain, apologize and rush to provide an update. If we wait a week or more it become much less stressful. One long time idea still need to be realized some day - daily / weekly dev builds in repository.

 

@Zador

OK, that's even better.

It is good to hear that you measure delay in weeks and not in months.

It fits to my plans and I will probably migrate to new 4.6 kernel.

 

BTW I have just test eMMC performance and find that while write has the same speed the read is 80% faster probably because of driver development.

 

About the U-Boot I have patched it as explained above in this thread and find a way to boot from all SATA, USB, SD/MMC and eMMC device at given order.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I have extend performance tests with measurement of eMMC, SD/MMC and SATA SSD R/W speed with kernel 4.6-rc7.

 

Interesting phenomenon is up to 87% eMMC read speed increase with kernel 4.6-rc7 (38.9 vs. 20.8 MB/s at iozone read with 512+ kB buffer).

Olliver Schinagl has reported the similar result for eMMC read speed with kernel 4.6-rc7 explaining it with added advances driver features.

 

Unfortunately, the better write speed of 17 MB/s reported by him is not observed in my tests.

A possible reason for that could be multiply writes of big files to eMMC in my case.

 

Best regards

Chris

eMMC-RW-speed-1.pdfFetching info...

1
chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

Meanwhile I have fond a semi-solution of none working USB OTG in mainline kernel.

Thanks to a help from sunxi form I find a solution to make USB OTG to work in Host only mode.

 

Any ideas how to make it to work in OTG mode are welcome.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,
 
Following http://linux-sunxi.org/1-Wire, thanks to http://forum.armbian.com/index.php/topic/1267-armbian-511-fails-to-build-kernel/ and after a whole night fighting I finally succeed to find how to patch Lime2-eMMC device tree to support OneWire devices in Armbian 5.12 with kernel 4.5.5:
 

  Reveal hidden contents

 

and the result is:

 

  Reveal hidden contents

 

There are 2x DS18B20 devices measuring ambient (24.2°C) and PMU (34.9°C) temperatures.
 
Following http://rpi-experiences.blogspot.bg/2013/06/rpi-monitor-version-20-advance-usage.html  I have also added them to status and statistics of RPI Monitor:

 

  Reveal hidden contents

 

 

Best regards
Chris

1
chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

These days I have succeed to build my first Lime2-4GB based prototype with aluminum box (160x125x30 mm).

It was applied interesting solution for heat dissipation from all chips to the box wall.

The first test shows good results at close to working conditions (see attachment).

 

It is on its way the real prototype based on Lime2-eMMC with aluminum box (160x155x50 mm).

All system staff will be mounted into the box for outside usage (humidity and dust resistant).

 

Best regards

Chris

Lime2-rev-C-E-comp-02.pdfFetching info...

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

These days I have finished Lime2-eMMC based prototype with aluminum box (160x165x51 mm).

It was applied already tested solution for heat dissipation from all chips (CPU, PMU, DDR and Flash) to the box walls.

All connectors, buttons etc. used are humidity and dust resistant.

STM32-H405 board used is only simulator of final low level peripheral staff.

 

Series of tests ware also done at close to working conditions, high CPU and network load and higher environment temperature.

All tests done include full battery discharge / charge cycle. See attached file for the results.

 

The most important conclusions are:

  • The temperatures of CPU and PMU chips are less than 50°C for all tests done;
  • DDR and Flash chips temperatures are probably close to the CPU one;
  • The temperature difference between the cooler and external air is less than 2°C;
  • The temperature difference between the cooler and CPU/PMU is less than 7°C;
  • There is no even a single hang at all tests done.

 

Unfortunately, uncertainty about CPU and PMU temperature measurement is still present so any comments about test results are welcome.

 

Best regards

Chris

Lime2-rev-C-E-comp-06-7p.pdfFetching info...

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

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept