I have an embedded Linux system (i.e just Busybox) with a framebuffer (/dev/fb0) and a serial port (/dev/hvc0).
The serial port is the only method of console input currently.
My Kernel has;
CONFIG_FB=y
CONFIG_FB_SIMPLE=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
My bootargs are currently;
bootargs = "console=hvc0 earlycon=sbi debug";
What I would like to do is use the frame-buffer to display the console output (login terminal, printk output), but with input coming from the serial port (/dev/hvc0).
Can you be more specific regarding the Hw and the OS and u-boot?
You need something like this:
setenv bootargs console=ttyO2,115200n8 vram=16M root=/dev/ram0 rw ramdisk_size=16384 initrd=0x83000000,16M rootfstype=ext2
or this:
setenv bootargs 'console=ttymxc0,115200 root=/dev/mmcblk2p1 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M#60,if=RGB24'
You see, you need to specify the tty = serial port configuration (speed, parity and so on). Also the type of file system ext2, ext4, ... the above are just examples and you need to base yours according to your system.
Related
I am working with an embedded board which supports u-boot.
I am trying to write and read the emmc device connected to the board,
After read, i need to have a look at the contents and compare it with the data that I have written to it.
Is there a way I can log the output of the a u-boot command, when I read a block from eMMC and store it in an address and try to view the contents of
it using:
mmc read 0x10700000 133120 1
mm.l 0x10700000
into a file and then can store the file in an emmc partition or a tftp server ?
Thank you for your time,
Nishad
The save command can be used to write memory to a file.
save file to a filesystem
save <interface> <dev[:part]> <addr> <filename> bytes [pos]
- Save binary file 'filename' to partition 'part' on device
type 'interface' instance 'dev' from addr 'addr' in memory.
'bytes' gives the size to save in bytes and is mandatory.
'pos' gives the file byte position to start writing to.
If 'pos' is 0 or omitted, the file is written from the start.
Of cause this requires the file system to be writable. For FAT this implies building with CONFIG_FAT_WRITE=y.
I am using an arm board using TFTP and NFS but it got stuck at kernel loading as shown in the screenshot and I have to input the run uenvcmd then the process will keep going and everything is OK.
Below is my uEnv.txt:
# This uEnv.txt file can contain additional environment settings that you
# want to set in U-Boot at boot time. This can be simple variables such
# as the serverip or custom variables. The format of this file is:
# variable=value
# NOTE: This file will be evaluated after the bootcmd is run and the
# bootcmd must be set to load this file if it exists (this is the
# default on all newer U-Boot images. This also means that some
# variables such as bootdelay cannot be changed by this file since
# it is not evaluated until the bootcmd is run.
autoload=no
ipaddr=192.168.1.100
serverip=192.168.1.13
gatewayip=192.168.1.1
staticip=${ipaddr}:${serverip}:${gatewayip}:255.255.255.0:::off
bootpath=/tftpboot
rootfspath=/opt/ti-processor-sdk-linux-rt-am57xx-evm-03.00.00.04/targetNFS
#setting for kernel loading
kernel_addr=0x82000000
fdt_addr=0x88000000
nfs_args=setenv bootargs console=ttyO0,115200n8 root=/dev/nfs rw nfsroot=${serverip}:${rootfspath} ip=${staticip}
load_zimage=tftp ${kernel_addr} ${bootpath}/zImage
loadfdt=tftp ${fdt_addr} ${bootpath}/am572x-idk.dtb
boot_zimage=bootz ${kernel_addr} - ${fdt_addr}
uenvcmd=run load_zimage; run loadfdt; run nfs_args; run boot_zimage
these is a strange file called uboot.env beside the uEnv.txt, too long to paste here, uboot.env
Problem solved: Just delete the file uboot.env
This should be a bug of SDK. I will report this to TI. Thanks #Notlikethat
I have a series of questions on how U-boot works on the BeagleBone Black. Everything started with this tutorial on how to use a micro SD card(uSD) as extra storage.
uSD as extra storage on BBB.
Currently my setup looks like this.
$ fdisk -l
Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes #uSD
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 2048 198655 98304 e W95 FAT16 (LBA)
/dev/mmcblk0p2 198656 15523839 7662592 83 Linux
Disk /dev/mmcbk1: 3867 MB, 3867148288 bytes #eMMC
Device Boot Start End Blocks Id System
/dev/mmcblk1p1 * 2048 198655 98304 e W95 FAT16 (LBA)
/dev/mmcblk1p2 198656 7553023 3677184 83 Linux
So if I havent had it wrong this is what happends.
Boot sequence.
1.The BBB is powered.
2.The U-boot is loaded from the eMMC(/dev/mmcblk1p1)
3.The U-boot searches for uEnv.txt file within the uSD(/dev/mmcblk0p1) and loads it.
...... We will retake from here.
In /dev/mmcblk0p1 i have a uEnv.txt file that looks like this.
mmcdev=1
bootpart=1:2
mmcroot=/dev/mmcblk1p2 ro
optargs=quiet
In /dev/mmcblk1p1 i have the default uEnv.txt file that at some point have this lines.
loadkernel=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}
loadinitrd=load mmc ${mmcdev}:${mmcpart} ${initrd_addr} ${initrd_file}; setenv initrd_size ${filesize}
.......
mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} ${kms_force_mode} root=${mmcroot} rootfstype=${mmcrootfstype} ${systemd}
We can see how ${mmcdev}, ${mmcroot}, ${optargs} are used although they arent defined in the file, they are defined uSD uEnv.txt.
Question 1.
¿Does this mean that both uEnv.txt files are loaded?
Retaking the boot sequence.
Boot sequence.
4.The U-boot searches for uEnv.txt file within the eMMC(/dev/mmcblk1p1) and loads it.
5.The Linux kernel is loaded.
When there is no uSD the ${mmcdev}, ${mmcroot}, ${optargs} arguments aren't defined, not in the uEnv.txt at least.
Question 2.
¿Where do the default values come?
Now the part that really bothers me. On another board a have a eMMC uEnv.txt file that looks like this.
optargs=quiet drm.debug=7 capemgr.enable_partno=BB-UART2,BB-UART1
The board boots fine without uSD.
Question 3.
How is that even posible?
The answer to the question should be in your board configuration file. Specifically the definition of 'CONFIG_EXTRA_ENV_SETTINGS'- "Define this to contain any number of null terminated strings (variable = value pairs) that will be part of the default environment compiled into the boot image." (from u-boot README file)
I am trying to get my own build of U-Boot to boot Linux on a Jetson TK1 board. As we are pushing for verified boot I am using the Flat Image Tree (unifying kernel image, device tree blob, ...) to describe my system. U-Boot can load the ITB file and tries to start the kernel but the system hangs after this message.
I assume that this is because no boot arguments are passed to the kernel (the original startup adds loads of arguments) but I am a little dumbfounded on how to pass the arguments to the kernel. I tried setting the bootargs environment variable but this did not change the situation.
How do I pass kernel arguments to the kernel when using an ITB file?
Command line arguments (taken from the APPEND command of the examples extlinux.conf):
console=ttyS0,115200n8 console=tty1 no_console_suspend=1
lp0_vec=2064#0xf46ff000 video=tegrafb mem=1862M#2048M memtype=255 ddr_die=2048M#2048M
section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 vpr=151M#3945M tsec=32M#3913M
otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150
core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter
audio_codec=rt5640 modem_id=0 android.kerneltype=normal usb_port_owner_info=0
fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0
touch_id=0#0 tegra_fbmem=32899072#0xad012000 board_info=0x0177:0x0000:0x02:0x43:0x00
root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt
Content of ITS file:
/dts-v1/;
/ {
description = "Simple image with single Linux kernel and FDT blob";
#address-cells = <1>;
images {
kernel#1 {
description = "Vanilla Linux kernel";
data = /incbin/("./zImage");
type = "kernel";
arch = "arm";
os = "linux";
compression = "none";
load = <0x81008000>;
entry = <0x81008000>;
hash#1 {
algo = "crc32";
};
hash#2 {
algo = "sha1";
};
};
fdt#1 {
description = "Flattened Device Tree blob";
data = /incbin/("./tegra124-pm375.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
hash#1 {
algo = "crc32";
};
hash#2 {
algo = "sha1";
};
};
};
configurations {
default = "conf#1";
conf#1 {
description = "Boot Linux kernel with FDT blob";
kernel = "kernel#1";
fdt = "fdt#1";
};
};
};
U-Boot Output:
Tegra124 (Jetson TK1) # fatload mmc 1 0x90000000 /kernel_fdt.itb
reading /kernel_fdt.itb
5946200 bytes read in 497 ms (11.4 MiB/s)
Tegra124 (Jetson TK1) # bootm 0x90000000
## Loading kernel from FIT Image at 90000000 ...
Using 'conf#1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel#1' kernel subimage
Description: Vanilla Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x900000ec
Data Size: 5910168 Bytes = 5.6 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00000000
Entry Point: 0x00000000
Hash algo: crc32
Hash value: c5b4b377
Hash algo: sha1
Hash value: f001007efe83f563425bfe0659186a32395c946c
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 90000000 ...
Using 'conf#1' configuration
Trying 'fdt#1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x905a30ac
Data Size: 34678 Bytes = 33.9 KiB
Architecture: ARM
Hash algo: crc32
Hash value: e466b23e
Hash algo: sha1
Hash value: ec909ae16e62233d0ed1e1f4c909085abc9b5879
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x905a30ac
Loading Kernel Image ... OK
Using Device Tree in place at 905a30ac, end 905ae821
Starting kernel ...
The salient issue is that the system seems to hang after U-Boot outputs the text
Starting kernel ...
If an uncompressed kernel Image file has been loaded, then the actual kernel startup code would be executed next.
But if a uImage or zImage file has been loaded (which are also reported as "uncompressed" because they are self-extracting), then the next code executed would be the decompression routine that is attached to the zImage file. Normally this decompression routine will output text such as
Uncompressing Linux............ done, booting the kernel.
before the actual kernel startup code would be executed, before any processing of the kernel command line, before any processing of the Device Tree blob, and prior to any console output from the kernel (including earlyprintk).
There's a discrepancy between the kernel load & start addresses specified in the image header
Load Address: 0x00000000
Entry Point: 0x00000000
versus what is specified in the DT:
load = <0x81008000>;
entry = <0x81008000>;
Since the kernel image is temporarily loaded at
## Loading kernel from FIT Image at 90000000 ...
the addresses in the DT would seem to be correct, and the addresses in the image header are bogus.
Assuming that there is no physical RAM at 0x00000000, the result will be that the kernel image is copied (or decompressed) to the bogus load address of 0, and then the kernel image will be executed by branching to the bogus entry point of 0. The CPU is likely to hang trying to execute garbage from nonexistent memory, and that correlates perfectly with what you report.
Solution is (1) confirm that the kernel is linked to the correct address and (2) to specify the correct addresses in the mkimage command using the -a and -e command options.
This correction should at least get you past this one point.
When using device tree, you still use bootargs to provide arguments.
Check that:
You have compiled the tree (using compiler scripts/dtc/dtc inside the Linux kernel)
Support for device tree is enabled in the kernel config (symbol CONFIG_USE_OF) (where OF stands for "Open Firmware")
You provided U-Boot the address of the tree: bootm <uImage address> - <dtb address>
Serial console is enabled in the kernel config under Device Drivers -> Character Devices -> Serial Drivers
Console is enabled in bootargs (e.g., console=ttyS0,115200)
I experienced the same or similar issue. My solution (or work around) for this issue was to set the U-Boot environment variables initrd_high and fdt_high to an address in RAM before the relocated U-boot (in my case 8effffff).
I have a beagle bone which has 256Mb of memory which has the dtb file.
memory{
device_type = "memory";
reg = <0x80000000 0x10000000>;
};
I expect the following change to reduce the available physical memory by 1Mb which i plan to access using io_pfn_page_range() in my driver.
memory{
device_type = "memory";
reg = <0x80000000 0x0FF00000>;
};
But even after the change the /proc/meminfo does not reflect the change. Am i missing something. Thanks in advance.
Rakesh
The bootargs passed through uEnv.txt using mem=255M does the required change. The dtb change is not respected though.
devices-tree(dts) changes will be over written by uboot
Option1:
Add mem=255M , in bootargs
Eg: setenv bootargs 'root=/dev/ram rw console=ttyS0,115200 mem=255M
Option2:
setenv bootm_size 0xFF00000