On Tue, May 07, 2024 at 03:26:18PM +0200, Michal Simek wrote:
Hi Tom,
út 7. 5. 2024 v 15:20 odesílatel Tom Rini trini@konsulko.com napsal:
On Tue, May 07, 2024 at 11:22:45AM +0530, Love Kumar wrote:
On 04/05/24 1:48 am, Tom Rini wrote:
On Fri, May 03, 2024 at 05:39:46PM +0530, Love Kumar wrote:
Add tests for booting image using tftpboot/pxe boot commands,
tftpboot
boot case loads the FIT image into DDR and boots using bootm command whereas pxe boot cases downloads the pxe configuration file from the TFTP server and interprets it to boot the images mentioned in the pxe configurations file. This test relies on boardenv_* containing configuration values
including
the parameter 'pattern'. tftpboot/pxe boot cases boots the Linux
till the
boot log pattern value is matched. For example, if the parameter 'pattern' is defined as 'login:', it will boot till login prompt.
Signed-off-by: Love Kumar love.kumar@amd.com
I'm not quite sure where the problem is, next. After enabling FIT image support in my build so I can use the image I have on hand: U-Boot> tftpboot 200000 v6.6/image.fit.nocomp Waiting for Ethernet connection... done. Using smsc95xx_eth device TFTP from server 192.168.1.10; our IP address is 192.168.1.100 Filename 'v6.6/image.fit.nocomp'. Load address: 0x200000 Loading: ################################################## 82 MiB 3.2 MiB/s done Bytes transferred = 85984256 (5200400 hex) U-Boot> U-Boot> crc32 200000 $filesize CRC32 for 00200000 ... 054003ff ==> 754c839a U-Boot> U-Boot> bootm 200000 ## Loading kernel from FIT Image at 00200000 ... Could not find configuration node ERROR -2: can't get kernel image! U-Boot>
And in u_boot_boardenv_rpi_arm64.py: env__tftp_boot_test_skip = False
env__net_tftp_bootable_file = { 'fn': 'v6.6/image.fit.nocomp', 'addr': 0x00200000, 'size': 85984256, 'crc32': '754c839a', 'pattern': 'Linux', 'config': 'conf-852', }
But it's not trying to boot conf-852 but instead just passing the address. This image lacks a default config, which your example has and
I
think is why the tests work in your case.
Hi,
Yes, this case expects to have some default config in fit image as it
uses
'bootm <addr>' command to boot, below change in fit image should work.
configurations { default = "conf-852";
test_net_tftpboot_boot_config - This case will boot from the given
config:
'bootm 200000#conf-852'
I wasn't clear, sorry. The problem is that since we define the config to use, which is good, we need to then use it. I intentionally have a FIT image that supports every aarch64 platform and I'd rather use it for every platform and not a per-platform FIT image.
What about putting those two tests together? I mean if config is not defined used default configuration, if config is defined use it.
So, I followed up with another email too about tests for FIT vs tests for OS boot. If we update the exiting FIT tests to test that the default config is used if present would that be a better way to cover the intent here?