Description of problem: a-b-c cannot discover the appropriate config option for my device. Version-Release number of selected component (if applicable): from f19-rc4 (0.49) How reproducible: always Steps to Reproduce: 1. boot using an AC100 2. 3. Actual results: boot fails Expected results: should boot on a kernel-tegra Additional info: target configuration. setenv bootargs console=ttyS0,115200n8 root=UUID=be62c538-034c-40a2-a761-02b7c7d5cec0 ro rootwait 3 cma=64M irqpool LANG=fr_FR.UTF-8 rhgb quiet ext2load mmc 1:1 4880000 uInitrd ext2load mmc 1:1 4080000 uImage ext2load mmc 1:1 5880000 tegra20.dtb bootm 4080000 4880000 5880000 from there, there is no support to boot from external mmc (1 instead of 0). To me, the soc is tegra20 on tegra2 devices. So: if test -n $soc; then if test $soc = tegra20; then if test $board = trimslice; then run config_trimslice else run config_tegra setenv u_dtb ${soc}-${board}.dtb fi fi fi But then I miss a u_kernel parameter (not set in config_tegra ?)
On trimslice devices soc is set to "tegra2" which appears different than on your device. I don't know which is the outlier in this regard. Please send me the output of "printenv" on your system before boot.scr is loaded. I will add support for your device.
A quick copy. (best would be to take a picture, will do later). board=paz00 board_name=paz00 boot_targets=mmc1 mmc0 usb0 dhcp ... fdt_addr_r=0x02000000 fdtaddr=1f7760e0 soc=tegra20 I'm using upstream u-boot from 2013.04 or later.
Ah, this is the first time I've seen upstream uboot used for tegra. Neat. I made a few changes to arm-boot-config 0.51 so it recognizes soc set to tegra2 and tegra20 as being one in the same. Your device should end up with the defaults once you use the new version: u_extraargs "console=ttyS0,115200n8" setenv u_k_addr 4080000 setenv u_ramfs_addr 4800000 setenv u_dtb_addr 0x02000000 (This gets grabbed from $fdt_addr_r) setenv skip_dtb "" setenv pass_dtb 1 setenv u_iodevs usb mmc setenv u_fs ext2 setenv u_boot bootz It's not uploaded yet, but in a few minutes/hours RC4.1 will be available with the new version at this location: http://armpkgs.fedoraproject.org/mash/stage/19-Beta-RC4.1/Images/armhfp/
Last message on boot: No kernel provides dtb named tegra20-paz00.dtb No value for u_kernel. Use klist dtblist to select.
Created attachment 752910 [details] boot from tegrarcm and u-boot with kb support
board=paz00 but is displayed earlier. (others fields might miss).
Based on the picture it should work. Are there any errors before the "No kernel provides..." bit? Another screen capture is fine.
I need to script to sleep before message disappear I've made some experiments (switch mmc usb , bootz -> bootm) At this step it should autodetect the k3 tegra kernel.
Created attachment 752980 [details] boot from a-b-c rc4.1 with modified sleep
Created attachment 753144 [details] A boot.scr with test -z's replaced with test -n's
Try replacing the RC4.1's boot.scr with the attached file and let me know how it goes. Thanks!
No improvement. still Using k3 tegra3 varriant. no kernel provides dtb named tegra20-paz00.dtb No value for u_kernel...
I've tried so re-use the boot.cmd from f18 adapted to 3.9 beta or my own 3.10 kernel and I've failed to load the initramfs with CRC check failure. That's probably another problem hidden behing this one. I've successfully managed to load the kernel initramfs dtb using: setenv fdt_high 0x2C000000 and changing the related loadaddr to: bootm 0x00800000 0x01100000 0x5880000 But then the kernel doesn't seems to load (need to have earlyprintk or boot with more verbosity).
quick note for me to better understand this loadder stuff: http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/configs/tegra20-common.h;hb=HEAD
Created attachment 756607 [details] Updated boot.scr with small debug addition This boot.scr is against the latest a-b-c which includes better generic tegra support and a "sleep " after claiming no value for u_dtb, plus more debugging output. Please give it a try and take a picture if it fails. Thanks!
Created attachment 756890 [details] output latest boot.bcl
Created attachment 756925 [details] More diagnostic info boot.scr This is an even noisier boot.scr. The information will scroll off your screen so I added a sleep 1 statement to each set_u_k7. Please snap a picture that includes the line: Using kernel k3 (3.9.2-301.fc19.armv7hl.tegra). Shows: u_kernel 3.9.2-301.fc19.armv7hl.tegra Then finally, when it shows u_kernel (IE, where the value for u_kernel is again null). On my system it doesn't disappear, so things look like this: ... catin k3_10 catout tegra20-trimslice.dtb u_kernel in set_u_k7 , tegra20-trimslice.dtb, tegra20-trimslice.dtb Using kernel k3 (3.9.2-301.fc19.armv7hl.tegra). on_d 11 in set_u_k6 3.9.2-301.fc19.armv7hl.tegra catin k3_11 catout tegra20-ventana.dtb u_kernel 3.9.2-301.fc19.armv7hl.tegra in set_u_k7 3.9.2-301.fc19.armv7hl.tegra, tegra20-ventana.dtb, tegra20-trimslice .dtb on_d 12 in set_u_k6 3.9.2-301.fc19.armv7hl.tegra catin k3_12 ...
I fail to understand how it defers than the previous. I'm not sure to have tested the right version. Anyway, I don't think we should rewrite all 0:0 1:1 combination but instead rely on upstream builtins: (mmc0 mmc1 usb0 notation and detection methods). http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/configs/tegra-common-post.h http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/configs/tegra20-common.h Also I don't know how the (patched) u-boot on trimslice differs from the this upstream paz00 version. PS: I won't be able to test again until the end of the week.
Not clear what you're proposing re 0:0 1:1 etc. Perhaps you downloaded the latest boot.scr and it was saved as boot.scr.1? The md5sum of the most recent is: 9b01a9390d97e8da89a8fd0c943bd6bb boot.scr
Fixed with 0.56 somehow.
Re-opening as I've missed some rpmnew files, so removing them made the boot to fail again.
Created attachment 780835 [details] working boot.cmd for the AC100
back to the closed state for this bug as I have found that some rpmnew files where still present. That been said, I expect a-b-c should use something like /usr/share/a-b-c.d instead of /etc/a-b-c.d to store the system wide configuration instead of using /etc/a-b-c.d that should be reserved for administrators. (I can open a new report if needed).