chwe

Moderators
  • Content Count

    1320
  • Joined

  • Last visited

2 Followers

About chwe

  • Rank
    Embedded member

Profile Information

  • Location
    Switzerland

Recent Profile Visitors

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

  1. well this part will be for sure off topic but: https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt thankfully I don't have to give legal advises but I think you can have a 'confidential' document how to use your GPL derived code (and documentation is somehow a 'how to'). Is it a practice I support, for sure not but it is what it is. Luckily some companies decided to push further into making such stuff public (e.g. rockchip having a wiki, and opened a bunch of their kernelcode so that we can really work with, others like mediatek started to actively push their drivers to mainline as well - I hope others follow this way, it makes their SoCs just more useful in the long term). But back to topic, I might dive into the w2 adventure in the future I just need to sort out a few things cause I'm definitively not up to date here (actually this was some sort of a follow up after my work on the mt7623n which worked quite well in the end - well nobody here was really interested in the work in the end, but I got it more or less properly working with a mainline kernel in the end). As far as I understand the boot-process (and please correct if I'm wrong). There's a 32 bit bootloader (u-boot) supposed to chain-load the 64 bit u-boot somewhere in between the tools from them also provided the pieces of ATF needed (it's not really an isolated atf source right? this must come somewhere out during u-boot building I guess but I didn't dive into those sources right now to figure out what happens here and I'm rather unfamiliar with ATF, ). Finally, the 64 bit u-boot fires up the kernel with current limitations that this has to sit either in a squashfs or fat? (here things get messy in my head ). And there's some sort of rescue tools if you mess up with the SPI NOR to recover if you mess up there (before I really want to dive into this, I'm a uboot plumber by try and error not by complete understanding and for sure I'll mess it up more than once... ). For me as a armbian oriented plumber, it's obvious that the final u-boot needs to be able to load a kernel and a rootfs from an ext4 (I assume a 2015 u-boot should be capable to learn this, it's just a bit of tweaking needed (the mediatek u-boot for mt7623 was a 2014 version and finally also able to do this, wasn't that much work, once you figured out how outdated u-boots work). I won't repeat a fat adventure as I did with my experiments with the RPi 4 on 64 bit images built with armbians buildscript (yes, this stuff was never published and Images were never distributed, so no GPL issues here.. - and just in case someone asks, it's not gonna happen that I'll push this on github, too much mess in the buildscript to get out a barely working image - probably don't even have the branch anymore). But at least I need some hints how to recover a broken SPI once I'm there before trying heavy modifications on this side. So if one of you can summarize this a little bit, I would like to read it.
  2. you might ask @Lion Wang or @Nora Lee if they can give you access to their newest repository on github. the repo contains a bit of documentation from RTD how the bootloaders are supposed to work (e.g. recovery etc). It seems to contain also the sourcecode for the SPI part of the bootloader (I'm not up to date how much of this code is currently 'in the wild' so please forgive me if it only contains stuff you already know).
  3. well it took a while to figure out that there are only a few desktop recording programs for wayland.. and without wayland a 13 inch full hd display sucks as desktop, due to x can only have 100% and 200% (both of them suck with gnome, wayland is capable of 125% which is just perfect). A small hint here.. gnome wayland on ubuntu doesn't record properly with a 125% zoom, so for recording you've to go back to 100% to get something 'useful' out of it. well I better don't tell you how long I normally need to prepare presentations.. A good training is "spin the powerpoint", a 'game' we quite often played at university.. basically, you see the slides the at the same time as your audience (cause someone else wrote it). It needs a basic understanding of the topic, but you learn a lot about free speech (not the american meaning of it). You must also consider that your audience normally doesn't know your topic well, which gives you some freedom in the presentation (it doesn't have to be 100% 'scientific correct'.
  4. Freshly from the not official Armbian studios: Armbian the last 2 years I would assume that even on a conference those topics wouldn't be presented: it's a special use case, and the question comes up on a weekly to monthly repetition pattern. that's simply user-side stuff, mostly unrelated to armbian as a project, but as a NAS example, OMV is quite common under armbian users cause the ARM maintainer of OMV is @tkaiser. that's what changelogs are for. I assume the major reason the video is on the page is not that we have a video but because it's a side-product of the conference. So chances to get a new video are rather low, except there would be a new talk about the project in another conference. And for such a talk I would propose other topics, like how to engage people to contribute or how to deal with different opinions etc. But luckily for you, most of your questions can be answered with the search engine. and with text to speech it might feel like a video.
  5. with the green + in the right upper corner you can follow a thread without even writing in it. just out of curiosity.. what use-case do you have for the board?
  6. check the userspace, maybe it was limited to 1.8GHz back then I don't know, check the DT (means decompile) to ensure we had the upper opps activated back then. It depends on when the image was built. Maybe there was a reason why we didn't had the higher opp's (could be powering is critical due to 'dumb' USB-C).
  7. http://opensource.rock-chips.com/wiki_Main_Page mostly around px30 cause it's the most similar one. the kernel adjustments are likely minor, rockchip64 might be probably the best starter, for sure a bit kernelconfig adjustments are needed. maybe a few patches cause ayufans repo didn't merge everything from rockchip 4.4 adjustments in u-boot are for sure also needed. obviously a board, a proper dt and a bit of time to see what raxda changed in their kernelfork for this board. well, code which you'll have to write is likely below 100 lines of code.. but figure out what you'll have to patch and merge from other kernels to ensure things work properly (on a kernel level) can still be hours of work.
  8. https://github.com/armbian/build/pull/1482 Far away from 'supported but basically the camera can work without loosing dt overlays. For the userspace part, once this one get merged you're on your own.. I can't provide more help than that. From a kernelside the cameras work both without crashes, they're patched to match the asus repo and you can switch between both.. Get the right commands and everything else sorted out to make them useful in userspace is a different story, and that's definitively not my story. I already spent too much time for this. turned out that a small commit in 2018 made the trick and a bunch of crappy patching.
  9. Nevermind, their development branch seems to have it.. https://github.com/TinkerBoard/debian_kernel/blob/c2fc097dfb04bfb5780c58137e94f7c8eab64b19/arch/arm/configs/miniarm-rk3288_defconfig#L547 https://github.com/TinkerBoard/debian_kernel/blob/c2fc097dfb04bfb5780c58137e94f7c8eab64b19/arch/arm/configs/miniarm-rk3288_defconfig#L401 hmm now let's see what else is needed..
  10. welcome back commander.. it's being quite some time. if.. and that's the if.. they have overlayFS and isp1 working on the same image.. then yes.. I'll give it a shot.. let me check their sources. Edit: seems to still based on isp10 https://github.com/TinkerBoard/debian_kernel/blob/de5c3c4a543c45dee4b102c879fb52c8604d78a3/arch/arm/configs/miniarm-rk3288_defconfig#L499
  11. probably our posts are more or less written at the same time so you missed it.. @JMCC multimediascript is great, and once the camera would work from kernelside.. it provides more or less everything to get it working from userspace side.. But well.. it's the kernelside which doesn't work. no wonder, there's no driver trying to probing it.. Didn't had neither.. You'll grow over time.. just throw enough time to a project and things will progress.. I'm more or less done with the ISP camera for the tinker, I tried, I figured out what causes the issue, it got reported and then ignored: https://github.com/rockchip-linux/kernel/issues/98#issuecomment-396422765 There's not much more I'm willing to do to get this fixed.. If I would get 5$ per hour for this issue I could probably buy 2 SBCs in this price range. It should be, it is reported (see thread above) but I've not tested it. And friendly arm uses different camera modules, whereas for the RockPi nobody tried it, and I would assume you've to deal with dtb to get it working.
  12. not an official.. and as long as there's no interest from rockchip to address it there's not much hope that this changes. The threads related to it are those: iirc it could work with some kernel modifications which then would not allow to use dt overlays.. which is on the other hand needed to support multiple cameras.. and it was a rabbit hole to get it booting (I know it, cause I went down this hole and wasted a few evenings and nights on it with constant sd-card swapping just to figure out that this one also doesn't boot until I got a booting one). for RK3399 the situation is slightly different, iirc it should still rely on isp10 (whereas rk3288 moved to isp1 - two different drivers developed by rockchip to access the csi) which should work but I never tested it (actually during development I saw something that rk3399 should also be supported by isp1 but I can be wrong on this). At least with isp10 they had success..
  13. well that was back in the days where we were really excited about every rk3399 sbc and immediately supported them cause cool devices.. The board starts at ~70$ (1gb) up to 100$ (4gb) which is okay.. I like that they sell expansion boards for the m.2 slot. the fact that the board has no ethernet without adding a carrier (and I didn't check if a carrier with ethernet exists) is a bummer.. This might be an interesting sort of SOM for small series high price devices but not a casual SBC for the average user here. But nevertheless, I hope the few hints for @Hijax may help him to integrate csc support for it. As long as he can provide a sane integration of the board into the buildsystem, I don't see a reason to reject such a PR. Obviously it's then up to him and other contributors to keep those patches alive. Otherwise csc support doesn't live long for it. Reminds me to the idea of having a staging like structure (https://lwn.net/Articles/324279/) in our buildsystem for csc, eol targets so that we can sort out related patches easily in case they break supported boards. But well, that's one for a different thread..
  14. ahh.. these guys which actually have a armbian logo on their website: https://www.96rocks.com/ but never showed up here? Well.. no dev has it.. and they claimed armbian support before the board was even available.. kernelconfig respectively boardfamily has to be either rockchip64 or rk3399.. Even as csc I don't want to see a third rk3399 boardfamily.. look at the related sources files as well.. for atf you'll need to tweak it maybe.. if possible add it to the rk3399 branch, cause it relies on upstream u-boot.. In case ram doesn't allow it switch to rockchip64.. iirc lpddr4 is not supported by upstream yet (but wip).. but ddr4 and ddr3 should be.
  15. @Igor when did we change RockPi to supported? Especially cause we provide 4.4 kernel in the first two dl. options as mature support.. IMO it doesn't represent the current status.. Only difference compared to before is that @ayufan took our patch and added it to his kernel (which is good cause it saves us a patch to maintain). But the 4.4 dts was never cleaned and iirc it had a bunch of 'not as healthy stuff in combination with this kernelfork. IMHO the status should still be wip, as more or less for the whole rk3399 family. But happily it's not my decision. Tagging @TonyMac32 and @martinayotte