[PATCH] board: sifive: unmatched: remove extra space in fdtfile value
Fixes: 44a792c994 ("riscv: sifive: unmatched: migrate to text environment")
Signed-off-by: Andreas Schwab
---
board/sifive/unmatched/unmatched.env | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sifive/unmatched/unmatched.env
b/board/sifive/unmatched/unmatched.env
index 0f1e5a7174..34425dc9ef 100644
--- a/board/sifive/unmatched/unmatched.env
+++ b/board/sifive/unmatched/unmatched.env
@@ -16,4 +16,4 @@ partitions=
name=loader1,start=17K,size=1M,type=${type_guid_gpt_loader1};
name=loader2,size=4MB,type=${type_guid_gpt_loader2};
name=system,size=-,bootable,type=${type_guid_gpt_system};
-fdtfile= CONFIG_DEFAULT_FDT_FILE
+fdtfile=CONFIG_DEFAULT_FDT_FILE
--
2.45.2
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH v5 10/11] ram: starfive: Read memory size information from EEPROM
On Jun 15 2023, Yanhong Wang wrote: > StarFive VisionFive 2 has two versions, 1.2A and 1.3B, each version of > DDR capacity includes 2G/4G/8G, a DT can not support multiple > capacities, so the capacity size information is recorded to EEPROM, when > DDR initialization required capacity size information is read from > EEPROM. Does that acutally work? I see that read_eeprom fails in SPL. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On Mai 02 2023, Matthias Brugger wrote: > I'm not sure I get your point. The devicetree will be passed to the kernel > via a pointer in a register, the kernel does not need to load the > devicetree into memory, it will use the one passed by U-Boot. But U-Boot needs to load it, and the kernel is the authority in providing it. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v5 00/17] Basic StarFive JH7110 RISC-V SoC support
On Apr 14 2023, Matthias Brugger wrote: > My opinion isIn my opinion user-friendlyness is more important then > developer friendly that from an end-user point of view it's much easier to > have one binary that works on all different board versions. If not users > will have to know which board version they have to flash the correct > U-Boot. As long as the kernel uses separate device trees, U-Boot needs to know which one to load. As it currently stands, U-Boot uses the wrong name that does not match either of the names used by the kernel, which means it will not be able find any of them. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v4 17/17] configs: starfive: add starfive_visionfive2_defconfig
On Mär 22 2023, yanhong wang wrote: > On 2023/3/21 21:51, Andreas Schwab wrote: >> On Mär 21 2023, yanhong wang wrote: >> >>> Except for CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE, >>> 1.2a and 1.3b versions use the same config. >>> >>> Version 1.3b uses the following configuration: >>> CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b" >>> >>> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.3b.dtb" >>> >>> Version 1.2a uses the following configuration: >>> CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.2a" >>> >>> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.2a.dtb" >>> >>> Is it necessary to separate the configs for 1.2a and 1.3b as separate >>> defconfig files? >> >> It makes a difference for when ethernet support is added. >> > > The difference between 1.2a and 1.3b versions is mainly in ethernet, so the > definition of > dts is separated. Defconfig file in addition to the differences mentioned > above, the others > are the same. Your suggestion is to define defconfig file separately, is that > right? Yes, a 1.2a board will need to use the 1.2a device tree to get a working ethernet, IIUC. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v4 17/17] configs: starfive: add starfive_visionfive2_defconfig
On Mär 21 2023, yanhong wang wrote: > Except for CONFIG_DEFAULT_DEVICE_TREE and CONFIG_DEFAULT_FDT_FILE, > 1.2a and 1.3b versions use the same config. > > Version 1.3b uses the following configuration: > CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b" > CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.3b.dtb" > > Version 1.2a uses the following configuration: > CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.2a" > CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.2a.dtb" > > Is it necessary to separate the configs for 1.2a and 1.3b as separate > defconfig files? It makes a difference for when ethernet support is added. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v4 17/17] configs: starfive: add starfive_visionfive2_defconfig
On Mär 16 2023, Yanhong Wang wrote: > This is the initial basic config for StarFive VisionFive v2 board. It > includes consol, Norflash, sdio, ddr etc. Are you also planning to add a config for the 1.2a version? -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH] fs: btrfs: limit the mapped length to the original length
On Feb 13 2023, Qu Wenruo wrote:
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 4aaaeab663f5..7d4095d9ca88 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -956,6 +956,7 @@ int __btrfs_map_block(struct btrfs_fs_info *fs_info, int
> rw,
> struct btrfs_mapping_tree *map_tree = _info->mapping_tree;
> struct cache_extent *ce;
> struct map_lookup *map;
> + u64 orig_len = *length;
> u64 offset;
> u64 stripe_offset;
> u64 *raid_map = NULL;
> @@ -1047,6 +1048,7 @@ again:
> } else {
> *length = ce->size - offset;
> }
> + *length = min_t(u64, *length, orig_len);
>
> if (!multi_ret)
> goto out;
I can confirm that this fixes the issue.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH] fs/btrfs: handle data extents, which crosss stripe boundaries, correctly
On Feb 13 2023, Qu Wenruo wrote: > On 2023/2/13 00:20, Andreas Schwab wrote: >> When I print ce->size in __btrfs_map_block, it is almost always >> 1073741824, which looks bogus. >> > Can you provide the image of that filesystem? How do I do that? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] fs/btrfs: handle data extents, which crosss stripe boundaries, correctly
When I print ce->size in __btrfs_map_block, it is almost always 1073741824, which looks bogus. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] fs/btrfs: handle data extents, which crosss stripe boundaries, correctly
The length returned by btrfs_map_block is clearly bogus: read_extent_data: cur=615817216, orig_len=16384, cur_len=16384 read_extent_data: btrfs_map_block: cur_len=479944704; ret=0 read_extent_data: ret=0 read_extent_data: cur=615833600, orig_len=4096, cur_len=4096 read_extent_data: btrfs_map_block: cur_len=479928320; ret=0 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] fs/btrfs: handle data extents, which crosss stripe boundaries, correctly
On Dez 30 2022, Qu Wenruo wrote: > [BUG] > Since btrfs supports single device RAID0 at mkfs time after btrfs-progs > v5.14, if we create a single device raid0 btrfs, and created a file > crossing stripe boundary: > > # mkfs.btrfs -m dup -d raid0 test.img > # mount test.img mnt > # xfs_io -f -c "pwrite 0 128K" mnt/file > # umount mnt > > Since btrfs is using 64K as stripe length, above 128K data write is > definitely going to cross at least one stripe boundary. > > Then u-boot would fail to read above 128K file: > > => host bind 0 /home/adam/test.img > => ls host 0 > < > 131072 Fri Dec 30 00:18:25 2022 file > => load host 0 0 file > BTRFS: An error occurred while reading file file > Failed to load 'file' > > [CAUSE] > Unlike tree blocks read, data extent reads doesn't consider cases in which > one data extent can cross stripe boundary. > > In read_data_extent(), we just call btrfs_map_block() once and read the > first mapped range. > > And if the first mapped range is smaller than the desired range, it > would return error. > > But since even single device btrfs can utilize RAID0 profiles, the first > mapped range can only be at most 64K for RAID0 profiles, and cause false > error. > > [FIX] > Just like read_whole_eb(), we should call btrfs_map_block() in a loop > until we read all data. > > Since we're here, also add extra error messages for the following cases: > > - btrfs_map_block() failure > We already have the error message for it. > > - Missing device > This should not happen, as we only support single device for now. > > - __btrfs_devread() failure > > With this bug fixed, btrfs driver of u-boot can properly read the above > 128K file, and have the correct content: > > => host bind 0 /home/adam/test.img > => ls host 0 > < > 131072 Fri Dec 30 00:18:25 2022 file > => load host 0 0 file > 131072 bytes read in 0 ms > => md5sum 0 0x2 > md5 for ... 0001 ==> d48858312a922db7eb86377f638dbc9f > ^^^ Above md5sum also matches. > > Reported-by: Sam Winchenbach > Signed-off-by: Qu Wenruo This breaks btrfs on the HiFive Unmatched. => pci enum PCIE-0: Link up (Gen1-x8, Bus0) => nvme scan => load nvme 0:2 0x8c00 /boot/dtb/sifive/hifive-unmatched-a00.dtb [hangs] -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v2 00/17] Basic StarFive JH7110 RISC-V SoC support
On Jan 18 2023, Yanhong Wang wrote: > This series of patches base on the latest branch/master, and add support > for the StarFive JH7110 RISC-V SoC and VisionFive V2 board. In order for > this to be achieved, the respective DT nodes have been added, and the > required defconfigs have been added to the boards' defconfig. What is more, > the basic required DM drivers have been added, such as reset, clock, pinctrl, > uart, ram etc. > > Note that the register base address of reset controller is same with the > clock controller. Therefore, there is no device tree node alone for reset > driver. It binds device node in the clock driver. > > The u-boot-spl and u-boot has been tested on the VisionFive V2 boards which > equip with JH7110 SoC and works normally. I tried to put that on an SD card for testing and boot from it, but the SPL cannot read it, thus fails to load U-Boot proper. U-Boot SPL 2023.01-00735-gc8fc99adce (Jan 24 2023 - 15:11:27 +0100) DDR version: dc2e84f0. Trying to boot from MMC2 spl: partition error SPL: failed to boot from all boot devices -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v2 17/17] configs: starfive: add starfive_visionfive2_defconfig
On Jan 18 2023, Yanhong Wang wrote: > This is the initial basic config for StarFive VisionFive v2 board. It > includes consol, Norflash, sdio, ddr etc. Please enable CONFIG_DISTRO_DEFAULTS. > +CONFIG_DEFAULT_FDT_FILE="starfive/starfive_visionfive2.dtb" That should match the name the kernel is using. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v2 1/3] riscv: implement __ashldi3, __lshrdi3
On Okt 01 2022, Heinrich Schuchardt wrote: > On 32bit RISC-V calls to __ashrdi3 and __lshrdi3 are generated. > These functions are normally provided by glibc but U-Boot is freestanding They are defined by libgcc, not glibc. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v2 2/6] lib: Drop SHA512_ALGO in lieu of SHA512
On Sep 02 2021, Alexandru Gagniuc wrote: > diff --git a/lib/crypt/Kconfig b/lib/crypt/Kconfig > index 5495ae8d4c..6a50029642 100644 > --- a/lib/crypt/Kconfig > +++ b/lib/crypt/Kconfig > @@ -20,7 +20,7 @@ config CRYPT_PW_SHA256 > config CRYPT_PW_SHA512 > bool "Provide sha512crypt" > select SHA512 > - select SHA512_ALGO > + select SHA512 SHA512 is now selected twice. > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index dacc3b5881..08463251cd 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -323,7 +323,7 @@ config EFI_TCG2_PROTOCOL > depends on TPM_V2 > select SHA1 > select SHA256 > - select SHA512_ALGO > + select SHA512 > select SHA384 > select SHA512 > select HASH Likewise. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] lib: add crc16.o if CONFIG_MMC_SPI_CRC_ON for SPL build
CONFIG_MMC_SPI_CRC_ON needs the crc16 functions, but it was not included in an SPL build. For non-SPL builds, crc16.o is already added unconditionally. This also removes CONFIG_SPL_YMODEM_SUPPORT from the sifive board configs, which is only relevant for some ARM boards and was only set for its side effect of adding crc16.o. --- configs/sifive_unleashed_defconfig | 1 - configs/sifive_unmatched_defconfig | 1 - lib/Makefile | 1 + 3 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/sifive_unleashed_defconfig b/configs/sifive_unleashed_defconfig index fd686dfadc..d6448dbf5e 100644 --- a/configs/sifive_unleashed_defconfig +++ b/configs/sifive_unleashed_defconfig @@ -22,7 +22,6 @@ CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_DM_RESET=y CONFIG_SPL_SPI_LOAD=y -CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_CLK=y diff --git a/configs/sifive_unmatched_defconfig b/configs/sifive_unmatched_defconfig index 6c40a35bc2..59c4a383e0 100644 --- a/configs/sifive_unmatched_defconfig +++ b/configs/sifive_unmatched_defconfig @@ -20,7 +20,6 @@ CONFIG_DISPLAY_BOARDINFO=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_DM_RESET=y -CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_EEPROM=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_PWM=y diff --git a/lib/Makefile b/lib/Makefile index 8ba745faa0..2d29cdad1e 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -88,6 +88,7 @@ endif ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16.o obj-$(CONFIG_$(SPL_TPL_)HASH_SUPPORT) += crc16.o +obj-$(CONFIG_MMC_SPI_CRC_ON) += crc16.o obj-y += net_utils.o endif obj-$(CONFIG_ADDR_MAP) += addr_map.o -- 2.33.0 -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] lib: add crc16.o if CONFIG_MMC_SPI_CRC_ON for SPL build
CONFIG_MMC_SPI_CRC_ON needs the crc16 functions, but it was not included in an SPL build. For non-SPL builds, crc16.o is already added unconditionally. This also removes CONFIG_SPL_YMODEM_SUPPORT from the sifive board configs, which is only relevant for some ARM boards and was only set for its side effect of adding crc16.o. Signed-off-by: Andreas Schwab --- configs/sifive_unleashed_defconfig | 1 - configs/sifive_unmatched_defconfig | 1 - lib/Makefile | 1 + 3 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/sifive_unleashed_defconfig b/configs/sifive_unleashed_defconfig index fd686dfadc..d6448dbf5e 100644 --- a/configs/sifive_unleashed_defconfig +++ b/configs/sifive_unleashed_defconfig @@ -22,7 +22,6 @@ CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_DM_RESET=y CONFIG_SPL_SPI_LOAD=y -CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_CLK=y diff --git a/configs/sifive_unmatched_defconfig b/configs/sifive_unmatched_defconfig index 38b7acd536..d37c019cda 100644 --- a/configs/sifive_unmatched_defconfig +++ b/configs/sifive_unmatched_defconfig @@ -20,7 +20,6 @@ CONFIG_DISPLAY_BOARDINFO=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_DM_RESET=y -CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_EEPROM=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_PWM=y diff --git a/lib/Makefile b/lib/Makefile index 07c2ccd7cf..7ae2ccf537 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -87,6 +87,7 @@ endif ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16.o obj-$(CONFIG_$(SPL_TPL_)HASH_SUPPORT) += crc16.o +obj-$(CONFIG_MMC_SPI_CRC_ON) += crc16.o obj-y += net_utils.o endif obj-$(CONFIG_ADDR_MAP) += addr_map.o -- 2.32.0 -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH v12 2/8] drivers: clk: add fu740 support
On Mai 27 2021, Green Wan wrote:
> +/* List of clock controls provided by the PRCI */
> +struct __prci_clock __prci_init_clocks_fu740[] = {
> + [PRCI_CLK_COREPLL] = {
> + .name = "corepll",
> + .parent_name = "hfclk",
> + .ops = _fu740_prci_wrpll_clk_ops,
> + .pwd = &__prci_corepll_data,
> + },
> + [PRCI_CLK_DDRPLL] = {
> + .name = "ddrpll",
> + .parent_name = "hfclk",
> + .ops = _fu740_prci_wrpll_clk_ops,
> + .pwd = &__prci_ddrpll_data,
> + },
> + [PRCI_CLK_GEMGXLPLL] = {
> + .name = "gemgxlpll",
> + .parent_name = "hfclk",
> + .ops = _fu740_prci_wrpll_clk_ops,
> + .pwd = &__prci_gemgxlpll_data,
> + },
> + [PRCI_CLK_DVFSCOREPLL] = {
> + .name = "dvfscorepll",
> + .parent_name = "hfclk",
> + .ops = _fu740_prci_wrpll_clk_ops,
> + .pwd = &__prci_dvfscorepll_data,
> + },
> + [PRCI_CLK_HFPCLKPLL] = {
> + .name = "hfpclkpll",
> + .parent_name = "hfclk",
> + .ops = _fu740_prci_wrpll_clk_ops,
> + .pwd = &__prci_hfpclkpll_data,
> + },
> + [PRCI_CLK_CLTXPLL] = {
> + .name = "cltxpll",
> + .parent_name = "hfclk",
> + .ops = _fu740_prci_wrpll_clk_ops,
> + .pwd = &__prci_cltxpll_data,
> + },
> + [PRCI_CLK_TLCLK] = {
> + .name = "tlclk",
> + .parent_name = "corepll",
> + .ops = _fu740_prci_tlclksel_clk_ops,
> + },
> + [PRCI_CLK_PCLK] = {
> + .name = "pclk",
> + .parent_name = "hfpclkpll",
> + .ops = _fu740_prci_hfpclkplldiv_clk_ops,
> + },
> + [PRCI_CLK_PCIEAUX] {
> + .name = "pciaux",
Shouldn't that be called "pcieaux"?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH v2 2/2] test: unit test for longjmp
On Mär 24 2021, Heinrich Schuchardt wrote: > And foo is obviously "changed between the setjmp invocation and longjmp > call". > > The current version of the patch is: > https://patchwork.ozlabs.org/project/uboot/patch/20210323181127.32411-3-xypron.g...@gmx.de/ > > So I guess we have to declare env as volatile in setjmp() in this > version of the patch because it is changed between the setjmp and > longjmp invocations? Yes, I think so, or make it static. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v2 2/2] test: unit test for longjmp
On Mär 22 2021, Sean Anderson wrote:
> int test_longjmp_ret(int i)
> {
> jmp_buf env;
> int ret;
> int foo = i;
>
> ret = setjmp(env);
> if (ret)
> return foo;
> foo = 0x1000;
> longjmp(env, i);
> /* We should not arrive here */
> return foo;
This is undefined. When modifying a non-volatile auto variable between
setjmp and longjmp, there is no requirement that the value is preserved.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH] efi_loader: Enable run-time variable support for tee based variables
On Jan 15 2021, Ilias Apalodimas wrote: > Anyway removing -fpic should work as well, but I'd rather do this [1], > instead of relying on linker flags. It's not the linker that breaks this, but the compiler, by forcing GOT addressing. And it can easily break again any time. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH] efi_loader: Enable run-time variable support for tee based variables
On Jan 14 2021, Atish Patra wrote: > I am a bit confused how this will work. This means it will reside in GOT > which is not mapped in virtual address for Linux. Whenever we try to > invoke get_variable service, it will panic. > Did we miss a trick in RISC-V ? I think the problem really is that RISC-V use -fpic for compiling. If I change that to -fpie, there is no longer a GOT reference. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [RESEND PATCH v5 1/6] riscv: Add boot hartid to Device tree
On Apr 17 2020, Atish Patra wrote: > Linux booting protocol mandates that register "a0" contains the hartid. > However, U-boot can not pass the hartid via a0 during via standard UEFI s/during via/during/ Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [U-Boot] [PATCH v3 2/2] sifive: fu540: Enable OF_SEPARATE
On Nov 09 2019, Jagan Teki wrote: > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst > index 7807f5b2c1..91b94ee06f 100644 > --- a/doc/board/sifive/fu540.rst > +++ b/doc/board/sifive/fu540.rst > @@ -58,7 +58,7 @@ firmware. We need to compile OpenSBI with below command: > > .. code-block:: none > > -make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH= > FW_PAYLOAD_FDT_PATH= > +make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH= > > (Note: Prefer hifive-unleashed-a00.dtb from Linux-5.3 or higher) > (Note: Linux-5.2 is also fine but it does not have ethernet DT node) Are these notes now obsolete? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sifive: riscv: update Hifive Unleashed configuration infrastructure
On Jul 30 2019, Sagar Kadam wrote: > I do remember using "git mv" here. git mv is identical to git rm + git add. A git repository has no concept of file renames. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V
On Mär 08 2019, Anup Patel wrote: > The reset button works fine for me an Atish. I am sure it works fine for lot > of > other folks too. There is no issue with the reset button, only with openSBI. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V
On Mär 07 2019, Anup Patel wrote: > Like I mentioned, there is no functional issue with this series. The > warm-boot issues were fixed in OpenSBI. > > @Andreas, please try at your end. As long as issue#65 isn't fixed opensbi is mostly a no-go for me. At least it gives me more reasons to press the reset button. :-) Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V
On Mär 06 2019, Anup Patel wrote: > On Wed, Mar 6, 2019 at 5:17 PM Andreas Schwab wrote: >> >> On Mär 06 2019, Anup Patel wrote: >> >> >> -Original Message- >> >> From: Andreas Schwab >> >> Sent: Wednesday, March 6, 2019 4:27 PM >> >> To: Anup Patel >> >> Cc: Auer, Lukas ; u-boot@lists.denx.de; >> >> paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org; >> >> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com; >> >> r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish Patra >> >> >> >> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V >> >> >> >> Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51 >> >> core), which will then fail to start userspace, since that cannot cope >> >> with the >> >> missing fpu. >> > >> > That's not possible >> >> Yes, it is. >> >> >> OpenSBI v0.3 (Mar 6 2019 10:55:01) >>_ _ >> / __ \ / | _ \_ _| >> | | | |_ __ ___ _ __ | (___ | |_) || | >> | | | | '_ \ / _ \ '_ \ \___ \| _ < | | >> | |__| | |_) | __/ | | |) | |_) || |_ >> \/| .__/ \___|_| |_|_/|/_| >> | | >> |_| >> >> Platform Name : SiFive Freedom U540 >> Platform HART Features : RV64ACDFIMSU >> Platform Max HARTs : 5 >> Current Hart : 2 >> Firmware Base : 0x8000 >> Firmware Size : 88 KB >> Runtime SBI Version: 0.1 >> >> PMP0: 0x8000-0x8001 (A) >> PMP1: 0x-0x007f (A,R,W,X) >> >> >> U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10 +0100) >> >> CPU: rv64imac >> Model: sifive,hifive-unleashed-a00 >> DRAM: 8 GiB > > How does this prove that U-Boot is booting on HART 0? See the CPU isa. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V
On Mär 06 2019, Anup Patel wrote: >> -Original Message- >> From: Andreas Schwab >> Sent: Wednesday, March 6, 2019 4:27 PM >> To: Anup Patel >> Cc: Auer, Lukas ; u-boot@lists.denx.de; >> paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org; >> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com; >> r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish Patra >> >> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V >> >> Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51 >> core), which will then fail to start userspace, since that cannot cope with >> the >> missing fpu. > > That's not possible Yes, it is. OpenSBI v0.3 (Mar 6 2019 10:55:01) _ _ / __ \ / | _ \_ _| | | | |_ __ ___ _ __ | (___ | |_) || | | | | | '_ \ / _ \ '_ \ \___ \| _ < | | | |__| | |_) | __/ | | |) | |_) || |_ \/| .__/ \___|_| |_|_/|/_| | | |_| Platform Name : SiFive Freedom U540 Platform HART Features : RV64ACDFIMSU Platform Max HARTs : 5 Current Hart : 2 Firmware Base : 0x8000 Firmware Size : 88 KB Runtime SBI Version: 0.1 PMP0: 0x8000-0x8001 (A) PMP1: 0x-0x007f (A,R,W,X) U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10 +0100) CPU: rv64imac Model: sifive,hifive-unleashed-a00 DRAM: 8 GiB Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V
Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51 core), which will then fail to start userspace, since that cannot cope with the missing fpu. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
On Feb 13 2019, Anup Patel wrote: > General practice (atlease what I have seen on few boards), is that board > will have unique MAC address printed/labelled for each Ethernet port. We > can just set-and-save "ethaddr" U-Boot env variable based on MAC address > printed on board. > > Unfortunately, I was not able to find printed MAC address on Unleashed board. It is derived from the serial number. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
On Feb 13 2019, Alexander Graf wrote: > The DT is supplied via SD card That's not true by default. It is part of the FSBL, I think. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
On Feb 12 2019, Bin Meng wrote: > The env var is stored in whatever supported media in U-Boot. Not like > PCI NICs which normally have EEPROM to store pre-flashed MAC address > by their vendors, for most embedded network controllers in the SoC, > normally there is no hardware provided mechanism to ensure a unique > MAC address, instead it relies on software to program one to the > hardware before bringing it up. On the Hifive the MAC is part of the initial DT, so there is no need to use a secondary store. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
On Feb 12 2019, Bin Meng wrote: > On Tue, Feb 12, 2019 at 4:34 PM Andreas Schwab wrote: >> >> On Feb 12 2019, Anup Patel wrote: >> >> > This is because we don't have place to put U-Boot environment >> > variables as of now on Unleashed board. This will be solved once >> > we have SPI driver and SPI_MMC driver for Unleased board. >> >> Isn't the MAC part of the initial DT? >> > > My understanding is that U-Boot should fixup the DT using the > environment value, before jumping to Linux. But where does it get the env var from? Why would it need to modify the MAC? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
On Feb 12 2019, Anup Patel wrote: > This is because we don't have place to put U-Boot environment > variables as of now on Unleashed board. This will be solved once > we have SPI driver and SPI_MMC driver for Unleased board. Isn't the MAC part of the initial DT? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 00/15] SiFive FU540 Support
On Feb 11 2019, Anup Patel wrote: > This patchset adds SiFive Freedom Unleashed (FU540) support > to RISC-V U-Boot. > > The patches are based upon latest U-Boot source tree > (git://git.denx.de/u-boot.git) at commit id > dbe70c7d4e3d5c705a98d82952e05a591efd0683 > > All drivers namely: SiFive PRCI, SiFive Serial, and Cadance > MACB Ethernet work fine on actual SiFive Unleashed board and > QEMU sifive_u machine. Looks like the MACB driver cannot find the correct MAC address. That makes it rather awkward for network boot. Warning: ethernet@1009 (eth0) using random MAC address - 0e:14:15:06:ae:e4 Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Feb 05 2019, Anup Patel wrote: > Ahh, looks like it is not picking up "CC" set by Makefile. This might > be because you have removed "-R" from MAKEFLAGS. Nope. That fixed it. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
mkdir -p `dirname /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep`; echo " AS-DEPplatform/sifive/fu540/firmware/fw_payload.dep"; echo -n `dirname /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep`/ > /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep && -g -Wall -nostdlib -D__ASSEMBLY__ -fno-omit-frame-pointer -fno-optimize-sibling-calls -mno-save-restore -mstrict-align -I/net/hawking/daten/src/riscv/opensbi/platform/sifive/fu540/include -I/net/hawking/daten/src/riscv/opensbi/platform/common/include -I/net/hawking/daten/src/riscv/opensbi/include -I/net/hawking/daten/src/riscv/opensbi/platform/common/libfdt/ -DFW_TEXT_START=0x8000 -DFW_JUMP_ADDR=0x8020 -DFW_JUMP_FDT_ADDR=0x8220 -DFW_PAYLOAD_PATH=/boot/Image-5.0.0-rc5-00011-gcf1db34127ee -DFW_PAYLOAD_OFFSET=0x20 -DFW_PAYLOAD_FDT_ADDR=0x8220 -mabi=lp64 -march=rv64imafdc -mcmodel=medany -I/net/hawking/daten/src/riscv/opensbi/firmware -D__OBJNAME__=fw_payload.dep -MM /net/hawking/daten/src/riscv/opensbi/firmware/fw_payload.S >> /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep || rm -f /net/hawking/daten/src/riscv/opensbi/build/platform/sifive/fu540/firmware/fw_payload.dep Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Feb 05 2019, Anup Patel wrote: > Okay, if you are doing native compilation then > make sure CROSS_COMPILE is not set so that > makefile will take native compiler instead of > cross-compiler. AS-DEPplatform/sifive/fu540/firmware/fw_payload.dep /bin/sh: -g: command not found Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Feb 05 2019, Anup Patel wrote: > The OpenSBI build is similar to Linux and U-Boot. We expect > CROSS_COMPILE environment variable to be set. Why? That doesn't make sense. > Example, if you cross-compiler I don't have a cross compiler. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Feb 04 2019, Atish Patra wrote: > Probably your cross compilation is not set. Can you try this ? > > export ARCH=riscv > export CROSS_COMPILE= There is no cross compile prefix. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Feb 03 2019, Anup Patel wrote: > Can try with https://github.com/riscv/opensbi.git ? AS-DEPplatform/sifive/fu540/firmware/fw_payload.dep /bin/sh: -g: command not found Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Jan 24 2019, Alexander Graf wrote: > On 24.01.19 14:38, Andreas Schwab wrote: >> On Jan 24 2019, Alexander Graf wrote: >> >>> Board_init() is too late. This needs to go into early_board_init_f(). >> >> I don't think we can modify the DT that early. > > I'm sure we can. Worst case we have to copy it over to RAM first. reserve_fdt is only called much later. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Jan 24 2019, Alexander Graf wrote: > Board_init() is too late. This needs to go into early_board_init_f(). I don't think we can modify the DT that early. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Jan 23 2019, Atish Patra wrote: > or you can try to edit the DT directly and update the FSBL if you are > comfortable with it. I think it would make sense to add the node in the board init function. That way it would work whether or not the FSBL is updated. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Jan 21 2019, Anup Patel wrote: > On Mon, Jan 21, 2019 at 10:40 PM Andreas Schwab wrote: >> >> On Jan 21 2019, Anup Patel wrote: >> >> > There is a fix required in BBL for real board. We have not send >> > this fix to riscv-pk. >> >> Where can I find the patch? > > The fix is to set following DT prop in /chosen DT node: > stdout-path = "/soc/serial@1001:115200" How can I do that? I cannot find any function in fdt.c to add new nodes. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Jan 21 2019, Anup Patel wrote: > There is a fix required in BBL for real board. We have not send > this fix to riscv-pk. Where can I find the patch? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Jan 21 2019, Anup Patel wrote: > On real board, we generally boot OpenSBI+U-Boot. We will > try and share log of BBL+U-Boot on real board but the log will > look exactly like above. Nothing is seen on the real board. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] riscv: Add SiFive FU540 board support
On Jan 18 2019, Anup Patel wrote: > This patch adds SiFive FU540 board support. For now, only > SiFive serial, SiFive PRCI, and Cadance MACB drivers are > only enabled. The SiFive FU540 defconfig by default builds > U-Boot for S-Mode because U-Boot on SiFive FU540 will run > in S-Mode as payload of BBL or OpenSBI. What am I expected to see when started with BBL? All I see is the logo, then nothing. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
