> 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? Sure. > 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. Cheers, Baozi
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail