Comment 10 for bug 746473

Revision history for this message
Guilherme Salgado (salgado) wrote : Re: [Bug 746473] Re: Need support for Snowball board

This feels very weird to me as the media we're writing to does not vary
according to the board -- it varies according to a command line switch.
For that reason I think it doesn't make sense to have it as a
BoardConfig attribute.

Also, we have plans of dropping the ability to create images on block
devices (bug 744449), so media.is_block_device and all the code specific
to block devices is going away soon.

It seems to me like the best alternative here is to have two separate
BoardConfigs for snowball as Loïc suggested
(http://<email address hidden>/msg03974.html)

On Mon, 2011-05-09 at 08:39 +0000, Hans Odeberg wrote:
[...]
> Then I have also started looking at getting
> linaro-android-media-create to work for Snowball, and have not gotten
> further than a couple of questions:
> 1) In partitions.py/get_android_partitions_for_media(), there is an
> assert for media.is_block_device. But Snowball really needs to build
> for raw images; the board cannot boot from SD card. Will this
> limitation go away in the future?

I think that assert is there only because when l-a-m-c was written it
didn't make much sense to generate image files for android. If now it
does, we can just remove the assert and make sure l-a-m-c knows how to
generate image files. We'll probably have to do that anyway as part of
the work to fix the bug I mentioned above.

> 2) android_boards.py/AndroidBoardConfig::get_sfdisk_cmd() defines the
> following partitions (assuming I got sfdisk right):
> boot partition, FAT (same as before)
> system partition, Linux
> cache partition, Linux
> an extended partition
> userdata partition, Linux
> sdcard partition
> If I am to add a loader partition, as I did in SnowballConfig, I then
> run into the minor problem that the partition table is full. So the
> question, at long last, is: Can you rearrange the default partition
> table to move more things to the extended partition, leaving a free
> entry, or is that my job when I define an
> AndroidSnowballlConfig::get_sfdisk_cmd()?

I think it doesn't make sense to always leave free space at the
beginning of the disk for just one or two boards that might need a
loader partition. It is common for board configs to override the
standard get_sfdisk_cmd(), and that's probably what we should do here.