Re: Need help: alternative module inclusion - duplicate symbols
Sorry forget about this, wrong mailing list !
Am 26.02.2024 um 11:36 schrieb Michael Lawnick:
> Hi group,
>
> hope you can help me:
> I have modules pci_fpga.c and pci_fpga_emul.c with same functions in
> them but different implementation, one for the real device, the other
> one is an emulation.
>
> What I now want is being able to include one of both versions through
> build command. I started with this:
>
> Makefile.core.def:
> ...
> module = {
> name = pci_fpga;
> common = startlib/board/pci_fpga.c;
> enable = efi;
> };
>
> module = {
> name = pci_fpga_emul;
> common = startlib/board/pci_fpga_emul.c;
> enable = efi;
> };
> ...
>
> and then give pci_fpga or pci_fpga_emu on the build but then I get
> duplicate symbols error.
>
> For using different packages than common like this
> module = {
> name = pci_fpga;
> pci_fpga = startlib/board/pci_fpga.c;
> enable = pci_fpga;
> };
> I could not find means to get pci_fpga included.
>
> Same problem if trying to approach it via different enable flag: How to?
>
> Can anybody help? In docs I couldn't find usable hints.
>
> --
> KR
> Michael
Need help: alternative module inclusion - duplicate symbols
Hi group,
hope you can help me:
I have modules pci_fpga.c and pci_fpga_emul.c with same functions in
them but different implementation, one for the real device, the other
one is an emulation.
What I now want is being able to include one of both versions through
build command. I started with this:
Makefile.core.def:
...
module = {
name = pci_fpga;
common = startlib/board/pci_fpga.c;
enable = efi;
};
module = {
name = pci_fpga_emul;
common = startlib/board/pci_fpga_emul.c;
enable = efi;
};
...
and then give pci_fpga or pci_fpga_emu on the build but then I get
duplicate symbols error.
For using different packages than common like this
module = {
name = pci_fpga;
pci_fpga = startlib/board/pci_fpga.c;
enable = pci_fpga;
};
I could not find means to get pci_fpga included.
Same problem if trying to approach it via different enable flag: How to?
Can anybody help? In docs I couldn't find usable hints.
--
KR
Michael
Re: Help needed: EFI debug
Am 13.01.2023 um 15:52 schrieb Heinrich Schuchardt: On 1/13/23 14:47, Michael Lawnick wrote: Hi, I am trying to printf-debug EFI execution triggered by Linux call. Specifically I remove a persistent variable via Linux console and want to follow execution. Without any printf() this works fine. I need this Hello Michael, U-Boot does not implement SetVariable() at runtime yet. Hi Heinrich, seems we got this by our SoC Vendor who provides us with U-Boot with EFI support. to refine existing implementation of saving variables to SPI flash. While printf() works in U-Boot startup context it leads to crash when EFI function was called from Linux. Same for putc(). Next I tried efi_st_printf() but this already crashes in U-Boot startup context. How do you achieve printf() debugging in this scenario? Which initialization steps are required to get efi_st_printf() working outside self_test context? TIA & KR Michael U-Boots print functions can only be used before ExitBootServices(). Don't use any library function that is not declared __efi_runtime after this point. that was my problem. At UEFI runtime you might be able to invoke a Linux syscall. I never tried it. Meanwhile I found out that the SPI write is moved into ATF from where I have much less restrictions. As such my problem is solved for now. Or move the debug output into a different UEFI variable using * efi_var_mem_del() to delete the existing instance * efi_var_mem_ins() to create the new instance Both calls are needed. Nice ugly idea :-) THX Michael
Help needed: EFI debug
Hi, I am trying to printf-debug EFI execution triggered by Linux call. Specifically I remove a persistent variable via Linux console and want to follow execution. Without any printf() this works fine. I need this to refine existing implementation of saving variables to SPI flash. While printf() works in U-Boot startup context it leads to crash when EFI function was called from Linux. Same for putc(). Next I tried efi_st_printf() but this already crashes in U-Boot startup context. How do you achieve printf() debugging in this scenario? Which initialization steps are required to get efi_st_printf() working outside self_test context? TIA & KR Michael
Re: Running qemu tests on RISC-V
Hi Simon, having absolutely no knowledge about the details here just 2 cents: It looks like concurrent run of multiple cores. Are you sure that all cores beside #0 are properly caught and blocked on start? KR Michael Am 07.02.2022 um 16:38 schrieb Simon Glass: Hi, I am trying to run the SPL tests for riscv32 but it dies with an illegal instruction. I have tried building qemu 4.2 but it seems to happen on various versions. Has anyone seen this? +u-boot-test-reset qemu-riscv32_spl na U-Boot SPL 2022.01 (Feb 07 2022 - 08:33:30 -0700) Trying to boot from RAM Unhandled exception: Illegal instruction EPC: 8UUU1000564nhandled nhandled exception:nhandled exceptexception: ion: RA: 81IIllegal10 instruction Iegal inegal instruction EPC: structEPC: ion EPC: TVAL: 81081000564 RA: 008100564 RA: 810100010 TVAL: TV 000 AL: 00 ode:0 Code:3400 050 808334004082 0073 00 8081050 2 bff5 0001 55b7007 4942 ( 3 859b 134f5) 2 0073 bff5 0 001 1050 bff5 055b7 001 55b74942 4942 ((859b 859b 34f34f5) 5) 81000564 RA: 8110 TVAL: Code: 3400 8082 0073 1050 bff5 0001 55b7 4942 (859b 34f5) resresetting ... pporesetting ...ng ... rese trtered ys not supported yet ### ERROet R ### Please RES### ERRet notET the board ### OR ### Please sRESEupT the board ### ported yet ### ERROR ### Please RESET the board ### Regards, Simon
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 11:37 schrieb AKASHI Takahiro: On Thu, Sep 16, 2021 at 11:14:01AM +0200, Michael Lawnick wrote: Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro: On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote: Am 16.09.2021 um 09:15 schrieb Michael Lawnick: - What is the reason/use to iterate through the recognized partitions even twice (in .setup and .execute) if they aren't needed/used? What line of code do you exactly mean by 'in .setup' (and in .execute)? My understanding: efi_selftests register their methods separated by setup/execute/teardown. The central test control is taking tests from list and executes the three methods, unaware of which exact test is executed: lib/efi_selftest/efi_selftest.c That is exactly what efi_selftest.c does. lib/efi_selftest/efi_selftest_block_device.c And this is a test instance for block device test. So what's your question? Hmm, I think the question is really clear, I don't know how to ask differently. But as the original issue is cleared and this is only for background understanding, let's drop it. THX again to you and Heinrich for fast help. -- KR Michael
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro: On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote: Am 16.09.2021 um 09:15 schrieb Michael Lawnick: Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration. Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try. Sometimes live is such easy. This fixed my issue, THX. For the after-math / my understanding: - Do I understand correctly that the problem was that 'efi_selftest block device' requires FAT support? So shouldn't there be a dependency in CONFIG? Strictly speaking, CONFIG_EFI_LOADER requires FAT per UEFI specification, and actually it has 'imply FAT'. I don't know why Heinrich uses 'imply' instead of 'select'. - What is the reason/use to iterate through the recognized partitions even twice (in .setup and .execute) if they aren't needed/used? What line of code do you exactly mean by 'in .setup' (and in .execute)? My understanding: efi_selftests register their methods separated by setup/execute/teardown. The central test control is taking tests from list and executes the three methods, unaware of which exact test is executed: lib/efi_selftest/efi_selftest.c lib/efi_selftest/efi_selftest_block_device.c
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 09:15 schrieb Michael Lawnick: Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration. Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try. Sometimes live is such easy. This fixed my issue, THX. For the after-math / my understanding: - Do I understand correctly that the problem was that 'efi_selftest block device' requires FAT support? So shouldn't there be a dependency in CONFIG? - What is the reason/use to iterate through the recognized partitions even twice (in .setup and .execute) if they aren't needed/used? -- KR Michael
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: On Wed, Sep 15, 2021 at 05:06:09PM +0200, Michael Lawnick wrote: Am 15.09.2021 um 13:36 schrieb Michael Lawnick: Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt: Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick : Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt: Could you, please send the complete output starting with 'bootefi selftest'. ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest Testing EFI API implementation Selected test: 'block device' Setting up 'block device' Setting up 'block device' succeeded Executing 'block device' ** Unrecognized filesystem type ** Is the FAT file system enabled in the configuration? No lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed Tearing down 'block device' Tearing down 'block device' succeeded Boot services terminated Summary: 1 failures Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible. We have 8 partitions of which no. 5 isn't initialized. I have put a bunch of printf to the code and see that the execute() is done exactly on the partition which is unknown, no other gets touched !? Just in case, "block device" selftest doesn't touch you disk at all. Instead, it sets up some memory region as a pseudo block device (i.e. block_io_protocol) with fat filesystem, and utilizes it for the test execution. Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration. Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try. KR Michael
Re: RFC: exclude partitions from efi_selftest
Am 15.09.2021 um 13:36 schrieb Michael Lawnick: Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt: Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick : Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt: Could you, please send the complete output starting with 'bootefi selftest'. ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest Testing EFI API implementation Selected test: 'block device' Setting up 'block device' Setting up 'block device' succeeded Executing 'block device' ** Unrecognized filesystem type ** Is the FAT file system enabled in the configuration? No lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed Tearing down 'block device' Tearing down 'block device' succeeded Boot services terminated Summary: 1 failures Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible. We have 8 partitions of which no. 5 isn't initialized. I have put a bunch of printf to the code and see that the execute() is done exactly on the partition which is unknown, no other gets touched !? -- KR Michael
Re: RFC: exclude partitions from efi_selftest
Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt: Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick : Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt: Could you, please send the complete output starting with 'bootefi selftest'. ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest Testing EFI API implementation Selected test: 'block device' Setting up 'block device' Setting up 'block device' succeeded Executing 'block device' ** Unrecognized filesystem type ** Is the FAT file system enabled in the configuration? No lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed Tearing down 'block device' Tearing down 'block device' succeeded Boot services terminated Summary: 1 failures Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible. -- KR Michael
Re: RFC: exclude partitions from efi_selftest
Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt: Could you, please send the complete output starting with 'bootefi selftest'. ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest Testing EFI API implementation Selected test: 'block device' Setting up 'block device' Setting up 'block device' succeeded Executing 'block device' ** Unrecognized filesystem type ** lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed Tearing down 'block device' Tearing down 'block device' succeeded Boot services terminated Summary: 1 failures -- KR Michael
Re: RFC: exclude partitions from efi_selftest
Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt: On 9/14/21 4:56 PM, Michael Lawnick wrote: Hi, in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you. When the UEFI sub-system is intialized we call efi_disk_register(). If it fails, we don't enter the UEFI sub-system. Are you able to identify where efi_disk_register() fails? The system starts up properly. This is what I see: ASIM-CN10KAS> efiload $loadaddr Loaded EFI App image at 0x4008 with 0x216000 bytes ASIM-CN10KAS> bootefi $loadaddr $fdtaddr Scanning disk sd...@8240.blk... ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** ** Unrecognized filesystem type ** Found 8 disks Init Monotonic Count to zero ... But the efi selftest fails. Shouldn't be the registering of partitions for self test been made dependent on successful basic init? I wouldn't qualify a non-initialized partition as reason to let self test fail. If at all a warning should be sufficient. As far as I understand efi self test is intended more as a functional regression test, not a H/W system test, isn't it? What about the idea to allow to exclude partitions by environment variable? We use efi_selftest in our continuous integration. Patches that make it fail will not be accepted upstream. It is nothing that you need on a deployed production system. Somehow I miss the connection between my question and your answer. We want to integrate the efi_selftest into our CI, too. But if it fails due to one uninitialized partition out of 8 then things become more complicated than they should. Based on this I am asking why this problem exists at all. -- KR Michael
RFC: exclude partitions from efi_selftest
Hi, in our environment we get error on efi_selftest if one of several SSD partitions isn't properly initialized (due to some other error, but that's a different topic). I tried to track down to where the partitions get registered for test but got a bit lost so I request advice from you. Shouldn't be the registering of partitions for self test been made dependent on successful basic init? I wouldn't qualify a non-initialized partition as reason to let self test fail. If at all a warning should be sufficient. As far as I understand efi self test is intended more as a functional regression test, not a H/W system test, isn't it? What about the idea to allow to exclude partitions by environment variable? KR Michael
Re: Q: EFI_SPI support
Nobody interested or is subject formatting wrong so it slips through all filters? Am 23.11.2020 um 14:23 schrieb Michael Lawnick: Hi, before starting to walk the troublesome way on my own: Is there any development for EFI_SPI, EFI_I2C and/or EFI_PCI ongoing? I will have to write an EFI application that needs access to devices on these buses. So I try to find the path with lowest harm. KR Michael Lawnick
Q: EFI_SPI support
Hi, before starting to walk the troublesome way on my own: Is there any development for EFI_SPI, EFI_I2C and/or EFI_PCI ongoing? I will have to write an EFI application that needs access to devices on these buses. So I try to find the path with lowest harm. KR Michael Lawnick
Re: [U-Boot] [PATCH v5 4/9] armv8: Add workaround for USB erratum A-008997
Am 04.09.2017 um 12:46 schrieb Ran Wang: ... arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 6 ++ arch/arm/cpu/armv8/fsl-layerscape/soc.c| 24 ++ ... Maybe I'm a bit pedentatic, but this doesn't sound for ARMv8 but for fsl-layerscape patch ... -- KR Michael ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] UBIFS: Missing offset relocation for compressor 'none'
On systems where U-Boot is linked to another address than it really lays (e.g. backup image), calls via function pointers must be fixed with a '+= gd->reloc_off'. This was not done for none_compr in ubifs_compressors_init() what leads to system crash on ubifsmount command. Signed-off-by: Michael Lawnick --- fs/ubifs.c |5 +- 1 files changed, 4 insertions(+), 1 deletions(-) diff -Naur a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c --- a/fs/ubifs/ubifs.c 2009-02-20 16:02:44.434443000 +0100 +++ b/fs/ubifs/ubifs.c 2009-03-18 16:06:09.0 +0100 @@ -147,7 +147,10 @@ int __init ubifs_compressors_init(void) if (err) return err; - ubifs_compressors[UBIFS_COMPR_NONE] = &none_compr; + err = compr_init(&none_compr); + if (err) + return err; + return 0; } -- Kind regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] UBIFS: Missing offset relocation for compressor 'none'
Michael Lawnick said the following: > On systems where U-Boot is linked to another address than it really lays > (e.g. backup image), calls via function pointers must be fixed with a > '+= gd->reloc_off'. > This was not done for none_compr in ubifs_compressors_init() what leads > to system crash on ubifsmount command. > > Signed-off-by: Michael Lawnick > --- What now followed is rubbish and works by chance. Please ignore, correct patch in a few hours. Sorry :-( -- Regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] UBIFS: Missing offset relocation for compressor 'none'
On systems where U-Boot is linked to another address than it really lays (e.g. backup image), calls via function pointers must be fixed with a '+= gd->reloc_off'. This was not done for none_compr in ubifs_compressors_init() what leads to system crash on ubifsmount command. Signed-off-by: Michael Lawnick --- fs/ubifs.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff -Naur a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c --- a/fs/ubifs/ubifs.c 2009-02-20 16:02:44.434443000 +0100 +++ b/fs/ubifs/ubifs.c 2009-03-18 16:06:09.0 +0100 @@ -147,7 +147,7 @@ int __init ubifs_compressors_init(void) if (err) return err; - ubifs_compressors[UBIFS_COMPR_NONE] = &none_compr; + ubifs_compressors[UBIFS_COMPR_NONE] = compr_init(&none_compr); return 0; } -- Kind regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] saveenv command erases flash u-boot
rudresh said the following: [quoting repaired] > Michael Lawnick wrote: >> >> rudresh said the following: >>> i'm using u-boot -1.3.0 in MPC8313 evaluation board, it having a NAND , >>> NOR >>> Flash , u-boot stored in NOR flash. when i do the saveenv , reset command >>> the u-boot is erased. i'm not able to fix this issue. help me to fix >>> this >>> issue >> >> Sounds U-Boot and environment share a flash sector. >> You'll have to give more info for correct diagnostic: >> Flash size, sector size, u-boot start address and size, position of >> environment data and if applicable of redundancy data. > Details are as follows .. the flash size 16Mbyte Nor flash.. NAND flash > 256MB. > /* > * Environment > */ > > #if defined(CONFIG_NAND_U_BOOT) ... > #elif !defined(CFG_RAMBOOT) ... > #else ... > #endif And now you expect me to guess your boot setting? Assuming neither CONFIG_NAND_U_BOOT nor CFG_RAMBOOT are set: check u-boot image size against 256k, as the offset of environment seems to be set to CFG_MONITOR_BASE + 0x4 Or is ONFIG_NAND_U_BOOT set (would be the explanation why you mention NAND at all ...)? With u-boot in NOR this indicates a general code/configuration problem in your image. HTH -- Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] saveenv command erases flash u-boot
rudresh said the following: > i'm using u-boot -1.3.0 in MPC8313 evaluation board, it having a NAND , NOR > Flash , u-boot stored in NOR flash. when i do the saveenv , reset command > the u-boot is erased. i'm not able to fix this issue. help me to fix this > issue Sounds U-Boot and environment share a flash sector. You'll have to give more info for correct diagnostic: Flash size, sector size, u-boot start address and size, position of environment data and if applicable of redundancy data. -- Regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Error uncompressing kernel image
Alemao said the following: > return Z_MEM_ERROR; > > > Any ideas why this is happening? Out of memory. You don't tell us processor architecture/type. In my case (PPC, u-boot 1.3.3 ff) I'd take a look into include/configs/.h and would increase the constant CONFIG_SYS_MALLOC_LEN HTH -- Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Makefile question
Steven Zedeck said the following: > For example, I'm having problems understanding what this means in a > Makefile: > > COBJS-$(CONFIG_HAS_DATAFLASH) += at45.o > COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o > COBJS-$(CONFIG_HAS_DATAFLASH) += dataflash.o > COBJS-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o > COBJS-$(CONFIG_MW_EEPROM) += mw_eeprom.o > > COBJS := $(COBJS-y) > SRCS := $(COBJS:.o=.c) > OBJS := $(addprefix $(obj),$(COBJS)) > > This is from drivers/mtd/Makefile. > > How does COBJS get initially defined upon entry into the Makefile? > > Does at45.o get added to the list of objects to be built only if the > CONFIG_HAS_DATAFLASH flag is set? > > What does the "-" sign mean before the "$" ? > On start of compile, the file autoconf.mk is generated along your board configuration #defines in board//.h It looks like this: CONFIG_PPC=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y CONFIG_SYS_CLK_FREQ=1 CONFIG_CMD_ITEST=y ... autoconf.mk is then used as a predefinition file for the rules of your Makefile. So COBJS-$(CONFIG_HAS_DATAFLASH) += at45.o evaluates to either COBJS-y += at45.o or COBJS- += at45.o or COBJS-n += at45.o > What does this mean? COBJS := $(COBJS-y) This is the assignment of the dynamically built string to the variable that is then used for the gcc command. HTH -- Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Not able to access uboot newsgroup from thunderbird
Sriram Chadalavada said the following: > My mistake Wolfang. Will not happen again. Although I am not sure why I am > not able to access the newsgroup from Thunderbird. > > I am using the free news server nntp.aioe.org. Anyone else using thunderbird > to access the newsgroup?? Subscribe to news.gmane.org Group is gmane.comp.boot-loaders.u-boot You definitely shouldn't do top-pos / full-quote. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Generic CFI flash driver is not so generic?
Choe, Hyun-ho said the following: > My second workaround is strange, too. > In ARM code, mapping physical address to logical is actually does > nothing, except re-calculating pointer with sector no. and offset. > It just eating several processor cycles. I actually have no ARM experience, but when you talk about 'mapping' the word 'cache' is coming to my mind. Any chance that you have not disabled caching for flash access address space? -- Michael Lawnick Software Design Engineer Lise-Meitner-Str. 7/1 89081 Ulm Tel: +49 731 9533 2066 [EMAIL PROTECTED] http://www.nokiasiemensnetworks.com/global/ Think before you print ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] Some speed improvements to U-Boot JFFS2 code
Joakim Tjernlund said the following: > On Tue, 2008-11-04 at 13:31 +0100, Michael Lawnick wrote: >> Could we modify this declaration to my non-static version in the trunk? > > Is this on PPC? If so it is due to missing fixup support. Grant Likely > once sent a patch fixing this. It got applied, but later reverted > because there was some problems that never got solved. It is on PPC. IMHO such parts should be removed at least step by step, where it is proven that the dynamic version works. I can't see any benefit in the static solution here. -- Michael Lawnick Software Design Engineer Lise-Meitner-Str. 7/1 89081 Ulm Tel: +49 731 9533 2066 [EMAIL PROTECTED] http://www.nokiasiemensnetworks.com/global/ Think before you print ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] Some speed improvements to U-Boot JFFS2 code
Michael Lawnick said the following: ... > - output of access rights is still corrupted, e.g.: > d-ÿÿ-ÿ0 Tue Oct 21 11:08:17 2008 10 > --ÿÿ-ÿ 262144 Thu Jan 01 00:00:33 1970 u-boot.bin > d-ÿÿ-ÿ0 Tue Oct 21 11:08:32 2008 1 > d-ÿÿ-ÿ0 Tue Oct 21 11:00:58 2008 2 ... Ok, fixed this in my code: in jffs2_1pass.c @@ mkmodestr(unsigned long mode, char *str) you'll find declaration static const char *l = "xwr"; Although this is per se correct, it is not needed in context and screws up 'ls' in my case: Our u-boot is not placed in flash were it is located to on compilation time. static const char * points into flash space at some not properly initialized flash space. After modifying to char *l = "xwr"; output of access rights is fine now: drwxr-xr-x0 Tue Oct 21 11:08:17 2008 10 -rwxr-xr-x 262144 Thu Jan 01 00:00:33 1970 u-boot.bin drwxr-xr-x0 Tue Oct 21 11:08:32 2008 1 drwxr-xr-x0 Tue Oct 21 11:00:58 2008 2 (Still directories are listed multiple times) Could we modify this declaration to my non-static version in the trunk? -- Michael Lawnick Software Design Engineer Lise-Meitner-Str. 7/1 89081 Ulm Tel: +49 731 9533 2066 [EMAIL PROTECTED] http://www.nokiasiemensnetworks.com/global/ Think before you print ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] Some speed improvements to U-Boot JFFS2 code
Ilya Yanok said the following: > Hello Michael, > > Michael Lawnick wrote: ... >> d) output of 'ls' is corrupted: no date and access right output, >> directories in / are shown multiple times > > Can you please be more specific on this? Is this with > CFG_JFFS2_SORT_FRAGMENTS enabled or not? How did you create your FS? I > can't reproduce any of described symptoms on our system... > > The only thing I can tell you for now is that the first patch from my > posting is wrong, the following patch fixes the problem: > ... I added your patch, it corrected date part of 'ls'. For both versions (CFG_JFFS2_SORT_FRAGMENTS set or not set) - device root based directories are printed out up to 9 times - output of access rights is still corrupted, e.g.: d-ÿÿ-ÿ0 Tue Oct 21 11:08:17 2008 10 --ÿÿ-ÿ 262144 Thu Jan 01 00:00:33 1970 u-boot.bin d-ÿÿ-ÿ0 Tue Oct 21 11:08:32 2008 1 d-ÿÿ-ÿ0 Tue Oct 21 11:00:58 2008 2 The difference is: *with*CFG_JFFS2_SORT_FRAGMENTS time for ls is ~ 16s *without* CFG_JFFS2_SORT_FRAGMENTS time for ls is ~ 2s Setup scenario: U-boot flashed, Linux booted and jffs mounted on erased flash --> in background-process flash gets formatted. create dir '10' in root of flash, copy 2 files with ~1.2MB each into it. Run following script ~300 times: mkdir /flash/11 cp /flash/10/* /flash/11 rm -rf /flash/1 mv /flash/2 /flash/1 mv /flash/3 /flash/2 mv /flash/4 /flash/3 mv /flash/5 /flash/4 mv /flash/6 /flash/5 mv /flash/7 /flash/6 mv /flash/8 /flash/7 mv /flash/9 /flash/8 mv /flash/10 /flash/9 mv /flash/11 /flash/10 sync This should mix up jffs image enough to see what I observe. -- Michael Lawnick Software Design Engineer Lise-Meitner-Str. 7/1 89081 Ulm Tel: +49 731 9533 2066 [EMAIL PROTECTED] http://www.nokiasiemensnetworks.com/global/ Think before you print ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] Some speed improvements to U-Boot JFFS2 code
Ilya Yanok said the following: > Hi Wolfgang, > > Wolfgang Denk wrote: >>> here is a set of changes we made to improve U-Boot JFFS2 code >>> performance. We still can't reach Linux's performance but improvements >>> are significant. >>> >>> Any comments are welcome. >>> >> >> Are these patches independent of each other, or are all of them >> needed, and if so, is there any specific order in which they have to >> be applied? >> > Argh... I forgot to create patches with xxx/nnn notation... > Here is the order of patches: > 0001-jffs2-add-sector_size-field-to-part_info-structure.patch > 0002-jffs2-rewrite-jffs2-scanning-code-based-on-Linux-on.patch > 0003-jffs2-summary-support.patch > 0004-jffs2-fix-searching-for-latest-version-in-jffs2_1pa.patch > 0005-jffs2-add-buffer-to-cache-flash-accesses.patch > 0006-jffs2-cache-data_crc-results.patch > > It's the order of changes in my tree and thus it's the simplest way to > apply this patches. But actual dependencies are as follows: > 0001 and 0004 don't depend on anything > 0002 depends on 0001 > 0003, 0005 and 0006 depend on 0002 > > Regards, Ilya. I have put these patches to our board (MPC8548, NOR Flash, MTD partition size 48MB). a) performance has improved (execution time of 'ls' reduced from ~16s to ~1.5s) b) there is a bug in the patch 0005-jffs2-add-buffer-to-cache-flash-accesses: The passage @@ -724,12 +731,14 @@ jffs2_1pass_read_inode(struct b_lists *pL, u32 inode, char *dest) latestVersion = jNode->version; } } - put_fl_mem(jNode); + if (pL->readbuf == NULL) + put_fl_mem(jNode); } #endif should be @@ -724,12 +731,14 @@ jffs2_1pass_read_inode(struct b_lists *pL, u32 inode, char *dest) latestVersion = jNode->version; } } - put_fl_mem(jNode); + if (pL->readbuf == NULL) + put_fl_mem(jNode, NULL); } #endif c) I found no improvement with CFG_JFFS2_SORT_FRAGMENTS set (the way I detected b) ;-) d) output of 'ls' is corrupted: no date and access right output, directories in / are shown multiple times. -- Michael Lawnick Software Design Engineer Lise-Meitner-Str. 7/1 89081 Ulm Tel: +49 731 9533 2066 [EMAIL PROTECTED] http://www.nokiasiemensnetworks.com/global/ Think before you print ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] jffs2: cache data_crc results
Ilya Yanok said the following:
> As we moved data_crc() invocation from jffs2_1pass_build_lists() to
> jffs2_1pass_read_inode() data_crc is going to be calculated on each
> inode access. This patch adds caching of data_crc() results. There
> is no significant improvement in speed (because of flash access
> caching added in previous patch I think, crc in RAM is really fast)
> but this patch impacts memory usage -- every b_node structure uses
> 12 bytes instead of 8.
>
> Signed-off-by: Alexey Neyman <[EMAIL PROTECTED]>
> Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
> ---
> fs/jffs2/jffs2_1pass.c |5 -
> fs/jffs2/jffs2_private.h |1 +
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
> index 9d9ac1a..b41c299 100644
> --- a/fs/jffs2/jffs2_1pass.c
> +++ b/fs/jffs2/jffs2_1pass.c
> @@ -768,7 +768,10 @@ jffs2_1pass_read_inode(struct b_lists *pL, u32 inode,
> char *dest)
> put_fl_mem(jNode, pL->readbuf);
> continue;
> }
> - if (!data_crc(jNode)) {
> + if (b->datacrc == CRC_UNKNOWN)
> + b->datacrc = data_crc(jNode) ?
> + CRC_OK : CRC_BAD;
> + if (b->datacrc == CRC_BAD) {
> put_fl_mem(jNode, pL->readbuf);
> continue;
> }
> diff --git a/fs/jffs2/jffs2_private.h b/fs/jffs2/jffs2_private.h
> index b3fab1c..7a9eda6 100644
> --- a/fs/jffs2/jffs2_private.h
> +++ b/fs/jffs2/jffs2_private.h
> @@ -7,6 +7,7 @@
> struct b_node {
> u32 offset;
> struct b_node *next;
> + enum { CRC_UNKNOWN = 0, CRC_OK, CRC_BAD } datacrc;
> };
>
> struct b_list {
Could be so kind to give us your source reference?
I can't find above code in u-boot 1.3.3 nor 1.3.4
The same seems to apply to the other patches you've sent yesterday :-(
I'm eagerly waiting for summary patch ;-)
Regards,
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2-Summary support for u-boot
Joakim Tjernlund transmode.se> writes: > Can't remember, possibly it was a hack. > Seems so. I tried to put it in my 1.3.3, but 'ls' never returns :-( So I will wait for Detlev Zundel. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2-Summary support for u-boot
Detlev Zundel schrieb: >> Has anybody tried to (and succeeded in) speed up u-boot? > > We are currently working on such a speedup bringing U-Boot up to par > with Linux. I am confident that we can post our results in the next > week. > Sounds promising! > PS: Wow, message-mode in Emacs wants a confirmation sending an email to > you as your address looks bogus ;) > Address is valid and in use. This nospam_ kept away spam for some time. Seems some filters sorted it out, others removed it. Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2-Summary support for u-boot
Joakim Tjernlund transmode.se> writes: > > Has anybody tried to (and succeeded in) speed up u-boot? > > Yes, there was an attempt some time ago(months or a year, dunno) where > someone had improved scanning dramatically, patch was posted to the > u-boot list. Can't remember who though. Seems to be the thread 'jffs2 fsload - SOLVED.' from 12 Jan 03:14 Dan Merillat. As I've looke into the patch, it seems not to have found its way into u-boot. Any(body any) idea why? Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2-Summary support for u-boot
Joakim Tjernlund transmode.se> writes: > > On Mon, 2008-09-29 at 08:45 +, Michael Lawnick wrote: > > Hi *, > > > > please feel free to correct me if I tell sh**: > > As far as I was told, bad JFFS2 boot performance of u-boot is result of not > > supporting summary. (Because there is no JFFS2 but only JFFS support?) > > It is not missing SUMMARY, it is excessive scanning of empty flash > blocks. Look at jffs2/scan.c, it only scan the first 4KB or before > declaring the block empty. Ok, did I get you correct: The performance difference between u-boot and linux is based on skipping senseless scans of empty blocks? I've taken a little look into scan.c The comment "The code lacks more or less any comment, and is still arcane and difficult to read in places." doesn't make me happy. Has anybody tried to (and succeeded in) speed up u-boot? Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] JFFS2-Summary support for u-boot
Hi *, please feel free to correct me if I tell sh**: As far as I was told, bad JFFS2 boot performance of u-boot is result of not supporting summary. (Because there is no JFFS2 but only JFFS support?) So my question: Has anybody done or is planning in next time (~weeks) to add summary support for u-boot JFFS2? We need a file system on 32MB NOR flash with wear leveling and acceptable boot time. Ubi is currently not supported for NOR, JFFS2 slow, ... :-( TIA Kind Regards, M.Lawnick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add MTD core & partition
Stefan Roese denx.de> writes: > > On Friday 19 September 2008, Michael Lawnick wrote: > > > BTW: Which NOR FLASH driver are you using? The common CFI driver? It has > > > no real connection to the MTD layer which is needed for the UBI port from > > > Kyungmin. Did you think about this? > > > > We are using CFI driver for AM29GL512. > > As said we are _planning_ to integrate, i.e. I'm currently gathering > > information. We need r/o access from u-boot to find our kernel and boot it. > > Writing to flash could be done from Linux. > > Understood. > > > What are the problems to face? > > As I mentioned the CFI driver is missing the interface to the MTD layer. This > is available for NAND and OneNAND but missing for NOR in the U-Boot CFI > implementation. It really is not needed right now and such an extension has > to be made carefully since it adds new code which increases the image size of > all boards using this driver. The only option (I can think of) to not > increase the image size for those boards would be to add this MTD connection > via #ifdef's. But this will not help to make the code more readable. > Hmm, seems I've got some problems to understand. If there is a clearly defined API (which I haven't found yet) it should be independent from H/W (NAND/NOR/SRAM/...) IMHO. If not, UBI will be NAND-only :-( Could you give me a kick into the right direction, so I will find e.g. a .h file where the functions are listed that have to be supported by H/W-layer driver? #ifdef's could be avoided by using a different sort of driver for the same H/W, e.g. cfi_flash and cfi_ubi_flash. Kind regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add MTD core & partition
Stefan Roese denx.de> writes: > > On Friday 19 September 2008, Michael Lawnick wrote: > > how far have you got? > > We are planning to integrate UBI in u-boot too (NOR flashes), so if all is > > already done - or will be in next time - we could spare some hours ... > > We also have a project to integrate UBI support into U-Boot. The real UBI > work > will start in 2-3 weeks. We really should coordinate our work on this. > > BTW: Which NOR FLASH driver are you using? The common CFI driver? It has no > real connection to the MTD layer which is needed for the UBI port from > Kyungmin. Did you think about this? > We are using CFI driver for AM29GL512. As said we are _planning_ to integrate, i.e. I'm currently gathering information. We need r/o access from u-boot to find our kernel and boot it. Writing to flash could be done from Linux. What are the problems to face? Kind Regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add MTD core & partition
Kyungmin Park infradead.org> writes: > > It's preparation for UBI codes. > UBI uses partition and get & put mtd devices > ... Hi, how far have you got? We are planning to integrate UBI in u-boot too (NOR flashes), so if all is already done - or will be in next time - we could spare some hours ... Kind Regards, Michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
