Jump to content

Willy Moto

Members
  • Posts

    41
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Willy Moto reacted to jernej in Allwinner H6   
    No, but I'm in contact with few of them. In fact, my job has nothing to do with Linux, although this will probably change in near future. It's just a hobby for getting some experience with developing various Linux drivers and learn how things work nowadays. You won't see me writting userspace apps, except for testing purposes or improving existing code which use drivers I'm working on.
     
    I follow few tutorials for character devices on net. But I find it easier to study existing drivers, especially if working on something new. Linux has well documented common code and there is a ton of helper functions. Reading various slides from presentations of particular subsystem also helps. You have to find the method which works for you.
    There is no single source for that either. Also depends what you mean by reverse engineering. Nowadays there is BSP linux source which means you just have to understand that code, but many times even this is not an easy task. But if you mean hard core reverse engineering, like analyzing binaries and trying to understand what they do, that's another beast entirely. It helps if you learn assembly language for target system, read a lot of tutorials, guides, etc. If you can solve various crackmes, then you're already better in this than most people. But truthfully, you really don't need that to be good kernel developer. However, I already found few interesting things that way, because Allwinner hid some things in binaries which were later linked in driver directly.
  2. Like
    Willy Moto reacted to TRS-80 in So, you want to run a file server?   
    This is not so much a 'Tutorial' or a 'Review' as it is an overview (and/or starting point for further research) of some things to consider when setting up a file server, some in general and then some more particular to SBC.
     
    In the simplest case, you could attach almost any drive to almost any board, by any number of ways, and you have yourself 'a file server.'  However with even a small amount of effort, there are so many better ways to do things nowadays.  We have a lot more interesting hardware choices, advanced filesystems, etc. and so those are mostly what I want to talk about.
     
    But first, some context.
     
    Dedicated distros vs simple directory sharing
     
    Personally I am not a fan of dedicated distros like FreeNAS, OMV, etc. as I consider them to be too 'heavy weight' and single solution specific.  I mean, if you need some/all of those features, or you like them or whatever, then great, use them.
     
    However, a 'file server' is one of the simplest use cases of a 'server' and I am sure one which almost everyone buying a SBC will do at some point.  IMO, all one needs to do is simply share some folder(s) via either NFS (if your network is mostly GNU/Linux machines) or Samba/SMB (if your network is mostly Windows machines).  And that's it, you're done!  Simple, lightweight, and using standard protocols (well, a little less 'standard' in case of Windows, but I digress ).
     
    You could also add any of the software included in the 'all in one' solutions in first paragraph on a 'piece by piece' basis, if/when you need them.  Personally I am more of a fan of starting small (vanilla Armbian base) and then adding things you need one by one.  But you are of course free to do whatever you want.
     
    Setting any of that up, or debating about it, is considered off-topic for this thread, as there are tons of resources already around the Internet about those things.  So I want to focus on other, (IMO) more interesting, aspects.  You are welcome to make your own thread with a different focus, of course.
     
    Important note about hardware RAID
     
    RAID, in case you were unaware, means "Redundant Array of Independent Disks."
     
    For a looooooong time, I (and I think many others with SOHO NAS perspective) thought that 'hardware RAID was the only proper way to do it' but in the course of researching ZFS I eventually became convinced otherwise.  In fact, apparently, historically 'big-iron' filesystems (Solaris, others) were always run with software RAID in the enterprise as there are a lot of advantages to that.
     
    Just think about it.  If your hardware RAID card dies, you need to replace it with exactly the same model, before you can even begin to recover your data.  With software RAID, you just re-connect drives and you are back in business (with ZFS, you can even connect them in any random order, amazing!).
     
    In particular if you are using ZFS, hardware RAID controllers are not recommended.  I am not sure how much this applies to other similar software RAID systems, but it would stand to reason that it does (IMO).
     
    Hardware controllers are also typically very expensive and proprietary.  Where software RAID uses readily available and inexpensive commodity hardware (while actually increasing reliability).  All of which is why I have become such a big fan of it, whether we are talking about ZFS (which I like) or some other software RAID solution you may prefer instead.
     
    Now, with that out of the way, onward!
     
    Filesystem
     
    Assuming you came to similar conclusions as I did in previous section already, this is where our decision making process really begins in earnest IMO.  As the way I see it, choice of file system will dictate topology, which will in turn dictate choice of hardware (which SBC to buy).
     
    Of course if you already bought some SBC, you are in a different boat (and working backwards, from my point of view ).  Anyway, you will have to adapt accordingly (and/or buy different hardware).  However, if you are already there, go to 'Historical Overview' section, and maybe you can find some solution there which will work with the hardware you already have.
     
    Now, back on track, we are really lucky nowadays, thanks to F/LOSS, to have some industrial grade, software based filesystems available to us mere mortals! 
     
    I like ZFS, but certainly, opinions will differ.  Some people like btrfs, in fact I got into a lengthy (but IMO informative) debate with @tkaiser about that.
     
    Then there are other distributed things like Ceph (and others) which I will admit to knowing less about.  If you do, kindly add your thoughts to the thread when you have a moment.
     
    Point being, hardware setup for someone like me (using ZFS) or even someone using btrfs will be perhaps quite different than someone using something distributed like Ceph.  Just keep that in mind.
     
    Historical Overview (SBC Hardware)
     
    I want to cover some of things which came before, as I think they are relevant to understanding where we are today.
     
    In the beginning, there was darkness.  Wait, let me fast forward a bit. 
     
    I will start with the creation of Armbian.  Which happened, in fact, because Igor was trying to set up a file server on a cubietruck.  True story (and like I said, you are not alone, this is a common use-case)!    Anyway, many of us bought (A20 based) cubietruck back then, because they sold a small power adapter board which made this easy and they also had a SATA connector right on the board.  I think they were one of first to do this in fact (I could be wrong).
     
    After that, a lot of us used (more powerful Samsung Exynos5 based octo-core) ODROID-XU4, along with a good quality USB to SATA adapter with UASP.  That one in particular was recommended by tkaiser a long time ago, however -- as of time of writing this post -- PINE64 still sell it in their store(!).  And it may be an 'okay' solution if you have some (especially, USB3 capable) board laying around that you just want to use.  Some people are still using this today.  But we have a lot better options now.
     
    Then RK3399 came on the scene.  Which was very exciting, because these support not only PCIe, but they are also 64-bit (which is required for ZFS).  Unfortunately, it took literally years for these to become really stable.  Lucky for you, this is all in the past by now.  And so, currently, many people will probably recommend RK3399 as a file (or other) server.
     
    There are a lot of other boards out there, which I do not have as much experience with.  But I also try to note only historically significant developments here (at least the way I see them).  If you have any to add, please comment below or contact me somehow (PM or IRC) and I will edit this post and add them.
     
    Usage (other than file server)
     
    As I already stated, almost any cheap board can be a (minimal) 'file server.'  From that point of view, more powerful boards (like RK3399, or others) are overkill.  However maybe you want better throughput.  Or more disks.  Or, like me, you want to run advanced filesystem like ZFS (also with more disks).
     
    Another thing which happens is that, once you handle the simple case of serving files, before you know it you will probably want to start doing more than that.  You may already have some more demanding requirements in mind beforehand.
     
    For all these reasons, a slightly more powerful (and more expensive) board may be a better choice, as you will not be limited in the future.  But if you are very sure about your needs and wants, and have perhaps other boards on your network to handle processing intensive tasks, this may not apply to you.  Just something to consider.
     
    Hardware Recommendations (RK3399 based)
     
    For reasons mentioned at end of 'Historical Overview' section, many of us are fans of RK3399 based devices nowadays.
     
    Within this subset, you will get a lot of opinions.    I know because I spent literally years asking people (including developers), while I was waiting for RK3399 to mature.  Some developers think certain vendors make crappy hardware (and maybe they are right).  Or they prefer the boards they know and develop on (naturally, IMO).  Some vendors support the project a lot more than others (PINE64, notably, do not support Armbian at all to my knowledge).  So you will have to do some amount of your own research, and form your own opinion here.
     
    I don't want to discount any of the above criteria too much.  However, in the end, at least for me, one criteria bubbled to the top.  And that was direct PCIe (or SATA) support.  Since we are talking about RK3399 here, this means PCIe support.  Which of course is in the SoC, but that is not what I am talking about.  I am talking about putting a standard PCIe physical interface directly on the board.
     
    This way, you can buy any standard cheap/dumb PCIe to SATA adapter card.  You can keep spares.  You will be able to obtain them for the foreseeable future.
     
    By contrast, you can certainly rig up your own adapters, cables, etc. from GPIO.  But personally, I find that fiddly and it doesn't strike me as the most reliable.  I know some people are doing this just fine though.
     
    Another way, is that many vendors sell some sort of HAT, which provides SATA connectivity.  However I find this short-sighted and -- quite frankly -- self-serving.  What if they are out of stock, or stop making them?  You are out of luck.  Or you would need to revert to the above option (rigging up cables and adapters).  It's good for them selling add-on hardware though I guess -- hence my 'self-serving' comment -- but maybe not the best for you and me in terms of keeping our important data available and up and running, on a long term basis.
     
    Therefore I say, skip all of that and go with a board that has a standard physical PCIe right on the board.
     
    ROCKPro64
     
    And AFAIK, there is only one (standalone SBC) RK3399 that meets that description, which is ROCKPro64.  Of course, I am not the first to come to same conclusion, in fact there is a whole thread where myself and some other like-minded folks discuss using ROCKPro64 as NAS.
     
    I say 'standalone SBC', because I almost forgot...
     
    Helios 64
     
    These of course are no longer made, and Kobol, our once partners, have unfortunately closed up shop.  However they still come up for sale on the forums from time to time (usually in Kobol Club but could be anywhere).
     
    Here you would be getting a more integrated solution, often including a nice case, for perhaps a bit more money.
     
    Some people have had problems with stability though, which I am not sure were ever fully worked out.  Have a look through Kobol club (linked above) and form your own opinion.
     
    Hardware Recommendations (not RK3399 based)
     
    ODROID HC4
     
    ODROID HC4 was also brought up today, when this subject came up in IRC, by @rpardini as that is what he uses.  This is an interesting alternative to the above, except Amlogic (S905X3) based (like a lot of TV boxes).  Which to me means two things:
     
    1. It almost certainly requires blobs.
    2. It's probably cheaper than RK3399.
     
    Well in fairness ROCKPro64 probably requires some blobs, too.  But somehow I get the impression that Amlogic are really obnoxious with their blobs, and I am not a fan of them as a company because of this.  Surely a developer will need to correct me here. 
     
    Anyway, I am not sure how it compares in processing power.  I suspect less than RK3399(?).  However for media transcoding, it may actually be better (perhaps hardware decoders(?), speculation on my part).
     
    Also for simple 'file server' use-case, in particular with Ceph or something like that, it becomes more interesting IMO.  Again, quoting rpardini from IRC today: "scale out, not up."
     
    Future
     
    There are newer SoCs, like RK3566 and others.  At this time, they are a lot like RK3399 was early on.  Very exciting, but not able to realize their full potential due to lack of (software/Linux) development.
     
    The consensus among developers seems to be that RK3566 development should go faster/easier than RK3399 development, because of all the ground work that was laid in the course of the latter.  Maybe that's true, but we are still talking about some time.  Maybe less years, but still significant time.
     
    If/when this changes, I will try and remember to update the post.  Feel free to ping me by posting, I should get notified.
     
    Others?
     
    Possibly anything in NAS category.  Which I mostly covered already (above, in more detail) but can always change in future.
     
    Certainly I forgot (or don't know about) some others.  I have shared what I learned from my research the last several years while looking for solution for myself.  However I do want to make this a more general resource that we can all point to, so please discuss, and I will be happy to edit this post later on and add relevant info.
     
    To clarify, I am not talking about 'any SBC which can be made into a file server' which is almost any of them, but rather particular hardware which is interesting for some specific reason(s), especially currently (or perhaps historically, which I would add to that section).
     
    Cheers!
     
     
  3. Like
    Willy Moto reacted to awawa in Allwinner H6   
    TX6 design summary and of course new release.
    Today was the day I decided to promote the TX6 as a my main native ARM development center. This brought some improvements and I finally decided to open it. There were no screws, just plastic snaps.

    It seems that the manufacturer tried to improve the thermal characteristics of this device. On the right side: a flat metal block and a plastic mass.
    At first I removed them but to my surprise the temperatures were worse. So this thermal bridge helps somehow.
    The next step was to drill a few holes at the bottom and turn the box upside down (which meant putting it back in its "right" position). I also included some new rubber feet on the "new" bottom.
    The box is cooler now, but the idle CPU temperature remains the same (it's better under load and the temperature returns to normal very quickly when the load is gone). So probably the TX6 design is not as flawed as I thought and the high temperature must be for some other reason.



    I've managed also to enable installation on the eMMC storage: the installer works now without errors and uboot's DTS was updated in bit different manner (from Aarch DTS patches).
    The speed is not great:


    Images are being uploaded:
    https://github.com/awawa-dev/build/releases/tag/v2022.03.08
  4. Like
    Willy Moto reacted to awawa in Allwinner H6   
    @Pic55 These are the same errors as earlier: now they disappear so fast that I didn't notice them too.
    I just uploaded new experimental undervoltage image to the release (switch voltage table designed for better CPU batch). Seems safe jugging by some old alternative patches but can't guarantee it.
    As a "side-effect" 1.8GHz works now. Still need to test it in long-term.
  5. Like
    Willy Moto reacted to MBB in Allwinner H6   
    The doc I posted a few days ago in this thread on building from mainline includes a patch to fix eMMC and everything is fully documented there.  I use it and it works well.  I find these boxes are far more responsive when running from eMMC vs SD. Plus, it frees up the SD slot for use as a removable storage device.  Or, if you install something like Balana Etcher, it can even flash it's own images from a URL.  We provide our products pre-flashed to eMMC so they are ready to plug in and use.  
     
    With the patch, you can boot from SD and flash eMMC using armbian-config in the usual way (basically, take the first option all the way through the menus and it will start).
  6. Like
    Willy Moto reacted to awawa in Allwinner H6   
    My repo is back. With new release of course Bump Kernel to new 5.15.25 and include all valid for us LibreElec patches after their review. https://github.com/awawa-dev/build/releases/tag/v2022.02.24
    The fork is now linked to armbian:master and it is ahead by 1 commit that contains all my changes. It will be easy to refresh origin with future Armbian upstream changes.
    Unfortunately for us tvboxes have a low priority for mainline development: few patches that are included in Armbian probably for other SCBs, prevent Tanix TX6 from booting or they are causing unstable behavior so I needed to exclude them. So that board needs to have its own patch repository (99% armbian patches included and most of LibreElec).
  7. Like
    Willy Moto reacted to MBB in Allwinner H6   
    @awawa Great news you are switching to mainline.  It will be fantastic to have someone maintain a Tanix H6 build again!  THANK YOU FOR SHARING ALL YOUR WORK ON THIS!
     
    On a somewhat related topic, I am working with a manufacturer in China to (hopefully) sell the Tanix-compatible T95 Mini under a new name to avoid confusion, with EMMC, preflashed with Armbian so ready-to-use out of the box.  If anyone is interested in such a product, please let me know.  @awawa's repo works flawlessly.
     
    For anyone considering a Tanix-compatible box, I highly  recommend the T95 Mini (with EMMC - often these get shipped with NAND unless you check and they understand what you are even asking ).  The reason why we like the T95 Mini is it seems to run cooler than any other compatible model.  It is also really small and inexpensive.
     
    Thanks again @awawa!
  8. Like
    Willy Moto reacted to jernej in Allwinner H6   
    Few differences I see:
    - different drive strength for wifi (lower than TX6) - not that important
    - slightly different eMMC settings (lower frequency, etc) - might be important
    - different IR key codes (nothing surprising)
    - it seems that slightly different LED display driver is used (can't be sure unless I see detailed PCB photo)
    - T95 max has slightly higher DRAM frequency (672 MHz) vs. TX6 (666 MHz)
    - different DRAM config, but it's unclear how much they influence stability
  9. Like
    Willy Moto reacted to awawa in Allwinner H6   
    @danboid Haven't tried dis/reconnecting HDMI yet. MATE version will be uploaded.

    New version for Tanix TX6 (Allwinner H6):
    https://github.com/awawa-dev/build/releases/tag/v2022.02.17
     
    Changelog:
    Add support for OpenVfd LED clock (service is disabled on default) upgrade current branch to: 5.15.24 include 4k60 H6 fix from LibreElec update current(5.15) Armbian patches include drivers for RTL8822CS  
    To enable LED clock service execute these commands:
     
    sudo systemctl enable openvfd sudo systemctl start openvfd  
  10. Like
    Willy Moto reacted to awawa in Allwinner H6   
    New build has just released and images are uploading. I've included now almost all new Kernel patches from official Armbian (a lot of changes for cedrus, sound mixer and media components): only these related to DTB/DTS and causing TX6 instability are excluded but they are not related to your subject. So @danboid in my opinion you can treat it almost as generic Armbian release in your straggling with accelerated ffmpeg. Can't help much more than that. Previous releases were primary targeting vanilla mainline Kernel using just few old balbes150 patches till I figured out where are the problems with current Armbian patches. Now I know why support for that board will probably never reach even Armbian's CSC level. I don't have a plan for sid release.

    I think that's the last build for Tanix TX6 H6 till next major Kernel upgrade appears as everything seems OK now.
    https://github.com/awawa-dev/build/releases/tag/v2022.02.14
  11. Like
    Willy Moto reacted to awawa in Allwinner H6   
    @danboid I've got something even better Support for 5.15 kernels, with kernel sources and headers packages this time.
     
    There is a nasty bug (or let's rather say: something incompatible with TX6) introduced with the mainstream kernel 5.15 sunxi that completely breaks eMMC, introduces I/O instability and causes high CPU usage as sideeffect: FIXED.

    Release (Tanix TX6, Allwinner H6, AC200/XR819 network cards):
    https://github.com/awawa-dev/build/releases/tag/v2022.02.12
  12. Like
    Willy Moto reacted to TonyMac32 in Is "Asus Tinker Board 2" supported by Armbian?   
    I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU.  I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver.  Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant.
     
    @JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall.  The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design.  Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade.
     
    I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.
  13. Like
    Willy Moto reacted to jock in CSC Armbian for RK322x TV box boards   
    @dotbg Some boxes with rk3566/rk3568 are sold with 8GB (gigabytes) of RAM. That chip is capable to address such amount of ram, yet you have to trust the chinese manufacturers and vendors that they really put 8Gb of RAM in the box
     
    rk322x instead is not able to go above 2GB (gigabytes). Everything beyond on a rk322x is surely fake.
  14. Like
    Willy Moto reacted to NicoD in Armbian 22.02 (Pig) has been released!   
    And here the video I made about the new release.
     
  15. Like
    Willy Moto reacted to TRS-80 in Armbian 22.02 (Pig) has been released!   
    https://www.armbian.com/newsflash/armbian-22-02-pig-release-announcement/
     
    Please promote, share, etc. on social media!
     
     
  16. Like
    Willy Moto reacted to Heisath in Armbian 22.02 (Pig) Release Thread   
    Release Candidate Code Freeze Date: 2022-02-14
    Release Planning Meeting Date:  2022-01-29 14:00 UTC+1 
    Release Planning Meeting Location: Armbian IRC
    Release Date: 2022-02-28
    Release Branch Link: https://github.com/armbian/build/tree/v22.02
    Release Changelog:
     
     
    Release Coordinator: @Heisath and hopefully some new person on the team
     
    Already creating this release topic for 22.02, to discuss upcoming changes, no longer maintained boards and help new people get into the release / maintain flow.
     
    Current steps:
    - Refine supported/WIP/CSC/etc. board status
    - Update maintainer list
    - Onboard new maintainers / contributors
    - Move Jira issues to new release
    - Select release name 
     
    @Igor @Werner @TonyMac32 @martinayotte @piter75 @ning @Myy @balbes150 @sfx2000 @ebin-dev @chwe  @gprovost @aprayoga @lanefu @5kft @JMCC @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @tony013  @rpardini
     
    Pls. ping developers I forgot  
  17. Like
    Willy Moto reacted to jernej in Allwinner H6   
    @danboidif you prefer, we can continue our discussion here.
     
    Note, mesa has nothing to do with HDMI plug detection. GPU is distinct core from display engine (that's why you have two dri cards present). I would say it's X11 issue, but then, I have no experience with it on H6.
     
    Regarding LED driver - you might make it work with above repo, but then there is easier way, at least if you have some python programming knowledge. I recently added a node for LED display in DT and it will debut with kernel 5.17:
    https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi#L32-L38
     
    Once you have that in DT, together with enabled i2c-gpio and i2c-dev drivers, you can play with LED display as much as you want. For example, with python script using python-periphery library:
     
    from periphery import I2C i2c = I2C("/dev/i2c-0") # adjust path as needed msgs = [I2C.Message([0x03], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x24, msgs) # enable display msgs = [I2C.Message([0xff, 0x67, 0x63, 0x63, 0x47], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x33, msgs) # set LEDs i2c.close()  
    Note, that ignore NAK flag is important. FD650 LED driver is not exactly your standard I2C device.
  18. Like
    Willy Moto reacted to andreq in Chinese A20 Android Tv Box   
    For the record, I got the nand boot working. Was way simpler than I expected.
     
    Got a Nand Lubuntu image from here http://dl.cubieboard.org/software/a20-cubieboard/lubuntu/cb-a20-lubuntu-12.10-v1.06/
    Used PhoenixCard to send it to a spare SD card.
    Booted from this card and it installed itself to Nand (yaay !)
    Booted from my first SD Card and ran nand install script.
    Everything went as expected, it booted form nand a minute ago !
     
    I'm currently loged in, wirelessly, without any SD card.
     
    Thanks again for the images and forum. I found a lot of information and I wouldn't be that far without it.


    Little google keywords for anyone looking for some help with this box  :  TXCZ_A20_V3.0  TXCZ_A20 V3  debian linux nand img firmware 
  19. Like
    Willy Moto reacted to jernej in t95 allwinner h616 armbian   
    T95 needs different configuration of DRAM driver. Quick and dirty T95 U-Boot port with appropriate defconfig can be found here: https://github.com/jernejsk/u-boot/commits/t95
  20. Like
    Willy Moto reacted to jock in CSC Armbian for RK322x TV box boards   
    Multitool update!
     
    Hello! I'm pleased to announce that multitool finally got network and SSH access, and now can be used on headless systems!
     
    The latest release will retrieve an IP from the network DHCP server automatically, so you can consult your local network router to discover what IP the box got.
    SSH access can be obtained logging in as root user; no password is requested.
    Example with IP 192.168.1.18:
    paolo@predatorg:~$ ssh root@192.168.1.18 Welcome to Multitool SSH session! root@multitool:~#  
     
    Link-local access:
     
    Multitool will also, by default, listen to link-local 169.254.120.120/16 address. This is useful if you have no DHCP server or have troubles retrieving the IP address.
    Note that to access such private IP you need to set a network interface of your PC on the same subnet, or also use a virtual interface.
     
    Here there is an example using ip assigning address 169.254.89.32/16 to virtual interface eth0:1 (address can be changed at your pleasure, interface must be the same interface you use to access the box, ie: wlan0, enp0s25, or whatever):
    ip addr add 169.254.89.32/16 brd + dev eth0 label eth0:1  
    or if you prefer old but good ifconfig:
    ifconfig eth0:1 169.254.89.32/16  
    then the multitool is accessible to 169.254.120.120:
    paolo@predatorg:~$ ssh root@169.254.120.120 Welcome to Multitool SSH session! root@multitool:~#  
    Of course link-local access won't work if you have multiple devices running multitool on the same network, since all of them will conflict because they have the same IP; in such case use the IP provided by DHCP.
  21. Like
    Willy Moto reacted to danboid in Allwinner H6   
    So it is! I've found it now:
     
    https://github.com/150balbes/build
     
    I shall try that later. Hopefully there is a 5.14+ kernel available (5.15?).
     
    That 5.15 sunxi64 kernel package I posted in my previous post does install and boot on Armbian running on my T95 MAX but the onboard LAN doesn't work OOTB like your H6 kernel . Hopefully it's just a case of me working out which kernel module I need to load to enable it?
  22. Like
    Willy Moto reacted to Igor in OrangePi Zero2 - Allwinner H616   
    Merged.
    https://github.com/armbian/build/pull/3236
    Test image:
    https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.11.0-trunk.53_Orangepizero2_impish_edge_5.15.1.img.xz
  23. Like
    Willy Moto reacted to Werner in Most powerful SBC running Armbian for distributed computing ?   
    Great choice. I had one myself but somehow managed to kill it
    Even made a custom fan hat for it. If you are interested reading my jabbering about this board take a look here: https://zuckerbude.org/nanopi-r4s-router-overkill/
     
    Another board with RK3399 that is fairly cheap are for example the quite recently released OrangePi 4 LTS (where LTS stands for 'we had to change the network chip due to shortage and simply call it LTS for no reason like we always do').
  24. Like
    Willy Moto reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @MarcoFdN
    Yes, armbian-config is not included in any Armbian minimal releases (not just mine), because if it was it would not be minimal  anymore: armbian-config requires lots of dependencies and, for this reason, it is undergoing a vast refactoring which I don't know when it will be ready.
     
    In the meantime, no armbian-config for minimal images.
    Plus minimal images are for more experienced debian users, since target is server-like tasks.
     
    dmesg log is essential for such issues: x88 boards have wifi over "external" sdmmc controller, thus rk3318-config should already have warned you that you had to configure, reboot and then run again rk3318-config to get wifi and bluetooth detected and working.
     
    wifi can be configured either from command line with nmcli, but also with nmtui which provide a nice and simpler text-based UI even on minimal distros.
  25. Like
    Willy Moto reacted to Werner in Most powerful SBC running Armbian for distributed computing ?   
    I think the best possible SoC that is also well supported is any device featuring RK3399. Yes there are successors now, the RK35xx series but it will take years go get to the same mature level as the RK3399 is now.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines