[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/6] tests/acceptance: Test the Fuloong 2E machine

From: BALATON Zoltan
Subject: Re: [PATCH 0/6] tests/acceptance: Test the Fuloong 2E machine
Date: Sun, 25 Oct 2020 15:30:07 +0100 (CET)

On Sun, 25 Oct 2020, Philippe Mathieu-Daudé wrote:
On 10/25/20 12:18 PM, Mark Cave-Ayland wrote:
On 21/10/2020 11:50, Philippe Mathieu-Daudé wrote:

This series add tests for the MIPS Fuloong 2E machine.

I have been using these tests for over 1 year now.
After recent discussions with Huacai and Mark regarding
how to contribute tests for machines using private blob,
I think it is time to publish this series, to see how
the final part will be discussed, as it tests a blob
which Lemote company doesn't publish the sources. The
binary is know to work and has been used for various
years on real hardware. Its MD5 is also know (I am not
using SHA-1 because it has been published with MD5).

The idea is to be able to share tests without infringing
licenses issues.

Please comment :)


Philippe Mathieu-Daudé (6):
   tests/acceptance: Remove unused import
   tests/acceptance: Use .ppm extention for Portable PixMap files
   tests/acceptance: Extract tesseract_available() helper in new
   tests/acceptance: Introduce tesseract_ocr() helper
   tests/acceptance: Test Linux on the Fuloong 2E machine
   tests/acceptance: Test PMON on the Fuloong 2E machine

  MAINTAINERS                                |   1 +
  tests/acceptance/machine_m68k_nextcube.py  |  51 ++---------
  tests/acceptance/machine_mips_fuloong2e.py | 101 +++++++++++++++++++++
  tests/acceptance/tesseract_utils.py        |  46 ++++++++++
  4 files changed, 158 insertions(+), 41 deletions(-)
  create mode 100644 tests/acceptance/machine_mips_fuloong2e.py
  create mode 100644 tests/acceptance/tesseract_utils.py

In general this looks good: certainly I don't see any reason why the tesseract_ocr helper changes shouldn't be merged, since I expect that this is something that will be used more in future.

Looking at the fuloong test it seems that it stops fairly early in the kernel boot: one of the problems that Zoltan's VIA southbridge patches were trying to solve earlier in the year was because of problems with PCI IRQ routing, so it would be nice to include a small OS image that can be used to boot to userspace to ensure that such problems can be detected in future.

The Linux tests (ab)use of the rescue image prepared for the Yeeloong
machine which we don't model (Loongson 2F CPU, 1GB of DRAM). The kernel
triggers DATA ABORT while accessing >256MB because we do not model
mapping more than 256MB :/ (The Fuloong comes with 512MB extensible to 1GB). I have a branch adding that but had the idea nobody was interested
in the Fuloong 2E so I didn't insist (I have more interest in embedded
32-bit CPUs). I might try to post it after the release, as it makes this
test complete.

I've noticed that missing high RAM when cleaning up SPD EEPROMs and addded a FIXME comment but did't know MIPS enough to attemt to fix it. Anyway I'm also only interested in fuloong2e as a test case for the devices also used by Pegasos2 (that I'll need to update and clean up to submit eventually) but not beyond that.

I haven't seen these patches before, so I've spotted only now that your test case uses -vga std. Shouldn't it work with ati-vga,model=rv100 which I think is the default for this machine and that's what the pmon firmware expects and has a driver for?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]