-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Next Thing Co's CHIP (Allwinner R8) support? #529
Comments
Just my 2 Cents: while adding basic support for the CHIP seems like 'just' assembling already existing stuff, MLC NAND has a great potential for 'apt upgrade' becoming a nightmare and based on the target audience's requirements it looks like maintaining support being a time consuming process anyway. In other words: without a new person feeling responsible for this new platform and doing most of initial and maintenance stuff I would refrain from adding support for the device :) |
What in particular about MLC? Just the general frailty of the soldered-in-place storage mechanism? If it matters, they're currently using the MLC as SLC. |
Yes, and maintaining support without having enough dev samples for the team (and relying on somebody else to debug issues and test images) is just not worth the effort. Current state of Odroid XU4, Lime 2, Cubieboard 1 & 2 is a good example of "support nightmare" when you don't have particular hardware samples. |
Yeah, it's more a bad feeling. If/when data corruption occurs it might be a software glitch, the only way to access/backup data on NAND is through FEL mode (we have basic support for a different platform now but no fool-proof armbian-backup tool), it will be time consuming and current team is already too small. We should start to think twice about adding 'new' platforms since initial support might be done pretty fast but Armbian is a lot about maintainance which needs a lot of resources. |
There is nothing wrong with properly supported MLC NAND, but having NAND as the only storage option makes recovery process after failed update (happens sometimes) look like black magic and certainly an almost impossible task for inexperienced user. |
You say that, but I'll put a great word in for the ease-of-use of the FEL-based flasher at https://flash.getchip.com... |
I'll personally buy y'all (@zador-blood-stained, @ThomasKaiser ) 5-10 CHIPs if it makes a difference. |
If it works like I think it works (exports a block device), then it is great for full image offline backup and restore, but I am talking about file level access, for which you need either another device running Linux (with UBIFS support) or loading recovery image via FEL (i.e. with g_ethernet and SSH+SFTP server). Not as easy as booting another image on the same board. Edit: yes, making full image backup, flashing new image and mounting old image from new OS is a possibility too. |
If @igorpecovnik wants to pick up support for this device now, then it can be done. |
I am not sure we can deal with new chip / platform at this time. If someone joins with C.h.i.p.(s), knowledge, willingness to provide long time support and a budget, than it might work out. I (¬ just me) already spent a whole day on the project and virtually for free. More than this is hard :) and I am in the process to cut my hours down to spent more time with the family and for live support project. We are all well stock with devices and board makers are more than happy to send us samples. |
Thanks all the same! @igorpecovnik @zador-blood-stained @ThomasKaiser - I sincerely appreciate your work! |
While there are indubitably more ARM single board computers than stars in the sky, I see merit for Armbian to support the CHIP - it's extremely popular, has mediocre images and kernel support, and uses the R8 equivalent of the A10/A13.
Has anyone investigated this before? Is there any interest?
I would be glad to furnish a core developer or three with CHIPs if necessary.
Regards!
The text was updated successfully, but these errors were encountered: