chwe

Moderators
  • Content Count

    1273
  • Joined

  • Last visited


Reputation Activity

  1. Like
    chwe got a reaction from bob_janes in Recommendation for new board   
    I would definitively not put all these stuff on one board... If something messes.. your entire network will be in trouble including all the data on the nas.
     
    check the PSU, if it's only that.. the board can still serve as a NAS, and thanks to the new patches for its sata implementation.. it shouldn't be a bad one..
     
    rk3399 is powerful for a lot of your other tasks.. but still wip.. and things might change here.. means the risk is higher that things break as well. for the blog/webserver stuff.. As long as you don't expect much visitors there.. a cheap H3 might do it.. and for pihole no idea.. probably one with GbE, not my field..
  2. Like
    chwe got a reaction from Tido in Support of Raspberry Pi   
    one of the maintainer of this project (dealing with rockchip and amlogic)?
     
    Who has not the right to remind you that the discussion is pointless? The decision that current RPis are note supported by armbian was made a long time ago and it still stands. And for the who started first on throwing dirt to each other here doesn't matter to me.. If it's not working on a acceptable level I'll simply end it (without needing dirt.. but with something I don't like, means closing the thread).
     
    and if you go through this whole thread.. You get some 'objective' and probably also a lot of subjective answers to that.. And just a last one.. Guess what happens if a platform gets added in which no developer has an interest in? Exactly, nobody cares about enhancing the support for it.. Means spending hours of hours of their spare time to make things better, following upstream to pick up stuff like this: https://lkml.org/lkml/2019/5/20/431 integrate it and test if it solves the crippled mailbox system the RPi has? Dealing with the blob bootloader the RPi needs and check after every update of this blob if the new one behaves similar or if they add new thermal throttling behavior which was barley annotated when the RPi3b+ came out? This stuff needs time. It's not only adding a few lines to the buildscript and you're done.. And further Pi1 and Zero is ARMv6, pi 2 is ARMv7 and some ARMv8, pi3 is ARMv8. By default we provide userspace matching to CPU architecture.. It will be a nightmare to explain again and again (and again) that a RPi2 image might not work on a RPi3. That by using RPi3 a bunch of the things which make the Pi useful (e.g. the decoder stuff) might not work cause all the userspace stuff isn't armhf on armbian for 64bit CPUs.
     
    With Raspian, there's a decent image out for RPis, it gets updates it supports the hardware. It's not armbian but also a debian derivative. And if, for whatever reason you want a Armbian userspace but don't want to deal with kernel work nor bootloader etc. @tkaiser provides a OS layer to frankenstein a 'Armbian on RPi' together (https://github.com/ThomasKaiser/OMV_for_Raspberries). And if you want to deal with kernel as well.. Fork armbian, add the needed configs for kernel bootloader etc. Glue everything together and deal with the FAT partition the RPi needs for its bootloader (basically the buildscript should allow such FAT partitions). Find a suitable Kernel (probably the one RPi provides on their GitHub - or if you really want to deal with it.. go for a mainline) and craft your own image, based on armbians buildscript (it's on github, everyone can fork it). But don't expect that someone does the work for you especially if those people are simply not interested in the currently available iterations of the RPi. 
    And don't expect as well that they always take as much time as I took this time to explain it again and again, when someone shows up complaining that we don't provide Armbian for RPi... I needed a break from writing serious stuff..
     
     
  3. Like
    chwe got a reaction from Aux in Support of Raspberry Pi   
    hmm..
     
    the bits to grap this information are here and there.. It needs time to summarize them.. It's mostly a boring task to summarize them, and it comes with *random board*... It's not only the RPi which some random people would like to see supported.. And normally it comes with.. why is *random board* not supported not, based on my attempts, *random board* could be an new interesting platform to support, this, this and this is currently working, here there and there I'm struggling to get things working, I would like to share my work and hope that you can give me some hints to fix them..
     
    Good examples how things can go in the right direction:
     
    and a few others (shamelessly I would say that the mt7623 platform bring up thread of mine is also a good one, even when things are on hold since a long time).
     
     
    It's a time vs. worthiness decision and @TonyMac32 decided to keep it short (which is completely fine, I would do it as well if I wouldn't need a break from thesis writing.. )
    not really, there are still cases where the RPi shines. It's not as expensive, it's available more or less everywhere.. so if you need a board immediately it might be worth to think about the RPi as well. I've one on my own for a camera related project, where the power is sufficient.. I've set 2-3 up for projects of colleagues.. They can't manage them on their own, and I don't want to deal with those boards anymore.. So an RPi is a save bet.. I can setup a crontab for updates (so that it's not one of those sloppy IoT devices used in botnets - or at least not more than the other RPis around the world) and if they mess up things I've a bash scripts which modifies their 'default raspbian' to their needs (there's absolutely nothing fancy at their needs, it could probably be solved with a ESP8266). I didn't want to wait until another boards makes it through customs and fear that I've to pay some additional taxes.. So going to the next local store, buying a RPi and the most ugly case I could find and a reliable SD-Card and everyone was fine. The Pi is Ok and has its value.. generally spoken it's just not attractive to the developers here, therefore they spend their time on stuff they're interested in.
     
     
  4. Like
    chwe got a reaction from Aux in Support of Raspberry Pi   
    one of the maintainer of this project (dealing with rockchip and amlogic)?
     
    Who has not the right to remind you that the discussion is pointless? The decision that current RPis are note supported by armbian was made a long time ago and it still stands. And for the who started first on throwing dirt to each other here doesn't matter to me.. If it's not working on a acceptable level I'll simply end it (without needing dirt.. but with something I don't like, means closing the thread).
     
    and if you go through this whole thread.. You get some 'objective' and probably also a lot of subjective answers to that.. And just a last one.. Guess what happens if a platform gets added in which no developer has an interest in? Exactly, nobody cares about enhancing the support for it.. Means spending hours of hours of their spare time to make things better, following upstream to pick up stuff like this: https://lkml.org/lkml/2019/5/20/431 integrate it and test if it solves the crippled mailbox system the RPi has? Dealing with the blob bootloader the RPi needs and check after every update of this blob if the new one behaves similar or if they add new thermal throttling behavior which was barley annotated when the RPi3b+ came out? This stuff needs time. It's not only adding a few lines to the buildscript and you're done.. And further Pi1 and Zero is ARMv6, pi 2 is ARMv7 and some ARMv8, pi3 is ARMv8. By default we provide userspace matching to CPU architecture.. It will be a nightmare to explain again and again (and again) that a RPi2 image might not work on a RPi3. That by using RPi3 a bunch of the things which make the Pi useful (e.g. the decoder stuff) might not work cause all the userspace stuff isn't armhf on armbian for 64bit CPUs.
     
    With Raspian, there's a decent image out for RPis, it gets updates it supports the hardware. It's not armbian but also a debian derivative. And if, for whatever reason you want a Armbian userspace but don't want to deal with kernel work nor bootloader etc. @tkaiser provides a OS layer to frankenstein a 'Armbian on RPi' together (https://github.com/ThomasKaiser/OMV_for_Raspberries). And if you want to deal with kernel as well.. Fork armbian, add the needed configs for kernel bootloader etc. Glue everything together and deal with the FAT partition the RPi needs for its bootloader (basically the buildscript should allow such FAT partitions). Find a suitable Kernel (probably the one RPi provides on their GitHub - or if you really want to deal with it.. go for a mainline) and craft your own image, based on armbians buildscript (it's on github, everyone can fork it). But don't expect that someone does the work for you especially if those people are simply not interested in the currently available iterations of the RPi. 
    And don't expect as well that they always take as much time as I took this time to explain it again and again, when someone shows up complaining that we don't provide Armbian for RPi... I needed a break from writing serious stuff..
     
     
  5. Like
    chwe got a reaction from Slackstick in Support of Raspberry Pi   
    one of the maintainer of this project (dealing with rockchip and amlogic)?
     
    Who has not the right to remind you that the discussion is pointless? The decision that current RPis are note supported by armbian was made a long time ago and it still stands. And for the who started first on throwing dirt to each other here doesn't matter to me.. If it's not working on a acceptable level I'll simply end it (without needing dirt.. but with something I don't like, means closing the thread).
     
    and if you go through this whole thread.. You get some 'objective' and probably also a lot of subjective answers to that.. And just a last one.. Guess what happens if a platform gets added in which no developer has an interest in? Exactly, nobody cares about enhancing the support for it.. Means spending hours of hours of their spare time to make things better, following upstream to pick up stuff like this: https://lkml.org/lkml/2019/5/20/431 integrate it and test if it solves the crippled mailbox system the RPi has? Dealing with the blob bootloader the RPi needs and check after every update of this blob if the new one behaves similar or if they add new thermal throttling behavior which was barley annotated when the RPi3b+ came out? This stuff needs time. It's not only adding a few lines to the buildscript and you're done.. And further Pi1 and Zero is ARMv6, pi 2 is ARMv7 and some ARMv8, pi3 is ARMv8. By default we provide userspace matching to CPU architecture.. It will be a nightmare to explain again and again (and again) that a RPi2 image might not work on a RPi3. That by using RPi3 a bunch of the things which make the Pi useful (e.g. the decoder stuff) might not work cause all the userspace stuff isn't armhf on armbian for 64bit CPUs.
     
    With Raspian, there's a decent image out for RPis, it gets updates it supports the hardware. It's not armbian but also a debian derivative. And if, for whatever reason you want a Armbian userspace but don't want to deal with kernel work nor bootloader etc. @tkaiser provides a OS layer to frankenstein a 'Armbian on RPi' together (https://github.com/ThomasKaiser/OMV_for_Raspberries). And if you want to deal with kernel as well.. Fork armbian, add the needed configs for kernel bootloader etc. Glue everything together and deal with the FAT partition the RPi needs for its bootloader (basically the buildscript should allow such FAT partitions). Find a suitable Kernel (probably the one RPi provides on their GitHub - or if you really want to deal with it.. go for a mainline) and craft your own image, based on armbians buildscript (it's on github, everyone can fork it). But don't expect that someone does the work for you especially if those people are simply not interested in the currently available iterations of the RPi. 
    And don't expect as well that they always take as much time as I took this time to explain it again and again, when someone shows up complaining that we don't provide Armbian for RPi... I needed a break from writing serious stuff..
     
     
  6. Like
    chwe reacted to jernej in Since Tanix TX6 can boot from the SD card   
    In case of Allwinner port of U-Boot, ATF (bl31.bin) gets packaged into itb file (u-boot.itb), along with U-Boot proper (u-boot.bin) and dtb file. You should just combine sunxi-spl.bin-arm32 (make sure is padded to 32K or 24K, I'm not sure ATM) and u-boot.itb.
     
    BTW, I'm not sure if mainline Linux works with BSP ATF binary. Just compile latest official ATF release (mainline H6 ATF is not board specific, so it should work).
     
    Not sure, I don't use earlyprintk. If it's not CPU mode issue (Linux expects that it's already in 64-bit mode) it may be DT issue.
     
    Anyway, I wouldn't bother with Linux at this stage. Fixing mainline DDR3 DRAM driver would help a lot with other issues.
  7. Like
    chwe got a reaction from lanefu in Support of Raspberry Pi   
    I see some decent moderator skills here... @Igor @lanefu we should change his official title here..
     
    btw. if this thread goes back and forth.. I'll simply close it until the first iteration of a not VC4 based RPi is out (or someone wrote a bootloader which allows to boot without binaries provided by the foundation ).
  8. Like
    chwe reacted to pkfox in Emmc USB adapter [solved]   
    Forget this folks it appears I put the module in the wrong way around ( face-palm )
     
  9. Like
    chwe got a reaction from lanefu in Final Image for Nanopi M4 ?   
    "newest and fastest" quite often ends here:
    https://forum.armbian.com/forum/31-sd-card-and-psu-issues/
     
    that's why I don't care about such information without actually prove that the used card is really fast (forum search will guide you how you can test it)... Especially when it's about Images we (as armbian team) are not 'in charge'.
     
    about which Image do we talk here? switched to Armbian or still on FriendlyElec's image?
     
    a short reminder (https://forum.armbian.com/guidelines):
    A support question must include the following: Board you use Issue you face Description of your set-up (e.g. powering, connected hardware, used SD-Card) 'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier!  
    besides being in 'Development' not 'Technical Support':
    Development A section for more experienced users. For example for SoCs where Armbian support is currently not mature enough for full support, questions related to the build framework and 'Board Bring Up' for new boards we might consider supporting in the future. We can't provide the same level of support for WIP (work in process) SoCs cause kernels for those boards are simply not ready yet. Board Bring Up is mostly for experienced users which want to contribute in support for new boards/SoCs, a *please support random board* without any rational and no interest in contribution for such a support will simply be ignored. If you just want to point us to a new interesting board our water-cooler (General chit chat) is the right place for it.  
    btw. @lanefu can you adjust the text there? 'Technical support' isn't anymore.. so the text need some small adjustments..
     
     
  10. Like
    chwe got a reaction from NicoD in merge rockchip64 with rk3399   
    I prepared (last weekend? - don't remember anymore) a first step towards a merge of rk3399 (currently nanopi boards) with rockchip64 (more or less all the rest) so that both can be covered fully under one boardfamily (rockchip64). Patches are adjusted and dts support for nanopis in ayufans kernel is done as well.
     
    https://github.com/chwe17/build/tree/rk3399merge
     
    I would happily give it into 'someone others' hands cause time in the next month might be really rare.
     
    Basically it needs testing on the boards which got newly merged into rockchip64 (don't own any nanopi *4 board so I can't test it). And probably a small helper script to adjust the 'living' boards config so that they'll get updates in the future from their new boardfamily (this might be tricky and needs for sure a lot of testing, to ensure we don't break them)
     
    Would be nice if someone can review it and test it on the nanopis
  11. Like
    chwe got a reaction from hipboi in merge rockchip64 with rk3399   
    I prepared (last weekend? - don't remember anymore) a first step towards a merge of rk3399 (currently nanopi boards) with rockchip64 (more or less all the rest) so that both can be covered fully under one boardfamily (rockchip64). Patches are adjusted and dts support for nanopis in ayufans kernel is done as well.
     
    https://github.com/chwe17/build/tree/rk3399merge
     
    I would happily give it into 'someone others' hands cause time in the next month might be really rare.
     
    Basically it needs testing on the boards which got newly merged into rockchip64 (don't own any nanopi *4 board so I can't test it). And probably a small helper script to adjust the 'living' boards config so that they'll get updates in the future from their new boardfamily (this might be tricky and needs for sure a lot of testing, to ensure we don't break them)
     
    Would be nice if someone can review it and test it on the nanopis
  12. Like
    chwe reacted to TonyMac32 in Daily (tech related) news diet   
    Via hackaday

    Sent from my Pixel using Tapatalk

  13. Like
    chwe got a reaction from TonyMac32 in [RockPro64] Armbian upstream kernel/uboot test?   
    going through the links spotted something for @martinayotte (and maybe @TonyMac32)
     
    https://github.com/archlinuxarm/PKGBUILDs/pull/1691/commits/dfe2881b2eaf32a5b2289005c675888345684fd7#diff-2347b909a334e35e45d31e5bb4961a3f
     
    there's a a patchset for upstream u-boot for the ram part.. as OP says it's not running stable.. but at least they got upstream u-boot up.. maybe worth a look as well.. to clean the rk u-boot mess asap.
  14. Like
    chwe got a reaction from Staars in Proof of concept - Realtek 1295   
    well.. that's one which you can solder without trouble.. @TonyMac32 would probably say I'm wrong.. but I would tin the first pad, press the SPI nor on it and remelt it.. once you have an anchor pad.. the rest is easy..
  15. Like
    chwe reacted to Staars in Proof of concept - Realtek 1295   
    Thanks to all for the recent responses! It helps to keep the motivation above zero and yes, maybe it is time to search for external help.
     
    But now the short guide "how to brick such a box":
    It was not bad luck but active stupitidy.
    Some weeks ago in a mixture of impatience, lack of time and sleep I decided to try out various commands of the u-boot-shell. Before that I had to reflash my box several times, which worked easily and besides I was under the (incorrect) impression, that things like the RPMB were already written to the box by the vendor. That led to a situation of recklessness. 
    So I typed in the command:  m m c  k s (I added additional spaces here to avoid dangerous copy-and-paste-actions!!)
    The I got:
     
    That did not look promising and it turned out to do the bricking.
    The good thing is, that you have to actively kill the box and it should not happen so easy.
    So the general advice of common sense is valid here too: Do not do things in a hurry, read through every available resource before you press enter button!
     
    My last try to recover the box  would be to solder a SPI flash chip onto the PCB and flash it with the REALTEK tool. Can someone provide a hint which chip type could be compatible?
  16. Like
    chwe reacted to Icenowy in Orange Pi One Plus usability ?'   
    @martinayotteI think many board DO explicitly provide the bus-width. Of course, I think many people haven't equipped ECC brain like me, so there could be some boards w/o bus-width.
     
    You can submit patches for mainline for those boards.
     
    The mainline doesn't agree to add bus-width to SoC DTSI because it's for the board's designer to decide the bus-width (of course it cannot go beyond the controller's maximum). For example, some board uses a SD card slot (which is bus-width = <4>) on a eMMC controller (which can be at most bus-width = <8>), and in this case the 4 remaining data lines can even be used as GPIO.
  17. Like
    chwe reacted to GeraltOfTrivia in Orange Pi One Plus usability ?'   
    Sorry to necro an old thread, but I didn't find a more suitable one and I didn't want to start a new one. 
    Anyway, to the point.
    When I install or build any of the Armbian dev/nightly images with kernel 5.x, the sdcard is practically unusable after the installation. 
    hdparm shows read/write speeds of max. 5 MB/sec. The reason is that unless the bus-width for mmc@4020000 is explicitly set to 4 bits in 
    sun50i-h6-orangepi-one-plus.dtb mmc@4020000 { compatible = "allwinner,sun50i-h6-mmc", "allwinner,sun50i-a64-mmc"; reg = <0x4020000 0x1000>; clocks = <0x2 0x43 0x2 0x40>; clock-names = "ahb", "mmc"; resets = <0x2 0x12>; reset-names = "ahb"; interrupts = <0x0 0x23 0x4>; status = "okay"; #address-cells = <0x1>; #size-cells = <0x0>; pinctrl-names = "default"; pinctrl-0 = <0xb>; vmmc-supply = <0xc>; bus-width = <0x4>; cd-gpios = <0xd 0x5 0x6 0x1>; phandle = <0x2f>; }; the bus width defaults to 1 bit as seen in 
    root@orangepi:~# cat /sys/kernel/debug/mmc0/ios clock: 50000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 0 (1 bits) timing spec: 2 (sd high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) which practically cripples the SD card interface. By default there is no bus-width entry in sun50i-h6-orangepi-one-plus.dtb for mmc@4020000. I don't know if this is Armbian specific or not or if this has been mentioned again, I just thought I'd share my findings in case this helps someone. 
  18. Like
    chwe reacted to SvOlli in Very Small Platforms - Rockchip 3308 and Allwinner V3s   
    The changes by "Squonk42" have been integrated into mainline buildroot something like two weeks ago. So if you checkout the current git, you can just build it.
     
    I also did something similar using the external layer feature of buildroot. This keeps custom changes separated from the "official" buildroot, so hacking is a bit more straight forward and migration to a new version of buildroot is easier. It's available at:
    https://git.h8u.de/Allwinner_V3s/buildroot-v3s
    I can also create a mirror on github if anyone is interested in joining in.
  19. Like
    chwe reacted to gufmar in Rock PI 4   
    perfect solution. works fine. thank you!
     
    For thus who try to C&P the above clock-frequency string: Attention it contains non-standard space chars after the number. So compiling to dtb fil fail with an error. Better use
     
    clock-frequency = <400000>;  
  20. Like
    chwe got a reaction from Da Alchemist in sick and tired of my Armbian desktop locking and crashing   
    If I didn't miss something the Rockpro is still marked as wip in the downloadpage right?
     

     
    but well, maybe we should rename it back to wip so that only expert=yes can build images for it.. to make it more obvious..
     
    but also this sub-forum has a nice reminder:

     
    My RockPi 4b was used in a pure CPU numbers crunshing project for 17 days between 75°C and 80°C without any crash.. Would I call the RockPi stable.. for sure not. It seems that it did well for this test but I've no idea if it runs stable under all the other use-cases people can imagine for the board in question.
     
    Just another reminder: https://forum.armbian.com/guidelines
    especially this points here:
     
     
    what makes you sure the powering issues are gone? Did you check voltage on 5v rail after replacing the PSU under stress?
  21. Like
    chwe got a reaction from qblueRed42 in sick and tired of my Armbian desktop locking and crashing   
    If I didn't miss something the Rockpro is still marked as wip in the downloadpage right?
     

     
    but well, maybe we should rename it back to wip so that only expert=yes can build images for it.. to make it more obvious..
     
    but also this sub-forum has a nice reminder:

     
    My RockPi 4b was used in a pure CPU numbers crunshing project for 17 days between 75°C and 80°C without any crash.. Would I call the RockPi stable.. for sure not. It seems that it did well for this test but I've no idea if it runs stable under all the other use-cases people can imagine for the board in question.
     
    Just another reminder: https://forum.armbian.com/guidelines
    especially this points here:
     
     
    what makes you sure the powering issues are gone? Did you check voltage on 5v rail after replacing the PSU under stress?
  22. Like
    chwe reacted to Staars in Proof of concept - Realtek 1295   
    This is only for sake of booting it somehow, but at least:
    _ _ _ | | __ _| | _____ / | | | / _` | |/ / _ \ | | | |__| (_| | < __/ | | |_____\__,_|_|\_\___| |_| Welcome to ARMBIAN 5.77 user-built Debian GNU/Linux 9 (stretch) 4.19.16-rtd1295 System load: 2.81 1.25 0.47 Up time: 2 min Memory usage: 5 % of 1932MB IP: CPU temp: 42°C Usage of /: 15% of 7.1G  
    This is useful for nothing at the moment (no usb, no net, no straightforward installation method), but I am not yet in the state to give up.
    It is a buggy mess at the moment and again I have not uploaded all stuff to my repo.
    To reach this pseudo-success, I had to boot with kernel 4.9.y, then let armbian resize the initial image (which does not work with 4.19.y for whatever reason) and then write the 4.19.-kernel and the DTB to the SD-card. So it is a bit of a click-bait 
     
  23. Like
    chwe reacted to jeanrhum in [brainstorm] ways to test new images   
    I didn't see that page. I will use it for my next tests now!
     
  24. Like
    chwe got a reaction from NicoD in [brainstorm] ways to test new images   
    actually the basics to test are there..
  25. Like
    chwe reacted to Maarti in RockPi 4b 'board bring up'   
    The schematics were upload:
    https://wiki.radxa.com/Rockpi4/hardware