| 09:31 | topi`> | vpeter: use a DC relay? |
| 10:14 | vpeter> | Transistor is more fancy :) |
| 10:15 | vpeter> | jnettlet[m]: Is it possible to use miniPCIe as mSATA + USB at the same time on cf pro? |
| 10:17 | jnettlet[m]> | vpeter: how do you plan to get access to the USB signals? Some kind of splitter? |
| 10:20 | vpeter> | I would solder wires on mSATA to SATA adapter. And used both. |
| 10:54 | jnettlet[m]> | should be doable. I would probably recommend using a proper msata mini pcie adapter and then soldering the usb 2.0 header cable on. usb is lower bandwidth so a bit more forgiving. |
| 10:54 | jnettlet[m]> | This would only be available on CON2, the one closest to the microsom |
| 10:56 | vpeter> | Thanks. Will see if I do this thing on current upgrade process. |
| 10:56 | Ke> | I was not able to get my transistors to work |
| 10:56 | jnettlet[m]> | oh, actually I am wrong. We have usb 2.0 on both pcie ports. It is only my early dev board that only has it on 1 |
| 10:56 | Ke> | they were in always conducting state |
| 10:56 | jnettlet[m]> | are the gpios working? |
| 10:57 | Ke> | sure, I am now conencting directly to mcbin and that works |
| 10:57 | Ke> | just commenting to previous discussion |
| 10:57 | Ke> | so I do not actually need a solution |
| 10:58 | vpeter> | jnettlet[m]: seems I would need to buy this at the start :) http://tweakers.net/ext/f/qrqVMybylebVgtrQTswQ8DDA/full.jpg |
| 10:58 | Ke> | well perhaps I need to implement harder power cycling via the atx header |
| 10:58 | jnettlet[m]> | vpeter: I would verify that actually will do both simultaneously. That may be an either or adapter |
| 11:00 | Ke> | I am now running live testing to see, if the mcbin has stability issues |
| 11:00 | Ke> | I am planning to replace the old router once linux-4.16 hits buster |
| 11:03 | jnettlet[m]> | Ke: unfortunately I think relying on mainline is a bit hopeful. There are still a fair amount of missing functionality. |
| 11:03 | jnettlet[m]> | it is generally getting there, but lots of corner case bug fixes won't be upstreamed yet. |
| 11:04 | Ke> | I am counting on you and suihkulokki =o) |
| 11:04 | Ke> | anyway, it works to the extent that I only notice some instability |
| 11:06 | jnettlet[m]> | Ke: are you running it at 2Ghz? |
| 11:06 | Ke> | yes |
| 11:07 | jnettlet[m]> | vpeter: do you plan to use the external USB 3.0 port? Your other option would be to desolder that and replace it with an internal header |
| 11:10 | vpeter> | Yes, USB 3 port is used for external disk sometimes. It is just one more crazy ideas I have for this USB 2 port :) Not really important. |
| 11:10 | Ke> | jnettlet[m]: anyway, I really believe I am not the only one who values upstreaming kernel stuff above many other things |
| 11:11 | Ke> | for some reason suihkulokki does not see the same for upstreaming boot firmware |
| 11:11 | jnettlet[m]> | Ke: well we value it, but upstreaming has way more politics than it should. |
| 11:12 | Ke> | kind of sad that there is upstream controlled by ARM, who perhaps does not have any interest in killing all the blobs |
| 11:12 | jnettlet[m]> | and unfortunately sometimes the time required to mainline something turns out to not be worth the effort. |
| 11:12 | Ke> | jnettlet[m]: agreed, you are not alone with that sentiment |
| 11:13 | Ke> | jnettlet[m]: also there is an option to privide thin patchset on top of most recent longterm kernels and reasonable recent kernel |
| 11:13 | Ke> | the patches with least effort to maintain and most value |
| 11:13 | jnettlet[m]> | Ke: in general that would be rmk's patchset |
| 11:14 | Ke> | yup |
| 11:14 | jnettlet[m]> | unfortunately he stopped pushing patches mainline because free-electrons/bootlin were being so difficult about things. |
| 11:15 | Ke> | is kind of sad, as this is vital for their perceived goals also |
| 11:20 | Ke> | to be honest, I think even using email the way linux community wants is a hindrance to many people |
| 11:20 | Ke> | smtp is heavily locked out thing and having it configured just to send patches is not too tempting |
| 11:21 | Ke> | same with debian bug reports |
| 11:21 | Ke> | for some reason using https get/post was not acceptable even though that is accessible for practically everyone without configuration |
| 11:25 | Ke> | probably spam is the reason |
| 11:37 | jnettlet[m]> | funny you brought that up. I have been rolling around an idea in my head regarding an OSS developer network based on blockchain and cryptocurrency |
| 11:38 | jnettlet[m]> | it would allow external companies to contract out for features and functionality have pay back the contributing members without it needing to be via a single outsourced company |
| 12:05 | Ke> | yeah idea is simple, but making alagorithm and the metrics is hard |
| 12:05 | Ke> | ie. how do you quantify the proof of work |
| 12:05 | Ke> | it is clear there is some work, but how much |
| 12:12 | jnettlet[m]> | well in general that would be provided by the company for a blockchain contract. |
| 12:13 | jnettlet[m]> | not unlike bounties, but just automated and traceable. |
| 12:14 | Ke> | if conpanies can create bounties from thin air, would not that create inflation? |
| 12:22 | jnettlet[m]> | you need to pay the crypto-currency into the system before you can start a contract. |
| 12:24 | jnettlet[m]> | but if you think about it you could also earn crypto-currency by providing devices that could be scheduled for feature testing. |
| 12:25 | jnettlet[m]> | and also earn by having various build boxes available for different architectures. |
| 12:26 | Ke> | so I assume you do not create any new units by fulfilling the contract, otherwise you could loop contract with your self? |
| 12:27 | jnettlet[m]> | nope. |
| 12:28 | jnettlet[m]> | I haven't hashed out the full economic workflow of an OSS developer system. Although it seems like it could be a viable experiment |
| 12:29 | Ke> | sure, designing such a system is still hard |
| 12:30 | Ke> | definitely getting something like bitcoin that runs on something useful would be wanted |
| 12:30 | Ke> | next you can solve the problems in Linux community and unscalable maintainers |
| 12:32 | jnettlet[m]> | well I think that is solving the messaging issues. But having an enormous amount of test nodes accessible via this interface would help to test and autovalidate patchsets. |
| 12:33 | jnettlet[m]> | especially if you are using something where you can deploy complex configurations to reproduce bugs. |
| 12:34 | jnettlet[m]> | it would make OSS developer productivity sky-rocket with near limitless access to hardware configurations. |
| 12:35 | Ke> | well it's not like there are no ambient bugs, there just are not always bugs with trivial reproducers |
| 12:35 | Ke> | if filing a bug would always lead to results, I would be filing quite a lot more of them |
| 12:36 | Ke> | it doesn't even, when you clearly point out, where the code possibly could not work |
| 12:37 | Ke> | you can always add a lot of swap and start reserving memory while using the system, there is almost always some part of the kernel that's not handling ENOMEM |
| 12:37 | Ke> | or NULL |
| 12:38 | Ke> | I remember there was some subsystem where devs said "we know this codebase is broken, do not create artificial tests to show it, just file actual real life bugs" |
| 12:38 | topi`> | jnettlet[m]: do we have documentation for the jumpers on the new HB2 board rev? |
| 12:38 | Ke> | (not actual quote) |
| 12:39 | topi`> | I need to see how to force a SD boot and how to set it to EMMC boot |
| 12:39 | jnettlet[m]> | It is on the wiki |
| 12:39 | Ke> | I think it was something x86 related, perhaps x86 bootup |
| 12:40 | topi`> | OK |
| 12:41 | jnettlet[m]> | https://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard |
| 14:27 | topi`> | found it thanks :) |
| 14:27 | topi`> | very thoughtful of Ilya to provide 3 jumpers with these boards |
| 15:23 | Ke> | I guess the next try is to connect the arduino input to atx "Power on" and get arduino power from "+5 V standby" |
| 15:23 | Ke> | no sw changes for the wd required |
| 15:24 | Ke> | https://www.ebay.com/itm/ATX-Extension-Cable-24-Pin-Male-to-24-Pin-Female-Internal-PC-PSU-Power/371189302281?epid=1571929943&hash=item566c9b4409:g:7pMAAOSw-jhUCGyy I'll just need to get something like this to mangle |
| 15:24 | Ke> | I would guess that mcbin does not make use of the standby pin |
| 15:25 | Ke> | perhaps should check the schematics |
| 15:25 | Ke> | then I can actually implement poweroff and poweron |