* Troubles running qemu64 target
@ 2018-06-28 13:46 ranquet guillaume
2018-06-29 0:46 ` Andrey Smirnov
0 siblings, 1 reply; 5+ messages in thread
From: ranquet guillaume @ 2018-06-28 13:46 UTC (permalink / raw)
To: barebox
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
Hello.
I'm pretty new to barebox and I'm having some troubles running the
qemu64 target.
to top it off, I'm also new to the ARM world... and this is my first
attempt at looking at a bootloader...
I'm having trouble porting some hardware to barebox... and while I'm
waiting for a JTAG probe, I though I could have some fun with qemu64
:)
The boot stops pretty early in the flow. way before anything can be
printed on the serial. I have attached gdb to the qemu-system.
The "qemu-system" seems to be stuck when trying to execute an stp with
the stack pointer as the destination.
I'm having the feeling that I have a configuration issue because sp = 0x0
x27 0x0 0
x28 0x0 0
x29 0x0 0
x30 0x0 0
sp 0x0 0x0
pc 0x40000000 0x40000000 <start>
cpsr 0x400003c5 1073742789
fpsr 0x0 0
fpcr 0x0 0
(gdb) disassemble
Dump of assembler code for function start:
=> 0x0000000040000000 <+0>: b 0x40000048 <start+72>
0x0000000040000004 <+4>: nop
0x0000000040000008 <+8>: nop
0x000000004000000c <+12>: nop
...
0x0000000040000048 <+72>: b 0x40013444 <barebox_arm_reset_vector>
then we are branching to <barebox_arm_reset_vector>
Dump of assembler code for function barebox_arm_reset_vector:
=> 0x0000000040013444 <+0>: stp x29, x30, [sp, #-16]!
0x0000000040013448 <+4>: mov x29, sp
0x000000004001344c <+8>: bl 0x40000050 <arm_cpu_lowlevel_init>
with sp still equals to 0x0.
stepping from there seems to get me "stuck"...
when interrupting gdb (Ctrl-C) and dumping the registers, I'm getting
the feeling I'm out of barebox code with pc equals 0x200
x29 0x0 0
x30 0x0 0
sp 0x0 0x0
pc 0x200 0x200
cpsr 0x3c5 965
fpsr 0x0 0
It's probably some kind of configuration issue...? though I see no
code to set sp before that stp instruction.
I tried toying with the memory map, setting stack and text base
addresses, but it doesn't seem to fix my issue.
Or maybe it's okay to decrement sp while it's equal to 0x0?
Any ideas? comments?
Thx,
Guillaume.
running qemu:
sudo qemu-system-aarch64 -m 4096M \
-cpu cortex-a57 -machine virt \
-display none -serial stdio \
-kernel qemu64/barebox -s -S
[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 9336 bytes --]
#
# Automatically generated file; DO NOT EDIT.
# Barebox/arm 2018.06.0 Configuration
#
CONFIG_ARM=y
CONFIG_ARM_LINUX=y
CONFIG_TEXT_BASE=0x40000000
#
# System Type
#
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCM283X is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_DIGIC is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_ARCH_OMAP is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_ARCH_S3C24xx is not set
# CONFIG_ARCH_S5PCxx is not set
# CONFIG_ARCH_S3C64xx is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_UEMD is not set
# CONFIG_ARCH_ZYNQ is not set
CONFIG_ARCH_QEMU=y
# CONFIG_ARCH_RMOBILE is not set
#
# Processor Type
#
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_CPU_64=y
CONFIG_CPU_V8=y
CONFIG_CPU_64v8=y
#
# processor features
#
# CONFIG_BOOT_ENDIANNESS_SWITCH is not set
CONFIG_SYS_SUPPORTS_64BIT_KERNEL=y
CONFIG_CPU_SUPPORTS_64BIT_KERNEL=y
CONFIG_ARCH_TEXT_BASE=0x40000000
CONFIG_BAREBOX_MAX_IMAGE_SIZE=0xffffffff
CONFIG_MACH_QEMU_VIRT64=y
CONFIG_64BIT=y
#
# ARM specific settings
#
# CONFIG_ARM_OPTIMZED_STRING_FUNCTIONS is not set
CONFIG_ARM_EXCEPTIONS=y
CONFIG_DEFCONFIG_LIST="$ARCH_DEFCONFIG"
CONFIG_GREGORIAN_CALENDER=y
CONFIG_HAS_KALLSYMS=y
CONFIG_HAS_CACHE=y
CONFIG_FILETYPE=y
CONFIG_BINFMT=y
CONFIG_UIMAGE=y
CONFIG_STDDEV=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
#
# General Settings
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BANNER=y
CONFIG_MEMINFO=y
CONFIG_ENVIRONMENT_VARIABLES=y
CONFIG_GLOBALVAR=y
CONFIG_NVVAR=y
#
# memory layout
#
CONFIG_HAVE_IMAGE_COMPRESSION=y
CONFIG_MMU=y
CONFIG_MMU_EARLY=y
CONFIG_HAVE_CONFIGURABLE_TEXT_BASE=y
CONFIG_BAREBOX_MAX_BARE_INIT_SIZE=0xffffffff
CONFIG_HAVE_CONFIGURABLE_MEMORY_LAYOUT=y
# CONFIG_MEMORY_LAYOUT_DEFAULT is not set
CONFIG_MEMORY_LAYOUT_FIXED=y
CONFIG_STACK_BASE=0x4007fff0
CONFIG_STACK_SIZE=0x8000
CONFIG_MALLOC_BASE=0x500000000
CONFIG_MALLOC_SIZE=0x400000
# CONFIG_EXPERIMENTAL is not set
CONFIG_MALLOC_DLMALLOC=y
# CONFIG_MALLOC_TLSF is not set
# CONFIG_KALLSYMS is not set
# CONFIG_RELOCATABLE is not set
# CONFIG_PANIC_HANG is not set
CONFIG_PROMPT="barebox:"
CONFIG_BAUDRATE=115200
CONFIG_SIMPLE_READLINE=y
CONFIG_CBSIZE=1024
CONFIG_SHELL_HUSH=y
# CONFIG_SHELL_SIMPLE is not set
# CONFIG_SHELL_NONE is not set
# CONFIG_GLOB is not set
CONFIG_PROMPT_HUSH_PS2="> "
# CONFIG_HUSH_FANCY_PROMPT is not set
# CONFIG_CMDLINE_EDITING is not set
# CONFIG_MENU is not set
# CONFIG_PASSWORD is not set
CONFIG_DYNAMIC_CRC_TABLE=y
CONFIG_ERRNO_MESSAGES=y
CONFIG_TIMESTAMP=y
CONFIG_BOOTM=y
# CONFIG_BOOTM_SHOW_TYPE is not set
# CONFIG_BOOTM_VERBOSE is not set
# CONFIG_BOOTM_INITRD is not set
# CONFIG_BOOTM_OFTREE is not set
# CONFIG_BOOTM_AIMAGE is not set
# CONFIG_BOOTM_FITIMAGE is not set
# CONFIG_FLEXIBLE_BOOTARGS is not set
# CONFIG_IMD is not set
# CONFIG_KERNEL_INSTALL_TARGET is not set
CONFIG_CONSOLE_FULL=y
# CONFIG_CONSOLE_SIMPLE is not set
# CONFIG_CONSOLE_NONE is not set
CONFIG_CONSOLE_ACTIVATE_FIRST=y
# CONFIG_CONSOLE_ACTIVATE_ALL is not set
# CONFIG_CONSOLE_ACTIVATE_NONE is not set
# CONFIG_CONSOLE_ALLOW_COLOR is not set
# CONFIG_CONSOLE_RATP is not set
# CONFIG_PARTITION is not set
CONFIG_ENV_HANDLING=y
CONFIG_DEFAULT_ENVIRONMENT=y
CONFIG_DEFAULT_COMPRESSION_NONE=y
# CONFIG_DEFAULT_ENVIRONMENT_GENERIC_NEW is not set
# CONFIG_DEFAULT_ENVIRONMENT_GENERIC is not set
CONFIG_DEFAULT_ENVIRONMENT_PATH=""
# CONFIG_BAREBOXENV_TARGET is not set
# CONFIG_BAREBOXCRC32_TARGET is not set
# CONFIG_POLLER is not set
# CONFIG_STATE is not set
# CONFIG_BOOTCHOOSER is not set
# CONFIG_RESET_SOURCE is not set
#
# Debugging
#
CONFIG_COMPILE_LOGLEVEL=6
CONFIG_DEFAULT_LOGLEVEL=7
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_LL is not set
# CONFIG_DEBUG_INITCALLS is not set
CONFIG_HAS_DEBUG_LL=y
CONFIG_COMMAND_SUPPORT=y
CONFIG_COMPILE_MEMORY=y
#
# Commands
#
#
# Information
#
CONFIG_CMD_ARM_CPUINFO=y
CONFIG_CMD_DEVINFO=y
# CONFIG_CMD_DMESG is not set
CONFIG_CMD_DRVINFO=y
CONFIG_CMD_HELP=y
# CONFIG_LONGHELP is not set
# CONFIG_CMD_IOMEM is not set
# CONFIG_CMD_IMD is not set
# CONFIG_CMD_MEMINFO is not set
CONFIG_CMD_VERSION=y
#
# Boot
#
# CONFIG_CMD_BOOT is not set
CONFIG_CMD_BOOTM=y
# CONFIG_CMD_GO is not set
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
# CONFIG_CMD_LOADY is not set
# CONFIG_CMD_RESET is not set
# CONFIG_CMD_UIMAGE is not set
#
# Partition
#
# CONFIG_CMD_PARTITION is not set
# CONFIG_CMD_AUTOMOUNT is not set
CONFIG_CMD_MOUNT=y
CONFIG_CMD_UMOUNT=y
#
# Environment
#
# CONFIG_CMD_NV is not set
# CONFIG_CMD_EXPORT is not set
# CONFIG_CMD_DEFAULTENV is not set
# CONFIG_CMD_GLOBAL is not set
# CONFIG_CMD_LOADENV is not set
# CONFIG_CMD_PRINTENV is not set
# CONFIG_CMD_MAGICVAR is not set
# CONFIG_CMD_SAVEENV is not set
#
# File
#
# CONFIG_CMD_BASENAME is not set
CONFIG_CMD_CAT=y
CONFIG_CMD_CD=y
CONFIG_CMD_CP=y
# CONFIG_CMD_CMP is not set
# CONFIG_CMD_DIGEST is not set
# CONFIG_CMD_DIRNAME is not set
# CONFIG_CMD_FILETYPE is not set
# CONFIG_CMD_LN is not set
CONFIG_CMD_LS=y
# CONFIG_CMD_MD5SUM is not set
CONFIG_CMD_MKDIR=y
CONFIG_CMD_PWD=y
# CONFIG_CMD_READLINK is not set
CONFIG_CMD_RM=y
CONFIG_CMD_RMDIR=y
# CONFIG_CMD_SHA1SUM is not set
# CONFIG_CMD_SHA224SUM is not set
# CONFIG_CMD_SHA256SUM is not set
# CONFIG_CMD_SHA384SUM is not set
# CONFIG_CMD_SHA512SUM is not set
# CONFIG_CMD_UNCOMPRESS is not set
#
# Shell scripting
#
CONFIG_CMD_FALSE=y
# CONFIG_CMD_GETOPT is not set
# CONFIG_CMD_LET is not set
# CONFIG_CMD_MSLEEP is not set
# CONFIG_CMD_READF is not set
# CONFIG_CMD_SLEEP is not set
CONFIG_CMD_TEST=y
CONFIG_CMD_TRUE=y
#
# Console and Framebuffer interaction
#
CONFIG_CMD_CLEAR=y
CONFIG_CMD_ECHO=y
# CONFIG_CMD_ECHO_E is not set
# CONFIG_CMD_EDIT is not set
# CONFIG_CMD_LOGIN is not set
# CONFIG_CMD_READLINE is not set
# CONFIG_CMD_TIMEOUT is not set
#
# Memory
#
# CONFIG_CMD_CRC is not set
CONFIG_CMD_MD=y
CONFIG_CMD_MEMCMP=y
CONFIG_CMD_MEMCPY=y
CONFIG_CMD_MEMSET=y
# CONFIG_CMD_MEMTEST is not set
# CONFIG_CMD_MM is not set
CONFIG_CMD_MW=y
#
# Hardware manipulation
#
# CONFIG_CMD_DETECT is not set
# CONFIG_CMD_FLASH is not set
# CONFIG_CMD_POWEROFF is not set
# CONFIG_CMD_SPI is not set
#
# Miscellaneous
#
# CONFIG_CMD_2048 is not set
# CONFIG_CMD_BAREBOX_UPDATE is not set
# CONFIG_CMD_FIRMWARELOAD is not set
# CONFIG_CMD_OF_DUMP is not set
# CONFIG_CMD_OF_NODE is not set
# CONFIG_CMD_OF_PROPERTY is not set
# CONFIG_CMD_OF_DISPLAY_TIMINGS is not set
# CONFIG_CMD_OF_FIXUP_STATUS is not set
# CONFIG_CMD_OFTREE is not set
# CONFIG_CMD_TIME is not set
# CONFIG_CMD_DHRYSTONE is not set
# CONFIG_CMD_SPD_DECODE is not set
# CONFIG_CMD_SEED is not set
# CONFIG_NET is not set
#
# Drivers
#
# CONFIG_OFDEVICE is not set
# CONFIG_AIODEV is not set
CONFIG_ARM_AMBA=y
#
# serial drivers
#
# CONFIG_SERIAL_DEV_BUS is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_DRIVER_SERIAL_NS16550 is not set
# CONFIG_DRIVER_SERIAL_CADENCE is not set
# CONFIG_SCIF_CONSOLE is not set
#
# SPI drivers
#
CONFIG_SPI=y
# CONFIG_I2C is not set
# CONFIG_MTD is not set
# CONFIG_DISK is not set
# CONFIG_USB_HOST is not set
# CONFIG_USB_GADGET is not set
# CONFIG_USB_MUSB is not set
# CONFIG_VIDEO is not set
# CONFIG_MCI is not set
CONFIG_CLOCKSOURCE_DUMMY_RATE=1000
CONFIG_CLOCKSOURCE_ARMV8_TIMER=y
#
# MFD
#
# CONFIG_MFD_MC13XXX is not set
# CONFIG_MFD_SYSCON is not set
#
# Misc devices
#
# CONFIG_SRAM is not set
# CONFIG_LED is not set
#
# EEPROM support
#
# CONFIG_EEPROM_AT25 is not set
#
# Input device support
#
# CONFIG_WATCHDOG is not set
# CONFIG_PWM is not set
# CONFIG_HWRNG is not set
#
# DMA support
#
# CONFIG_W1 is not set
# CONFIG_PINCTRL is not set
# CONFIG_NVMEM is not set
#
# Bus devices
#
# CONFIG_REGULATOR is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_RTC_CLASS is not set
#
# Firmware Drivers
#
# CONFIG_GENERIC_PHY is not set
# CONFIG_CRYPTO_HW is not set
#
# Memory controller drivers
#
#
# Filesystem support
#
CONFIG_FS=y
# CONFIG_FS_CRAMFS is not set
# CONFIG_FS_EXT4 is not set
CONFIG_FS_RAMFS=y
CONFIG_FS_DEVFS=y
# CONFIG_FS_FAT is not set
# CONFIG_FS_BPKFS is not set
# CONFIG_FS_UIMAGEFS is not set
# CONFIG_FS_PSTORE is not set
# CONFIG_FS_SQUASHFS is not set
#
# ZLIB support disabled
#
#
# LZ4 support disabled
#
#
# LZO support disabled
#
#
# XZ support disabled
#
#
# ZSTD support disabled
#
#
# Library routines
#
CONFIG_PARAMETER=y
CONFIG_UNCOMPRESS=y
# CONFIG_ZLIB is not set
# CONFIG_BZLIB is not set
# CONFIG_LZ4_DECOMPRESS is not set
# CONFIG_ZSTD_DECOMPRESS is not set
# CONFIG_XZ_DECOMPRESS is not set
# CONFIG_GENERIC_FIND_NEXT_BIT is not set
# CONFIG_PROCESS_ESCAPE_SEQUENCE is not set
# CONFIG_LZO_DECOMPRESS is not set
CONFIG_FNMATCH=y
# CONFIG_RATP is not set
# CONFIG_ALLOW_PRNG_FALLBACK is not set
# CONFIG_CRC_CCITT is not set
#
# Library gui routines
#
# CONFIG_BAREBOX_LOGO is not set
#
# Crypto support
#
CONFIG_CRC32=y
CONFIG_CRC16=y
# CONFIG_DIGEST is not set
# CONFIG_CRYPTO_KEYSTORE is not set
#
# Firmware files
#
CONFIG_EXTRA_FIRMWARE_DIR="firmware"
#
# Host Tools
#
# CONFIG_COMPILE_HOST_TOOLS is not set
[-- Attachment #3: barebox_gdb.log --]
[-- Type: application/octet-stream, Size: 6403 bytes --]
% gdb-multiarch qemu64/barebox
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from qemu64/barebox...(no debugging symbols found)...done.
(gdb) set architecture aarch64
The target architecture is assumed to be aarch64
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000000040000000 in start ()
(gdb) info r
x0 0x0 0
x1 0x0 0
x2 0x0 0
x3 0x0 0
x4 0x0 0
x5 0x0 0
x6 0x0 0
x7 0x0 0
x8 0x0 0
x9 0x0 0
x10 0x0 0
x11 0x0 0
x12 0x0 0
x13 0x0 0
x14 0x0 0
x15 0x0 0
x16 0x0 0
x17 0x0 0
x18 0x0 0
x19 0x0 0
x20 0x0 0
x21 0x0 0
x22 0x0 0
x23 0x0 0
x24 0x0 0
x25 0x0 0
x26 0x0 0
x27 0x0 0
x28 0x0 0
x29 0x0 0
x30 0x0 0
sp 0x0 0x0
pc 0x40000000 0x40000000 <start>
cpsr 0x400003c5 1073742789
fpsr 0x0 0
fpcr 0x0 0
(gdb) disassemble
Dump of assembler code for function start:
=> 0x0000000040000000 <+0>: b 0x40000048 <start+72>
0x0000000040000004 <+4>: nop
0x0000000040000008 <+8>: nop
0x000000004000000c <+12>: nop
0x0000000040000010 <+16>: nop
0x0000000040000014 <+20>: nop
0x0000000040000018 <+24>: fnmls z2.h, p0/m, z11.h, z18.h
0x000000004000001c <+28>: .inst 0x00786f62 ; undefined
0x0000000040000020 <+32>: .inst 0xffffffff ; undefined
0x0000000040000024 <+36>: .inst 0x00019f18 ; undefined
0x0000000040000028 <+40>: .inst 0x55555555 ; undefined
0x000000004000002c <+44>: .inst 0x55555555 ; undefined
0x0000000040000030 <+48>: .inst 0x55555555 ; undefined
0x0000000040000034 <+52>: .inst 0x55555555 ; undefined
0x0000000040000038 <+56>: .inst 0x55555555 ; undefined
0x000000004000003c <+60>: .inst 0x55555555 ; undefined
0x0000000040000040 <+64>: .inst 0x55555555 ; undefined
0x0000000040000044 <+68>: .inst 0x55555555 ; undefined
0x0000000040000048 <+72>: b 0x40013444 <barebox_arm_reset_vector>
0x000000004000004c <+76>: ret
End of assembler dump.
(gdb) s
Single stepping until exit from function start,
which has no line number information.
0x0000000040013444 in barebox_arm_reset_vector ()
(gdb) disassemble
Dump of assembler code for function barebox_arm_reset_vector:
=> 0x0000000040013444 <+0>: stp x29, x30, [sp, #-16]!
0x0000000040013448 <+4>: mov x29, sp
0x000000004001344c <+8>: bl 0x40000050 <arm_cpu_lowlevel_init>
0x0000000040013450 <+12>: mov x0, #0xc000 // #49152
0x0000000040013454 <+16>: movk x0, #0xbfff, lsl #16
0x0000000040013458 <+20>: mov sp, x0
0x000000004001345c <+24>: mov x2, #0x0 // #0
0x0000000040013460 <+28>: mov x1, #0x80000000 // #2147483648
0x0000000040013464 <+32>: mov x0, #0x40000000 // #1073741824
0x0000000040013468 <+36>: bl 0x40014978 <barebox_arm_entry>
End of assembler dump.
(gdb) info r
x0 0x0 0
x1 0x0 0
x2 0x0 0
x3 0x0 0
x4 0x0 0
x5 0x0 0
x6 0x0 0
x7 0x0 0
x8 0x0 0
x9 0x0 0
x10 0x0 0
x11 0x0 0
x12 0x0 0
x13 0x0 0
x14 0x0 0
x15 0x0 0
x16 0x0 0
x17 0x0 0
x18 0x0 0
x19 0x0 0
x20 0x0 0
x21 0x0 0
x22 0x0 0
x23 0x0 0
x24 0x0 0
x25 0x0 0
x26 0x0 0
x27 0x0 0
x28 0x0 0
x29 0x0 0
x30 0x0 0
sp 0x0 0x0
pc 0x40013444 0x40013444 <barebox_arm_reset_vector>
cpsr 0x400003c5 1073742789
fpsr 0x0 0
fpcr 0x0 0
(gdb) s
Single stepping until exit from function barebox_arm_reset_vector,
which has no line number information.
^C
Program received signal SIGINT, Interrupt.
0x0000000000000200 in ?? ()
(gdb) disassemble
No function contains program counter for selected frame.
(gdb) info r
x0 0x0 0
x1 0x0 0
x2 0x0 0
x3 0x0 0
x4 0x0 0
x5 0x0 0
x6 0x0 0
x7 0x0 0
x8 0x0 0
x9 0x0 0
x10 0x0 0
x11 0x0 0
x12 0x0 0
x13 0x0 0
x14 0x0 0
x15 0x0 0
x16 0x0 0
x17 0x0 0
x18 0x0 0
x19 0x0 0
x20 0x0 0
x21 0x0 0
x22 0x0 0
x23 0x0 0
x24 0x0 0
x25 0x0 0
x26 0x0 0
x27 0x0 0
x28 0x0 0
x29 0x0 0
x30 0x0 0
sp 0x0 0x0
pc 0x200 0x200
cpsr 0x3c5 965
fpsr 0x0 0
fpcr 0x0 0
(gdb)
[-- Attachment #4: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles running qemu64 target
2018-06-28 13:46 Troubles running qemu64 target ranquet guillaume
@ 2018-06-29 0:46 ` Andrey Smirnov
2018-06-29 9:01 ` Raphaël Poggi
0 siblings, 1 reply; 5+ messages in thread
From: Andrey Smirnov @ 2018-06-29 0:46 UTC (permalink / raw)
To: ranquet.guillaume; +Cc: Barebox List, Raphaël Poggi
Guillaume:
I haven't used QEMU ARM64 version of the code, but I have spent some
time on i.MX8M which is ARM64 as well. See my comments below.
On Thu, Jun 28, 2018 at 6:46 AM ranquet guillaume
<ranquet.guillaume@gmail.com> wrote:
>
> Hello.
>
> I'm pretty new to barebox and I'm having some troubles running the
> qemu64 target.
> to top it off, I'm also new to the ARM world... and this is my first
> attempt at looking at a bootloader...
>
> I'm having trouble porting some hardware to barebox... and while I'm
> waiting for a JTAG probe, I though I could have some fun with qemu64
> :)
>
> The boot stops pretty early in the flow. way before anything can be
> printed on the serial. I have attached gdb to the qemu-system.
> The "qemu-system" seems to be stuck when trying to execute an stp with
> the stack pointer as the destination.
>
> I'm having the feeling that I have a configuration issue because sp = 0x0
>
> x27 0x0 0
> x28 0x0 0
> x29 0x0 0
> x30 0x0 0
> sp 0x0 0x0
> pc 0x40000000 0x40000000 <start>
> cpsr 0x400003c5 1073742789
> fpsr 0x0 0
> fpcr 0x0 0
> (gdb) disassemble
> Dump of assembler code for function start:
> => 0x0000000040000000 <+0>: b 0x40000048 <start+72>
> 0x0000000040000004 <+4>: nop
> 0x0000000040000008 <+8>: nop
> 0x000000004000000c <+12>: nop
> ...
> 0x0000000040000048 <+72>: b 0x40013444 <barebox_arm_reset_vector>
>
>
> then we are branching to <barebox_arm_reset_vector>
> Dump of assembler code for function barebox_arm_reset_vector:
> => 0x0000000040013444 <+0>: stp x29, x30, [sp, #-16]!
> 0x0000000040013448 <+4>: mov x29, sp
The above looks like barebox_arm_reset_vector's preamble to me, which
it would have since:
a) It is not declared as __naked
b) AFAIK, __naked is not supported on AArch64 version of GCC, so even
if it was it wouldn't help
> 0x000000004001344c <+8>: bl 0x40000050 <arm_cpu_lowlevel_init>
>
> with sp still equals to 0x0.
>
> stepping from there seems to get me "stuck"...
> when interrupting gdb (Ctrl-C) and dumping the registers, I'm getting
> the feeling I'm out of barebox code with pc equals 0x200
>
> x29 0x0 0
> x30 0x0 0
> sp 0x0 0x0
> pc 0x200 0x200
> cpsr 0x3c5 965
> fpsr 0x0 0
>
>
> It's probably some kind of configuration issue...? though I see no
> code to set sp before that stp instruction.
IMHO this doesn't look like a configuration issue and I agree there's
no code to set SP up.
> I tried toying with the memory map, setting stack and text base
> addresses, but it doesn't seem to fix my issue.
> Or maybe it's okay to decrement sp while it's equal to 0x0?
AFAIK, it would be OK if underlying emulated hardware had any kind of
memory mapped at the end of address space (sp would wrap in that
case), but as far as I can tell QEMU ARM64 virt platform doesn't,
which I think is the reason you are seeing the result you are seeing.
> Any ideas? comments?
I am not sure about the proper way to resolve this, I'd be curious to
hear from Raphael (original author, CC'd in this reply) and how this
worked for him first. However you can very quickly verify/disprove
your bad SP value theory by doing:
set $sp=0xBFFFFFF0
before letting the processor hit those SP instructions when you step
through it and see if barebox runs fine after that.
Thanks,
Andrey Smirnov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles running qemu64 target
2018-06-29 0:46 ` Andrey Smirnov
@ 2018-06-29 9:01 ` Raphaël Poggi
2018-06-29 17:59 ` Andrey Smirnov
0 siblings, 1 reply; 5+ messages in thread
From: Raphaël Poggi @ 2018-06-29 9:01 UTC (permalink / raw)
To: andrew.smirnov; +Cc: ranquet.guillaume, barebox
Hi Guillaume & Andrew,
Le ven. 29 juin 2018 à 01:46, Andrey Smirnov
<andrew.smirnov@gmail.com> a écrit :
>
> Guillaume:
>
> I haven't used QEMU ARM64 version of the code, but I have spent some
> time on i.MX8M which is ARM64 as well. See my comments below.
>
> On Thu, Jun 28, 2018 at 6:46 AM ranquet guillaume
> <ranquet.guillaume@gmail.com> wrote:
> >
> > Hello.
> >
> > I'm pretty new to barebox and I'm having some troubles running the
> > qemu64 target.
> > to top it off, I'm also new to the ARM world... and this is my first
> > attempt at looking at a bootloader...
> >
> > I'm having trouble porting some hardware to barebox... and while I'm
> > waiting for a JTAG probe, I though I could have some fun with qemu64
> > :)
> >
> > The boot stops pretty early in the flow. way before anything can be
> > printed on the serial. I have attached gdb to the qemu-system.
> > The "qemu-system" seems to be stuck when trying to execute an stp with
> > the stack pointer as the destination.
> >
> > I'm having the feeling that I have a configuration issue because sp = 0x0
> >
> > x27 0x0 0
> > x28 0x0 0
> > x29 0x0 0
> > x30 0x0 0
> > sp 0x0 0x0
> > pc 0x40000000 0x40000000 <start>
> > cpsr 0x400003c5 1073742789
> > fpsr 0x0 0
> > fpcr 0x0 0
> > (gdb) disassemble
> > Dump of assembler code for function start:
> > => 0x0000000040000000 <+0>: b 0x40000048 <start+72>
> > 0x0000000040000004 <+4>: nop
> > 0x0000000040000008 <+8>: nop
> > 0x000000004000000c <+12>: nop
> > ...
> > 0x0000000040000048 <+72>: b 0x40013444 <barebox_arm_reset_vector>
> >
> >
> > then we are branching to <barebox_arm_reset_vector>
> > Dump of assembler code for function barebox_arm_reset_vector:
> > => 0x0000000040013444 <+0>: stp x29, x30, [sp, #-16]!
> > 0x0000000040013448 <+4>: mov x29, sp
>
> The above looks like barebox_arm_reset_vector's preamble to me, which
> it would have since:
>
> a) It is not declared as __naked
>
> b) AFAIK, __naked is not supported on AArch64 version of GCC, so even
> if it was it wouldn't help
>
> > 0x000000004001344c <+8>: bl 0x40000050 <arm_cpu_lowlevel_init>
> >
> > with sp still equals to 0x0.
> >
> > stepping from there seems to get me "stuck"...
> > when interrupting gdb (Ctrl-C) and dumping the registers, I'm getting
> > the feeling I'm out of barebox code with pc equals 0x200
> >
> > x29 0x0 0
> > x30 0x0 0
> > sp 0x0 0x0
> > pc 0x200 0x200
> > cpsr 0x3c5 965
> > fpsr 0x0 0
> >
> >
> > It's probably some kind of configuration issue...? though I see no
> > code to set sp before that stp instruction.
>
> IMHO this doesn't look like a configuration issue and I agree there's
> no code to set SP up.
>
> > I tried toying with the memory map, setting stack and text base
> > addresses, but it doesn't seem to fix my issue.
> > Or maybe it's okay to decrement sp while it's equal to 0x0?
>
> AFAIK, it would be OK if underlying emulated hardware had any kind of
> memory mapped at the end of address space (sp would wrap in that
> case), but as far as I can tell QEMU ARM64 virt platform doesn't,
> which I think is the reason you are seeing the result you are seeing.
>
> > Any ideas? comments?
>
> I am not sure about the proper way to resolve this, I'd be curious to
> hear from Raphael (original author, CC'd in this reply) and how this
> worked for him first. However you can very quickly verify/disprove
> your bad SP value theory by doing:
>
> set $sp=0xBFFFFFF0
>
> before letting the processor hit those SP instructions when you step
> through it and see if barebox runs fine after that.
>
> Thanks,
> Andrey Smirnov
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
Thank you for adding in CC.
I have looked at bit at this issue, indeed the fact that "
barebox_arm_reset_vector" is not naked, is not good.
I did not catch this issue by the time I have get my work merged,
because it was not crashing (don't know why...).
I have test with the master branch and barebox crashs but I can have
some serial output:
barebox 2018.06.0-00145-gfe040e0-dirty #1 Fri Jun 29 09:06:54 DST 2018
Board: ARM QEMU virt64
DABT (current EL) exception (ESR 0x9400004b) at 0x0000000000000000
elr: 000000004100cad8 lr : 000000004100cac4
x0 : 00000000000000f0 x1 : 0000000000000001
x2 : 00000000bffefd2c x3 : 00000000ffffffff
x4 : 0000000000000008 x5 : 0000000000000000
x6 : 0000000040c06710 x7 : 0000000000000000
Anyway, the qemu virt board is broken.
I will try to work a bit on this in the week end.
Andrew, how do you set up the stack on the imx8 board ?
Thanks,
Raphael
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles running qemu64 target
2018-06-29 9:01 ` Raphaël Poggi
@ 2018-06-29 17:59 ` Andrey Smirnov
2018-07-03 4:03 ` ranquet guillaume
0 siblings, 1 reply; 5+ messages in thread
From: Andrey Smirnov @ 2018-06-29 17:59 UTC (permalink / raw)
To: Raphaël Poggi; +Cc: Guillaume Ranquet, Barebox List
On Fri, Jun 29, 2018 at 2:01 AM Raphaël Poggi <poggi.raph@gmail.com> wrote:
>
> Hi Guillaume & Andrew,
>
>
> Le ven. 29 juin 2018 à 01:46, Andrey Smirnov
> <andrew.smirnov@gmail.com> a écrit :
> >
> > Guillaume:
> >
> > I haven't used QEMU ARM64 version of the code, but I have spent some
> > time on i.MX8M which is ARM64 as well. See my comments below.
> >
> > On Thu, Jun 28, 2018 at 6:46 AM ranquet guillaume
> > <ranquet.guillaume@gmail.com> wrote:
> > >
> > > Hello.
> > >
> > > I'm pretty new to barebox and I'm having some troubles running the
> > > qemu64 target.
> > > to top it off, I'm also new to the ARM world... and this is my first
> > > attempt at looking at a bootloader...
> > >
> > > I'm having trouble porting some hardware to barebox... and while I'm
> > > waiting for a JTAG probe, I though I could have some fun with qemu64
> > > :)
> > >
> > > The boot stops pretty early in the flow. way before anything can be
> > > printed on the serial. I have attached gdb to the qemu-system.
> > > The "qemu-system" seems to be stuck when trying to execute an stp with
> > > the stack pointer as the destination.
> > >
> > > I'm having the feeling that I have a configuration issue because sp = 0x0
> > >
> > > x27 0x0 0
> > > x28 0x0 0
> > > x29 0x0 0
> > > x30 0x0 0
> > > sp 0x0 0x0
> > > pc 0x40000000 0x40000000 <start>
> > > cpsr 0x400003c5 1073742789
> > > fpsr 0x0 0
> > > fpcr 0x0 0
> > > (gdb) disassemble
> > > Dump of assembler code for function start:
> > > => 0x0000000040000000 <+0>: b 0x40000048 <start+72>
> > > 0x0000000040000004 <+4>: nop
> > > 0x0000000040000008 <+8>: nop
> > > 0x000000004000000c <+12>: nop
> > > ...
> > > 0x0000000040000048 <+72>: b 0x40013444 <barebox_arm_reset_vector>
> > >
> > >
> > > then we are branching to <barebox_arm_reset_vector>
> > > Dump of assembler code for function barebox_arm_reset_vector:
> > > => 0x0000000040013444 <+0>: stp x29, x30, [sp, #-16]!
> > > 0x0000000040013448 <+4>: mov x29, sp
> >
> > The above looks like barebox_arm_reset_vector's preamble to me, which
> > it would have since:
> >
> > a) It is not declared as __naked
> >
> > b) AFAIK, __naked is not supported on AArch64 version of GCC, so even
> > if it was it wouldn't help
> >
> > > 0x000000004001344c <+8>: bl 0x40000050 <arm_cpu_lowlevel_init>
> > >
> > > with sp still equals to 0x0.
> > >
> > > stepping from there seems to get me "stuck"...
> > > when interrupting gdb (Ctrl-C) and dumping the registers, I'm getting
> > > the feeling I'm out of barebox code with pc equals 0x200
> > >
> > > x29 0x0 0
> > > x30 0x0 0
> > > sp 0x0 0x0
> > > pc 0x200 0x200
> > > cpsr 0x3c5 965
> > > fpsr 0x0 0
> > >
> > >
> > > It's probably some kind of configuration issue...? though I see no
> > > code to set sp before that stp instruction.
> >
> > IMHO this doesn't look like a configuration issue and I agree there's
> > no code to set SP up.
> >
> > > I tried toying with the memory map, setting stack and text base
> > > addresses, but it doesn't seem to fix my issue.
> > > Or maybe it's okay to decrement sp while it's equal to 0x0?
> >
> > AFAIK, it would be OK if underlying emulated hardware had any kind of
> > memory mapped at the end of address space (sp would wrap in that
> > case), but as far as I can tell QEMU ARM64 virt platform doesn't,
> > which I think is the reason you are seeing the result you are seeing.
> >
> > > Any ideas? comments?
> >
> > I am not sure about the proper way to resolve this, I'd be curious to
> > hear from Raphael (original author, CC'd in this reply) and how this
> > worked for him first. However you can very quickly verify/disprove
> > your bad SP value theory by doing:
> >
> > set $sp=0xBFFFFFF0
> >
> > before letting the processor hit those SP instructions when you step
> > through it and see if barebox runs fine after that.
> >
> > Thanks,
> > Andrey Smirnov
> >
> > _______________________________________________
> > barebox mailing list
> > barebox@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/barebox
>
>
>
> Thank you for adding in CC.
>
> I have looked at bit at this issue, indeed the fact that "
> barebox_arm_reset_vector" is not naked, is not good.
>
> I did not catch this issue by the time I have get my work merged,
> because it was not crashing (don't know why...).
>
> I have test with the master branch and barebox crashs but I can have
> some serial output:
>
> barebox 2018.06.0-00145-gfe040e0-dirty #1 Fri Jun 29 09:06:54 DST 2018
>
> Board: ARM QEMU virt64
> DABT (current EL) exception (ESR 0x9400004b) at 0x0000000000000000
> elr: 000000004100cad8 lr : 000000004100cac4
> x0 : 00000000000000f0 x1 : 0000000000000001
> x2 : 00000000bffefd2c x3 : 00000000ffffffff
> x4 : 0000000000000008 x5 : 0000000000000000
> x6 : 0000000040c06710 x7 : 0000000000000000
>
> Anyway, the qemu virt board is broken.
>
> I will try to work a bit on this in the week end.
>
> Andrew, how do you set up the stack on the imx8 board ?
>
Ideally start_nxp_imx8mq_evk is declared as __naked which, if it was
working, would've removed its function prologue/epilogue and we could
either set up the stack at that point or, if looking at disassembly
showed no stack usage, we could wait until that would be done as apart
of barebox_arm_entry().
However, given how __naked wasn't working on AArch64 for me and I
didn't want to majorly change what ENTRY_FUNCTION() does, I just
settled to exploit the fact that i.MX8M uses MaskROM firmware that
implements initial bootstrapping (fetching the image from the medium,
executing DCD, etc.) which sets up some initial stack for its internal
needs and can be used until we reach barebox_arm_entry() where SP
would be properly set up.
Thanks,
Andrey Smirnov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Troubles running qemu64 target
2018-06-29 17:59 ` Andrey Smirnov
@ 2018-07-03 4:03 ` ranquet guillaume
0 siblings, 0 replies; 5+ messages in thread
From: ranquet guillaume @ 2018-07-03 4:03 UTC (permalink / raw)
To: Andrey Smirnov; +Cc: Barebox List, Raphaël Poggi
>> > set $sp=0xBFFFFFF0
Indeed, I'm so used to debug coredumps with gdb, I didn't even think
about that :)
it gets me a little bit further, but execution is ending up in hang()
pretty quickly.
I need to find a bit of time to investigate further.
I made a dirty workaround, calling setup_stack() just before barebox_arm_entry()
just to get me going.
Thx,
Guillaume.
On Fri, Jun 29, 2018 at 7:59 PM, Andrey Smirnov
<andrew.smirnov@gmail.com> wrote:
> On Fri, Jun 29, 2018 at 2:01 AM Raphaël Poggi <poggi.raph@gmail.com> wrote:
>>
>> Hi Guillaume & Andrew,
>>
>>
>> Le ven. 29 juin 2018 à 01:46, Andrey Smirnov
>> <andrew.smirnov@gmail.com> a écrit :
>> >
>> > Guillaume:
>> >
>> > I haven't used QEMU ARM64 version of the code, but I have spent some
>> > time on i.MX8M which is ARM64 as well. See my comments below.
>> >
>> > On Thu, Jun 28, 2018 at 6:46 AM ranquet guillaume
>> > <ranquet.guillaume@gmail.com> wrote:
>> > >
>> > > Hello.
>> > >
>> > > I'm pretty new to barebox and I'm having some troubles running the
>> > > qemu64 target.
>> > > to top it off, I'm also new to the ARM world... and this is my first
>> > > attempt at looking at a bootloader...
>> > >
>> > > I'm having trouble porting some hardware to barebox... and while I'm
>> > > waiting for a JTAG probe, I though I could have some fun with qemu64
>> > > :)
>> > >
>> > > The boot stops pretty early in the flow. way before anything can be
>> > > printed on the serial. I have attached gdb to the qemu-system.
>> > > The "qemu-system" seems to be stuck when trying to execute an stp with
>> > > the stack pointer as the destination.
>> > >
>> > > I'm having the feeling that I have a configuration issue because sp = 0x0
>> > >
>> > > x27 0x0 0
>> > > x28 0x0 0
>> > > x29 0x0 0
>> > > x30 0x0 0
>> > > sp 0x0 0x0
>> > > pc 0x40000000 0x40000000 <start>
>> > > cpsr 0x400003c5 1073742789
>> > > fpsr 0x0 0
>> > > fpcr 0x0 0
>> > > (gdb) disassemble
>> > > Dump of assembler code for function start:
>> > > => 0x0000000040000000 <+0>: b 0x40000048 <start+72>
>> > > 0x0000000040000004 <+4>: nop
>> > > 0x0000000040000008 <+8>: nop
>> > > 0x000000004000000c <+12>: nop
>> > > ...
>> > > 0x0000000040000048 <+72>: b 0x40013444 <barebox_arm_reset_vector>
>> > >
>> > >
>> > > then we are branching to <barebox_arm_reset_vector>
>> > > Dump of assembler code for function barebox_arm_reset_vector:
>> > > => 0x0000000040013444 <+0>: stp x29, x30, [sp, #-16]!
>> > > 0x0000000040013448 <+4>: mov x29, sp
>> >
>> > The above looks like barebox_arm_reset_vector's preamble to me, which
>> > it would have since:
>> >
>> > a) It is not declared as __naked
>> >
>> > b) AFAIK, __naked is not supported on AArch64 version of GCC, so even
>> > if it was it wouldn't help
>> >
>> > > 0x000000004001344c <+8>: bl 0x40000050 <arm_cpu_lowlevel_init>
>> > >
>> > > with sp still equals to 0x0.
>> > >
>> > > stepping from there seems to get me "stuck"...
>> > > when interrupting gdb (Ctrl-C) and dumping the registers, I'm getting
>> > > the feeling I'm out of barebox code with pc equals 0x200
>> > >
>> > > x29 0x0 0
>> > > x30 0x0 0
>> > > sp 0x0 0x0
>> > > pc 0x200 0x200
>> > > cpsr 0x3c5 965
>> > > fpsr 0x0 0
>> > >
>> > >
>> > > It's probably some kind of configuration issue...? though I see no
>> > > code to set sp before that stp instruction.
>> >
>> > IMHO this doesn't look like a configuration issue and I agree there's
>> > no code to set SP up.
>> >
>> > > I tried toying with the memory map, setting stack and text base
>> > > addresses, but it doesn't seem to fix my issue.
>> > > Or maybe it's okay to decrement sp while it's equal to 0x0?
>> >
>> > AFAIK, it would be OK if underlying emulated hardware had any kind of
>> > memory mapped at the end of address space (sp would wrap in that
>> > case), but as far as I can tell QEMU ARM64 virt platform doesn't,
>> > which I think is the reason you are seeing the result you are seeing.
>> >
>> > > Any ideas? comments?
>> >
>> > I am not sure about the proper way to resolve this, I'd be curious to
>> > hear from Raphael (original author, CC'd in this reply) and how this
>> > worked for him first. However you can very quickly verify/disprove
>> > your bad SP value theory by doing:
>> >
>> > set $sp=0xBFFFFFF0
>> >
>> > before letting the processor hit those SP instructions when you step
>> > through it and see if barebox runs fine after that.
>> >
>> > Thanks,
>> > Andrey Smirnov
>> >
>> > _______________________________________________
>> > barebox mailing list
>> > barebox@lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/barebox
>>
>>
>>
>> Thank you for adding in CC.
>>
>> I have looked at bit at this issue, indeed the fact that "
>> barebox_arm_reset_vector" is not naked, is not good.
>>
>> I did not catch this issue by the time I have get my work merged,
>> because it was not crashing (don't know why...).
>>
>> I have test with the master branch and barebox crashs but I can have
>> some serial output:
>>
>> barebox 2018.06.0-00145-gfe040e0-dirty #1 Fri Jun 29 09:06:54 DST 2018
>>
>> Board: ARM QEMU virt64
>> DABT (current EL) exception (ESR 0x9400004b) at 0x0000000000000000
>> elr: 000000004100cad8 lr : 000000004100cac4
>> x0 : 00000000000000f0 x1 : 0000000000000001
>> x2 : 00000000bffefd2c x3 : 00000000ffffffff
>> x4 : 0000000000000008 x5 : 0000000000000000
>> x6 : 0000000040c06710 x7 : 0000000000000000
>>
>> Anyway, the qemu virt board is broken.
>>
>> I will try to work a bit on this in the week end.
>>
>> Andrew, how do you set up the stack on the imx8 board ?
>>
>
> Ideally start_nxp_imx8mq_evk is declared as __naked which, if it was
> working, would've removed its function prologue/epilogue and we could
> either set up the stack at that point or, if looking at disassembly
> showed no stack usage, we could wait until that would be done as apart
> of barebox_arm_entry().
>
> However, given how __naked wasn't working on AArch64 for me and I
> didn't want to majorly change what ENTRY_FUNCTION() does, I just
> settled to exploit the fact that i.MX8M uses MaskROM firmware that
> implements initial bootstrapping (fetching the image from the medium,
> executing DCD, etc.) which sets up some initial stack for its internal
> needs and can be used until we reach barebox_arm_entry() where SP
> would be properly set up.
>
> Thanks,
> Andrey Smirnov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-03 4:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-28 13:46 Troubles running qemu64 target ranquet guillaume
2018-06-29 0:46 ` Andrey Smirnov
2018-06-29 9:01 ` Raphaël Poggi
2018-06-29 17:59 ` Andrey Smirnov
2018-07-03 4:03 ` ranquet guillaume
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox