[PATCH v2] sandbox: Add a build without CMDLINE

Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v2: - Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS index 8e375e75e53..2affcd08939 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1544,6 +1544,7 @@ SANDBOX M: Simon Glass sjg@chromium.org S: Maintained F: arch/sandbox/ +F: configs/sandbox* F: doc/arch/sandbox.rst F: drivers/*/*sandbox*.c F: include/dt-bindings/*/sandbox*.h diff --git a/configs/sandbox_nocmdline_defconfig b/configs/sandbox_nocmdline_defconfig new file mode 100644 index 00000000000..aade1d44236 --- /dev/null +++ b/configs/sandbox_nocmdline_defconfig @@ -0,0 +1,365 @@ +CONFIG_TEXT_BASE=0 +CONFIG_SYS_MALLOC_LEN=0x6000000 +CONFIG_NR_DRAM_BANKS=1 +CONFIG_ENV_SIZE=0x2000 +CONFIG_DEFAULT_DEVICE_TREE="sandbox" +CONFIG_DM_RESET=y +CONFIG_SYS_LOAD_ADDR=0x0 +CONFIG_PRE_CON_BUF_ADDR=0xf0000 +CONFIG_PCI=y +CONFIG_DEBUG_UART=y +CONFIG_SYS_MEMTEST_START=0x00100000 +CONFIG_SYS_MEMTEST_END=0x00101000 +CONFIG_EFI_SECURE_BOOT=y +CONFIG_EFI_RT_VOLATILE_STORE=y +CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y +CONFIG_EFI_CAPSULE_ON_DISK=y +CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y +CONFIG_EFI_CAPSULE_AUTHENTICATE=y +CONFIG_EFI_CAPSULE_CRT_FILE="board/sandbox/capsule_pub_key_good.crt" +CONFIG_BUTTON_CMD=y +CONFIG_FIT=y +CONFIG_FIT_RSASSA_PSS=y +CONFIG_FIT_CIPHER=y +CONFIG_FIT_VERBOSE=y +CONFIG_BOOTMETH_ANDROID=y +CONFIG_UPL=y +CONFIG_LEGACY_IMAGE_FORMAT=y +CONFIG_MEASURED_BOOT=y +CONFIG_BOOTSTAGE=y +CONFIG_BOOTSTAGE_REPORT=y +CONFIG_BOOTSTAGE_FDT=y +CONFIG_BOOTSTAGE_STASH=y +CONFIG_BOOTSTAGE_STASH_SIZE=0x4096 +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_PROMPT="Enter password "a" in %d seconds to stop autoboot\n" +CONFIG_AUTOBOOT_ENCRYPTION=y +CONFIG_AUTOBOOT_SHA256_FALLBACK=y +CONFIG_AUTOBOOT_NEVER_TIMEOUT=y +CONFIG_AUTOBOOT_STOP_STR_ENABLE=y +CONFIG_AUTOBOOT_STOP_STR_CRYPT="$5$rounds=640000$HrpE65IkB8CM5nCL$BKT3QdF98Bo8fJpTr9tjZLZQyzqPASBY20xuK5Rent9" +CONFIG_IMAGE_PRE_LOAD=y +CONFIG_IMAGE_PRE_LOAD_SIG=y +CONFIG_CEDIT=y +CONFIG_CONSOLE_RECORD=y +CONFIG_CONSOLE_RECORD_OUT_SIZE=0x6000 +CONFIG_PRE_CONSOLE_BUFFER=y +CONFIG_LOG=y +CONFIG_LOG_MAX_LEVEL=9 +CONFIG_LOG_DEFAULT_LEVEL=6 +CONFIG_LOGF_FUNC=y +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_STACKPROTECTOR=y +CONFIG_CMD_CPU=y +CONFIG_CMD_LICENSE=y +CONFIG_CMD_SMBIOS=y +CONFIG_CMD_BOOTM_PRE_LOAD=y +CONFIG_CMD_BOOTZ=y +CONFIG_BOOTM_OPENRTOS=y +CONFIG_BOOTM_OSE=y +CONFIG_CMD_BOOTEFI_HELLO=y +CONFIG_CMD_BOOTMENU=y +CONFIG_CMD_ABOOTIMG=y +CONFIG_CMD_ASKENV=y +CONFIG_CMD_GREPENV=y +CONFIG_CMD_ERASEENV=y +CONFIG_CMD_ENV_CALLBACK=y +CONFIG_CMD_ENV_FLAGS=y +CONFIG_CMD_NVEDIT_EFI=y +CONFIG_CMD_NVEDIT_INFO=y +CONFIG_CMD_NVEDIT_LOAD=y +CONFIG_CMD_NVEDIT_SELECT=y +CONFIG_LOOPW=y +CONFIG_CMD_MD5SUM=y +CONFIG_CMD_MEMINFO=y +CONFIG_CMD_MEM_SEARCH=y +CONFIG_CMD_MX_CYCLIC=y +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_CLK=y +CONFIG_CMD_DEMO=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_GPIO_READ=y +CONFIG_CMD_PWM=y +CONFIG_CMD_GPT=y +CONFIG_CMD_GPT_RENAME=y +CONFIG_CMD_IDE=y +CONFIG_CMD_I2C=y +CONFIG_CMD_LOADM=y +CONFIG_CMD_LSBLK=y +CONFIG_CMD_MTD=y +CONFIG_CMD_MUX=y +CONFIG_CMD_OSD=y +CONFIG_CMD_PCI=y +CONFIG_CMD_PCI_MPS=y +CONFIG_CMD_READ=y +CONFIG_CMD_REMOTEPROC=y +CONFIG_CMD_SPI=y +CONFIG_CMD_TEMPERATURE=y +CONFIG_CMD_USB=y +CONFIG_CMD_RKMTD=y +CONFIG_CMD_WDT=y +CONFIG_CMD_WRITE=y +CONFIG_CMD_AXI=y +CONFIG_CMD_CAT=y +CONFIG_CMD_SETEXPR_FMT=y +CONFIG_CMD_XXD=y +CONFIG_CMD_DHCP6=y +CONFIG_BOOTP_DNS2=y +CONFIG_CMD_PCAP=y +CONFIG_CMD_TFTPPUT=y +CONFIG_CMD_TFTPSRV=y +CONFIG_CMD_RARP=y +CONFIG_CMD_CDP=y +CONFIG_CMD_SNTP=y +CONFIG_CMD_DNS=y +CONFIG_CMD_LINK_LOCAL=y +CONFIG_IPV6_ROUTER_DISCOVERY=y +CONFIG_CMD_ETHSW=y +CONFIG_CMD_2048=y +CONFIG_CMD_BMP=y +CONFIG_CMD_BOOTCOUNT=y +CONFIG_CMD_EFIDEBUG=y +CONFIG_CMD_RTC=y +CONFIG_CMD_TIME=y +CONFIG_CMD_PAUSE=y +CONFIG_CMD_TIMER=y +CONFIG_CMD_SOUND=y +CONFIG_CMD_QFW=y +CONFIG_CMD_PSTORE=y +CONFIG_CMD_PSTORE_MEM_ADDR=0x3000000 +CONFIG_CMD_BOOTSTAGE=y +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y +CONFIG_CMD_AES=y +CONFIG_CMD_TPM=y +CONFIG_CMD_TPM_TEST=y +CONFIG_CMD_SCMI=y +CONFIG_CMD_BTRFS=y +CONFIG_CMD_CBFS=y +CONFIG_CMD_CRAMFS=y +CONFIG_CMD_EROFS=y +CONFIG_CMD_EXT4_WRITE=y +CONFIG_CMD_SQUASHFS=y +CONFIG_CMD_MTDPARTS=y +CONFIG_CMD_STACKPROTECTOR_TEST=y +CONFIG_MAC_PARTITION=y +CONFIG_AMIGA_PARTITION=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIVE=y +CONFIG_ENV_IS_NOWHERE=y +CONFIG_ENV_IS_IN_EXT4=y +CONFIG_ENV_EXT4_INTERFACE="host" +CONFIG_ENV_EXT4_DEVICE_AND_PART="0:0" +CONFIG_ENV_IMPORT_FDT=y +CONFIG_BOOTP_SEND_HOSTNAME=y +CONFIG_NETCONSOLE=y +CONFIG_IP_DEFRAG=y +CONFIG_BOOTP_SERVERIP=y +CONFIG_IPV6=y +CONFIG_DM_DMA=y +CONFIG_DEBUG_DEVRES=y +CONFIG_SIMPLE_PM_BUS=y +CONFIG_ADC=y +CONFIG_ADC_SANDBOX=y +CONFIG_AXI=y +CONFIG_AXI_SANDBOX=y +CONFIG_BLKMAP=y +CONFIG_SYS_IDE_MAXBUS=1 +CONFIG_SYS_ATA_BASE_ADDR=0x100 +CONFIG_SYS_ATA_STRIDE=4 +CONFIG_SYS_ATA_DATA_OFFSET=0 +CONFIG_SYS_ATA_REG_OFFSET=1 +CONFIG_SYS_ATA_ALT_OFFSET=2 +CONFIG_SYS_ATA_IDE0_OFFSET=0 +CONFIG_BOOTCOUNT_LIMIT=y +CONFIG_DM_BOOTCOUNT=y +CONFIG_DM_BOOTCOUNT_RTC=y +CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y +CONFIG_DM_BOOTCOUNT_SYSCON=y +CONFIG_BUTTON_ADC=y +CONFIG_BUTTON_GPIO=y +CONFIG_CLK=y +CONFIG_CLK_COMPOSITE_CCF=y +CONFIG_CLK_K210=y +CONFIG_CLK_K210_SET_RATE=y +CONFIG_SANDBOX_CLK_CCF=y +CONFIG_CLK_SCMI=y +CONFIG_CPU=y +CONFIG_DM_DEMO=y +CONFIG_DM_DEMO_SIMPLE=y +CONFIG_DM_DEMO_SHAPE=y +CONFIG_DFU_SF=y +CONFIG_DMA=y +CONFIG_DMA_CHANNELS=y +CONFIG_SANDBOX_DMA=y +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 +CONFIG_ARM_FFA_TRANSPORT=y +CONFIG_GPIO_HOG=y +CONFIG_DM_GPIO_LOOKUP_LABEL=y +CONFIG_QCOM_PMIC_GPIO=y +CONFIG_SANDBOX_GPIO=y +CONFIG_DM_HWSPINLOCK=y +CONFIG_HWSPINLOCK_SANDBOX=y +CONFIG_I2C_CROS_EC_TUNNEL=y +CONFIG_I2C_CROS_EC_LDO=y +CONFIG_DM_I2C_GPIO=y +CONFIG_I2C_MUX=y +CONFIG_I2C_ARB_GPIO_CHALLENGE=y +CONFIG_CROS_EC_KEYB=y +CONFIG_I8042_KEYB=y +CONFIG_IOMMU=y +CONFIG_LED=y +CONFIG_LED_BLINK=y +CONFIG_LED_GPIO=y +CONFIG_DM_MAILBOX=y +CONFIG_SANDBOX_MBOX=y +CONFIG_MISC=y +CONFIG_NVMEM=y +CONFIG_CROS_EC=y +CONFIG_CROS_EC_I2C=y +CONFIG_CROS_EC_LPC=y +CONFIG_CROS_EC_SANDBOX=y +CONFIG_CROS_EC_SPI=y +CONFIG_P2SB=y +CONFIG_PWRSEQ=y +CONFIG_I2C_EEPROM=y +CONFIG_MMC_PCI=y +CONFIG_MMC_SANDBOX=y +CONFIG_MMC_SDHCI=y +CONFIG_DM_MTD=y +CONFIG_MTD_RAW_NAND=y +CONFIG_SYS_MAX_NAND_DEVICE=8 +CONFIG_SYS_NAND_USE_FLASH_BBT=y +CONFIG_NAND_SANDBOX=y +CONFIG_SYS_NAND_ONFI_DETECTION=y +CONFIG_SYS_NAND_PAGE_SIZE=0x200 +CONFIG_SPI_FLASH_SANDBOX=y +CONFIG_BOOTDEV_SPI_FLASH=y +CONFIG_SPI_FLASH_ATMEL=y +CONFIG_SPI_FLASH_EON=y +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_SST=y +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_NVMXIP_QSPI=y +CONFIG_MULTIPLEXER=y +CONFIG_MUX_MMIO=y +CONFIG_NVME_PCI=y +CONFIG_PCI_REGION_MULTI_ENTRY=y +CONFIG_PCI_FTPCI100=y +CONFIG_PCI_SANDBOX=y +CONFIG_PHY=y +CONFIG_PHY_SANDBOX=y +CONFIG_PINCTRL=y +CONFIG_PINCONF=y +CONFIG_PINCTRL_SANDBOX=y +CONFIG_PINCTRL_SINGLE=y +CONFIG_POWER_DOMAIN=y +CONFIG_SANDBOX_POWER_DOMAIN=y +CONFIG_SCMI_POWER_DOMAIN=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_ACT8846=y +CONFIG_DM_PMIC_PFUZE100=y +CONFIG_DM_PMIC_MAX77686=y +CONFIG_DM_PMIC_MC34708=y +CONFIG_PMIC_QCOM=y +CONFIG_PMIC_RK8XX=y +CONFIG_PMIC_S2MPS11=y +CONFIG_DM_PMIC_SANDBOX=y +CONFIG_PMIC_S5M8767=y +CONFIG_PMIC_TPS65090=y +CONFIG_DM_REGULATOR=y +CONFIG_REGULATOR_ACT8846=y +CONFIG_DM_REGULATOR_PFUZE100=y +CONFIG_DM_REGULATOR_MAX77686=y +CONFIG_DM_REGULATOR_FIXED=y +CONFIG_REGULATOR_RK8XX=y +CONFIG_REGULATOR_S5M8767=y +CONFIG_DM_REGULATOR_SANDBOX=y +CONFIG_REGULATOR_TPS65090=y +CONFIG_DM_REGULATOR_SCMI=y +CONFIG_DM_PWM=y +CONFIG_PWM_CROS_EC=y +CONFIG_PWM_SANDBOX=y +CONFIG_RAM=y +CONFIG_DM_REBOOT_MODE=y +CONFIG_DM_REBOOT_MODE_GPIO=y +CONFIG_DM_REBOOT_MODE_RTC=y +CONFIG_REMOTEPROC_SANDBOX=y +CONFIG_SANDBOX_RESET=y +CONFIG_RESET_SYSCON=y +CONFIG_RESET_SCMI=y +CONFIG_DM_RTC=y +CONFIG_RTC_MAX313XX=y +CONFIG_RTC_RV8803=y +CONFIG_RTC_HT1380=y +CONFIG_SCSI=y +CONFIG_SANDBOX_SERIAL=y +CONFIG_SM=y +CONFIG_SMEM=y +CONFIG_SANDBOX_SMEM=y +CONFIG_SOUND=y +CONFIG_SOUND_DA7219=y +CONFIG_SOUND_MAX98357A=y +CONFIG_SOUND_SANDBOX=y +CONFIG_SOC_DEVICE=y +CONFIG_SANDBOX_SPI=y +CONFIG_SPMI=y +CONFIG_SPMI_SANDBOX=y +CONFIG_SYSINFO=y +CONFIG_SYSINFO_SANDBOX=y +CONFIG_SYSINFO_GPIO=y +CONFIG_SYSRESET=y +CONFIG_DM_THERMAL=y +CONFIG_TIMER=y +CONFIG_TIMER_EARLY=y +CONFIG_SANDBOX_TIMER=y +CONFIG_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_EMUL=y +CONFIG_USB_KEYBOARD=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_USB_ETHER=y +CONFIG_USB_ETH_CDC=y +CONFIG_VIDEO=y +CONFIG_VIDEO_FONT_SUN12X22=y +CONFIG_VIDEO_COPY=y +CONFIG_CONSOLE_ROTATION=y +CONFIG_CONSOLE_TRUETYPE=y +CONFIG_CONSOLE_TRUETYPE_CANTORAONE=y +CONFIG_I2C_EDID=y +CONFIG_VIDEO_SANDBOX_SDL=y +CONFIG_VIDEO_DSI_HOST_SANDBOX=y +CONFIG_OSD=y +CONFIG_SANDBOX_OSD=y +CONFIG_BMP_16BPP=y +CONFIG_BMP_24BPP=y +CONFIG_W1=y +CONFIG_W1_GPIO=y +CONFIG_W1_EEPROM=y +CONFIG_W1_EEPROM_SANDBOX=y +# CONFIG_WATCHDOG_AUTOSTART is not set +CONFIG_WDT=y +CONFIG_WDT_GPIO=y +CONFIG_WDT_SANDBOX=y +CONFIG_WDT_ALARM_SANDBOX=y +CONFIG_WDT_FTWDT010=y +CONFIG_FS_CBFS=y +CONFIG_FS_CRAMFS=y +CONFIG_ADDR_MAP=y +CONFIG_CMD_DHRYSTONE=y +CONFIG_MBEDTLS_LIB=y +CONFIG_ECDSA=y +CONFIG_ECDSA_VERIFY=y +CONFIG_TPM=y +CONFIG_ERRNO_STR=y +CONFIG_GETOPT=y +CONFIG_TEST_FDTDEC=y +CONFIG_UNIT_TEST=y +CONFIG_UT_TIME=y +CONFIG_UT_DM=y +# CONFIG_CMDLINE is not set

On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.

Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
Regards, Simon

On Sun, Oct 27, 2024 at 03:52:02PM +0100, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
I assume this is related to the issue I filed? Among the problems are that buildman doesn't "know" about the architecture for example in time and so thinks everything is sandbox (since that's the default). That won't be an issue for your use case here (we have a number of defconfigs today that work around this issue by setting CONFIG_ARM=y and then a few other options too, so that the resulting build ends up correct).

Hi Tom,
On Sun, 27 Oct 2024 at 15:56, Tom Rini trini@konsulko.com wrote:
On Sun, Oct 27, 2024 at 03:52:02PM +0100, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
I assume this is related to the issue I filed? Among the problems are that buildman doesn't "know" about the architecture for example in time and so thinks everything is sandbox (since that's the default). That won't be an issue for your use case here (we have a number of defconfigs today that work around this issue by setting CONFIG_ARM=y and then a few other options too, so that the resulting build ends up correct).
Yes...OK so I think I understand. If we are happy with the '#include' scheme then I believe it would be easy enough to implement in buildman. As Caleb mentions, it could likely run the pre-processor first, or just process the #includes (which I prefer).
Is the '#include' in defconfigs documented somewhere in Linux or U-Boot? I really had no idea about this until you mentioned it.
Regards, Simon

On Fri, Nov 01, 2024 at 04:38:26PM +0100, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 15:56, Tom Rini trini@konsulko.com wrote:
On Sun, Oct 27, 2024 at 03:52:02PM +0100, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
I assume this is related to the issue I filed? Among the problems are that buildman doesn't "know" about the architecture for example in time and so thinks everything is sandbox (since that's the default). That won't be an issue for your use case here (we have a number of defconfigs today that work around this issue by setting CONFIG_ARM=y and then a few other options too, so that the resulting build ends up correct).
Yes...OK so I think I understand. If we are happy with the '#include' scheme then I believe it would be easy enough to implement in buildman. As Caleb mentions, it could likely run the pre-processor first, or just process the #includes (which I prefer).
Is the '#include' in defconfigs documented somewhere in Linux or U-Boot? I really had no idea about this until you mentioned it.
It should be documented somewhere too, yes. But you did review the original in 2027e99e61aa :)

Hi Tom,
On Fri, 1 Nov 2024 at 17:26, Tom Rini trini@konsulko.com wrote:
On Fri, Nov 01, 2024 at 04:38:26PM +0100, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 15:56, Tom Rini trini@konsulko.com wrote:
On Sun, Oct 27, 2024 at 03:52:02PM +0100, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
I assume this is related to the issue I filed? Among the problems are that buildman doesn't "know" about the architecture for example in time and so thinks everything is sandbox (since that's the default). That won't be an issue for your use case here (we have a number of defconfigs today that work around this issue by setting CONFIG_ARM=y and then a few other options too, so that the resulting build ends up correct).
Yes...OK so I think I understand. If we are happy with the '#include' scheme then I believe it would be easy enough to implement in buildman. As Caleb mentions, it could likely run the pre-processor first, or just process the #includes (which I prefer).
Is the '#include' in defconfigs documented somewhere in Linux or U-Boot? I really had no idea about this until you mentioned it.
It should be documented somewhere too, yes. But you did review the original in 2027e99e61aa :)
Yes, although my question was never addressed [1]
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/patch/20230829221457.101469-2-afd...

On 27/10/2024 15:52, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
qcm6490_defconfig needs to re-define CONFIG_ARM=y for buildman to be happy.
Why is buildman looking at the defconfig anyway? Maybe it could just run the pre-processor first?
Regards, Simon

Hi Caleb, Tom,
On Mon, 28 Oct 2024 at 22:54, Caleb Connolly caleb.connolly@linaro.org wrote:
On 27/10/2024 15:52, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
qcm6490_defconfig needs to re-define CONFIG_ARM=y for buildman to be happy.
Why is buildman looking at the defconfig anyway? Maybe it could just run the pre-processor first?
It could, but I really want buildman to understand things. If we can say that '#include' in the file is the only thing it needs to deal with, then I believe we can update Kconfiglib to deal with it, or perhaps preprocess the file. That uncertainty (as to what the 'spec' actually is) is what has held me back from looking at it too seriously.
Regards, Simon

On Fri, Nov 01, 2024 at 04:37:17PM +0100, Simon Glass wrote:
Hi Caleb, Tom,
On Mon, 28 Oct 2024 at 22:54, Caleb Connolly caleb.connolly@linaro.org wrote:
On 27/10/2024 15:52, Simon Glass wrote:
Hi Tom,
On Sun, 27 Oct 2024 at 00:33, Tom Rini trini@konsulko.com wrote:
On Sat, Oct 26, 2024 at 02:02:49PM +0200, Simon Glass wrote:
Something this breaks, so add a build to keep it working. Since sandbox enables a lot of options, it is a good board to use. The new config is created simply by copying the existing sandbox and turning off CMDLINE
Once we have tests for non-CMDLINE operation, this can be adjusted to run those tests.
Create a new build which will be picked up by CI. Update the maintainer entry as well.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v2:
- Create a new build instead of messing with CI
MAINTAINERS | 1 + configs/sandbox_nocmdline_defconfig | 365 ++++++++++++++++++++++++++++ 2 files changed, 366 insertions(+) create mode 100644 configs/sandbox_nocmdline_defconfig
Please use the #include mechanism instead of a full config that will also now have to be kept in sync.
Hmmm we still haven't come up with a way to deal with the #include mechanism in buildman. I've forgotten where it got to, or even what the problem was?
qcm6490_defconfig needs to re-define CONFIG_ARM=y for buildman to be happy.
Why is buildman looking at the defconfig anyway? Maybe it could just run the pre-processor first?
It could, but I really want buildman to understand things. If we can say that '#include' in the file is the only thing it needs to deal with, then I believe we can update Kconfiglib to deal with it, or perhaps preprocess the file. That uncertainty (as to what the 'spec' actually is) is what has held me back from looking at it too seriously.
Given https://github.com/llvm/llvm-project/issues/78778 I do not like preprocessing the files. I want to stress that scripts/kconfig/merge_config.sh is the canonical way to merge fragments. So if taking the Kconfiglib approach, implementing the above but in python would be good (and we can suggest that #include be the normal way one file says to use other fragments but not let us be blocked on making this better).
participants (3)
-
Caleb Connolly
-
Simon Glass
-
Tom Rini