jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

(Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 12:39 pm

Ref: The following posting
viewtopic.php?f=28&t=310972

System is a Pi-4, 4gb, running a recent, (but not latest), version of Raspbian with the latest firmware.

While working on a multi-boot solution that used multiple config.txt files joined by "include" directives, I noticed that certain statements in config.txt do not survive across an "include".

Specifically, I have a very generic config.txt file that then includes an additional config file(s) as needed. At the end of the included config file is the statement "start_x=1" which enables the Pi camera.

With the statement at the end of the included config file, the camera does not work.
With the statement as a part of the original config file that is doing the including, it does work.

1. Is this expected behavior? If so, where is it documented and where can I find a list of statements and/or directives that do not survive being "included".

2. If this is not expected behavior, is it a known issue or should I open an issue on GitHUb?

Here are the files in question:

First is the "master" config.sys.

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# Setup GPIO pins, set as inputs, (ip), pulled high, (pu).
#
# Pin/dip-switch mapping for GPIO O/S selection:
# Dip-switch   Broadcomm pin   Physical pin	    Function
#    1		   21		   40		Raspbian for Robots (see switch 5)
#    2		   26		   37		GoPiGo O/S (see switch 5)
#    3		   20		   38		Raspbian 32-bit (see switch 5)
#    4		   19		   35		Raspbian 64-bit
#    5		   16		   36		"Bitness" selector. Selected = 64-bit kernel
#						"Bitness" is selected in the individual O/S
#						config.txt file. (e.g. R4R_config.txt, etc.)
#  common	 ground		   39

gpio=21=ip,pu
gpio=26=ip,pu
gpio=20=ip,pu
gpio=19=ip,pu
gpio=16=ip,pu

# O/S #1 is also raspbian for robots
[gpio21=0]
# include R4R_config.txt
include /R4R_boot/config.txt
[all]

# O/S #2 is GoPiGo O/S 3.0.0
[gpio26=0]
# include GPG_config.txt
include /GPG_Boot/config.txt
[all]

# O/S #3 is Raspbian 32 bit
[gpio20=0]
# include Rasp32_config.txt
include /Raspbian32/config.txt
[all]

# O/S #4 is Raspbian 64 bit
[gpio19=0]
# include Rasp64_config.txt
include /Raspbian64/config.txt
[all]

# This only works if used in this file.
# start_x=1

Here is one of the "called" configuration files:
(Assume OS-2 is being booted)

Code: Select all

# GPG_Config.txt which corresponds to GoPiGo O/S's /boot/config.txt

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# This file must be used with the corresponding master config.txt
# within the boot partition to enable GPIO pin config.

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=2
hdmi_mode=39

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

# Enable Adafruit RTC modules
# Uncomment the line that corresponds to
# the module, (clock chip), you're using
#dtoverlay=i2c-rtc,ds1307
#dtoverlay=i2c-rtc,pcf8523
dtoverlay=i2c-rtc,ds3231

#  Enable experimental 64-bit kernel if dip-switch 5 is flipped.
[gpio16=0]
arm_64bit=1
[all]

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

[all]
#dtoverlay=vc4-fkms-v3d

# This statement is ineffective here.
start_x=1

gpu_mem=128
dtparam=i2c1=on

os_prefix=GPG_Boot/
Any help would be gratefully appreciated.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 12:42 pm

the start_x=1 directive, must be processed by bootcode(4).bin, since that is what loads start(4).elf

and a quick check over the decompile, says that bootcode4.bin lacks support for the include directive, so that would explain the problems

timg236
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 835
Joined: Thu Jun 21, 2018 4:30 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 1:06 pm

The 'include' directive is not supported in the Pi4 EEPROM bootloader or bootcode.bin on previous models. It is unlikely that support for the include directory will be added due to the implementation of the config parser / memory allocator.

timg236
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 835
Joined: Thu Jun 21, 2018 4:30 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 1:09 pm

cleverca22 wrote:
Wed May 05, 2021 12:42 pm
the start_x=1 directive, must be processed by bootcode(4).bin, since that is what loads start(4).elf

and a quick check over the decompile, says that bootcode4.bin lacks support for the include directive, so that would explain the problems
Or for easy reference https://www.raspberrypi.org/documentati ... xt/misc.md
Include directives are not supported by bootcode.bin or the EEPROM bootloader

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 1:42 pm

timg236 wrote:
Wed May 05, 2021 1:09 pm
cleverca22 wrote:
Wed May 05, 2021 12:42 pm
the start_x=1 directive, must be processed by bootcode(4).bin, since that is what loads start(4).elf

and a quick check over the decompile, says that bootcode4.bin lacks support for the include directive, so that would explain the problems
Or for easy reference https://www.raspberrypi.org/documentati ... xt/misc.md
Include directives are not supported by bootcode.bin or the EEPROM bootloader
i guess i'm too pessimistic, ive found a lot of things that just arent documented, so i default to just going right to the binary
docs can lie, the actual code implementing a thing cant lie

jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 2:46 pm

cleverca22 wrote:
Wed May 05, 2021 12:42 pm
the start_x=1 directive, must be processed by bootcode(4).bin, since that is what loads start(4).elf

and a quick check over the decompile, says that bootcode4.bin lacks support for the include directive, so that would explain the problems
OK, I'll bite.
Where's "bootcode(4).bin"? The bootfs partition of the last Raspbian/Raspberry Pi (32 bit) O/S I downloaded, (maybe a week ago?) only has ONE "bootcode" file - bootcode.bin.

Another issue:
"supported" and "not supported" appear to be relative terms. Telling me that "bootcode[n].bin doesn't support [feature] is pointless as I have no idea what that means in real "where the rubber meets the road" terms. It's not like I've never worked with microcontrollers or microcontroller development - but how the [censored!] am I to know that something like "start_x" is handled by bootcode.bin, but [this other feature] is not?
pound_head.gif
pound_head.gif (9.2 KiB) Viewed 973 times

How do I discover what features are, or are not, impacted by this particular quirk?

This would explain a lot of the behaviors I have been seeing, and puzzling over, trying to implement a mult-boot environment for the Pi.

Viz.:
Things that behave normally in a "standard", (two partitions on an SD card), installation behave oddly when booted from a USB SSD with multiple boot/root partitions.

So, "The Musical Question" becomes "What features, aside from "start_x" are handled in such a way that they do not survive across an include boundary?"

Which rapidly degenerates into "how big can a config.txt file be?" Since I can no longer assume that anything reliably works across an include boundary - or if it does, it may work oddly - I am forced to consider the prospect of including the text of EVERY SINGLE supplementary config file in-line within the master config.txt - which becomes an implementation nightmare!

Likewise, anything that modifies config.txt - like raspi-config - becomes a nightmare too since I cannot assume that a single, all-encompassing, config.txt file will work for every Raspbian-derived operating system, or that if it does, it will remain so.

I'm rapidly coming to the conclusion that "I'm borked".

This is a crying shame. I am in a position to do some interesting robotics research using the Raspberry Pi and a GoPiGo-3 robot that will cross several operating system boundaries. The original method - everything on an independent SD card - is unworkable because the cards are so tiny and, (on this robot), so difficult to get to, that constantly swapping in/out SD cards is not a viable option. (I also doubt that the micro-SD connector has multiple-hundreds of insertion-removal cycle reliability either.)

The option I chose was to use a very fast, USB-3.n, Seagate Expansion/OneTouch SSD, (500 gb), to hold the experimental copies of the operating systems and software I am working on. Since these Seagate SSD's are actually slightly smaller and less thick than the Pi itself, it easily fits on the robot.

I have implemented a dip-switch arrangement for selecting the O/S to boot and the "bitness" of the kernel to use without having to have a keyboard or monitor attached. Flip the corresponding dip-switch, reboot, and blammo! - you're running the requested O/S.

Now it looks like this is all rapidly going down the tubes, unless someone can help me predict what features work, and what features don't work, across an include boundary.

Pardon me if my angst meter is slamming against the full-scale stop, but this has been going in circles for months now.

Any additional help would be appreciated.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

timg236
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 835
Joined: Thu Jun 21, 2018 4:30 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 3:23 pm

bootcode.bin on Pi4 is not relevant. The bootloader is in the EEPROM. See my previous post which linked to the official docs.

The only text which must be in config.txt instead of the included files are entries that are specific to the bootloader e.g. start_x, gpu_mem. I would just hoist the bootloader specific bits into config.txt duplicating the gpio-conditionals and resetting them. Those keys will be ignored by start.elf because they aren't recognized.

The bootloader only really looks at config.txt in order to determine what GPU firmware to load + GPU mem settings

4KB should be fine for config.txt

Code: Select all

[gpio16=0]
start_x=1
gpu_mem=128
[all]


cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 3:47 pm

timg236 wrote:
Wed May 05, 2021 3:23 pm
bootcode.bin on Pi4 is not relevant. The bootloader is in the EEPROM. See my previous post which linked to the official docs.
the file handling routines still refer to the blob in the EEPROM as bootcode.bin, but i sometimes use the name bootcode4.bin, because thats what rpiboot decided to call it, and to keep it distinct from the old one
jharris1993 wrote:
Wed May 05, 2021 2:46 pm
So, "The Musical Question" becomes "What features, aside from "start_x" are handled in such a way that they do not survive across an include boundary?"
its probably in a doc somewhere, but i'm not sure which ones cover every single part

last time i checked it, the rpi4 bootloader in the EEPROM only supports the following config.txt entries:

Code: Select all

bootcode_delay
bootloader_update
boot_load_flags
fixup_file
gpu_mem
gpu_mem_1024
gpu_mem_256
gpu_mem_512
mfg_test
require_total_mem
sdram_freq
start_debug
start_file
start_x
total_mem
uart_2ndstage
all others, including the "include" directive, are just ignored, and start(4).elf will re-parse the config and do a lot more, once it is booting

(some gpio ones may be missing, due to them behaving differently)

jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 5:00 pm

Thanks for all this information - perhaps this list of things that the binary blob, (or firmware, or whatever), processes can be placed in the official documentation somewhere? This would have saved me much angst.

Update to project:
It turns out that after having a nice dinner with the wife and granddaughters, things didn't look so bad and I had an idea:
To what extent do the config.txt files actually differ between the various Raspbian/Raspberry Pi O/S versions I am booting?

Run a diff on all four of them and it turns out that about 5% of the files are different because:
  • The files had different title blocks and some OS specific code (os_prefix=)
  • There were configuration differences that had not been propagated to all the files yet.
So, I decided to "bite the bullet" and merge all the config-txt files into one file with all the settings I need to be universally applicable set in a uniform manner throughout.

I then cut-and-pasted the GPIO pin selection logic out of the "master" config.txt file and merged it into what I was calling my "unified config.txt".

I made the fixups needed to merge all the logic into one file, (removed a LOT of redundant code), and generally refactored the heck out of it.

I now have one monolithic file, no includes, that resides in the root of the boot partition and the individual boot partition sub-directories which will make management a lot easier.

I am testing right now and will see if this solves any of my wonkyness.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Wed May 05, 2021 7:20 pm

cleverca22 wrote:
Wed May 05, 2021 3:47 pm
last time i checked it, the rpi4 bootloader in the EEPROM only supports the following config.txt entries:

Code: Select all

bootcode_delay
bootloader_update
boot_load_flags
fixup_file
gpu_mem
gpu_mem_1024
gpu_mem_256
gpu_mem_512
mfg_test
require_total_mem
sdram_freq
start_debug
start_file
start_x
total_mem
uart_2ndstage

all others, including the "include" directive, are just ignored, and start(4).elf will re-parse the config and do a lot more, once it is booting

(some gpio ones may be missing, due to them behaving differently)

The start_x one should be on that list too.

What would be very useful would be a list of all the things that do NOT survive an "include" - is this it?
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Thu May 06, 2021 8:47 am

jharris1993 wrote:
Wed May 05, 2021 7:20 pm
The start_x one should be on that list too.

What would be very useful would be a list of all the things that do NOT survive an "include" - is this it?
the bootloader does not support include, so everything in that list, will be ignored when in an include'd file

jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Thu May 06, 2021 8:03 pm

Excellent!

I think I am beginning to really "get my arms around" this topic - it is gratefully appreciated.

A corollary question if I may:

Given:
a directory in the root of a partition
three operating system boot subdirectories
NO overlay or whatever else directories except for the three OS subdirectories.

The root directory has all the start.elf files and fixup.dat files, and the config.txt.
The three subdirectories have all the files and folders for each operating system's /boot, including a copy of the exact same config.txt. One of these subdirectories eventually ends up mounted on /boot depending on the operating system being booted.

Part of the config file is an "os_prefix" statement that points to one of the three subdirectories depending on what O/S is being booted. (That's the one that ends up on /boot.)

Question:
What part of the boot files MUST be in the root of the boot partition, and what files MUST be in the individual subdirectories?

In other words:
Is it possible to have the boot process transfer total control to all the files and folders in one of the subdirectories, as if that were the entire boot partition?
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Thu May 06, 2021 8:05 pm

it sounds like your just re-inventing noobs/pinn, which does the same thing

maybe you should have a look at those projects first?

jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Thu May 06, 2021 8:23 pm

cleverca22 wrote:
Thu May 06, 2021 8:05 pm
it sounds like your just re-inventing noobs/pinn, which does the same thing

maybe you should have a look at those projects first?

Very similar, but with a slightly different boot paradigm.

I have already done this with PINN and I am not happy with the way PINN backs up and restores operating system images. (Though I am still working with procount on this.)

I want to try a different multi-boot method to find out which one, if any, provides the most accurate boot/runtime experience.

Once I have both of these figured out, I can compare/contrast and perhaps figure out a way to make the installation/backup process on PINN work better.
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Thu May 06, 2021 8:51 pm

it could also help to understand how PINN works behind the scenes, and then hijack that mechanism for your own needs

https://github.com/raspberrypi/noobs/wi ... -low-level

basically, the bootcode.bin will load from either the 1st fat32 partition (pre-pi4 models) or the SPI flash
it will then load either start(4).elf or recover{y,4}.elf from the 1st fat32 partition
if start was renamed to recovery, it wlll load recovery.img instead of kernel.img (i dont see much point in renaming either file?)

that kernel can then present a GUI for selection OS's, or timeout and boot the default (pinn/noobs use linux, but it could be a custom baremetal os)

to boot the chosen os, it tells the firmware to reboot into partition #X
it will reboot the SoC, and the bootcode.bin will find that X in a special register
then it will load config.txt + start(4).elf from a different fat32 partition


so at the cost of booting the firmware twice, you could replace the noobs/pinn kernel with any arm kernel you want, and get all of the same features
on the 2nd boot, it will fully respect the target config.txt, no need to jam it full of if statements

User avatar
thagrol
Posts: 4927
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 10:46 am

cleverca22 wrote:
Thu May 06, 2021 8:51 pm
that kernel can then present a GUI for selection OS's, or timeout and boot the default (pinn/noobs use linux, but it could be a custom baremetal os)

to boot the chosen os, it tells the firmware to reboot into partition #X
it will reboot the SoC, and the bootcode.bin will find that X in a special register
then it will load config.txt + start(4).elf from a different fat32 partition
That's fine if you have a monitor and keyboard connected. What about for headless Pi? That's where a GPIO filter based approach wins.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 10:48 am

thagrol wrote:
Fri May 07, 2021 10:46 am
That's fine if you have a monitor and keyboard connected. What about for headless Pi? That's where a GPIO filter based approach wins.
if using a custom baremetal kernel, you can do whatever you want, including checking gpio

you could even drive a tiny text-only lcd, and use gpio buttons for a menu

User avatar
thagrol
Posts: 4927
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 11:30 am

cleverca22 wrote:
Fri May 07, 2021 10:48 am
thagrol wrote:
Fri May 07, 2021 10:46 am
That's fine if you have a monitor and keyboard connected. What about for headless Pi? That's where a GPIO filter based approach wins.
if using a custom baremetal kernel, you can do whatever you want, including checking gpio

you could even drive a tiny text-only lcd, and use gpio buttons for a menu
Sure, but that's a lot more work and requires a different skill set.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 11:37 am

yeah, just stating that is is a possible option, for those that have the skills and want to investigate it

User avatar
Milliways
Posts: 693
Joined: Fri Apr 25, 2014 12:18 am
Location: Sydney, Australia

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 11:54 am

Maybe I am missing something, but (in the past) I have implemented different config.txt files - I just rename (actually copy) the desired file.

I now have a single config.txt file which works on all my Pi (from Pi B to Pi4) using Conditional Filters. No need for complicated includes.

The only exception is camera which needs different settings.

User avatar
thagrol
Posts: 4927
Joined: Fri Jan 13, 2012 4:41 pm
Location: Darkest Somerset, UK
Contact: Website

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 12:43 pm

Milliways wrote:
Fri May 07, 2021 11:54 am
Maybe I am missing something,
Probably. This thread (and at least one other) hasn't arisen from one config.txt that'll work on many Pi. It's ceem from a desire to have an SD card with one boot partition and several root partitions then using a GPIO filter in config.txt to switch between them at boot time.

Knida like noobs/pinn but headless.
I'm a volunteer. Take me for granted or abuse my support and I will walk away

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 2:24 pm

thagrol wrote:
Fri May 07, 2021 12:43 pm
This thread (and at least one other) hasn't arisen from one config.txt that'll work on many Pi. It's ceem from a desire to have an SD card with one boot partition and several root partitions then using a GPIO filter in config.txt to switch between them at boot time.

Knida like noobs/pinn but headless.

Actually, it is EXACTLY the way PINN works. . .

Due to MASSIVE amounts of support from procount, (and testing by me), we were able to get:
1. PINN is now able to read pinn_init files from USB.
2. PINN can use GPIO selections to boot-select headless via a custom pinn_init.

So, this has already been done in PINN and, in fact, I have a separate SSD that I have dedicated to testing this with PINN.

I want to explore more than one boot paradigm for several reasons:
1. I want to understand very clearly what goes on "under the hood".
2. I want to understand what and where all the "quirks" and "gotchas" are.
3. Evaluating more than one method is always a good idea.
4. I want to help procount with some of the rough-edges in PINN, and I don't want to just say "YOU DUMMY! This doesn't work!!!" I want to be able to make constructive suggestions and maybe even some code massaging. He's done a lot for me and (IMHO) it's payback time.

I'd really like to know more about booting the Pi than just "you put this on the SD card, plug it in, and apply power. . ." I don't trust "magic" solutions and I like to find out what's really happening.
cleverca22 wrote: i guess I'm too pessimistic, I've found a lot of things that just aren't documented, so i default to just going right to the binary
docs can lie, the actual code implementing a thing cant lie
Interesting!

I was told, in NO UNCERTAIN TERMS, that the firmware and binaries are CLOSED SOURCE. (No touchee, no lookee.) I wanted to see it, and maybe even contribute to it, but was (politely) told to bugger off. ;) (Not really, but they did say it was closed-source and unavailable.)

Would you please explain how YOU can look at "the actual code implementing a thing" when the rest of us are told "Я не говорю по-английски"? (Sorry mate. Don't speak English.)
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 2:31 pm

jharris1993 wrote:
Fri May 07, 2021 2:24 pm
Interesting!

I was told, in NO UNCERTAIN TERMS, that the firmware and binaries are CLOSED SOURCE. (No touchee, no lookee.) I wanted to see it, and maybe even contribute to it, but was (politely) told to bugger off. (Not really, but they did say it was closed-source and unavailable.)

Would you please explain how YOU can look at "the actual code implementing a thing" when the rest of us are told "Я не говорю по-английски"? (Sorry mate. Don't speak English.)
even if it is closed source, you can still decompile the binary, and depending on your skill and tools, you can get things into a state where you can read what its doing

in this case, i just did a dumb search for "include" and found zero hits, so the actual decompile doesnt matter, it has no reference to string-compare against and know a given line is an include statement


i have been investing a lot of time into the open firmware to make it much simpler to both get answers and extend things
but it currently doesnt support pi4 at all, so you need to co-operate with the existing closed firmware
and thats where understanding how pinn works within the closed firmware, enables you to write custom solutions that run on the arm side, and co-operate with the closed firmware

jharris1993
Posts: 247
Joined: Sat Oct 05, 2013 10:26 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 3:06 pm

cleverca22 wrote:
Fri May 07, 2021 2:31 pm
even if it is closed source, you can still decompile the binary, and depending on your skill and tools, you can get things into a state where you can read what its doing

Isn't "reverse engineering" forbidden by the Broadcomm license?
in this case, i just did a dumb search for "include" and found zero hits, so the actual decompile doesnt matter, it has no reference to string-compare against and know a given line is an include statement


i have been investing a lot of time into the open firmware to make it much simpler to both get answers and extend things
but it currently doesnt support pi4 at all, so you need to co-operate with the existing closed firmware
and thats where understanding how pinn works within the closed firmware, enables you to write custom solutions that run on the arm side, and co-operate with the closed firmware

Right now I am not interested in "hacking" PINN. I already have enough projects on my plate as it is. ;)

What I do want to know is the "down and dirty" details about what happens during (what I now learn is) first and second boot.

Re: PINN

IMHO, PINN has a LOT of advantages, is one heck of a powerful tool, kicks butt and takes names, and takes no prisoners. Procount has worked miracles, walked on water, and just about raised the dead with his efforts on PINN and he gets total respect from me.

However, the one real bitch part is that you cannot use an operating system as-is, (unless it's a pre-packaged O/S)

If you have a "re-spin" O/S, (the robotics operating systems I work with are re-spins of Raspbian), you have to "PINNify" it by extracting it, mangling it, repackaging it, compressing it, and then create a bunch of metadata, (and hope you get it right!), before you can use it. All of these steps are not trivial and are fraught with danger and the possibility of mistakes.

I am not entirely convinced that PINNifying an operating system, along with being installed, (and munged), by PINN to do the necessary fix-ups, results in a binary equivalent of a SD installation - there are just too many strange things that go on - like permissions getting mangled - to allow me to trust it.

Don't get me wrong, I'm not criticizing PINN per se. It's a complex subject that is poorly documented, and I am not surprised that errors creep in. Like I said, I want to know more about it so that I can do something to actually HELP, instead of just bitching and moaning.

The current multi-boot installation method I am experimenting with avoids PINN altogether - you unpack the O/S's boot partitions directly into sub-directories in the target device's boot partition, (and some essential boot files into the root of that partition), and the root of the operating systems into a separate root partition for each O/S.

There are only two fix-ups that need to be done:
1. Make sure that cmdline.txt and fstab reference the correct partition UUID's for each of the operating systems in turn.
2. Create a bind-mount to mount the O/S specific subdirectory on /boot in that O/S's root file system.

IMHO, this is much easier to follow than scripts with sed and awk statements that look like strings of cartoon curse-words.

Again, (IMHO), once I understand the fundamentals of the boot process better, I can take another look at PINN and figure out what's going on there.

P. S.
What can you tell me about this secret "register" that can redirect the boot process? How to I access/use it?

P. P. S.
i have been investing a lot of time into the open firmware. . .

I just took a look over there at that project, and you gotta have a BIGGER set of BRASS BALLS than I'll ever hope to have!

Thanks!
Jim "JR"

Some see things as they are, and ask "Why?"
I dream things that never were, and ask "Why Not".

Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.
Old Chinese Proverb

cleverca22
Posts: 3743
Joined: Sat Aug 18, 2012 2:33 pm

Re: (Bug?) "start_x=1" (and possibly other commands/directives) do not work in an "included" config.txt file.

Fri May 07, 2021 3:14 pm

jharris1993 wrote:
Fri May 07, 2021 3:06 pm
I am not entirely convinced that PINNifying an operating system, along with being installed, (and munged), by PINN to do the necessary fix-ups, results in a binary equivalent of a SD installation - there are just too many strange things that go on - like permissions getting mangled - to allow me to trust it.
in the case of the rpi4, the bootcode.bin is held in SPI flash and is the same no matter which SD card you insert

so on the 2nd boot, it will behave exactly as if that secondary /boot was the only fat32 partition on the card (as far as firmware is concerned)
then its purely up to configuring the os (linux) to use the right partition for /boot and / (the cmdline.txt and fstab uuid stuff all being unique and a matched set)

pre-rpi4, the only difference, is that your using the "wrong" bootcode.bin to bootstrap things, it wont be the one from the chosen /boot partition, but it has very little to say about how the final state works, and it will respect the right config.txt from the chosen /boot

Return to “Troubleshooting”