[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



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
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> 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>> 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>> 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>
> >     >       >
> >     >       > 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>
> >     >       >
> >     >       >
> >     >       > 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.

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.