On Wed, 2014-12-17 at 23:28 +0800, Chen Baozi wrote: > > On Dec 17, 2014, at 23:04, Ian Campbell <i...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org