Jump to content


  • Posts

  • Joined

 Content Type 


Member Map




Everything posted by tkaiser

  1. Nearly all the stuff around the horrible power situation of the Lamobo R1 can be found in this otherwise pretty useless and crappy forum: http://bananapi.com/index.php/forum/general/391-why-the-sata-disk-doesnt-work-on-bpi-r1?start=12 I would have a look for undervoltage issues (very likely). @Patcher: If you power the board using the LiPo socket does a connected HDD/SSD still work? And how do you solved the mechanical challenge to insert a plug into the LiPo connector and also use a disk (bending the connector?). JFR: I used the board with an older image (3.4.106 or even older) and both a connected 2.5" HDD and a HDMI display. Since the AXP209 also has to power the disk on the Lamobo R1 you can simply read out the power requirements using sysfs. And due to the crappy Micro USB connector it's not possible to boot the board when a power hungry USB keyboard and mouse were also connected (peak consumption when trying to spin up the disk exceeded the overall power maximum). Without the USB peripherals it worked even with unpatched u-boot (rootfs on SATA). And when using the stress utility to produce some load the consumption of the board sometimes reached 9V (maximum since Micro USB allows 5V/1.8A max.) And never ever use the original acrylic enclosure especially lying flat around. Both disk and the AXP209 power management unit might overheat easily due to bad placement and no airflow possible.
  2. Sorry, no time to test (been busy in the kitchen). But if you want to give different TX/RX delay parameters a try you could play with the 64 different u-boot packages my script created: http://kaiser-edv.de/tmp/lime2-u-boot.tgz Contains 64 debs with the following name scheme: linux-u-boot-lime2_1.9_$TX_$RX_armhf.deb. To use an unmodified RX delay and eg. 4 as TX delay simply install dpkg -i linux-u-boot-lime2_1.9_4_0_armhf.deb (I completely rely on Igor's compile_uboot function and no testing has been done regarding RX delay! Be warned: you might end up with a corrupted bootloader!). JFR: Another u-boot patch was necessary: diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 2fcab60..4623de6 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -451,4 +451,10 @@ config GMAC_TX_DELAY ---help--- Set the GMAC Transmit Clock Delay Chain value. +config GMAC_RX_DELAY + int "GMAC Receive Clock Delay Chain" + default 0 + ---help--- + Set the GMAC Reveice Clock Delay Chain value. + endif Both u-boot patches combined for GMAC RX DELAY: http://pastebin.com/adiWjzya Regarding the problems you experience: Do the Lime2 showing problems have a different board revision? I can not remember having packet losses with my Lime2. Unfortunately I cannot test immediately since I have to prefer the Lamobo-R1 that is dedicated to a customer and shows really bad performance right now. Maybe on thursday I'll have a look.
  3. Well, I doubt that TX DELAY is related to the problems you experience (these delay settings should only matter when you compare different boards or board revisions). But anyway. Now I have a patchset to create 64 u-boot variants with all possible TX/RX delay variations and will give them later a try (with Lamobo-R1 first, will try the very same stuff with my Lime2 if I suceed with testing and this brute-force approach shows good results). I just added two more lines to gmac.c and hope that they will work: diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c index 8849132..1bce3ce 100644 --- a/board/sunxi/gmac.c +++ b/board/sunxi/gmac.c @@ -26,6 +26,8 @@ int sunxi_gmac_initialize(bd_t *bis) CCM_GMAC_CTRL_GPIT_RGMII); setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_DELAY(CONFIG_GMAC_TX_DELAY)); + setbits_le32(&ccm->gmac_clk_cfg, + CCM_GMAC_CTRL_RX_CLK_DELAY(CONFIG_GMAC_RX_DELAY)); #else setbits_le32(&ccm->gmac_clk_cfg, CCM_GMAC_CTRL_TX_CLK_SRC_MII | CCM_GMAC_CTRL_GPIT_MII); The diff for modifications of Igor's scripts are here: http://pastebin.com/ZMF89Y57 and you still would need to define 'GMAC_DELAY_TEST="yes"' in compile.sh
  4. BTW: Since I want to play around with both TX and RX delay parameters I started to modify Igor's build scripts for this purpose. Since the build system creates a .deb package for u-boot that overwrites the SPL/u-boot on SD card my idea was to let create all 64 variants of possible TX/RX delay values and then let a script automatically install the different u-boot variants, reboot afterwards, test network performance using ping/iperf, tries the next u-boot.deb until all combinations are tested. Currently I got the first step finished: Automatically creating 8 different u-boot .deb packages by adjusting Igor's script. 1) Add GMAC_DELAY_TEST="yes" to compile.sh 2) Modify one line in lib/common.sh. Exchange CHOOSEN_UBOOT="linux-u-boot-$VER-"$BOARD"_"$REVISION"_armhf" with CHOOSEN_UBOOT="linux-u-boot-${VER}-${BOARD}_${REVISION}_${TX}_${RX}_armhf" 3) Add the following lines in lib/main.sh after "grab_kernel_version" # check whether we should just build a bunch of u-boot versions to # brute-force all available GMAC TX/RX delay variations. if [ "X${GMAC_DELAY_TEST}" == "Xyes" ]; then for TX in 0 1 2 3 4 5 6 7 ; do for RX in 0 ; do CHOOSEN_UBOOT="linux-u-boot-${VER}-${BOARD}_${REVISION}_${TX}_${RX}_armhf" UBOOT_PCK="linux-u-boot-$VER-"$BOARD # search defconfig file for $BOARD Defconfig="$(grep -i -- "-${BOARD}.dtb" ${DEST}/u-boot/configs/*_defconfig | cut -d: -f1)" if [ ! -f "${Defconfig}" ]; then case ${BOARD} in aw-som-a20) Defconfig="${DEST}/u-boot/configs/Awsom_defconfig" ;; cubieboard2) Defconfig="${DEST}/u-boot/configs/Cubieboard2_defconfig" ;; lime) Defconfig="${DEST}/u-boot/configs/A20-OLinuXino-Lime_defconfig" ;; micro) Defconfig="${DEST}/u-boot/configs/A20-OLinuXino_MICRO_defconfig" ;; bananapipro) Defconfig="${DEST}/u-boot/configs/Bananapro_defconfig" ;; udoo*) Defconfig="${DEST}/u-boot/configs/udoo_quad_defconfig" ;; esac fi # patch defconfig with appropriate tx/rx values MyTmpFile="$(mktemp /tmp/gmac_test.XXXXXX || exit 1)" trap "cd /tmp; rm -f \"${MyTmpFile}\"; exit 0" 0 1 2 3 15 grep -v CONFIG_GMAC_TX_DELAY "${Defconfig}" | grep -v CONFIG_GMAC_RX_DELAY >"${MyTmpFile}" cat "${MyTmpFile}" >"${Defconfig}" echo -e "CONFIG_GMAC_TX_DELAY=${TX}\nCONFIG_GMAC_RX_DELAY=${RX}" >>"${Defconfig}" compile_uboot done done exit 0 fi Step 2) and 3) as patch: http://pastebin.com/RC5WptYB After execution of compile.sh you will end up with 8 different u-boot.debs in output/output/u-boot containing different GMAC TX DELAY settings that can be installed using "dpkg -i". Execution will stop afterwards. Next step is to patch gmac.c so that different definitions of "CONFIG_GMAC_RX_DELAY" might lead to different results.
  5. You can set the register values from within u-boot directly if you've a serial connection and stop autoboot: https://groups.google.com/d/msg/linux-sunxi/Y_Zh5juEJG4/egjJojeTgS8J (but I've no clue why he just tried 0x006, 0x406, 0x806 and 0xc06 and how this should 'translate' to 0, 1, 2 and 3? If we're speaking about 3 bits then 8 -- 0 to 7 -- different values should be possible?)
  • Create New...