This is a place were we put configurations we tried, and didn't work or did work up to a certain point.
Note to members of the gitbook: I don't know if it is useful to make this person-specific.
This hangs at without supplying device tree with dtb=
If device tree is supplied, cpuidle complains at printed.
[ 0.000000] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 0.000000] cfg80211: failed to load regulatory.db
Testing without device tree from here on
Changed:CONFIG_CFG80211=n
[ 0.000000] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 0.000000] cfg80211: failed to load regulatory.db
This is issue doesn't exist anymore, it just freezes at [ 0.000000] Freeing unused kernel memory: 1024K
Note the line, clock should be 100kHz[ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns
[ 0.000000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.000000] Warning: unable to open an initial console.
It looks like it's using some serial and then is unable to open a console. -> No device tree so it doesn't know /dev/ttyS0 (UART-A)
CONFIG_FB_EFI=y
CONFIG_CMDLINE="console=ttyS0,115200 console=tty0 earlyprintk initcall_debug sched_debug lpj=10000"
It booted, then disabled uart and printed to the screen. Log only contains print from uart. Stuck at the same line.
CONFIG_CMDLINE="console=ttyS0,115200 console=tty0 earlycon earlyprintk initcall_debug sched_debug lpj=10000"
Log should be the same apart from the cmdline. Again, it displayed to display, so log doesn't include that output.
CONFIG_CMDLINE="console=ttyS0,115200 earlycon earlyprintk initcall_debug sched_debug lpj=10000"
Screen with a cursor, all output on uart. But because there is no device tree, no console from initrd.
Testing with device tree from here on
Nothing changed in config. Only added device tree.
Kernel panic: [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000010
Has to do with cpuidle. You can also see complaints about a bad device tree.
Only device tree edits.
Screen has no cursor anymore, only backlight is turned on. You can't print something on it with echo hello >> /dev/fb0
or echo hello >> /dev/tty0
Successful boot to Buildroot.
Note: Log has a lot of entries two times.
CONFIG_VGA_ARB=n
CONFIG_TEGRA_HOST1X=n
CONFIG_DRM=n
No different screen behaviour.
Log has some commands at the bottom.
No config changed. Only device tree edits. Added nodes to it until dtc didn't complain about anything.
Some strange screen behaviour.
[ 0.000000] tegra20-cpufreq tegra20-cpufreq: operating points not found
[ 0.000000] tegra20-cpufreq tegra20-cpufreq: please update your device tree
Looks like some cpu frequency nodes have to be added to device tree.
Only device tree edits.
Screen still doesn't work.
Boots fine to Buildroot. Log has commands at the bottom.
CONFIG_CMDLINE="console=ttyS0,115200 console=tty0 earlyprintk initcall_debug sched_debug lpj=10000"
Found out that screen works, but it gets cleared when Busybox (from ramdisk) starts. At least I think at that point it gets cleared, not 100% sure.
CONFIG_CMDLINE="console=ttyS0,115200 earlyprintk initcall_debug sched_debug lpj=10000"
Minimal device tree with sd-card+emmc+uart, it includes tegra30.dtsi
No display output with this command line, but you get log output when adding console=tty0
, but afterwards it stops around when Busybox takes over.
Added a raspberry pi rootfs. Specifying root= option with efi shell
Display stops working after the line [ 251.431349] tegra-devfreq 6000c800.actmon: Failed to get emc clock
Log contains output from rootfs.
Config reseted. Started from a new one.
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_CMDLINE="console=ttyS0,115200n8 earlyprintk initcall_debug sched_debug lpj=10000 boot_delay=50"
CONFIG_CMDLINE_EXTEND=y
CONFIG_SMP=n
CONFIG_CACHE_L2X0=n
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_TEGRA_UART=y
CONFIG_TEGRA_DEBUG_UARTA=y
CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_BOOT_PRINTK_DELAY=y
and boot_delay=50(cmdline)
are necessary so mmc driver gets loaded early enough.
Log contains a few commands from rootfs.
I'm not sure what changed.
Working display with booted raspberry pi os!
Booting linux with UEFI boot is now possible.
PMIC regulators don't work.
Audio, Wireless, Cameras, Sensors .This is also true for APX boot.
Implement ACPI for arm32. This will help in development for all other devices that run Windows RT too. Why? It removes the need for a device tree and enables us to comunicate with the firmware, which will hopefully enable us to use PMIC stuff. Also we can upstream our ACPI Parking Protocol driver, which is needed for SMP.
Get Audio, Wireless, Cameras, Sensors.
Possibly more, but we don't know about it yet.
Debug Linux kernel with GDB
Clone a Linux tree and run make ARCH=arm defconfig
to make a generic kernel configuration suited for qemu. Now edit the kernel configuration (.config
) and add the following lines at the bottom:
Now run make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)
to compile the kernel. If you get asked about anything, just press enter to use the standard value.
Copy the output zImage (arch/arm/boot/zImage
) to efi/boot/bootarm.efi
on your EFI partition folder in your qemu directory.
Run sudo apt-get install gdb-multiarch
to install GDB on Ubuntu. gdb-mutliarch
is required because normal gdb
package doesn't have support for ARM.
Open up the terminal you want GDB to run in, and change directory to your Linux compilation directory. Then run gdb-multiarch vmlinux
., it will open GDB you and you can now connect to a target with target remote localhost:1234
. At this point GDB will wait for qemu to start. After that you can now debug with qemu, there are tutorials online to show you how to do this.
Go to the directory where your qemu files are located, start qemu as described in Qemu emulation, only change is that you need to add a -s
parameter, this lets qemu know that it starts a GDB server.
Debug Linux kernel within Visual Studio Code
The following steps have to be performed in your Linux source directory.
Create a file called tasks.json
in the directory .vscode
and paste the following contents into it:
You may want to change line 26 and 34, as they point to the directory where your qemu files are located.
See https://go.microsoft.com/fwlink/?LinkId=733558 for the documentation about the tasks.json
format
Create a file called launch.json
in the directory .vscode
and paste the following contents into it:
Use IntelliSense to learn about possible attributes. Hover to view descriptions of existing attributes. For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
Create a file called c_cpp_properties.json
in the directory .vscode
and paste the following contents into it:
Press F5 to start debugging. The following steps will be performed:
Compile Kernel
Copy zImage to qemu EFI partition
Launch qemu
Start GDB debugging
The following keys are important:
F9 for creating a breakpoint
F10 for going a step forward
F11 for stepping into a function
F12 to step out of a function
Run arm32 UEFI in a virtual machine.
Emulating a arm32 UEFI device is useful for developing Linux and debugging it.
In the GDB Debugging page you can find instructions on how to compile Linux for this virtual machine.
A premade ZIP with all required files can be found at the bottom.
Run the following commands to install the required packages.
You will need other stuff too, but that is probably already installed. (e.g. git)
You need the source code of edk2 and acpica.
Go to your source directory and run the following commands.
Your output OVMF firmware file for qemu is$WORKSPACE/Build/ArmVirtQemu-ARM/RELEASEGCC5/FV/QEMU
_EFI.fd
Create a directory, where you want your files to be in. Put your QEMU_EFI.fd
firmware file in this directory, compiled in the previous section. Now run the following commands to create some disk images:
Now create a directory named boot
. This will be your EFI partition. You can now easily place your EFI files in there.
To start your virtual machine run the following command, and make sure qemu-system-arm
is installed.
This will run qemu with 4 virtual CPU cores. They are Coretx-A15 cores. Used because it works.
The following ZIP includes all files setup in their proper location. In addition its EFI partition folder has a UEFI shell in it. To run it either execute the run.sh
file or enter the command described in Run qemu.
Links where the above compiling information is from: