But after I recompile the Image and boot it, the UEFI gets stuck at the following location:
EFI stub: Exiting boot services and installing virtual address map…
I found that as long as I put the newly defined struct sched_class variable into the location corresponding to “__tt_sched_class” through “__section” , the UEFI startup will get stuck at the above location.
Do you have any ideas?
Thanks in advance.
Can you please provide the full booting log?
How did you make the new kernel image take effect? Did you specify it in /boot/extlinux/extlinux.conf?
Have you tried the same modification on maybe some x86 machines?
I have tried recompiling the kernel in the x86 VM, but it caused the VM to hang.
Going back to Xavier, in the entire startup process, which link is related to the layout of SCHED_DATA or RO_DATA?
For example, UEFI and ATF, are they related to the layout of SCHED_DATA or RO_DATA?
After modifying the layout of SCHED_DATA or RO_DATA, is it necessary to modify UEFI and/or ATF simultaneously?
Cross compiling (on a Linux PC) does not require a VM (it just uses very easily installed cross tools). If you have enough disk space, then native compile directly on the AGX Xavier is also a good choice (e.g., building on a USB3 external SATA drive or a large thumb drive is an option). Are you interested in either of those options (cross compile on Linux PC or native compile on the Xavier)?
Did you start by matching the existing kernel config, or else with target tegra_defconfig? Even if you go minimal, you should start with either the existing “/proc/config.gz” (gunzip and rename as .config), or else the tegra_defconfig. Then use something like make target nconfig or menuconfig to remove what you don’t want (and don’t forget to add CONFIG_LOCALVERSION so modules can be found). If those basics are not met, then it is likely boot would fail.
Do you mean maybe they occupy more space in kernel memory now and overwrite UEFI?
I’m not that familiar with kernel source so I cannot make sure, but if it does not work even on x86 machines, then clearly your code is buggy.
Thanks for your reply.
The purpose of making such changes is to do a simple experiment of adding a new scheduler class. The background of this matter is the subject of deterministic scheduler in the kernel. As you can see, let alone this subject, simply adding a scheduling class is problematic.
Back to the topic of exceptions triggered by UEFI startup.
I am using jacpack5.1.2, please help to check if there is any problem with the compilation steps:
edkrepo checkout r35.4.1
Okay, this problem does not seem to be a nvidia problem, it is probably just a common problem in the linux kernel of the ARM platform. My current idea is to see more startup information through the debug version of UEFI. Just now, my newly compiled UEFI can be started. The previous inability to boot was actually caused by the case of the file name. Next I will analyze the UEFI information. If there are any nvidia-related problems that cannot be solved, please continue to help.