• Content Count

  • Joined

  • Last visited


About chwe

  • Rank
    Embedded member

Profile Information

  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. can you provide an the output of sudo armbianmonitor -u? I don't have a recent current nor dev image installed on my RockPi.
  2. 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..
  3. 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: 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.
  4. 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 ) 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.
  5. 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..
  6. chwe

    Pinebook Pro

    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..
  7. chwe

    Pinebook Pro

    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: 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.
  8. 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: 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...
  9. 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: 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..
  10. 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.
  11. should explain most of it.. this whole mess should be cleaned once we've moved all boards to upstream u-boot for rk3399 boards...
  12. 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) vs. mrfixit (that's a different panel) 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..
  13. 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).
  14. 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 ( 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).
  15. 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..