chwe

  • Posts

    1432
  • Joined

  • Last visited

Reputation Activity

  1. Like
    chwe got a reaction from Werner in List of Stuff   
    you guys have to many SBCs...
     
    They dropped cause they no longer wanted to use armbian as a base for their images iirc..
     
     
    Hmm the boards I remember I have..
     
    Beagle bone the white one
    beagle board xM or so, they were from the pre RPi time, I never did much with it..
    opi zero, opi pc+, opi 2g-iot, opi 4g-iot, OPi 3 and OPi with H6 but no USB3 don't even remember the name..
    BPi m2 zero, BPI R2, BPi W2
    RPi 1b (one of the first in switzerland probably...) RPi 2b, somewhere there should be a 3b, and yes I bought a 4b
    RockPi 4b, somewhere there's a RK3399 TV box which I never hacked fully..
    a Olimex Lime 2 (this board looks just like made by people who know what they're doing I would love to see some new boards from them.. )
    and finally a Lichee Pi Zero which runs Debian stretch on a 64mb ram board without issues.. (okay.. I never gave it much workload.. but iirc there was once a python script with logging stuff running on it).. 
     
    okay.. I might have also too many SBCs..
    ahh.. and a Tinkerboard.. they were dirt cheap here back then.. now 2 years later they're doubled the price they had in the beginnings..
     
    The most used one is still the OPi Zero.. it was cheap back then.. and for most of my work sufficient.. The RockPi crushed numbers for 14 days in a row sitting at 75-80°C without issues, I was actually surprised.. cause it was one of the self crafted early images for this board.. The tinker was fun to mess with.. but I never cared about desktop.. so actually this board didn't make much sense for me.. The BPi R2 was a rabbit hole to mess with u-boot, but I learned a lot (network is still crippled).. The W2, I don't know.. it's a strange thingie.. People here do crazy thing to hack TV boxes with the same SoC (actually a cool thread cause not much bloating, so please don't mess there ..).
     
    completely forgot.. there's a HC1 as well,, but this serves as a NAS box I don't mess with, I just does what I expect from a NAS box..
  2. Like
    chwe reacted to 5kft in armbianmonitor cpu-temperature broken? -ge: unary operator expected   
    Hi @Igor, @guidol - in case it is helpful, I took a quick look at this and the fix is pretty straightforward.  Essentially all that needs to be done is to remove the existing "patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch" for 5.1, and to port over the 4.19 "patch/kernel/sunxi-next/ths-29-add-correct-h5-thermal-zone.patch" to 5.1 (i.e., bring into "patch/kernel/sunxi-dev/").  The problem is the currently the thermal-zone is defined in the wrong DT location, and the zone definition and tips  and cooling maps are incorrect/incomplete for the 5.1 version.
     
    I did a quick test of fixing it this way and the result works:
    root@nanopineo2:~# cat /proc/version Linux version 5.1.15-sunxi64 (root@elrond) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.90.190705 SMP Thu Jul 4 14:05:17 UTC 2019 root@nanopineo2:~# cat /sys/class/thermal/thermal_zone0/temp 40936 root@nanopineo2:~# I'd fix this and submit the change myself, but unfortunately I don't have time to be thorough about testing it right now (e.g., verify on some H3 boards and other H5 boards as well), and likely won't be able to until next week...I'm happy to do this then if you don't have time to look into this.
  3. Like
    chwe got a reaction from Jens Bauer in Raspberry Pi 4 Released - From $35 USD   
    FYI:
     
    asked about ext4 support for boot to get rid off the FAT partition:
    https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=243890&p=1487617#p1487617
    seems not of importance for them..
     
    some charger issues:
    https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=244146
    and a nice link provided there:
    https://www.scorpia.co.uk/2019/06/28/pi4-not-working-with-some-chargers-or-why-you-need-two-cc-resistors/
    as with more or less every boardmaker, things are not mature in the beginnings.. But at least some of the flaws will likely be fixed over time..
     
     
     
  4. Like
    chwe got a reaction from Igor in Raspberry Pi 4 Released - From $35 USD   
    https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=244166

     
    if you ever look for a textbook example of whataboutism.. There you go. We need some more HackRF boards to target all those CRT displays in the wild..
     
  5. Like
    chwe got a reaction from gounthar in Raspberry Pi 4 Released - From $35 USD   
    I couldn't less agree on this one..
     
    It is a TV box SoC with schematics.. It might not matter if you only consume and someone else provides the images.. But it matters if you're on the other side. You (mostly) know what you get, whereas TV boxes sometimes change depending on what is cheaper at the moment (e.g. different wifi module, NAND instead of eMMC etc.).
     
    well.. IMO it was RPi who had to respond.. all those RK3399 based boards crushed the RPi fully..
     
    I assume we'll see more specialized SBCs in the future. e.g. https://www.cnx-software.com/2019/06/19/rock-pi-s-tiny-sbc-rockchip-rk3308-processor/
    some NAS ones etc.
     
    Indeed it is the first RPi since v2 which doesn't look annoying. They try their first step away from VC4 which might be interesting.. I don't get this (claimed) full backwards compatibility of images. IMO it was a good opportunity to make a cut (keep, pin-compatibility etc. but craft an image which is either fully armhf - or arm64). having a VC4 and a VC6 branch of raspian is something the majority of their believers would probably accept.
     
    I will likely buy one (will be the first one I bought after the Pi2 IIRC), I've a project where the A72 cores might shine, and if thermals are somehow controllable passively, 4xA72 for 35$ looks good to me (don't need really much ram for this project, it's really about numbers crunshing). They did a couple of things right, e.g. SPI NOR, USB-C instead of microUSB (btw it's a 'dumb' one right? so no PD), even the double HDMI was IMO a smart move (now it's somehow unique to its competitors). And from the software side I'm quite sure things will mature over time (looking forward to the PXE, my project would really benefit from a proper PXE implementation), and we'll soon get some deeper insights from people experienced in kernelcode.. E.g.
    https://www.cnx-software.com/2019/06/24/raspberry-pi-4-features-broadcom-bcm2711-processor-up-to-4gb-ram/#comment-563948
     
    But I don't think that 'chinese' (whatever that means) have to respond. For different use-cased several companies have a good line-up, and the user group they target is often different.
     
    It was a needed, and from the first glace well crafted update of the (IMO) complete failure called RPi3b+. I was surprised by the 4xA72 core they've chosen and the 1,2 and 4 GB ram was smart too. Let's face it, the average 'rich' user will always opt for the 4GB variant no matter he needs it or not and I assume the profit margin will be slightly higher with this variant.
     
     
  6. Like
    chwe reacted to Staars in Proof of concept - Realtek 1295   
    Just a small update on the kernel side.
     
    I uploaded all my latest local changes for the kernel tree 4.19.y (= 4.19.55), so you can build it (DEV) from my repo. But don't get too excited, it will not really work.
    This is only meant for further developing and hopefully some more skilled kernel-hackers can take look. There are some backports (for instance android/staging) and all API-changes were done according to the compiler output and the following internet search, so the process included traces of cargo-cult-programming. Expect stupid bugs here and there.
     
    Expected behaviour:
    A boot-log with surprisingly few errors but the inability to have a root device . The console output will stop and after while you should see a kernel error.
    Disabling usb or ahci or sd or mmc drivers (or combinations) will change the error slightly. It seems, as if there is always a DMA-problem, but that might be coincidence.
     
    I simply do not know, if there is just one wrong line of code somewhere or if the whole construction is lightyears away from working.
     
    Happy hacking!
  7. Like
    chwe reacted to Staars in Proof of concept - Realtek 1295   
    Now everything is totally clear :
     

  8. Like
    chwe got a reaction from Slackstick in Raspberry Pi 4 Released - From $35 USD   
    I couldn't less agree on this one..
     
    It is a TV box SoC with schematics.. It might not matter if you only consume and someone else provides the images.. But it matters if you're on the other side. You (mostly) know what you get, whereas TV boxes sometimes change depending on what is cheaper at the moment (e.g. different wifi module, NAND instead of eMMC etc.).
     
    well.. IMO it was RPi who had to respond.. all those RK3399 based boards crushed the RPi fully..
     
    I assume we'll see more specialized SBCs in the future. e.g. https://www.cnx-software.com/2019/06/19/rock-pi-s-tiny-sbc-rockchip-rk3308-processor/
    some NAS ones etc.
     
    Indeed it is the first RPi since v2 which doesn't look annoying. They try their first step away from VC4 which might be interesting.. I don't get this (claimed) full backwards compatibility of images. IMO it was a good opportunity to make a cut (keep, pin-compatibility etc. but craft an image which is either fully armhf - or arm64). having a VC4 and a VC6 branch of raspian is something the majority of their believers would probably accept.
     
    I will likely buy one (will be the first one I bought after the Pi2 IIRC), I've a project where the A72 cores might shine, and if thermals are somehow controllable passively, 4xA72 for 35$ looks good to me (don't need really much ram for this project, it's really about numbers crunshing). They did a couple of things right, e.g. SPI NOR, USB-C instead of microUSB (btw it's a 'dumb' one right? so no PD), even the double HDMI was IMO a smart move (now it's somehow unique to its competitors). And from the software side I'm quite sure things will mature over time (looking forward to the PXE, my project would really benefit from a proper PXE implementation), and we'll soon get some deeper insights from people experienced in kernelcode.. E.g.
    https://www.cnx-software.com/2019/06/24/raspberry-pi-4-features-broadcom-bcm2711-processor-up-to-4gb-ram/#comment-563948
     
    But I don't think that 'chinese' (whatever that means) have to respond. For different use-cased several companies have a good line-up, and the user group they target is often different.
     
    It was a needed, and from the first glace well crafted update of the (IMO) complete failure called RPi3b+. I was surprised by the 4xA72 core they've chosen and the 1,2 and 4 GB ram was smart too. Let's face it, the average 'rich' user will always opt for the 4GB variant no matter he needs it or not and I assume the profit margin will be slightly higher with this variant.
     
     
  9. Like
    chwe reacted to martinayotte in Trial to merge UBoot for RK3399 and Rockchip64   
    I was preparing myself to struggle again with this issue ...
    But in the meantime, upgrading first all my RK3399 to 5.1.y, I've discovered that we have random eth0 MAC on few ones (I didn't check this in past months, since I mostly running all those on WiFi) :
    The discovery is that random MAC are present on v2019.04, but not in Ayufan's v2017.09. It was missing the ethernet0 alias, I've added it, but it didn't fixed the issue...
    The sad thing is that is on the wrong side of the fence : if the issue were in v2017.09, I wouldn't bother trying to fix it, but it is under v2019.04 ...
    I don't have any other idea for now ...
  10. Like
    chwe got a reaction from TonyMac32 in Very Small Platforms - Rockchip 3308 and Allwinner V3s   
    the RPi isn't a board I look long enough to it.. Glue it together and hopefully you don't have to spend more time with it at all..
     
     
  11. Like
    chwe got a reaction from gounthar in Very Small Platforms - Rockchip 3308 and Allwinner V3s   
    remember those dirt cheap android sticks you could buy years ago? The MK802.. I knew that I bought one years ago.. but didn't know for a long time that they're equipped with a AW A10... http://linux-sunxi.org/Rikomagic_mk802
     

     
    Well, seems that they're supported in mainline (u-boot and kernel).
     
    __ __ _ _____ ___ ____ | \/ | |/ ( _ ) / _ \___ \ | |\/| | ' // _ \| | | |__) | | | | | . \ (_) | |_| / __/ |_| |_|_|\_\___/ \___/_____| Welcome to Debian Stretch with Armbian Linux 5.1.7-sunxi System load: 2.26 1.12 0.43 Up time: 2 min Memory usage: 4 % of 999MB IP: CPU temp: 11°C Usage of /: 4% of 30G ... root@mk802:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 21:44:11: 1008MHz 1.57 82% 30% 20% 0% 30% 0% 11.6°C 21:44:16: 1008MHz 1.68 19% 19% 0% 0% 0% 0% 10.9°C 21:44:21: 1008MHz 1.55 13% 13% 0% 0% 0% 0% 11.4°C 21:44:27: 1008MHz 1.42 22% 21% 0% 0% 0% 0% 11.2°C 21:44:32: 1008MHz 1.31 17% 14% 1% 0% 0% 0% 11.6°C 21:44:37: 1008MHz 1.20 21% 20% 0% 0% 0% 0% 11.0°C 21:44:43: 1008MHz 1.11 13% 13% 0% 0% 0% 0% 8.5°C well the thermal is a bit sloppy.. in fact the SoC was roughly 60°C at this time...
     
    and soldering UART to test points isn't as fun.. but it works
     
    and now imagine this board with sata instead of HDMI wired out.. (well maybe with the A20 instead of A10)..
  12. Like
    chwe got a reaction from TonyMac32 in Very Small Platforms - Rockchip 3308 and Allwinner V3s   
    remember those dirt cheap android sticks you could buy years ago? The MK802.. I knew that I bought one years ago.. but didn't know for a long time that they're equipped with a AW A10... http://linux-sunxi.org/Rikomagic_mk802
     

     
    Well, seems that they're supported in mainline (u-boot and kernel).
     
    __ __ _ _____ ___ ____ | \/ | |/ ( _ ) / _ \___ \ | |\/| | ' // _ \| | | |__) | | | | | . \ (_) | |_| / __/ |_| |_|_|\_\___/ \___/_____| Welcome to Debian Stretch with Armbian Linux 5.1.7-sunxi System load: 2.26 1.12 0.43 Up time: 2 min Memory usage: 4 % of 999MB IP: CPU temp: 11°C Usage of /: 4% of 30G ... root@mk802:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 21:44:11: 1008MHz 1.57 82% 30% 20% 0% 30% 0% 11.6°C 21:44:16: 1008MHz 1.68 19% 19% 0% 0% 0% 0% 10.9°C 21:44:21: 1008MHz 1.55 13% 13% 0% 0% 0% 0% 11.4°C 21:44:27: 1008MHz 1.42 22% 21% 0% 0% 0% 0% 11.2°C 21:44:32: 1008MHz 1.31 17% 14% 1% 0% 0% 0% 11.6°C 21:44:37: 1008MHz 1.20 21% 20% 0% 0% 0% 0% 11.0°C 21:44:43: 1008MHz 1.11 13% 13% 0% 0% 0% 0% 8.5°C well the thermal is a bit sloppy.. in fact the SoC was roughly 60°C at this time...
     
    and soldering UART to test points isn't as fun.. but it works
     
    and now imagine this board with sata instead of HDMI wired out.. (well maybe with the A20 instead of A10)..
  13. 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..
  14. 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..
     
     
  15. 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.
     
     
  16. 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..
     
     
  17. 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..
     
     
  18. 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.
  19. 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 ).
  20. 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 )
     
  21. 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..
     
     
  22. 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
  23. 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
  24. Like
    chwe reacted to TonyMac32 in Daily (tech related) news diet   
    Via hackaday

    Sent from my Pixel using Tapatalk

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