mboehmer

Hi guys, after some interesting weeks, I could successfully install eight Odroid C2 together with dedicated FPGA hardware now, and prepare them now for deep sea operation. Just wanted to express a big "THANK YOU" to all here in the forum which were involved in helping me to get the beast working. The boards operate now with patches inside Uboot (serial console 9600 8N1) and several small patches inside the kernel (device tree, PWM, ADCs, 1Wire), and a patch inside the rt8152 driver to switch off the LEDs in the USB ethernet dongle (PMTs don't like such bright light usually). 128GB eMMCs are working fine, thanks to the speed patch The Armbian image does a great job, it's a pleasure to work with. At the moment I run it headless over some DSL connection, with a SSH tunnel and TigerVNC to remotely operate it and test under hard conditions Again, thanks to all persons involved. BTW, I'm open for ideas on how to save power on C2 during operation, as well as how to read CPU temperature remotely - we have 22W max power dissipation inside the Titanium shell... every Watt counts. BTW2, how can I take the kernel image out of updates? I want to use apt-get for normal packages, but hands off the kernel So far, Michael

Hi, after doing some last changes (hopefully) to Uboot and the kernel, I have some questions on how to get the new Uboot and kernel on eMMC (I can't reinstall everything on a cleanly etched system). I have normal build environment, with mainline kernel and v2017.11. compile.sh gives me a new image without problems. The target system is running nicely on a 128GB eMMC, but how can I safely install the new Uboot and the new kernel to my eMMC? I would really be happy to have one of the experts telling me how to proceed without killing my system Thanks in advance, any help is appreciated. Michael

It was a really hard to track issue: we operate the Odroid and the FPGA from one single 48V/5V DC/DC. The FPGA is powered off while booting, and connected to the GbE port of Odroid. External link is done by USB ethernet. When powering up the FPGA (by GPIO pin and FET), there was a voltage drop on 5V output of DC/DC due to inrush currents while FPGA memory was not yet cleared. That voltage dip made the USB ethernet disconnect and (usually) reconnect at once again, so it caused some small delay in the shell. Changing configuration to have the readout software running increased current consumption, and the USB ethernet just disconnected and stayed in an intermediate condition (not reconnecting to USB, but building up a link on ethernet).... simply adding three passive components to the FET fixed it (turning it into an inrush current limiter )

Hi, after getting access to GPIO pins now (thnx to Neil ) I wonder that accessing pins be bash scripts gives me quite different access times. For example, I use one pin to switch a connected device on and off by a MOSFET. Setting the pin low is fast, setting it high takes about two seconds. I use the following shell script: #!/bin/bash echo "0" > /sys/class/gpio/gpio102/value ("0" for off, "1" for on) Any ideas? The pin seems to switch immediately, while the shell prompt takes about two seconds to return - but ONLY in case of "1". The corresponding pin is set to output, of course, before Best regards, Michael EDIT: problem solved. It was power supply related... the +5V line received a voltage drop when the FPGA was booting up. That drop killed the USB network connection, and the reconnection did cause the long delay.

Hi, maybe someone can give me a hint... I have a running system now on 128GB eMMC card, and wanto to use GPIO. I have /sys/class/gpio/ with export, and unexport files, and two gpiochip0 and gpiochip14 entries. Unfortunately I can't export pins, as export 231 > /sys/class/gpio/export gives me a (as user and root) bash: echo: write error: Invalid argument Any help is appreciated. EDIT: works now. It is somehow a bit complicated, as the "usual" numbers as known from 3.x kernels vanished. Debug output shows two "gpiochips", with a certain number of pins, which you have to correlate to the device tree enums for that "chips" - giving you finally the number you want. Maybe I simply don't get the simplicity of that new concept... So far, Michael

Come on, no one except me wants to use PWM on Odroid C2? I tried meanwhile to figure out which settings in Device Tree to add to get the pwm-meson kernel driver recognize it, but so far I failed. ANY help is appreciated!

Hi, as the "huge eMMC" patch for Odroid C2 seems to work, I want to proceed now on PWM and SAR. I just installed a fresh system, and try to get both things working. Can someone give me a hint on which modules I need, and if some tweaking in device tree is needed? lsmod shows me that the SAR module seems to be present (meson_saradc), but I can't find the corresponding files on /sys/class/... Moreover, the meson_pwm.ko is present and can be modprobe'd, but I don't get any files unter /sys/class/pwm/ Any help is appreciated. Thanks in advance, Michael

First quick test with patch: seems to work, Armbian installation and logins worked, as well as pass word changes for root. Meanwhile I copy a huge ZIP file for checking data integrity to 64GB eMMC. Looks good so far Thanks for that patch.

Wuha. That's really good news We need a recent kernel for our DAQ system, and we need fast nonvolatile storage to buffer the run data. My best guess was to go for 128GB eMMC, and keep a SDcard for emergencies. So, talking business, which most recent kernel does allow huge eMMC storage? Which size is the limit from where on we can expect "bad behaviour"? I tested 8GB and 16GB so far, 8GB seems slow quite often, and 16GB was perfectly working. Can you advise please? Michael

Hi, I just changed from my 16GB eMMC to a 64GB eMMC (black type, ordered by Pollin, with Android initially on it). I use Etcher on Windows 7, as before, no problems occured so far. If I use the same image (Armbian_5.37_Odroidc2_Debian_stretch_next_4.14.13) as I do on my 16GB eMMC, the C2 boots up normally. I can login in as root, and get prompted for a new password. This image includes Uboot changes for setting serial port baudrate, no other changes to kernel. An here the trouble starts: no matter what password I want to use as new one, I fail. If I use a "too easy one" I get denied (as it should be). If I use a complicated one, I get Debian GNU/Linux 9 odroidc2 ttyAML0 odroidc2 login: root Password: You are required to change your password immediately (root enforced) Changing password for root. (current) UNIX password: Enter new UNIX password: Retype new UNIX password: Authentication token manipulation error Debian GNU/Linux 9 odroidc2 ttyAML0 odroidc2 login: Passwords do match. I tried by serial console, I tried by network, no matter what I do - I get this authentication token manipulation error. I tried the second 64GB eMMC, too, same problem. I also tried to use a pre-built system (Armbian_5.37.171231_Odroidc2_Debian_stretch_next_4.14.10) from download area with exactly same result. Same image works like a charm on a 16GB uSD (Samsung brand), works also well on 16GB eMMC (red PCB). Using a 32GB uSD (Samsung brand), boot process stalls at [ OK ] Started LSB: Armbian gathering hardware information. with heavily blinking blue LED. After a power cycle, I can login normally as root and set a new password. Problem seems to occur on large eMMCs only (so far, with bad statistics, next week I can try the 128GB eMMC). My best guess so far ist that resizing of the file system fails on bigger cards (just guessing), destroying something in the password area. Are there any known problems with large eMMC / uSD on Odroid C2? Any help is appreciated. Michael

I just checked. In the image produced by compile.sh, there is no data no offset 0xb4000 (all 0x00). After starting the C2 with this image, and manually "saveenv" in Uboot, I can readout the eMMC by dd, and see the envs correctly stored on offset 0xb4000. This problem seems to be build related - compile.sh does not include the env section on the image in that case? As you get a "CRC error" on the empty env section on booting, it may look like a corrupted memory area. Any ideas on why the scripts does not include the env variables into the image? EDIT: the env area must be 64kB aligned to fit the "erase page boundary". This allows to access the env from Linux by fw_printenv et.al. # <device> <offset> <length> /dev/mmcblk0 0xc0000 0x8000 Still, the image for flashing the SDcard / eMMC does lack the initial settings. EDIT2: I still get a CRC error with that file if accessing the env variables by fw_printenv. If I do a dd if=/dev/mmcblk0 of=y bs=512 skip=1536 count=64 (which is directly translated from fw_env.config file), I get the variables as they are printed in Uboot. So something seems still to be broken if accessing from fw_printenv, while it seems to work inside Uboot now.

Hi, maybe someone can give me a hint on this issue. I'm working on U-Boot v2017.11 currently, and just found out that on the Odroid C2 env settings are not changable inside the eMMC, but only at compile time for Uboot. I use an 16GB eMMC, not a sdcard. So my question is: where and to what values have the following CONFIG_* parameters be set to have env settings changeable by setenv and saveenv in Uboot again? #define CONFIG_ENV_SIZE (32 * SZ_1K) #define CONFIG_ENV_OFFSET (720 * SZ_1K) #define CONFIG_SYS_MMC_ENV_DEV 1 #define CONFIG_SYS_MMC_ENV_PART 0 That's what I tried inside the include/configs/odroid-c2.h file, but it doesn't seem to work. EDIT: the variables are not inside the image, after it has been written to eMMC by etcher. After a first reboot, and inside UBoot, I can "saveenv" the standard values and see them afterwards on the eMMC on the right position. I can also change and save them again. What fails is using fw_printenv inside Linux. With the /etc/fw_env.config file # <device> <offset> <length> /dev/mmcblk0 0xB4000 0x8000 I get an error message like "Environment does not start on (erase) block boundary". Any help / hint is appreciated. Michael

Sounds like a Pico8 (did assembler there) or similar - yes, I usually do VHDL programming, but C is fine for me, as long as we stay in simple hardware environments with no cvs or GIT involved... Maybe my question was not clear: up to now, I used the standard Xenial 16.04 build environment, and simply made a "./compile.sh" to get an eMMC image (or some errors...). With a new fork on GitHub, I can't do that, as the compile script will get the sources of the main branch. So far, I made changes in the git clone of that build environment, and git a patch file with all my changes included. I prefer to stay within that build script as long as possible, as I have no time (and no nerves) to start learning yet another cross compiler orgy (did that on the MCM4+16 from Axis years ago and still hate it...). So maybe I get things finished and will apply my patches in my fork in the end. Sorry for asking so many stupid questions Michael

Thanks for the link I will try to follow instruction, but usually I'm struggling with git or cvs stuff... in case I will ask for assistance. Somehow doing low level programming seems to be much easier than using git correctly First question is: I use the ARMBIAN build stuff (with ./compile.sh), which is always fetching current source of the GIT. If I create a fork, how can I get compile.sh (which is doing a great job, indeed, it works like a charm) to use that fork instead of the main branch? Michael

Hi, I'm working on adding baudrate changes to recent Uboot v2017.11 for the Odroid C2. Took some time to understand the way Uboot handles access to hardware... I tried to get some clean solution, and wanted to ask on how I can submit my changes to the main developpers. Would be great if you could give me a hint on that issue. I still need some time for testing the changes, so it is not urgent (we need this feature to have 9600 8N1 access to the C2, as it will be deployed on a place without easy access So far, Michael