Hi Florian, Does this problem only occur in version 9.0.0? Or is it happening to the current master as well?
Are you following this tutorial: https://www.youtube.com/watch?v=oL6KAgkTb8M Also you can increase the debug level (include warn and info). BR, Alan On 5/16/20, Florian Wehmeyer <flo...@gmx.net> wrote: > Hi Alan, > updated it again to 9.0.0 and also good! > However, got a new problem now which I've not figured out yet: > The binary loader does not load the elf if the program is a built-in > app... very strange.. > It does not even try to load the elf file from file-system, it directly > goes to the built-in app.. > Funnily, it does try to load the nsh embedded tools: > exec_spawn: ERROR: Failed to load program 'ls': > -2 > exec_spawn: ERROR: Failed to load program 'dmesg': -2 > If I do not compile the app as a built-in app, the binary loader will > load it: > load_absmodule: Loading > /mnt/ramdisk/Neo_Ledtest > elf_loadbinary: Loading file: > /mnt/ramdisk/Neo_Ledtest > elf_init: filename: /mnt/ramdisk/Neo_Ledtest loadinfo: 0x2000a4cc > Which shows that the CONFIG_BINFMT_EXEPATH=y and CONFIG_PATH_INITIAL ar > e correctly set, and the elf file is also working correctly.. > I never had this situation before... > BR, > Florian > > -- > Florian Wehmeyer > TFW Tech-Solutions > On Sáb, 2020-05-16 at 16:08 -0300, Alan Carvalho de Assis wrote: >> Hi Florian, >> >> Nice to know you got if fixed. >> >> It should be nice if you can test it again using the nuttx-9.0.0 >> release. >> >> BR, >> >> Alan >> >> On 5/16/20, Florian Wehmeyer <flo...@gmx.net> wrote: >> > >> > Hi all, >> > just to let you know, the heap problem was solved after pulling the >> > latest commit from master.. >> > Now I can use very much of it, also I was able to use a lot more >> > features in the config, as cmd line history etc... >> > So, the available memory of 256K was not the problem, @Greg. >> > @Nathan: now malloc returns NULL if out of heap.. >> > Sorry for that, guys, normally someone should make sure to have the >> > latest version, not a version from 4 weeks ago as I. >> > What happens is, as there is a lot of changes going on constantly, >> > sometimes I hesitate to make frequent pushes, because it can mess >> > up my >> > processes. (for example if someone changes the nuttx folder >> > structure >> > or similar) >> > Very good that now there are release branches, I hope the release >> > branch will suffer only bug-fixes as changes.. >> > Thanks again, >> > >> > -- >> > Florian Wehmeyer >> > TFW Tech-Solutions >> > On Seg, 2020-05-11 at 18:43 -0300, Florian Wehmeyer wrote: >> > > >> > > OK Greg, >> > > could be that I was using too much.. using 64KB of ramdisk also.. >> > > I >> > > disabled some of the comfortable features like cmd line history >> > > etc, >> > > and was already able to alloc quite a bit more than before.. >> > > Will further improve the sram usage.. >> > > Also, I missed the commit >> > > mm/mm_heap: fix mm_heap not support BUILD_FLAT >> > > >> > > >> > > >> > > GUIDINGLI >> > > >> > > >> > > authored and patacongo >> > > >> > > committed >> > > on Apr 10 >> > > >> > > >> > > >> > > which well might impact my stuff here, will pull and let you >> > > know, >> > > @Nathan I will also make tests if malloc continues returning non >> > > NULL >> > > pointers even if out of memory.. >> > > >> > > Seems on a good way!! >> > > >> > > Many thanks, >> > > Florian >> > > >> > > >> > > >> > > -- >> > > Florian Wehmeyer >> > > TFW Tech-Solutions >> > > On Seg, 2020-05-11 at 15:09 -0600, Gregory Nutt wrote: >> > > > >> > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > No custom board, it's the tm4c1294-launchpad. >> > > > > > Seems no general problem with heap allocation, so I guess >> > > > > > it's >> > > > > > not in >> > > > > > the linker script, it's rather directly linked to the usage >> > > > > > of >> > > > > > the elf- >> > > > > > binary loader, and there are only two configs in the nuttx >> > > > > > repo >> > > > > > which >> > > > > > use the CONFIG_ELF stuff. >> > > > > That part has 256Kb of SRAM. That is more that many, but it >> > > > > could >> > > > > be >> > > > > that you are using too much SRAM and just cannot run ELF >> > > > > reliably. >> > > > > It >> > > > > does want a lot of SRAM. >> > > > Most of the other boards that use CONFIG_ELF=y in a >> > > > configuration >> > > > have a >> > > > much larger internal ram (exceptions in red): >> > > > >> > > > $ find . -name defconfig | xargs grep -l CONFIG_ELF=y | xargs >> > > > grep >> > > > RAM_SIZE >> > > > ./arm/cxd56xx/spresense/configs/elf/defconfig:CONFIG_RAM_SIZE=1 >> > > > 5728 >> > > > 64 >> > > > ./arm/cxd56xx/spresense/configs/module/defconfig:CONFIG_RAM_SIZ >> > > > E=15 >> > > > 72 >> > > > 864 >> > > > ./arm/cxd56xx/spresense/configs/posix_spawn/defconfig:CONFIG_RA >> > > > M_SI >> > > > ZE >> > > > =1572864 >> > > > ./arm/cxd56xx/spresense/configs/rndis/defconfig:CONFIG_RAM_SIZE >> > > > =157 >> > > > 28 >> > > > 64 >> > > > ./arm/cxd56xx/spresense/configs/wifi/defconfig:CONFIG_RAM_SIZE= >> > > > 1572 >> > > > 86 >> > > > 4 >> > > > ./arm/lc823450/lc823450- >> > > > xgevk/configs/elf/defconfig:CONFIG_RAM_SIZE=1044480 >> > > > ./arm/lc823450/lc823450- >> > > > xgevk/configs/krndis/defconfig:CONFIG_RAM_SIZE=1044480 >> > > > ./arm/lc823450/lc823450- >> > > > xgevk/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=1044480 >> > > > ./arm/lc823450/lc823450- >> > > > xgevk/configs/rndis/defconfig:CONFIG_RAM_SIZE=1044480 >> > > > ./arm/lc823450/lc823450- >> > > > xgevk/configs/usb/defconfig:CONFIG_RAM_SIZE=1044480 >> > > > ./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_RAM_SIZE >> > > > =655 >> > > > 36 >> > > > ./arm/sama5/sama5d4- >> > > > ek/configs/elf/defconfig:CONFIG_RAM_SIZE=268435456 >> > > > ./arm/sama5/sama5d4- >> > > > ek/configs/knsh/defconfig:CONFIG_RAM_SIZE=268435456 >> > > > ./arm/stm32/olimex-stm32- >> > > > p407/configs/kelf/defconfig:CONFIG_RAM_SIZE=114688 >> > > > ./arm/stm32/stm32f4discovery/configs/elf/defconfig:CONFIG_RAM_S >> > > > IZE= >> > > > 11 >> > > > 4688 >> > > > ./arm/stm32/stm32f4discovery/configs/posix_spawn/defconfig:CONF >> > > > IG_R >> > > > AM >> > > > _SIZE=114688 >> > > > ./arm/stm32/stm32f4discovery/configs/rndis/defconfig:CONFIG_RAM >> > > > _SIZ >> > > > E= >> > > > 114688 >> > > > ./arm/tms570/tms570ls31x-usb- >> > > > kit/configs/nsh/defconfig:CONFIG_RAM_SIZE=262143 >> > > > ./risc-v/k210/maix- >> > > > bit/configs/elf/defconfig:CONFIG_RAM_SIZE=2097152 >> > > > ./risc-v/k210/maix- >> > > > bit/configs/module/defconfig:CONFIG_RAM_SIZE=2097152 >> > > > ./risc-v/k210/maix- >> > > > bit/configs/posix_spawn/defconfig:CONFIG_RAM_SIZE=2097152 >> > > > >> > > > And one of these exceptions has a large external DRAM: >> > > > >> > > > $ find . -name defconfig | xargs grep -l CONFIG_ELF=y | xargs >> > > > grep >> > > > EXTDRAM >> > > > ./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_LPC17_40 >> > > > _EXT >> > > > DR >> > > > AM=y >> > > > ./arm/lpc17xx_40xx/lx_cpu/configs/nsh/defconfig:CONFIG_LPC17_40 >> > > > _EXT >> > > > DR >> > > > AMSIZE=33554432 >> > > > >> > > > >
