I want to buy the Jetson Tx2 in order to do some deep dive. According to their Docs, the Bootloader at some point executes the C-Boot followed by U-Boot. C-Boot runs with Exception Level (EL) 2, does somebody know whether C-Boot passes EL 2 to U-Boot (or C-Boost passes EL 3 to U-Boot)?
If you have a Tx2 you could simply test it by:
dmesg | grep EL
Thanks in advance!
TF-A drops to EL2 before invoking Cboot. See https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3231/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fbootflow_tx2.html%23. U-Boot then also runs at EL2. If you want to run software in the secure zone, you could use OP-TEE.
Should U-Boot be called in EL3 and you boot via UEFI U-Boot will drop to EL2 before loading the EFI binary by calling the function switch_to_non_secure_mode().
Related
I'm trying to offload a small EBPF program to the NIC that uses a map. I can lookup elements in the hash map, but when I add the command bpf_map_update_elem I get back an error when I attempt to load.
14: (85) call bpf_map_update_elem#2
[nfp] map_update: not supported by FW
The driver I'm running:
$ ethtool -i $ETHNAME
driver: nfp
version: 5.15.0-27-generic
firmware-version: 0.0.3.5 0.31 bpf-2.0.6.124 ebpf
expansion-rom-version:
bus-info: 0000:06:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
According to https://www.netronome.com/media/documents/UG_Getting_Started_with_eBPF_Offload.pdf this function should be supported.
Has anybody found a solution?
The document you link states:
Since Kernel 4.17, map updates are supported by our driver. As of this writing, our public firmware does
not contain map update support from the datapath, but this is available on request.
You should contact Netronome's customer support service to get the version of the firmware which supports map updates.
(I worked on this guide and can confirm that, to my knowledge, the firmware with map updates has not been publicly released.)
For example in a videa about u-boot, https://www.youtube.com/watch?v=INWghYZH3hI, near time 43:01, I see the lecturer gives u-boot the kernel address and fdt address but not the initramfs address. (bootz 0x80000000 - 0x80800000) but linux boots to the login prompt and he can log in.
How come this is possible? I understand after the kernel boots it starts init process in the initramfs.(I forgot there were a precedence). Without initramfs, how is it possible to run login process or shell?
(it's related to programming so I ask it here. If requested I can move it to unix stackexchange. Is there a method of moving a question to somerewhere else automatically? guess not..)
this is what I learned from the comments with combination with my previous knowledge.
you can embed the initramfs.tar.gz file in the kernel binary image using CONFIG_INITRAMFS_SOURCE=nitramfs.cpio.gz in the configuration. (menuconfig). The initramfs image is placed at the end of the kernel image maybe (I remember).
But this was not the case in the youtube video I mentioned in my question. Near 40:29 in the video, the kernel boot command is shown to have "root=/dev/mmcblk0p1 rootfstype=ext4 rootwait console=tty0e,115200". So it's telling the kernel to use SD card 0's partition 1 as the root system after boot, instead of using initramfs.(when you want to use initramfs, you specify root=/dev/ram and pass the initramfs location. in qemu you use -initrd initramfs.cpio.gz option, or in real machine this information is passed through the device tree to the kernel, in the chosen node's initrd-start and initrd-end address.).
I'd like to boot the raspberry pi with a device-tree-driven linux kernel, is there anything special to do to do that?
Can anyone point what are required to set up a device-tree-based kernel boot up for the raspberry pi.
I may need to have raspberry pi kernel source where drivers for devices should be compatible with device tree. If so, where can I find such kernel sources for Raspberry Pi?
Device-Tree support on Raspberry Pi
Raspberry Pi embeds an ARM11 SoC: Broadcom BCM2835. Device Tree (DT) support for ARM is fairly new, but it seems that it has made its way to the Raspberry Pi CPU. You can find a DT for the Raspberry Pi in arch/arm/boot/dts/bcm2835.dts*.
However the default config file bcm2835_defconfig does not enable device tree:
$ grep DT arch/arm/configs/bcm2835_defconfig
<nothing interesting>
I expected something like CONFIG_OF*=y or CONFIG_USE_OF=y. Bad news: that is going to be tough and long (3 noob.month ?).
is there anything special to do to do that?
It depends on your current linux kernel version. Chances are that your current linux already uses the device-tree (linux-3.7 or later ?).
If not, there are wide changes that you need to study:
Device-Tree impact on a system
Device Tree completely changes the way Linux kernel boots. It impacts:
your bootloader (e.g. u-boot.bin). U-Boot must know how to handle device-tree. Old U-Boots do not know what a device-tree is...
the Linux kernel image (e.g. zImage). Linux must know that it has to fetch its hardware description in the device-tree.
the flash/SD card partition layout. You need to make room for the device tree file itself.
Impact means: you need a way to compile/program these images: full-source, build environment, UART access, potentially JTAG hardware. Changing the bootloader without JTAG is usually suicide, except (today) you can reprogram your SD card off the board safely.
You might find references to OpenFirmware (OF) when talking about device tree. OpenFirmware was the original specification on IBM PowerPC before the Device Tree convention was chosen. Code related to device-tree is prefixed with of_ in linux. Not intuitive, I know...
Please read:
http://devicetree.org/Main_Page
Documentation/devicetree
How to generate the Device-Tree Binary (.dtb)?
Example on a PowerPC board using buildroot:
/usr/bin/make -j5 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=powerpc INSTALL_MOD_PATH=/home/evigier/buildroot/output/target CROSS_COMPILE=" /home/evigier/buildroot/output/host/usr/bin/powerpc-buildroot-linux-gnu-" DEPMOD=/home/evigier/buildroot/output/host/sbin/depmod -C /home/evigier/buildroot/output/build/linux-master mpc8347.dtb
Example U-Boot console output on a PowerPC board:
Uncompressing Kernel Image ... OK
kernel loaded at 0x00000000, end = 0x006f8780
## cmdline at 0x0ff1b900 ... 0x0ff1b925
## initrd_high = 0xffffffff, copy_to_ram = 1
ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
## device tree at 00780000 ... 00781f57 (len=20312 [0x4F58])
Loading Device Tree to 0ff16000, end 0ff1af57 ... OK
## Transferring control to Linux (at address 00000000) ...
Booting using OF flat tree..
Happy hacking :-)
While in u-boot of my ARM based board (DM368) I mark some kernel partition block manually as bad. U-boot says that it was marked and, for example, while writing/reading kernel image I see it skipping this bad block.
But when I try to write the same partition from within Linux (loaded via NFS) I see that Linux nandwrite command USES this bad block! I checked this in several ways - Linux ignores bad block mark for 100%. But everywhere in the internet it is said that BBT is one for both u-boot and Linux.
So, where is the catch?
OK, the answer is found.
For some unclear reason Texas Instruments, manufacturer of the board DM365EVM which I use for development, provides the kernel with different BBT structure. They defined BBT offset as 2, while all the world, including the provided u-boot, defines this offset as 8.
I wish them a good health for many years.
From my understanding, after a PC/embedded system booted up, the OS will occupy the entire RAM region, the RAM will look like this:
Which means, while I'm running a program I write, all the variables, dynamic memory allocated in the stacks, heaps and etc, will remain inside the region. If I run firefox, paint, gedit, etc, they will also be running in this region. (Is this understanding correct?)
However, I would like to shrink the OS region. Below is an illustration of how I want to divide the RAM:
The reason that I want to do this is because, I want to store some data receive externally through the driver into the Custom Region at fixed physical location, then I will be able to access it directly from the user space without using copy_to_user().
I think it is possible to do that by configuring u-boot, but I have no experience in u-boot, can anyone give me some directions where to begin with, such as: do I need to modify the source of u-boot, or changing the environment variables of u-boot will be sufficient?
Or is there any alternative method of doing this?
Any help is much appreciated. Thanks!
p/s: I'm using TI ARM processor, and booting up from an SD card, I'm not sure if it matters.
The platform is ARM. min_addr and max_addr will not work on these platform since these are for Intel-only implementations.
For the ARM platform try to look at "mem=size#start" kernel parameter. Read up on Documentation/kernel-parameters.txt and arch/arm/kernel/setup.c. This option is available on most new Linux code base (ie. 2.6.XX).
You need to set the following parameters:
max_addr=some_max_physical
min_addr=some_min_physical
to be passed to the kernel through uboot in the 'bootargs' u-boot environment variable.
I found myself trying to do the opposite recently - in other words get Linux to use the additional memory in my system - although I'm using Barebox rather than u-boot on a OMAP4 platform.
I found (a bit to my surprise) that once the Barebox MLO first stage boot-loader was aware of the extra RAM, the kernel then detected and used it as well without any bootargs. Since the memory size is not passed anywhere on the boot-line, I can only assume the kernel inspects the memory mappings set up by the boot-loader to determine RAM size. This suggests that modifying your u-boot to not map all of the RAM is the way to go.
On the subject of boot-args, there was a time when you it was recommended that you mapped out a chunk of RAM (used by the frame buffer?) on OMAP4 systems, using the boot-line. It's still unclear whether this is still necessary.