On 11 September 2013 02:00, Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
> This fix looks correct but as indicated by us not having discovered this
> bug earlier, this is a very unusual case and it's difficult to ensure
> that similar bug doesn't pop up in another place or that we don't suffer
> a
>for (*r = grub_mm_base; *r; *r = (*r)->next)
> -if ((grub_addr_t) ptr > (grub_addr_t) ((*r) + 1)
> - && (grub_addr_t) ptr <= (grub_addr_t) ((*r) + 1) + (*r)->size)
> - break;
> +{
> + grub_addr_t region_start = (grub_addr_t) ((*r) + 1);
> + grub_addr_t region_end
On 10 September 2013 23:36, Leif Lindholm wrote:
> On 10 September 2013 22:46, Seth Goldberg wrote:
>> Why would region_end be zero? That sounds like an invalid value.
>
> Because when a heap region sits at the top of RAM, region base +
> region size == 0.
(On that specific platform. In gener
On 10 September 2013 22:46, Seth Goldberg wrote:
> Why would region_end be zero? That sounds like an invalid value.
Because when a heap region sits at the top of RAM, region base +
region size == 0.
/
Leif
___
Grub-devel mailing list
Grub-devel
Quoting Leif Lindholm, who wrote the following on Tue, 10 Sep 2013:
On Thu, Aug 29, 2013 at 07:26:03PM +0200, Leif Lindholm wrote:
When allocating memory for the heap on ARMv7 UEFI, the init code
pretty much just allocates a chunk from the top of available RAM.
This means that when grub_mm_in
The current version of ARM cache maintenance code contains a few bugs,
preventing GRUB from running properly on my hardware platforms.
Main issues are that clean_dcache_range/invalidate_icache_range use the
addresses of grub_arch_cache_dlinesz/grub_arch_cache_ilinesz rather
than the values read in
On Thu, Aug 29, 2013 at 07:26:03PM +0200, Leif Lindholm wrote:
> When allocating memory for the heap on ARMv7 UEFI, the init code
> pretty much just allocates a chunk from the top of available RAM.
>
> This means that when grub_mm_init_region is called for a region
> extending to the top of the 32
