|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Values generated by the ViryaOS uboot-script-gen do not work correctly on the Chromebook Snow
On 11/15/2023 7:07 PM, Mario Marietto wrote: > It didn't work. This is the scr file generated. > > ext2load mmc 1:3 0x51000000 zImage-6.6.0-xen-iommu-dma-on-xen > ext2load mmc 1:3 0x60000000 xen-4.17-armhf.ub When you created the xen-4.17-armhf.ub file, do you remember what the LOADADDR and entry point was? In my case those needed to be offset by 0x4000. So the uboot version of Xen would created with with the offset of 0x4000 for the LOADADDR and entry point from where the script loads it: mkimage -A arm -T kernel -C none -a 0x60004000 -e 0x60004000 -d xen-4.17-armhf xen-4.17-armhf.ub That is what has been working in my case. > ext2load mmc 1:3 0x61000000 exynos5250-snow.dtb > fdt addr 0x61000000 > fdt resize 1024 > fdt set /chosen \#address-cells <0x2> > fdt set /chosen \#size-cells <0x2> > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 dom0_mem=768 > dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null" > fdt mknod /chosen dom0 > fdt set /chosen/dom0 compatible "xen,linux-zimage" "xen,multiboot-module" > "multiboot,module" > fdt set /chosen/dom0 reg <0x0 0x51000000 0x0 0x87C200 > > fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen earlyprintk=xen > root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused" > setenv fdt_high 0xffffffffffffffff > bootm 0x60000000 - 0x61000000 > > So,I ran : > > bash /boot/./uboot-script-gen -c /boot/xen-config -d . > > it says : > > Image Name: > Created: Wed Nov 15 23:55:40 2023 > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 884744 Bytes = 864.01 KiB = 0.84 MiB > Load Address: 60000000 > Entry Point: 60000000 > Generated uboot script xen-stef.scr, to be loaded at address 0x42000000: > ext2load mmc 1:3 0x42000000 xen-stef.scr; source 0x42000000 > > ok,I've booted xen with the suggested address : > > ext2load mmc 1:3 0x42000000 xen-stef.scr; source 0x42000000 > > but it rebooted to the verification screen. > > NB : I have applied both your suggestions (offset + your new start and end > memory address. Maybe they auto exclude each other ?) > > On Thu, Nov 16, 2023 at 12:49 AM Stefano Stabellini <sstabellini@xxxxxxxxxx > <mailto:sstabellini@xxxxxxxxxx>> wrote: > > On Wed, 15 Nov 2023, Chuck Zmudzinski wrote: > > On 11/14/2023 6:43 PM, Mario Marietto wrote: > > > I hope that the informations below are correct : > > > > I don't know that they are correct. I have not spent the necessary time > to > > determine what the correct values for MEMORY_START and MEMORY_END are > for > > the Chromebook we are using. I just presumed, probably incorrectly, that > > the entire 2 GB memory is safe, but obviously that is not the case with > > this Chromebook. Most likely, it requires a good understanding of the > > particular way booting is done on a Chromebook, which seems to be > different > > from other devices. > > > > I plan to eventually look into finding values for MEMORY_START and > MEMORY_END > > sothe uboot-script-gen script computes usable values for loading Xen > and dom0 > > on this Chromebook in the script, but I might not get to that task > immediately. > > I plan to look at it within the next week or so. > > A couple of suggestions. I noticed that the addresses you chose have a > higher alignment compared to the one chosen by Imagebuilder. > Imagebuilder uses 2MB: > > offset=$((2*1024*1024)) > > I would think that a 2MB alignment should be sufficient, but you can > increase the alignment chosen by Imagebuilder simply by changing > "offset" at the top of uboot-script-gen. You seem to be used a 240MB > offset: > > offset=$((240*1024*1024)) > > The other suggestion is about MEMORY_START and MEMORY_END. Looking at > the addresses you picked by hand, the following you should give you very > similar results: > > MEMORY_START=0x33000000 > MEMORY_END=0x80000000 > > > > > - the imagebuilder config file : > > > > > > MEMORY_START="0x0" > > > MEMORY_END="0x80000000" > > > LOAD_CMD="ext2load mmc 1:3" > > > BOOT_CMD="bootm" > > > DEVICE_TREE="exynos5250-snow.dtb" > > > XEN="xen-4.17-armhf" > > > XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=1152M > dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null" > > > DOM0_KERNEL="zImage-6.6.0-xen-iommu-dma-on-xen" > > > DOM0_CMD="console=tty earlycon=xen earlyprintk=xen > root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused" > > > UBOOT_SOURCE="xen.source" > > > UBOOT_SCRIPT="xen.scr" > > > > > > xen.source : (that does not work) > > > > > > mmc dev 1 > > > ext2load mmc 1:3 0xE00000 zImage-6.6.0-xen-iommu-dma-on-xen > > > ext2load mmc 1:3 0x1800000 xen-4.17-armhf.ub > > > ext2load mmc 1:3 0x1A00000 exynos5250-snow.dtb > > > fdt addr 0x1A00000 > > > fdt resize 1024 > > > fdt set /chosen \#address-cells <0x2> > > > fdt set /chosen \#size-cells <0x2> > > > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 > dom0_mem=1152M dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null" > > > fdt mknod /chosen dom0 > > > fdt set /chosen/dom0 compatible "xen,linux-zimage" > "xen,multiboot-module" "multiboot,module" > > > fdt set /chosen/dom0 reg <0x0 0xE00000 0x0 0x87C200 > > > > fdt set /chosen xen,dom0-bootargs "console=tty earlycon=xen > earlyprintk=xen root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused" > > > setenv fdt_high 0xffffffffffffffff > > > bootm 0x1800000 - 0x1A00000 > > > > > > xen.source : (created by chuck and that works) > > > > > > mmc dev 1 > > > ext2load mmc 1:3 0x42000000 zImage-6.6.0-xen-iommu-dma-on-xen > > > ext2load mmc 1:3 0x51000000 xen-4.17-armhf-armmp-0x51004000.ub > > > ext2load mmc 1:3 0x5ffec000 exynos5250-snow.dtb > > > fdt addr 0x5ffec000 > > > fdt resize 1024 > > > fdt set /chosen \#address-cells <0x2> > > > fdt set /chosen \#size-cells <0x2> > > > fdt set /chosen xen,xen-bootargs "console=dtuart dtuart=serial0 > dom0_mem=1152M dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null" > > > fdt mknod /chosen dom0 > > > fdt set /chosen/dom0 compatible "xen,linux-zimage" > "xen,multiboot-module" "multiboot,module" > > > fdt set /chosen/dom0 reg <0x0 0x42000000 0x0 0x87C200 > > > > fdt set /chosen xen,dom0-bootargs "console=tty1 root=/dev/mmcblk1p4 > rw rootwait clk_ignore_unused --no-log" > > > bootm 0x51000000 - 0x5ffec000 > > > > > > all the values that you see in this conf. files have been calculated > by chuck by hand,because the values generated by the imagebuilder are wrong. > The only value that's well calculated by the imagebuilder is 0x87C200 > > > > > > - the size of all the binaries specified in the imagebuilder config > file : > > > > > > exynos5250-snow.dtb = 46.6 KiB (47,769 byte) > > > zImage-6.6.0-xen-iommu-dma-on-xen = 8.5 MiB (8,897,024 byte) > > > > > > > > > > > > On Wed, Nov 15, 2023 at 12:17 AM Stefano Stabellini > <sstabellini@xxxxxxxxxx <mailto:sstabellini@xxxxxxxxxx> > <mailto:sstabellini@xxxxxxxxxx <mailto:sstabellini@xxxxxxxxxx>>> wrote: > > > > > > Hi Mario, > > > > > > I think we misunderstood each other :-) > > > > > > MEMORY_START-MEMORY_END is not supposed to be computed: it is > supposed > > > to come from the memory node in device tree tree (/memory) of the > > > platform. The idea is that you should not have to do any > computations, > > > but only reuse the same address range specified there. > > > > > > Similarly in regards to "please post the size of all the > binaries", > > > this is just for debugging, so that I can see if there are any > bugs with > > > uboot-script-gen. I cannot debug the script unless I figure out > what the > > > problem is and the only way I can do that is with the binary > sizes and > > > redoing all the steps by hand. > > > > > > The expected outcome is that once we resolve the problem you > should be > > > able to use uboot-script-gen without any additional computation > needed. > > > > > > Of course using static values is also OK. > > > > > > > > > On Wed, 15 Nov 2023, Mario Marietto wrote: > > > > ---> uboot-script-gen assumes that the memory range specified > by MEMORY_START-MEMORY_END is valid and correct. > > > > > > > > Actually Chuck chose 0 as MEMORY_START and 0x800000 as > MEMORY_END and these are stable values,they don't change. If you ask me to > calculate > > > > those values,it means that we need to compute these values. I > imagine that to calculate these values is not easy. > > > > > > > > ---> To debug this kind of issues please post the size of all > the binaries specified in the imagebuilder config file > > > > > > > > I imagine that I should also calculate those values. And > again,I see a complication. > > > > > > > > I'm realizing that the method used by Chuck is easier because > he uses stable values. In the end,there aren't any calculations to do and > > > > since I'm looking for an easier method,not a more complicated > one,I think that Chuck's method is good as is. > > > > > > > > On Tue, Nov 14, 2023 at 11:51 PM Stefano Stabellini > <sstabellini@xxxxxxxxxx <mailto:sstabellini@xxxxxxxxxx> > <mailto:sstabellini@xxxxxxxxxx <mailto:sstabellini@xxxxxxxxxx>>> wrote: > > > > Hi Mario, > > > > > > > > It is difficult to know how to change uboot-script-gen if > we don't know > > > > why it is currently going wrong. > > > > > > > > uboot-script-gen assumes that the memory range specified > by > > > > MEMORY_START-MEMORY_END is valid and correct. > > > > > > > > So if you specified a valid and correct memory range in > your config file > > > > (0x41e00000-0x60000000) why is it failing? > > > > > > > > The only thing uboot-script-gen does is choosing aligned > addresses > > > > within the MEMORY_START-MEMORY_END range. The addresses > are supposed not > > > > to overlap (meaning the initrd will not overwrite part of > the kernel > > > > when loaded). If the issue is a bug in uboot-script-gen, > such as the > > > > generated addresses overlap or they are not aligned, then > we can fix the > > > > alignment or overlap bug. To debug this kind of issues > please post: > > > > - the imagebuilder config file > > > > - the generate boot.source script > > > > - the size of all the binaries specified in the > imagebuilder config file > > > > > > > > On the other hand if 0x41e00000-0x60000000 is not a safe > memory range to > > > > use, then you need to specify a different memory range. > > > > > > > > Cheers, > > > > > > > > Stefano > > > > > > > > > > > > > > > > On Mon, 13 Nov 2023, Mario Marietto wrote: > > > > > Hello. > > > > > > > > > > I'm trying to find an easier way to the problem that > you can read here : > > > > > > > > > > > https://github.com/mobile-virt/u-boot-chromebook-xe303c12/tree/chromebook/xen#starting-a-domu-guest > > <https://github.com/mobile-virt/u-boot-chromebook-xe303c12/tree/chromebook/xen#starting-a-domu-guest> > > <https://github.com/mobile-virt/u-boot-chromebook-xe303c12/tree/chromebook/xen#starting-a-domu-guest > > <https://github.com/mobile-virt/u-boot-chromebook-xe303c12/tree/chromebook/xen#starting-a-domu-guest>> > > > > > > > > > > where Chuck says : > > > > > > > > > > 6. Create the u-boot shell commands that will be used > to boot Xen and dom0. > > > > > > > > > > Create a file in /home/user (or any other directory) > named bootxen.source with these contents : > > > > > > > > > > > > > > > mmc dev 1 && mmc rescan 1 > > > > > ext2load mmc 1:3 0x42000000 zImage-6.1.61-stb-xen-cbe+ > > > > > ext2load mmc 1:3 0x51000000 > xen-4.17-armhf-armmp-0x51004000.ub > > > > > ext2load mmc 1:3 0x5ffec000 > exynos5250-snow-6.1.61-stb-xen-cbe+.dtb > > > > > fdt addr 0x5ffec000 > > > > > fdt resize 1024 > > > > > fdt set /chosen \#address-cells <0x2> > > > > > fdt set /chosen \#size-cells <0x2> > > > > > fdt set /chosen xen,xen-bootargs "console=dtuart > dtuart=serial0 dom0_mem=1G dom0_max_vcpus=2 bootscrub=0 vwfi=native" > > > > > fdt mknod /chosen dom0 > > > > > fdt set /chosen/dom0 compatible "xen,linux-zimage" > "xen,multiboot-module" "multiboot,module" > > > > > fdt set /chosen/dom0 reg <0x0 0x42000000 0x0 0x7D7200 > > > > > > fdt set /chosen xen,dom0-bootargs "console=tty1 > root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused" > > > > > bootm 0x51000000 - 0x5ffec000 > > > > > > > > > > The hex value 0x7D7200 is the size of the > zImage-6.1.61-stb-xen-cbe+ file, and that value is computed from the > > > > uboot-script-gen script > > > > > available from here : > > > > > > > > > > > > > > > https://gitlab.com/ViryaOS/imagebuilder > <https://gitlab.com/ViryaOS/imagebuilder> > <https://gitlab.com/ViryaOS/imagebuilder > <https://gitlab.com/ViryaOS/imagebuilder>> > > > > > > > > > > > > > > > This is the interesting point : > > > > > > > > > > > > > > > Please note that most of the other values in the script > generated by the ViryaOS uboot-script-gen do not work correctly with > > > > the Chromebook > > > > > Snow, but the script does correctly calculate the size > of the dom0 Linux kernel image. > > > > > > > > > > > > > > > Some time ago Stefano suggested to put the values below > for MEMORY_START and MEMORY_END inside the xen-config file : > > > > > > > > > > > > > > > nano xen-config file : > > > > > > > > > > > > > > > MEMORY_START="0x41e00000" > > > > > MEMORY_END="0x60000000" > > > > > LOAD_CMD="ext2load mmc 1:3" > > > > > BOOT_CMD="bootm" > > > > > DEVICE_TREE="exynos5250-snow.dtb" > > > > > XEN="xen-4.17-armhf" > > > > > XEN_CMD="console=dtuart dtuart=serial0 dom0_mem=768M > dom0_max_vcpus=2 bootscrub=0 vwfi=native sched=null" > > > > > DOM0_KERNEL="zImage-6.6.0-xen-dma-mapping" > > > > > DOM0_CMD="console=tty earlycon=xen earlyprintk=xen > root=/dev/mmcblk1p4 rw rootwait clk_ignore_unused" > > > > > UBOOT_SOURCE="xen.source" > > > > > > > > > > > > > > > bash ./uboot-script-gen -c xen-config -d . > > > > > > > > > > > > > > > Image Name: > > > > > Created: Thu Nov 2 20:59:24 2023 > > > > > Image Type: ARM Linux Kernel Image (uncompressed) > > > > > Data Size: 884744 Bytes = 864.01 KiB = 0.84 MiB > > > > > Load Address: 42c00000 > > > > > Entry Point: 42c00000 > > > > > > > > > > > > > > > Generated uboot script xen.scr, to be loaded at address > 0x42000000: > > > > > ext2load mmc 1:3 0x42000000 xen.scr; source 0x42000000 > > > > > > > > > > > > > > > and I tried to boot Xen and Linux 6.6 as dom0 : > > > > > > > > > > SMDK5250 # mmc dev 1 > > > > > SMDK5250 # ext2load mmc 1:3 0x42000000 xen.scr; source > 0x42000000 > > > > > but it did not work : it reboots on the verification > screen. > > > > > > > > > > -- > > > > > Mario. > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Mario. > > > > > > > > > > > > > > > > > > > > -- > > > Mario. > > > > > > -- > Mario.
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |