Is necessary to test WIC images on all reference HW on QA cycles. This should be reflected on the Test Plan for BSPs on 2.3.
José, when you create the supported hardware list please add the Freescale MPC8315ERDB there.
List of HW is dcouemnted on iki page, test WIC images on all refernece HW will be acomplished after 2.3 M1 QA cycle. https://wiki.yoctoproject.org/wiki/QA/Master_Test_Plan#Runtime_testing
What's P1022ds ? It's not mentioned in README.hardware as a reference hardware. If wic images need to be tested on it we need to take care of this before 2.3 M1 QA cycle. As for MPC8315ERDB platform I need help to ensure wic images work on it as I don't have working hardware. You can see details in the bug 8719 The rest of hardware looks good to me.
Adding Yi on CC to the bug to give more details on this platforms
BTW, is this bug about automated testing? I really hope it is.
Why Edgerouter, Beaglebone and Qemu testing items don't include wic images?
(In reply to comment #3) > What's P1022ds ? It's not mentioned in README.hardware as a reference > hardware. If wic images need to be tested on it we need to take care of this > before 2.3 M1 QA cycle. > We had dropped p1002ds. Please see bug 9637 . > As for MPC8315ERDB platform I need help to ensure wic images work on it as I > don't have working hardware. You can see details in the bug 8719 > I will check the wic image for MPC8315E. //Yi > The rest of hardware looks good to me.
(In reply to comment #6) > Why Edgerouter, Beaglebone and Qemu testing items don't include wic images? Currently the beaglebone and edgerouter have wic image in http://downloads.yoctoproject.org/releases/yocto/yocto-2.2/machines/ , but mpc8315e doesn't have.
This is because I have Beaglebone and Edgerouter hardware and built and tested wic images for them. If you tell me what kind of image mpc8315e supports I can build it.
Jose, I've looked at the wiki page you prepared https://wiki.yoctoproject.org/wiki/QA/Master_Test_Plan#Runtime_testing and I can see that testing wic images is not planned for most of reference hardware from the first table. It can only planned for MPC8315e-rdb, which is the only piece of reference hardware that was not tested. Can you elaborate on this, please?
Ed I updated the table, just added support for EdgeRouter, MPC8315e and Beaglebone the other ones were already planned i set "WIC" at the end of the image name make more notorious on the plan. Please review it and let me know if you are agree with the coverage https://wiki.yoctoproject.org/wiki/QA_Master_Test_Plan#Runtime_testing
(In reply to comment #6) > Why Edgerouter, Beaglebone and Qemu testing items don't include wic images? Edgerouter, Beaglebone were now added to the plan, Qemu are tested on hosts machines and wic images are not being generated.
Even if they're not generated it would be good to test them. With this patch http://lists.openembedded.org/pipermail/openembedded-core/2016-November/129219.html you can enable generation of qemu wic images by adding this line to cone/local.conf: IMAGE_FSTYPES += "wic" I'll try to do the same for the rest of qemu images, so please consider testing wic images on qemu targets.
It looks like qemu refuses to run non-x86 wic images. I'll investigate this further, but for now let's add wic images to the test plan only for qemux86* machines as they're known to work correctly.
(In reply to comment #5) > BTW, is this bug about automated testing? I really hope it is. automated testing is coming along so, initially it is not
(In reply to comment #9) > This is because I have Beaglebone and Edgerouter hardware and built and > tested wic images for them. > > If you tell me what kind of image mpc8315e supports I can build it. The mpc8315e has a 150GB hard disk within it. Normally we extract the tar.bz2 rootfs to the hard disk partition to test it. Would you please give me a patch for generating wic image? Then I can build and test it. Thanks. //Yi
I need to know partitioning scheme and boot configuration to generate an image. Please confirm that this configuration is ok for the device or propose your own: boot loader - u-boot Partition scheme: Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 4096B 16.8MB 16.8MB primary fat16 boot, lba 2 16.8MB 82.6MB 65.8MB primary ext4 boot partition - vfat partition with u-boot.bin, kernel and device tree in the root directory: drwxr-xr-x 2 root root 16384 Jan 1 1970 . drwxr-xr-x 23 root root 4096 Mar 9 2015 .. -rwxr-xr-x 1 root root 423964 Nov 30 2016 u-boot-mpc8315e-rdb.bin -rwxr-xr-x 1 root root 423964 Nov 30 2016 u-boot.bin -rwxr-xr-x 1 root root 9598 Nov 30 2016 uImage-mpc8315erdb.dtb root partition - ext4 partition with poky core-image-minimal rootfs on it.
Usually to test if wic image boots I flash it to USB stick or sd card and try to boot from it. However, the procedure for MPC may be different. Let me point out that unlike oe images wic images is not just a rootfs. They're partitioned images with configured bootloader and kernel. That means that all 3 above components(boot loader, kernel and rootfs) need to be tested together. Testing rootfs is not enough. So, if you just copy content of rootfs partition to root partition on the hard drive and boot from it you'll test only one component - rootfs. This is not enough to test wic image.
According to this document http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/powerquicc-processors/powerquicc-ii-pro-83xx/mpc8313e-rdb-reference-platform:MPC8313E-RDB MPC device has sd card slot. Can you try to flash wic image on sd card and boot from it?
(In reply to comment #14) > It looks like qemu refuses to run non-x86 wic images. I'll investigate this > further, but for now let's add wic images to the test plan only for qemux86* > machines as they're known to work correctly. Added WIC image to the plan for QEMU's
It would be hard/impossible to properly test wic images on non-x86 qemu targets. Can you please remove wic images from qemuarm* qemuppc and qemumips* machines?
(In reply to comment #21) > It would be hard/impossible to properly test wic images on non-x86 qemu > targets. Can you please remove wic images from qemuarm* qemuppc and > qemumips* machines? Done
thank you! now the plan looks good to me.
(In reply to comment #19) > According to this document > http://www.nxp.com/products/microcontrollers-and-processors/power- > architecture-processors/powerquicc-processors/powerquicc-ii-pro-83xx/ > mpc8313e-rdb-reference-platform:MPC8313E-RDB MPC device has sd card slot. > Can you try to flash wic image on sd card and boot from it? The link is for MPC8313E, not MPC8315E. The MPC8315E doesn't support sd card: http://www.nxp.com/products/software-and-tools/hardware-development-tools/embedded-board-solutions-ebs/low-power-powerquicc-ii-pro-processor-with-ddr2-tdm-pci-pci-express-sata-1-gb-ethernet-security-usb:MPC8315E The USB also doesn't support to boot. There are a 8MB NOR flash and 32MB NAND flash on the board. We also have a case to test jffs2 image boot from NAND: https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=1036 Here are the 3 partitions for NAND (mtd device in Linux OS): # cat /proc/mtd dev: size erasesize name mtd0: 00800000 00010000 "fe000000.flash" # This is NOR flash mtd1: 00100000 00004000 "u-boot" mtd2: 00300000 00004000 "kernel" mtd3: 01c00000 00004000 "fs" # In our case, we only erase this partition and flash the jffs2 rootfs # mtdinfo /dev/mtd1 mtd1 Name: u-boot Type: nand Eraseblock size: 16384 bytes, 16.0 KiB Amount of eraseblocks: 64 (1048576 bytes, 1024.0 KiB) Minimum input/output unit size: 512 bytes Sub-page size: 512 bytes OOB size: 16 bytes Character device major/minor: 90:2 Bad blocks are allowed: true Device is writable: false # mtdinfo /dev/mtd2 mtd2 Name: kernel Type: nand Eraseblock size: 16384 bytes, 16.0 KiB Amount of eraseblocks: 192 (3145728 bytes, 3.0 MiB) Minimum input/output unit size: 512 bytes Sub-page size: 512 bytes OOB size: 16 bytes Character device major/minor: 90:4 Bad blocks are allowed: true Device is writable: true # mtdinfo /dev/mtd3 mtd3 Name: fs Type: nand Eraseblock size: 16384 bytes, 16.0 KiB Amount of eraseblocks: 1792 (29360128 bytes, 28.0 MiB) Minimum input/output unit size: 512 bytes Sub-page size: 512 bytes OOB size: 16 bytes Character device major/minor: 90:6 Bad blocks are allowed: true Device is writable: true We still have some problems even if the wic supports NAND: 1. The size of NAND flash is 32MB, we only can use minimal image. 2. We need a u-boot for NAND. The default u-boot is from NOR flash so it only build u-boot for NOR in Yocto. We need to build a u-boot for NAND and adjust the jumpers in the board to make sure the u-boot is from NAND. 3. It should be jffs2 for rootfs, not ext4 format. How do you think about it? Thanks, Yi
adding bug 10747 as a dependency and moving this to M2, because of the dependency. Though, what is ready for M1 should be still included in such milestone. Perhaps break down the bug again and leave this for M2 and have in M1 what will be included?
Yi, thank you for the detailed information. So, basically you're not testing kernel and u-boot from the build. You're testing only rootfs. It looks a bit strange to me to say the least. Especially looking at the instructions from README.hardware: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/README.hardware I'd suggest you to do the following: 1. flash u-boot from the build to the device 2. Try to load kernel from USB. You said that it's not possible with the default u-boot, but it may be too old and doesn't support working with USB. If you upgrade it you may be able to load kernel from USB stick There is a bunch of usb-related commands supported by newer u-boot: usb start, usb reset, usb tree, usb info, usb stop, usb scan, usb device, usb read, usb boot .... fatload command can be used to load kernel from USB stick. I'm just guessing here of course as I don't have access to the device. 3. if 2 doesn't work - load kernel from tftp. Even old u-boot should support it 4. flash wic image to USB stick, point kernel to the root partition of it and try to boot the system from the USB stick. 5. If 4 doesn't work - copy root partition to NFS and try to boot the system from it. PS: I'd suggest to move to bug 8719 which is more appropriate for this discussion. It'd also be interesting to know how do you test the rest of non-x86 reference hardware (Beaglebone, Edgerouter).
(In reply to comment #26) > Yi, thank you for the detailed information. > > So, basically you're not testing kernel and u-boot from the build. You're > testing only rootfs. It looks a bit strange to me to say the least. > Especially looking at the instructions from README.hardware: > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/README.hardware Hi Ed, Sorry that my last comment make you confused, let me make it more clear: 1. We didn't test or use wic image for all non-x86 BSPs before. Generally we use nfs or other boot methods (see below for more details). 2. We definitely test u-boot, kernel and rootfs in testing for MPC8315E (every milestone in Yocto). I also flash the u-boot once it is updated in Yocto so we keep the latest u-boot in our boards. Currently we have 3 methods to boot this board in testing: a. Boot from NFS for most runtime testing. This is same with section "Booting from NFS root" in README.hardware. b. Boot from harddisk for LTP/POSIX testing in order to avoid some unexpected case failures caused by NFS. In this method, the rootfs is deployed to the harddisk partition manually. The kernel and dtb are downloaded from tftp which is same with NFS boot method. c. Boot from jffs2in NAND. This is same with section "Booting from JFFS2 root" in README.hardware. Notice that the kernel and dtb still from tftp and the jffs2 rootfs is deployed to the mtd partition manually. As I said above, we also didn't use wic image in testing for beaglebone and edgerouter. We use the old method which describe in README.hardware that before you update: For edgerouter, use nfs or create partition and deploy rootfs to usb by hand. For beaglebone, create partition and deploy u-boot, kernel and rootfs to SD card by hand. I tested wic image recently for these 2 boards and it works fine. So we will switch to wic image in subsequent testing. For your suggestion, first I need to do is trying to load kernel from USB stick and then trying to flash wic image to the USB stick. I will give the result ASAP. But I have a question, as you said in comment 18, a wic image should be consisted with bootloader, kernel and rootfs. But for MPC8315E, seems like the u-boot must be in NOR or NAND flash, not in usb stick. That mean the wic image for MPC8315E only includes kernel and rootfs, is that right ? Thanks, Yi > > I'd suggest you to do the following: > > 1. flash u-boot from the build to the device > > 2. Try to load kernel from USB. You said that it's not possible with the > default u-boot, but it may be too old and doesn't support working with USB. > If you upgrade it you may be able to load kernel from USB stick > > There is a bunch of usb-related commands supported by newer u-boot: > usb start, usb reset, usb tree, usb info, usb stop, usb scan, usb device, > usb read, usb boot .... > > fatload command can be used to load kernel from USB stick. > > I'm just guessing here of course as I don't have access to the device. > > 3. if 2 doesn't work - load kernel from tftp. Even old u-boot should support > it > > 4. flash wic image to USB stick, point kernel to the root partition of it > and try to boot the system from the USB stick. > > 5. If 4 doesn't work - copy root partition to NFS and try to boot the system > from it. > > > PS: I'd suggest to move to bug 8719 which is more appropriate for this > discussion. It'd also be interesting to know how do you test the rest of > non-x86 reference hardware (Beaglebone, Edgerouter).
Hi Ed, Here is a result for booting from USB for mpc8315e: 1. Create USB partition and deploy kernel, dtb and rootfs. I don't create a separated vfat partition to deploy kernel and dtb. Because the current u-boot for mpc8315e doesn't support load file from vfat format partition (There is no fatload/fatls command in u-boot commandline) fdisk /dev/sdb mkfs.ext3 /dev/sdb1 tar xjf core-image-minimal-mpc8315e-rdb.tar.bz2 -C /run/media/sdb1 cp uImage /run/media/sdb1/boot/uImage cp dtb /run/media/sdb1/boot/dtb 2. Set the boot command in u-boot: usb start ext2load usb 0:1 $loadaddr boot/uImage ext2load usb 0:1 $fdtaddr boot/dtb setenv bootargs root=/dev/sdb1 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs bootm $loadaddr - $fdtaddr We can set a usbboot bootcmd: setenv usbboot 'usb start; setenv bootargs root=/dev/sdb1 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs; ext2load usb 0:1 $loadaddr boot/uImage; ext2load usb 0:1 $fdtaddr boot/dtb; bootm $loadaddr - $fdtaddr' saveenv run usbboot The system can boot without problem. So I think you can give me a patch to create wic image for mpc8315e and test it for USB. If you prefer deploying kernel and dtb in a separated vfat partition, I need to add the vfat support for u-boot and rebuilt it. How do you think about it? Thanks, Yi
> But I have a question, as you said in comment 18, a wic image should be consisted with bootloader, kernel and rootfs. But for MPC8315E, seems like the u-boot must be in NOR or NAND flash, not in usb stick. That mean the wic image for MPC8315E only includes kernel and rootfs, is that right ? True, but it can be loaded from USB to the NOR flash, right? Can you try it? > The system can boot without problem. That's great! Now you don't need to deal with NFS. If you can load u-boot from USB stick it would be even better! > So I think you can give me a patch to create wic image for mpc8315e and test it for USB. I will prepare .wks file and a patch, but i need to know first if you can load u-boot from USB stick > If you prefer deploying kernel and dtb in a separated vfat partition, I need to add the vfat support for u-boot and rebuilt it. How do you think about it? I'm thinking about deploying u-boot, kernel and dab to a separate ext3 partition. This should give you possibility to load everything you need from that partition: usb start ext2load usb 0:1 <loadaddr for u-boot> u-boot.bin ext2load usb 0:1 $loadaddr uImage ext2load usb 0:1 $fdtaddr dtb setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs bootm $loadaddr - $fdtaddr However, it would depend on either you're able to load u-boot.bin from USB stick or not. Does this make sense for you?
I think u-boot should be flashed after it's loaded with 'protect off all, erase and cp.b' commands. You probably know it better than me.
(In reply to comment #29) > > But I have a question, as you said in comment 18, a wic image should be consisted with bootloader, kernel and rootfs. But for MPC8315E, seems like the u-boot must be in NOR or NAND flash, not in usb stick. That mean the wic image for MPC8315E only includes kernel and rootfs, is that right ? > > True, but it can be loaded from USB to the NOR flash, right? Can you try it? > > > The system can boot without problem. > That's great! Now you don't need to deal with NFS. > If you can load u-boot from USB stick it would be even better! > > > So I think you can give me a patch to create wic image for mpc8315e and test it for USB. > > I will prepare .wks file and a patch, but i need to know first if you can > load u-boot from USB stick > > > If you prefer deploying kernel and dtb in a separated vfat partition, I need to add the vfat support for u-boot and rebuilt it. How do you think about it? > > I'm thinking about deploying u-boot, kernel and dab to a separate ext3 > partition. This should give you possibility to load everything you need from > that partition: > usb start > ext2load usb 0:1 <loadaddr for u-boot> u-boot.bin Hi Ed, I have confirmed with Kexin Hao <kexin.hao@windriver.com> who is our ppc BSP developer that this boot method is not supported for MPC8315E. This board is too old so missing many modern features (e.g. booting from sd card/usb ). Maybe the best way is dropping this reference BSP and choosing a new one in Yocto. I add Kexin Hao in CC list. He can answer more technical problems. Thanks, Yi > ext2load usb 0:1 $loadaddr uImage > ext2load usb 0:1 $fdtaddr dtb > setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate > $othbootargs > bootm $loadaddr - $fdtaddr > > However, it would depend on either you're able to load u-boot.bin from USB > stick or not. > > Does this make sense for you?
(In reply to comment #31) > (In reply to comment #29) > > I'm thinking about deploying u-boot, kernel and dab to a separate ext3 > > partition. This should give you possibility to load everything you need from > > that partition: > > usb start > > ext2load usb 0:1 <loadaddr for u-boot> u-boot.bin > > Hi Ed, > > I have confirmed with Kexin Hao <kexin.hao@windriver.com> who is our ppc BSP > developer that this boot method is not supported for MPC8315E. This board is > too old so missing many modern features (e.g. booting from sd card/usb ). I'm sorry for the confusion. I didn't propose to boot MPC8315 from usb. I proposed to load u-boot.bin, kernel and device tree from ext3 partition. > Maybe the best way is dropping this reference BSP and choosing a new one in Yocto. This work is ongoing, but it'll take some time, I'm afraid. We should keep working with MPC8315 until it's replaced by another hardware. > > > ext2load usb 0:1 $loadaddr uImage > > ext2load usb 0:1 $fdtaddr dtb > > setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate > > $othbootargs > > bootm $loadaddr - $fdtaddr > > > > However, it would depend on either you're able to load u-boot.bin from USB > > stick or not. > > > > Does this make sense for you? So, can you try to load u-boot.bin from ext3 partition on USB stick? I think it should be possible with newer u-boot.
(In reply to comment #32) > (In reply to comment #31) > > (In reply to comment #29) > > > I'm thinking about deploying u-boot, kernel and dab to a separate ext3 > > > partition. This should give you possibility to load everything you need from > > > that partition: > > > usb start > > > ext2load usb 0:1 <loadaddr for u-boot> u-boot.bin > > > > Hi Ed, > > > > I have confirmed with Kexin Hao <kexin.hao@windriver.com> who is our ppc BSP > > developer that this boot method is not supported for MPC8315E. This board is > > too old so missing many modern features (e.g. booting from sd card/usb ). > > I'm sorry for the confusion. I didn't propose to boot MPC8315 from usb. I > proposed to load u-boot.bin, kernel and device tree from ext3 partition. > Thank you Ed, I'm sorry that I misunderstood your comment before. OK, I have re-tested with the usb stick. I created 3 partitions on the usb: Partition 1: ext3 format, u-boot.bin Partition 2: ext3 format, uImage and dtb Partition 3: ext3 format, rootfs Step 1 Load u-boot.bin from usb and flash it: usb start ext2load usb 0:1 200000 u-boot.bin protect off all erase fe000000 fe06ffff cp.b 200000 fe000000 70000 Step 2 Reset the u-boot and boot up the system: usb start ext2load usb 0:2 $loadaddr uImage ext2load usb 0:2 $fdtaddr dtb setenv bootargs root=/dev/sdb3 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs bootm $loadaddr - $fdtaddr All steps work well. Thanks, Yi > > > Maybe the best way is dropping this reference BSP and choosing a new one in Yocto. > > This work is ongoing, but it'll take some time, I'm afraid. We should keep > working with MPC8315 until it's replaced by another hardware. > > > > > > ext2load usb 0:1 $loadaddr uImage > > > ext2load usb 0:1 $fdtaddr dtb > > > setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate > > > $othbootargs > > > bootm $loadaddr - $fdtaddr > > > > > > However, it would depend on either you're able to load u-boot.bin from USB > > > stick or not. > > > > > > Does this make sense for you? > > So, can you try to load u-boot.bin from ext3 partition on USB stick? I think > it should be possible with newer u-boot.
That's a very good news! Thank you very much for helping with this! I'd suggest last small improvement: you can put u-boot.bin, kernel and dtb on the same partition. There is no need to load u-boot.bin from one partition, but kernel and dab from another. The summary: We can't boot MPC8315 directly from usb stick due to the limitation of the device. However, we can simplify loading u-boot.bin, kernel and dtb and booting the device by preparing wic image with 2 partitions(1st ext3 partition is for loading u-boot, kernel and dtb, second partition - rootfs). This setup is much easier to deal with than current setup described in README.hardware as it doesn't involve setting up tftp and nfsroot. Moreover, it doesn't require networking setup. Device can be even detached from network and proposed setup would still work. I'd suggest to go for it. Does this make sense for you? Any other ideas?
Yi, can you build wic image for MPC from my contrib branch: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ed/poky/ref-BSP-wic-8719 ? It should produce wic image with 2 partitions: boot ext3 partition with 3 files: u-boot.bin, uImage and dtb root ext3 partition with rootfs Please, try to flash the image on USB stick and boot it the way you've previously described with a little changes: Step 1 Load u-boot.bin from usb and flash it: usb start ext2load usb 0:1 200000 u-boot.bin protect off all erase fe000000 fe06ffff cp.b 200000 fe000000 70000 Step 2 Reset the u-boot and boot up the system: usb start ext2load usb 0:1 $loadaddr uImage ext2load usb 0:1 $fdtaddr dtb setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs bootm $loadaddr - $fdtaddr Hopefully this will work well. I'd really appreciate if you describe the process in as much details as possible as I'm going to update README.hardware with your description and suggest it as a preferred way to test the device. Thank you for your great help with this!
(In reply to comment #34) > That's a very good news! Thank you very much for helping with this! > > I'd suggest last small improvement: you can put u-boot.bin, kernel and dtb > on the same partition. There is no need to load u-boot.bin from one > partition, but kernel and dab from another. > > The summary: > > We can't boot MPC8315 directly from usb stick due to the limitation of the > device. > However, we can simplify loading u-boot.bin, kernel and dtb and booting the > device by preparing wic image with 2 partitions(1st ext3 partition is for > loading u-boot, kernel and dtb, second partition - rootfs). > > This setup is much easier to deal with than current setup described in > README.hardware as it doesn't involve setting up tftp and nfsroot. Moreover, > it doesn't require networking setup. Device can be even detached from > network and proposed setup would still work. I'd suggest to go for it. > > Does this make sense for you? It's fine to me Yi > > Any other ideas?
(In reply to comment #35) > Yi, can you build wic image for MPC from my contrib branch: > https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ed/poky/ref- > BSP-wic-8719 ? > > It should produce wic image with 2 partitions: > boot ext3 partition with 3 files: u-boot.bin, uImage and dtb > root ext3 partition with rootfs > > Please, try to flash the image on USB stick and boot it the way you've > previously described with a little changes: > > Step 1 Load u-boot.bin from usb and flash it: > usb start > ext2load usb 0:1 200000 u-boot.bin > protect off all > erase fe000000 fe06ffff > cp.b 200000 fe000000 70000 > > Step 2 Reset the u-boot and boot up the system: > usb start > ext2load usb 0:1 $loadaddr uImage > ext2load usb 0:1 $fdtaddr dtb > > setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate > $othbootargs > bootm $loadaddr - $fdtaddr > > Hopefully this will work well. > > I'd really appreciate if you describe the process in as much details as > possible as I'm going to update README.hardware with your description and > suggest it as a preferred way to test the device. I will try it ASAP. Yi > > Thank you for your great help with this!
Any news on this?
(In reply to comment #38) > Any news on this? Hi Ed, Sorry a little late because I'm working on 2.0.3 testing these days. But now I have finished it: 1. built a wic image for mpc8315e from your contrib branch 2. dd the wic image to a USB stick dd if=./core-image-sato-mpc8315e-rdb-20161212013335.rootfs.wic of=/dev/sdc 3. load the u-boot.bin from USB stick and flash it # Load the u-boot.bin usb start ext2load usb 0:1 200000 u-boot.bin # Flash the u-boot protect off all erase fe000000 fe06ffff cp.b 200000 fe000000 70000 protect on all # Reset the board reset Here is the full output for above input: Hit any key to stop autoboot: 0 => => usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => ext2load usb 0:1 200000 u-boot.bin 428664 bytes read in 137 ms (3 MiB/s) => protect off all Un-Protect Flash Bank # 1 ....................................................................................................................................... done => erase fe000000 fe06ffff ....... done Erased 7 sectors => cp.b 200000 fe000000 70000 Copy to Flash... done => protect on all Protect Flash Bank # 1 ....................................................................................................................................... done => reset Resetting the board. 4. Boot up from USB # Set the correct value for fdtaddr and loadaddr (It is not necessary if you set these before) setenv fdtaddr a00000 setenv loadaddr 1000000 # Load the kernel and dtb usb start ext2load usb 0:1 $loadaddr uImage ext2load usb 0:1 $fdtaddr dtb # Set bootargs and boot up system setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs bootm $loadaddr - $fdtaddr Notice that the rootdelay must be added because we need a few seconds to wait the kernel found the usb stick when booting. Here is the full output for above input: Hit any key to stop autoboot: 0 => usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => ext2load usb 0:1 $loadaddr uImage 5489915 bytes read in 508 ms (10.3 MiB/s) => ext2load usb 0:1 $fdtaddr dtb 9598 bytes read in 69 ms (135.7 KiB/s) => setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs => bootm $loadaddr - $fdtaddr ## Booting kernel from Legacy Image at 01000000 ... Image Name: Linux-4.8.10-yocto-standard Created: 2016-12-12 2:10:35 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 5489851 Bytes = 5.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 00f00000 Booting using the fdt blob at 0xf00000 Uncompressing Kernel Image ... OK Loading Device Tree to 07ef2000, end 07ef757d ... OK NOTICE: No or unknown board_type hwconfig specified. Assuming board with TSEC1. Linux version 4.8.10-yocto-standard (zhaoyi@pek-yzhao1-d1) (gcc version 6.2.0 (GCC) ) #1 PREEMPT Mon Dec 12 10:10:09 CST 2016 Using MPC831x RDB machine description bootconsole [udbg0] enabled ----------------------------------------------------- Hash_size = 0x0 phys_mem_size = 0x8000000 dcache_bsize = 0x20 icache_bsize = 0x20 cpu_features = 0x0000000000020460 possible = 0x0000000005a6fd77 always = 0x0000000000020000 cpu_user_features = 0x8c000000 0x00000000 mmu_features = 0x00210000 ----------------------------------------------------- [snip] If you want to use autoboot in u-boot, you can set: setenv bootcmd 'usb start; setenv bootargs root=/dev/sdb2 rw rootdelay=5 console=$consoledev,$baudrate $othbootargs; ext2load usb 0:1 $loadaddr uImage; ext2load usb 0:1 $fdtaddr dtb; bootm $loadaddr - $fdtaddr' saveenv reset Thanks, Yi
Yi, thank you for detailed explanations. One small point: you can use rootwait instead of rootdelay=5 in kernel command line. Kernel will wait indefinitely for usb device to show up. Can you explain what are parameters of some u-boot commands you've used. Especially if they're potentially dangerous for the device. As I'm going to put it into README.hardware I should be certain that commands are harmless. For example what's 70000 in this command: cp.b 200000 fe000000 70000 What does 'erase fe000000 fe06ffff' command erases?
According to MPC8315E-RDB Reference Design User’s Guide, The address 0xFE000000 - 0xFE7FFFFF is the memory map for NOR flash (8 MB). The u-boot address in the flash starts from 0xFE000000. # Load the new u-boot.bin from usb to memory address 200000 usb start ext2load usb 0:1 200000 u-boot.bin # Disable the flash protection protect off all # Erase the old u-boot from fe000000 to fe06ffff in NOR flash. The size is 0x70000 (458752 Bytes, our new u-boot is about 428664 Bytes.) erase fe000000 fe06ffff # Copy the new u-boot from address 200000 to fe000000, the size is 0x70000 cp.b 200000 fe000000 70000 # Enable the flash protection again protect on all I must say that flash the u-boot is dangerous, the user should know what the above commands meaning. The rootwait works fine. Thanks. Yi
(In reply to comment #39) > > 4. Boot up from USB > # Set the correct value for fdtaddr and loadaddr (It is not necessary if you > set these before) > setenv fdtaddr a00000 Here the fdtaddr should be f00000, not a00000 > setenv loadaddr 1000000 >
Yi, thank you very much for the detailed explanations! Now we successfully tested wic images for all Yocto reference hardware!
WIC images were validated on 2.3 M1 results can be found here: https://wiki.yoctoproject.org/wiki/WW52_-_2016-12-19_-_Full_Test_Cycle_2.3_M1_rc1#Test_Run_Summary_Report
Jose, can you explain how to see that wic image was used for MPC8315e-rdb, Edgerouter and Beaglebone from that report?
(In reply to comment #45) > Jose, can you explain how to see that wic image was used for MPC8315e-rdb, > Edgerouter and Beaglebone from that report? This was executed by Yi Zaho. Yi are you able to respond to Ed.
(In reply to comment #45) > Jose, can you explain how to see that wic image was used for MPC8315e-rdb, > Edgerouter and Beaglebone from that report? Hi Ed, For Yocto 2.3, we already perform all test cases for these BSPs on the wic images. So it is no need to specify it in test runs summary or add extra "wic" test cases. //Yi
Verified, all details on tested wic images are here: https://wiki.yoctoproject.org/wiki/QA_Master_Test_Plan#Runtime_testing