Boot and kernel - too weird?!

[cu6apum]

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]

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.

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

[cu6apum]

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]

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

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]

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.

[igorp]

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.

Yes. Dietpi grabs stock (garbage) and adds more of it with a bash script. All development is around installing 3rd party software.

[cu6apum]

@igorp - thanks a lot, I’m in. (Although the lightmost image failed to start; ok, let’s use desktop now...)
No hidden boot/config, no odd overlay fs - I prove! No need for strange eflasher. Linux as it is. Yepperz.

[igorp]

No need for strange eflasher. Linux as it is. Yepperz.

That's the point!

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]

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]

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]

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.

This is not really a bug. 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]

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.

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

[cu6apum]

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

Yes, it has.
And then third boot from eMMC somehow destroyed the bootloader in it. Not kidding, sowwy.

[cu6apum]

VERY buggy distro, sorry. Flickering boot, unknown kernel source, drunk armbian-config doing unpredictable things... bah.
Will look for another distro with conventional filesystem.

[igorp]

VERY buggy distro, sorry.

Is this the only/first Linux you have ever seen? Now prepare for what you will experience elsewhere ... but from support on my costs I saw that you don't listen to my advices. Its hard to help this way.

another distro with conventional filesystem

It is not possible to be more conventional. Good luck! But only luck will not be enough ...

[cu6apum]

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

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:

Code: Select all

=> 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
=> 

[igorp]

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:

There are people that runs Armbian wit years of up time. https://forum.armbian.com/search/?q=uptime&fromCSE=1

Those problems are not Linux related (early boot loader). I am out of office, but can try to recreate during next week if you tell the exact procedure how you get here. (If you want to boot again from SD card you need to hold boot button for few moments and power on/reset)

Linux on ARM boards is getting standards, slowly, but 5-6 years ago it was a disaster. Armbian made a huge progress in this. If you want to understand some background, check my presentation below https://www.armbian.com/authors/

My first Linux public email/web server was on network in 1994, before with Unix/VAX.

[cu6apum]

Ok. "Weird" is definitely the word of the day in this topic.
1. Download armbian image, flash it.
2. Using armbian-confing install the system to emmc. No need to press any button, as microsd always boots first.
3. Boot from emmc, set everything up, enjoy.
4. Reboot several times while playing with dtbs. After 3 or 4 reboots we have errors mentioned above. Card don't respond to voltage setting, can't find file system.
5. For some time, bootz/boot helps. After some more reboots the bootloader stably refuses to go on.
6. Booting from sd again, we can unpredictably get booted to the image on emmc or to the image on microsd. No dependency found. However the board never refuses to boot from sd.
7. If working from sd (emmc unmounted) we quickly encounter some filesystem errors leading to readonly remount of it. This, however, may happen due to a noname chinese card which I planned to use for one-time install.
8. emmc filesystem did not fail yet.

[cu6apum]

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.

[igorp]

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.

There are several options, which came to my mind ATM and it popped up in the past:

FriendlyArm uses new/different eMMC chip which hasn't landed to our boot loader yet. It happened before. I am about to receive most recent batch of their boards next week and will have at least a test subject where I might replicate this. I never experienced troubles you are describing with my test board. I also used them for real as mobile router / NAS with booting from eMMC/NvME. Many reboots and no troubles. eMMC is more or less an embedded SD card and behave accordingly. It is possible (small chances) that someone pushed things to far https://forum.armbian.com/topic/8153-sd ... derations/ for eMMC so this has to be checked. Hardware failure that manifest only on Armbian? More likely as a quality issue ... if at all. In case our setting are less conservative. Small chances, but possible.

As you can see from the Rockchip documentation, RK3399 can boot up on more then one way ... so this mess could actually be quite complicated if and I think we do use different way then official, together with more recent u-boot. So far, it worked fine.

to all that device-tree madness

You won't believe, but this is one of the best things which has been developed Implementation is still rough, there are changes, hardware makers are not the best example of doing this right, people are confused. Yes its a mess, but imagine 5-10 years ago, when each hardware maker had his own way of doing the same thing. What a waste. We still support one Allwinner's: https://github.com/armbian/build/tree/master/config/fex ...

[cu6apum]

Well, the bad thing is that it isn't me who designed the board. I have only one proprietary design using Octavo SOC - surely it works like a charm.
The alarm I hear when the bootloader cries about the card voltage sounds very similar to the contents of the article you linked. Look, emmc has way more interfacing options than sd (which is 3.3v only) - maybe there's some bottleneck in the bootloader code? After the kernel settles in, there were no errors. Whilst setting emmc parameters in wrong time (??) one can not only lose the card, but even perform a spurious write/erase.
I should have saved affected sectors and compare to a fresh install. Probably I will.

[cu6apum]

Maybe this is a hint? Preboot always selects device 0, be it sd or emmc...
Perhaps setting voltage for a wrong device is the case, previous boards (TI, allwinner) always used mmc0 for sd and mmc1 for internal storage.

[cu6apum]

Compared bootsectors. Nothing changed => emmc ok.
Moreover, 3 times AFTER full refuse, it booted right with no touch of mine.
The board must be flickering, or I'm a wood.