spl: Add semihosting boot method
This adds a boot method for loading the next stage from the host. It is
mostly modeled off of spl_load_image_ext. I am not really sure why/how
spl_load_image_fat uses three different methods to load the image, but
the simple case seems to work OK for now.
To control the presence of this boot method, we add a config symbol.
While we're at it, we update the original semihosting config symbol.
I think semihosting has some advantages of other forms of JTAG boot.
Common other ways to boot from JTAG include:
- Implementing DDR initialization through JTAG (typically with dozens of
lines of TCL) and then loading U-Boot. The DDR initialization
typically uses hard-coded register writes, and is not easily adapted
to different boards. BOOT_DEVICE_SMH allows booting with SPL,
leveraging U-Boot's existing DDR initialization code. This is the
method used by NXP's CodeWarrior IDE on Layerscape processors (see
AN12270).
- Loading a bootloader into SDRAM, waiting for it to initialize DDR, and
then loading U-Boot. This is tricky, because the debugger must stop the
boot after the bootloader has completed its work. Trying to load
U-Boot too early can cause failure to boot. This is the method used by
Xilinx with its Zynq(MP) processors.
- Loading SPL with BOOT_DEVICE_RAM and breaking before SPL loads the
image to load U-Boot at the appropriate place. This can be a bit
tricky, because the load address is dependent on the header size. An
elf with symbols must also be used in order to stop at the appropriate
point. BOOT_DEVICE_SMH can be viewed as an extension of this process,
where SPL automatically stops and tells the host where to place the
image.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
2022-03-22 20:59:19 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
|
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2022 Sean Anderson <sean.anderson@seco.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <common.h>
|
|
|
|
|
#include <image.h>
|
|
|
|
|
#include <log.h>
|
|
|
|
|
#include <semihosting.h>
|
|
|
|
|
#include <spl.h>
|
2023-11-08 16:48:55 +00:00
|
|
|
#include <spl_load.h>
|
spl: Add semihosting boot method
This adds a boot method for loading the next stage from the host. It is
mostly modeled off of spl_load_image_ext. I am not really sure why/how
spl_load_image_fat uses three different methods to load the image, but
the simple case seems to work OK for now.
To control the presence of this boot method, we add a config symbol.
While we're at it, we update the original semihosting config symbol.
I think semihosting has some advantages of other forms of JTAG boot.
Common other ways to boot from JTAG include:
- Implementing DDR initialization through JTAG (typically with dozens of
lines of TCL) and then loading U-Boot. The DDR initialization
typically uses hard-coded register writes, and is not easily adapted
to different boards. BOOT_DEVICE_SMH allows booting with SPL,
leveraging U-Boot's existing DDR initialization code. This is the
method used by NXP's CodeWarrior IDE on Layerscape processors (see
AN12270).
- Loading a bootloader into SDRAM, waiting for it to initialize DDR, and
then loading U-Boot. This is tricky, because the debugger must stop the
boot after the bootloader has completed its work. Trying to load
U-Boot too early can cause failure to boot. This is the method used by
Xilinx with its Zynq(MP) processors.
- Loading SPL with BOOT_DEVICE_RAM and breaking before SPL loads the
image to load U-Boot at the appropriate place. This can be a bit
tricky, because the load address is dependent on the header size. An
elf with symbols must also be used in order to stop at the appropriate
point. BOOT_DEVICE_SMH can be viewed as an extension of this process,
where SPL automatically stops and tells the host where to place the
image.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
2022-03-22 20:59:19 +00:00
|
|
|
|
2023-07-22 19:27:48 +00:00
|
|
|
static ulong smh_fit_read(struct spl_load_info *load, ulong file_offset,
|
|
|
|
|
ulong size, void *buf)
|
|
|
|
|
{
|
2023-11-08 16:48:36 +00:00
|
|
|
long fd = *(long *)load->priv;
|
2023-07-22 19:27:48 +00:00
|
|
|
ulong ret;
|
|
|
|
|
|
2023-11-08 16:48:36 +00:00
|
|
|
if (smh_seek(fd, file_offset))
|
2023-07-22 19:27:48 +00:00
|
|
|
return 0;
|
|
|
|
|
|
2023-11-08 16:48:36 +00:00
|
|
|
ret = smh_read(fd, buf, size);
|
|
|
|
|
return ret < 0 ? 0 : ret;
|
2023-07-22 19:27:48 +00:00
|
|
|
}
|
|
|
|
|
|
spl: Add semihosting boot method
This adds a boot method for loading the next stage from the host. It is
mostly modeled off of spl_load_image_ext. I am not really sure why/how
spl_load_image_fat uses three different methods to load the image, but
the simple case seems to work OK for now.
To control the presence of this boot method, we add a config symbol.
While we're at it, we update the original semihosting config symbol.
I think semihosting has some advantages of other forms of JTAG boot.
Common other ways to boot from JTAG include:
- Implementing DDR initialization through JTAG (typically with dozens of
lines of TCL) and then loading U-Boot. The DDR initialization
typically uses hard-coded register writes, and is not easily adapted
to different boards. BOOT_DEVICE_SMH allows booting with SPL,
leveraging U-Boot's existing DDR initialization code. This is the
method used by NXP's CodeWarrior IDE on Layerscape processors (see
AN12270).
- Loading a bootloader into SDRAM, waiting for it to initialize DDR, and
then loading U-Boot. This is tricky, because the debugger must stop the
boot after the bootloader has completed its work. Trying to load
U-Boot too early can cause failure to boot. This is the method used by
Xilinx with its Zynq(MP) processors.
- Loading SPL with BOOT_DEVICE_RAM and breaking before SPL loads the
image to load U-Boot at the appropriate place. This can be a bit
tricky, because the load address is dependent on the header size. An
elf with symbols must also be used in order to stop at the appropriate
point. BOOT_DEVICE_SMH can be viewed as an extension of this process,
where SPL automatically stops and tells the host where to place the
image.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
2022-03-22 20:59:19 +00:00
|
|
|
static int spl_smh_load_image(struct spl_image_info *spl_image,
|
|
|
|
|
struct spl_boot_device *bootdev)
|
|
|
|
|
{
|
|
|
|
|
const char *filename = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME;
|
|
|
|
|
int ret;
|
|
|
|
|
long fd, len;
|
2023-11-08 16:48:55 +00:00
|
|
|
struct spl_load_info load;
|
spl: Add semihosting boot method
This adds a boot method for loading the next stage from the host. It is
mostly modeled off of spl_load_image_ext. I am not really sure why/how
spl_load_image_fat uses three different methods to load the image, but
the simple case seems to work OK for now.
To control the presence of this boot method, we add a config symbol.
While we're at it, we update the original semihosting config symbol.
I think semihosting has some advantages of other forms of JTAG boot.
Common other ways to boot from JTAG include:
- Implementing DDR initialization through JTAG (typically with dozens of
lines of TCL) and then loading U-Boot. The DDR initialization
typically uses hard-coded register writes, and is not easily adapted
to different boards. BOOT_DEVICE_SMH allows booting with SPL,
leveraging U-Boot's existing DDR initialization code. This is the
method used by NXP's CodeWarrior IDE on Layerscape processors (see
AN12270).
- Loading a bootloader into SDRAM, waiting for it to initialize DDR, and
then loading U-Boot. This is tricky, because the debugger must stop the
boot after the bootloader has completed its work. Trying to load
U-Boot too early can cause failure to boot. This is the method used by
Xilinx with its Zynq(MP) processors.
- Loading SPL with BOOT_DEVICE_RAM and breaking before SPL loads the
image to load U-Boot at the appropriate place. This can be a bit
tricky, because the load address is dependent on the header size. An
elf with symbols must also be used in order to stop at the appropriate
point. BOOT_DEVICE_SMH can be viewed as an extension of this process,
where SPL automatically stops and tells the host where to place the
image.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
2022-03-22 20:59:19 +00:00
|
|
|
|
|
|
|
|
fd = smh_open(filename, MODE_READ | MODE_BINARY);
|
|
|
|
|
if (fd < 0) {
|
|
|
|
|
log_debug("could not open %s: %ld\n", filename, fd);
|
|
|
|
|
return fd;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = smh_flen(fd);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
log_debug("could not get length of image: %d\n", ret);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
len = ret;
|
|
|
|
|
|
2023-11-08 16:48:55 +00:00
|
|
|
load.read = smh_fit_read;
|
|
|
|
|
spl_set_bl_len(&load, 1);
|
|
|
|
|
load.priv = &fd;
|
|
|
|
|
ret = spl_load(spl_image, bootdev, &load, len, 0);
|
spl: Add semihosting boot method
This adds a boot method for loading the next stage from the host. It is
mostly modeled off of spl_load_image_ext. I am not really sure why/how
spl_load_image_fat uses three different methods to load the image, but
the simple case seems to work OK for now.
To control the presence of this boot method, we add a config symbol.
While we're at it, we update the original semihosting config symbol.
I think semihosting has some advantages of other forms of JTAG boot.
Common other ways to boot from JTAG include:
- Implementing DDR initialization through JTAG (typically with dozens of
lines of TCL) and then loading U-Boot. The DDR initialization
typically uses hard-coded register writes, and is not easily adapted
to different boards. BOOT_DEVICE_SMH allows booting with SPL,
leveraging U-Boot's existing DDR initialization code. This is the
method used by NXP's CodeWarrior IDE on Layerscape processors (see
AN12270).
- Loading a bootloader into SDRAM, waiting for it to initialize DDR, and
then loading U-Boot. This is tricky, because the debugger must stop the
boot after the bootloader has completed its work. Trying to load
U-Boot too early can cause failure to boot. This is the method used by
Xilinx with its Zynq(MP) processors.
- Loading SPL with BOOT_DEVICE_RAM and breaking before SPL loads the
image to load U-Boot at the appropriate place. This can be a bit
tricky, because the load address is dependent on the header size. An
elf with symbols must also be used in order to stop at the appropriate
point. BOOT_DEVICE_SMH can be viewed as an extension of this process,
where SPL automatically stops and tells the host where to place the
image.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
2022-03-22 20:59:19 +00:00
|
|
|
if (ret)
|
|
|
|
|
log_debug("could not read %s: %d\n", filename, ret);
|
|
|
|
|
out:
|
|
|
|
|
smh_close(fd);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
SPL_LOAD_IMAGE_METHOD("SEMIHOSTING", 0, BOOT_DEVICE_SMH, spl_smh_load_image);
|
