Hi Bin, 2015-12-29 14:19 GMT+08:00 Bin Meng <bmeng...@gmail.com>: > Hi Miao, > > nits: please use "x86: qemu" as the tag in the commit title. > > On Mon, Dec 28, 2015 at 5:18 PM, Miao Yan <yanmiaob...@gmail.com> wrote: >> Document the usage of 'fw' command >> >> Signed-off-by: Miao Yan <yanmiaob...@gmail.com> >> --- >> doc/README.x86 | 36 +++++++++++++++++++++++++++++++++--- >> 1 file changed, 33 insertions(+), 3 deletions(-) >> >> diff --git a/doc/README.x86 b/doc/README.x86 >> index 1271e5e..f39c157 100644 >> --- a/doc/README.x86 >> +++ b/doc/README.x86 >> @@ -295,9 +295,39 @@ show QEMU's VGA console window. Note this will disable >> QEMU's serial output. >> If you want to check both consoles, use '-serial stdio'. >> >> Multicore is also supported by QEMU via '-smp n' where n is the number of >> cores >> -to instantiate. Currently the default U-Boot built for QEMU supports 2 >> cores. >> -In order to support more cores, you need add additional cpu nodes in the >> device >> -tree and change CONFIG_MAX_CPUS accordingly. >> +to instantiate. U-Boot uses fw_cfg interface provided by QEMU to detect >> certain >> +system information, such as cpu number, so 'n' can be any number allowed by >> +QEMU. > > I've tested this. Looks when n > 47, U-Boot mp_init() will fail. I > guess we may need limit U-Boot maximum supported cpu number to some > reasonable number, say 32?
Did you see this error: error adding apic-id: FDT_ERR_NOSPACE (-3) No spaces left in dtb when there are too many cpus. I guess reserve more spaces for dtb should do. U-Boot itself should not limit the cpu number. > >> + >> +The fw_cfg interface in QEMU also provides information about kernel data, >> initrd >> +,command-line arguments and more. U-Boot supports directly accessing these >> informtion >> +from fw_cfg interface, this saves the time of loading them from hard disk or >> +network again, through emulated devices. To use it , simply providing them >> in >> +QEMU command line: >> + >> +$ qemu-system-x86_64 -nographic -bios path/to/u-boot.rom -m 1024 -kernel >> /path/to/bzImage > > Please use qemu-system-i386 for consistency with other instances > mentioned in the doc. Maybe changing them to qemu-system-x86_64 is better ? > >> + -append 'root=/dev/sda1 console=ttyS0' -initrd /path/to/initrd -smp 8 >> + >> +Note: -initrd and -smp are both optional >> + >> +Then start QEMU, in U-Boot command line use the following U-Boot command to >> setup kernel: >> + >> + => fw >> +fw - qemu firmware interface >> + >> +Usage: >> +fw <command> >> + - list : print firmware(s) currently loaded >> + - cpus : print online cpu number >> + - load <addr> : load kernel (if any) to address <addr> >> + >> +=> fw load >> +loading kernel to address 01000000, initrd 015dd010 >> + >> +Here the kernel (bzImage) is loaded to 01000000 and initrd is to 0x15dd010. >> Then, 'zboot' > > Looks 01000000 is not kernel (bzImage) address. It is setup data > address. Can we enhance the 'fw load' command to output all available > loaded components address and size? > >> +can be used to boot the kernel: >> + >> +=> zboot 01000000 - 015dd010 > > zboot has 4 parameters, the second parameter is kernel image size, > which can be zero. The last one is initrd image size, which should not > omitted. I'll have a try. Miao > > My test shows the kernel does not recognize my initramfs.gz, kernel log below: > > [ 4.328688] Unpacking initramfs... > [ 4.331688] Initramfs unpacking failed: junk in compressed archive > >> >> CPU Microcode >> ------------- >> -- > > Regards, > Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot