FriendlyELEC-Forum

cu6apum wrote:
Hi there. I'm relatively new to ARM SBCs, however 3 or 4 boards I used to work with gave easy and sensible way to manage peripherals: uEnv.txt for uBoot in Texas Instruments, or at least boot.cmd in sunxi.

Here (nanopc-T4) we have hidden bootloader AND kernel, and if someone needs to add (or better DEBUG) a device, he encounters lots of pain having to recompile everything each time - and flashing the image! Being a noob I lost my root system once already.

Is this cumbersome, opaque and inconvenient boot arch the property of the CPU boot manner, or is it Ubuntu? Is there a way to config peripherals just by editing a text file like everywhere, or at least by compiling a dts and putting it onto filesystem, not hidden flash area?! Surely uBoot can do this. Where's the obstacle???

Or am i too dumb to not see some obvious things? Thank you.

igorp wrote:
Check Armbian. It has consistency across all platform. There is no uEnv.txt but armbianEnv.txt

cu6apum wrote:

igorp wrote:
Check Armbian. It has consistency across all platform. There is no uEnv.txt but armbianEnv.txt

Afaik it's based on the same Ubuntu/Debian blend. I never encountered such weirdness in any of them, so I strongly suspect that it's unavoidable. http://opensource.rock-chips.com/wiki_Partitions

However if one can at least mount the boot partition, the things MAY clean up a bit...

igorp wrote:
Things are already cleaned Armbian does not have such weird partition scheme. It has identical scheme (from users perspective) on all boards virtually since the day one. A lot of work needed to get there ... Debian will get universal boot process, Armbian has it for years. What is the same as Debian/Ubuntu? Userland packages relations and versions to maintain application compatibility. What is better? Improvements are on all levels, with focus on hardware features. Don't want to make promo - just try ...

cu6apum wrote:

igorp wrote:
Things are already cleaned Armbian does not have such weird partition scheme. It has identical scheme (from users perspective) on all boards virtually since the day one. A lot of work needed to get there ... Debian will get universal boot process, Armbian has it for years. What is the same as Debian/Ubuntu? Userland packages relations and versions to maintain application compatibility. What is better? Improvements are on all levels, with focus on hardware features. Don't want to make promo - just try ...

Will do, thank you.
Don’t have anything on topic about dietPi? I’m familiar with it so development may get a bit faster.

cu6apum wrote:
No need for strange eflasher. Linux as it is. Yepperz.

igorp wrote:
Most lightweight image, probably with kernel 5.3.y ? ... AFAIK it works but it takes a lot of time to light up the screen. Beta development kernel issues ... minor problem considering how much was needed to get here.

cu6apum wrote:

igorp wrote:
Most lightweight image, probably with kernel 5.3.y ? ... AFAIK it works but it takes a lot of time to light up the screen. Beta development kernel issues ... minor problem considering how much was needed to get here.

No, 4.4.190. Funny thing, I cannot find the source! The configurator downloads 4.4.176...

igorp wrote:

cu6apum wrote:

igorp wrote:
Most lightweight image, probably with kernel 5.3.y ? ... AFAIK it works but it takes a lot of time to light up the screen. Beta development kernel issues ... minor problem considering how much was needed to get here.

No, 4.4.190. Funny thing, I cannot find the source! The configurator downloads 4.4.176...

Hmm, bug ...

Move to nightly builds (armbian-config -> system) if you want to have most fresh sources.

cu6apum wrote:

igorp wrote:

cu6apum wrote:
The bug is that armbian destroys the eMMC bootloader for some odd reason (ubuntu was doing just fine if we forget about the weird structure). Third or forth reboot it says can't find ext2 filesystem, but if i say bootz/boot it finds. Next times it refuses to boot at all.
Foooock.
SD card boots ok. Haven't tried M.2.

igorp wrote:

cu6apum wrote:

igorp wrote:

Armbian doesn't destroy anything. If you install it on eMMC it will naturally wipe out everything, including boot loader.

cu6apum wrote:
VERY buggy distro, sorry.

another distro with conventional filesystem

igorp wrote:
Is this the only/first Linux you have ever seen?

=> boot      
Card did not respond to voltage select!
=> mmc info
Device: sdhci@fe330000
Manufacturer ID: 15
OEM: 100
Name: AJTD4 
Bus Speed: 52000000
Mode : MMC High Speed (52MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 14.6 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 14.6 GiB WRREL
Boot Capacity: 4 MiB ENH
RPMB Capacity: 4 MiB ENH
=> boot    
Card did not respond to voltage select!
=> mmc part

Partition Map for MMC device 0  --   Partition Type: DOS

Part   Start Sector   Num Sectors   UUID      Type
** Can't read partition table on 0:0 **
~~~~~~~~~~~~~~~~~~~~~~~~~~~

=> mmc part

Partition Map for MMC device 0  --   Partition Type: DOS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Part   Start Sector   Num Sectors   UUID      Type
  1   32768        30197536     1fa70110-01   83
=> 

cu6apum wrote:
Yes, last 22 years I was using self-made images only on x86. Current servers have only 2.5 years uptime.

But these boot issues actually can be problems of the board. Look:

cu6apum wrote:
Addition: after I realized that my dtb experiments may have led to some hardware misbehavior (I'm new to all that device-tree madness and have not got the very ideology) I obviously started over with a fresh install.
5 reboots and we're broken again.

Defective board? But ubunty did not flicker at all.

to all that device-tree madness