Bug#773255: Add TI OMAP5 uEVM board support db
Control: tag -1 +pending
On Sat, 2014-12-20 at 15:39 +0800, Chen Baozi wrote:
On Dec 19, 2014, at 16:15, Ian Campbell i...@debian.org wrote:
On Fri, 2014-12-19 at 13:38 +0800, Chen Baozi wrote:
I’ve only booted the system by ‘bootz’ without initrd. If I load the raw
initrd image (rather than ‘uInitrd”), when I use bootz, it would output:
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
This is the reason that I’m still using bootm when initrd is needed.
bootz requires you to give the filesize for the raw initrd. e.g.
load $kernel_addr_r kernel
load $fdt_addr_r
load $ramdisk_addr_r
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
The :${filesize} is what I mean, it is implicitly set by load (and
similar commands) which is why initrd is loaded last in the above, so it
doesn't get clobbered.
Aha, the CONFIG_SUPPORT_RAW_INITRD is not defined by default when building
u-boot with omap5_uevm_defconfig. That is why I used to fail booting with
‘bootz’.
With the latest u-boot enabling CONFIG_SUPPORT_RAW_INITRD, the following
db description works:
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
DTB-Id: omap5-uevm.dtb
Thanks. I think this platform supports LPAE, so I added Kernel-Flavors:
armmp armmp-lpae, and Method defaults to generic so I omitted it,
resulting in:
Machine: TI OMAP5 uEVM board
Kernel-Flavors: armmp armmp-lpae
DTB-Id: omap5-uevm.dtb
U-Boot-Script-Name: bootscr.uboot-generic
Boot-Script-Path: /boot/boot.scr
Required-Packages: u-boot-tools
I've committed this to flash-kernel.git, and I'll upload around the time
the kernel side is uploaded.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773255: Add TI OMAP5 uEVM board support db
On Fri, 2014-12-19 at 13:38 +0800, Chen Baozi wrote:
I’ve only booted the system by ‘bootz’ without initrd. If I load the raw
initrd image (rather than ‘uInitrd”), when I use bootz, it would output:
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
This is the reason that I’m still using bootm when initrd is needed.
bootz requires you to give the filesize for the raw initrd. e.g.
load $kernel_addr_r kernel
load $fdt_addr_r
load $ramdisk_addr_r
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
The :${filesize} is what I mean, it is implicitly set by load (and
similar commands) which is why initrd is loaded last in the above, so it
doesn't get clobbered.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773255: Add TI OMAP5 uEVM board support db
On Dec 19, 2014, at 16:15, Ian Campbell i...@debian.org wrote:
On Fri, 2014-12-19 at 13:38 +0800, Chen Baozi wrote:
I’ve only booted the system by ‘bootz’ without initrd. If I load the raw
initrd image (rather than ‘uInitrd”), when I use bootz, it would output:
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
This is the reason that I’m still using bootm when initrd is needed.
bootz requires you to give the filesize for the raw initrd. e.g.
load $kernel_addr_r kernel
load $fdt_addr_r
load $ramdisk_addr_r
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
The :${filesize} is what I mean, it is implicitly set by load (and
similar commands) which is why initrd is loaded last in the above, so it
doesn't get clobbered.
Aha, the CONFIG_SUPPORT_RAW_INITRD is not defined by default when building
u-boot with omap5_uevm_defconfig. That is why I used to fail booting with
‘bootz’.
With the latest u-boot enabling CONFIG_SUPPORT_RAW_INITRD, the following
db description works:
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
DTB-Id: omap5-uevm.dtb
Baozi.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Bug#773255: Add TI OMAP5 uEVM board support db
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
Bug#773255: Add TI OMAP5 uEVM board support db
On Dec 19, 2014, at 02:03, Ian Campbell i...@debian.org wrote: 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? 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
Bug#773255: Add TI OMAP5 uEVM board support db
On Dec 19, 2014, at 10:54, Chen Baozi baoz...@gmail.com wrote: On Dec 19, 2014, at 02:03, Ian Campbell i...@debian.org wrote: 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’. I’ve only booted the system by ‘bootz’ without initrd. If I load the raw initrd image (rather than ‘uInitrd”), when I use bootz, it would output: Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid This is the reason that I’m still using bootm when initrd is needed. Baozi signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#773255: Add TI OMAP5 uEVM board support db
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? * Does it support loading from sensible (i.e. other than FAT and raw partitions) filesystems? (possibly via the generic load command)? * Is /dev/mmcblk1p1 normally mounted (perhaps on /boot) or is it a dedicated boot partition which is not normally mounted? 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). On a separate note, there is no DTB-Id field. Does this mean that the platform comes with a DTB in the firmware? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773255: Add TI OMAP5 uEVM board support db
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’. * 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. * 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. 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. 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.*? Cheers, Baozi signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#773255: Add TI OMAP5 uEVM board support db
Package: flash-kernel Version: 3.28 Severity: wishlist Tags: patch With the patch attached, TI OMAP5 uEVM board is supported. diff -Nru flash-kernel-3.28/db/all.db flash-kernel-3.28.1/db/all.db --- flash-kernel-3.28/db/all.db 2014-10-13 03:01:11.0 + +++ flash-kernel-3.28.1/db/all.db 2014-12-16 04:49:57.0 + @@ -580,6 +580,18 @@ U-Boot-Script-Name: bootscr.beaglebone Required-Packages: u-boot-tools +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 + Machine: Toshiba AC100 / Dynabook AZ Method: android Android-Boot-Device: /dev/mmcblk0
