Jump to content

chwe

Members
  • Posts

    1432
  • Joined

  • Last visited

Everything posted by chwe

  1. checked this one? http://files.pine64.org/doc/rockpro64/ROCKPRo64 Engineering Change Notice 20180628RP01.pdf
  2. can you provide an the output of sudo armbianmonitor -u? I don't have a recent current nor dev image installed on my RockPi.
  3. feel free even the last one didn't bother me.. but in case you want that people take you serious something *less creative* might work better.. explore your creativity where it's worth it and that might not be forum name nicknames.. well that could be a field of your research not? How much he contributed to get armbian running on all those tv boxes no other dev even looks at. I don't think this subforum would even exist without him maintaining it more or less on his own. If you show up again with actual research done not only trying to convince others that they should do the research for you write me a pm an I'll happily reopen your thread. it's good to value your own time and how you spend it, therefore upon proven otherwise, I just decided to no longer waste my time in answering to your posts..
  4. it got slightly better.. E.g. pinebook uses the lpddr4 driver from u-boot let's see if we can/should move some other too.. most blobs are used to boot may it be SPL or whatever.. It's then up to you to decide that you trust that they only do what they should.. e.g. we had this discussion for amlogic devices where the blobs did much more than just bringing the SoC in a state where u-boot linux can fully control iirc linux had never fully control over CPU clockspeed.. No idea if this changed in between I'm not interested in amlogic at all atm. Some sort of a bootrom will always be there and mostly if not ever this isn't opensource nor upgradable/replaceable. Same counts for every wifi chip as well.. some pieces of 'firmware' will always be there.. otherwise there you go: https://www.cnx-software.com/2019/12/16/openwifi-is-an-open-source-linux-wifi-stack-running-on-fpga-hardware/ IMO arm was never about being as much as possible opensource, if you look for that maybe you find your luck with a risc-V SoC, but even there it's likely that 'full free' isn't the goal of most SoC makers build something based on it. Same counts then for displays etc. They may or may not contain some sort of firmware which is closed source and can't be replaced.
  5. well that one escalated quickly.. and due to all the notifications popping up I had to follow most of the crap happened here.. And first before I even try to sum this up. I suppose you change your nick immediately to something else. You started with a thread about a dirt cheap TV box which you already bought and then tried to convince others to buy it as well cause it's cheap and somehow in the hope armbian will run on it.. This one got deleted by @TRS-80 . Which might be an overreaction. Depending on how you read the rules he had the right to do it.. I would probably just moved it to TV boxes so that it get read by the right persons namely @balbes150 who more or less maintains 'armbian on TV boxes' on his own. Most others doing development are for good reasons not interested in TV boxes (even with schematics it's mostly a pain if things like a proper DT don't exist from the vendor.. But instead of trying to get this in a better shape you tried to find every possible sub-forum to tell everyone that you're pissed-off that he deleted your first post here and there.. since he set you back that everything must be approved it just bloated my messegeboard more with stuff I actually have no passion to deal with.. After seeing that you bloat around everywhere, it was probably the right decision to revoke your post right upon approval by a moderator.. I'm not a fan of such actions cause it's just more work for me to approve x posts more per day.. A small hint the few bucks you spend for an SBC or for TV box is nothing compared to the $ you spend for support. If balbes thinks it's not even worth to have a briefer look at a box he will have likely good reasons for that (I don't even waste my time for TV boxes anymore.. you don't know what you get, things can change cause the vendor runs out of something and replaces it with something else e.g. another wifi chip other ram other whatever he runs out... and then he has to deal with the fall out of that cause people show up here that their similar looking TV box doesn't work as expected). Who will then dive into it to fix it? Will you be around and fixing all this stuff? Or is it then up to him to explain the new users that "this batch works" and this batch doesn't cause component x changed and there's no support for it? It's mostly the second.. And why should he do that for a TV box he's not interested in at all? He answered quite polite that it's a boring TV box he's not interested in.. After that you tried to convince that this is somehow valuable for armbian for whatever reason. I don't think it is.. people here around know that the W905 variants are mostly well supported in the kernel a well supported SoC doesn't give you a well supported TV box/SBC.. As you both figured out the only network connection on this board is crap and due to limited other options (only 2 USB2 every other possibility e.g. attaching network over USB will limit a limited TV box even more making it a wasted 18$ for everyone who buys this box based on that thread in the hope that enough pressure on balbes will convince him to look at it). And that around a time you didn't even tried to get your research done if and how this thing can be re-flashed, that might be your starting point https://lmgtfy.com/?q=amlogic+s905+firmware+update+over+USB ) and then from the picture: you see on the right side VCC RX TX GND? that's likely your debug UART and 'most likely' it's 3V or 3v3 so setting up your debug UART see what comes out use google or bing or whatever searchengine you prefer. so that you get a clue what is there if people already did something with the bootloader there or a similar one (if it's u-boot and you can interrupt it printenv gives you some nice hints) post your finding and your guesses and maybe someone will give you a hint here and there how you should progress. That would show @balbes150 that you're actually interested in doing something not just soak up his time, maybe not cause I think he has enough valid points to declare this box as a waste of time.. And the TV box subforum is still a forum about armbian on TV boxes not elec"something" on TV boxes.. If you want that ask the guys there to support your new paperweight maybe they're willing maybe they're not - that's then their decision. But except the confirmation that there's a crap wifi IMO your thread provided nothing of value to armbian. Well at least those involved in the whole TV boxes stuff now can honestly say that you shouldn't buy this one if someone asks for advice which TV box he should buy (and if you want something which works without much pain it's a good idea to do your research first and then buy). Why should it get deleted? Maybe cause it's not about censorship here? If this would be about censorship we would have deleted your account all your posts and it would look like you were never here. That's censorship.. Locking a discussion where everything is said and all needed persons made clear that support for it wont happen isn't. It's just keeping the forum somehow readable. Tagging randomly people to waste their time as well is just bad taste. If Igor thinks that someone acted not the way it is acceptable he would already made this clear. Moderator rights already got revoked if someone didn't had a common sense how he should act like.. Was everything perfect ofc not - or at least I would maybe solved things different, but mistakes happen and from what I saw no major mistake happened.. You got your thread back after things clarified even the restrictions got revoked. The only stuff which is 'censored' from you is where you entered a thread which was used by proved spammers to get the first mod approval just to bloat the forum after its with spam IMO that whole thread can go to trash cause it doesn't add any value to armbian but let others decide that. And your answers there honestly were just a try to make people angry so that you get a reaction nothing of value for ambian as well.. just another thread which wastes peoples time. So if you really wanna do some research (this here got the research tag removed by myself cause it's ranting not research) you could spend some time to get something out of your paperweight and see how far you get. likely this time is better spent as starting another discussion about random claims and insults to people here. Even when I think balbes is right and this box is a waste of time, it might be a good one to learn things on your own instead of pushing other people to do the work for you. And even when not.. at least you only wasted your time and not everyone else' time.
  6. without a bootlog nobody can tell you what's going on.. and even then.. If you're concerned about bricking the device by messing up bootloader... I don't think that can happen.. It might be just more pain to get it back.. but IMO rk3399 is more or less fail save to work with..
  7. it is in the boottext or boot.cmd file somewhere... I can't boot manjaro images at the moment.. their bootscript expects a connected eMMC module which I removed on purpose (to ensure seeing always our bootloader does the lifting during boot and to see if this one works) our bootscript will bring UART2 back then over bootargs.. without it you won't have any output on UART... but yeah those bits gave me the idea that something with sound is fishy that's why I disabled es83xx in the first term.. welcome to the u-boot/kernel nightmare... I post this image from time to time.. when the nightmare hits me again.. btw if you want do dive into this just apply my patch from the PR into your buildscript and start messing around.. Most of the stuff tobias applied to his 5.4 kernel should be in as well.. and if I missed something, great let us know..
  8. the newer kernel will just be worse for that at the moment.. cw2015 (the charger driver) didn't land upstream yet and the first iterations from Tobias at manjaro currently throw some errors in dmesg. Pinebook is wip and IMO early wip so don't expect the nice features to be done soon. Btw camera is another one I simply refuse to work on until basic stuff is sorted out.. So if you want it, you've to figure it out on your own. I know.. and I don't really get why ours refuse to work... nope at the moment no display output in mainline with armbian. You're happily invited to solve this: https://github.com/armbian/build/pull/1759 adding the eDP to the kernel bootargs btw didn' help for me. But I'm quite sure we had something like video=eDP-1:1920x1080@60 to the bootargs, either over DT or with armbianEnv.txt or bootscript.. ( adding @martinayotte and @TonyMac32 ). And for u-boot, if we don't use the the 2017 bsp u-boot I don't think we see display output soon for the pinebook, as far as I'm aware the edp driver didn't make into upstream u-boot yet and at least I don't try to forward port this mess from u-boot 2017 into upstream.
  9. the problem with switching the forum software is, links to threads to this forum are spread around the world.. it's not a 'closed' environment where our changes don't have an impact on others.. some examples: https://lkml.org/lkml/2019/11/8/339 https://lkml.org/lkml/2016/5/3/396 https://www.heise.de/forum/Make/News-Kommentare/Low-Tech-Website-geht-offline-wenn-die-Wolken-aufziehen/SD-Karte-mehr-Geschwindigkeit-im-Vergleich-zu-Festplatten-WTF/thread-5763610/page-2/#posting_33242056 https://www.cnx-software.com/2019/07/31/buy-orange-pi-zero-lts-sbc/#comment-565095 and I could probably post 200-300 links more with it. Breaking all those links won't be a smart idea IMO I know people love to be as opensource as possible but the reality on ARM is a different one, a bunch of boards wouldn't even boot without closed source bootloaders: until recently all LPDDR4 boards with RK3399, every Raspberry Pi ever, most if not all Amlogic boards. You either accept this as being part of arm or you trust in the openness of intels managment engine.. IMO the whole situation is even worse on x86-64 but people don't even bother to complain about this.. Change to 'more opensource' by killing open information which helps other opensource projects wont help anyone.. And as soon as you enter things like wifi/gps.. oh dear.. say goodbye to your nice free software bubble or the reality will likely hit you hard.. and you can mostly replace opensource with free software in my posts. As much as I love the work of RMS for providing a bunch of great GNU tools, the dogmatic discussion about open source and free software is something I happily ignore most of the time.. back to topic, if some features of discourse might help us to get things done great do it.. if it breaks all the links shared around the world about our forum bad...
  10. will likely end in me ignoring this queue even more means more work for the newcomer mods here. people will then just ask somewhere else.. and someone remembers this post? veni vidi vici... and I remember I unlocked this post back then. at least devs not really tied (yet) to armbian may only post a few stuff here to let us know hot to fix things. We should not make it harder for them to contribute. IMO I prefer to deal with more annoying questions than with missing good contributions which I've to search then in someones gist or on someone else's github repo.. cause we scared him away.. you think this survives the usual add blocker most people have installed? test it and if it works why not.. those who want will find each other no matter how much a thread is messed.. e.g. the rockchip guys here have a >2500 posts long PM thread talking to each other (and yes Igor you're out there on purpose, I didn't wanna float you back then with all the OT stuff and it all started with a discussion about beer back then.. ). If I think it's 'important' that someone is aware of my post I just highlight them in the thread. If I'm just frustrated about rockchip again I rant in PMs so that only those which shouldn't get disturbed get disturbed.. Another example those guys here: found each other and share the pain to get an RTD SoC working. They had barley support from our side (me being the only one having the W2 board and honestly I didn't spend much time with it - just to much pain to deal with atm) I think we should avoid 'overmoderating' the forum. It is a 'technical' forum and it's driven by development around armbian but there will always be people which just come with 'please support my random petproject' and I think we have to deal with those. Somehow.. The forum is a melting pot of people around arm some are more experienced some less (I started with some dirt cheap orange pi boards - zero and 2g-IoT - with no clue about booting on arm at all and now mostly focused on u-boot/kernel related stuff)... You don't wanna push those guys who can evolve out by being a dick in the first term... I'd rather just ignore those only requesting features without meaningful contribution, they might see that nobody cares about their petproject and move on or evolve to getting things done on their own. We're not super welcoming like it is the new 'trend' around the internet and that's IMO fine (good contributors like @piter75 find their way into the community without getting a 'warm welcome' with his first post ). For the development/boardbring up.. We once had a dedicated sub-forum for that: https://forum.armbian.com/forum/22-board-bring-up/ somehow one of the few examples where this was used was for mt7623/BPi R2 or RTD 1295 (both didn't really made it) but at least the threads were mostly focused on development not on bloating.. Maybe something like this can work? And maybe such a thread can then be moderated a bit more to keep it focused on development and not random features request/petproject support who knows..
  11. from docs.. it looks they use DT overlays... I don't think @piter75 implemented thin into 4.4 (it would be the first 64bit rockchip 4.4 kernel with dt overlay support - I did it for rk3288 back then to get both cameras supported). Decompile the DT deactivate the nodes they do with the overlay.. activate the spi node and fill it with the data from the waveshare node and recompile it.
  12. https://github.com/armbian/build/blob/9be143c2e4788deae6faf26d8ecfd921cfd52deb/patch/u-boot/u-boot-rk3399/add-board-nanopi-m4v2.patch#L29 https://lists.denx.de/pipermail/u-boot/2017-April/285942.html should explain most of it.. this whole mess should be cleaned once we've moved all boards to upstream u-boot for rk3399 boards...
  13. at least for x86-64 mesa 19.3 works like a charm on bionic... OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.2 - kisak-mesa PPA but I don't think he provides armhf/arm64 packages for it.. and yes, it doesn't work with friendly arms kernel fork, and I honestly don't understand why it works with ayufans kernel.. e.g. the supposed bits needed to get it working are missing in panel-simple (e.g. no timings nor clockspeed for the display we use) https://github.com/ayufan-rock64/linux-kernel/blob/d3f1be0ed310d118ccf04cf9b691c92a914a97a9/drivers/gpu/drm/panel/panel-simple.c#L1295-L1321 vs. mrfixit (that's a different panel) https://github.com/mrfixit2001/rockchip-kernel/blob/1440cd8cfcd029eb4f97c97c11f607e49d1986a3/drivers/gpu/drm/panel/panel-simple.c#L1330-L1353 I guess I need to understand how ayufan got the display working.. or why it works on his kernel even when he didn't touch panel-simple..
  14. well having it in rk3399 means we swap to friendly elecs 4.4 kernelfork.. First attempt display backlight fired up but no display output (well I know the reason I just forgot to patch panel-simple).. and a few bits here and there might be needed as well (at least I found out about one).
  15. IMO there's no reason to rush here.. before we haven't cleaned some of the mess in bootloaders I don't see much of a reason to change things. Yes the boards run surprisingly stable, but there are still odds here and there. I think most of the overlay features are not fully tested (compile log at least indicates that some of them might need some inspection as well) and we still have various kernel sources for the bsp kernel which needs to be cleaned first, and as just noticed, the odds regarding rebooting starting again with the pinebook.. There isn't much of a difference between the bugtracker forums and the dev forum at all. And 4.4 kernel gets old (no matter it is supported well or not), so might hit the fallout of this with the next versions of debian/ubuntu. So the same thing happened with 3.4 on sunxi shouldn't bite us again (kernel to old for recent ubuntu/debian but a bunch of interesting features are only available there). they could be marked, "potential harmful to your family" and people would still use it productive... our "supported" definition is so generic (https://docs.armbian.com/#what-is-supported) that it means in fact nothing.. (I'll burn in hell for that statement I know).. At least when people run into problems they should be aware that things are working progress right now. Most basic seem to work without major issues, but for everything a bit more fancy (camera, display etc) there's not much tested and proved to work right now. Multimedia works only on half of the boards (those belong to rk3399).
  16. well I'll fire up the pinebook now with the rk3399 4.4 kernel (e.g. integrate it into friendly arms fork) and see if this works. If that works we would at least have 4.4 and likely @JMCC multimedia stuff working. I don't get why the driver doesn't even try to probe the display.. so something must be fishy here.. Someone would then need to test if this works with stock image on eMMC cause I removed eMMC and I don't want to open and close the pinebook for a 100 times during development (I don't see a reason for not, but I didn't expect the display fooling me that hard either). But hey we have a new rk3399 SBC with it's own UPS working..
  17. https://github.com/armbian/build/pull/1759 go out and mess with it.. it could still be u-boot related.. I'm not sure how pwm works in mainline.. Could be that there's a difference between mainline and BSP kernel. Well I guess I've to dive into Tobias mainline kernel deeper to figure out what goes wrong here.. A diff off his defconfig compared to a defconfig based on our .config didnd't show any obvious oddity.
  18. well you've no chance I already set up the pinebook in rk3399 with u-boot 2020: U-Boot 2020.01-armbian (Jan 21 2020 - 23:08:47 +0100) Model: Pine64 Pinebook Pro DRAM: 3.9 GiB PMIC: RK808 MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0 In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Pine64 Pinebook Pro ## Error: Can't overwrite "serial#" ## Error inserting "serial#" variable, errno=1 rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 6 ms (478.5 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 143 bytes read in 6 ms (22.5 KiB/s) 7118384 bytes read in 752 ms (9 MiB/s) 20722176 bytes read in 2178 ms (9.1 MiB/s) 72693 bytes read in 17 ms (4.1 MiB/s) 2698 bytes read in 9 ms (292 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7118320 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f5853000, end f5f1cdf0 ... OK Loading Device Tree to 00000000f57d8000, end 00000000f5852fff ... OK Starting kernel ... [ 2.647157] Internal error: Oops: 96000004 [#1] PREEMPT SMP it seems it doesn't like my new DT.. but u-boot works fine and blobfree..
  19. right that one is on my todo list as well.. I got fooled by their documentation which mentioned a way to reset clock of eMMC to enter maskroom but then I couldn't erase it.. @piter75 wrote how he did it with the buttons so that I'm soon ready to test it. I've the patches for integrating it into rockchip64 family (u-boot and 4v4 kenel) laying around since days.. (if we will base it on nanopi m4v2 we would have to change them a bit cause different bsp kernel and u-boot) but not tested cause the stock firmware didn't try do boot SD card for me. Will be tested once pinebooks display doesn't fool me anymore.. btw @TonyMac32 I might switch to upstram 2020 u-boot with the pinebook if you don't mind. orangepi4_uboot.patch orangepi4_kernel.patch
  20. kernel boots, the charger driver and display settings were added (obviously display doesn't work yet), dmesg looks quite smooth (don't have it anymore - my notebook is on low diskspace the whole time so I've to throw out non fully working images). The DT taken for this was from manjaro. Sound was disabled cause it polutes debug UART for whatever reason. So this guy should boot: kernel-rockchip64-current (copy).patch but it's not a proper device tree, especially this node here: + vcc3v3_s0: vcc3v3-s0-regulator { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + regulator-name = "vcc3v3_s0"; + regulator-always-on; + }; needs some love.. we've the same node with a different name too (this one is present in the manjaro DT the other one was added by myself and taken out of PMIC cause it has nothing to do with REG2 in PMIC, that's not how things are wired according to schematics): + vcc_lcd_en: vcc-lcd-en-regulator { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 RK_PC6 GPIO_ACTIVE_HIGH>; +// pinctrl-names = "default"; +// pinctrl-0 = <&vcc_lcd_en_drv>; + regulator-name = "vcc_lcd_en"; + regulator-enable-ramp-delay = <100000>; + vin-supply = <&vcc3v3_sys>; + regulator-always-on; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; so in PMIC this node was killed: + unused: SWITCH_REG2 { + regulator-name = "SWITCH_REG2"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-off-in-suspend; + }; maybe just diff the two DT files (ours and the one from manjaro: https://gitlab.manjaro.org/tsys/linux-pinebook-pro/blob/master/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts) to get a clue. And sound was disabled yet: + es8316-sound { + status = "disabled"; + compatible = "simple-audio-card"; + simple-audio-card,name = "rockchip,es8316-codec"; + simple-audio-card,format = "i2s"; + simple-audio-card,mclk-fs = <256>; + + simple-audio-card,widgets = + "Microphone", "Mic Jack", + "Headphone", "Headphones", + "Speaker", "Speaker"; + simple-audio-card,routing = + "MIC1", "Mic Jack", + "Headphones", "HPOL", + "Headphones", "HPOR", + "Speaker Amplifier INL", "HPOL", + "Speaker Amplifier INR", "HPOR", + "Speaker", "Speaker Amplifier OUTL", + "Speaker", "Speaker Amplifier OUTR"; + + simple-audio-card,hp-det-gpio = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>; + simple-audio-card,aux-devs = <&speaker_amp>; + + simple-audio-card,cpu { + sound-dai = <&i2s1>; + }; + + simple-audio-card,codec { + sound-dai = <&es8316>; + }; + }; I simply don't care about sound yet, but working debug UART is a must atm.
  21. well I still hope I can sort this mess out till then.. there are a bunch of device trees flying around with a wrong regulater claimed to be on PMIC but in fact triggered by a gpio. The reason this works is likely that u-boot did the lifting before and the kernel couldn't mess it cause it's simply doesn't do something else..
  22. let's see if we get the pinebook pro with mainline and the orange pi 4 in a working state til then.. Still struggle with display (some of the available DTs for mainline are wrong regarding to regulators so my display gets likely not powered, sound polutes debug UART and so on).. Maybe we send the display then as a bugfix. I mean a non working display for a notebook is a bug, a working one isn't a feature right?..
  23. I wouldn't think 3 lines is a bloated footer (I've 3 lines I didn't update in a while - maybe I should).. A few thoughts about moderating (and I probably do mostly a bad job here cause I didn't do much moderating in a while - well I got that job somehow by mistake ).. I'm a fan of "as less as possible as much as needed". If someone chooses a obviously wrong title maybe change it.. If the title is not best, he'll learn from lack of attention that he might do better next time. I don't deal much with unfamiliar hardware anymore.. E.g. there are some parts in the forum you won't find me. Mostly Armada and amlogic. We have people knowing the odds of those boards so they can deal better with it than me. Moderators moderate first responders help. For some platforms I'm both (e.g. rockchkip) for others I just unlock topics and have a quick view if there's something odd about it (e.g. hidden shit in links). But different mods will have different styles, and as long as it is not harmful to the community at all people need to deal with it. Depending on which moderator you get you might get a different style of answer. It's not that we have to follow some cooperate guidelines how an answer should look like. If you split, merge or delete you might inform people by leaving a short post why you did it and where the other part can be found. If you move things I mostly let the checkbox with the 'simlink' so that the guy sees where his post is now.
  24. interesting, for me it only happens on mainline not on bsp, but I don't see any major differences in DT (it's written in a different style, but nothing scary about it). I don't really know why the "soundcard" pollutes UART - it's obvious from the schematics that it can happen but there's no reason to do something for the sound output at all as long we're only in the console. Well on my todo list for later - I don't care much about sound yet. @belfastraven this happened on the Manjaro build (I just picked out some parts of it to integrate it in our 5.4 sources)? Someone might then inform Tobias Schramm, it seems he prepares it for sending parts upstream so he may wanna know it - to avoid getting shit-talked on LKML again (https://lkml.org/lkml/2018/5/11/107)... Someone knows which bootloader Manjaro uses? Mrfixits or own build? I currently work with eMMC and stock OS removed and have some odds getting the display working so some inspiration would be appreciated.
  25. back then the boarddetection was roughly 200 lines of code, now ~72 commits affecting this file later. we have 600 lines of code. I didn't even look at it fully to see if something in the logic changed and I won't do it. GPIO handling is of minor interest to me. The reason I maintained pyGPIO for a while (credits for writing it goes mostly Olimex - I just added a few other boards and a detection mechanism for those using armbian) was cause there was a community demand for it - there was never much attention to it so pyGPIO is more or less dead. From the boards you list on your lib I probably own 4-5 and most of them either run productive and I don't touch them anymore (except updating the OS from time to time) or they sit in their boxes and do nothing. So I couldn't even test if it works as it should. If the code is still maintainable for you keep going, if it isn't don't expect others to fix it for you and rewrite it on your own once you've the time for it. The same counts for armbian as well - I don't expect someone to rewrite NandSataInstall one of our scripts which is boated to hell and should've been rewritten a long time ago but being aware that this should be done once - it's just a question when someone has the time for it. As @TonyMac32 mentions we've soon a new armbian release and I've some plans to get some (for me interesting) features working unfortunately for you, none of them is GPIO nor python related...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines