Bug#773255: Add TI OMAP5 uEVM board support db

[Ian Campbell <ijc@debian.org>]

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?

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

> >      * 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.

Ian.