Porting to a new unsupported board: uboot fails to properly read the partition table

[Andrea Bernabei]

On Tue, Dec 15, 2015 at 3:47 PM, Andrea Bernabei <
andrea.bernabei at canonical.com> wrote:

>
>
> On Tue, Dec 15, 2015 at 3:37 PM, Woodrow Shen <woodrow.shen at canonical.com>
> wrote:
>
>> Hi,
>>
>> I wonder which board did you win to get ? :) Also, Is your board able to
>> boot into Snappy successfully ?
>> If yes, I think the partitions of image should be fine to work well.
>>
>> Before flashing image to SD card, you also can use `fdisk -lu
>> /path/to/image` to check all the partitions.
>> In my experiences of Snappy porting, I met a problem to break up the
>> partitions generated by u-d-f,
>> and I diff the hex between BSP image and Snappy. I found that u-d-f
>> overwrote wrong the partition table
>> due to bigger size of preloader binary, so I made the binary divide into
>> two parts. Furthermore, The offsets
>> also needed to be described in package.yaml in the OEM snap.
>>
>> The another interesting thing is that I need to make boot flag of 1st
>> partition turn off, and then the board
>> can boot to Snappy normally. XD
>>
>> This is my reflection, hope it can help you :)
>>
>>
> Hi Woodrow,
> thanks for getting back to me :)
>
> I haven't had the time to write a post about it, though I managed to get
> Snappy to boot successfully on my board
> just a couple of days after my help request here :)
> (for the record: the issue I reported here was due to a very dumb mistake
> on my side: I was flashing on sdb1 instead of sdb, so it wasn't
> actually overwriting the partition table that was already available on the
> SD)
>
> I have to say it has been quite easy, I was expecting porting to a new
> board would have been much more difficult :)
> I only had to patch and tweak u-boot, basically (and apply the apparmor
> patches to the kernel, but that's almost automatic) :)
>
>
I forgot the step where I defined the OEM package and the flashing offsets
etc, but I think that was it :)


> I should definitely post the modified bits so that others with the same
> board can get Snappy, but
> time is never enough :) It's on my TODO
>
> PS: the board is a Toradex Iris + Colibr iMX6DL module
>
> Cheers,
> Andrea
>
>
>
>> Cheers,
>>
>> Woodrow
>>
>> On Fri, Nov 20, 2015 at 1:15 AM, Andrea Bernabei <
>> andrea.bernabei at canonical.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I recently won a dev board at a conference, and I'm trying to port
>>> Snappy to it as a spare time pet project (yeah, this is the kind of things
>>> I am into :D)
>>>
>>> I read the porting guide
>>> https://developer.ubuntu.com/en/snappy/guides/porting/
>>>
>>> and Ogra's post at
>>>
>>> https://ograblog.wordpress.com/2015/01/25/porting-ubuntu-snappy-to-a-yet-unsupported-armhf-board/
>>>
>>> I have already patched the kernel with the required apparmor patches and
>>> also uboot to add ext4 commands, and I successfully installed them on the
>>> board.
>>>
>>> The problem I have at the moment is that the partition tablet of the
>>> image created by ubuntu-device-flash (using my custom device tarball as
>>> input) does not seem to be properly supported by uboot (and even some tools
>>> like gparted).
>>>
>>> Here's what a few tools report when listing the partitions on the
>>> *sdcard*
>>> (I tried both with a 32Gb and a 4Gb sdcard)
>>> - uboot's "mmc part" reports just 1 partition, type 0c
>>> - gparted only shows 1 big partition, like uboot, with unknown
>>> filesystem and lba flag
>>> - parted shows 4 partitions
>>> - kpartx shows 4 partitions
>>>
>>> Any advice?
>>>
>>> Andrea
>>>
>>> --
>>> snappy-devel mailing list
>>> snappy-devel at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>>>
>>>
>>
>>
>> --
>> snappy-devel mailing list
>> snappy-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151215/b64ef3e7/attachment-0001.html>