[PATCH] hw/crypto: add Allwinner sun4i-ss crypto device

2022-04-10 Thread Corentin Labbe
From: Corentin LABBE 

The Allwinner A10 has a cryptographic offloader device which
could be easily emulated.
The emulated device is tested with Linux only as any of BSD does not
support it.

Signed-off-by: Corentin LABBE 
---
 MAINTAINERS|   8 +
 docs/system/arm/cubieboard.rst |   1 +
 docs/system/devices/allwinner-sun4i-ss.rst |  31 +
 hw/Kconfig |   1 +
 hw/arm/Kconfig |   1 +
 hw/arm/allwinner-a10.c |  11 +
 hw/crypto/Kconfig  |   2 +
 hw/crypto/allwinner-sun4i-ss.c | 688 +
 hw/crypto/meson.build  |   3 +
 hw/crypto/trace-events |   3 +
 hw/crypto/trace.h  |   1 +
 hw/meson.build |   1 +
 include/hw/arm/allwinner-a10.h |   2 +
 include/hw/crypto/allwinner-sun4i-ss.h |  72 +++
 meson.build|   1 +
 15 files changed, 826 insertions(+)
 create mode 100644 docs/system/devices/allwinner-sun4i-ss.rst
 create mode 100644 hw/crypto/Kconfig
 create mode 100644 hw/crypto/allwinner-sun4i-ss.c
 create mode 100644 hw/crypto/meson.build
 create mode 100644 hw/crypto/trace-events
 create mode 100644 hw/crypto/trace.h
 create mode 100644 include/hw/crypto/allwinner-sun4i-ss.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 4ad2451e03..f07d9713af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -583,6 +583,14 @@ F: include/hw/*/allwinner-h3*
 F: hw/arm/orangepi.c
 F: docs/system/arm/orangepi.rst
 
+Allwinner sun4i-ss cryptographic offloader
+M: Corentin LABBE 
+L: qemu-...@nongnu.org
+S: Maintained
+F: hw/crypto/allwinner-*
+F: include/hw/crypto/allwinner-*
+F: docs/system/arm/orangepi.rst
+
 ARM PrimeCell and CMSDK devices
 M: Peter Maydell 
 L: qemu-...@nongnu.org
diff --git a/docs/system/arm/cubieboard.rst b/docs/system/arm/cubieboard.rst
index 344ff8cef9..7836643ba4 100644
--- a/docs/system/arm/cubieboard.rst
+++ b/docs/system/arm/cubieboard.rst
@@ -14,3 +14,4 @@ Emulated devices:
 - SDHCI
 - USB controller
 - SATA controller
+- crypto
diff --git a/docs/system/devices/allwinner-sun4i-ss.rst 
b/docs/system/devices/allwinner-sun4i-ss.rst
new file mode 100644
index 00..6e7d2142b5
--- /dev/null
+++ b/docs/system/devices/allwinner-sun4i-ss.rst
@@ -0,0 +1,31 @@
+Allwinner sun4i-ss
+==
+
+The ``sun4i-ss`` emulates the Allwinner cryptographic offloader
+present on early Allwinner SoCs (A10, A10s, A13, A20, A33)
+In qemu only A10 via the cubieboard machine is supported.
+
+The emulated hardware is capable of handling the following algorithms:
+- SHA1 and MD5 hash algorithms
+- AES/DES/DES3 in CBC/ECB
+- PRNG
+
+The emulated hardware does not handle yet:
+- CTS for AES
+- CTR for AES/DES/DES3
+- IRQ and DMA mode
+Anyway the Linux driver also does not handle them yet.
+
+The emulation needs a real crypto backend, for the moment only gnutls/nettle 
is supported.
+So the device emulation needs qemu to be compiled with optionnal gnutls.
+
+Emulation limit
+---
+
+PRNG:
+The PRNG is not really emulated as its internal is not known.
+It is replaced by the g_random_int function from glib.
+
+SPEED:
+The emulated hardware is ""faster"" than real hw as any write
+already give results immediatly instead of a few delay in real HW.
diff --git a/hw/Kconfig b/hw/Kconfig
index ad20cce0a9..43bd7fc14d 100644
--- a/hw/Kconfig
+++ b/hw/Kconfig
@@ -6,6 +6,7 @@ source audio/Kconfig
 source block/Kconfig
 source char/Kconfig
 source core/Kconfig
+source crypto/Kconfig
 source display/Kconfig
 source dma/Kconfig
 source gpio/Kconfig
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 97f3b38019..fd8232b1d4 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -317,6 +317,7 @@ config ALLWINNER_A10
 select AHCI
 select ALLWINNER_A10_PIT
 select ALLWINNER_A10_PIC
+select ALLWINNER_CRYPTO_SUN4I_SS
 select ALLWINNER_EMAC
 select SERIAL
 select UNIMP
diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
index 05e84728cb..e9104ee028 100644
--- a/hw/arm/allwinner-a10.c
+++ b/hw/arm/allwinner-a10.c
@@ -23,6 +23,7 @@
 #include "hw/misc/unimp.h"
 #include "sysemu/sysemu.h"
 #include "hw/boards.h"
+#include "hw/crypto/allwinner-sun4i-ss.h"
 #include "hw/usb/hcd-ohci.h"
 
 #define AW_A10_MMC0_BASE0x01c0f000
@@ -32,6 +33,7 @@
 #define AW_A10_EMAC_BASE0x01c0b000
 #define AW_A10_EHCI_BASE0x01c14000
 #define AW_A10_OHCI_BASE0x01c14400
+#define AW_A10_CRYPTO_BASE  0x01c15000
 #define AW_A10_SATA_BASE0x01c18000
 #define AW_A10_RTC_BASE 0x01c20d00
 
@@ -48,6 +50,10 @@ static void aw_a10_init(Object *obj)
 
 object_initialize_child(obj, "emac", &s->emac, TYPE_AW_EMAC);
 
+#if defined CONFIG_NETTLE
+object_initialize_child(obj, "crypto&q

[Qemu-devel] sparc: crash when using initrd > 5M

2019-01-03 Thread Corentin Labbe
Hello

When using an initrd > 5M, I hit the following kernel crash:
qemu-system-sparc -kernel vmlinux -initrd rootfs.cpio.gz -nographic
Configuration device id QEMU version 1 machine id 32
Probing SBus slot 0 offset 0
Probing SBus slot 1 offset 0
Probing SBus slot 2 offset 0
Probing SBus slot 3 offset 0
Probing SBus slot 4 offset 0
Probing SBus slot 5 offset 0
Invalid FCode start byte
CPUs: 1 x FMI,MB86904
UUID: ----
Welcome to OpenBIOS v1.1 built on Oct 5 2018 08:20
  Type 'help' for detailed information
[sparc] Kernel already loaded
switching to new context:
PROMLIB: obio_ranges 1
[0.00] PROMLIB: Sun Boot Prom Version 3 Revision 2
[0.00] Linux version 4.20.0-next-20190102+ (compile@Red) (gcc version 
7.3.0 (Gentoo 7.3.0-r3 p1.4)) #148 Thu Jan 3 16:17:08 CET 2019
[0.00] printk: bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4M
[0.00] TYPE: SPARCstation 5
[0.00] Ethernet address: 52:54:00:12:34:56
[0.00] Unable to handle kernel NULL pointer dereference
[0.00] tsk->{mm,active_mm}->context = 
[0.00] tsk->{mm,active_mm}->pgd = 
[0.00]   \|/  \|/
[0.00]   "@'/ ,. \`@"
[0.00]   /_| \__/ |_\
[0.00]  \__U_/
[0.00] swapper(0): Oops [#1]
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.20.0-next-20190102+ 
#148
[0.00] PSR: 04001fc0 PC: f0010ef0 NPC: f0010ef4 Y: Not 
tainted
[0.00] PC: 
[0.00] %G: 000a 03c4  f05ece08 f05ecc00   00e0  
f05d4000 0001
[0.00] %O:  00e0  0080 00e0   0002  
f05d5bb8 f00bba58
[0.00] RPC: 
[0.00] %L: 0040 f05dfaf8  f05d5c68 0001  0003 006951e0  
f05ed014 f0674ab4
[0.00] %I: f05d5c80   0002 f100     
f05d5c20 f0007fd8
[0.00] Disabling lock debugging due to kernel taint
[0.00] Caller[f0007fd8]: srmmu_fault+0x58/0x68
[0.00] Caller[f0618598]: memblock_alloc_try_nid+0xb8/0xc8
[0.00] Caller[f0611094]: srmmu_paging_init+0x174/0xaf8
[0.00] Caller[f06106a8]: paging_init+0x4/0x24
[0.00] Caller[f060e4f0]: setup_arch+0x3e8/0x480
[0.00] Caller[f060ab50]: start_kernel+0x48/0x460
[0.00] Caller[f060a43c]: continue_boot+0x324/0x334
[0.00] Caller[]:   (null)
[0.00] Instruction DUMP:
[0.00]  c800a024 
[0.00]  83286002 
[0.00]  073c17b3 
[0.00] 
[0.00]  c600e22c 
[0.00]  8a08a003 
[0.00]  80a16001 
[0.00]  0280003b 
[0.00]  c600c001 
[0.00] 
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] Press Stop-A (L1-A) from sun keyboard or send break
[0.00] twice on console to return to the boot prom
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task! ]---
qemu-system-sparc: terminating on signal 15 from pid 13043 (killall)

The NULL ptr dereference is done by memset() in srmmu_nocache_init() and 
memblock_alloc_try_nid().
If I comment both memset, the boot pass

But since nothing explain the NULL ptr deref in memset(), I suspect something 
is overriden by the initrd

Regards



Re: [Qemu-devel] Running linux on qemu omap

2019-06-04 Thread Corentin Labbe
On Wed, May 22, 2019 at 02:23:23AM +0300, Aaro Koskinen wrote:
> Hi,
> 
> On Mon, May 20, 2019 at 09:05:33PM +0200, Corentin Labbe wrote:
> > Hello
> > 
> > I am working on adding a maximum set of qemu machine on kernelCI.
> 
> That's cool.
> 
> > For OMAP, five machine exists and I fail to boot any of them.
> 
> Which machines?
> 
> > The maximum I can get with omap1_defconfig is
> > qemu-system-arm -kernel zImage -nographic -machine cheetah -append 
> > 'root=/dev/ram0 console=ttyO0'
> > Uncompressing Linux... done, booting the kernel.
> > then nothing more.
> 
> It's known that omap1_defconfig doesn't work well for QEMU or
> "multi-board" usage. Perhaps the kernel size is now just too big?
> I'm using a custom config for every OMAP1 board anyway...
> 
> > Does someone have a working config+version to share ?
> 
> I have used the below config for OMAP1 SX1 board (the only one I got
> working with QEMU). Unfortunately the functionality is quite limited,
> but it still allows to run e.g. GCC bootstrap & testsuite, that is rare
> nowadays for armv4t.
> 
> I'm using the following command line with qemu-system-arm 3.1.0:
> 
> -M sx1 \
> -kernel "sx1-zImage" \
> -nographic \
> -drive file="sx1-mmc",if=sd,format=raw \
> -no-reboot
> 
> This should work with v5.1 kernel.
> 
> I'm also interested to run other OMAP kernels under QEMU, e.g. cheetah
> (the real device, Palm TE works OK with the current mainline), and it
> would be interesting to know why QEMU/kernel has regressed...
> 

Thanks, with your config as starting point, I was able to boot both sx1 and 
cheetah

So I now use the omap1_defconfig and the only trick is to disable 
CONFIG_CPU_DCACHE_WRITETHROUGH.
I need also to disable CONFIG_FB for cheetah to works.

Regards



Re: [Qemu-devel] sparc: crash when using initrd > 5M

2019-02-05 Thread Corentin Labbe
On Fri, Feb 01, 2019 at 02:15:15PM +, Mark Cave-Ayland wrote:
> On 18/01/2019 13:33, Mark Cave-Ayland wrote:
> 
> > On 03/01/2019 15:48, Corentin Labbe wrote:
> > 
> >> Hello
> >>
> >> When using an initrd > 5M, I hit the following kernel crash:
> >> qemu-system-sparc -kernel vmlinux -initrd rootfs.cpio.gz -nographic
> >> Configuration device id QEMU version 1 machine id 32
> >> Probing SBus slot 0 offset 0
> >> Probing SBus slot 1 offset 0
> >> Probing SBus slot 2 offset 0
> >> Probing SBus slot 3 offset 0
> >> Probing SBus slot 4 offset 0
> >> Probing SBus slot 5 offset 0
> >> Invalid FCode start byte
> >> CPUs: 1 x FMI,MB86904
> >> UUID: ----
> >> Welcome to OpenBIOS v1.1 built on Oct 5 2018 08:20
> >>   Type 'help' for detailed information
> >> [sparc] Kernel already loaded
> >> switching to new context:
> >> PROMLIB: obio_ranges 1
> >> [0.00] PROMLIB: Sun Boot Prom Version 3 Revision 2
> >> [0.00] Linux version 4.20.0-next-20190102+ (compile@Red) (gcc 
> >> version 7.3.0 (Gentoo 7.3.0-r3 p1.4)) #148 Thu Jan 3 16:17:08 CET 2019
> >> [0.00] printk: bootconsole [earlyprom0] enabled
> >> [0.00] ARCH: SUN4M
> >> [0.00] TYPE: SPARCstation 5
> >> [0.00] Ethernet address: 52:54:00:12:34:56
> >> [0.00] Unable to handle kernel NULL pointer dereference
> >> [0.00] tsk->{mm,active_mm}->context = 
> >> [0.00] tsk->{mm,active_mm}->pgd = 
> >> [0.00]   \|/  \|/
> >> [0.00]   "@'/ ,. \`@"
> >> [0.00]   /_| \__/ |_\
> >> [0.00]  \__U_/
> >> [0.00] swapper(0): Oops [#1]
> >> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> >> 4.20.0-next-20190102+ #148
> >> [0.00] PSR: 04001fc0 PC: f0010ef0 NPC: f0010ef4 Y: Not 
> >> tainted
> >> [0.00] PC: 
> >> [0.00] %G: 000a 03c4  f05ece08 f05ecc00   00e0 
> >>  f05d4000 0001
> >> [0.00] %O:  00e0  0080 00e0   0002 
> >>  f05d5bb8 f00bba58
> >> [0.00] RPC: 
> >> [0.00] %L: 0040 f05dfaf8  f05d5c68 0001  0003 006951e0 
> >>  f05ed014 f0674ab4
> >> [0.00] %I: f05d5c80   0002 f100    
> >>  f05d5c20 f0007fd8
> >> [0.00] Disabling lock debugging due to kernel taint
> >> [0.00] Caller[f0007fd8]: srmmu_fault+0x58/0x68
> >> [0.00] Caller[f0618598]: memblock_alloc_try_nid+0xb8/0xc8
> >> [0.00] Caller[f0611094]: srmmu_paging_init+0x174/0xaf8
> >> [0.00] Caller[f06106a8]: paging_init+0x4/0x24
> >> [0.00] Caller[f060e4f0]: setup_arch+0x3e8/0x480
> >> [0.00] Caller[f060ab50]: start_kernel+0x48/0x460
> >> [0.00] Caller[f060a43c]: continue_boot+0x324/0x334
> >> [0.00] Caller[]:   (null)
> >> [0.00] Instruction DUMP:
> >> [0.00]  c800a024 
> >> [0.00]  83286002 
> >> [0.00]  073c17b3 
> >> [0.00] 
> >> [0.00]  c600e22c 
> >> [0.00]  8a08a003 
> >> [0.00]  80a16001 
> >> [0.00]  0280003b 
> >> [0.00]  c600c001 
> >> [0.00] 
> >> [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
> >> [0.00] Press Stop-A (L1-A) from sun keyboard or send break
> >> [0.00] twice on console to return to the boot prom
> >> [0.00] ---[ end Kernel panic - not syncing: Attempted to kill the 
> >> idle task! ]---
> >> qemu-system-sparc: terminating on signal 15 from pid 13043 (killall)
> >>
> >> The NULL ptr dereference is done by memset() in srmmu_nocache_init() and 
> >> memblock_alloc_try_nid().
> >> If I comment both memset, the boot pass
> >>
> >> But since nothing explain the NULL ptr deref in memset(), I suspect 
> >> something is overriden by the initrd
> > 
> > Sorry about the delay in replying to this, I haven't been too well recently.
> > 
> > Looking at the code I suspect the problem is that when loading a kernel 
> > directly,
> > OpenBIOS isn't adding the kernel/initrd memory ranges to th

Re: [Qemu-devel] sparc: crash when using initrd > 5M

2019-02-05 Thread Corentin Labbe
On Tue, Feb 05, 2019 at 04:45:16PM +, Mark Cave-Ayland wrote:
> On 05/02/2019 09:11, Corentin Labbe wrote:
> 
> > On Fri, Feb 01, 2019 at 02:15:15PM +, Mark Cave-Ayland wrote:
> >> On 18/01/2019 13:33, Mark Cave-Ayland wrote:
> >>
> >>> On 03/01/2019 15:48, Corentin Labbe wrote:
> >>>
> >>>> Hello
> >>>>
> >>>> When using an initrd > 5M, I hit the following kernel crash:
> >>>> qemu-system-sparc -kernel vmlinux -initrd rootfs.cpio.gz -nographic
> >>>> Configuration device id QEMU version 1 machine id 32
> >>>> Probing SBus slot 0 offset 0
> >>>> Probing SBus slot 1 offset 0
> >>>> Probing SBus slot 2 offset 0
> >>>> Probing SBus slot 3 offset 0
> >>>> Probing SBus slot 4 offset 0
> >>>> Probing SBus slot 5 offset 0
> >>>> Invalid FCode start byte
> >>>> CPUs: 1 x FMI,MB86904
> >>>> UUID: ----
> >>>> Welcome to OpenBIOS v1.1 built on Oct 5 2018 08:20
> >>>>   Type 'help' for detailed information
> >>>> [sparc] Kernel already loaded
> >>>> switching to new context:
> >>>> PROMLIB: obio_ranges 1
> >>>> [0.00] PROMLIB: Sun Boot Prom Version 3 Revision 2
> >>>> [0.00] Linux version 4.20.0-next-20190102+ (compile@Red) (gcc 
> >>>> version 7.3.0 (Gentoo 7.3.0-r3 p1.4)) #148 Thu Jan 3 16:17:08 CET 2019
> >>>> [0.00] printk: bootconsole [earlyprom0] enabled
> >>>> [0.00] ARCH: SUN4M
> >>>> [0.00] TYPE: SPARCstation 5
> >>>> [0.00] Ethernet address: 52:54:00:12:34:56
> >>>> [0.00] Unable to handle kernel NULL pointer dereference
> >>>> [0.00] tsk->{mm,active_mm}->context = 
> >>>> [0.00] tsk->{mm,active_mm}->pgd = 
> >>>> [0.00]   \|/  \|/
> >>>> [0.00]   "@'/ ,. \`@"
> >>>> [0.00]   /_| \__/ |_\
> >>>> [0.00]  \__U_/
> >>>> [0.00] swapper(0): Oops [#1]
> >>>> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 
> >>>> 4.20.0-next-20190102+ #148
> >>>> [0.00] PSR: 04001fc0 PC: f0010ef0 NPC: f0010ef4 Y: 
> >>>> Not tainted
> >>>> [0.00] PC: 
> >>>> [0.00] %G: 000a 03c4  f05ece08 f05ecc00   
> >>>> 00e0  f05d4000 0001
> >>>> [0.00] %O:  00e0  0080 00e0   
> >>>> 0002  f05d5bb8 f00bba58
> >>>> [0.00] RPC: 
> >>>> [0.00] %L: 0040 f05dfaf8  f05d5c68 0001  0003 
> >>>> 006951e0  f05ed014 f0674ab4
> >>>> [0.00] %I: f05d5c80   0002 f100   
> >>>>   f05d5c20 f0007fd8
> >>>> [0.00] Disabling lock debugging due to kernel taint
> >>>> [0.00] Caller[f0007fd8]: srmmu_fault+0x58/0x68
> >>>> [0.00] Caller[f0618598]: memblock_alloc_try_nid+0xb8/0xc8
> >>>> [0.00] Caller[f0611094]: srmmu_paging_init+0x174/0xaf8
> >>>> [0.00] Caller[f06106a8]: paging_init+0x4/0x24
> >>>> [0.00] Caller[f060e4f0]: setup_arch+0x3e8/0x480
> >>>> [0.00] Caller[f060ab50]: start_kernel+0x48/0x460
> >>>> [0.00] Caller[f060a43c]: continue_boot+0x324/0x334
> >>>> [0.00] Caller[]:   (null)
> >>>> [0.00] Instruction DUMP:
> >>>> [0.00]  c800a024 
> >>>> [0.00]  83286002 
> >>>> [0.00]  073c17b3 
> >>>> [0.00] 
> >>>> [0.00]  c600e22c 
> >>>> [0.00]  8a08a003 
> >>>> [0.00]  80a16001 
> >>>> [0.00]  0280003b 
> >>>> [0.00]  c600c001 
> >>>> [0.00] 
> >>>> [0.00] Kernel panic - not syncing: Attempted to kill the idle 
> >>>> task!
> >>>> [0.00] Press Stop-A (L1-A) from sun keyboard or send break
> >>>> [0.00] twice on console to return to the boot prom
> >>>> [0.00] ---[ end Kernel panic - not syncing: Attemp

Re: [Qemu-devel] sparc: crash when using initrd > 5M

2019-02-06 Thread Corentin Labbe
On Wed, Feb 06, 2019 at 07:37:29AM +, Mark Cave-Ayland wrote:
> On 06/02/2019 07:28, Corentin Labbe wrote:
> 
> >>> Hello
> >>>
> >>> Sorry even with the patch I still hit the issue.
> >>>
> >>> I have added some debug and at least qemu set initrd_size correctly now.
> >>>
> >>> I have tried to compile openbios-sparc32 for debugging but fail with
> >>> arch/sparc32/context.c:116:5: error: PIC register clobbered by 'l7' in 
> >>> 'asm'
> >>>  asm __volatile__ ("\n\tcall __switch_context"
> >>>  ^~~
> >>> make[1]: *** [rules.mak:219: target/arch/sparc32/context.o] Error 1
> >>> (gcc 7.2 and gc 6.4 with binutils 2.30)
> >>
> >> Hmmm. One other thing I've noticed is that newer kernels tend need a 
> >> minimum of 256M
> >> RAM to start up - does it work if you add -m 256 to your command line?
> >>
> >>
> > 
> > I have already set 256M of RAM. (and tried 512)
> 
> I wonder then if this is being triggered by a recent kernel change? I tend to 
> test
> using the latest Debian ports ISOs which are currently running 4.9 and that 
> booted
> fine when I was testing the patches above.
> 
> Can you try with a few older kernels to see if this is the case?
> 
> 

Hello

Good catch, it boot fine with 4.9.99.

A start a long git bisect...

Regards



Re: [Qemu-devel] sparc: crash when using initrd > 5M

2019-02-06 Thread Corentin Labbe
On Wed, Feb 06, 2019 at 07:37:29AM +, Mark Cave-Ayland wrote:
> On 06/02/2019 07:28, Corentin Labbe wrote:
> 
> >>> Hello
> >>>
> >>> Sorry even with the patch I still hit the issue.
> >>>
> >>> I have added some debug and at least qemu set initrd_size correctly now.
> >>>
> >>> I have tried to compile openbios-sparc32 for debugging but fail with
> >>> arch/sparc32/context.c:116:5: error: PIC register clobbered by 'l7' in 
> >>> 'asm'
> >>>  asm __volatile__ ("\n\tcall __switch_context"
> >>>  ^~~
> >>> make[1]: *** [rules.mak:219: target/arch/sparc32/context.o] Error 1
> >>> (gcc 7.2 and gc 6.4 with binutils 2.30)
> >>
> >> Hmmm. One other thing I've noticed is that newer kernels tend need a 
> >> minimum of 256M
> >> RAM to start up - does it work if you add -m 256 to your command line?
> >>
> >>
> > 
> > I have already set 256M of RAM. (and tried 512)
> 
> I wonder then if this is being triggered by a recent kernel change? I tend to 
> test
> using the latest Debian ports ISOs which are currently running 4.9 and that 
> booted
> fine when I was testing the patches above.
> 
> Can you try with a few older kernels to see if this is the case?
> 

Hello

In fact the problem was due to .config since a defconfig works fine on 
next-20190205
After lots of diff I found that CONFIG_LOG_BUF_SHIFT=18 cause this behaviour.

Note that values of 16,17 cause also the same problem.

Regards



[Qemu-devel] Running linux on qemu omap

2019-05-20 Thread Corentin Labbe
Hello

I am working on adding a maximum set of qemu machine on kernelCI.

For OMAP, five machine exists and I fail to boot any of them.
The maximum I can get with omap1_defconfig is
qemu-system-arm -kernel zImage -nographic -machine cheetah -append 
'root=/dev/ram0 console=ttyO0'
Uncompressing Linux... done, booting the kernel.
then nothing more.

Does someone have a working config+version to share ?

Thanks
Regards



Re: [Qemu-devel] Running linux on qemu omap

2019-05-22 Thread Corentin Labbe
On Wed, May 22, 2019 at 02:23:23AM +0300, Aaro Koskinen wrote:
> Hi,
> 
> On Mon, May 20, 2019 at 09:05:33PM +0200, Corentin Labbe wrote:
> > Hello
> > 
> > I am working on adding a maximum set of qemu machine on kernelCI.
> 
> That's cool.
> 
> > For OMAP, five machine exists and I fail to boot any of them.
> 
> Which machines?

Hello

qemu-system-arm -M help |grep OMAP
cheetah  Palm Tungsten|E aka. Cheetah PDA (OMAP310)
n800 Nokia N800 tablet aka. RX-34 (OMAP2420)
n810 Nokia N810 tablet aka. RX-44 (OMAP2420)
sx1  Siemens SX1 (OMAP310) V2
sx1-v1   Siemens SX1 (OMAP310) V1

> 
> > The maximum I can get with omap1_defconfig is
> > qemu-system-arm -kernel zImage -nographic -machine cheetah -append 
> > 'root=/dev/ram0 console=ttyO0'
> > Uncompressing Linux... done, booting the kernel.
> > then nothing more.
> 
> It's known that omap1_defconfig doesn't work well for QEMU or
> "multi-board" usage. Perhaps the kernel size is now just too big?
> I'm using a custom config for every OMAP1 board anyway...
> 
> > Does someone have a working config+version to share ?
> 
> I have used the below config for OMAP1 SX1 board (the only one I got
> working with QEMU). Unfortunately the functionality is quite limited,
> but it still allows to run e.g. GCC bootstrap & testsuite, that is rare
> nowadays for armv4t.
> 
> I'm using the following command line with qemu-system-arm 3.1.0:
> 
> -M sx1 \
> -kernel "sx1-zImage" \
> -nographic \
> -drive file="sx1-mmc",if=sd,format=raw \
> -no-reboot
> 
> This should work with v5.1 kernel.
> 
> I'm also interested to run other OMAP kernels under QEMU, e.g. cheetah
> (the real device, Palm TE works OK with the current mainline), and it
> would be interesting to know why QEMU/kernel has regressed...
> 

thanks, with your config I was able to boot both sx1 and cheetah (by adding 
CONFIG_MACH_OMAP_PALMTE=y)
Now I need to find what is missing (or in excess) in omap1_defconfig to made it 
boot

Another obstacle is the disabling of the initrd, perhaps by using sdcard as an 
"initrd" will do the trick, but the sdcard is ignored for the moment.

(I have added linux-ker...@vger.kernel.org for larger audience in case of 
someone have n800/n810 working)

Regards

qemu-system-arm -kernel zImage -nographic -machine sx1 -append 'console=ttyS0 
root=/dev/sda' -m 256 -cpu ti925t -drive format=qcow2,file=disk.img,if=sd
omap_clkm_write: clocking scheme set to synchronous scalable
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.2.0-rc1-next-20190521-sx1+ (compile@Red) (gcc 
version 8.2.0 (Gentoo 8.2.0-r6 p1.7)) #7 Wed May 22 11:04:32 CEST 2019
[0.00] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=317f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: OMAP310 based Siemens SX1
[0.00] Ignoring tag cmdline (using the default kernel command line)
[0.00] Memory policy: Data cache writethrough
[0.00] OMAP0310 revision 2 handled as 15xx id: a8858bfac9581f0e
[0.00] Clocks: ARM_SYSST: 0x003a DPLL_CTL: 0x2002 ARM_CKCTL: 0x3000
[0.00] Clocking rate (xtal/DPLL1/MPU): 12.0/12.0/12.0 MHz
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 8128
[0.00] Kernel command line: mem=32M console=ttyS0,115200n8
[0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Memory: 30104K/32768K available (1680K kernel code, 91K rwdata, 
292K rodata, 104K init, 62K bss, 2664K reserved, 0K cma-reserved)
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] Total of 64 interrupts in 2 interrupt banks
[0.000435] sched_clock: 32 bits at 6MHz, resolution 166ns, wraps every 
357913940908ns
[0.000873] clocksource: mpu_timer2: mask: 0x max_cycles: 
0x, max_idle_ns: 318543407797 ns
[0.003038] Calibrating delay loop... 469.40 BogoMIPS (lpj=2347008)
[0.191676] pid_max: default: 4096 minimum: 301
[0.192828] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.192886] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.206350] *** VALIDATE proc ***
[0.206803] CPU: Testing write buffer coherency: ok
[0.222891] Setting up static identity map for 0x10008400 - 0x1000842c
[0.232941] devtmpfs: initialized
[0.240739] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.240916] futex hash table entries: 16 (order: -5, 192 bytes)
[0.245376] DMA: preallocated 256 KiB pool for ato