[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#773255: Add TI OMAP5 uEVM board support db

> On Dec 19, 2014, at 02:03, Ian Campbell <ijc@debian.org> wrote:
> On Wed, 2014-12-17 at 23:28 +0800, Chen Baozi wrote:
>>> On Dec 17, 2014, at 23:04, Ian Campbell <ijc@debian.org> wrote:
>>> On Wed, 2014-12-03 at 12:18 +0800, Chen Baozi wrote:
>>>> Package: flash-kernel
>>>> Version: 3.28
>>>> Severity: wishlist
>>>> Tags: patch
>>>> With the patch attached, TI OMAP5 uEVM board is supported.
>>> Thanks.
>>>> +Machine: TI OMAP5 uEVM board
>>>> +Method: generic
>>>> +U-Boot-Kernel-Address: 0x80008000
>>>> +U-Boot-Initrd-Address: 0x0
>>>> +U-Boot-Script-Address: 0x0
>>>> +U-Boot-Script-Name: bootscr.omap
>>>> +Boot-Device: /dev/mmcblk1p1
>>>> +Boot-Kernel-Path: uImage
>>>> +Boot-Initrd-Path: uInitrd
>>>> +Boot-Script-Path: boot.scr
>>>> +Required-Packages: u-boot-tools
>>> A few questions about u-boot on this platform:
>>>     * Does it support the bootz command?
>> The default one shipped with the board, which I got last year, seems not.
>> But I’m now using the latest upstream u-boot, which does support ‘bootz’.
> Is updating u-boot on this platform safe? As in can you brick the system
> or is it always recoverable?

Yes. Since the u-boot image (MLO & u-boot.img) is actually stored on the
external microSD card (in the 1st partition that formatted as vfat), it
is very easy to upgrade or downgrade the u-boot.

> Does it have an easily accessible serial console (i.e. no soldering or
> magic hard to get cables required)?

Of course, it is a development board. The board provides a micro-usb serial
debug port.

>>>     * Does it support loading from "sensible" (i.e. other than FAT and
>>>       raw partitions) filesystems? (possibly via the generic load
>>>       command)?
>> My current upstream u-boot does support.
> Good.
>>>     * Is /dev/mmcblk1p1 normally mounted (perhaps on /boot) or is it a
>>>       dedicated boot partition which is not normally mounted?
>> This is the partition when people use the external Micro-SD card as the
>> rootfs on the board. I configured my system (debian) to mount it
>> automatically. When I was using the old kernel last year, this partition
>> is recognised as /dev/mmcblk0p1. With more platform driver available,
>> the /dev/mmcblk0p1 is now considered to be the on-board nand flash,
>> which I never used. However, with the sata driver support now, one
>> should be able to attach a normal sata hard disk and boot the system
>> from it. But I haven’t tried that yet.
> The Boot-Device field is intended for use on systems where the
> bootloader is either dumb or inflexible, i.e. it expects a certain
> partition to contain a FAT filesystem with a particular set of files
> (referred to via Boot-*-Path) on it, probably with mkimage headers on
> them.
> That partition would not normally be mounted during normal operation but
> is mounted on demand by flash-kernel to update the files. It is not
> expected that Boot-Device points to the partition mounted on /boot or
> anything like that (not normally at least).
> For more capable systems where the bootloader supports loading from a
> regular Linux fs, supports boot scripts and bootz etc we would prefer to
> just use the files in /boot directly, i.e. no need for Boot-Device (and
> in many case no need for Boot-*-Path either)
>>> Ultimately what I'm getting at is, can this platform use
>>> bootscr.uboot-generic? I'd like to try and default to that wherever
>>> possible for new platforms. (bootscr.omap predates all of the above
>>> facilities being generally available in u-boot AFAIK).
>> Oh, I haven’t had tried the boot script. I just copy this field from
>> OMAP4 Panda board, which is somehow similar as uEVM.
> Right, they are similar but much older and therefore not as capable,
> also I wouldn't be surprised if the Panda entry had bit rotted and no
> longer works (the lack of a DTB-Id is suspicious...)
> Anyhow, it sounds like bootscr.uboot-generic ought to work for this
> platform, at least with the updated upstream u-boot. Can you give it a
> go?


> I think you would just want:
>        Machine: TI OMAP5 uEVM board
>        Method: generic
>        U-Boot-Script-Name: bootscr.uboot-generic
>        Boot-Script-Path: /boot/boot.scr
>        Required-Packages: u-boot-tools
> Perhaps with DTB-Id as discussed below.
>>> On a separate note, there is no DTB-Id field. Does this mean that the
>>> platform comes with a DTB in the firmware?
>> No. The DTB is on the /boot too. I miss it because OMAP4 doesn’t
>> include this field. I guess you mentioned it because it is useful
>> for flash-kernel to generate the right bootscr.*?
> If you specify DTB-Id then flash-kernel will copy that file from the
> kernel package to /boot/dtb-`uname -r` (and to Boot-DTB-Path if you
> specify it) where it can be picked up by the boot.scr.
> If your platform supplies an FDT from somewhere else then you likely
> don't want this, but not many platforms do that so chances are that you
> do.

In this case, I think DTB-Id should be included, for the dtb I used now
is directly built from upstream kernel tree.

I’ll test the new description file and resend the new patch.



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply to: