[U-Boot] Booting linux zImage on vexpress-a15

Andre Wagner andre.wagner at richard-wolf.com
Fri Feb 8 14:30:51 UTC 2019


Hi Liviu,

I got the qemu + uboot + zImage running now! The solution was to use 
qemu version 3.1 like you and not the ancient 2.11 version of Ubuntu 
18.04. Thank you very much for your support. I was completely lost in 
the debugging of linux, qemu and u-boot...


Greetings,

André


On 07.02.19 15:40, Liviu Dudau wrote:
> On Thu, Feb 07, 2019 at 01:55:00PM +0100, Andre Wagner wrote:
>> Hi Liviu,
>>
>> thank you very much for your reply. A very good hint was that I need to set
>> the extra kernel parameter earlyprintk for showing further debug output. I
>> expected that setting the 'Early Printk' option in Kconfig is enough. After
>> adding this kernel parameter i can see the kernel boot messages, but the
>> kernel stucks now at 'smp: Bringing up secondary CPUs ...'. As a cross-check
>> I booted the kernel directly on the qemu vexpress machine and there are also
>> error messages at the SMP step shown, but the boot process continues. In the
>> running system I can only see one CPU, so SMP does not work at all. So I
>> disabled all CPUs expect the first one in the device tree, so my boot
>> procedure in u-boot is as following:
>>
>> 1. Set boot args: setenv bootargs console=ttyAMA0 earlyprintk debug verbose
> May I suggest you use
>
>     $ setenv bootargs 'console=ttyAMA0 earlyprintk debug verbose'
>
> i.e. put single quotes around the value of the variable.
>
>> 2. Load the zImage at start of RAM + 8000h offset: ext4load mmc 0:1 80008000
>> zImage
>>
>> 3. Load Device Tree: ext4load mmc 0:1 8a000000 vexpress-v2p-ca15-tc1.dtb
>>
>> 4. Init fdt subsystem: fdt addr 8a000000
> In my test with mainline kernel and U-Boot from yesterday I didn't had to do
> this, because ....
>
>> 5. Deactivate second CPU:  fdt rm /cpus/cpu at 1
> I didn't have to disable the other CPUs either.
>
>
>> 6. Boot with bootz command: bootz 80008000 - 8a000000
>>
>> 7. In the SMP boot step only one CPU it recognized, the boot process
>> continues
>>
>> 8. Now the boot process stucks at 'DMA: preallocated 256 KiB pool for atomic
>> coherent allocations'
>>
>>
>> Further I found that:
>>
>> 1. The space between kernel loadaddr and DTB load address of 2ff8000h Bytes
>> (about 50MB) was big enough, since there is no difference if I use the old
>> (85000000h) or the new DTB loadaddr (8a000000h). Just for being on the sure
>> site I continue using 8a000000 for DTB load address
>>
>> 2. All vexpress DTBs contain a ARM HBI number with seems to be a
>> identificator for the ARM board. The ARM HBI of vexpress-v2p-ca15-tc1.dtb
>> fits the expected ARM HBI of the qemu vexpress-a15, the
>> vexpress-v2p-ca15_a7.dtb fits not. So I keep using the
>> vexpress-v2p-ca15-tc1.dtb device tree
> Like I've said, those dtbs are for real hardware CoreTiles placed inside the
> Versatile Express motherboard. I don't know (or remember exactly) if qemu
> emulates all the aspects, but it should not matter much.
>
>> 3. I recompiled the vexpress-v2p-ca15-tc1.dtb device tree without the
>> /cpus/cpu at 1 and let it run directly by qemu. The boot process succeeds. The
>> next message after 'DMA: preallocated 256 KiB pool for atomic coherent
>> allocations' is in this case 'cpuidle: using governor ladder'
>>
>> 4. I didn't mentioned the versions I'm using: It's qemu version
>> 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.8), Linux version 5.0.0-rc5 and U-Boot
>> version 2019.01-00523-ge5fd39c886. I'm aware that these are development
>> versions.
> My versions are qemu 3.1.0, U-Boot 2019.01-00058-g23b00a07fc-dirty,
> Linux version 5.0.0-rc5+. Attached is a log of my session.
>
> Best regards,
> Liviu
>
>>
>> At this point I assume that kernel and DTB are loaded correctly, but I
>> haven't any idea what influence u-boot can have initializing DMA and/or
>> cpuidle. Any suggestions?
>>
>>
>> P.S. I will continue testing other stable vanilla kernels.
>>
>> P.S. I attached the boot logs: The file boot_qemu_only is the successful
>> boot with qemu only via kernel and dtb option, the file boot_qemu_uboot is
>> the boot with qemu + u-boot.
>>
>>
>> Thanks for your help.
>>
>> Greetings,
>>
>> André
>>
>>
>>
>>
>> On 06.02.19 17:58, Liviu Dudau wrote:
>>> On Tue, Feb 05, 2019 at 07:05:55PM +0100, Andre Wagner wrote:
>>>> Hi @all,
>>> Hi Andre,
>>>
>>>> I'm trying to build a linux kernel as zImage and boot it with u-boot on a
>>>> qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04.
>>>>
>>>> What I tried until now:
>>>>
>>>> 1. Get Linux from git, export ARCH=arm and
>>>> CROSS_COMPILE=arm-linux-gnueabihf-
>>>>
>>>> 2. Make Defconfig: make vexpress_defconfig
>>>>
>>>> 3. Enable 'Early Printk' with make menuconfig
>>>>
>>>> 4. Make Kernel: make
>>>>
>>>> 5. Get U-Boot from git, export ARCH=arm and
>>>> CROSS_COMPILE=arm-linux-gnueabihf-
>>>>
>>>> 6. Make Defconfig: make vexpress_ca15_tc2_defconfig
>>>>
>>>> 7. Make U-Boot: make
>>>>
>>>> 8. Generate empty image file and mount it: truncate -s 100M image; mkfs.ext4
>>>> image; mount -o loop image /mnt
>>>>
>>>> 9. Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp
>>>> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt
>>>>
>>>> 10. Unmount Image: umount /mnt
>>>>
>>>> 11. Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu
>>>> cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I
>>>> can hit a key to stop automount, ok so far
>>>>
>>>> 12. In u-boot, checking filesystem on image: ext4ls mmc 0:0 => I can see my
>>>> zImage and my DTB file, ok so far
>>>>
>>>> 13. In u-boot, loading kernel: ext4load mmc 0:0 82008000 zImage => XXXX
>>>> bytes read is shown, ok so far
>>>>
>>>> 14. In u-boot, loading DTB: ext4load mmc 0:0 85000000
>>>> vexpress-v2p-ca15_a7.dtb => YYYY bytes read, ok so far
>>>>
>>>> 15. In u-boot, boot: bootz 82008000 - 85000000 => 'Starting kernel ....' and
>>>> 'Uncompressing kernel done' is shown and then nothing at all...
>>> I think your problem is that you're putting the device tree too close to the
>>> kernel, so it might be trampled on by the kernel decompression.
>>>
>>> Steps I suggest you try that worked in my environment:
>>>
>>>     1. set the bootargs variable in U-Boot to 'console=ttyAMA0 earlyprintk debug verbose'
>>>     2. Load the kernel at 0x80008000
>>>
>>>> Cross-checks I have done right now:
>>>>
>>>> - Booting kernel and DTB directly from qemu with 'qemu-system-arm -m 1024M
>>>> -M vexpress-a15 -cpu cortex-a15 -kernel arch/arm/boot/zImage  -dtb
>>>> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -serial stdio' works, normal
>>>> boot output is shown. Also the standard console device ttyAMA0 is available
>>>> after mounting devtmpfs.
>>>>
>>>> - Same setup with vexpress-a9  (uboot with vexpress_ca9x4_defconfig, linux
>>>> with vexpress_defconfig and DTB vexpress-v2p-ca9.dtb. The kernel was loaded
>>>> to 62008000 and the DTB to 65000000) worked, Normal boot output was shown.
>>>>
>>>>
>>>> What I don't understand right now is:
>>>>
>>>> - Am I using the corrected DTB? vexpress-v2p-ca15-tc1.dtb or
>>>> vexpress-v2p-ca15_a7.dtb ? Which is the right one?
>>> None is the right one, as they are DTBs for actual hardware that QEMU doesn't
>>> emulate correctly with your parameters. However, the emulation should be close
>>> enough to allow you to boot the kernel.
>>>
>>>> - What are the addresses I need to load kernel and the DTB? In the working
>>>> vexpress-a9 sample the kernel was loaded with a offset of 2008000h and the
>>>> DTB with a offset of 5000000h to start of RAM at 60000000h. So I decided use
>>>> the same offsets with the alternate start of RAM address of 8000000h of
>>>> vexpress-a15, i.e. kernel at 82008000 and DTB at 85000000. Is this
>>>> assumption correct?
>>> No, the offset should be 0x8000 from the start of your memory, because the kernel
>>> for arm arch expects to be loaded at the beginning of the RAM. For DTB it doesn't
>>> matter (other than probably faster if it is 32bit aligned).
>>>
>>>> - 'Starting kernel...' is a last message from u-boot and 'Uncompressing
>>>> kernel done' the first from the kernels self extractor?
>>> Correct.
>>>
>>>> - Where in RAM is the zImage decompressed by u-boot bootz? Between start of
>>>> RAM at 80000000h and kernels loadaddr at 82008000h?
>>> I might be wrong but I believe it decompresses in memory *after* the kernel image,
>>> not before (otherwise the decompression might generate an image that overwrites
>>>    the start of the kernel, which is where the decompressor lives).
>>>
>>>> - What are the differences between loading kernel and DTB by qemu directly
>>>> and loading kernel and DTB indirectly via u-boot?
>>> Placement in memory of the kernel image :)
>>>
>>> Best regards,
>>> Liviu
>>>
>>>> Thank you very very much for your replies in advance.
>>>>
>>>>
>>>> Greetings,
>>>>
>>>> André
>>>>
>>>>
>>>> +++
>>>> Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen
>>>> Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register:
>>>> Mannheim HRB 510031 +++
>>>> Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately.
>>>> +++
>>>> _______________________________________________
>>>> U-Boot mailing list
>>>> U-Boot at lists.denx.de
>>>> https://lists.denx.de/listinfo/u-boot
>> +++
>> Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen
>> Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register:
>> Mannheim HRB 510031 +++
>> Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately.
>> +++
>> Booting Linux on physical CPU 0x0
>> Linux version 5.0.0-rc5 (wagner at wagner-Precision-3510) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #1 SMP Tue Feb 5 17:09:25 CET 2019
>> CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
>> CPU: div instructions available: patching division code
>> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
>> OF: fdt: Machine model: V2P-CA15
>> Memory policy: Data cache writealloc
>> Reserved memory: created DMA memory pool at 0x18000000, size 8 MiB
>> OF: reserved mem: initialized node vram at 18000000, compatible id shared-dma-pool
>> cma: Reserved 16 MiB at 0xbf000000
>> random: get_random_bytes called from start_kernel+0x9c/0x458 with crng_init=0
>> percpu: Embedded 17 pages/cpu @(ptrval) s37196 r8192 d24244 u69632
>> Built 1 zonelists, mobility grouping on.  Total pages: 260096
>> Kernel command line: root=/dev/mmcblk0p1 console=ttyAMA0,9600
>> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> Memory: 1012188K/1048576K available (7168K kernel code, 420K rwdata, 1572K rodata, 1024K init, 158K bss, 20004K reserved, 16384K cma-reserved)
>> Virtual kernel memory layout:
>>      vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>      fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
>>      vmalloc : 0xc0800000 - 0xff800000   (1008 MB)
>>      lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>      modules : 0x7f000000 - 0x80000000   (  16 MB)
>>        .text : 0x(ptrval) - 0x(ptrval)   (8160 kB)
>>        .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
>>        .data : 0x(ptrval) - 0x(ptrval)   ( 421 kB)
>>         .bss : 0x(ptrval) - 0x(ptrval)   ( 159 kB)
>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> rcu: Hierarchical RCU implementation.
>> rcu: 	RCU event tracing is enabled.
>> rcu: 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
>> rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
>> rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
>> NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
>> clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
>> Failed to initialize '/smb at 8000000/motherboard/iofpga at 3,00000000/timer at 120000': -22
>> arch_timer: cp15 timer(s) running at 62.50MHz (virt).
>> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
>> sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
>> Switching to timer-based delay loop, resolution 16ns
>> Console: colour dummy device 80x30
>> Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
>> pid_max: default: 32768 minimum: 301
>> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> CPU: Testing write buffer coherency: ok
>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
>> /cpus/cpu at 0 missing clock-frequency property
>> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> Setting up static identity map for 0x80100000 - 0x80100060
>> rcu: Hierarchical SRCU implementation.
>> smp: Bringing up secondary CPUs ...
>> smp: Brought up 1 node, 1 CPU
>> SMP: Total of 1 processors activated (125.00 BogoMIPS).
>> CPU: All CPU(s) started in SVC mode.
>> devtmpfs: initialized
>> VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
>> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
>> futex hash table entries: 256 (order: 2, 16384 bytes)
>> NET: Registered protocol family 16
>> DMA: preallocated 256 KiB pool for atomic coherent allocations
>> cpuidle: using governor ladder
>> hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
>> hw-breakpoint: maximum watchpoint size is 8 bytes.
>> Serial: AMBA PL011 UART driver
>> 1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 33, base_baud = 0) is a PL011 rev1
>> printk: console [ttyAMA0] enabled
>> 1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 34, base_baud = 0) is a PL011 rev1
>> 1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 35, base_baud = 0) is a PL011 rev1
>> 1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 36, base_baud = 0) is a PL011 rev1
>> OF: amba_device_add() failed (-19) for /smb at 8000000/motherboard/iofpga at 3,00000000/wdt at f0000
>> OF: amba_device_add() failed (-19) for /memory-controller at 2b0a0000
>> OF: amba_device_add() failed (-19) for /memory-controller at 7ffd0000
>> OF: amba_device_add() failed (-19) for /dma at 7ffb0000
>> SCSI subsystem initialized
>> usbcore: registered new interface driver usbfs
>> usbcore: registered new interface driver hub
>> usbcore: registered new device driver usb
>> Advanced Linux Sound Architecture Driver Initialized.
>> clocksource: Switched to clocksource arch_sys_counter
>> NET: Registered protocol family 2
>> tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes)
>> TCP established hash table entries: 8192 (order: 3, 32768 bytes)
>> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
>> TCP: Hash tables configured (established 8192 bind 8192)
>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>> NET: Registered protocol family 1
>> RPC: Registered named UNIX socket transport module.
>> RPC: Registered udp transport module.
>> RPC: Registered tcp transport module.
>> RPC: Registered tcp NFSv4.1 backchannel transport module.
>> hw perfevents: enabled with armv7_cortex_a15 PMU driver, 1 counters available
>> workingset: timestamp_bits=30 max_order=18 bucket_order=0
>> squashfs: version 4.0 (2009/01/31) Phillip Lougher
>> jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
>> 9p: Installing v9fs 9p2000 file system support
>> io scheduler mq-deadline registered
>> io scheduler kyber registered
>> drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram at 18000000
>> drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory
>> drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111
>> drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD
>> physmap-flash 8000000.flash: physmap platform flash device: [mem 0x08000000-0x0bffffff]
>> 8000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000
>> Intel/Sharp Extended Query Table at 0x0031
>> Using buffer write method
>> physmap-flash 8000000.flash: physmap platform flash device: [mem 0x0c000000-0x0fffffff]
>> 8000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000
>> Intel/Sharp Extended Query Table at 0x0031
>> Using buffer write method
>> Concatenating MTD devices:
>> (0): "8000000.flash"
>> (1): "8000000.flash"
>> into device "8000000.flash"
>> physmap-flash 14000000.psram: physmap platform flash device: [mem 0x14000000-0x15ffffff]
>> libphy: Fixed MDIO Bus: probed
>> smsc911x 1a000000.ethernet: Linked as a consumer to regulator.1
>> libphy: smsc911x-mdio: probed
>> smsc911x 1a000000.ethernet eth0: MAC Address: 52:54:00:12:34:56
>> isp1760 1b000000.usb: bus width: 32, oc: digital
>> isp1760 1b000000.usb: NXP ISP1760 USB Host Controller
>> isp1760 1b000000.usb: new USB bus registered, assigned bus number 1
>> isp1760 1b000000.usb: Scratch test failed.
>> isp1760 1b000000.usb: can't setup: -19
>> isp1760 1b000000.usb: USB bus 1 deregistered
>> usbcore: registered new interface driver usb-storage
>> rtc-pl031 1c170000.rtc: registered as rtc0
>> mmci-pl18x 1c050000.mmci: Got CD GPIO
>> mmci-pl18x 1c050000.mmci: Got WP GPIO
>> mmci-pl18x 1c050000.mmci: Linked as a consumer to regulator.1
>> mmci-pl18x 1c050000.mmci: mmc0: PL181 manf 41 rev0 at 0x1c050000 irq 29,30 (pio)
>> ledtrig-cpu: registered to indicate activity on CPUs
>> usbcore: registered new interface driver usbhid
>> usbhid: USB HID core driver
>> aaci-pl041 1c040000.aaci: ARM AC'97 Interface PL041 rev0 at 0x1c040000, irq 28
>> aaci-pl041 1c040000.aaci: FIFO 512 entries
>> oprofile: using timer interrupt.
>> NET: Registered protocol family 17
>> 9pnet: Installing 9P2000 support
>> Registering SWP/SWPB emulation handler
>> input: AT Raw Set 2 keyboard as /devices/platform/smb at 8000000/smb at 8000000:motherboard/smb at 8000000:motherboard:iofpga at 3,00000000/1c060000.kmi/serio0/input/input0
>> mmc0: new SD card at address 4567
>> mmcblk0: mmc0:4567 QEMU! 1.00 GiB
>> drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram at 18000000
>> drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory
>> Error: Driver 'vexpress-muxfpga' is already registered, aborting...
>> drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111
>> drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD
>>   mmcblk0: p1
>> drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram at 18000000
>> drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory
>> Error: Driver 'vexpress-muxfpga' is already registered, aborting...
>> drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111
>> drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD
>> drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram at 18000000
>> drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory
>> Error: Driver 'vexpress-muxfpga' is already registered, aborting...
>> drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111
>> drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD
>> rtc-pl031 1c170000.rtc: setting system clock to 2019-02-07T12:12:07 UTC (1549541527)
>> ALSA device list:
>>    #0: ARM AC'97 Interface PL041 rev0 at 0x1c040000, irq 28
>> input: ImExPS/2 Generic Explorer Mouse as /devices/platform/smb at 8000000/smb at 8000000:motherboard/smb at 8000000:motherboard:iofpga at 3,00000000/1c070000.kmi/serio1/input/input2
>> drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram at 18000000
>> drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory
>> Error: Driver 'vexpress-muxfpga' is already registered, aborting...
>> drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111
>> drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD
>>
>> Booting Linux on physical CPU 0x0
>> Linux version 5.0.0-rc5 (wagner at wagner-Precision-3510) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #1 SMP Tue Feb 5 17:09:25 CET 2019
>> CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
>> CPU: div instructions available: patching division code
>> CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
>> OF: fdt: Machine model: V2P-CA15
>> printk: bootconsole [earlycon0] enabled
>> Memory policy: Data cache writealloc
>> Reserved memory: created DMA memory pool at 0x18000000, size 8 MiB
>> OF: reserved mem: initialized node vram at 18000000, compatible id shared-dma-pool
>> cma: Reserved 16 MiB at 0xbf000000
>> On node 0 totalpages: 262144
>>    Normal zone: 2048 pages used for memmap
>>    Normal zone: 0 pages reserved
>>    Normal zone: 262144 pages, LIFO batch:63
>> random: get_random_bytes called from start_kernel+0x9c/0x458 with crng_init=0
>> percpu: Embedded 17 pages/cpu @(ptrval) s37196 r8192 d24244 u69632
>> pcpu-alloc: s37196 r8192 d24244 u69632 alloc=17*4096
>> pcpu-alloc: [0] 0
>> Built 1 zonelists, mobility grouping on.  Total pages: 260096
>> Kernel command line: console=ttyAMA0 earlyprintk debug verbose
>> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> Memory: 1012216K/1048576K available (7168K kernel code, 420K rwdata, 1572K rodata, 1024K init, 158K bss, 19976K reserved, 16384K cma-reserved)
>> Virtual kernel memory layout:
>>      vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>      fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
>>      vmalloc : 0xc0800000 - 0xff800000   (1008 MB)
>>      lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>      modules : 0x7f000000 - 0x80000000   (  16 MB)
>>        .text : 0x(ptrval) - 0x(ptrval)   (8160 kB)
>>        .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
>>        .data : 0x(ptrval) - 0x(ptrval)   ( 421 kB)
>>         .bss : 0x(ptrval) - 0x(ptrval)   ( 159 kB)
>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> rcu: Hierarchical RCU implementation.
>> rcu: 	RCU event tracing is enabled.
>> rcu: 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
>> rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
>> rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
>> NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
>> clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
>> Failed to initialize '/smb at 8000000/motherboard/iofpga at 3,00000000/timer at 120000': -22
>> arch_timer: cp15 timer(s) running at 62.50MHz (virt).
>> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
>> sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
>> Switching to timer-based delay loop, resolution 16ns
>> Console: colour dummy device 80x30
>> Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
>> pid_max: default: 32768 minimum: 301
>> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> CPU: Testing write buffer coherency: ok
>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
>> /cpus/cpu at 0 missing clock-frequency property
>> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> Setting up static identity map for 0x80100000 - 0x80100060
>> rcu: Hierarchical SRCU implementation.
>> smp: Bringing up secondary CPUs ...
>> smp: Brought up 1 node, 1 CPU
>> SMP: Total of 1 processors activated (125.00 BogoMIPS).
>> CPU: All CPU(s) started in SVC mode.
>> devtmpfs: initialized
>> VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
>> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
>> futex hash table entries: 256 (order: 2, 16384 bytes)
>> NET: Registered protocol family 16
>> DMA: preallocated 256 KiB pool for atomic coherent allocations
>>
>

+++
Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen
Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 
+++
Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately.
+++


More information about the U-Boot mailing list