Re: [PATCH ARM v6 00/14] mini-os: initial ARM support

[Julien Grall <julien.grall@linaro.org>]

Hi Thomas,

On 16/07/14 12:07, Thomas Leonard wrote:
> This series is based on Karim's ARM support commits, further broken up into
> smaller patches.
>
> The comments from last time should be addressed now, plus a few other things:
>
> - The series is rebased on staging, dropping patches that have already been
>    applied.
>
> - The changes have been further split into smaller patches to ease reviewing.
>    Note that the build system isn't changed to allow building the new code until
>    patch 13.
>
> - Define BUG to cause an undefined instruction fault. This lets us us dump the
>    registers.
>
> - Renamed stack to _boot_stack for clarity.
>
> - Include kernel.h from arm/os.h. This is for consistency with x86/os.h
>    and is needed to compile with lwIP.
>
> - Moved SVC stack to first 16KB of RAM (provides some protection against
>    stack overlow corrupting memory).
>
> - Put translation table in second 16KB (simplifies boot code).
>
> - Moved shared_info_page and irqstack to .bss section (smaller image).
>
> - Moved __bss_start and _edata inside section in linker script.
>    The linker adds non-listed sections, such as .got, just before .bss.
>    This meant that we accidentally zeroed those out too.
>
> - Enable floating point unit.
>
> - Require only minimum FDT property lengths (requested by Ian Campbell).
>
> Addressed Julien Grall's comments:
>
> - Get hypercall numbers from xen.h.
> - Avoid duplicating the definition of _start's virtual address.
> - Moved definition of physical_address_offset from asm to C.
> - Added paddr_t type to represent physical addresses.
> - Added comments explaining the lengths when checking FDT properties.
> - Fixed (commented) DEBUG macro.
> - Drop check for arm,cortex-a9-gic.
>
> There are two assumptions the code makes that may need changing in the future, but
> which hopefully don't need to hold up this initial support:
>
> - The assumption that the kernel will be loaded at start of RAM + 0x8000.
>
> - The assumption that Xen will mark the GIC address range as device memory.
>    This should probably be fixed when the C code gains the ability to control
>    the translation tables, map 4K pages, etc.

I'm fine with the assumptions for an initial support. Did you write-down 
somewhere those restrictions? So if an issue happen in the future, we 
will be able to find quickly the issue.

Regards,

-- 
Julien Grall