lkml.org 
[lkml]   [2020]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: x86_32: CONFIG_PHYSICAL_START problem
Date
On Sat, Dec 12 2020 at 22:29, Randy Dunlap wrote:
> Little to my knowledge, this came up with
> CONFIG_PHYSICAL_START=0x81000000
...
> I tracked it down to this large value of CONFIG_PHYSICAL_START
> and changed it back to its default value, then the kernel
> built with no problems.
>
> So far I haven't been able to track the chain of values/changes
> that involve PHYSICAL_START, __PAGE_OFFSET, LOAD_OFFSET, etc.

It's convoluted :)

> Anyway, I would like to see PHYSICAL_START limited to some
> acceptable range of values in arch/x86/Kconfig,

Its the combination of CONFIG_PHYSICAL_START and CONFIG_PAGE_OFFSET so
having checks in Kconfig is going to be a challenge.

> or at a minimum, a little bit better error message coming
> from arch/x86/kernel/vmlinux.lds.S:
>
> . = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
> "kernel image bigger than KERNEL_IMAGE_SIZE");
>
> so maybe:
>
> . = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
> "kernel image bigger than KERNEL_IMAGE_SIZE or load address is too large");
> (or start address)

Some reasonable error message is definitely due, but we probably can
catch that at the compile stage already once we computed the combined
values. Then we can sanity check those for resonable ranges.

Thanks,

tglx

\
 
 \ /
  Last update: 2020-12-16 16:59    [W:0.031 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site