setup environment in u-boot SPL - embedded-linux

Is there any option to load the environment variables in u-boot SPL?
I have a device (Arria10 SoC) in which a part of the FPGA firmware is loaded in u-boot SPL by using the Firmware Loader API.
This allows the usage of the environment variables storage_interface and fw_dev_part to define the storage.
I was able to set the variables in u-boot and store them to the MMC device. u-boot also reads the variables correct. But in SPL the environment variables aren't initialized.
Is it possible to load it in SPL and use the values from MMC?
Thanks for any hint!

The environment is initialized by calling env_init(). Other boards call this function in the board or architecture specific spl.c file in either of the following functions:
board_boot_order()
board_init_f()
board_init_r()
spl_start_uboot()
Just grep for 'env_init(' to find the code locations.
You will have to implement one of the functions.

Related

How to create new environment variable for CAN database in CANoe for CAPL and Panels?

I am new to CAPL and CANoe.
I want to access some particular signals from CAN database.
I am able to create new system variables for Panel designing, but for some specific scenario, I want to use CAN signals directly as environmental variables.
I am unable to add new environment variables in the database, could anyone help me?
I want to access some particular signals from CAN database.
You can do this easily from a CAPL script or a Panel. In CAPL script, start typing the name of the signal, or its identifier. If you set up a dbc file with that CANoe configuration, you'll have access to auto-complete functions.
From a Panel, select a suitable UI control, then go into properties and see that you can link it to a given signal, provided you set up a dbc for that CANoe configuration.
I am able to create system variables for PANEL designing , but for
some specific scenario , i want to use CAN signals directly as
environmental variable .
You can create System Variables, but are not interested in them. You want to use CAN signals as Environment variables.
CAN signals are meant to be physical signals transmitted over a bus (CAN, LIN etc..). Environment Variables are digital signals living in the CANoe simulation. They will never be transmitted over a bus. On a side note, you can map a signal over a variable using the Environment > Signal Mapping function of CANoe, from the ribbon.
I am unable to add database in environmetal variable
Many pages of the help are referring to env vars being usable only if they were added to the Database, but then again via the CANoe Ribbon there is no way of adding new Environment Variables, and this is were you are confused.
To set new Environment Variables, you'll need CANdb++. To see existing Environment Variables, go View > List > Environment Variables. From here, you can add new env vars to the database.
Env Vars are typically used as interface between network nodes and specifically in panels as handles.
More details at : https://support.vector.com/kb?id=kb_article_view&sysparm_article=KB0012412&sys_kb_id=e63502681b2614148e9a535c2e4bcbb1&spa=1
Starting from CANoe and CANalyzer 12 no more new Environment Variables can be created in CANdb++ Editor.
Since CANoe/CANalyzer 7.0 System Variables are supported as a successor of Environment Variables for configurations in CANoe and CANalyzer.
It is still possible to use existing configurations and database files which contain Environment Variables. But it is recommended to use System Variables instead.
As per the vector documentation Environment variables can not be created from the version 12 but can be if there are already created variables. Environment variables are replaced by system variables. But still we have back door to create one. video in the following link
https://www.youtube.com/watch?v=Jhoj2f-XQ18
gives more details about how to create ev variables in CANoe version above 12, But it is good to migrate to system variables, because vector can stop supporting ev variable at any point of time.

How does Linux kernel parse vga= parameter?

I want to boot my Linux 3.18.48 compiled from source, with resolution 640x480. So I'm passing it a parameter vga=0x312. For some reason, it doesn't work.
To understand what's happening, I grep'ed the kernel source for "vga=", expecting some macro __setup("vga=", function_ptr), similar to other kernel cmdline parameters (video=, root=, etc).
However, there's no such occurrence.
So how does the Linux kernel parse vga= parameter?
According to the docs:
vga= [BOOT,X86-32] Select a particular video mode
...
This is actually a boot loader parameter; the value is
passed to the kernel using a special protocol.
So the kernel does not parse this parameter at all. In my case it's GRUB 2.02 parsing this parameter and passing to the kernel through variable gfxpayload, as listed in GRUB's linux command.
Now I can continue investigating why vga= parameter is being ignored, looking at GRUB's source :-)
EDIT
vga= is parsed by GRUB only on legacy BIOS systems.
That's why vga= is being ignored on my machine. Since I'm using a UEFI system, I need to set the gfxpayload variable directly:
set gfxpayload=640x480
Now it sets the resolution correctly.

Using fixed device table instead of udev

I'd like to generate a fixed device table in my embedded Linux image and skip using udev.
Following the Yocto Dev Manual, chapter* 5.18.1*, I've set the 2 variables USE_DEVFS="0" and IMAGE_DEVICE_TABLES = "device_table-mymachine.txt" and removed udev from the variable VIRTUAL-RUNTIME_dev_manager.
But the table was not created and I still need udev to populate devices.
Does anyone have an idea?
I am not sure how you have defined device_table-mymachine.txt but this is device_table-minimal.txt for example.
Secondly, without udev, you need to add another device manager such as BusyBox's mdev by specifying it in your conf/local.conf file as follow:
VIRTUAL_RUNTIME_dev_manager = "mdev"
Note that this will work only with core images that include packagegroup-core-boot

How to configure spi in the driver file insted of giving configuration in the application

I want to write a test driver for mcspi and want to give all configuration in my driver file (instead of using user space application I want to use driver as a test driver and want to create .ko) and want to pass all configuration to the mcspi controller.
The configurations like chip_select, mode, speed, bits etc., Basically all these configurations I want to use for my test driver to check functionality of FIFO mode in the mcspi. I have already enabled FIFO in the mcspi but I want to check its functionality.
Can anyone please give me some suggestions?
I don't really know why cant you do something you want. I think you can pass the configuration by set up parameters using module_param
Adding on what #sunnyleevip suggested: another "standard" way to configure your driver would be to expose the params of interest via the /proc or the /sys filesystems.
You can find all the details in Linux Device Driver
Expanding on #sergico and #sunnyleevip, you could also use device tree to pass configuration data to the driver. The SPI bus master driver (since the 2.6.30s and all of the 3.x kernels) already are pretty devicetree supportive, so there might not be much more to do to get it to work.

Uboot Option to print boot time prefixes

Is there any uboot config option to print boot sequence with time prefixes similar to kernel option CONFIG_PRINTK?
I am expecting output like below,
[ 0.000000] U-Boot 1.1.4-gedeced79 (Feb 6 2012 - 09:27:11)
[ 0.011300] Starting kernel ...
[ 0.015686] Uncompressing Linux... done, booting the kernel
define DEBUG config option is best for your purpose, it is picked up by all u-boot code after you put it in your include/configs/myboard.h. (each config option is '#define', but that is doing strange things in my page preview)
Also
define CONFIG_BOOTSTAGE.
You can look at README for this, code is in common/bootstage.c, its functions do some of what you want. You may have to add a function show_boot_progress() in your BSP, for these functions to be used. With those in place, I believe there are already hooks in infrastructure code for them to get called, but I haven't used this option.
I am not aware of U-Boot config option that does such thing, but there are some other techniques which enables you to do it. I.e. config option inside the Linux kernel.
Take a look at: Measuring Boot-up time

Resources