• 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. well if the module itself has wired out the 4 lanes, it's likely only a DT issue to define those 4 lines vs. likely that on mainline driver the data lines are also configurable via DT. But you need also then a camera module with 4 data lanes and I've no idea how the schematics of those camera modules look like. For sure getting this "properly" working on mainline isn't an easy task. Even on 4.4 kernel the cameras don't work perfectly cause nobody cares. See: during development of the isp1 driver (branch deleted by rockchip but you can grab most of the information here: people also used it successfully on rk3399. I assume with a bit of tinkering (e.g. apply the patches to fix the boot issue support for dt overlays in rk3399 4.4 kernel, I think we didn't add overlay support for 4.4, obviously the needed camera drivers and a proper overlay for your cameras). All this would be relatively straight forward if someone takes the time to do it. It's just the question if someone takes this task up and actually tries to get it working.. I only have 2 lane CSI cameras (e.g. RPi cams which may work on the RockPi, for everything else I miss useful CSI cameras...)
  2. chwe

    M4 V2

    well you need a device able to go to this baudrate.. otherwise you'll only get garbage out. as describen in the topic I linked, if all things go wrong.. you can even ssh into a SBC use its UART to connect to another one, called the silly approach (and if you love the insane approach, you can then even uart back to the first one.. ).
  3. chwe

    M4 V2

    ... or also shown here:
  4. it is doable no question. But the way raspian configures interfaces differs from ours which adds then additional work to do. I don't know if there are any web UIs for NetworkManager this might then not be exactly the same interface as this one but also work. nothing to feel bad about.. Never the less you can try to port it.. and maybe someone will help you. Only cause I'm not interested in doesn't mean nobody is.
  5. no it's a cli based but should be possible to configure even for a newbie. you may need to write a tutorial with printscreens how to to do it. for me the whole request sounds a bit like offloading your work to us (it seems you sell a product based on armbian, I can be wrong here but it just sounds like that). Armbian is ubuntu/debian + usable kernel (might not be the official definition but it's mine), IMO this doesn't really fit into the project for the following reasons: we had to make sure that both armbian-config and RaspAP will work at the same time (means one doesn't mess the other one up) armbian uses NetworkManager, Raspbian not, so it's not just a few hacks here and there to get this working I don't see much of a use-case for it but a lot of maintenance costs to keep it updated honestly, lack of interest to maintain another piece of software I don't use.
  6. happily we're not a vendor right. would it be nice to have the hashes published somewhere.. of course it would.. it would also be nice to have a unified bootloader on arm which doesn't suck give me headache every time I look at it. or wifi which just works or device tree which actually describes the devices properly and not copy paste gone or boardmaker cares about mainlining their products etc. If you don't trust our images you can still build them yourself. Then you just have to trust that we didn't hide something in the x lines of code to create an image (have fun to review that ). it would also be nice if someone rewrites nand-sata-install.. My attempts so far just made it worse.. He is a bit paranoid ... well is still a thing? well we had fun to send each other shutdown commands over network in school when I was young (nothing was more insecure than our schools network back then - that's why no teacher trusted it and never had exams on the school computer )..
  7. maybe the drivers are not there. honestly I didn't test much mPCIe stuff on that board back then. you might check
  8. then feel free to try out someone else's stuff. The instructions are in one place: or in the FAQ section on the downloadpage. then it would probably make sense that you link the conversations you find. This would give a first impression that you actually did your part. Is it a satisfying solution we have right now? Probably not, but around all the stuff which isn't in a perfect shape using 2 programs for image decompression and writing is probably for most people here on the lower end of priorities. and exactly that's probably the reason nobody touches stuff which works "good enough". probably not, I'm okay when they at least read the getting started and follow the recommendations. Otherwise chances are higher that they end here:
  9. why not? what on armbian-config is not "end-user" friendly?
  10. search engine might do it as well.. cause it's google.
  11. Possible? Probably, but it doesn't make sense. The main "work" for this board will be u-boot support (from kernel-side there's not much lifting needed to get it working). We will not add a third bootsource for rk3399. Especially not a outdated 2014 version. So if you really want to do something useful.. just get at least the 2017 uboot working. I don't think this is worth it otherwise (if they didn't mess up something hard, and I don't think they did the rest will just run fine so not much 'testing' needed). I would base one on the RockPi4b defconfig and see if you need to fix things here and there to get it working.
  12. and did you ever look into the sourcecode for this SoC (e.g. bootloader and kernel). I clearly understand why nobody wants to deal with this.. Compared to a 'well understood' allwinner a64.. have fun to build up a community around such a dead chip (in terms of being outdated) somehow motivate them to rewrite and upstream this so that your "freephone" will not be a security nightmare in the future (not that mainline is bugfree, but at least there's an existing chance that they are found over time whereas in a rotten bsp kernel they're likely last forever). I'm quite sure that something like linux-sunxi doesn't happen that often (there was a time when Allwinner offered SoCs with a interesting set of features, for a cheap price and somehow enough sourcecode and documentation reached the needed people to mainline those SoCs - luckily for them, AW SoCs being well mainlined now with minor investments from their side). I'll mix you a cocktail of hormones and half of your body will think you're pregnant. A bit more serious.. IMO that's a bit a stallman-ish point of view. I think there are several levels of free, and indeed things can be more or less free. But that's more a philosophical question. or as a friend always says: "It is, what it is. Describe the result as best as you can and others must decide if they want to false advertise your results to gain attraction" (he's a pessimistic doing in science.. ). For the Pinephone, they try at least to go a good job (e.g. datasheets for all used ICs are linked on the wiki), and they summarize what is used. It is what it is....
  13. Could we make a diff between the two commits of a version bump? If we store those in a dedicated folder it would be easier to make a more detailed change log cause you can see what changed between those.
  14. the driver is here... it's just a question of time to implement it properly.. And the driver itself tends do be a bit buggy see: I just don't see a reason to implement this into our kernel yet. Due to: It's likely to still have bugs (as by the submitter explained) without hardware accelerated encoding/decoding I don't see much of a gain to use the camera on mainline, the current state of those drivers and their userspace applications are unknown to me (I'm not much of a desktop user guy, camera support for the tinkerboard was added cause it pissed me off annoyed that I don't find the rootcase why this driver hanged the kernel each time). I don't have the hardware to test it (e.g. a nanopi, they use a 4lane csi compared to RPi/rockpi 2 lane, I'm quite sure I would fail on such an implementation without hardware to test) None of the two available camera modules for the nanopi (ov13850, nor ov4689) are mainlined, there's a vo13858 driver there but I've no idea how much those two differ. Even when the initial support was done for rkisp1 for rk3288, the community contribution to enhance the quality (e.g. imx219 aka rpi cam v2.1picture is green cause something with color stuff doesn't work properly - config files have to be loaded from userspace to ensure it gets corrected) seems to be of minor interest. I don't see a big chance that this changes with a driver which is probably in a worse condition compared to the bsp driver (in case of functionality not code quality - the mainline driver goes through the review process). the initial stuff to support the camera on mainline is here, but it's up to someone to apply and test it. Currently I don't think this someone will be myself. But I will help in case questions come up.
  15. on the available versions there won't be a off switch. See the third answer you got when the thread started.