* Single device tree blob between linux and u-boot
@ 2016-10-13 18:20 Xo Wang
2016-10-13 18:38 ` Cédric Le Goater
2016-10-13 18:41 ` Maxim Sloyko
0 siblings, 2 replies; 8+ messages in thread
From: Xo Wang @ 2016-10-13 18:20 UTC (permalink / raw)
To: OpenBMC Maillist
Hi folks,
I saw Cedric had mentioned "...you can use the linux compiled [dtb]
and dd it at the end of the u-boot
partition..."
To provide the device tree to u-boot, should we do what Cedric said
and also pass the address of the DTB from U-Boot to Linux? According
to these slides:
https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
U-Boot can pass the DTB address to Linux in r2 (p. 6) with the right
bootm command parameters.
This means we can have U-Boot and Linux use the same DTB binary (I
prefer built in Linux) rather than each source tree building one.
Then we can remove the CONFIG_ARM_APPENDED_DTB option in our Linux
build that is described as a legacy "compatibility" mechanism. We also
avoid having an extra copy of the DTSs in U-Boot source and avoid
duplicate DTBs in our image.
Thoughts?
cheers
xo
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Single device tree blob between linux and u-boot
2016-10-13 18:20 Single device tree blob between linux and u-boot Xo Wang
@ 2016-10-13 18:38 ` Cédric Le Goater
2016-10-13 18:41 ` Maxim Sloyko
1 sibling, 0 replies; 8+ messages in thread
From: Cédric Le Goater @ 2016-10-13 18:38 UTC (permalink / raw)
To: Xo Wang, OpenBMC Maillist
On 10/13/2016 08:20 PM, Xo Wang wrote:
> Hi folks,
>
> I saw Cedric had mentioned "...you can use the linux compiled [dtb]
> and dd it at the end of the u-boot
> partition..."
>
> To provide the device tree to u-boot, should we do what Cedric said
> and also pass the address of the DTB from U-Boot to Linux? According
> to these slides:
>
> https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
>
> U-Boot can pass the DTB address to Linux in r2 (p. 6) with the right
> bootm command parameters.
to see what it takes, you can tftp the dtb at some address and start
using it from uboot after telling him where it is with "fdt addr".
For linux, just add the address to bootm and boot. The main issue
I saw was the use the default kernel command line in the dtb
You will need a recompile of uboot to add fdt support. Check out my
branch.
> This means we can have U-Boot and Linux use the same DTB binary (I
> prefer built in Linux) rather than each source tree building one.
I would rather keep the dtb in Linux also.
> Then we can remove the CONFIG_ARM_APPENDED_DTB option in our Linux
> build that is described as a legacy "compatibility" mechanism. We also
> avoid having an extra copy of the DTSs in U-Boot source and avoid
> duplicate DTBs in our image.
>
> Thoughts?
It's easy to experiment, you can get all the flow working under qemu to
see the pros and cons. You just need to build your own test flash with
a couple of dd lines. There is some room before u-boot-env.
Cheers,
C.
ast# fdt addr 0x20050000
ast# fdt header
magic: 0xd00dfeed
totalsize: 0x37f3 (14323)
off_dt_struct: 0x38
off_dt_strings: 0x3610
off_mem_rsvmap: 0x28
version: 17
last_comp_version: 16
boot_cpuid_phys: 0x0
size_dt_strings: 0x1e3
size_dt_struct: 0x35d8
number mem_rsv: 0x0
ast# bootm 20080000 20300000 20050000
## Booting kernel from Legacy Image at 20080000 ...
Image Name: legoater-201610132032
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1565643 Bytes = 1.5 MiB
Load Address: 40008000
Entry Point: 40008000
## Loading init Ramdisk from Legacy Image at 20300000 ...
Image Name: legoater-201610132032
Image Type: ARM Linux RAMDisk Image (lzma compressed)
Data Size: 1567123 Bytes = 1.5 MiB
Load Address: 48000000
Entry Point: 48000000
## Flattened Device Tree blob at 20050000
Booting using the fdt blob at 0x20050000
Loading Kernel Image ... OK
Loading Ramdisk to 5ea0b000, end 5eb89993 ... OK
Loading Ramdisk to 5e88c000, end 5ea0a993 ... OK
Loading Device Tree to 5e885000, end 5e88b7f2 ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.7.3-00073-g178805942243-dirty (legoater@hermes.kaod.org) (gcc version 4.9.3 (GCC) ) #223 Thu Oct 13 19:15:31 CEST 2016
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine model: Palmetto BMC
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] SOC Rev: 02000303
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: console=ttyS4,115200 earlyprintk
...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Single device tree blob between linux and u-boot
2016-10-13 18:20 Single device tree blob between linux and u-boot Xo Wang
2016-10-13 18:38 ` Cédric Le Goater
@ 2016-10-13 18:41 ` Maxim Sloyko
2016-10-13 19:37 ` Rick Altherr
1 sibling, 1 reply; 8+ messages in thread
From: Maxim Sloyko @ 2016-10-13 18:41 UTC (permalink / raw)
To: Xo Wang; +Cc: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]
On Thu, Oct 13, 2016 at 11:20 AM, Xo Wang <xow@google.com> wrote:
> Hi folks,
>
> I saw Cedric had mentioned "...you can use the linux compiled [dtb]
> and dd it at the end of the u-boot
> partition..."
>
> To provide the device tree to u-boot, should we do what Cedric said
> and also pass the address of the DTB from U-Boot to Linux? According
> to these slides:
>
> https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-
> device-tree-dummies.pdf
>
> U-Boot can pass the DTB address to Linux in r2 (p. 6) with the right
> bootm command parameters.
>
> This means we can have U-Boot and Linux use the same DTB binary (I
> prefer built in Linux) rather than each source tree building one.
>
This introduces the dependency of U-Boot on Linux. Do we plan to keep this
dependency forever? This may be fine with OpenBMC, but what about mainline
U-Boot and Linux?
Also, are we sure that they are 100% compatible? IIRC Peter was saying that
in practice you need two different device trees for U-Boot and Linux.
>
> Then we can remove the CONFIG_ARM_APPENDED_DTB option in our Linux
> build that is described as a legacy "compatibility" mechanism. We also
> avoid having an extra copy of the DTSs in U-Boot source and avoid
> duplicate DTBs in our image.
>
> Thoughts?
>
> cheers
> xo
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
--
*M*axim *S*loyko
[-- Attachment #2: Type: text/html, Size: 2462 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Single device tree blob between linux and u-boot
2016-10-13 18:41 ` Maxim Sloyko
@ 2016-10-13 19:37 ` Rick Altherr
2016-10-13 20:58 ` Cédric Le Goater
2016-10-26 5:22 ` Joel Stanley
0 siblings, 2 replies; 8+ messages in thread
From: Rick Altherr @ 2016-10-13 19:37 UTC (permalink / raw)
To: Maxim Sloyko; +Cc: Xo Wang, OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]
I've been working on signed kernel images which depends on building FIT
images that include the kernel, initrd, and dtb. The kernel_fitimage
branch of my tree (https://github.com/kc8apf/openbmc) will build an
unsigned FIT image by including the dtb specified in the machine config
(usually from the kernel). There are also provisions in there for u-boot
being built in two stages so a control dtb that includes the public signing
keys can be combined into the final u-boot binary. From how that is
structure, I suspect Maxim is right that there will be some differences
between u-boot's dtb and linux's dtb. That shouldn't be an issue as the
u-boot dtb gets built into the u-boot image while the kernel dtb is loaded
from the FIT image.
Rick
On Thu, Oct 13, 2016 at 11:41 AM, Maxim Sloyko <maxims@google.com> wrote:
>
>
> On Thu, Oct 13, 2016 at 11:20 AM, Xo Wang <xow@google.com> wrote:
>
>> Hi folks,
>>
>> I saw Cedric had mentioned "...you can use the linux compiled [dtb]
>> and dd it at the end of the u-boot
>> partition..."
>>
>> To provide the device tree to u-boot, should we do what Cedric said
>> and also pass the address of the DTB from U-Boot to Linux? According
>> to these slides:
>>
>> https://events.linuxfoundation.org/sites/events/files/
>> slides/petazzoni-device-tree-dummies.pdf
>>
>> U-Boot can pass the DTB address to Linux in r2 (p. 6) with the right
>> bootm command parameters.
>>
>> This means we can have U-Boot and Linux use the same DTB binary (I
>> prefer built in Linux) rather than each source tree building one.
>>
>
> This introduces the dependency of U-Boot on Linux. Do we plan to keep this
> dependency forever? This may be fine with OpenBMC, but what about mainline
> U-Boot and Linux?
> Also, are we sure that they are 100% compatible? IIRC Peter was saying
> that in practice you need two different device trees for U-Boot and Linux.
>
>
>>
>> Then we can remove the CONFIG_ARM_APPENDED_DTB option in our Linux
>> build that is described as a legacy "compatibility" mechanism. We also
>> avoid having an extra copy of the DTSs in U-Boot source and avoid
>> duplicate DTBs in our image.
>>
>> Thoughts?
>>
>> cheers
>> xo
>> _______________________________________________
>> openbmc mailing list
>> openbmc@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/openbmc
>>
>
>
>
> --
> *M*axim *S*loyko
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
>
[-- Attachment #2: Type: text/html, Size: 4116 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Single device tree blob between linux and u-boot
2016-10-13 19:37 ` Rick Altherr
@ 2016-10-13 20:58 ` Cédric Le Goater
2016-10-26 5:22 ` Joel Stanley
1 sibling, 0 replies; 8+ messages in thread
From: Cédric Le Goater @ 2016-10-13 20:58 UTC (permalink / raw)
To: Rick Altherr, Maxim Sloyko; +Cc: OpenBMC Maillist
On 10/13/2016 09:37 PM, Rick Altherr wrote:
> I've been working on signed kernel images which depends on building
> FIT images that include the kernel, initrd, and dtb. The kernel_fitimage
> branch of my tree (https://github.com/kc8apf/openbmc) will build an
> unsigned FIT image by including the dtb specified in the machine config
> (usually from the kernel). There are also provisions in there for u-boot
> being built in two stages so a control dtb that includes the public signing
> keys can be combined into the final u-boot binary. From how that is structure,
> I suspect Maxim is right that there will be some differences between u-boot's
> dtb and linux's dtb. That shouldn't be an issue as the u-boot dtb gets built
> into the u-boot image while the kernel dtb is loaded from the FIT image.
No it shouldn't be too problematic.
let's get going and see what a first draft would look like. We would need
a first driver using a very minimal u-boot dtb to start with and I suppose
it will be the I2C one. Could you build a uboot tree with both so we can
experiment ?
We need to make sure that a new uboot boots an old image also.
Thanks,
C.
> Rick
>
> On Thu, Oct 13, 2016 at 11:41 AM, Maxim Sloyko <maxims@google.com <mailto:maxims@google.com>> wrote:
>
>
>
> On Thu, Oct 13, 2016 at 11:20 AM, Xo Wang <xow@google.com <mailto:xow@google.com>> wrote:
>
> Hi folks,
>
> I saw Cedric had mentioned "...you can use the linux compiled [dtb]
> and dd it at the end of the u-boot
> partition..."
>
> To provide the device tree to u-boot, should we do what Cedric said
> and also pass the address of the DTB from U-Boot to Linux? According
> to these slides:
>
> https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf <https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf>
>
> U-Boot can pass the DTB address to Linux in r2 (p. 6) with the right
> bootm command parameters.
>
> This means we can have U-Boot and Linux use the same DTB binary (I
> prefer built in Linux) rather than each source tree building one.
>
>
> This introduces the dependency of U-Boot on Linux. Do we plan to keep this dependency forever? This may be fine with OpenBMC, but what about mainline U-Boot and Linux?
> Also, are we sure that they are 100% compatible? IIRC Peter was saying that in practice you need two different device trees for U-Boot and Linux.
>
>
>
> Then we can remove the CONFIG_ARM_APPENDED_DTB option in our Linux
> build that is described as a legacy "compatibility" mechanism. We also
> avoid having an extra copy of the DTSs in U-Boot source and avoid
> duplicate DTBs in our image.
>
> Thoughts?
>
> cheers
> xo
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
> https://lists.ozlabs.org/listinfo/openbmc <https://lists.ozlabs.org/listinfo/openbmc>
>
>
>
>
> --
> *M*axim *S*loyko
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org <mailto:openbmc@lists.ozlabs.org>
> https://lists.ozlabs.org/listinfo/openbmc <https://lists.ozlabs.org/listinfo/openbmc>
>
>
>
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Single device tree blob between linux and u-boot
2016-10-13 19:37 ` Rick Altherr
2016-10-13 20:58 ` Cédric Le Goater
@ 2016-10-26 5:22 ` Joel Stanley
2016-10-26 6:39 ` Cédric Le Goater
2016-10-26 16:21 ` Rick Altherr
1 sibling, 2 replies; 8+ messages in thread
From: Joel Stanley @ 2016-10-26 5:22 UTC (permalink / raw)
To: Rick Altherr; +Cc: Maxim Sloyko, OpenBMC Maillist, Cédric Le Goater
Hey Rick,
On Fri, Oct 14, 2016 at 6:07 AM, Rick Altherr <raltherr@google.com> wrote:
> I've been working on signed kernel images which depends on building FIT
> images that include the kernel, initrd, and dtb. The kernel_fitimage branch
> of my tree (https://github.com/kc8apf/openbmc) will build an unsigned FIT
> image by including the dtb specified in the machine config (usually from the
> kernel). There are also provisions in there for u-boot being built in two
> stages so a control dtb that includes the public signing keys can be
> combined into the final u-boot binary. From how that is structure, I
> suspect Maxim is right that there will be some differences between u-boot's
> dtb and linux's dtb. That shouldn't be an issue as the u-boot dtb gets
> built into the u-boot image while the kernel dtb is loaded from the FIT
> image.
I finally got around to testing your FIT changes.
I had to build my own u-boot, as we don't have FIT support enabled. We
should make sure to add that to your patch series (in fact, we could
enable it now interdependently of the other changes).
I created an image like this:
$ dd if=/dev/zero of=flash-test bs=1M count=32
$ dd if=/home/joel/dev/u-boot/u-boot.bin of=flash-test conv=notrunc bs=1
$ dd if=/home/joel/dev/obmc/fit/fitImage-core-image-minimal-initramfs-palmetto.bin
of=flash-test conv=notrunc bs=1K seek=512
Here it is booting in Qemu:
$ qemu-system-arm -m 256M -M palmetto-bmc -nographic -nodefaults -net
nic -net user,hostfwd=:127.0.0.1:2222-:22,hostname=qemu -serial stdio
-drive file=~/dev/obmc/flash-test,format=raw,if=mtd
U-Boot 2016.11-rc2-02954-g9f82ceb7118d (Oct 26 2016 - 15:36:23 +1030)
SOC : AST2400-A0
RST : Power On
PLL : 24 MHz
CPU : 384 MHz
MEM : 0 MHz, EEC:Disable
VGA : 16 MiB
DRAM : init by SOC
Model: Palmetto BMC
DRAM: 240 MiB
WARNING: Caches not enabled
Flash: 32 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: aspeednic#0
Error: aspeednic#0 address not set.
Hit any key to stop autoboot: 0
ast# bootm 0x80000
## Loading kernel from FIT Image at 00080000 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x00080124
Data Size: 1511416 Bytes = 1.4 MiB
Architecture: ARM
OS: Linux
Load Address: 0x40008000
Entry Point: 0x40008000
Hash algo: sha1
Hash value: 1ab23fabb23234a21cd80651cd3c96a9b58a9e4c
Verifying Hash Integrity ... sha1+ OK
## Loading ramdisk from FIT Image at 00080000 ...
Using 'conf@1' configuration
Trying 'ramdisk@1' ramdisk subimage
Description: ramdisk image
Type: RAMDisk Image
Compression: uncompressed
Data Start: 0x001f62b8
Data Size: 4724736 Bytes = 4.5 MiB
Architecture: ARM
OS: Linux
Load Address: unavailable
Entry Point: unavailable
Hash algo: sha1
Hash value: 202c90e945a883ba8ff73fa4e197a17d6a9ce9f4
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 00080000 ...
Using 'conf@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x001f1210
Data Size: 20463 Bytes = 20 KiB
Architecture: ARM
Hash algo: sha1
Hash value: 63054f0970e89a70a15d1faac53fe9544a83e2e5
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x1f1210
Loading Kernel Image ... OK
Loading Ramdisk to 4e700000, end 4eb81800 ... OK
Loading Ramdisk to 4e27e000, end 4e6ff800 ... OK
Loading Device Tree to 4e276000, end 4e27dfee ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.7.10-32ede9ab3deda73c484c4e2d372863bb73d0f7e0
(joel@ka3.ozlabs.ibm.com) (gcc version 5.3.0 (GCC) ) #1 Wed Oct 26
13:57:23 AEDT 2016
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
CPU: VIVT data cache, VIVT instruction cache
Machine model: Palmetto BMC
Memory policy: Data cache writeback
SOC Rev: 02000303
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60960
Kernel command line: console=ttyS4,115200n8 root=/dev/ram rw
Looks good!
Cheers,
Joel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Single device tree blob between linux and u-boot
2016-10-26 5:22 ` Joel Stanley
@ 2016-10-26 6:39 ` Cédric Le Goater
2016-10-26 16:21 ` Rick Altherr
1 sibling, 0 replies; 8+ messages in thread
From: Cédric Le Goater @ 2016-10-26 6:39 UTC (permalink / raw)
To: Joel Stanley, Rick Altherr; +Cc: Maxim Sloyko, OpenBMC Maillist
On 10/26/2016 07:22 AM, Joel Stanley wrote:
> Hey Rick,
>
> On Fri, Oct 14, 2016 at 6:07 AM, Rick Altherr <raltherr@google.com> wrote:
>> I've been working on signed kernel images which depends on building FIT
>> images that include the kernel, initrd, and dtb. The kernel_fitimage branch
>> of my tree (https://github.com/kc8apf/openbmc) will build an unsigned FIT
>> image by including the dtb specified in the machine config (usually from the
>> kernel). There are also provisions in there for u-boot being built in two
>> stages so a control dtb that includes the public signing keys can be
>> combined into the final u-boot binary. From how that is structure, I
>> suspect Maxim is right that there will be some differences between u-boot's
>> dtb and linux's dtb. That shouldn't be an issue as the u-boot dtb gets
>> built into the u-boot image while the kernel dtb is loaded from the FIT
>> image.
>
> I finally got around to testing your FIT changes.
>
> I had to build my own u-boot, as we don't have FIT support enabled. We
> should make sure to add that to your patch series (in fact, we could
> enable it now interdependently of the other changes).
>
> I created an image like this:
>
> $ dd if=/dev/zero of=flash-test bs=1M count=32
> $ dd if=/home/joel/dev/u-boot/u-boot.bin of=flash-test conv=notrunc bs=1
> $ dd if=/home/joel/dev/obmc/fit/fitImage-core-image-minimal-initramfs-palmetto.bin
> of=flash-test conv=notrunc bs=1K seek=512
>
> Here it is booting in Qemu:
>
> $ qemu-system-arm -m 256M -M palmetto-bmc -nographic -nodefaults -net
> nic -net user,hostfwd=:127.0.0.1:2222-:22,hostname=qemu -serial stdio
> -drive file=~/dev/obmc/flash-test,format=raw,if=mtd
I just included the above in the u-boot wiki. Gavin was asking for it
for its development. I should extend a bit on the topic but I would
need to check which image to use first. This is all very custom for
the moment.
The TODO list needs an update also for the FIT image.
Thanks,
C.
>
> U-Boot 2016.11-rc2-02954-g9f82ceb7118d (Oct 26 2016 - 15:36:23 +1030)
>
> SOC : AST2400-A0
> RST : Power On
> PLL : 24 MHz
> CPU : 384 MHz
> MEM : 0 MHz, EEC:Disable
> VGA : 16 MiB
> DRAM : init by SOC
> Model: Palmetto BMC
> DRAM: 240 MiB
> WARNING: Caches not enabled
> Flash: 32 MiB
> *** Warning - bad CRC, using default environment
>
> In: serial
> Out: serial
> Err: serial
> Net: aspeednic#0
> Error: aspeednic#0 address not set.
>
> Hit any key to stop autoboot: 0
> ast# bootm 0x80000
> ## Loading kernel from FIT Image at 00080000 ...
> Using 'conf@1' configuration
> Trying 'kernel@1' kernel subimage
> Description: Linux kernel
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x00080124
> Data Size: 1511416 Bytes = 1.4 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x40008000
> Entry Point: 0x40008000
> Hash algo: sha1
> Hash value: 1ab23fabb23234a21cd80651cd3c96a9b58a9e4c
> Verifying Hash Integrity ... sha1+ OK
> ## Loading ramdisk from FIT Image at 00080000 ...
> Using 'conf@1' configuration
> Trying 'ramdisk@1' ramdisk subimage
> Description: ramdisk image
> Type: RAMDisk Image
> Compression: uncompressed
> Data Start: 0x001f62b8
> Data Size: 4724736 Bytes = 4.5 MiB
> Architecture: ARM
> OS: Linux
> Load Address: unavailable
> Entry Point: unavailable
> Hash algo: sha1
> Hash value: 202c90e945a883ba8ff73fa4e197a17d6a9ce9f4
> Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 00080000 ...
> Using 'conf@1' configuration
> Trying 'fdt@1' fdt subimage
> Description: Flattened Device Tree blob
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x001f1210
> Data Size: 20463 Bytes = 20 KiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 63054f0970e89a70a15d1faac53fe9544a83e2e5
> Verifying Hash Integrity ... sha1+ OK
> Booting using the fdt blob at 0x1f1210
> Loading Kernel Image ... OK
> Loading Ramdisk to 4e700000, end 4eb81800 ... OK
> Loading Ramdisk to 4e27e000, end 4e6ff800 ... OK
> Loading Device Tree to 4e276000, end 4e27dfee ... OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.7.10-32ede9ab3deda73c484c4e2d372863bb73d0f7e0
> (joel@ka3.ozlabs.ibm.com) (gcc version 5.3.0 (GCC) ) #1 Wed Oct 26
> 13:57:23 AEDT 2016
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
> CPU: VIVT data cache, VIVT instruction cache
> Machine model: Palmetto BMC
> Memory policy: Data cache writeback
> SOC Rev: 02000303
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60960
> Kernel command line: console=ttyS4,115200n8 root=/dev/ram rw
>
>
> Looks good!
>
> Cheers,
>
> Joel
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Single device tree blob between linux and u-boot
2016-10-26 5:22 ` Joel Stanley
2016-10-26 6:39 ` Cédric Le Goater
@ 2016-10-26 16:21 ` Rick Altherr
1 sibling, 0 replies; 8+ messages in thread
From: Rick Altherr @ 2016-10-26 16:21 UTC (permalink / raw)
To: Joel Stanley; +Cc: Maxim Sloyko, OpenBMC Maillist, Cédric Le Goater
[-- Attachment #1: Type: text/plain, Size: 5813 bytes --]
Excellent. Thank you for testing. Even though you mentioned using qemu
previously, I kept overlooking that I could do that myself.
Now the question is when and how should we switch to using FIT? Do we want
to switch all boards at once or select it on a per-board basis? At a
minimum, obmc-phosphor-image_type_uboot.bbclass needs to be refactored to
not include the initramfs directly in the flash image when using a kernel
fitImage.
I think we can safely remove the initrd segment from the flash layout on
all boards without breaking backward compatibility. Basically, initrd
would be removed from the flash layout in aspeed-bmc-opp-flash-layout.dtsi
and obmc-phosphor-image_type_uboot would stop including the build initramfs
directly in the flash image. For cuImage, we'd set INITRAMFS_IMAGE_BUNDLE
so the initrd gets built into the cuImage via the kernel's
CONFIG_INITRAMFS_SOURCE option. fitImage already bundles the initramfs as
a separate image in the FIT. As long as nothing in userspace is assuming
it can access the initramfs via mtd, everything should still work.
On Tue, Oct 25, 2016 at 10:22 PM, Joel Stanley <joel@jms.id.au> wrote:
> Hey Rick,
>
> On Fri, Oct 14, 2016 at 6:07 AM, Rick Altherr <raltherr@google.com> wrote:
> > I've been working on signed kernel images which depends on building FIT
> > images that include the kernel, initrd, and dtb. The kernel_fitimage
> branch
> > of my tree (https://github.com/kc8apf/openbmc) will build an unsigned
> FIT
> > image by including the dtb specified in the machine config (usually from
> the
> > kernel). There are also provisions in there for u-boot being built in
> two
> > stages so a control dtb that includes the public signing keys can be
> > combined into the final u-boot binary. From how that is structure, I
> > suspect Maxim is right that there will be some differences between
> u-boot's
> > dtb and linux's dtb. That shouldn't be an issue as the u-boot dtb gets
> > built into the u-boot image while the kernel dtb is loaded from the FIT
> > image.
>
> I finally got around to testing your FIT changes.
>
> I had to build my own u-boot, as we don't have FIT support enabled. We
> should make sure to add that to your patch series (in fact, we could
> enable it now interdependently of the other changes).
>
> I created an image like this:
>
> $ dd if=/dev/zero of=flash-test bs=1M count=32
> $ dd if=/home/joel/dev/u-boot/u-boot.bin of=flash-test conv=notrunc bs=1
> $ dd if=/home/joel/dev/obmc/fit/fitImage-core-image-minimal-
> initramfs-palmetto.bin
> of=flash-test conv=notrunc bs=1K seek=512
>
> Here it is booting in Qemu:
>
> $ qemu-system-arm -m 256M -M palmetto-bmc -nographic -nodefaults -net
> nic -net user,hostfwd=:127.0.0.1:2222-:22,hostname=qemu -serial stdio
> -drive file=~/dev/obmc/flash-test,format=raw,if=mtd
>
>
> U-Boot 2016.11-rc2-02954-g9f82ceb7118d (Oct 26 2016 - 15:36:23 +1030)
>
> SOC : AST2400-A0
> RST : Power On
> PLL : 24 MHz
> CPU : 384 MHz
> MEM : 0 MHz, EEC:Disable
> VGA : 16 MiB
> DRAM : init by SOC
> Model: Palmetto BMC
> DRAM: 240 MiB
> WARNING: Caches not enabled
> Flash: 32 MiB
> *** Warning - bad CRC, using default environment
>
> In: serial
> Out: serial
> Err: serial
> Net: aspeednic#0
> Error: aspeednic#0 address not set.
>
> Hit any key to stop autoboot: 0
> ast# bootm 0x80000
> ## Loading kernel from FIT Image at 00080000 ...
> Using 'conf@1' configuration
> Trying 'kernel@1' kernel subimage
> Description: Linux kernel
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x00080124
> Data Size: 1511416 Bytes = 1.4 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x40008000
> Entry Point: 0x40008000
> Hash algo: sha1
> Hash value: 1ab23fabb23234a21cd80651cd3c96a9b58a9e4c
> Verifying Hash Integrity ... sha1+ OK
> ## Loading ramdisk from FIT Image at 00080000 ...
> Using 'conf@1' configuration
> Trying 'ramdisk@1' ramdisk subimage
> Description: ramdisk image
> Type: RAMDisk Image
> Compression: uncompressed
> Data Start: 0x001f62b8
> Data Size: 4724736 Bytes = 4.5 MiB
> Architecture: ARM
> OS: Linux
> Load Address: unavailable
> Entry Point: unavailable
> Hash algo: sha1
> Hash value: 202c90e945a883ba8ff73fa4e197a17d6a9ce9f4
> Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 00080000 ...
> Using 'conf@1' configuration
> Trying 'fdt@1' fdt subimage
> Description: Flattened Device Tree blob
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x001f1210
> Data Size: 20463 Bytes = 20 KiB
> Architecture: ARM
> Hash algo: sha1
> Hash value: 63054f0970e89a70a15d1faac53fe9544a83e2e5
> Verifying Hash Integrity ... sha1+ OK
> Booting using the fdt blob at 0x1f1210
> Loading Kernel Image ... OK
> Loading Ramdisk to 4e700000, end 4eb81800 ... OK
> Loading Ramdisk to 4e27e000, end 4e6ff800 ... OK
> Loading Device Tree to 4e276000, end 4e27dfee ... OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.7.10-32ede9ab3deda73c484c4e2d372863bb73d0f7e0
> (joel@ka3.ozlabs.ibm.com) (gcc version 5.3.0 (GCC) ) #1 Wed Oct 26
> 13:57:23 AEDT 2016
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
> CPU: VIVT data cache, VIVT instruction cache
> Machine model: Palmetto BMC
> Memory policy: Data cache writeback
> SOC Rev: 02000303
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 60960
> Kernel command line: console=ttyS4,115200n8 root=/dev/ram rw
>
>
> Looks good!
>
> Cheers,
>
> Joel
>
[-- Attachment #2: Type: text/html, Size: 7242 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-10-26 16:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-13 18:20 Single device tree blob between linux and u-boot Xo Wang
2016-10-13 18:38 ` Cédric Le Goater
2016-10-13 18:41 ` Maxim Sloyko
2016-10-13 19:37 ` Rick Altherr
2016-10-13 20:58 ` Cédric Le Goater
2016-10-26 5:22 ` Joel Stanley
2016-10-26 6:39 ` Cédric Le Goater
2016-10-26 16:21 ` Rick Altherr
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.