• 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. it's our default sunxi kernel and mainline u-boo and choosen the right device tree. See those 3 commits first I thought about it's own SoC family.. but it's not really needed.. The board works also with defaults.. BOOTCONFIG="LicheePi_Zero_defconfig" and a normal sunxi kernel..
  2. depends which threads you look at.. The RPi isn't a bad board.. People just try to do insane things with it.. And their last iteration has IMO some really annoying drawbacks.. Which is sometimes a bit annoying when you try to explain it to a RPi fan. Some of them tend to ignore that there are other boards which might fit better for their use-case as a Pi. Similar to some boards we support are probably not the best choice when you want a TV box for hardware accelerated video decoding. If you buy by use-case and not by price you mostly get a good one for the job you have (I have some OPi Zeros which perform perfect for my needs there but system load in average is below 10% for the job it has)... Anyway.. this post went a 'bit' off-topic..
  3. chwe

    Board LED (RockPi 4b),

    should we split the thread? It's a way more than just LED for rockchip now..
  4. chwe

    Board LED (RockPi 4b),

    Well the kernel discussion is open since a long time.. and we switched from here to there to here to... original goal was once to have RK3328, RK3399 (and if possible RK3288) under one kernelconfig/source.. Something we probably never achieve.. RK3399 kernel is under friendly arms control and I'm not sure if this makes things better ore worse.. They may also adjust stuff just to ensure it works on their NanoPis without issues but don't care about other boardmakers needs. And we support a bunch of different RK3399 boards... The revert shows only kernelconfig.. Do we relay on his kernelconfig as well?
  5. chwe

    Renegade touchscreen everything is there.. just activate the needed modules and build your own kernel.. But probably none of us tested if it works on RKs kernel. Fire up a virtualBox with ubuntu, build kernel, try it, report and if everything works create a PR.
  6. chwe

    Board LED (RockPi 4b),

    From an early point of development having your own kernel makes sense.. Saves you time and you don't have to deal with other people messing with it which might break stuff for the RockPi and cause you provide your own images based on it it's understandable to use it for some early armbian previews as well. For Armbian as a project it doesn't make that much sense. The more Rockchip boards we can maintain with one kernel source, the less work we have. Something I noticed by looking through your kernel commits: You've started with devicetree overlays right? As far as I know, the normal workflow to load them is to have the kernel module config_of_overlay ( compiled. Last time I had config of overlay together with Rockchips ISP driver ( the kernel crashed immediately at booting. Since you claim that the camera works on your images (and from DT it looks like you use isp1) does it also work with device tree overlays? Did I miss something obvious here? Or is DT overlay early wip and not yet implemented?
  7. chwe

    Board LED (RockPi 4b),

    hehe is it public? Didn't spot in on their page..
  8. chwe

    Board LED (RockPi 4b),

    WIP so things like that are expected.. Provide a bootlog and I'll have a look into it.. [small to medium rant] If it's a Raxda produced 'Armbian' things might not work and I'll not fix it.. They decided to use their own 4.4 kernel fork and I'm not willing to look into it. If they want a more stable 4.4 based armbian Image they should contribute to Armbians 4.4 Kernel (basically @ayufan one with some patches). And not something like this: We won't maintain a third RK3399 bsp kernel only cause there's a new board out which throws us a bunch of errors with ayufans kernel.. That's where their armbian previews came from... The whole device tree looks like a fire and forget push.. e.g. doesn't make sense at all.. The CSI populated on the board is a 2 lane 'RPi alike one' whereas ov13850 is a 13mp camera normally connected via 4lane mipi csi.. Looks like some leftover from a firefly or so.. Even then, it's on a different i2c bus which also looks fishy.. didn't work.. At least only one LED could be triggered.. or there's a third led somewhere which I didn't spot.. Unfortunately there aren't public available schematics to get a clue how things are soldered together here.. there's no IR led populated per default.. so this stuff looks just wrong... Maybe things get better once the board reaches mainline: normally the peer review there stops people from messing up stuff.. but this will take some time.. [/rant] Currently, time doesn't allow to dig into it.. I've a lot of other work to do and my rockPi runs productive on mainline for a numbers crushing project I'm in (since 7 days it runs 24/7 at roughly 80°C and it does well here).. So I won't stop it from it only to fix a 4.4 kernel which is broken.. I can have a look into debug from console but not much more.. First I would try to boot it from SD-Card not burning images directly onto eMMC.. Attach an USB-UART and provide us bootlogs.. Then we see where it stucks..
  9. chwe

    Board LED (RockPi 4b),

    that should be the normal behavior.. As far as I know, there's no way to toggle green.. Tried it once and failed.. But without bootlog from serial.. there's no way to help you. btw... the title is a bit... --> well I fixed it for you.. Edit: should explain the LED behavior, but at least on mainline only red could be triggered.. Green was always on..
  10. chwe

    nand-sata-install warning dialog is broken

    maybe related to those two?
  11. chwe

    RockPi 4b 'board bring up'

    there you go: it's called 'The silly approach'
  12. chwe

    RockPi 4b 'board bring up'

    it's wip... things don't work should be the default expectation... 4.4 will have some drawbacks with the rockPI, as far as I know (tested some time ago) the DT needs some fixing cause we lent it out from their kernelfork which seems to be 'slightly' different to the one armbian uses.
  13. chwe

    RockPi 4b 'board bring up'

    Hmm things might break for the RockPi during bring up.. The device tree is lent out from an other board and the whole RK3399 boards must be considered as WIP. You can freeze the kernel in the beginnings until stuff gets mature. If your board runs in production and you want fix a broken kernel this might be a good idea. I would probably build a 4.19 kernel rather then using the provided one (but well.. I build my images mostly on my own, except I'm at work.. :D) The board runs fine so far (currently running a hight CPU load application since 2-3 days 24/7 so the SoC sits between 75 and 80°C the whole time.. I really should optimize its cooling cause the big cores throttle down )...
  14. Since python 2.7 goes EOL and nobody should deploy a website based on it anymore a few updates for Debian Stretch 4.14.x Kernel not sure if all of them are needed, but pip install pillow worked after its finally: sudo apt-get -y install python3-devlibtiff5-dev libjpeg62-turbo-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.6-dev tk8.6-dev python-tk python3-tk libharfbuzz-dev libfribidi-dev Deploy changes also a bit: virtualenv -p python3 env source env/bin/activate pip install --upgrade pip pip install djangocms-installer djangocms -f -p . mysite