[SOLVED] What does ${extra} mean in boot file boot.cmd?

Hello I am trying to make an sd card image for a cubieboard2. One of the last steps is to create a boot.scr file. The instructions specify to use this as the first line:

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10 ${extra}

Then says:

You may want to add more arguments to set up display, etc

Are these extra arguments meant to be placed where the '${extra}' tag is, or '${extra}' stays and the extra arguments are placed after it? If the latter, what does this tag mean?

Here's a link to the how to page, but linux-sunxi.org seems to be down today: linux-sunxi.org/Manual_build_howto

I'm assuming extra is an existing environment variable. Are you in the uboot command line? You should be able to use printenv to view all, or specific variables.

U-Boot# printenv
... prints out all known environment variables and their assigned strings/values

U-Boot# printenv <variable-name>
... prints out the requested environment variable and it's assigned string/value

If not U-Boot, perhaps a different bootloader. Either case, extra seems to me to be a set-up variable that has a string or something similar which decodes to relevant boot arguments for Linux, and particularly the Linux kernel which is being loaded on that system or target.

And by the way, if extra is not defined, then having it in the bootargs ends up being meaningless, because it will just be nothing. And their documentation is just giving you that option for a way to inject particular arguments of relevance to your boot.

Thanks rtmistler, I'm afraid I don't know how to get into the uboot command line. From some bits of information I found, it seems to be related to connecting via serial port during boot (http://www.stlinux.com/u-boot/using)? The board does have a serial port header, but I haven't used it yet.

I'll just leave the ${extra} where it is then. Thank you! My next project will be to see if I can run uboot from the serial port, if that's how it's done.

Originally Posted by linux_walt Thanks rtmistler, I'm afraid I don't know how to get into the uboot command line. From some bits of information I found, it seems to be a related to connecting via serial port during boot (http://www.stlinux.com/u-boot/using)? The board does have a serial port header, but I haven't used it yet. I'll just leave the ${extra} where it is then. Thank you! My next project will be to see if I can run uboot from the serial port, if that's is how it's done.

Dealing with an embedded board I would sincerely recommend you do eventually attach a serial cable. Because there are things which may not be available or capable easily unless you have that resource.

Not familiar with those board types, but am with Beagleboards. The default allows for a USB connected network with a pre-determined IP address; much like how your WIFI home device would be 192.168.1.1, they just picked a different static address and since it works as Ethernet over USB it's also point to point with your computer, so very similar to a serial link. However it has to be booted fully with the network stack operational for all that to happen.

Once you stop loading the default distribution and put something on there that you intend, say Debian or if you modify from their defaults, you stand to lose their built in webserver capability and maybe end up getting a network address via DHCP. Well then how do you know what you have? Best case there is the hardwired serial cable is always working and can let you know firstly that the thing booted all the way, and you can also log in that way and use ifconfig to determine your IP address.

Plus just a lot of other general things, mainly the boot status are very helpful when experimenting with an embedded and/or hobby board.

Just bought the serial to USB adapter and will experiment as soon as it gets here. Also found this video that explains how to hook it up to the cubieboard2, although nothing about uboot.

It's becoming clear why this is an essential tool. There have been several booting attempts, with the new image, where it would just freeze with no output to the screen, except 2 penguins on the top left corner.

Thanks again.

PS I didn't mention what I'm putting on the sd card because it's been a long process and I just couldn't remember all the steps. After going through my notes, looking for something else, I found that I used debootstrap to create a Debian root file system.

I'm still not clear how a Linux kernel from sunxi is guaranteed compatible with a Debian root file system, but hopefully understanding will come later.

Update:
Received serial cable and it's working great. I can now see the whole boot sequence from boot0.

I may have found at least one use of ${extra}. The short story is that uEnv.txt sets the value of 'extra', and is also called before boot.scr. Boot.scr then appends 'extra' to its own list of settings.

In uEnv.txt I have:

extra=hdmi.audio=EDID:0 disp.screen0_output_mode=EDID:1280x720p50

boot.scr:

setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait panic=10 ${extra}
ext2load mmc 0 0x43000000 /script.bin
ext2load mmc 0 0x48000000 /uImage
bootm 0x48000000

The long story is that I would never have found out that uEnv.txt was called before boot.scr, without the debug serial cable. Which, in turn, led to the discovery that uEnv.txt did not have 'extra=' but 'extraargs='. So endless relocation of monitor arguments, and remaking of boot.cmd to boot.scr (over and over), never worked. Screen settings were always wrong.

Since it was all sorted out, I have tried several different setups:
no uEnv.txt with all monitor settings in boot.scr - works
Moved ${extra} to different places in boot.scr parameter list - all worked
no uEnv.txt, all monitor settings in boot.scr, but kept the ${extra} tag in boot.scr -works

Strange that it seems unbreakable now, whereas before not one thing I tried worked.

Definitely sometimes things are mysteries. That's why when I'm configuring a new system I always keep some form of diary of all the things I've done and tried and also what worked versus didn't. Of course you still can encounter situations where the same actions and same flow of how you did things cause you to get different outcomes. That's not very comforting if you're considering deploying a system like that. Makes you want to really tear it apart and get a full understanding.

A technique I learned from a former coworker was to put in obvious faults, either in a compilation or in a startup script/file. This was their way of truly validating that the system was operating as expected. Or they'd add a debug output line to a file, something to validate that it actually ran through that file versus ignored it. Because they were sometimes right. I'd be befuddled with something, they'd come over and backstop my opinion and also think "that should absolutely work ... what's wrong here?" 2-3 times over the years, they'd modify code or a file to force an error and the result sometimes was that the file was never being used; hence why the changes did not have effect.

Originally Posted by rtmistler .. Of course you still can encounter situations where the same actions and same flow of how you did things cause you to get different outcomes.

Yup, I spoke too soon. Even with trying to take notes on my work flow, I got mixed up. I was trying to put together a Debian system on SD card, using 'debootstrap'. This was not working. Then decided to try a ready made SD card image of Lubuntu, and compare the files in the boot directory. This last image was the one that I finally got to work, after figuring out that I had ${extra} in boot.scr, but ${extraarg} in uEnv.txt.

The original Debian system I still can't get to work, and I'm comparing the debug output right now.
...

Finally got the 'bootstrapped' SD card Debian image to work. At least part of the problem was the serial debug cable. I noticed that if you left the serial cable connected, then powered off the board, the power led on the board would stay dimly lit. When powering up the board again, this power leakage (from the cable into the board) was causing errors when the booting process was initializing the hardware.
....
No, wrong again. My card image was faulty, and, not sure if it's u-boot, decided to boot off the rootfs I had in my nandb partition, not in the card.

It turns out that sunxi are not very particular about how much guesswork is acceptable to leave to a newbee. Followed their instructions -to the letter-. In one of the steps, specifically (at least strongly implied) intended for SD card, you convert a board specific Cubieboard2.fex file to script.bin. What they failed to mention, is that the Cubieboard2.fex file had the mmc card support disabled.

It took maybe 6 to 7 rebuilds at x 4 hours each to finally figure it out. I'm enjoying Linux, but am considering looking for a different platform than my dear cubieboard.