Vanilla mainline Debian 11 (Bullseye) on the RockPro64
#11
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".
  Reply
#12
(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 Smile

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.
  Reply
#13
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.
  Reply
#14
(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.
  Reply
#15
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.
  Reply
#16
(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.
  Reply
#17
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.
  Reply
#18
(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.
  Reply
#19
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.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  RockPro64 EDP in Armbian hannescam 2 201 10-15-2021, 09:07 AM
Last Post: hannescam
  Debian Bullseye & RockPro64: No tty consoles? Pete Tandy 5 274 10-09-2021, 02:02 PM
Last Post: TRS-80
  Two Questions About Debian on RockPro64 publiclewdness 0 107 09-30-2021, 11:54 AM
Last Post: publiclewdness
  Overlays not loading at boot - ROCKPRO64 on Armbian rookieone 0 103 09-28-2021, 04:10 AM
Last Post: rookieone
  slave mode on Rockpro64 Radhika.gabani 1 836 09-22-2021, 05:35 AM
Last Post: mahtew
  slarm64 (unofficial slackware) ROCKPro64 RK3399 (aarch64) mara 46 30,939 09-21-2021, 09:39 AM
Last Post: mara
  New OS for RockPro64 is here, TwisterOS Armbian jtremblant 85 26,932 08-28-2021, 11:25 AM
Last Post: jtremblant
  Compiling ayufan mainline - DT-overlay missing Mentaluproar 0 314 07-24-2021, 09:46 PM
Last Post: Mentaluproar
Question Booting official Debian on RP64 arteeh 6 1,688 07-06-2021, 10:16 AM
Last Post: TRS-80
  RockPro64 CRUX-ARM (aarch64) mara 0 478 06-05-2021, 11:29 AM
Last Post: mara

Forum Jump:


Users browsing this thread: 1 Guest(s)