Summary of discussion from #fedora-arm --------------------------------------
Dennis Gilmore will be creating a kernel-dtb subpackage for the 3.7 kernel, using 'make dtb' during the kernel build.
The plan is to pull in the 3.7 dtb's into our 3.6 based F18 RC1 release. We will only be including the DTB's where needed, for Trimslice and vexpress which do not boot without a DTB. The Pandaboard will boot the 3.7 without use of a DTB, and Highbank provides it's own.
For a full summary of the testing: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Te...
Paul
On Tue, Jan 22, 2013 at 1:51 PM, Paul Whalen pwhalen@redhat.com wrote:
Summary of discussion from #fedora-arm
Dennis Gilmore will be creating a kernel-dtb subpackage for the 3.7 kernel, using 'make dtb' during the kernel build.
The plan is to pull in the 3.7 dtb's into our 3.6 based F18 RC1 release. We will only be including the DTB's where needed, for Trimslice and vexpress which do not boot without a DTB. The Pandaboard will boot the 3.7 without use of a DTB, and Highbank provides it's own.
For a full summary of the testing:
https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Te...
Paul _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
I get DTB working on the panda by the following code:
# wget http://ausil.us/dtb/omap4-panda.dtb -o /root/omap4-panda.dtb
# cat /boot/vmlinuz-3.6.10-6.fc18.armv7hl.omap /root/omap4-panda.dtb > /root/foo.zimg
# mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "3.6.10-6-DTB" -d /root/foo.zimg /boot/uboot/uImage-dtb
# rm -i /root/foo.zimg
# sed -i -e 's|(uImage)|\1-dtb|s' /boot/uboot/uEnv.txt
That makes an appended DTB style kernel image, and results in /proc/device-tree
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Tue, 22 Jan 2013 14:15:57 -0600 Jon jdisnard@gmail.com escribió:
On Tue, Jan 22, 2013 at 1:51 PM, Paul Whalen pwhalen@redhat.com wrote:
Summary of discussion from #fedora-arm
Dennis Gilmore will be creating a kernel-dtb subpackage for the 3.7 kernel, using 'make dtb' during the kernel build.
The plan is to pull in the 3.7 dtb's into our 3.6 based F18 RC1 release. We will only be including the DTB's where needed, for Trimslice and vexpress which do not boot without a DTB. The Pandaboard will boot the 3.7 without use of a DTB, and Highbank provides it's own.
For a full summary of the testing:
https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Te...
Paul _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
I get DTB working on the panda by the following code:
# wget http://ausil.us/dtb/omap4-panda.dtb -o /root/omap4-panda.dtb
# cat /boot/vmlinuz-3.6.10-6.fc18.armv7hl.omap /root/omap4-panda.dtb
/root/foo.zimg
# mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "3.6.10-6-DTB" -d /root/foo.zimg /boot/uboot/uImage-dtb
# rm -i /root/foo.zimg
# sed -i -e 's|(uImage)|\1-dtb|s' /boot/uboot/uEnv.txt
That makes an appended DTB style kernel image, and results in /proc/device-tree
appending the dtb seems to work fine for a pandaboard, i've never personally had a pandaboard boot when loading the dtb separately
Dennis
On Tue, Jan 22, 2013 at 2:54 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Tue, 22 Jan 2013 14:15:57 -0600 Jon jdisnard@gmail.com escribió:
On Tue, Jan 22, 2013 at 1:51 PM, Paul Whalen pwhalen@redhat.com wrote:
Summary of discussion from #fedora-arm
Dennis Gilmore will be creating a kernel-dtb subpackage for the 3.7 kernel, using 'make dtb' during the kernel build.
The plan is to pull in the 3.7 dtb's into our 3.6 based F18 RC1 release. We will only be including the DTB's where needed, for Trimslice and vexpress which do not boot without a DTB. The Pandaboard will boot the 3.7 without use of a DTB, and Highbank provides it's own.
For a full summary of the testing:
https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Te...
Paul _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
I get DTB working on the panda by the following code:
# wget http://ausil.us/dtb/omap4-panda.dtb -o /root/omap4-panda.dtb
# cat /boot/vmlinuz-3.6.10-6.fc18.armv7hl.omap /root/omap4-panda.dtb
/root/foo.zimg
# mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "3.6.10-6-DTB" -d /root/foo.zimg /boot/uboot/uImage-dtb
# rm -i /root/foo.zimg
# sed -i -e 's|(uImage)|\1-dtb|s' /boot/uboot/uEnv.txt
That makes an appended DTB style kernel image, and results in /proc/device-tree
appending the dtb seems to work fine for a pandaboard, i've never personally had a pandaboard boot when loading the dtb separately
Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlD+/KAACgkQkSxm47BaWffdIACeMwMqcgH55FeGACEllmJVq66w IdAAn0TzGyXXQOQB78CrL3LxqQFhEwH9 =Myby -----END PGP SIGNATURE-----
Bellow is how to create an appended kernel for trimslice. This was working on the older U-Boot 2010.09-1.03-00006-ga52694f firmware.
# wget http://ausil.us/dtb/tegra20-trimslice.dtb -O /boot/tegra20-trimslice.dtb # cat /boot/vmlinuz-3.6.10-6.fc18.armv7hl.tegra /boot/tegra20-trimslice.dtb > /root/blah.zimg # mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "3.6.10-6-DTB" -d /root/blah.zimg /boot/uImage-dtb
# cat <<-EOF > /boot/boot.cmd.appended-dtb.mmc setenv bootargs console=ttyS0,115200n8 root=/dev/mmcblk0p3 ro rootwait ext2load mmc 0:1 4880000 uInitrd ext2load mmc 0:1 4080000 uImage-dtb bootm 4080000 4880000 EOF
# mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "appended-dtb 3.6.10-6" -d /boot/boot.cmd.appended-dtb.mmc /boot/boot.scr.appended-dtb.mmc # cp -f /boot/boot.scr /boot/boot.scr_before_appended # cp -f /boot/boot.scr.appended-dtb.mmc /boot/boot.scr
Not sure the old firmware used here is able to able to load a DTB. This test is nothing special, just wanted to ensure consumers of older trimslice with older firmware would somehow be able to load a DTB. Of course we might want to consider the idea of encouraging the users to update firmware.
Also this firmware provides all the memory of the device: # grep MemTotal /proc/meminfo MemTotal: 1029300 kB
On 01/22/2013 03:54 PM, Dennis Gilmore wrote:
appending the dtb seems to work fine for a pandaboard, i've never personally had a pandaboard boot when loading the dtb separately
Hi Dennis, Jon, others,
It is good to know that the append option works, however since it is not required to use a dtb on OMAP in order for it to boot both the 3.6 and the 3.7 update kernel, I would like to remind everyone that we have decided not to ship an OMAP dtb in F18 final. We can return to this later, but our focus this week must be on the immediate F18 need.
Jon.
On Tue, Jan 22, 2013 at 7:51 PM, Paul Whalen pwhalen@redhat.com wrote:
Summary of discussion from #fedora-arm
Dennis Gilmore will be creating a kernel-dtb subpackage for the 3.7 kernel, using 'make dtb' during the kernel build.
The plan is to pull in the 3.7 dtb's into our 3.6 based F18 RC1 release. We will only be including the DTB's where needed, for Trimslice and vexpress which do not boot without a DTB. The Pandaboard will boot the 3.7 without use of a DTB, and Highbank provides it's own.
For a full summary of the testing: https://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Kernel_Te...
I got time to play with the building of these today within the kernel rpms. I ran into some trouble with the way to kernels builds and the way the dtbs are generated that made the easiest way to deal with this is to package the corresponding dtbs with the matching kernel. Then having sorted that out I needed to version the directory as kernels are parallel installable.
Basically when you do a "make dtbs" it makes the dtbs that match the kernel config. So we end up with the following with the 3.7.x kernels that we have in F-18 and they're in /boot/dtb-%{uname}. Note this scheme can be tweaked but I figured getting something there to start with was better than nothing.
unified: highbank.dtb armada-370-db.dtb armada-xp-db.dtb vexpress-v2p-ca5s.dtb vexpress-v2p-ca9.dtb vexpress-v2p-ca15-tc1.dtb vexpress-v2p-ca15_a7.dtb xenvm-4.2.dtb
tegra: tegra20-harmony.dtb tegra20-medcom-wide.dtb tegra20-paz00.dtb tegra20-plutux.dtb tegra20-seaboard.dtb tegra20-tec.dtb tegra20-trimslice.dtb tegra20-ventana.dtb tegra20-whistler.dtb tegra30-cardhu-a02.dtb tegra30-cardhu-a04.dtb
omap: omap2420-h4.dtb omap3-beagle-xm.dtb omap3-evm.dtb omap3-tobi.dtb omap4-panda.dtb omap4-pandaES.dtb omap4-var_som.dtb omap4-sdp.dtb omap5-evm.dtb am335x-evm.dtb am335x-bone.dtb
kirkwood: kirkwood-dns320.dtb kirkwood-dns325.dtb kirkwood-dockstar.dtb kirkwood-dreamplug.dtb kirkwood-goflexnet.dtb kirkwood-ib62x0.dtb kirkwood-iconnect.dtb kirkwood-iomega_ix2_200.dtb kirkwood-km_kirkwood.dtb kirkwood-lschlv2.dtb kirkwood-lsxhl.dtb kirkwood-ts219-6281.dtb kirkwood-ts219-6282.dtb
Peter
On 01/27/2013 08:51 AM, Peter Robinson wrote:
Basically when you do a "make dtbs" it makes the dtbs that match the kernel config. So we end up with the following with the 3.7.x kernels that we have in F-18 and they're in /boot/dtb-%{uname}. Note this scheme can be tweaked but I figured getting something there to start with was better than nothing.
Note: This will require changes to grubby's new-kernel-pkg similar to what was necessary to run mkimage for uboot. The principle benefit of having a separate package is that the dtbs land somewhere with a consistent name, enabling grubby, boot.scr and uEnv.txt to remain static.
On Sun, Jan 27, 2013 at 7:22 PM, Brendan Conoboy blc@redhat.com wrote:
On 01/27/2013 08:51 AM, Peter Robinson wrote:
Basically when you do a "make dtbs" it makes the dtbs that match the kernel config. So we end up with the following with the 3.7.x kernels that we have in F-18 and they're in /boot/dtb-%{uname}. Note this scheme can be tweaked but I figured getting something there to start with was better than nothing.
Note: This will require changes to grubby's new-kernel-pkg similar to what was necessary to run mkimage for uboot. The principle benefit of having a separate package is that the dtbs land somewhere with a consistent name, enabling grubby, boot.scr and uEnv.txt to remain static.
grubby needs to deal with all of those because the kernel doesn't install anything into uboot, the naming scheme is the same and grubby will need to be able to deal with dtb files so I didn't see that it added any complexity because the same scheme is already being dealt with for both the kernel and the initrd.
Peter
-
Brendan Conoboy -
Dennis Gilmore -
Jon -
Jon Masters -
Paul Whalen -
Peter Robinson