Am 9. Januar 2021 22:23:01 MEZ schrieb Tom Rini <tr...@konsulko.com>: >On Sat, Jan 09, 2021 at 08:59:01PM +0100, Heinrich Schuchardt wrote: >> Am 9. Januar 2021 20:40:04 MEZ schrieb Tom Rini <tr...@konsulko.com>: >> >On Sat, Jan 09, 2021 at 08:33:40PM +0100, Heinrich Schuchardt wrote: >> >> On 1/9/21 7:58 PM, Tom Rini wrote: >> >> > On Sat, Jan 09, 2021 at 08:47:07PM +0200, Andy Shevchenko wrote: >> >> > > On Sat, Jan 9, 2021 at 8:06 PM Heinrich Schuchardt >> ><xypron.g...@gmx.de> wrote: >> >> > > > >> >> > > > The comment for initrd_high in the coding and in README were >> >contradicting >> >> > > > and neither fully described what the coding does. >> >> > > > >> >> > > > Clarify the usage of the special value ~0UL for the >environment >> >variable >> >> > > > initrd_high. >> >> > > >> >> > > All those F:s are hard to read in the comments and >documentation >> >and >> >> > > typo prone. I would prefer to rephrase like "all 1:s value in >32- >> >or >> >> > > 64-bit format" or alike.
Who would understand that? All 1s that is 111111111? We need something a non-developer will grasp. Copying the exact value from the readme is the easiest thing to do and the least typo prone. Best regards Heinrich >> >> > >> >> > If we're going to improve this we should also note it's >discouraged >> >> > unless you know for certain there will be no overlap and it's >> >strongly >> >> > discouraged in default environments. >> >> >> >> What exactly is discouraged? >> >> >> >> * setting initrd_high to a value != ~0? Here I would agree. >> >> * setting intird_high to ~0? Why should we copy initrd to a >> >> different place? Is it for some outdated Linux release? >> > >> >We should always default to allowing the initrd to be relocated >because >> >we can see (in many cases) overlap that will lead to failure to boot >> >but >> >this forces us to ignore that. Having good default load values >means >> >we >> >don't have a problem here. >> >> We have an initrd that is already in memory. What could it overlap >> with that is not already overwritten? > >Having the kernel and initrd too close in memory has the kernel BSS >overwrite the initrd. This has happened time and time again before >I went around making some platforms have reasonable (ie kernel early, >ramdisk in lowmem but beyond where a kernel+bss can be, etc) defaults >and pushing others to do the same. > >> Can you provide the text you want to see here? > >Off-hand, it should look more like the big comment block in >include/configs/ti_armv7_common.h and reference the Linux booting on >arm/arm64 documents while noting that other architectures have the same >fundamental issues and their exact limits may or may not be as well >documented.
