On Sat, Jul 18, 2020 at 2:24 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Sat, Jul 18, 2020 at 3:05 AM Atish Patra <atishp@xxxxxxxxxxxxxx> wrote: > > On Thu, Jul 16, 2020 at 11:32 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > On Fri, Jul 17, 2020 at 1:41 AM Atish Patra <atish.patra@xxxxxxx> wrote: > > > > +#define DTB_EARLY_SIZE SZ_1M > > > > +static char early_dtb[DTB_EARLY_SIZE] __initdata; > > > > > > Hardcoding the size in .bss seems slightly problematic both for > > > small and for big systems. On machines with very little memory, > > > this can lead to running out of free pages before .initdata gets freed, > > > and it increases the size of the uncompressed vmlinux file by quite > > > a bit. > > > > > > On some systems, the 1MB limit may get too small. While most dtbs > > > would fall into the range between 10KB and 100KB, it can also be > > > much larger than that, e.g. when there are DT properties that include > > > blobs like device firmware that gets loaded into hardware by a kernel > > > driver. > > > > > I was not aware that we can do such things. Is there a current example of that ? > > I worked on a product in the distant past where the host firmware > included the ethernet controller firmware as a DT property[1] to get around > restrictions on redistributing the blob in the linux-firmware package. > > For the .dts files we distribute with the kernel, that would not make > sense, and I don't know of any current machines that do this in their > system firmware. > > > > Is there anything stopping you from parsing the FDT in its original > > > location without the extra copy before it gets unflattened? > > > > That's what the original code was doing. A fixmap entry was added to > > map the original fdt > > location to a virtual so that parse_dtb can be operated on a virtual > > address. But we can't map > > both FDT & early ioremap within a single PMD region( 2MB ). That's why > > we removed the DT > > mapping from the fixmap to .bss section. The other alternate option is > > to increase the fixmap space to 4MB which seems more fragile. > > Could the original location just be part of the regular linear mapping of all > RAM? No. Because we don't map the entire RAM until setup_vm_final(). We need to parse DT before setup_vm_final() to get the memblocks and reserved memory regions. I'm not too familiar with the early mapping code myself, so it may not > be possible, but that would be the most logical place where I'd put it. > > Arnd > > [1] drivers/net/ethernet/toshiba/spider_net.c -- Regards, Atish
