| Message ID | 20191221161340.27047-2-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Bin Meng |
| Headers | show |
| Series | x86: Improve support for chain-loading U-Boot | expand |
Hi Simon, On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote: > > When U-Boot is no the first-stage bootloader much of this code is not > needed and can break booting. Add checks for this to the FSP code. > > Rather than checking for the amount of available SDRAM, just use 1GB in > this situation, which should be safe. Using 2GB may run into a memory > hole on some SoCs. > > Signed-off-by: Simon Glass <sjg@chromium.org> > --- > > arch/x86/lib/fsp/fsp_dram.c | 8 ++++++++ > arch/x86/lib/fsp/fsp_graphics.c | 3 +++ > arch/x86/lib/fsp2/fsp_dram.c | 10 ++++++++++ > arch/x86/lib/fsp2/fsp_init.c | 2 +- > 4 files changed, 22 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c > index 9ce0ddf0d3..15e82de2fe 100644 > --- a/arch/x86/lib/fsp/fsp_dram.c > +++ b/arch/x86/lib/fsp/fsp_dram.c > @@ -44,6 +44,14 @@ int dram_init_banksize(void) > phys_addr_t low_end; > uint bank; > > + if (!ll_boot_init()) { > + gd->bd->bi_dram[0].start = 0; > + gd->bd->bi_dram[0].size = gd->ram_size; > + > + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size); > + return 0; > + } > + I wonder why this change is needed. When booting from other bootloader, this dram_init_banksize() will not be called, no? > low_end = 0; > for (bank = 1, hdr = gd->arch.hob_list; > bank < CONFIG_NR_DRAM_BANKS && !end_of_hob(hdr); > diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c > index 226c7e66b3..98b762209f 100644 > --- a/arch/x86/lib/fsp/fsp_graphics.c > +++ b/arch/x86/lib/fsp/fsp_graphics.c > @@ -78,6 +78,9 @@ static int fsp_video_probe(struct udevice *dev) > struct vesa_mode_info *vesa = &mode_info.vesa; > int ret; > > + if (!ll_boot_init()) > + return 0; > + the same question as above > printf("Video: "); > > /* Initialize vesa_mode_info structure */ > diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c > index 90a238a224..74835eebce 100644 > --- a/arch/x86/lib/fsp2/fsp_dram.c > +++ b/arch/x86/lib/fsp2/fsp_dram.c > @@ -12,11 +12,18 @@ > #include <asm/fsp/fsp_support.h> > #include <asm/fsp2/fsp_api.h> > #include <asm/fsp2/fsp_internal.h> > +#include <linux/sizes.h> > > int dram_init(void) > { > int ret; > > + if (!ll_boot_init()) { > + /* Use a small and safe amount of 1GB */ > + gd->ram_size = SZ_1G; > + ditto. Maybe we should explain on what configuration ll_boot_init() is set to true / false? > + return 0; > + } > if (spl_phase() == PHASE_SPL) { > #ifdef CONFIG_HAVE_ACPI_RESUME > bool s3wake = gd->arch.prev_sleep_state == ACPI_S3; > @@ -68,6 +75,9 @@ int dram_init(void) > > ulong board_get_usable_ram_top(ulong total_size) > { > + if (!ll_boot_init()) > + return gd->ram_size; > + > #if CONFIG_IS_ENABLED(HANDOFF) > struct spl_handoff *ho = gd->spl_handoff; > > diff --git a/arch/x86/lib/fsp2/fsp_init.c b/arch/x86/lib/fsp2/fsp_init.c > index da9bd6b45c..c7dc2ea257 100644 > --- a/arch/x86/lib/fsp2/fsp_init.c > +++ b/arch/x86/lib/fsp2/fsp_init.c > @@ -23,7 +23,7 @@ int arch_cpu_init_dm(void) > int ret; > > /* Make sure pads are set up early in U-Boot */ > - if (spl_phase() != PHASE_BOARD_F) > + if (!ll_boot_init() || spl_phase() != PHASE_BOARD_F) > return 0; > > /* Probe all pinctrl devices to set up the pads */ > -- Regards, Bin
Hi Bin, On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote: > > > > When U-Boot is no the first-stage bootloader much of this code is not > > needed and can break booting. Add checks for this to the FSP code. > > > > Rather than checking for the amount of available SDRAM, just use 1GB in > > this situation, which should be safe. Using 2GB may run into a memory > > hole on some SoCs. > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > --- > > > > arch/x86/lib/fsp/fsp_dram.c | 8 ++++++++ > > arch/x86/lib/fsp/fsp_graphics.c | 3 +++ > > arch/x86/lib/fsp2/fsp_dram.c | 10 ++++++++++ > > arch/x86/lib/fsp2/fsp_init.c | 2 +- > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c > > index 9ce0ddf0d3..15e82de2fe 100644 > > --- a/arch/x86/lib/fsp/fsp_dram.c > > +++ b/arch/x86/lib/fsp/fsp_dram.c > > @@ -44,6 +44,14 @@ int dram_init_banksize(void) > > phys_addr_t low_end; > > uint bank; > > > > + if (!ll_boot_init()) { > > + gd->bd->bi_dram[0].start = 0; > > + gd->bd->bi_dram[0].size = gd->ram_size; > > + > > + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size); > > + return 0; > > + } > > + > > I wonder why this change is needed. When booting from other > bootloader, this dram_init_banksize() will not be called, no? How about this: It is useful to be able to boot the same x86 image on a device with or without a first-stage bootloader. For example, with chromebook_coral, it is helpful for testing to be able to boot the same U-Boot (complete with FSP) on bare metal and from coreboot. It allows checking of things like CPU speed, comparing registers, ACPI tables and the like. The idea is to change ll_boot_init() to false, and rebuild without changing anything else. Regards, Simon
Hi Simon, On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Simon, > > > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > When U-Boot is no the first-stage bootloader much of this code is not > > > needed and can break booting. Add checks for this to the FSP code. > > > > > > Rather than checking for the amount of available SDRAM, just use 1GB in > > > this situation, which should be safe. Using 2GB may run into a memory > > > hole on some SoCs. > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > --- > > > > > > arch/x86/lib/fsp/fsp_dram.c | 8 ++++++++ > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +++ > > > arch/x86/lib/fsp2/fsp_dram.c | 10 ++++++++++ > > > arch/x86/lib/fsp2/fsp_init.c | 2 +- > > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c > > > index 9ce0ddf0d3..15e82de2fe 100644 > > > --- a/arch/x86/lib/fsp/fsp_dram.c > > > +++ b/arch/x86/lib/fsp/fsp_dram.c > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void) > > > phys_addr_t low_end; > > > uint bank; > > > > > > + if (!ll_boot_init()) { > > > + gd->bd->bi_dram[0].start = 0; > > > + gd->bd->bi_dram[0].size = gd->ram_size; > > > + > > > + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size); > > > + return 0; > > > + } > > > + > > > > I wonder why this change is needed. When booting from other > > bootloader, this dram_init_banksize() will not be called, no? > > How about this: > > It is useful to be able to boot the same x86 image on a device with or > without a first-stage bootloader. For example, with chromebook_coral, it > is helpful for testing to be able to boot the same U-Boot (complete with > FSP) on bare metal and from coreboot. It allows checking of things like > CPU speed, comparing registers, ACPI tables and the like. > > The idea is to change ll_boot_init() to false, and rebuild without changing > anything else. This sounds like for a debugging purpose, instead of a supported configuration. So when we boot from previous bootloader, we really should use its configuration, for the coreboot case, coreboot-x86_defconfig should be used, and we can compare the registers, ACPI tables in that configuration, instead of "hacking" current U-Boot codes like in this series. Regards, Bin
Hi Bin, On Mon, 3 Feb 2020 at 10:10, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > Hi Simon, > > > > > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > When U-Boot is no the first-stage bootloader much of this code is not > > > > needed and can break booting. Add checks for this to the FSP code. > > > > > > > > Rather than checking for the amount of available SDRAM, just use 1GB in > > > > this situation, which should be safe. Using 2GB may run into a memory > > > > hole on some SoCs. > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > --- > > > > > > > > arch/x86/lib/fsp/fsp_dram.c | 8 ++++++++ > > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +++ > > > > arch/x86/lib/fsp2/fsp_dram.c | 10 ++++++++++ > > > > arch/x86/lib/fsp2/fsp_init.c | 2 +- > > > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c > > > > index 9ce0ddf0d3..15e82de2fe 100644 > > > > --- a/arch/x86/lib/fsp/fsp_dram.c > > > > +++ b/arch/x86/lib/fsp/fsp_dram.c > > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void) > > > > phys_addr_t low_end; > > > > uint bank; > > > > > > > > + if (!ll_boot_init()) { > > > > + gd->bd->bi_dram[0].start = 0; > > > > + gd->bd->bi_dram[0].size = gd->ram_size; > > > > + > > > > + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size); > > > > + return 0; > > > > + } > > > > + > > > > > > I wonder why this change is needed. When booting from other > > > bootloader, this dram_init_banksize() will not be called, no? > > > > How about this: > > > > It is useful to be able to boot the same x86 image on a device with or > > without a first-stage bootloader. For example, with chromebook_coral, it > > is helpful for testing to be able to boot the same U-Boot (complete with > > FSP) on bare metal and from coreboot. It allows checking of things like > > CPU speed, comparing registers, ACPI tables and the like. > > > > The idea is to change ll_boot_init() to false, and rebuild without changing > > anything else. > > This sounds like for a debugging purpose, instead of a supported > configuration. So when we boot from previous bootloader, we really > should use its configuration, for the coreboot case, > coreboot-x86_defconfig should be used, and we can compare the > registers, ACPI tables in that configuration, instead of "hacking" > current U-Boot codes like in this series. Well the problem is then that we cannot boot the same image with or without coreboot. Also there are various of device-tree things in coral that we need for the laptop to work properly. My idea is to detect coreboot and set ll_boot_init() dynamically if needed. Regards, Simon
Hi Simon, On Tue, Feb 4, 2020 at 1:15 AM Simon Glass <sjg@chromium.org> wrote: > > Hi Bin, > > On Mon, 3 Feb 2020 at 10:10, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Simon, > > > > On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > Hi Bin, > > > > > > On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > Hi Simon, > > > > > > > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > When U-Boot is no the first-stage bootloader much of this code is not > > > > > needed and can break booting. Add checks for this to the FSP code. > > > > > > > > > > Rather than checking for the amount of available SDRAM, just use 1GB in > > > > > this situation, which should be safe. Using 2GB may run into a memory > > > > > hole on some SoCs. > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > --- > > > > > > > > > > arch/x86/lib/fsp/fsp_dram.c | 8 ++++++++ > > > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +++ > > > > > arch/x86/lib/fsp2/fsp_dram.c | 10 ++++++++++ > > > > > arch/x86/lib/fsp2/fsp_init.c | 2 +- > > > > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c > > > > > index 9ce0ddf0d3..15e82de2fe 100644 > > > > > --- a/arch/x86/lib/fsp/fsp_dram.c > > > > > +++ b/arch/x86/lib/fsp/fsp_dram.c > > > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void) > > > > > phys_addr_t low_end; > > > > > uint bank; > > > > > > > > > > + if (!ll_boot_init()) { > > > > > + gd->bd->bi_dram[0].start = 0; > > > > > + gd->bd->bi_dram[0].size = gd->ram_size; > > > > > + > > > > > + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size); > > > > > + return 0; > > > > > + } > > > > > + > > > > > > > > I wonder why this change is needed. When booting from other > > > > bootloader, this dram_init_banksize() will not be called, no? > > > > > > How about this: > > > > > > It is useful to be able to boot the same x86 image on a device with or > > > without a first-stage bootloader. For example, with chromebook_coral, it > > > is helpful for testing to be able to boot the same U-Boot (complete with > > > FSP) on bare metal and from coreboot. It allows checking of things like > > > CPU speed, comparing registers, ACPI tables and the like. > > > > > > The idea is to change ll_boot_init() to false, and rebuild without changing > > > anything else. > > > > This sounds like for a debugging purpose, instead of a supported > > configuration. So when we boot from previous bootloader, we really > > should use its configuration, for the coreboot case, > > coreboot-x86_defconfig should be used, and we can compare the > > registers, ACPI tables in that configuration, instead of "hacking" > > current U-Boot codes like in this series. > > Well the problem is then that we cannot boot the same image with or > without coreboot. Also there are various of device-tree things in > coral that we need for the laptop to work properly. My idea is to > detect coreboot and set ll_boot_init() dynamically if needed. If so, why should we keep coreboot_defconfig for U-Boot as a supported target? I am more interested in what you proposed here: "detect coreboot and set ll_boot_init() dynamically if needed." The name ll_boot_init() does not sound great. It's written like a function call but actually it is a macro for true/false. Can we do something in the gd->flags to indicate we are booting from previous stage bootloaders instead of relying on ll_boot_init()? Regards, Bin
Hi Bin, On Mon, 3 Feb 2020 at 21:52, Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Simon, > > On Tue, Feb 4, 2020 at 1:15 AM Simon Glass <sjg@chromium.org> wrote: > > > > Hi Bin, > > > > On Mon, 3 Feb 2020 at 10:10, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > Hi Simon, > > > > > > On Tue, Feb 4, 2020 at 12:20 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > Hi Bin, > > > > > > > > On Mon, 3 Feb 2020 at 04:05, Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Sun, Dec 22, 2019 at 12:13 AM Simon Glass <sjg@chromium.org> wrote: > > > > > > > > > > > > When U-Boot is no the first-stage bootloader much of this code is not > > > > > > needed and can break booting. Add checks for this to the FSP code. > > > > > > > > > > > > Rather than checking for the amount of available SDRAM, just use 1GB in > > > > > > this situation, which should be safe. Using 2GB may run into a memory > > > > > > hole on some SoCs. > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org> > > > > > > --- > > > > > > > > > > > > arch/x86/lib/fsp/fsp_dram.c | 8 ++++++++ > > > > > > arch/x86/lib/fsp/fsp_graphics.c | 3 +++ > > > > > > arch/x86/lib/fsp2/fsp_dram.c | 10 ++++++++++ > > > > > > arch/x86/lib/fsp2/fsp_init.c | 2 +- > > > > > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c > > > > > > index 9ce0ddf0d3..15e82de2fe 100644 > > > > > > --- a/arch/x86/lib/fsp/fsp_dram.c > > > > > > +++ b/arch/x86/lib/fsp/fsp_dram.c > > > > > > @@ -44,6 +44,14 @@ int dram_init_banksize(void) > > > > > > phys_addr_t low_end; > > > > > > uint bank; > > > > > > > > > > > > + if (!ll_boot_init()) { > > > > > > + gd->bd->bi_dram[0].start = 0; > > > > > > + gd->bd->bi_dram[0].size = gd->ram_size; > > > > > > + > > > > > > + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size); > > > > > > + return 0; > > > > > > + } > > > > > > + > > > > > > > > > > I wonder why this change is needed. When booting from other > > > > > bootloader, this dram_init_banksize() will not be called, no? > > > > > > > > How about this: > > > > > > > > It is useful to be able to boot the same x86 image on a device with or > > > > without a first-stage bootloader. For example, with chromebook_coral, it > > > > is helpful for testing to be able to boot the same U-Boot (complete with > > > > FSP) on bare metal and from coreboot. It allows checking of things like > > > > CPU speed, comparing registers, ACPI tables and the like. > > > > > > > > The idea is to change ll_boot_init() to false, and rebuild without changing > > > > anything else. > > > > > > This sounds like for a debugging purpose, instead of a supported > > > configuration. So when we boot from previous bootloader, we really > > > should use its configuration, for the coreboot case, > > > coreboot-x86_defconfig should be used, and we can compare the > > > registers, ACPI tables in that configuration, instead of "hacking" > > > current U-Boot codes like in this series. > > > > Well the problem is then that we cannot boot the same image with or > > without coreboot. Also there are various of device-tree things in > > coral that we need for the laptop to work properly. My idea is to > > detect coreboot and set ll_boot_init() dynamically if needed. > > If so, why should we keep coreboot_defconfig for U-Boot as a supported target? > > I am more interested in what you proposed here: "detect coreboot and > set ll_boot_init() dynamically if needed." The name ll_boot_init() > does not sound great. It's written like a function call but actually > it is a macro for true/false. Can we do something in the gd->flags to > indicate we are booting from previous stage bootloaders instead of > relying on ll_boot_init()? That sounds like a good idea, although at present it is statically configured. But we don't really care about code size here I think. Regards, Simon
diff --git a/arch/x86/lib/fsp/fsp_dram.c b/arch/x86/lib/fsp/fsp_dram.c index 9ce0ddf0d3..15e82de2fe 100644 --- a/arch/x86/lib/fsp/fsp_dram.c +++ b/arch/x86/lib/fsp/fsp_dram.c @@ -44,6 +44,14 @@ int dram_init_banksize(void) phys_addr_t low_end; uint bank; + if (!ll_boot_init()) { + gd->bd->bi_dram[0].start = 0; + gd->bd->bi_dram[0].size = gd->ram_size; + + mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size); + return 0; + } + low_end = 0; for (bank = 1, hdr = gd->arch.hob_list; bank < CONFIG_NR_DRAM_BANKS && !end_of_hob(hdr); diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c index 226c7e66b3..98b762209f 100644 --- a/arch/x86/lib/fsp/fsp_graphics.c +++ b/arch/x86/lib/fsp/fsp_graphics.c @@ -78,6 +78,9 @@ static int fsp_video_probe(struct udevice *dev) struct vesa_mode_info *vesa = &mode_info.vesa; int ret; + if (!ll_boot_init()) + return 0; + printf("Video: "); /* Initialize vesa_mode_info structure */ diff --git a/arch/x86/lib/fsp2/fsp_dram.c b/arch/x86/lib/fsp2/fsp_dram.c index 90a238a224..74835eebce 100644 --- a/arch/x86/lib/fsp2/fsp_dram.c +++ b/arch/x86/lib/fsp2/fsp_dram.c @@ -12,11 +12,18 @@ #include <asm/fsp/fsp_support.h> #include <asm/fsp2/fsp_api.h> #include <asm/fsp2/fsp_internal.h> +#include <linux/sizes.h> int dram_init(void) { int ret; + if (!ll_boot_init()) { + /* Use a small and safe amount of 1GB */ + gd->ram_size = SZ_1G; + + return 0; + } if (spl_phase() == PHASE_SPL) { #ifdef CONFIG_HAVE_ACPI_RESUME bool s3wake = gd->arch.prev_sleep_state == ACPI_S3; @@ -68,6 +75,9 @@ int dram_init(void) ulong board_get_usable_ram_top(ulong total_size) { + if (!ll_boot_init()) + return gd->ram_size; + #if CONFIG_IS_ENABLED(HANDOFF) struct spl_handoff *ho = gd->spl_handoff; diff --git a/arch/x86/lib/fsp2/fsp_init.c b/arch/x86/lib/fsp2/fsp_init.c index da9bd6b45c..c7dc2ea257 100644 --- a/arch/x86/lib/fsp2/fsp_init.c +++ b/arch/x86/lib/fsp2/fsp_init.c @@ -23,7 +23,7 @@ int arch_cpu_init_dm(void) int ret; /* Make sure pads are set up early in U-Boot */ - if (spl_phase() != PHASE_BOARD_F) + if (!ll_boot_init() || spl_phase() != PHASE_BOARD_F) return 0; /* Probe all pinctrl devices to set up the pads */
When U-Boot is no the first-stage bootloader much of this code is not needed and can break booting. Add checks for this to the FSP code. Rather than checking for the amount of available SDRAM, just use 1GB in this situation, which should be safe. Using 2GB may run into a memory hole on some SoCs. Signed-off-by: Simon Glass <sjg@chromium.org> --- arch/x86/lib/fsp/fsp_dram.c | 8 ++++++++ arch/x86/lib/fsp/fsp_graphics.c | 3 +++ arch/x86/lib/fsp2/fsp_dram.c | 10 ++++++++++ arch/x86/lib/fsp2/fsp_init.c | 2 +- 4 files changed, 22 insertions(+), 1 deletion(-)