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 [email protected] 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.000000] Booting Linux on physical CPU 0x0
[ 0.000000] 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.000000] CPU: ARM925T [54029252] revision 2 (ARMv4T), cr=0000317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: OMAP310 based Siemens SX1
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] Memory policy: Data cache writethrough
[ 0.000000] OMAP0310 revision 2 handled as 15xx id: a8858bfac9581f0e
[ 0.000000] Clocks: ARM_SYSST: 0x003a DPLL_CTL: 0x2002 ARM_CKCTL: 0x3000
[ 0.000000] Clocking rate (xtal/DPLL1/MPU): 12.0/12.0/12.0 MHz
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 8128
[ 0.000000] Kernel command line: mem=32M console=ttyS0,115200n8
[ 0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Memory: 30104K/32768K available (1680K kernel code, 91K rwdata, 292K rodata, 104K init, 62K bss, 2664K reserved, 0K cma-reserved)
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] 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: 0xffffffff max_cycles: 0xffffffff, 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: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.240916] futex hash table entries: 16 (order: -5, 192 bytes)
[ 0.245376] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.259782] omap_gpio omap_gpio.0: Runtime PM disabled, clock forced on.
[ 0.265624] irq: Cannot allocate irq_descs @ IRQ80, assuming pre-allocated
[ 0.273854] irq: Cannot allocate irq_descs @ IRQ96, assuming pre-allocated
[ 0.276477] MUX: Setting register UART1_TX
[ 0.276528] FUNC_MUX_CTRL_9 (0xfffe1028) = 0x00000000 -> 0x00200000
[ 0.276572] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00000000 -> 0x00000008
[ 0.276616] MUX: Setting register UART1_RTS
[ 0.276639] FUNC_MUX_CTRL_9 (0xfffe1028) = 0x00200000 -> 0x00201000
[ 0.276663] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00000008 -> 0x00000009
[ 0.276689] MUX: Setting register UART2_TX
[ 0.276713] FUNC_MUX_CTRL_C (0xfffe1034) = 0x00000000 -> 0x08000000
[ 0.276736] PULL_DWN_CTRL_3 (0xfffe104c) = 0x00000000 -> 0x00000008
[ 0.276765] MUX: Setting register UART2_RTS
[ 0.276790] FUNC_MUX_CTRL_C (0xfffe1034) = 0x08000000 -> 0x09000000
[ 0.276813] PULL_DWN_CTRL_3 (0xfffe104c) = 0x00000008 -> 0x0000000c
[ 0.276839] MUX: Setting register UART3_TX
[ 0.276863] FUNC_MUX_CTRL_6 (0xfffe101c) = 0x00000000 -> 0x00000001
[ 0.276886] PULL_DWN_CTRL_0 (0xfffe1040) = 0x00000000 -> 0x40000000
[ 0.278190] MUX: Setting register MMC_CMD
[ 0.278220] FUNC_MUX_CTRL_A (0xfffe102c) = 0x00000000 -> 0x00000000
[ 0.278246] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00000009 -> 0x00000009
[ 0.278275] MUX: Setting register MMC_CLK
[ 0.278303] FUNC_MUX_CTRL_A (0xfffe102c) = 0x00000000 -> 0x00000000
[ 0.278333] MUX: Setting register MMC_DAT0
[ 0.278359] FUNC_MUX_CTRL_B (0xfffe1030) = 0x00000000 -> 0x00000000
[ 0.278391] PULL_DWN_CTRL_2 (0xfffe1048) = 0x00000009 -> 0x00000009
[ 0.282369] Clocking rate (xtal/DPLL1/MPU): 12.0/120.0/120.0 MHz
[ 0.284362] DMA support for OMAP15xx initialized
[ 0.305623] omap-dma-engine omap-dma-engine: failed to get L1 IRQ: -6
[ 0.345197] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[ 0.350775] SCSI subsystem initialized
[ 0.352338] omap_i2c omap_i2c.1: Runtime PM disabled, clock forced on.
[ 0.352387] omap_i2c omap_i2c.1: Runtime PM disabled, clock forced on.
[ 0.354801] omap_i2c omap_i2c.1: bus 1 rev1.1 at 100 kHz
[ 0.356226] clocksource: Switched to clocksource mpu_timer2
[ 0.373816] workingset: timestamp_bits=30 max_order=13 bucket_order=0
[ 0.376643] io scheduler bfq registered
[ 0.380205] Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
[ 0.391718] printk: console [ttyS0] disabled
[ 0.599303] serial8250.0: ttyS0 at MMIO 0xfffb0000 (irq = 62, base_baud = 750000) is a 16550A
[ 0.632021] printk: console [ttyS0] enabled
[ 0.837594] serial8250.0: ttyS1 at MMIO 0xfffb0800 (irq = 63, base_baud = 750000) is a 16550A
[ 1.044254] serial8250.0: ttyS2 at MMIO 0xfffb9800 (irq = 31, base_baud = 750000) is a 16550A
[ 1.047921] i2c /dev entries driver
[ 1.050288] mmci-omap mmci-omap.0: Runtime PM disabled, clock forced on.
[ 1.050782] mmci-omap mmci-omap.0: Runtime PM disabled, clock forced on.
[ 1.090290] clock: disabling unused clocks to save power
[ 1.090838] Skipping reset check for DSP domain clock "dsptim_ck"
[ 1.091249] Skipping reset check for DSP domain clock "dspxor_ck"
[ 1.091646] Skipping reset check for DSP domain clock "dspper_ck"
[ 1.092421] random: get_random_bytes called from 0xc0018860 with crng_init=0
[ 1.095384] mmci-omap mmci-omap.0: command timeout (CMD52)
[ 1.096356] mmci-omap mmci-omap.0: command timeout (CMD52)
[ 1.101963] hctosys: unable to open rtc device (rtc0)
[ 1.113769] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 1.114266] Please append a correct "root=" boot option; here are the available partitions:
[ 1.115058] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 1.116009] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
Hi,
On Wed, May 22, 2019 at 11:33:41AM +0200, Corentin Labbe wrote:
> 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.
With N800/N810 omap2plus_defconfig should be used instead. However,
I don't think that works either (but haven't tried recently). Also with
N800/N810 you need to append the DTB file to the kernel image.
> thanks, with your config I was able to boot both sx1 and cheetah
> (by adding CONFIG_MACH_OMAP_PALMTE=y)
Great!
> Now I need to find what is missing (or in excess) in omap1_defconfig
> to made it boot
A simple (but slow) way would be to start adding config options from
omap1_defconfig one by one to the working config, and see which one
makes it fail.
> 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.
Using CONFIG_INITRAMFS_SOURCE it's possible to include a file system
inside the kernel image.
Based on your boot log, I think the kernel probably panics before the
MMC/sdcard is found (asynchronous probe). You could try adding rootwait
to the kernel command line. (My config has CONFIG_CMDLINE_FORCE=y, so
you need to add it to CONFIG_CMDLINE, as QEMU -append gets ignored). Also
the sdcard will appear as /dev/mmcblk0 instead of /dev/sda.
The sdcard is working fine for me, and it can be used to run a full-blown
distro rootfs; I don't know what is the capacity limit in the MMC driver
but at least 16 GB image is working fine:
[ 2.011012] mmc0: new SDHC card at address 4567
[ 2.016419] mmcblk0: mmc0:4567 QEMU! 16.0 GiB
A.
On 22/05/2019 20.19, Aaro Koskinen wrote:
> Hi,
>
> On Wed, May 22, 2019 at 11:33:41AM +0200, Corentin Labbe wrote:
>> 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.
>
> With N800/N810 omap2plus_defconfig should be used instead. However,
> I don't think that works either (but haven't tried recently). Also with
> N800/N810 you need to append the DTB file to the kernel image.
FWIW, Philippe recently posted a mail how to run older kernels on n810:
https://www.mail-archive.com/[email protected]/msg610653.html
HTH,
Thomas
On 5/23/19 1:27 PM, Thomas Huth wrote:
> On 22/05/2019 20.19, Aaro Koskinen wrote:
>> Hi,
>>
>> On Wed, May 22, 2019 at 11:33:41AM +0200, Corentin Labbe wrote:
>>> 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.
>>
>> With N800/N810 omap2plus_defconfig should be used instead. However,
>> I don't think that works either (but haven't tried recently). Also with
>> N800/N810 you need to append the DTB file to the kernel image.
>
> FWIW, Philippe recently posted a mail how to run older kernels on n810:
>
> https://www.mail-archive.com/[email protected]/msg610653.html
What I use as reference for testing ARM boards [*] is the work of
Guenter Roeck:
https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh
However I can see than none of the board listed by Corentin are tested
... That reminder me I never succeed at using the Cheetah PDA. So the
OMAP310 is probably bitroting in QEMU...
[*] and slowly add to upstream patches he sent that fell through the
cracks of qemu-devel.
Regards,
Phil.
Hi,
On Thu, May 23, 2019 at 02:00:41PM +0200, Philippe Mathieu-Daud? wrote:
> On 5/23/19 1:27 PM, Thomas Huth wrote:
> > On 22/05/2019 20.19, Aaro Koskinen wrote:
> >> On Wed, May 22, 2019 at 11:33:41AM +0200, Corentin Labbe wrote:
> >>> 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.
> >>
> >> With N800/N810 omap2plus_defconfig should be used instead. However,
> >> I don't think that works either (but haven't tried recently). Also with
> >> N800/N810 you need to append the DTB file to the kernel image.
> >
> > FWIW, Philippe recently posted a mail how to run older kernels on n810:
> >
> > https://www.mail-archive.com/[email protected]/msg610653.html
So it seems the issue with N8x0 is that serial console does not work.
And we are missing the display support in the mainline kernel.
> However I can see than none of the board listed by Corentin are tested
> ... That reminder me I never succeed at using the Cheetah PDA. So the
> OMAP310 is probably bitroting in QEMU...
Cheetah works with serial console. I tried with console on display,
and it seems to boot up, and the frame buffer window gets correctly
sized but for some reason it just stays blank.
A.
On Thu, 23 May 2019 at 19:36, Aaro Koskinen <[email protected]> wrote:
> Cheetah works with serial console. I tried with console on display,
> and it seems to boot up, and the frame buffer window gets correctly
> sized but for some reason it just stays blank.
As a general question, when you're doing these tests are you
using a kernel image that is known to work on real hardware?
One problem we have with some of these older QEMU platforms
is that it turns out that QEMU is only tested with the kernel,
and the kernel support for the platform is only tested with
QEMU, and so you get equal and opposite bugs in QEMU and the
kernel that cancel each other out and don't get noticed...
(On the QEMU side these platforms are all basically orphaned:
if somebody submits patches to fix bugs we'll review them,
but they're unlikely to get a great deal of attention otherwise.
They're also quite near the top of the "maybe we'll just
deprecate and then delete these" list, since we have not
historically had any working guest images to test against.
If there's a real userbase that wants them to continue to
exist that's a different matter, of course.)
thanks
- PMM
Hi,
On Fri, May 24, 2019 at 10:08:09AM +0100, Peter Maydell wrote:
> On Thu, 23 May 2019 at 19:36, Aaro Koskinen <[email protected]> wrote:
> > Cheetah works with serial console. I tried with console on display,
> > and it seems to boot up, and the frame buffer window gets correctly
> > sized but for some reason it just stays blank.
>
> As a general question, when you're doing these tests are you
> using a kernel image that is known to work on real hardware?
With Cheetah (I wonder where that name comes from?), yes, same for
N8x0. SX1 I don't have, but the SoC is the same as on Palm TE.
> One problem we have with some of these older QEMU platforms
> is that it turns out that QEMU is only tested with the kernel,
> and the kernel support for the platform is only tested with
> QEMU, and so you get equal and opposite bugs in QEMU and the
> kernel that cancel each other out and don't get noticed...
>
> (On the QEMU side these platforms are all basically orphaned:
> if somebody submits patches to fix bugs we'll review them,
> but they're unlikely to get a great deal of attention otherwise.
> They're also quite near the top of the "maybe we'll just
> deprecate and then delete these" list, since we have not
> historically had any working guest images to test against.
> If there's a real userbase that wants them to continue to
> exist that's a different matter, of course.)
Please don't delete OMAP boards quite yet :) In the mainline kernel
they are not orphaned, they frequently get tested using actual hardware,
and QEMU would help in additional testing. I'll try to get N8x0 boot to
work with the minimal kernel I use on real HW.
Regarding N8x0 and bluetooth (mentioned in one of the linked threads), I
guess the removal of the bluetooth subsystem can be done without removing
the whole machine: just don't pass the OMAP BT TAG to the kernel anymore,
and it should ignore the BT hardware (just an idea based on quick read
of vendor kernel sources, the mainline kernel does not support BT on
this board).
A.
Hi,
On Fri, May 24, 2019 at 06:00:18PM +0300, Aaro Koskinen wrote:
> Please don't delete OMAP boards quite yet :) In the mainline kernel
> they are not orphaned, they frequently get tested using actual hardware,
> and QEMU would help in additional testing. I'll try to get N8x0 boot to
> work with the minimal kernel I use on real HW.
So it was only a matter of attaching the serial console at the QEMU side
(a hackish patch at the end of the mail).
$ qemu-system-arm --version
QEMU emulator version 4.0.0 (v4.0.0-dirty)
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
$ qemu-system-arm -M n810 -kernel zImage -nographic
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.1.0-n8x0_tiny-los_b1ac4+-00007-g7435e73d8ac4 (aaro@amd-fx-6350) (gcc version 8.3.0 (GCC)) #1 Fri May 24 20:43:02 EEST 2019
[ 0.000000] CPU: ARMv6-compatible processor [4107b362] revision 2 (ARMv6TEJ), cr=00c5387d
[ 0.000000] CPU: VIPT aliasing data cache, unknown instruction cache
[ 0.000000] OF: fdt: Machine model: Nokia N810
[ 0.000000] printk: bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] OMAP2420
[...]
However there are plenty of WARNs that are not present on real hardware.
Anyway, it's a start.
A.
...
diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
index 906b7ca22d43..52ff83ec5147 100644
--- a/hw/arm/nseries.c
+++ b/hw/arm/nseries.c
@@ -792,6 +792,7 @@ static void n8x0_uart_setup(struct n800_s *s)
qdev_connect_gpio_out(s->mpu->gpio, N8X0_BT_WKUP_GPIO,
csrhci_pins_get(radio)[csrhci_pin_wakeup]);
+ omap_uart_attach(s->mpu->uart[2], serial_hd(0));
omap_uart_attach(s->mpu->uart[BT_UART], radio);
}
On 24/05/2019 20.59, Aaro Koskinen wrote:
> Hi,
>
> On Fri, May 24, 2019 at 06:00:18PM +0300, Aaro Koskinen wrote:
>> Please don't delete OMAP boards quite yet :) In the mainline kernel
>> they are not orphaned, they frequently get tested using actual hardware,
>> and QEMU would help in additional testing. I'll try to get N8x0 boot to
>> work with the minimal kernel I use on real HW.
>
> So it was only a matter of attaching the serial console at the QEMU side
> (a hackish patch at the end of the mail).
Does not look too much hackish to me. Could you please send it as a
proper patch to the list (with patch description and Signed-off-by line)?
Thomas
>
> diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
> index 906b7ca22d43..52ff83ec5147 100644
> --- a/hw/arm/nseries.c
> +++ b/hw/arm/nseries.c
> @@ -792,6 +792,7 @@ static void n8x0_uart_setup(struct n800_s *s)
> qdev_connect_gpio_out(s->mpu->gpio, N8X0_BT_WKUP_GPIO,
> csrhci_pins_get(radio)[csrhci_pin_wakeup]);
>
> + omap_uart_attach(s->mpu->uart[2], serial_hd(0));
> omap_uart_attach(s->mpu->uart[BT_UART], radio);
> }
>
>
Hi,
* Philippe Mathieu-Daudé <[email protected]> [190523 12:01]:
> What I use as reference for testing ARM boards [*] is the work of
> Guenter Roeck:
> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh
I think Guenter also has v2.3.50-local-linaro branch in his
github repo that has support for few extra boards like Beagleboard.
Not sure what's the current branch to use though.
Regards,
Tony
On 5/26/19 11:32 PM, Tony Lindgren wrote:
> Hi,
>
> * Philippe Mathieu-Daudé <[email protected]> [190523 12:01]:
>> What I use as reference for testing ARM boards [*] is the work of
>> Guenter Roeck:
>> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh
>
> I think Guenter also has v2.3.50-local-linaro branch in his
> github repo that has support for few extra boards like Beagleboard.
> Not sure what's the current branch to use though.
>
I'd be happy to use a different (supported) branch, but the Linaro branch
was the only one I could find that supports those boards. Unfortunately,
qemu changed so much since 2.3 that it is all but impossible to merge
the code into mainline qemu without spending a lot of effort on it.
Guenter
On 5/27/19 5:56 PM, Guenter Roeck wrote:
> On 5/26/19 11:32 PM, Tony Lindgren wrote:
>> Hi,
>>
>> * Philippe Mathieu-Daudé <[email protected]> [190523 12:01]:
>>> What I use as reference for testing ARM boards [*] is the work of
>>> Guenter Roeck:
>>> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh
>>>
>>
>> I think Guenter also has v2.3.50-local-linaro branch in his
>> github repo that has support for few extra boards like Beagleboard.
>> Not sure what's the current branch to use though.
>>
> I'd be happy to use a different (supported) branch, but the Linaro branch
> was the only one I could find that supports those boards. Unfortunately,
> qemu changed so much since 2.3 that it is all but impossible to merge
> the code into mainline qemu without spending a lot of effort on it.
Peter commented on that here:
https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00137.html
"This is not a trivial job (my estimate was that it would be a couple
of months work to get the complete set sorted out and upstreamed ..."
On Mon, 27 May 2019 at 16:56, Guenter Roeck <[email protected]> wrote:
> I'd be happy to use a different (supported) branch, but the Linaro branch
> was the only one I could find that supports those boards. Unfortunately,
> qemu changed so much since 2.3 that it is all but impossible to merge
> the code into mainline qemu without spending a lot of effort on it.
Even back at 2.3 it wasn't possible to merge the code into mainline
without spending a lot of effort -- that's why it was not merged :-)
thanks
-- PMM