On Tue, 2016-04-12 at 20:35 -0700, Andrey Smirnov wrote: > > In order to get an image file out of flash and programmed into the FPGA, > > it's useful to have a number of barebox drivers, like the MCI system, > > partition table parsing, FAT filesystem, etc. Basically getting the > > full barebox (with a minimal set of drivers, e.g. no shell) running > > without having SDRAM access. > > > > So can one run barebox in 256 Kb? > > I was able to do it, although in a different, but IMHO comparable > configuration. My use-case was running bare minimum Barebox _with_ the > shell and UART driver, sans everything else out of IRAM (256kB) on > i.MX6Q (the users wanted to be able to tweak DDR controller's > configuration at runtime via BB console interface). If memory serves > me well after system booted I had about 50kB or RAM to spare(although > I don't know what the peak usage was during boot process) I've done some trials now by booting a small barebox configured for 256kB from a real barebox. I could get a shell-less non-relocatable non-pbl barebox to work, with mci, fat, partition, uart, i2c, eeprom drivers. But with the simple shell I run out of heap space (116Kb of heap) as the shell runs init scripts. Found a few issues when trying to optimize barebox: PBL without relocation doesn't work because the PBL and main barebox try to link at the same TEXT_BASE value. One can't specify a TEXT_BASE when using relocation. barebox always links at 0, even if you know it will usually be loaded at a certain address. socfpga relocates the PBL twice. The board entry function does it and then the code in start.c does it again. > > A minimal config of a non-PBL non-relocatable barebox with the necessary > > features is only about 54 Kb. So that certainly fits. But that doesn't > > include stack, heap, bss, etc. Can a stripped down barebox actually run > > in 256 Kb and mount a FAT filesystem to get a next stage bootloader? > > The image I was building was indeed a non-PBL non-relocatable variant, > however I had to do three further modifications: > > - Disable MMU, becuase just the page table alone in my case would take > about 1MB or space Thanks for the hint, I needed to do this too. Even mapping just 1MB takes a significant amount of space. Also the MMU code appears to crash if one tells it to map less than 1MB. > In case of non-relocatable image device-tree blob should already be > preloaded into memory as a part of Barebox binary upload, so there is > no need to 'memcpy' it again Why does the dtb ever need to be copied? It looks to me like a relocatable barebox will copy from _text to __bss_start to the relocation address. The compiled in dtb data will be that range. So in the relocation case, what's the point of the copying it a second time? Seems like the only reason to copy it would be if it was an external dtb image provided to barebox by another bootloader. Is there anything that can do this besides a PBL? _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
