OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
379b42e8b7
qemu-e2k/target/xtensa/core-dc232b.c

53 lines
2.1 KiB
C
Raw Normal View History

target-xtensa: add license to core-dc232b.c Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2012-04-15 17:12:17 +02:00
/*
* Copyright (c) 2011, Max Filippov, Open Source and Linux Lab.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of the Open Source and Linux Lab nor the
* names of its contributors may be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
* DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
xtensa: Clean up includes Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1453832250-766-29-git-send-email-peter.maydell@linaro.org
2016-01-26 19:17:21 +01:00
#include "qemu/osdep.h"
target-xtensa: add dc232b core This is Diamond 232L Standard Core Rev.B (LE), implemented through linux/gdb overlay. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2011-10-16 00:56:05 +02:00
#include "cpu.h"
exec: move include files to include/exec/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-17 18:19:49 +01:00
#include "exec/gdbstub.h"
misc: move include files to include/qemu/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-17 18:20:00 +01:00
#include "qemu/host-utils.h"
target/xtensa: Include "qemu/timer.h" to use NANOSECONDS_PER_SECOND Since d0ce7e9cfc the dc232b structure uses the NANOSECONDS_PER_SECOND definition from "qemu/timer.h". Include it to allow further includes cleanup. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20180528232719.4721-7-f4bug@amsat.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-05-29 01:27:04 +02:00
#include "qemu/timer.h"
target-xtensa: add dc232b core This is Diamond 232L Standard Core Rev.B (LE), implemented through linux/gdb overlay. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2011-10-16 00:56:05 +02:00
#include "core-dc232b/core-isa.h"
#include "overlay_tool.h"
target/xtensa: switch dc232b to libisa Autogenerated xtensa-modules.c is added by the import_core.sh script. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2017-11-03 23:55:17 +01:00
#define xtensa_modules xtensa_modules_dc232b
meson: rename included C source files to .c.inc With Makefiles that have automatically generated dependencies, you generated includes are set as dependencies of the Makefile, so that they are built before everything else and they are available when first building the .c files. Alternatively you can use a fine-grained dependency, e.g. target/arm/translate.o: target/arm/decode-neon-shared.inc.c With Meson you have only one choice and it is a third option, namely "build at the beginning of the corresponding target"; the way you express it is to list the includes in the sources of that target. The problem is that Meson decides if something is a source vs. a generated include by looking at the extension: '.c', '.cc', '.m', '.C' are sources, while everything else is considered an include---including '.inc.c'. Use '.c.inc' to avoid this, as it is consistent with our other convention of using '.rst.inc' for included reStructuredText files. The editorconfig file is adjusted. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-04 12:41:01 +01:00
#include "core-dc232b/xtensa-modules.c.inc"
target/xtensa: switch dc232b to libisa Autogenerated xtensa-modules.c is added by the import_core.sh script. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2017-11-03 23:55:17 +01:00
target-xtensa: fix gdb register map construction Due to different gdb overlay organization between windowed/call0 configurations core import script doesn't always work correctly. Simplify the script: always copy complete gdb register map from overlay, count registers at core registerstion time. Update existing cores. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2015-07-01 12:00:29 +02:00
static XtensaConfig dc232b __attribute__((unused)) = {
target-xtensa: add dc232b core This is Diamond 232L Standard Core Rev.B (LE), implemented through linux/gdb overlay. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2011-10-16 00:56:05 +02:00
.name = "dc232b",
.gdb_regmap = {
.reg = {
meson: rename included C source files to .c.inc With Makefiles that have automatically generated dependencies, you generated includes are set as dependencies of the Makefile, so that they are built before everything else and they are available when first building the .c files. Alternatively you can use a fine-grained dependency, e.g. target/arm/translate.o: target/arm/decode-neon-shared.inc.c With Meson you have only one choice and it is a third option, namely "build at the beginning of the corresponding target"; the way you express it is to list the includes in the sources of that target. The problem is that Meson decides if something is a source vs. a generated include by looking at the extension: '.c', '.cc', '.m', '.C' are sources, while everything else is considered an include---including '.inc.c'. Use '.c.inc' to avoid this, as it is consistent with our other convention of using '.rst.inc' for included reStructuredText files. The editorconfig file is adjusted. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-02-04 12:41:01 +01:00
#include "core-dc232b/gdb-config.c.inc"
target-xtensa: add dc232b core This is Diamond 232L Standard Core Rev.B (LE), implemented through linux/gdb overlay. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2011-10-16 00:56:05 +02:00
}
},
target/xtensa: switch dc232b to libisa Autogenerated xtensa-modules.c is added by the import_core.sh script. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2017-11-03 23:55:17 +01:00
.isa_internal = &xtensa_modules,
target/xtensa: fix timers test The value of CCOUNT special register is calculated as time elapsed since CCOUNT == 0 multiplied by the core frequency. In icount mode time increment between consecutive instructions that don't involve time warps is constant, but unless the result of multiplication of this constant by the core frequency is a whole number the CCOUNT increment between these instructions may not be constant. E.g. with icount=7 each instruction takes 128ns, with core clock of 10MHz CCOUNT values for consecutive instructions are: 502: (128 * 502 * 10000000) / 1000000000 = 642.56 503: (128 * 503 * 10000000) / 1000000000 = 643.84 504: (128 * 504 * 10000000) / 1000000000 = 645.12 I.e.the CCOUNT increments depend on the absolute time. This results in varying CCOUNT differences for consecutive instructions in tests that involve time warps and don't set CCOUNT explicitly. Change frequency of the core used in tests so that clock cycle takes exactly 64ns. Change icount power used in tests to 6, so that each instruction takes exactly 1 clock cycle. With these changes CCOUNT increments only depend on the number of executed instructions and that's what timer tests expect, so they work correctly. Longer story: http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg04326.html Cc: Pavel Dovgaluk <Pavel.Dovgaluk@ispras.ru> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2018-03-23 13:56:19 +01:00
.clock_freq_khz = (NANOSECONDS_PER_SECOND / 64) / 1000,
target-xtensa: refactor standard core configuration Coalesce all standard configuration sections into single DEFAULT_SECTIONS macro for all cores. This allows to add new features in a single place: overlay_tool.h Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2014-02-15 17:58:47 +01:00
DEFAULT_SECTIONS
target-xtensa: add dc232b core This is Diamond 232L Standard Core Rev.B (LE), implemented through linux/gdb overlay. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
2011-10-16 00:56:05 +02:00
};
REGISTER_CORE(dc232b)
Reference in New Issue Copy Permalink