Hello, Thanks guys. I found out where the problem was. Now dom0 booted more. But I have a new one. This is a kernel panic during Dom0 loading. Maybe someone is able to suggest something ?
Regards, O. [ 3.771362] sfp_register_bus: upstream ops attach [ 3.776119] sfp_register_bus: Bus registered [ 3.780459] sfp_register_socket: register sfp_bus succeeded [ 3.789399] of_cfs_init [ 3.789499] of_cfs_init: OK [ 3.791685] clk: Not disabling unused clocks [ 11.010355] SError Interrupt on CPU0, code 0xbe000000 -- SError [ 11.010380] CPU: 0 PID: 9 Comm: kworker/u4:0 Not tainted 5.15.72-xilinx-v2022.1 #1 [ 11.010393] Workqueue: events_unbound async_run_entry_fn [ 11.010414] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 11.010422] pc : simple_write_end+0xd0/0x130 [ 11.010431] lr : generic_perform_write+0x118/0x1e0 [ 11.010438] sp : ffffffc00809b910 [ 11.010441] x29: ffffffc00809b910 x28: 0000000000000000 x27: ffffffef69ba88c0 [ 11.010451] x26: 0000000000003eec x25: ffffff807515db00 x24: 0000000000000000 [ 11.010459] x23: ffffffc00809ba90 x22: 0000000002aac000 x21: ffffff807315a260 [ 11.010472] x20: 0000000000001000 x19: fffffffe02000000 x18: 0000000000000000 [ 11.010481] x17: 00000000ffffffff x16: 0000000000008000 x15: 0000000000000000 [ 11.010490] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 11.010498] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 11.010507] x8 : 0000000000000000 x7 : ffffffef693ba680 x6 : 000000002d89b700 [ 11.010515] x5 : fffffffe02000000 x4 : ffffff807315a3c8 x3 : 0000000000001000 [ 11.010524] x2 : 0000000002aab000 x1 : 0000000000000001 x0 : 0000000000000005 [ 11.010534] Kernel panic - not syncing: Asynchronous SError Interrupt [ 11.010539] CPU: 0 PID: 9 Comm: kworker/u4:0 Not tainted 5.15.72-xilinx-v2022.1 #1 [ 11.010545] Hardware name: D14 Viper Board - White Unit (DT) [ 11.010548] Workqueue: events_unbound async_run_entry_fn [ 11.010556] Call trace: [ 11.010558] dump_backtrace+0x0/0x1c4 [ 11.010567] show_stack+0x18/0x2c [ 11.010574] dump_stack_lvl+0x7c/0xa0 [ 11.010583] dump_stack+0x18/0x34 [ 11.010588] panic+0x14c/0x2f8 [ 11.010597] print_tainted+0x0/0xb0 [ 11.010606] arm64_serror_panic+0x6c/0x7c [ 11.010614] do_serror+0x28/0x60 [ 11.010621] el1h_64_error_handler+0x30/0x50 [ 11.010628] el1h_64_error+0x78/0x7c [ 11.010633] simple_write_end+0xd0/0x130 [ 11.010639] generic_perform_write+0x118/0x1e0 [ 11.010644] __generic_file_write_iter+0x138/0x1c4 [ 11.010650] generic_file_write_iter+0x78/0xd0 [ 11.010656] __kernel_write+0xfc/0x2ac [ 11.010665] kernel_write+0x88/0x160 [ 11.010673] xwrite+0x44/0x94 [ 11.010680] do_copy+0xa8/0x104 [ 11.010686] write_buffer+0x38/0x58 [ 11.010692] flush_buffer+0x4c/0xbc [ 11.010698] __gunzip+0x280/0x310 [ 11.010704] gunzip+0x1c/0x28 [ 11.010709] unpack_to_rootfs+0x170/0x2b0 [ 11.010715] do_populate_rootfs+0x80/0x164 [ 11.010722] async_run_entry_fn+0x48/0x164 [ 11.010728] process_one_work+0x1e4/0x3a0 [ 11.010736] worker_thread+0x7c/0x4c0 [ 11.010743] kthread+0x120/0x130 [ 11.010750] ret_from_fork+0x10/0x20 [ 11.010757] SMP: stopping secondary CPUs [ 11.010784] Kernel Offset: 0x2f61200000 from 0xffffffc008000000 [ 11.010788] PHYS_OFFSET: 0x0 [ 11.010790] CPU features: 0x00000401,00000842 [ 11.010795] Memory Limit: none [ 11.277509] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- пт, 21 апр. 2023 г. в 15:52, Michal Orzel <michal.or...@amd.com>: > Hi Oleg, > > On 21/04/2023 14:49, Oleg Nikitenko wrote: > > > > > > > > Hello Michal, > > > > I was not able to enable earlyprintk in the xen for now. > > I decided to choose another way. > > This is a xen's command line that I found out completely. > > > > (XEN) $$$$ console=dtuart dtuart=serial0 dom0_mem=1600M dom0_max_vcpus=2 > dom0_vcpus_pin bootscrub=0 vwfi=native sched=null timer_slop=0 > Yes, adding a printk() in Xen was also a good idea. > > > > > So you are absolutely right about a command line. > > Now I am going to find out why xen did not have the correct parameters > from the device tree. > Maybe you will find this document helpful: > > https://github.com/Xilinx/xen/blob/xlnx_rebase_4.16/docs/misc/arm/device-tree/booting.txt > > ~Michal > > > > > Regards, > > Oleg > > > > пт, 21 апр. 2023 г. в 11:16, Michal Orzel <michal.or...@amd.com <mailto: > michal.or...@amd.com>>: > > > > > > On 21/04/2023 10:04, Oleg Nikitenko wrote: > > > > > > > > > > > > Hello Michal, > > > > > > Yes, I use yocto. > > > > > > Yesterday all day long I tried to follow your suggestions. > > > I faced a problem. > > > Manually in the xen config build file I pasted the strings: > > In the .config file or in some Yocto file (listing additional > Kconfig options) added to SRC_URI? > > You shouldn't really modify .config file but if you do, you should > execute "make olddefconfig" afterwards. > > > > > > > > CONFIG_EARLY_PRINTK > > > CONFIG_EARLY_PRINTK_ZYNQMP > > > CONFIG_EARLY_UART_CHOICE_CADENCE > > I hope you added =y to them. > > > > Anyway, you have at least the following solutions: > > 1) Run bitbake xen -c menuconfig to properly set early printk > > 2) Find out how you enable other Kconfig options in your project > (e.g. CONFIG_COLORING=y that is not enabled by default) > > 3) Append the following to "xen/arch/arm/configs/arm64_defconfig": > > CONFIG_EARLY_PRINTK_ZYNQMP=y > > > > ~Michal > > > > > > > > Host hangs in build time. > > > Maybe I did not set something in the config build file ? > > > > > > Regards, > > > Oleg > > > > > > чт, 20 апр. 2023 г. в 11:57, Oleg Nikitenko <oleshiiw...@gmail.com > <mailto:oleshiiw...@gmail.com> <mailto:oleshiiw...@gmail.com <mailto: > oleshiiw...@gmail.com>>>: > > > > > > Thanks Michal, > > > > > > You gave me an idea. > > > I am going to try it today. > > > > > > Regards, > > > O. > > > > > > чт, 20 апр. 2023 г. в 11:56, Oleg Nikitenko < > oleshiiw...@gmail.com <mailto:oleshiiw...@gmail.com> <mailto: > oleshiiw...@gmail.com <mailto:oleshiiw...@gmail.com>>>: > > > > > > Thanks Stefano. > > > > > > I am going to do it today. > > > > > > Regards, > > > O. > > > > > > ср, 19 апр. 2023 г. в 23:05, Stefano Stabellini < > sstabell...@kernel.org <mailto:sstabell...@kernel.org> <mailto: > sstabell...@kernel.org <mailto:sstabell...@kernel.org>>>: > > > > > > On Wed, 19 Apr 2023, Oleg Nikitenko wrote: > > > > Hi Michal, > > > > > > > > I corrected xen's command line. > > > > Now it is > > > > xen,xen-bootargs = "console=dtuart dtuart=serial0 > dom0_mem=1600M dom0_max_vcpus=2 dom0_vcpus_pin bootscrub=0 vwfi=native > sched=null > > > > timer_slop=0 way_size=65536 xen_colors=0-3 > dom0_colors=4-7"; > > > > > > 4 colors is way too many for xen, just do > xen_colors=0-0. There is no > > > advantage in using more than 1 color for Xen. > > > > > > 4 colors is too few for dom0, if you are giving 1600M > of memory to Dom0. > > > Each color is 256M. For 1600M you should give at least > 7 colors. Try: > > > > > > xen_colors=0-0 dom0_colors=1-8 > > > > > > > > > > > > > Unfortunately the result was the same. > > > > > > > > (XEN) - Dom0 mode: Relaxed > > > > (XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID > > > > (XEN) P2M: 3 levels with order-1 root, VTCR > 0x0000000080023558 > > > > (XEN) Scheduling granularity: cpu, 1 CPU per > sched-resource > > > > (XEN) Coloring general information > > > > (XEN) Way size: 64kB > > > > (XEN) Max. number of colors available: 16 > > > > (XEN) Xen color(s): [ 0 ] > > > > (XEN) alternatives: Patching with alt table > 00000000002cc690 -> 00000000002ccc0c > > > > (XEN) Color array allocation failed for dom0 > > > > (XEN) > > > > (XEN) **************************************** > > > > (XEN) Panic on CPU 0: > > > > (XEN) Error creating domain 0 > > > > (XEN) **************************************** > > > > (XEN) > > > > (XEN) Reboot in five seconds... > > > > > > > > I am going to find out how command line arguments > passed and parsed. > > > > > > > > Regards, > > > > Oleg > > > > > > > > ср, 19 апр. 2023 г. в 11:25, Oleg Nikitenko < > oleshiiw...@gmail.com <mailto:oleshiiw...@gmail.com> <mailto: > oleshiiw...@gmail.com <mailto:oleshiiw...@gmail.com>>>: > > > > Hi Michal, > > > > > > > > You put my nose into the problem. Thank you. > > > > I am going to use your point. > > > > Let's see what happens. > > > > > > > > Regards, > > > > Oleg > > > > > > > > > > > > ср, 19 апр. 2023 г. в 10:37, Michal Orzel < > michal.or...@amd.com <mailto:michal.or...@amd.com> <mailto: > michal.or...@amd.com <mailto:michal.or...@amd.com>>>: > > > > Hi Oleg, > > > > > > > > On 19/04/2023 09:03, Oleg Nikitenko wrote: > > > > > > > > > > > > > > > > > > > > Hello Stefano, > > > > > > > > > > Thanks for the clarification. > > > > > My company uses yocto for image generation. > > > > > What kind of information do you need to > consult me in this case ? > > > > > > > > > > Maybe modules sizes/addresses which were > mentioned by @Julien Grall <mailto:jul...@xen.org <mailto:jul...@xen.org> > <mailto:jul...@xen.org <mailto:jul...@xen.org>>> ? > > > > > > > > Sorry for jumping into discussion, but FWICS > the Xen command line you provided seems to be not the one > > > > Xen booted with. The error you are observing > most likely is due to dom0 colors configuration not being > > > > specified (i.e. lack of dom0_colors=<> > parameter). Although in the command line you provided, this parameter > > > > is set, I strongly doubt that this is the > actual command line in use. > > > > > > > > You wrote: > > > > xen,xen-bootargs = "console=dtuart > dtuart=serial0 dom0_mem=1600M dom0_max_vcpus=2 dom0_vcpus_pin bootscrub=0 > vwfi=native > > > > sched=null timer_slop=0 way_szize=65536 > xen_colors=0-3 dom0_colors=4-7"; > > > > > > > > but: > > > > 1) way_szize has a typo > > > > 2) you specified 4 colors (0-3) for Xen, but > the boot log says that Xen has only one: > > > > (XEN) Xen color(s): [ 0 ] > > > > > > > > This makes me believe that no colors > configuration actually end up in command line that Xen booted with. > > > > Single color for Xen is a "default if not > specified" and way size was probably calculated by asking HW. > > > > > > > > So I would suggest to first cross-check the > command line in use. > > > > > > > > ~Michal > > > > > > > > > > > > > > > > > > Regards, > > > > > Oleg > > > > > > > > > > вт, 18 апр. 2023 г. в 20:44, Stefano > Stabellini <sstabell...@kernel.org <mailto:sstabell...@kernel.org> > <mailto:sstabell...@kernel.org <mailto:sstabell...@kernel.org>> <mailto: > sstabell...@kernel.org <mailto:sstabell...@kernel.org> <mailto: > sstabell...@kernel.org <mailto:sstabell...@kernel.org>>>>: > > > > > > > > > > On Tue, 18 Apr 2023, Oleg Nikitenko > wrote: > > > > > > Hi Julien, > > > > > > > > > > > > >> This feature has not been merged in > Xen upstream yet > > > > > > > > > > > > > would assume that upstream + the > series on the ML [1] work > > > > > > > > > > > > Please clarify this point. > > > > > > Because the two thoughts are > controversial. > > > > > > > > > > Hi Oleg, > > > > > > > > > > As Julien wrote, there is nothing > controversial. As you are aware, > > > > > Xilinx maintains a separate Xen tree > specific for Xilinx here: > > > > > https://github.com/xilinx/xen < > https://github.com/xilinx/xen> <https://github.com/xilinx/xen < > https://github.com/xilinx/xen>> <https://github.com/xilinx/xen < > https://github.com/xilinx/xen> <https://github.com/xilinx/xen < > https://github.com/xilinx/xen>>> > > > > > > > > > > and the branch you are using > (xlnx_rebase_4.16) comes from there. > > > > > > > > > > > > > > > Instead, the upstream Xen tree lives > here: > > > > > > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary < > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary> < > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary < > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary>> < > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary < > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary> < > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary < > https://xenbits.xen.org/gitweb/?p=xen.git;a=summary>>> > > > > > > > > > > > > > > > The Cache Coloring feature that you are > trying to configure is present > > > > > in xlnx_rebase_4.16, but not yet present > upstream (there is an > > > > > outstanding patch series to add cache > coloring to Xen upstream but it > > > > > hasn't been merged yet.) > > > > > > > > > > > > > > > Anyway, if you are using > xlnx_rebase_4.16 it doesn't matter too much for > > > > > you as you already have Cache Coloring > as a feature there. > > > > > > > > > > > > > > > I take you are using ImageBuilder to > generate the boot configuration? If > > > > > so, please post the ImageBuilder config > file that you are using. > > > > > > > > > > But from the boot message, it looks like > the colors configuration for > > > > > Dom0 is incorrect. > > > > > > > > > > > > > > > > > > > > > > >
