Jump to content

mboehmer

Members
  • Posts

    142
  • Joined

  • Last visited

Everything posted by mboehmer

  1. mboehmer

    Rock PI 4

    Some news: https://wiki.radxa.com/Rockpi4/downloads There is a first Armbian image available.
  2. Sounds reasonable. Many people won't need it anyway. If peeking around with DT it would be great to have also entries for PWM and 1wire (just commented out, but known working). I2C should also be prepared... Frpm my experience it is hardcto get correct entries for that periphials unless you are a DT expert
  3. Damned, I compiled new images for C2 recently, but operating it headless, I never checked USB ports. Network was stable so far, I did not notice any hangups or really bad performance. I can check lines with logic analyzer, in case that helps. Just let me know how I can support debugging (I will need C2 boards soon for next deep sea operation, and it also seems to be a really cool board for Antarctica setup)... Michael
  4. Hi guys, just wanted to let you know that I have no a Nanopi Neo4 and NanoPC T4 here on my desk. So if you need help in testing, please let me know. If the Neo4 just had a little more RAM - it's a real cute board size, but hot without cooling unit Michael
  5. mboehmer

    Rock PI 4

    Sorry, no link, it was direct contact with the German distributor by phone (and some luck, talking about my specfifc requirements).
  6. mboehmer

    Rock PI 4

    RockPi4 sales start officially today. I got two preproduction run boards, one was clearly not yet optimized in soldering Accoridng to revision printing on silk screen it's the final version being sold. One issue only so far: the M.2 adaptor is from a different board, but works electrically.
  7. mboehmer

    Rock PI 4

    So, to get back to facts, build is running, may take a while. Just compared the RockPI4 with the NanoPC-T4. Seems a good choice for starting, bioth RK808D and RT8211E are the same. Audio circuit is different, the RockPI uses an ES8316 instead of ALC5651. Wifi/BT is at least similar, on the RockPI there is an AP6256, compared to the AP6356 on the T4. IR is missing. Update: NanoPC T4 image compilation succeeded, but fails booting. It starts the BL31, but hangs after two NOTICE lines. BL31 version of original image is different to the one used in NanoPC T4 image. I can post both boot logs, if anyone is interested (good ol' FT232AM works with 1.5MBaud, while Prolific fails )
  8. mboehmer

    Rock PI 4

    Zinq = Xilinx = NoGo. I started with Xilinx FPGAs, but use only Lattice ones nowadays. There are company policies which I don't support at all. Maybe a Mico32?
  9. mboehmer

    Rock PI 4

    Hi Igor, I'm a VHDL programmer mostly, with C on microcontrollers. Bash is out of my reach - too complicated... Honestly, if I can contribute by different means, I will do (and will read that page again, as suggested). Are you sure that there is really no FPGA to be programmed? So far, Michael
  10. mboehmer

    Rock PI 4

    Sir, yes Sir I have a working Armbian developer system, that's not a big deal (even for a noob like me )
  11. mboehmer

    Rock PI 4

    Hi Igor, yes... I know. I have patches prepared for Uboot 2018/Odroid C2, Tony takes already a look on. I'm not a kernel programmer, but willing to test - needing a starting point, i.e. someone to include the RockPi4 into the Armbian development tool. So, instead of pointing me to the general "contribute" page, what would be the best "first step" for me? Michael
  12. mboehmer

    Rock PI 4

    Hi all, a new RK3399 board appeared, it is called RockPi4 I have two of these beasts here already, and they works nicely - I like the small details about it (nice eMMC fixture, all heat plates on the bottom side for simple cooling, and an M.2 PICe slot for my second network card Do you see any chance to get Armbian working on that beast, and if so, what can *I* do (with my limited experience in kernel programming)? Debian is working on it already, in case you need more specific information please let me know. Any help is appreciated. So far, Michael
  13. Hi guys, finally, paper is finished, and for anyone interested it can be found here on the arXiv site Be warned, it concentrates on the physics, not the electronics Michael
  14. Just removed the lines in config, and just left my UART baudrate changes in, which didn't change anything regarding this error message. Seems that Uboot tries to load/save from uSD card. Guess I wait a day or so - I tried to understand the defines, but they seem quite complicated.
  15. Hi guys, I just recompiled my patches from old 2015 Uboot to the 2018 version, allowing setting the baud rate in Uboot (for accessing it by 9600 8N1), and saving envs in eMMC. First one works, I can switch easily baudrates now, but "saveenv" fails, spitting out a lot of error messages: => saveenv Saving Environment to EXT4... Card did not respond to voltage select! ** Bad device mmc 0 ** Failed (1) I also see that apparently the settings are being loaded from a wrong partition: U-Boot 2018.07-armbian (Oct 28 2018 - 10:43:58 +0100) odroid-c2 DRAM: 2 GiB MMC: mmc@72000: 0, mmc@74000: 1 Loading Environment from EXT4... Card did not respond to voltage select! ** Bad device mmc 0 ** Failed (-5) In: serial@4c0 Out: serial@4c0 Err: serial@4c0 Net: eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 Any ideas on that? Maybe eMMC disk layout changed? Any help is appreciated (if you need patches, I can post them here). Michael
  16. It is a research program, one of our professors from TU Muenchen cooperates with the Canadians (who operate the sub sea infrastructure). The goal of this setup was to measure water quality in North Pacific (more specific, this special site) by deploying some light emitters and light detectors on two strings. We want to learn about bioluminescence and radioactivity induced light, which both are kind of noise for the measurements intended later. Let's say it like this: it's dark there, really, you have a perfect stable temperature, and it's easier to get things there (and back again) than going for deep holes in ice. Moreover, we had to learn all necessary things about sub sea technics in a short period of time, including deployment technis (thanks to one guy supporting us, we made the job). The setup is still operational (which I call success), and with some luck we will extend it with a third string next year, including some Odroid C2 based setups and (as we go for real fibre that time instead of good ol' copper lines) some more sophisticated electronics. As soon as our paper is published, I can give more details (while I "just" did the electronics, there will be some more physics included )
  17. Issue solved, btw. A wrong capacitor was mounted on our power supply assembly (SMD, unmarked). We got a small dip on +5V rail, disconnecting the USB ethernet adaptor. It was reenumerated, but in brown out, so the USB interface showed up again, but the network part was dead. Changing the capacitor, and adding some smart power regulation for another switched load fixed the issue.
  18. Hi guys, after some rest we will soon start a new development (yet another deep sea installation). Just wanted to warn you, I will come up with some silly questions again for sure Especially about the changes made last time on kernel, like device tree, eMMC issues, and UART speed for kernel console. So far, Michael
  19. It's working perfectly. You need the correct files for dts/dtb, otherwise it will not work. As my systems are deployed already (no access, 2650m deep), I have other issues now to solve. I recommend to kindly address Neil Armstrong (no, not the one who was on Moon ) and ask for the correct files, and... to check them into to official branch In case you need help, please let me know, I can try to help, but my time is at the moment severily limited. Michael
  20. Short update... we seem to have kind of network trouble with the 1GbE ethernet port of Odroid C2. It seems to "die" after some time, more or less the same way on all five Odroids. Is there any known issue with the network kernel driver? Still investigating the circumstances, and can provide more debugging info if needed. Any help/hint is appreciated.
  21. No compass or GPS. You see a picture from the videostream taken by the ROV, which made optical inspection after deployment and attached cablings afterwards. The ROV uses GPS coordinates from the mother ship, and corrections made by sonar system. The module itself carries no GPS, as obviously, there is no signal down there - nevertheless, we use a compass chip (MC6470) to measure orientation inside gravitational field or earth and hopefully also inside magnetic field (depends on how well that works inside the Titanium housing).
  22. Hi guys, some months ago I implemented an Odroid C2 as readout controller for a scientific instrument. Lot of people were kind and helped me with some problems with Armbian, especially eMMC and PWM. Today, finally, we managed to have our instrument (two strings with several Odroid C2 and other stuff) deployed. It is sitting now at 2628m depth in the Pacific Ocean, and will go operational the next days. Here we are... I think I can announce the deepest Odroid so far (cry loud if I'm wrong :) ) In the picture you just can see the Titanium housing with two glass covers attached to the string. Again, thanks for the fish :) Michael
  23. I have that patch inside patch/kernel/odroidc2-next/ https://github.com/armbian/build/commit/e3cb45afd90befc8423ca50fb35161d978a60fe3
  24. Just as a remark: I use eight of the 128GB eMMC modules now on eight C2 setups for some days now, without any problems. I have "ARMBIAN 5.41 user-built Debian GNU/Linux 9 (stretch) 4.14.26-odroidc2" systems with the speed patch included. Before speed patch these eMMCs were a "no go" with Armbian, while smaller ones (16GB usually) worked like a charm. Michael
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines