• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by gprovost

  1. @tekrantz @epleminator Thanks both for the measurement (epleminator measured the same values than tekrantz - sent by DM). I will follow up with each of you by Direct Message to arrange product replacement and by safety we will replace also the PSU because we are still not sure what happened, could be just a electronic discharge or something wrong with the PSU. Our apologies for the inconvenience.
  2. @tekrantz @epleminator If you can we will need you to measure following 2 points on the board while the board is powered-up. This will help us to determine if it's just a faulty PSU or if it's an issue on the board. This way we know if we just need to send you a new PSU or if we need to request you to send us back the board in order to repair or replace. You need to be careful while doing such measure to respect the polarity as shown in the picture. If you don't feel comfortable to do such measure then you can just Direct Message me and will arrange something else. Measure 1 : Measuring at capacitor C18. You should read 12V Measure 2 : Measuring at inductor L1 and capacitor C34. You should read 3.3V
  3. @tekrantz Sorry to hear that, I understand the frustration when something goes wrong with a product you just got. Let's try to figure out what's the issue first ok ? If the Board or the PSU is defective then we will proceed to a replacement. Don't worry. Any change you have voltmeter to measure voltage on the DC connector of the PSU ?
  4. @Tido Kobol is the designer and owner of the carrier board which is what defines Helios4 product, and we have released on our wiki all the files (Schematics, PCB layout, BOM, etc...) of the carrier. If tomorrow you are designing a product and decide to use a SoM from X vendor, are you going to say that your product is designed by X vendor ? No. But are you going to hide you are using X vendor SoM ? No if you want to be transparent. I'm sure you will understand it's a tiny bit frustrating the assimilation / confusion when you put some much effort in a project... but we understand why it occurs. So it's something we learnt from this first product and for our next products we won't use anyone SoM. Anyhow I don't think it's the right to carry on this conversation.
  5. @epleminator Not even LED8 is ON ? (LED located near the DC connector). Is the LED on the Power Adapter ON ? By any chance you have a voltmeter to check the output of the DC plug of the power adapter ?
  6. @Tido The power consumption for Helios4 is up-to-date on our wiki. I don't really consider that like too much energy for a NAS board. @barish Just FYI, Helios4 is not a product from Solidrun, we are just using their System-on-Module.
  7. @sirleon Good to hear. BTW it's the 30cm ribbon cable that needs to be used when putting together the Kit, the 20cm is a bit too short. I made a mistake when sourcing the OLED displays and ordered the wrong cable length along. Fortunately we realized it on time and added the 30cm one last minute. That's the reason in the kit there are 2 cables (1x 20cm and 1x 30cm)
  8. @sirleon Based effectively on your I2C scan, no device is detected on channel 1. I would still suspect wrong wiring. Can you post a picture of your I2C wiring on each side ? Have you tried another cable ? In the kit there is 2 ribbon cables, a long one (30cm) and a short one (20cm). The short one is just a spare cable. Maybe try with the short one, just to be sure it's not a cable issue first. The second OLED display you tried is it from another Helios4 kit, or just another display you already had ?
  9. @Mikezim No you won't loose your data, each RAID array self contains its own metadata that define the array definition. However it's always wiser to do a backup first of your most valuable data. After doing a fresh install you can refer to the following section of our wiki : or under OMV it's pretty obvious how to add an existing array. Just be careful, to understand what you are doing before just doing copy&paste command lines. Important: As mentioned in our different announcement, OMV for Debian Buster is not stable, still in Beta. You won't be able to run properly OMV4 on Buster. So if you still want to use OMV, you need to stick to Debain Stretch+ OMV4 for now.
  10. I guess we will all have different opinions on the matter but I feel we still forgot to see it from user perspective. I don't really agree on using debian-like denomination for out use case. We are talking kernel here with a naming system to measure hardware support maturity. It's not because a kernel only supports 60% of the feature of a board that it means it's Unstable. Same the other way it's not because a kernel version support 80% of the feature that it means it's Stable. Using Debian convention will just confuse user because the meaning in reality will be pretty different. I agree that Next is the most confusing name as for now. As for Default, I like the idea of renaming it Legacy, and loosen up a bit the definition... because in my case Helios4 has nothing to do with Vendor BSP. Again let's take a one concrete example. Helios4. latest release (v5.91) is as follow Default : U-Boot 2018.11 + LK Mainline 4.14.y (100% hardware support) Next : U-Boot Mainline 2019.04 + LK Mainline 4.19.y (100% hardware support) Dev : U-Boot Mainline 2019.04 + LK Mainline 5.x Let's put aside Dev, because personally I feel Dev meaning is pretty clear... and end of the day we don't publish dev image. Again let's look at it from user perspective, we aren't building image just for ourselves. If today I publish 2 images : Helios4 Default Buster and Helios4 Next Buster, what would drive a User to choose Default over Next ? I mean both have 100% hardware support, both are based on LK mainline and LK version that longterm ( actually LK 4.14 is much more Longterm than 4.19 if you look at the LK calendar) and both use latest Debian. You might say the choice is pretty trivial, user should pick up Next. But some users might ask themselves shouldn't I use Default since it seems to be the default choice (or in other word recommanded choice). Maybe it won't sound fancy, but I feel it's the following naming that matches the closest to what the builds really are, and it should be quite clear to user what is what and what he should pick. (Ok maybe it applies better to Helios4 use case than other). - Legacy - Current - Dev
  11. I do agree that kernel branch naming is a bit confusing... or rather how the original definition applies in today reality. In mvebu family, there is no more vendor kernel in usage, and I actually I do wonder how many board still use vendor kernel ? In mvebu family, all kernel branch (default, next and dev) are all actually mainline... and both Default and Next are Longterm. I don't know if the discussion extend to U-Boot ? Because there is also a mix of vendor and mainline. And you have case (more than few) where Kernel is mainline but U-Boot is vendor. I don't really see the point of a dedicated 'mainline' branch, usually the dev branch (what you call unstable) will be the most recent LK mainline version without any patches at first, then slowly maintainer will add patches to make this new mainline usable with this or that boards... unless the board support is already upstream. Once the dev branch is stable enough it should become the next NEXT and so on. Also let's see the reality of most vendor, after 18 months they released their product they are already moving on on their next product, so any vendor repo they have created is usually not maintained. It's why there shouldn't be any concept of vendor branch. What we aim at providing is stable images with as much hardware support as possible... that those images use a vendor kernel or vendor u-boot it's doesn't really matter... For user what actually matters is which LK version and which OS he is running end of the day... and maybe he cares a tiny bit about the U-Boot version. He doesn't really care where it comes from, vendor or not vendor. @lanefu Even though I like your naming/definitions, I think there shouldn't be more than 2 or 3 kernel tree variants. 4 variants will not only make it confusing for user but for developer to. We need to emphasis user perspective. What a user wants in 99% of the case is an image with the best comprise between hardware support / stability / up-to-date kernel. It's not normal that a user is offered with more than 3-4 different images choice (I include OS variant stretch, buster, bionic in the number of choices). Following your naming / definition suggestion, i would rather see it that way : - LTS ( previously called Default ) - Next - Dev As said I'm talking from mvebu perspective... where we have not more LK vendor version and if all goes well. So for us losing Default name and current definition make sense. Then introducing LTS naming and define a clear line between what is LTS and what is Next is what interest me. There should be rolling mechanism LTS <- Next <- Dev In perfect world, each Dev versions becomes Next when providing as much hardware support as current Next. And at some point we elect a Next version to become the new LTS, and so on. To finish :p Even though I understand the intention to decouple those branch form the OS version... I still think we should a minimum of correlation there. But maybe we keep that for later.
  12. has been updated to be ready for upcoming Debian Buster release. For Debian Buster we will use AF_ALG as Crypto API userspace interface. We choose AF_ALG for Debian Buster because it doesn't require any patching or recompiling but it comes with some limitation. While benchmark shows in some case throughput improvement with AF_ALG, the CPU load is not improved compared to cryptodev or 100% software encryption. This will require further investigation. So far I didn't succeed to enable cryptodev in Debian version of libssl1.1.1... Need further work, and it's not really our priority right now. Also for Debian Stretch I updated the prebuild libssl1.0.2 debian deb to latest security update release (libssl1.0.2_1.0.2s). Can be found here.
  13. @jimandroidpc I tested again the patch and it works. Patch it's for OMV4, didn't tested on OMV3 or 5. sudo patch < helios4-omv-luks.patch /usr/share/php/openmediavault/system/storage/luks/ patching file /usr/share/php/openmediavault/system/storage/luks/ The maintainer of openmediavault-luksencryption plugin hasn't yet did the modification, so you still need to use the patch. If you can't use the patch, just open the patch file and look at the two +/- lines, you will see it's pretty straight forward, so you can manually modify the code.
  14. Armbian Buster is ready, but we are still working at upgrading Linux Kernel and U-boot for Default and Next Armbian branch. Making the upcoming release a major Armbian release For Helios4. New OS images and Debian packages should be published in one to 2 weeks time max.
  15. @Iskren Chernev Please PM me and we see what's the best approach to replace your power supply ;-)
  16. Neat trick I just thought that whenever we can, or rather whenever the scope of an RFC is clear to everyone in the forum, we should move the conversation to github under an RFC issue. What do you guys think about the RFC naming convention ? If you agree @Igor and @lanefu then you could already rename the concerned forum topic with the prefix [ RFC 00x ], same for the note card/issue. I really think it's important and it's also a way to know that whenever a RFC has been allocated a number it means it's been accepted by the team. So when someone want to suggest a RFC, they can open a discussion in the forum with the prefix [ RFC Proposal ].
  17. @lanefu You should create issue instead of 'note card' that you then link to the project. Better to use 'note card' for things / idea we don't want to forget but don't deserve yet to have an issue created. It looks like now there is more than one RFC that fall under Build Framework Rework. Maybe it's time to list down clearly which RFC is in the pipeline of the Build Framework Rework, and I think would be cool to give each RFC a number. Here what I gather so far, but there might more RFC lost in the forum : [ RFC 001 ] Repackage BSP into dpkg (which is the RFC described originally in this thread) [ RFC 002 ] Ramlog rework (reference by @Tido above ,not sure if it's still an open issue - [ RFC 003 ] Moving board patches to sub-module ( The work for each RFC will go into dedicated branch (before getting merge into Master when complete), and branch naming convention would be quite simple (e.g rfc-001, rfc-002, etc). This way not more confusion on what is what.
  18. @lanefu Good suggestion because I think everyone is a bit lost on what the roadmap is. We did the required work for Helios4 bsp package and were expecting everyone would have done so for their respective board... but doesn't seem it happened. Can you explain the 'move kernel patch our form main script' ? Because I'm really not sure what you mean.
  19. Can we have an update status on this RFC. What's the plan / roadmap ?
  20. @helios4noob Your issue is unrelated to Helios4 hardware. It's a software setup issue, could be on your computer / laptop trying to access the share drives on Helios4. You will find better help effectively on the OMV forum for that. Have you tried to disable the firewall on you computer / laptop just to test if you can access the share drives without ? I assume you are using windows machine. As for the Helios4 froze that happened once, next occurrence check status of LED8 and LED1 and let us know. (ref to this wiki page to identify LED :
  21. Hi @Igor Is the SFTP upload available ?
  22. Yes we are working on it, we just wanted to ask the question first of the intention for Default if we move the pointer for Next branch ;-)
  23. @Igor If we move Next branch to kernel 4.19, then should we move Default branch to kernel 4.14 ? I don't really see the point of letting Default branch pointing to a supposedly 'vendor provided' kernel stuck at 4.4.
  24. I also wanted to post a little update regarding the issue reported by @uzair which ended up being a conflict between OMV standby mode and watchdog service. It is an issue unrelated to Helios4, however we committed a change to OMV official repo to finally address the issue that was actually impacting any user of any platform.
  25. @djurny Well at least you narrow down the issue as being the board. Running out of clue of what it could be. Anyhow, let's proceed to a board replacement then since we can't figure out the root cause. Please PM me.