lanefu Posted July 4, 2019 Posted July 4, 2019 note: This is from a previous thread about testing, I accidentally moved it, and this was the only way to resume the conversation --- Just kicking off a thread here to talk about different ideas around testing. It would be great if the community could help test more.,,, but what would it look like.... maybe end users can burn a test image and run a test script. the script could do cool things like: * spi loopback test * check for healthy kernel modules * look for dmesg errors * test wifi * test ethernet * test audio? * even run a phoronix test of somesort to validate a particular feature. Are there any simple circuit diagrams people could design to make testing easier... i2c testing? bitbang something into the audio input? who knows. On 3/24/2019 at 10:46 PM, lanefu said: It would be great if the community could help test more. well, in a way they do via complaint. ;-) A lot of parts need some sort of script, amlogic BSP kernels (not Armbian) are tested in such a way (perform 1000 reboots, etc). On 3/24/2019 at 10:46 PM, lanefu said: Are there any simple circuit diagrams people could design to make testing easier... That I can aid in, but the typical user probably won't have the sorts of things needed. On 3/24/2019 at 10:46 PM, lanefu said: run a test script. https://github.com/armbian/testings On 3/25/2019 at 12:24 AM, TonyMac32 said: That I can aid in, but the typical user probably won't have the sorts of things needed That'd be awesome! I'm coming from the perspective of creating more opportunities and interest for the undiscovered non-typical users. On 3/25/2019 at 7:05 AM, Tido said: https://github.com/armbian/testings was a nice starter, unfortunately nobody contributes to it and the testings there are really outdated.. I did some tests back then to automate testing (actually it was one of the use-cases I thought about for my BPi-R2 (using its serial from the pinheader to connect them to the serials of the tested boards) doing automated upgrades and check if network comes up, in case not it would try to log-in via serial.. automation has some issues.. e.g. properly filter dmesg issues is hard cause different drivers tend to float dmesg with different errors so it's hard to filter them properly.. You also need some way to powercycle the board (e.g. reboot and powercycle are different things in case of a proper reboot - BPi R2 boots up properly when you powercycle it from eMMC, whereas it doesn't with a simple reboot.. ). The idea is great, and we need more testing break due to bad testing is something we had to often... I'm willing to test new images on the boards I've got. Maybe you could make a checklist with all images that need to be tested. Once tested you check, and it's removed from the list and can be put on download page. You could also do a button at the download page to let users download the test image, and ask them to give test results. Just an idea. On 3/25/2019 at 6:41 PM, NicoD said: Maybe you could make a checklist with all images that need to be tested On 3/25/2019 at 7:05 AM, Tido said: https://github.com/armbian/testings actually the basics to test are there.. cool so since this a brain storming thread. i wanna try to stay away from thinking about process. This is more about thinking of creative ways to do testing. On 3/25/2019 at 7:05 AM, Tido said: https://github.com/armbian/testings I didn't see that page. I will use it for my next tests now! Hi, I tried to push my testing of pineh64-dev compiled from today, but have no access to armbian/testings.git Is there something I have done in the wrong way? Spoiler ~/testings ‹master›$ ./createreport.sh -f check dependencies: Hub is installed local repo settings set Already on 'master' Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) From https://github.com/armbian/testings * branch master -> FETCH_HEAD Already up-to-date. fatal: A branch named '20190402-pineh64-dev' already exists. yes=works no=don't work NT=not tested NA=not populated NETWORK: yes WIRELESS: yes HDMI: yes USB: yes DVFS: NT % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 98537 100 18 100 98519 1 9067 0:00:18 0:00:10 0:00:08 9285 =================================================== Do you want to push this changes upstream and send a PR to armbian? [YES/NO]: YES Commitmessage: pineh64-dev-5.0.5 testing report [master a1b6fc9] pineh64-dev: 5.77 pineh64-dev-5.0.5 testing report 1 file changed, 1 insertion(+), 1 deletion(-) existing remote: jeanrhum Username for 'https://github.com': jeanrhum Password for 'https://jeanrhum@github.com': Branch 20190402-pineh64-dev set up to track remote branch 20190402-pineh64-dev from jeanrhum. Everything up-to-date Aborted: 3 commits are not yet pushed to jeanrhum/master (use `-f` to force submit a pull request anyway) As you can see I tried 3 times and even with '-f' it does nothing. I tried to push manually but got this error: Spoiler ~/testings ‹master›$ git push Username for 'https://github.com': jeanrhum Password for 'https://jeanrhum@github.com': remote: Permission to armbian/testings.git denied to jeanrhum. fatal: unable to access 'https://github.com/armbian/testings/': The requested URL returned error: 403 On 3/24/2019 at 10:46 PM, lanefu said: Just kicking off a thread here to talk about different ideas around testing. It would be great if the community could help test more.,,, but what would it look like.... maybe end users can burn a test image and run a test script. the script could do cool things like: * spi loopback test * check for healthy kernel modules * look for dmesg errors * test wifi * test ethernet * test audio? * even run a phoronix test of somesort to validate a particular feature. Are there any simple circuit diagrams people could design to make testing easier... i2c testing? bitbang something into the audio input? who knows. If you are out to test the full functionality of a modern Linux distribution such as Ubuntu including multimedia capabilities, etc, it's quite difficult (I really mean it's rather impossible) to write a script to do it. There are quite simply too many possible use cases. Not even Ubuntu people do it for their x86-64 images. They rely on tens of thousands of users to report on possible bugs. Personally I test my Amlogic TV boxes running armbian / Ubuntu 18.04 by running a distributed kernel compilation on them. That tests the network functionality, roughly tests the kernel and memory for stability, roughly tests the ext4 filesystem on the SD cards, test the basic functionality of Ubuntu 18.04 on Aarch64 hardware, and... that's it. I am happy to report that for my use case, Armbian Ubuntu has shown exceptional stability on some of the cheapest hardware one can find on the planet. On 4/2/2019 at 4:17 PM, jeanrhum said: Is there something I have done in the wrong way? did you clone your fork when testing? Or did you follow this one? git clone https://github.com/armbian/testings cd testings ./createreport.sh createreport.sh was glued together relatively quickly (I know it cause I wrote it.. ) and its git remote handling is a bit hacky (e.g. upstream and origin).. If you clone from your fork things mess up quickly and then it tries to push directly into armbian/testings for which you don't have commit rights.. I didn't test it recently (just moved a few days ago and more or less all my SBCs are somewhere in boxes.. ).. Once I've a bit more time I'll hopefully clean it up a bit.. can you give me the output of: git remote -v? On 4/2/2019 at 5:43 PM, AndrewDB said: If you are out to test the full functionality of a modern Linux distribution such as Ubuntu including multimedia capabilities, etc, it's quite difficult (I really mean it's rather impossible) to write a script to do it. There are quite simply too many possible use cases. My angle more about any testing vs no testing. Ya i mostly care about like not seeing dmesg full of noise etc.... extra credit for spi and i2c and technically the gpu, and hardware encoding and decoding could be tested headless. On 4/2/2019 at 7:49 PM, lanefu said: My angle more about any testing vs no testing. Oh yes, any testing is way better than no testing. Perhaps document a systematic testing procedure and leave it to the hundreds of Armbian users to do the testing and report on results back here in the forum? I would suggest that would be the better approach to this. Right now most people only bother to report when they have a problem, not when everything works fine for their use case. On 4/2/2019 at 7:58 PM, AndrewDB said: Oh yes, any testing is way better than no testing. Perhaps document a systematic testing procedure and leave it to the hundreds of Armbian users to do the testing and report on results back here in the forum? I would suggest that would be the better approach to this. Right now most people only bother to report when they have a problem, not when everything works fine for their use case. Yes all your points are true, and there are at least some pieces floating around that could be tied together and documented. I was trying to keep this thread on the creative side and not on the process side. Ex: I have a 4 channel relay board and a bag of solder on USB A sockets and the allwinner H3 has like 4 uarts in it. If we tested images via usb booting its possible a test image could be mounted on another SBC and delivered via usb gadget mode from the OTG port. On 4/2/2019 at 8:04 PM, lanefu said: Yes all your points are true, and there are at least some pieces floating around that could be tied together and documented. I was trying to keep this thread on the creative side and not on the process side. Ex: I have a 4 channel relay board and a bag of solder on USB A sockets and the allwinner H3 has like 4 uarts in it. If we tested images via usb booting its possible a test image could be mounted on another SBC and delivered via usb gadget mode from the OTG port. That's a little bit complicated, I guess. A much, much simpler approach to testing Armbian images is to network boot them. But then you are not testing an essential functionality that most Armbian users depend upon: the ability to boot from an $4 micro SD card. Yeah nfs root is would be way simpler. Main advantage to the theoretical usb boot would being able to test uboot on the image. Can you chainload uboot from uboot? On 4/2/2019 at 8:14 PM, lanefu said: Can you chainload uboot from uboot? I don't think that's officially supported because both u-boot's would want to load at the same address, so the second one would load on top of the first one and the boot process would crash. I see there has been some discussion of this in the u-boot mailing list, but you'd have to ask if there is any recent update on this issue. Also note that some SBC vendors are shipping their boards with u-boot pre-installed on SPI ROM (afaik, Khadas and Libre Computer). On 4/2/2019 at 7:14 PM, chwe said: did you clone your fork when testing? Or did you follow this one? I follow these instructions, but when executing the script it creates a fork on my account. Here is the result of git remote -v: jeanrhum https://github.com/jeanrhum/testings.git (fetch) jeanrhum https://github.com/jeanrhum/testings.git (push) origin https://github.com/armbian/testings (fetch) origin https://github.com/armbian/testings (push)
lanefu Posted July 5, 2019 Author Posted July 5, 2019 Speaking of testing... I now have a nomad job that lets me dispatch parameterized runs of armbian builder for CI Need to work on applying patches from github PRs then I can probably integrate.
lanefu Posted July 14, 2019 Author Posted July 14, 2019 ..and the other part of the conversation that I tried to move in the first place. I haven't tested it so I don't know if that will help, but there's a tool named "LAVA", used by the Linaro folks, which is basically a CI agent devised for ARM boards and software testing. https://master.lavasoftware.org/static/docs/v2/index.html#lava-overview Besides having special images, we could have "nice people" who accept to register their agents for running integrations tests on them. On 6/11/2019 at 12:12 PM, Myy said: Besides having special images, we could have "nice people" who accept to register their agents for running integrations tests on them. Or set as a default feature on nightly images or when attached to beta repository? On 6/11/2019 at 1:08 PM, Igor said: Or set as a default feature on nightly images or when attached to beta repository? Yeah that would be good... although I think it should still be 'opt-in' . People get weird about their OS reporting without their explicit permission...just have to make it an easy choice. I guess that's a good thing to survey. Well, the two options : Running images clearly labelled as "Automated tests images that test, collect and send data back to a remote server" Allow any user to run a special script that run tests, and send the data back to the server with their consent Could do the trick. Running the test automatically on "nightly images" or "beta images" might lead some insane people to throwing a tantrum and firing GDPR requests, because data are collected from their hardware and sent to a remote server, without them be 'clearly informed' and without their 'consent'. Given how long you're running this forum, I don't have to remind you that insane people will *always* find a way to download "beta nightly images", run them without second thought, and throw a tantrum on the forum because THESE IMAGES ARE NOT STABLE AND ARE STEALING THEIR PRECIOUS DATA. On 6/11/2019 at 2:09 PM, Myy said: Running the test automatically on "nightly images" or "beta images" might lead some insane people to throwing a tantrum and firing GDPR requests, because data are collected from their hardware and sent to a remote server, without them be 'clearly informed' and without their 'consent'. ...yeah that's definitely a concern.... and thanks for reminding me about GDPR. Yeah... Though, when I see how the European Data Protection Board handles GDPR requests, (Want your data removed ? Show me your ID !) this isn't as threatening as it seems. Just make sure to have a script that can remove test data related to some user ID. having a new forum badge.. TESTER... People love to hunt for badges.. or a supporter badge in pink.. OK, I definitively need a nap.. I raise another step - improve QUALITY ASSURANCE without human interaction. I know, new features are more fun to integrate, but this is also a feature :-) What kind of code (script, C, others??) and which checks are available that can support the human I think @Igor linked that, at least I saw it here somewhere https://github.com/koalaman/shellcheck A Lint-Checker Lint is a code scanning tool to identify, suggest and correct the wrong or the risky code present in the project. There are ones for many different languages. TRAVIS CI - add your idea For the integration, do not spend to much time, just setup so it basically works and improve it over time - I am talking about tools that are free for FLOSS projects - don't get me wrong please. https://github.com/marketplace Lust but not least a nice badge on Github I thought about opening a new thread for Quality Improvement - so feel free to move it where it belongs. No intention to hijack this thread. Shall we ask in public what other ideas the crowd has of tools we don't know ? I do like the bash linting idea. Thats a pretty obtainable goal. I did kick off a Public thread about testing a few months back. There are some good ideas there. We do have an open role for "testing / code quality" are you that person? As for as traditional CI/CD testing with something like Travis CI, i think were a long way from that. The sheer size of the depency chain and the length of the build time isnt really a good fit for their free offering. The code base would need a refactoring strategy to get there. That being said... Armbian is unique, so we need to come up with some unique solutions, including figuring out what it is that we actually want to test rather than follow established models oriented around building microservices. Check out some of the testing stuff linaro has. I think we should get more involved with them as a whole. On 6/9/2019 at 10:46 AM, lanefu said: I did kick off a Public thread about testing a few months back. We do have an open role for "testing / code quality" are you that person? Travis CI, The sheer size of the depency chain and the length of the build time isnt really a good fit for their free offering. The code base would need a refactoring strategy to get there. Check out some of the testing stuff linaro has. I think we should get more involved with them as a whole. I thought if the team is small, automatic testing tool can support. Now as you mention your thread I remember, but it lead nowhere by now. I am looking for low hanging fruits, while your ideas are good, they look like a lot of work to me. To little know how over the whole project (all the scripts and folders) and Github per se. The idea from @chwe was okay, but to solve it via github wasn't smooth. As you wrote it needs a simple server to collect and reflect this data (some unique solutions). TRAVIS was just as an idea, a starter for brainstorming or so I don't know linaro, I mean I heard of it but that's it. Sorry for not having better news. On 6/10/2019 at 4:59 PM, Tido said: The idea from @chwe was okay, but to solve it via github wasn't smooth. As you wrote it needs a simple server to collect and reflect this data (some unique solutions). you mean? https://github.com/armbian/testings The idea behind having this on github it that others than the usual suspects contribute to testing (everything more customized would fail for sure, except we could use forum credentials).. It has to be easy as hell without even thinking what're you doing. If things are complicated and if you give the testers more possibilities than yes or no, I'm confident that you don't get any contribution at all. We had 15 different contributors on the repo and around september, november last year it basically worked (most of them pushed around this time - I started my thesis in november so I hadn't much time to push it further). I still think it can work.. it needs an enhancement and more publicity before releases so that people actually do it.. But it needs some force.. All those software tools are nice to look at code.. Problem is.. our work doesn't fail then.. it fails once it's on hardware.. Hardware testing must be done on hardware.. and is probably not as easy to automate (testing wise).. So the 'only' part where software helps us there is on the buildscript related part (so basically this thing must only understand bash, and besides the obvious stuff $VAR should be ${VAR} those tools can't help much - prove me wrong!).. On 6/10/2019 at 5:17 PM, chwe said: It has to be easy as hell without even thinking what're you doing. On 6/10/2019 at 5:17 PM, chwe said: Problem is.. our work doesn't fail then.. it fails once it's on hardware.. Hardware testing must be done on hardware.. and is probably not as easy to automate (testing wise).. Soooooo what if we also produced special "test" images.... and those would be built with a different customize_script.... and could just self-test on boot and phone home a report. and that's all they did....no other functionality.... all they do is burn image to sdcard, plug in ethernet, boot, and then its done. That way novice users could help contribute just by running the test image.
Igor Posted July 20, 2019 Posted July 20, 2019 On 7/5/2019 at 1:47 AM, lanefu said: You also need some way to powercycle the board What about if we make a simple hardware (perhaps already exists?) around Nanopi Duo or similar: 8 - 16 channels - power distribution with GPIO controlled relays - the same number of UART's (we need additional multiplexer) - prediction of having a programmable SD card module from which a system gets up while later, root loads from NFS server ... Each of us mount boards to this creature, control board is accessible from our (future connected) test network ... then you can code scripts: power on/off, check serial output ... 1
Tido Posted July 20, 2019 Posted July 20, 2019 1 hour ago, Igor said: programmable SD card module If I remember correctly, TK loaded the operating-system on OTG boards via MicroUSB cable. This is then not testing via SDcard, but a cheap solution on a powered USB3-Hub to test the smaller boards. What can go wrong?
Igor Posted July 20, 2019 Posted July 20, 2019 41 minutes ago, Tido said: loaded the operating-system on OTG boards via MicroUSB cable 42 minutes ago, Tido said: What can go wrong? You need to hold a special key to enter FEL mode. http://linux-sunxi.org/FEL/USBBoot & not universal method since its limited only on (some) Allwinner boards.
lanefu Posted July 20, 2019 Author Posted July 20, 2019 (edited) 2 hours ago, Igor said: What about if we make a simple hardware (perhaps already exists?) around Nanopi Duo or similar: 8 - 16 channels - power distribution with GPIO controlled relays - the same number of UART's (we need additional multiplexer) - prediction of having a programmable SD card module from which a system gets up while later, root loads from NFS server ... Each of us mount boards to this creature, control board is accessible from our (future connected) test network ... then you can code scripts: power on/off, check serial output ... Yep that's pretty much the vision i had. Inspired by 8-Channel 5V Relay Shield Module Board Optocoupler module Arduino ARM PIC AVR https://www.amazon.com/dp/B01ARS8OVQ/ref=cm_sw_r_cp_apa_i_1qVmDbG1TMZ8B The allwinners have like 4 uarts. Ive read bitbanging uarts is possible but a i2c uart expander or something is probably saner. I think making a ansible serial Connection plugin would be the ideal way to interact with OS Now that i think about it. Just logging serial then using ssh should be more than fine. If the network doesnt come up, then it fails the test Edited July 20, 2019 by lanefu Duh ssh is fine
lanefu Posted July 20, 2019 Author Posted July 20, 2019 12 minutes ago, lanefu said: I think making a ansible serial Connection plugin would be the ideal way to interact with OS This might be close https://docs.ansible.com/ansible/latest/plugins/connection/persistent.html
Igor Posted July 20, 2019 Posted July 20, 2019 1 hour ago, lanefu said: but a i2c uart expander or something is probably saner. Better. 1 hour ago, lanefu said: Inspired by 8-Channel 5V Relay Shield Module Board Optocoupler module Arduino ARM PIC AVR That would surely do. Why don't we come out with most advanced version of this device and see if that is possible to make? I would do it but am too detached from making PCBs and too busy with other things ... We have a bunch of highly competent hardware people around here and perhaps someone from community is able to make this happen? - made around anySoC, PCB in some standard/industrial size or as (double/daisy chained) "rpi" HAT - power input from ITX PSU, separate 5V/12V or even with PSU on PCB (we need to count for min 15W per channel) - relays soldered to our board, screwed power outputs and header for UARTS - jumpers to select 12V/5V for output - multiplexer, perhaps with 4 x https://www.maximintegrated.com/en/products/interface/controllers-expanders/MAX14830.html 1
lanefu Posted July 20, 2019 Author Posted July 20, 2019 1 minute ago, Igor said: We have a bunch of highly competent hardware people around here and perhaps someone from community is able to make this happen? yeah i'd love to see that.. a solder your own PCB would be great... are there any funds in the treasury for a token bounty?
Igor Posted July 20, 2019 Posted July 20, 2019 1 minute ago, lanefu said: yeah i'd love to see that.. a solder your own PCB would be great... are there any funds in the treasury for a token bounty? Surely we can add a compensation and also cover BOM for all that will use this for our purpose but since I have zero experience in PCB making costs from this decade ... you will need to whisper, help me on this. As a backup, we still can go and ask industry for this contribution - and they also might have a need (for a better version) of such device. 1
Hijax Posted July 20, 2019 Posted July 20, 2019 Speaking of the needed hardware. As I understand you need a multiplexer that will connect a real SD card to some connected SBCs under test (let's call them SUT) and the controller itself. Why real SD? As I do believe there is no point to emulate it. So the HW shall be something like hat on top of one of cheapest SBC, like Rock64 (that I will call MasterSBC), that multiplex: - SD card to USB-to-SD adapter connected to MasterSBC, for writing new image to it or one of SUT for read/write - Serial port of selected SUT to MasterSBC, - Select SUT by applying also power to it, trivial circuit with MOSFET will do the job, controlled by HC4515 chip (4 to 16 decoder) (I suggest to power SUTs via 40pin header) Of course with such mux only one SUT will be possible to control at the time. With this setup, MasterSBC will use native USB to access SD card, using 4 GPIO to select SUT and serial port for monitoring what SUT is doing. Capacity? 15 connected SUTs All easy scriptable with basic python commands. In my free time, I can design such a hat and publish schematics & gerber files here. 1
Hijax Posted July 20, 2019 Posted July 20, 2019 Quick update. Middle of the work: 4 ports to connect 4 SUT: power, serial & SD card adapter. Dedicated screw terminal to connect +5V Dedicated micro SD socket. Size - Raspberry Pi hat. Connection with Master SBC - through 26 pin header (compatible with oldest Raspberry Pi as well) Preview.... 1
Igor Posted July 20, 2019 Posted July 20, 2019 6 hours ago, Hijax said: Why real SD? As I do believe there is no point to emulate it. Wear out? Perhaps not that critical anymore. So it simply gets exchanged once it dies and that's about it? 6 hours ago, Hijax said: I suggest to power SUTs via 40pin header Simple to solve, but going away from real-world. SBC powering method is also critical. Ideally would be to have both/more options. 6 hours ago, Hijax said: Serial port of selected SUT to MasterSBC If I understand correctly you get a serial console connected to the main board of a selected & powered SBC?
Hijax Posted July 20, 2019 Posted July 20, 2019 New rendering: 2 hours ago, Igor said: So it simply gets exchanged once it dies and that's about it? Yeap. To emulate SD first of all a strong machine will be nedded, or FPGA. Cheaper solution is to replace died SD rather than invest / maintain complicated HW / SW. 2 hours ago, Igor said: Ideally would be to have both/more options. As power is exposed through 2x5 pin header, SUT can be powered using barrel plug, micro USB or USBC connector or using pins 4 & 6 of the header. Multiple options available. 2 hours ago, Igor said: If I understand correctly you get a serial console connected to the main board of a selected & powered SBC? Yes, GPIO 2,3 & 4 are 3 bit that selects which SBC is powered, and also which serial works. As SD card used SPI protocol (MISO/MOSI/CLK) all SUTs are connected to the same SBC all the time. But only the one that is powered can utilize the SD. When all GPIO=1 then no SUT is powered, and SD card is available to the master SBC through SD to USB adapter. Master SBC will be powered by 40 PIN header from this multiplexer board. External supply is connected using screw terminal and protected by 3A polymer fuse. BOM is small, all components would cost few bucks. Same with PCB production - china factories will make 10pcs for 5 USD. Also they can mount components (PCBA service) I am imaging that all 4 test boards (RPI shaped) would be stacked on top of this. All connected to some Ethernet switch. Basic test of kernel booting can be done with simple check of HDMI initialization. That is not all, a set of microSD card adapters are needed as well. Something like this: https://wiki.tizen.org/File:Cable.jpg Waiting for comments
Igor Posted July 21, 2019 Posted July 21, 2019 8 hours ago, Hijax said: Yeap. To emulate SD first of all a strong machine will be nedded, or FPGA. Cheaper solution is to replace died SD rather than invest / maintain complicated HW / SW. OK 8 hours ago, Hijax said: As power is exposed through 2x5 pin header, SUT can be powered using barrel plug, micro USB or USBC connector or using pins 4 & 6 of the header. Multiple options available. 2x5 pin header is used for SD card. So we need additional connector. Can some power hungry SUT be connected over this? XU4 for example? (20W+) 8 hours ago, Hijax said: Yes, GPIO 2,3 & 4 are 3 bit that selects which SBC is powered, and also which serial works. As SD card used SPI protocol (MISO/MOSI/CLK) all SUTs are connected to the same SBC all the time. But only the one that is powered can utilize the SD. When all GPIO=1 then no SUT is powered, and SD card is available to the master SBC through SD to USB adapter. OK. This seems o.k. More SUTs - just stacking multiplexer board? I know it gets complicated -> what if we want to run all boards at once? Boot from SD, remove SD, move to another ... 8 hours ago, Hijax said: That is not all, a set of microSD card adapters are needed as well. Something like this: The one who will producing this, shell pack pcb + cabling in one set. That its plug and play. If that will bring costs up, let it be. This tool should be saving time.
Hijax Posted July 21, 2019 Posted July 21, 2019 6 minutes ago, Igor said: 2x5 pin header is used for SD card In this solution 2x5 header is used to proxy SPI (SD), serial port ground and power. Imaging one end of the cable with 2x5 header while second end split to two or three separate plugs. One issue that needs prototyping is: now SD card is all the time powered by 3.3V. For high speeds card shall by powered by 1.8V but now there is no connection between SUT card slot power and SD card itself. I do not exactly know if card will work only in let's say 40MB/sec 8 minutes ago, Igor said: More SUTs - just stacking multiplexer board? One multilpexer + one MasteSBC = 4 SUT tested. For more SUT, dimensioning is done by adding more Masters/Multiplexers. Hence parallel testing depends on number of MasterSBCs. 10 minutes ago, Igor said: The one who will producing this, shell pack pcb + cabling in one se Yes, not only multiplexer but also micro SD adapter cables shall be provided in single design. Now I have focused on multiplexer as it is "more complicated" than SD card adapter. But when I will decide to send gerbers for PCB manufacturing, I will send not only multiplexer but also adapters.
Hijax Posted July 21, 2019 Posted July 21, 2019 37 minutes ago, Igor said: Can some power hungry SUT be connected over this? XU4 for example? (20W+) This needs to be corrected, some boards specs provides information of high current as assumption is done some USB devices are connected. Typical RPi alike board rarely goes beyond 1.5A This multiplexer design uses IRF7425 mosfet that can drive continuously up to 15A, i.e. 75W with 5V. But I assume it will be used to level up to 3A hence its will heat up to ~4 deg above ambient.
Igor Posted July 21, 2019 Posted July 21, 2019 54 minutes ago, Hijax said: Typical RPi alike board rarely goes beyond 1.5A I think we have basic functionality, except SD card speed. Let's also wait a while for others input. Now, lets see how far we can get before it gets to complicated: - bulk of the board is not RPi size, while most have at least powering at the same spot. Cabling/powering must be user friendly. - XU4 will not boot up at all < 3A Optional: running all boards at once, their serial consoles accessible via master ssh, each on separate port. If this is not able to move into this design, can be done separately - for doing long term tests. In essence this is just a serial console multiplexer to solve this problem: I have now few serial connections on my workstation and I do attach them to devices which I am dealing with ... now I want to connect all of them to one SBC "console server", with an option to power cycle the board and no SD card multiplexer. 1 hour ago, Hijax said: I do not exactly know if card will work only in let's say 40MB/sec Usually it doesn't go that fast neither So you mean we don't have an option to test high-speed modes? Perhaps this is nice to have, but adding unneeded(?) complexity ... so another voltage switching for SD card?
Tido Posted July 21, 2019 Posted July 21, 2019 @Hijax, wow, I am impressed how quick you came up with this. If the HAT sits above the SBC, it does cover on some devices the heat sink & fan and not all SBC ones have may therefore be accessible. Means the User cannot use it on all its devices - just saying. Hmm, as it is a ribbon cable 40-Pin adapter a la "old hard disk" (PATA) can the board as well lay aside attached via PATA cable? Power Connector, in almost every household you find a 5,5 x 2,1mm plug and most probably attached to a 12V, 1A power supply. Like it comes with every Router or other boxes. While easy to handle it may reach sooner its power limit. I think at first we should focus on the majority of boards and not the exception like XU4. Why, 1. you will never get a 'perfect design'. 2. After testing a first sample/batch you will find points that need change. SDcard voltage switcher can be important, in case it works with high but not with low voltage. Last but not least, is this design what we are looking for? It is my understanding, that only one SUT can be tested (serial not parallel), because of the SDcard? It is my understanding, that every SBC has a different U-Boot but the same Debian/Ubuntu on top of it. What can be tested once U-Boot is loaded versus the complete OS?
Hijax Posted July 21, 2019 Posted July 21, 2019 23 minutes ago, Igor said: now I want to connect all of them to one SBC "console server", with an option to power cycle the board and no SD card multiplexer. That simplifies the design. But: 25 minutes ago, Igor said: running all boards at once, their serial consoles accessible via master ssh, each on separate port. ...puts additional demands on power section. To provide lets say 30A from single source creates demand on external power supply and also PCB design. From the other hand if only power control & serial port is needed, then: Moxa Nport Server for serial and some Remote Power Switched PDU ?
Hijax Posted July 21, 2019 Posted July 21, 2019 3 minutes ago, Tido said: If the HAT sits above the SBC, it does cover on some devices the heat sink & fan and not all SBC ones have may therefore be accessible. One can use spacers. In my projects I typically use 25mm, like on images. Pine H64 with spacers and with installed some fancy hat board. Please remember this multiplexer is not designed to test SBC beneath it. It is designed to sit on some RPi like SBC to create master controller. 20 minutes ago, Tido said: It is my understanding, that only one SUT can be tested (serial not parallel), because of the SDcard? Yes, as this is .. multiplexer. The goal of this design was to able automate SD card change, So in real life it will be similar to setup when you have 4 SBC to test and one SD card you need to move around. 21 minutes ago, Tido said: It is my understanding, that every SBC has a different U-Boot but the same Debian/Ubuntu on top of it. What can be tested once U-Boot is loaded versus the complete OS? What is the verification strategy here? 1) One thing is to test uboot/kernel, every time new patch arrives. Kernel can be tested using USB port. Is the difference between SD/USB important here? 2) Another is to test rootfs, rarly done. And rootfs can be loaded remotely via TFTP. So only special uboot would be needed. 3) Integration test, assuming end to end approach. So full image on SD card - lets say once per week. This multiplexer addresses point 3, but it is my point of view only. Again what is the strategy? 1
lanefu Posted July 21, 2019 Author Posted July 21, 2019 3 hours ago, Hijax said: What is the verification strategy here? 1) One thing is to test uboot/kernel, every time new patch arrives. Kernel can be tested using USB port. Is the difference between SD/USB important here? 2) Another is to test rootfs, rarly done. And rootfs can be loaded remotely via TFTP. So only special uboot would be needed. 3) Integration test, assuming end to end approach. So full image on SD card - lets say once per week. This multiplexer addresses point 3, but it is my point of view only. Again what is the strategy? Fantastic question...and one thats important. From an iterrative standpoint, achieving 1 & 2 is a great start. Although i'd isolate uboot and kernel. As we currently have the capanility to test over NFS which lets us accurately test kernel and high level things on rootfs, just not uboot because thats a current config. With your multiplexer we could still test nfs boot, and given we just need the sdcard for uboot we can probably mux to next system once booted. Pretty cool! IMHO this board would be standalone rather than a hat so that its flexible with what master SBC is attached. MVP version would be a strong power source feeding a relay board with USB-A ports for power and uart ports as like JST ports.or something so we can use a JST-to-dupont for our serial console breakouts. And just static sdcards in board for nfs uboot.
Igor Posted July 21, 2019 Posted July 21, 2019 2 hours ago, lanefu said: IMHO this board would be standalone rather than a hat so that its flexible with what master SBC is attached. Master SBC can stay as Rpi size hat. IMO there is no point to make hat in any other size unless functionality is extended and stuff will not fit there anymore. It would only be nice to have more ports/master ... 6 hours ago, Hijax said: ...puts additional demands on power section. To provide lets say 30A from single source creates demand on external power supply and also PCB design. From the other hand if only power control & serial port is needed, then: Moxa Nport Server for serial and some Remote Power Switched PDU ? Standard rack PDU is big/clumsy and its complicated to plug original SBC PSU there. If we limit this to 8 channels we need up to 20Amps which we get from ATX PSU. SPI based UART multiplexer should be cheap and easy to make. Another option is to switch each one/their original PSU at DC. Input is standard 2.5 x 5.5 female jack, output screwed. 1
Hijax Posted July 21, 2019 Posted July 21, 2019 @Igor if we go towards no SD option then it would be possible to have 8 ports towards SUTs, that conveys serial port and power supply. I can change design easily: control of power outputs (0 to 8 powered simultaneously) and multiplex of 8 serial ports to be connected to MasterSBC one. One note: as the SBC itself is not system under test I strongly suggest to drop idea of powering through barrel or usb ports, but use header. First 2x5 pins are enough in that case. Simple, secure, and will limit down number of test environment failures. 1
Igor Posted July 21, 2019 Posted July 21, 2019 9 minutes ago, Hijax said: if we go towards no SD option then it would be possible to have 8 ports towards SUTs I see both designs somehow useful. Boards that are in early development phase, where bricking boot is highly possible or "just" automated test of the image before release - SD card emulation or "total control" make sense, while where fatal boot failure will rarely occur - second design with no SD option is more useful - controlling 8 devices via serial and on/off option. 21 minutes ago, Hijax said: One note: as the SBC itself is not system under test I strongly suggest to drop idea of powering through barrel or usb ports, but use header. First 2x5 pins are enough in that case. Simple, secure, and will limit down number of test environment failures. Absolutely.
Hijax Posted July 21, 2019 Posted July 21, 2019 1 hour ago, Igor said: I see both designs somehow useful. Ok. So to see the usability of second design, I have quickly reorganized the schematics (attached) and placed components. I mean routing is far from completion but 8 port (with different sockets, Molex KK 254 AE 6410 04A) is max for this board size. Mainly due to power distribution (look at the cad picture) serial-mux.pdf 2
Recommended Posts