Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Dec 28, 2014, at 17:08, Ian Campbell i...@debian.org wrote: On Fri, 2014-12-26 at 18:43 +0800, Chen Baozi wrote: With the attached patch applied, debian installer (tested with network-console) can support OMAP5's ethernet driver and external MicroSD card. Note that I added related regulator phy entries to files that mainly writes the modules which use them, since there is no file dedicated to those modules. Do you know if phy-ti-pipe3 is used exclusively by USB or just only within the set of things used in the d-i context? Likewise the two regulators added to mmc? So far as I can tell from DTS, there are two types of modules use phy-ti-pipe3, which are ‘usb3’ and ‘sata’. But I am not quite sure how the hardware modules are connected. And pbias seems be only meaningful to mmc, and palmas relates to many other devices of the board. Baozi. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Tue, Dec 23, 2014 at 7:44 PM, Ian Campbell i...@debian.org wrote: On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote: I have a glance at the kernel’s installer configs and tried the netboot without any modification. Some work should be done to make debian-installer support OMAP5 uEVM (e.g., ethernet driver etc). Right, those should be listed in e.g. debian/installer/armhf/modules/armhf-armmp/nic-modules. By waiting the kernel building with some initial attempted configs added, just one question to ask. I looked through the debian/installer/armhf/modules/armhf-armmp/, but it looks like none of files is about regulator modules. However, according to my previous experience, missing regulator driver modules is the main reason that the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer deal with this situation (if it does need extra regulator drivers included?) Long term its a bit of an open question what we do wrt modules such as regulators, clocks, pinctrl etc. So far we have been a bit lucky: either such things are so central to the platform that it is acceptable (at least for now) to just build them into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410 which is for the main power controller on arndale) or they are closely associated with some particular device and it makes sense to put them in that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in usb-modules). Eventually I expect that we will end up creating separate udebs for these things, but I'm hoping that we can defer that until at least Stretch to avoid needing to mess around with any more new packages for Jessie. If uEVM has some module which either shouldn't be built in or isn't obviously associated with a particular device let us know what it is and we can have a think about how best to approach it. One thing I've played with, and I'm not sure if this is acceptable or not, is to put core drivers which aren't =y into the kernel-image udeb itself. I'm not really sure if that's a good idea, we don't currently do this for anything AFAIK, but it's perhaps an option. With the attached patch applied, debian installer (tested with network-console) can support OMAP5's ethernet driver and external MicroSD card. Note that I added related regulator phy entries to files that mainly writes the modules which use them, since there is no file dedicated to those modules. Baozi. --- diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-09-21 20:04:21.0 + +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-12-26 03:16:02.0 + @@ -4,3 +4,5 @@ omap_hsmmc sunxi-mmc dw_mmc-exynos +pbias-regulator +palmas-regulator diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules 2014-12-23 08:10:49.0 + +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules 2014-12-25 02:56:08.0 + @@ -1,8 +1,13 @@ #include usb-modules phy-sun4i-usb dwc3-exynos ohci-exynos ehci-exynos phy-exynos-usb2 ci_hdrc_imx +phy-mxs-usb +dwc3-omap +ohci-omap3 +ehci-omap +phy-omap-usb2 +phy-ti-pipe3 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caeyzweflwsbbpd-yrcxcplpfbupsahc4ycwmtu1r3xdmdou...@mail.gmail.com
Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Fri, Dec 26, 2014 at 6:43 PM, Chen Baozi baoz...@gmail.com wrote: On Tue, Dec 23, 2014 at 7:44 PM, Ian Campbell i...@debian.org wrote: On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote: I have a glance at the kernel’s installer configs and tried the netboot without any modification. Some work should be done to make debian-installer support OMAP5 uEVM (e.g., ethernet driver etc). Right, those should be listed in e.g. debian/installer/armhf/modules/armhf-armmp/nic-modules. By waiting the kernel building with some initial attempted configs added, just one question to ask. I looked through the debian/installer/armhf/modules/armhf-armmp/, but it looks like none of files is about regulator modules. However, according to my previous experience, missing regulator driver modules is the main reason that the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer deal with this situation (if it does need extra regulator drivers included?) Long term its a bit of an open question what we do wrt modules such as regulators, clocks, pinctrl etc. So far we have been a bit lucky: either such things are so central to the platform that it is acceptable (at least for now) to just build them into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410 which is for the main power controller on arndale) or they are closely associated with some particular device and it makes sense to put them in that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in usb-modules). Eventually I expect that we will end up creating separate udebs for these things, but I'm hoping that we can defer that until at least Stretch to avoid needing to mess around with any more new packages for Jessie. If uEVM has some module which either shouldn't be built in or isn't obviously associated with a particular device let us know what it is and we can have a think about how best to approach it. One thing I've played with, and I'm not sure if this is acceptable or not, is to put core drivers which aren't =y into the kernel-image udeb itself. I'm not really sure if that's a good idea, we don't currently do this for anything AFAIK, but it's perhaps an option. With the attached patch applied, debian installer (tested with network-console) can support OMAP5's ethernet driver and external MicroSD card. Note that I added related regulator phy entries to files that mainly writes the modules which use them, since there is no file dedicated to those modules. Baozi. --- diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-09-21 20:04:21.0 + +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-12-26 03:16:02.0 + @@ -4,3 +4,5 @@ omap_hsmmc sunxi-mmc dw_mmc-exynos +pbias-regulator +palmas-regulator diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules 2014-12-23 08:10:49.0 + +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules 2014-12-25 02:56:08.0 + @@ -1,8 +1,13 @@ #include usb-modules phy-sun4i-usb dwc3-exynos ohci-exynos ehci-exynos phy-exynos-usb2 ci_hdrc_imx +phy-mxs-usb ^ Oops, this is introduced by '-ckt2', not by me... +dwc3-omap +ohci-omap3 +ehci-omap +phy-omap-usb2 +phy-ti-pipe3 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caeyzweet7al4pqglvxkr41fx1ohfy+gymp9w7zqklbel7bh...@mail.gmail.com
Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
Hi Ian, On Dec 17, 2014, at 16:38, Ian Campbell i...@debian.org wrote: On Wed, 2014-12-17 at 15:10 +0800, Chen Baozi wrote: Hi Ian, On Dec 13, 2014, at 20:21, Ian Campbell i...@debian.org wrote: If you care about Debian Installer support then you should also check whether any of the newly added modules need to be added to the installer udebs (which you can mainly do via the module lists under debian/installer/armhf/modules/armhf-armmp/). I've added dwc3-omap to usb-modules already since that one seemed obvious. I haven't tried debian-installer on arm platform before. I guess people usually don’t use it as a CD/DVD installer image like x86 on arm? I usually use netboot, others use hd-media from USB sticks etc. Any pre-built image for a quick test? Do I need to generate the image by myself? There are daily installer images at http://d-i.debian.org/daily-images/armhf/ but these are built from the kernel etc in sid not from svn, i.e. don't yet include the changes to enable uEVM, so until the kernel is next uploaded you would indeed need to build d-i yourself. That's not too hard: Take all the udebs from your kernel build (e.g. from dcmd --udeb linux_..._armhf.changes) and put them in the build/localudebs directory of the debian-installer.git. Then: make -C build build_netboot etc. It doesn't (easily?) cross compile, so you will need an armhf host. I have a glance at the kernel’s installer configs and tried the netboot without any modification. Some work should be done to make debian-installer support OMAP5 uEVM (e.g., ethernet driver etc). By waiting the kernel building with some initial attempted configs added, just one question to ask. I looked through the debian/installer/armhf/modules/armhf-armmp/, but it looks like none of files is about regulator modules. However, according to my previous experience, missing regulator driver modules is the main reason that the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer deal with this situation (if it does need extra regulator drivers included?) Cheers, Baozi -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d2886b41-533c-45f1-90df-5346ca274...@gmail.com
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 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 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
Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
Hi Ian, On Dec 13, 2014, at 20:21, Ian Campbell i...@debian.org wrote: If you care about Debian Installer support then you should also check whether any of the newly added modules need to be added to the installer udebs (which you can mainly do via the module lists under debian/installer/armhf/modules/armhf-armmp/). I've added dwc3-omap to usb-modules already since that one seemed obvious. I haven't tried debian-installer on arm platform before. I guess people usually don’t use it as a CD/DVD installer image like x86 on arm? Any pre-built image for a quick test? Do I need to generate the image by myself? 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
