Linux boot commands for memory boot on am335x - linux-kernel

I am using am335x based custom board. I have only uart port for loading images to memory. I was able to get u-boot working. What are the load addresses for the linux kernel and the dts file. What will be boot command for running the loaded kernel from memory.

The DDR on Am335x starts at address 0x80000000. The ending address depends on the size of your DDR RAM. For a 128MB RAM, you have the last addres at 0x88000000 So you can load your kernel anywhere. Make sure you load the device tree blob toward the end of the RAM and set the following for u-boot
setenv fdt_high 0x88000000
This ensures that fdt is not relocated outside the max address of your ram.
Your basic bootargs will be
console=ttyO0,115200n8 earlyprintk=serial mem=128m
Anything else depends on your rootfs which can be on mmc or sd.

Refer TI AM335x links for loading kernel and dtb images from different places,
below links explains load address as well commands to load and run,
AM335x User's Guide
AMSDK u-boot User's Guide

Related

Barebox booting u-boot using bootm

I have got a Board with NXP LS1021A which regularly boot Barebox from a QSPI rom partition.
Unfortunately this bootloader has several compatibility problems with my board, so I would like to use Barebox for booting a u-boot image from another partition on the same QSPI rom. I regularly modified and compiled u-boot for the board, changing the starting address to be compatible with the new partition. This is ok.
Problem is related to u-boot execution as my Barebox has problem with direct “go” command (seems not to be able to se direct addresses of partitioned flash) but I am able to use bootm in the partition.
So I try the command
bootm /dev/flash.uboot-partition
Unfortunately says “no handle for uImage format“. uImage is correctly checked and is fine.
Is there a way to do this?
Thanks in advance
I tried bootm command, I expected u-Boot to be booted.

External xilinx PCie driver with Yocto

I compiled the xilinx pcie driver using this as a starting point.
https://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules
and then instead of using this to the prebuilt image:
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
I copy kernel file .ko directly to the image as:
fs#fs:/opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/met/0.1-r0$ scp xpcie.ko root#172.17.100.101:/lib/modules
then when I insert this kernel module with hardware connected:
root#imx7d-phyboard-zeta-001:/lib/modules# insmod /lib/modules/xpcie.ko
Base hw val 0
Base hw len 0
BAR0 of 0K
BAR0 of 0M
xpcie: Init: Could not remap memory.
insmod: ERROR: could not insert module /lib/modules/xpcie.ko: Operation
not permitted
root#imx7d-phyboard-zeta-001:/lib/modules#
What is the reason?
Is it not allowed to copy kernel directly on already built image like this?
Futhermore when I add it to the image as in local.conf file:
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
again built and load the image, it is not available in /lib/modules/ directory. Where i can find it? or using other 3 methods will be better?
Using insmod to install the driver is the right thing to do. It does not seem to be the cause of the problem you are seeing.
When you build the driver, the .ko file will usually be in the source directory where you built it, unless you make modules_install.
Getting back to the actual problem:
Looking at the driver source, the message "Could not remap memory" indicates that the driver could not map the PCIE memory region into the kernel address space.
Looks like the base address registers were not configured. On all the machines I use, the BIOS has to configure the base address registers before Linux can use the device.
We program the FPGA, reboot the machine, and then load the driver and use the FPGA. Did you try this? Does your FPGA show up with lspci?
Once the FPGA is programmed, if the PCIE configuration does not change you can tell the kernel to rescan and it will write the base address registers with the same values.

How does U-Boot communicate with Linux kernel?

I'm reading the book and it tells that:
After U-Boot loads Linux kernel, the kernel will claim all the resources of U-Boot
What does this mean? Does it mean that all data structures that allocated in U-Boot will be discarded?
For example: during U-Boot, PCIE and Network Device will be initialized.
After booting Linux kernel, will the PCIE and Network Device data structure be discarded? Will the Linux kernel do PCIE and NEtwork initialize again? Or U-Boot will transfer some data to kernel?
It depends on your CPU architecture how the communication happens, but it is usually via a special place in RAM, flash or the filesystem. No data structures are transferred, they would be meaningless to the kernel and the memory space will be different between the two. Uboot generally passes boot parameters like what type of hardware is present, what memory to use for something, or which type of mode to use for a specific driver. So yes, the kernel will re-initialize the hardware. The exception may be some of the low level CPU specifics which the kernel may expect uboot or a BIOS to have setup already.
Depending on your architecture, there may be different mechanism for the u-boot to communicate with the Linux kernel.
Actually there may be some structures defined by u-boot which are transferred to and used by the kernel using ATAGS. The address in which these structure are passed is stored in r2 register on ARM. They convey information such as available RAM size and location, kernel command line, ...
Note that on some architectures (like ARM again) we have support for device-tree which intends for defining the hardware in which the kernel is going to be run as well as kernel command line, memory and other thins. Such description is usually created during kernel compile time, loaded into the memory by the u-boot and in case of ARM architecture, its address is transferred through r2 register.
The interesting thing about this (regarding your question) is that u-boot can change this device-tree structure before passing it to the kernel through device tree overlay mechanism. So this is a (relatively) new way of u-boot/kernel communication. Note that device-tree is not supported on some architectures.
And at the end, yes, the hardware is reinitialized by the kernel even in they have already initialized by the u-boot except for memory controller and some other very low level initialization, AFAIK.

How to add new device in uboot?

I want to access the different peripherals of i-MX6 at uboot level but I don't know how to do that?
How to add support for new devices in u-boot?
what are the differences between drivers present in u boot level and kernel level?
The five (4) boot phases.
1.ROM loads x-load (MLO)
2.X-load loads u-boot --> Primary boot-loader
3.U-boot reads commands/Load kernel --> Secondary Boot-Loader
4.Kernel reads root file system.
x-loader (Primary Boot-Loader) :
The x-loader configures the pin muxing, clocks, DDR, and serial console, so that it can access and load the second stage bootloader (u-boot) into the DDR
U-Boot (Secondary Boot-Loader) :
The u-boot can perform CPU dependent and board dependent initialization and configuration not done in the x-loader. The u-boot also includes fastboot functionality for partitioning and flashing the eMMC. The u-boot runs on the Master CPU (CPU ID 0), which is responsible for the initialization and booting; at the same time, the Slave CPU (CPU ID 1) is held in the “wait for event” state.
U-Boot is kind of firmware. It'll basically initialize basic functionality. Like Display, CPU0, FastBoot functionality, Create a temporary file system for loading a kernel and Loading Kernel.
Kernel Driver :
A device driver is a program that controls a particular type of device that is attached to your computer. There are device drivers for printers, displays,Touch, CD-ROM readers, diskette drives, and so on.
U-Boot is mainly for loading a Operating System (Kernel). Device Driver is part of kernel for controlling a device. you want to accesses your device in u-boot loader then you will have to initialize all need hardware for your device like memory an all.

Not able to mount rootfs on zedboard

I am having issues in loading my root fs and after inspecting the Kernel Log it says some thing like
"INITRD: 0x1f8ca000+0x0028ac63 is not a memory region - disabling initrd"
What does this mean?
Background
I am running linux on one core of an ARM Cortex A9 and trying to run another baremetal application on another core. I have changed the device tree to reflect this and i am reserving part of the SDRAM for Linux and part for the bare-metal application. I am using Uboot. Is this something to do with the uboot?
Cheers,
S
As you are NOT dedicating the entire RAM to the Linux kernel on the main core, you will need to ensure that the intrd load address specified in the bootargs is accesible from the main core.
Next, this info is usually passed to the Linux kernel in bootargs passed from u-boot as
initrd=<initrd-start-addr>,<initrd-size>
Modify it according to your custom memory-map
Finally in u-boot, load the initrd at the new proper address you just specified and boot the Linux kernel.

Resources