I don't live in an English-speaking country, so I am not able to convey the most delicate nuances.
In addition, my English skills are extremely poor. Please keep that in mind first.
----
Now, let's get down to business.
Since you've already tried "Manjaro" & "Armbian", I'll use that as an example.
If you look at the file structure of each distribution yourself, you can check the contents.
In the case of "Manjaro",
/boot/extlinux/extlinux.conf ...
For "Amabian", it is
/boot/boot.scr ...
These boot files are directly interpreted and executed by "u-boot".
*) This is a rough analogy, but these files are equivalent to the configuration files of "GRUB".
If you have a specific reason to use GRUB, that's one thing.
Otherwise, you don't need to use GRUB (which is poor quality) to boot Debian,
you can just boot it the same way as any other distribution.
---
If you can provide the exact version of "u-boot" you are using, and whether or not you have a "serial console",
I can tell you exactly what to do.
However, I don't know your "separation of /var etc..." will have any negative effect.
*) You can do without the "serial console", but it will make a difference in the amount of work to change the "boot-loader".
(10-01-2021, 07:48 PM)t4_4t Wrote: I don't live in an English-speaking country, so I am not able to convey the most delicate nuances.
In addition, my English skills are extremely poor. Please keep that in mind first.
----
Now, let's get down to business.
Since you've already tried "Manjaro" & "Armbian", I'll use that as an example.
If you look at the file structure of each distribution yourself, you can check the contents.
In the case of "Manjaro",
/boot/extlinux/extlinux.conf ...
For "Amabian", it is
/boot/boot.scr ...
These boot files are directly interpreted and executed by "u-boot".
*) This is a rough analogy, but these files are equivalent to the configuration files of "GRUB".
If you have a specific reason to use GRUB, that's one thing.
Otherwise, you don't need to use GRUB (which is poor quality) to boot Debian,
you can just boot it the same way as any other distribution.
---
If you can provide the exact version of "u-boot" you are using, and whether or not you have a "serial console",
I can tell you exactly what to do.
However, I don't know your "separation of /var etc..." will have any negative effect.
*) You can do without the "serial console", but it will make a difference in the amount of work to change the "boot-loader".
Your English is quite effective 
I do not have specific reason to use GRUB, so I'm willing to try either method.
Unfortunately, I do not have serial console. But I'd be willing to learn either way, depending on whatever you consider appropriate in this scenario.
And while I do have custom partition scheme I can mount them all and chroot before making changes. Your instructions on installing GRUB worked perfectly once that was done.
You are using sigmaris's "u-boot" on "spi-flash", I am aware of that.
And I know that you don't have a "serial console".
The important thing is the version of "u-boot" you are using.
If I don't know it, I won't be able to reproduce it correctly if it doesn't work.
The "URL" of the file you used, if you can provide it, is sufficient.
(I'm hoping it's the latest version at the now, but...)
Once that is provided, we can begin.
(10-02-2021, 12:15 AM)t4_4t Wrote: You are using sigmaris's "u-boot" on "spi-flash", I am aware of that.
And I know that you don't have a "serial console".
The important thing is the version of "u-boot" you are using.
If I don't know it, I won't be able to reproduce it correctly if it doesn't work.
The "URL" of the file you used, if you can provide it, is sufficient.
(I'm hoping it's the latest version at the now, but...)
Once that is provided, we can begin.
I've just verified my version of U-Boot is v2021.04.
I've identified the file you used as the following
https://github.com/sigmaris/u-boot/releases
rockpro64 u-boot v2021.04-rockpro64-ci
When rebooting, can you interrupt the boot sequence by holding down the KeyBoard(USB) "Back Space" key?
Check it out.
(10-02-2021, 04:55 PM)t4_4t Wrote: I've identified the file you used as the following
https://github.com/sigmaris/u-boot/releases
rockpro64 u-boot v2021.04-rockpro64-ci
When rebooting, can you interrupt the boot sequence by holding down the KeyBoard(USB) "Back Space" key?
Check it out.
Yes, I am able to interrupt a boot process by hitting the backspace key. I am then presented with some kind of interactive shell.
I Understood.
Now, type in the following command and run it.
If there are no typos, you will be given 10 seconds to interrupt the boot process from the next boot.
(You only need to press the key within 10 seconds, so you don't need to keep pressing the key, which makes the operation easier.
Please be very careful when executing the "saveenv" command.
If an unintended environment variable is changed due to a typo, etc., and "saveenv" is executed in that state, it will result in a bad situation.
--- U-BOOT ---
Code: Hit any key to stop autoboot: 0
=> printenv bootdelay
bootdelay=0
=> setenv bootdelay 10
=> printenv bootdelay
bootdelay=10
=>saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK
=>reset
Switching the "bootloader" itself is quite simple, just copying a few files and creating a text file of about 20 lines.
Copying the files is a familiar "bash" process, so there is no problem.
If you make a mistake, shell will report the error to you and you can try again as many times as you like.
The difficulty is in creating text files, typos are not tolerated.
Even if there is a mistake in the text, no one will report it to you.
And the only way to know if there is a mistake is at boot time.
In short, it is very inefficient.
If you have an environment where you can copy and paste text and write it back to the target media, then you don't have to worry about it.
Can you prepare such an environment ?
Please think about it before next time.
(10-04-2021, 05:23 PM)t4_4t Wrote: I Understood.
Now, type in the following command and run it.
If there are no typos, you will be given 10 seconds to interrupt the boot process from the next boot.
(You only need to press the key within 10 seconds, so you don't need to keep pressing the key, which makes the operation easier.
Please be very careful when executing the "saveenv" command.
If an unintended environment variable is changed due to a typo, etc., and "saveenv" is executed in that state, it will result in a bad situation.
--- U-BOOT ---
Code: Hit any key to stop autoboot: 0
=> printenv bootdelay
bootdelay=0
=> setenv bootdelay 10
=> printenv bootdelay
bootdelay=10
=>saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK
=>reset
Switching the "bootloader" itself is quite simple, just copying a few files and creating a text file of about 20 lines.
Copying the files is a familiar "bash" process, so there is no problem.
If you make a mistake, shell will report the error to you and you can try again as many times as you like.
The difficulty is in creating text files, typos are not tolerated.
Even if there is a mistake in the text, no one will report it to you.
And the only way to know if there is a mistake is at boot time.
In short, it is very inefficient.
If you have an environment where you can copy and paste text and write it back to the target media, then you don't have to worry about it.
Can you prepare such an environment ?
Please think about it before next time.
My apologies for the delayed response: My RockPro is at another location.
I've successfully followed your instructions and now have a working boot delay.
I also believe I have such an environment at the ready.
Please note I'll be away until Wednesday due to the Thanksgiving weekend here in Canada.
Since this is a boot-related change, it is normal to have to press the reset button if the operation fails.
It is impossible to do this remotely.
There is no hurry for us, so please post here again when you have it in hand.
10-30-2021, 12:36 PM
(This post was last modified: 10-30-2021, 12:39 PM by Pete Tandy.)
I'm terribly sorry for the belated reply, but I've bricked my RockPro64 after flashing the SPI with another U-Boot. I wanted to try Ayufan's build and see if it would recognize my USB-C adaptor+external SSD combination before installing a bootable Debian (Sigmaris U-Boot doesn't recognize this setup and I really need to use that USB-C port due to dimensional limitations). Plus I wanted to get off micro-SD card dependence. Something obviously went wrong during the flash process as the SBC no longer displays any video output. Thank you very much for your help.
(10-30-2021, 12:36 PM)Pete Tandy Wrote: I'm terribly sorry for the belated reply, but I've bricked my RockPro64 after flashing the SPI with another U-Boot. I wanted to try Ayufan's build and see if it would recognize my USB-C adaptor+external SSD combination before installing a bootable Debian (Sigmaris U-Boot doesn't recognize this setup and I really need to use that USB-C port due to dimensional limitations). Plus I wanted to get off micro-SD card dependence. Something obviously went wrong during the flash process as the SBC no longer displays any video output. Thank you very much for your help.
|
Vanilla mainline Debian 11 (Bullseye) on the RockPro64
