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 <tr...@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.ku...@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? -- Tom
signature.asc
Description: PGP signature
