Jump to content

pzw

Members
  • Posts

    96
  • Joined

  • Last visited

Everything posted by pzw

  1. @Thomasmas How is your answer applicable to armbian? The SD card written with Etcher is 99% sure not a (Ex)FAT formatted card...
  2. If you go through the hassle of creating a female - male adapter, then you do not need to cut the CC1/CC2 lines I think ;-) .
  3. Wait.... The tone of your message, and the lack of used words, indicate that you do not get the concept of free open source software. You haven't paid a dime for it but expect, and basically insist judging from your messages, that you get support. I think @Igor was very clear, and friendly, in pointing you in the direction how to solve the issue. If you expect more, find a commercial distribution which runs on your hardware, which has the option to buy commercial support.
  4. @NicoD; Thanks for all the info. I think I made the decision to go for the M4.
  5. Hi @NicoD; Thanks for your reply, it did help for sure. To answer some questions; - 1 GB should be enough I think, but if I can get for a small extra fee 2GB I would be happy. - Power efficiency is not a big thing, same for voltage. Whatever it needs I can supply. (Using active POE, which allows a lot of options :-) - Physical size is not important, as long as it is not the size of a PC! haha Some remarks / questions about the boards you mention...: NEO4 --> Not enough USB connectors. I would like to avoid an "external" USB hub NEO3 --> Can't find it. But the description you give points me to the Fire3? But same thing, not enough USB connectors. T3+ --> Enough USB connections! :-) You mention the lower per core performance. How can I compare it to a "H3" core? It is also one of the more expensive ones, basically the same as the M4. Which one will perform better? Reading your post I think the M4 will be the best choice so far. Maybe someone else has another option?
  6. I am looking to replace 3 OrangePi boards with a H3 CPU with one board. Every board has a RTL-SDR USB stick attached to it, and the software tends to load up the CPU a lot on at least one core, in some cases the total load is high on 2 cores. To make it all easier / simpler I would like to replace the 3 with one board with enough processing power, but nothing extreme. The goal is that it will be in an enclosure up the antenna mast, POE fed, so not easily accessible! I even looked at the Atomic Pi, but I am not so sure about processing power in that unit.. (I might be wrong though!) Browsing the options online, I saw the NanoPi M4 which looks like a good candidate to me. Another one is the Odroid-N2, but there is no armbian support for it (yet). Without a doubt I have missed good candidates, therefore my question to the community... Anyone with a good suggestion? Anything H2/H3/H5 will not do it performance wise I think. Maybe a H6 based board? Thanks in advance for your time and help! :-)
  7. pzw

    pzw

  8. Hi @NicoD ; Looks like a good start for sure. I also consider a learning project for me, since I would like to learn more about how the kernel etc works, so I can make the needed overlays where needed... But for now I need to make sure they are loading! (Pretty critical step in the process!)
  9. Hi @martinayotte ; Thanks for that hint :-) . I changed the extension and it looks like it is still not loading. Where can I find / set which dtb is being loaded at boot time? This is what I have at the moment in the /boot/dtb-4.19.25-sunxi dir: root@nanopiduo2:/boot/dtb-4.19.25-sunxi# dtc -o sun8i-h3-nanopi-duo2.dtb sun8i-h3-nanopi-duo2.dts sun8i-h3-nanopi-duo2.dtb: Warning (unit_address_vs_reg): Node /opp_table0/opp@120000000 has a unit name, but no reg property sun8i-h3-nanopi-duo2.dtb: Warning (unit_address_vs_reg): Node /opp_table0/opp@240000000 has a unit name, but no reg property sun8i-h3-nanopi-duo2.dtb: Warning (unit_address_vs_reg): Node /opp_table0/opp@480000000 has a unit name, but no reg property sun8i-h3-nanopi-duo2.dtb: Warning (unit_address_vs_reg): Node /opp_table0/opp@648000000 has a unit name, but no reg property sun8i-h3-nanopi-duo2.dtb: Warning (unit_address_vs_reg): Node /opp_table0/opp@816000000 has a unit name, but no reg property sun8i-h3-nanopi-duo2.dtb: Warning (unit_address_vs_reg): Node /opp_table0/opp@960000000 has a unit name, but no reg property sun8i-h3-nanopi-duo2.dtb: Warning (unit_address_vs_reg): Node /opp_table0/opp@1008000000 has a unit name, but no reg property sun8i-h3-nanopi-duo2.dtb: Warning (simple_bus_reg): Node /soc/eeprom@01c14000 simple-bus unit address format error, expected "1c14000" sun8i-h3-nanopi-duo2.dtb: Warning (simple_bus_reg): Node /soc/sound missing or empty reg/ranges property root@nanopiduo2:/boot/dtb-4.19.25-sunxi# ls *duo2* sun8i-h3-nanopi-duo2.dtb sun8i-h3-nanopi-duo2.dts root@nanopiduo2:/boot/dtb-4.19.25-sunxi# Do you have more pointers? :-) Thanks in advance! Paul
  10. This is what I see when I run dmesg: [ 9.119901] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 9.119929] cpu cpu0: _opp_add: OPP not supported by regulators (1056000000) [ 9.120409] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 9.120445] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 9.120645] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 9.120659] cpu cpu0: _opp_add: OPP not supported by regulators (1152000000) [ 9.120859] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 9.120874] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 9.121078] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 9.121095] cpu cpu0: _opp_add: OPP not supported by regulators (1224000000) [ 9.121256] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 9.121282] cpu cpu0: _opp_add: OPP not supported by regulators (1248000000) [ 9.121545] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 9.121566] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 9.121848] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 9.121865] cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) [ 9.122055] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 9.122088] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000) I have created a .dts / .dto without these setpoints, so it looks like it is not being loaded. It is named sun8i-h3-nanopi-duo2.dto . The contents are: (of the .dts) My question is now how to ensure that the overlay is loaded? Maybe @tkaiser or @Igor can help? If there is a page somewhere describing what to do I can (most likely) figure it all out myself... :-) I am running into a few other issues, but I think that once I understand how to work with the overlays, I will should be ok....
  11. What program did you use to write the image to the SD card? I hope Etcher or another program which actually verifies the data? IF there would be an issue with the OS/scripts provided by Armbian, for sure you would not be the only one experiencing it... Better look at what you use, like common parts, how you do things, like writing the image to the SD card, etc. I have a number of Opi0 / other Opis and now a few NanoPi Duo2 boards, which all run without any issue. For the SD cards I am only using the Samsung EVO cards, (at the moment I just buy Samsung EVO select cards from Amazon), use only the power supply from the Orange Pi, or a supply which can deliver at least 2A to the board. (Stable, tested on an oscilloscope to ensure it is stable without funny spikes etc) I have not experienced a problem in this setup so far..
  12. I played around a little bit with the build system and got a working config for a Duo2. I made an image, which worked fine. But... After the standard compile process my new / added files are gone... I guess that's because the build system updates the files. Still strange that the image building went fine! Anyway, I will make the same files again, and keep a few copies... How do I prevent this from happening again? Once I have verified that everything works fine, I will posts the files here too. (I tried opening a thread in the board bringup forum, but I can't?)
  13. Filesystem corruption it can be... Power supply / SD cards are all the same? Have you tried one node with another SD card / power supply?
  14. Not sure if this is the right forum, or it should be under board bringup.... I have a few Duo2 boards running with the FriendlyElec image, but my OrangePi boards all run Armbian... I do prefer Armbian :-) . Playing around a little I can get the Nanopi Neo Air image running, but not with the wired ethernet. (My boards reside on my own design with a ethernet jack, which works perfect with the FE/FA image) I have the Armbian build environment running in a VM, and can compile my own kernel etc. ButI need a few pointers how to get the right board config in the image/kernel.... Or... Does someone already have a build setup running for the Duo2, who is willing to share it? Thanks in advance for your time..! Paul
  15. There is a reason why Etcher is recommended by the creators of Armbian... It is for sure one of the (few) image writing utilities which actually verify after the writing... And yes, that is important, because corrupted SD cards can generate strange issues..... Good to hear it is working, but I would strongly recommend using Etcher to create the flash cards in the future, to ensure you are not dealing with a corrupted image on the card...
  16. Could it be that the image on the SD card you first used was corrupted? Did you use Etcher to create the SD card? Just curious... :-)
  17. pzw

    RockPro64

    Just one question.. why did you set the emmisivity so low? The temperature reading is heavily influenced by the setting... You can see the heat spread through.
  18. Might seem unrelated to you... But what kind of power supply are you using? You need a good power supply which can easily supply high currents (2A). A standard phone charger will not work reliably. Also the quality of the SD card is very important. Samsung EVO cards have always worked great for me. FYI My 2E has been running Armbian mainline for the last 12 weeks non-stop, with a EVO 32GB card and a 5A PSU, which is also supplying some other power hungry stuff, but has for sure enough capacity for the 2E... No problems at all stability wise!
  19. You use different clock speeds between the Arduino and the OPi. Depending on the wiring parasitic capacitance, this can make the difference.... Also... Are you running the Arduino on 5V or 3.3V? I guess 3.3V since the LDC1314 is a 3.3V device.. But just making sure :-) . What surprises me is by looking at the scope images is that it seems that the SDA line is held at 1/2Vcc . You say that doesn't change depending on the pull up resistor value. And that is strange. Because that means it is a state which is voltage controlled, and not the result of a "latched up" driver or something. Because if that would be the case, the voltage would move depending on the pull up resistor. The driving element will be having the same resistance in the latched state... Just thinking out loud now...
  20. If the "0" level is not hitting ground, it means that the current through the switching device (BJT/FET etc) is too high. A pullup of 4k7 seems to be ok, but I am not 100% sure if there is a pull up on the die of the CPU... So I would personally start with removing the pullups... Or... You have a bad ground connection. Can you take a picture of the wiring?
  21. What changes will be implemented?
  22. I tried asking FA, but didn't get a reply... I need a few for a project which has only space for that module... (got 36mm width to use....) Every week I try to check it, but so far no luck. I am wondering if it would help to just order a few so I might get them sooner..
  23. The converters which were "faked" were the FTDI based USB <--> RS232 converters... The converter you are using is based on a Sipex 3232 (or Maxim MAX3232) chip. Those are so super basic converters (you can buy them on a PCB ready to go for 15 cents each!) that they are not worthwhile faking... I bet you that the issue you are having is just a cold (bad) solder joint, like in the picture below... The sad part is that this is a picture of an advertisement of one of those 15 cent converters ads on Aliexpress.... In this case the converter would actually work, since the cap with the bad connection is the power supply bypass... So their "quality control" would not even notice it in a functional test..
  24. @TonyMac32 Thanks for verifying it :-) . It did strike me as odd if FA would have overlooked this termination requirement... Also I would have expected network throughput issues because of it, but I couldn't find reports about that... So that made it almost certain that the termination was happening on the die.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines