On 30 November 2017 at 12:40, Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 30/11/2017 13:14, Peter Maydell wrote:
>> On 30 November 2017 at 08:53, Thomas Huth <th...@redhat.com> wrote:
>>> +static const uint8_t kernel_mcf5208[] = {
>>> + 0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc060000,%a0 */
>>> + 0x10, 0x3c, 0x00, 0x54, /* move.b #'T',%d0 */
>>> + 0x11, 0x7c, 0x00, 0x04, 0x00, 0x08, /* move.b #4,8(%a0) Enable
>>> TX */
>>> + 0x11, 0x40, 0x00, 0x0c, /* move.b %d0,12(%a0) Print
>>> 'T' */
>>> + 0x60, 0xfa /* bra.s loop */
>>> +};
>>
>> This approach doesn't seem to be scalable to me -- are we
>> really going to have 50 or more fragments of hand-coded hex in
>> this file to cover the various board models?
>>
>> I'd much rather see us have a framework for being able
>> to build test blobs from source using a cross compiler
>> setup (and docker or similar so anybody can rebuild
>> the test blobs). That will be much easier to maintain
>> and easier to extend to having tests that test other
>> parts of the board or other aspects of TCG emulation.
>
> It seems a bit overkill, as these snippets are ~16 bytes long.
They're 16 bytes long because that's about the limit of
what you can do with this approach. The consequence is that
they barely test anything at all. A more sensible framework
would allow:
* better testing of TCG instructions more generally
* writing your test cases in C
* more interesting board dependent tests
* "integration test" setups like 'boot entire kernel'
* etc
thanks
-- PMM
