APPLIED: UBUNTU: [Config] Armada 37x/38x/XP based boards support (e.g. Globalscale Mirabox)

[Tim Gardner]

On 07/15/2014 04:56 AM, Paolo Pisati wrote:
> The following changes since commit c09c285702ee331f49f7a3be20e4dc280bb83350:
> 
>   UBUNTU: [Config] armhf: generic: CC_OPTIMIZE_FOR_SIZE=y (2014-07-14 15:59:18 +0100)
> 
> are available in the git repository at:
> 
>   git://kernel.ubuntu.com/ppisati/ubuntu-utopic.git master-next-mirabox
> 
> for you to fetch changes up to c09c285702ee331f49f7a3be20e4dc280bb83350:
> 
>   UBUNTU: [Config] armhf: generic: CC_OPTIMIZE_FOR_SIZE=y (2014-07-14 15:59:18 +0100)
> 
> ----------------------------------------------------------------
> 
> This patch set enable support for boards based on the Marvell Armada 37x/38x
> and XP SOCs (e.g. Globalscale Mirabox):
> 
> patch 01 - 18 are config changes to enable all the feature of these SOCs
> 
> patch 19 build DTBs for every board supported upstream
> 
> patch 20 is a fix for the MVEBU PCI driver (already queued for 3.16rc6)
> 
> patch 21 enables the serial controller present on the Globalscale Mirabox
> 
> patch 22 is a workaround for the buggy Mirabox's bootloader that crashes
> when loading a kernel bigger than 6MB (it seems it's triggered around
> 5.9MB actually)
> 
> To enable the Mirabox we either:
> 
> a) "fix" the bootloader: unfortunately, Globalscale uses a modified
> version of u-boot and there's no support for this board upstream - i
> already made the company aware of this bug but i didn't get any answer
> so far
> 
> b) accept to compile generic armhf with Os (patch 22) - unlikely but
> it shrink kernel size to ~5.5MB
> 
> c) put the generic kernel on diet (if we ever find something that we can
> turn off or compile it as a module)
> 

We must have _some_ core components built-in that are of little use on
armhf. I'd consider turning them off in order to save some RAM on these
small footprint systems. Also, I'd love to be able to use my Mirabox
with a stock kernel.

I wonder if you could chain from the 1.1 u-boot loader to a newer u-boot
that could actually load a large kernel ? The alternative is to post a
u-boot repository with the size corrections, but that requires a
somewhat harrowing u-boot upgrade (plus its a giant pain in the ass to
build). If you botch the upgrade then you own a brick.

rtg
-- 
Tim Gardner tim.gardner at canonical.com