* [PATCH] sim: bfin: new port
@ 2010-11-16 1:41 Mike Frysinger
2010-12-31 23:12 ` [PATCH v2] " Mike Frysinger
0 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2010-11-16 1:41 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1.1: Type: text/plain, Size: 10787 bytes --]
Here is the Blackfin sim port. It is too large to post uncompressed, so it is
attached. Any feedback would be good :).
The testsuite isn't included yet as it needs a bit of a clean up, common sim
changes, and is pretty huge all by itself.
include/gdb/:
2010-11-16 Mike Frysinger <vapier@gentoo.org>
* sim-bfin.h: New file.
sim/:
2010-11-16 Mike Frysinger <vapier@gentoo.org>
* MAINTAINERS: Add bfin entry.
* configure.tgt (bfin-*-*): Handle bfin targets.
* configure: Regenerate.
sim/bfin/:
2010-11-16 Mike Frysinger <vapier@gentoo.org>
* Makefile.in, TODO, _insn_list.h, _proc_list.h, aclocal.m4,
bfin-dis.c, bfin-sim.c, bfin-sim.h, bfroms/all.h, bfroms/bf51x-0.0.h,
bfroms/bf51x-0.1.h, bfroms/bf51x-0.2.h, bfroms/bf526-0.0.h,
bfroms/bf526-0.1.h, bfroms/bf527-0.0.h, bfroms/bf527-0.1.h,
bfroms/bf527-0.2.h, bfroms/bf533-0.1.h, bfroms/bf533-0.2.h,
bfroms/bf533-0.3.h, bfroms/bf537-0.0.h, bfroms/bf537-0.1.h,
bfroms/bf537-0.3.h, bfroms/bf538-0.0.h, bfroms/bf54x-0.0.h,
bfroms/bf54x-0.1.h, bfroms/bf54x-0.2.h, bfroms/bf54x_l1-0.0.h,
bfroms/bf54x_l1-0.1.h, bfroms/bf54x_l1-0.2.h, bfroms/bf561-0.5.h,
config.in, configure, configure.ac, devices.c, devices.h,
dv-bfin_cec.c, dv-bfin_cec.h, dv-bfin_ctimer.c, dv-bfin_ctimer.h,
dv-bfin_dma.c, dv-bfin_dma.h, dv-bfin_dmac.c, dv-bfin_dmac.h,
dv-bfin_ebiu_amc.c, dv-bfin_ebiu_amc.h, dv-bfin_ebiu_ddrc.c,
dv-bfin_ebiu_ddrc.h, dv-bfin_ebiu_sdc.c, dv-bfin_ebiu_sdc.h,
dv-bfin_emac.c, dv-bfin_emac.h, dv-bfin_eppi.c, dv-bfin_eppi.h,
dv-bfin_evt.c, dv-bfin_evt.h, dv-bfin_gptimer.c, dv-bfin_gptimer.h,
dv-bfin_mmu.c, dv-bfin_mmu.h, dv-bfin_nfc.c, dv-bfin_nfc.h,
dv-bfin_otp.c, dv-bfin_otp.h, dv-bfin_pll.c, dv-bfin_pll.h,
dv-bfin_ppi.c, dv-bfin_ppi.h, dv-bfin_rtc.c, dv-bfin_rtc.h,
dv-bfin_sic.c, dv-bfin_sic.h, dv-bfin_spi.c, dv-bfin_spi.h,
dv-bfin_trace.c, dv-bfin_trace.h, dv-bfin_twi.c, dv-bfin_twi.h,
dv-bfin_uart.c, dv-bfin_uart.h, dv-bfin_uart2.c, dv-bfin_uart2.h,
dv-bfin_wdog.c, dv-bfin_wdog.h, dv-eth_phy.c, gui.c, gui.h, interp.c,
machs.c, machs.h, sim-main.h, tconfig.in: New Blackfin port.
sim/common/:
2010-11-16 Mike Frysinger <vapier@gentoo.org>
* gennltvals.sh: Handle bfin targets.
* nltvals.def: Regenerate.
---
include/gdb/sim-bfin.h | 84 +
sim/MAINTAINERS | 1 +
sim/bfin/Makefile.in | 82 +
sim/bfin/TODO | 16 +
sim/bfin/_insn_list.h | 38 +
sim/bfin/_proc_list.h | 30 +
sim/bfin/aclocal.m4 | 171 +
sim/bfin/bfin-dis.c | 3485 +++++++++++++++++
sim/bfin/bfin-sim.c | 6050 +++++++++++++++++++++++++++++
sim/bfin/bfin-sim.h | 345 ++
sim/bfin/bfroms/all.h | 37 +
sim/bfin/bfroms/bf51x-0.0.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf51x-0.1.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf51x-0.2.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf526-0.0.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf526-0.1.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf527-0.0.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf527-0.1.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf527-0.2.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf533-0.1.h | 131 +
sim/bfin/bfroms/bf533-0.2.h | 131 +
sim/bfin/bfroms/bf533-0.3.h | 131 +
sim/bfin/bfroms/bf537-0.0.h | 259 ++
sim/bfin/bfroms/bf537-0.1.h | 259 ++
sim/bfin/bfroms/bf537-0.3.h | 259 ++
sim/bfin/bfroms/bf538-0.0.h | 131 +
sim/bfin/bfroms/bf54x-0.0.h | 515 +++
sim/bfin/bfroms/bf54x-0.1.h | 515 +++
sim/bfin/bfroms/bf54x-0.2.h | 515 +++
sim/bfin/bfroms/bf54x_l1-0.0.h | 8195 ++++++++++++++++++++++++++++++++++++++++
sim/bfin/bfroms/bf54x_l1-0.1.h | 8195 ++++++++++++++++++++++++++++++++++++++++
sim/bfin/bfroms/bf54x_l1-0.2.h | 8195 ++++++++++++++++++++++++++++++++++++++++
sim/bfin/bfroms/bf561-0.5.h | 259 ++
sim/bfin/config.in | 158 +
sim/bfin/configure | 6831 +++++++++++++++++++++++++++++++++
sim/bfin/configure.ac | 73 +
sim/bfin/devices.c | 158 +
sim/bfin/devices.h | 144 +
sim/bfin/dv-bfin_cec.c | 800 ++++
sim/bfin/dv-bfin_cec.h | 139 +
sim/bfin/dv-bfin_ctimer.c | 267 ++
sim/bfin/dv-bfin_ctimer.h | 33 +
sim/bfin/dv-bfin_dma.c | 554 +++
sim/bfin/dv-bfin_dma.h | 65 +
sim/bfin/dv-bfin_dmac.c | 445 +++
sim/bfin/dv-bfin_dmac.h | 32 +
sim/bfin/dv-bfin_ebiu_amc.c | 242 ++
sim/bfin/dv-bfin_ebiu_amc.h | 32 +
sim/bfin/dv-bfin_ebiu_ddrc.c | 184 +
sim/bfin/dv-bfin_ebiu_ddrc.h | 27 +
sim/bfin/dv-bfin_ebiu_sdc.c | 201 +
sim/bfin/dv-bfin_ebiu_sdc.h | 40 +
sim/bfin/dv-bfin_emac.c | 603 +++
sim/bfin/dv-bfin_emac.h | 61 +
sim/bfin/dv-bfin_eppi.c | 271 ++
sim/bfin/dv-bfin_eppi.h | 30 +
sim/bfin/dv-bfin_evt.c | 153 +
sim/bfin/dv-bfin_evt.h | 31 +
sim/bfin/dv-bfin_gptimer.c | 183 +
sim/bfin/dv-bfin_gptimer.h | 27 +
sim/bfin/dv-bfin_mmu.c | 508 +++
sim/bfin/dv-bfin_mmu.h | 93 +
sim/bfin/dv-bfin_nfc.c | 245 ++
sim/bfin/dv-bfin_nfc.h | 41 +
sim/bfin/dv-bfin_otp.c | 270 ++
sim/bfin/dv-bfin_otp.h | 79 +
sim/bfin/dv-bfin_pll.c | 187 +
sim/bfin/dv-bfin_pll.h | 27 +
sim/bfin/dv-bfin_ppi.c | 231 ++
sim/bfin/dv-bfin_ppi.h | 32 +
sim/bfin/dv-bfin_rtc.c | 194 +
sim/bfin/dv-bfin_rtc.h | 27 +
sim/bfin/dv-bfin_sic.c | 1381 +++++++
sim/bfin/dv-bfin_sic.h | 27 +
sim/bfin/dv-bfin_spi.c | 230 ++
sim/bfin/dv-bfin_spi.h | 54 +
sim/bfin/dv-bfin_trace.c | 285 ++
sim/bfin/dv-bfin_trace.h | 37 +
sim/bfin/dv-bfin_twi.c | 227 ++
sim/bfin/dv-bfin_twi.h | 38 +
sim/bfin/dv-bfin_uart.c | 437 +++
sim/bfin/dv-bfin_uart.h | 49 +
sim/bfin/dv-bfin_uart2.c | 258 ++
sim/bfin/dv-bfin_uart2.h | 33 +
sim/bfin/dv-bfin_wdog.c | 206 +
sim/bfin/dv-bfin_wdog.h | 37 +
sim/bfin/dv-eth_phy.c | 206 +
sim/bfin/gui.c | 286 ++
sim/bfin/gui.h | 50 +
sim/bfin/interp.c | 790 ++++
sim/bfin/machs.c | 1149 ++++++
sim/bfin/machs.h | 52 +
sim/bfin/sim-main.h | 116 +
sim/bfin/tconfig.in | 27 +
sim/common/gennltvals.sh | 4 +
sim/common/nltvals.def | 30 +
sim/configure | 8 +
sim/configure.tgt | 3 +
98 files changed, 90559 insertions(+), 0 deletions(-)
create mode 100644 include/gdb/sim-bfin.h
create mode 100644 sim/bfin/Makefile.in
create mode 100644 sim/bfin/TODO
create mode 100644 sim/bfin/_insn_list.h
create mode 100644 sim/bfin/_proc_list.h
create mode 100644 sim/bfin/aclocal.m4
create mode 100644 sim/bfin/bfin-dis.c
create mode 100644 sim/bfin/bfin-sim.c
create mode 100644 sim/bfin/bfin-sim.h
create mode 100644 sim/bfin/bfroms/all.h
create mode 100644 sim/bfin/bfroms/bf51x-0.0.h
create mode 100644 sim/bfin/bfroms/bf51x-0.1.h
create mode 100644 sim/bfin/bfroms/bf51x-0.2.h
create mode 100644 sim/bfin/bfroms/bf526-0.0.h
create mode 100644 sim/bfin/bfroms/bf526-0.1.h
create mode 100644 sim/bfin/bfroms/bf527-0.0.h
create mode 100644 sim/bfin/bfroms/bf527-0.1.h
create mode 100644 sim/bfin/bfroms/bf527-0.2.h
create mode 100644 sim/bfin/bfroms/bf533-0.1.h
create mode 100644 sim/bfin/bfroms/bf533-0.2.h
create mode 100644 sim/bfin/bfroms/bf533-0.3.h
create mode 100644 sim/bfin/bfroms/bf537-0.0.h
create mode 100644 sim/bfin/bfroms/bf537-0.1.h
create mode 100644 sim/bfin/bfroms/bf537-0.3.h
create mode 100644 sim/bfin/bfroms/bf538-0.0.h
create mode 100644 sim/bfin/bfroms/bf54x-0.0.h
create mode 100644 sim/bfin/bfroms/bf54x-0.1.h
create mode 100644 sim/bfin/bfroms/bf54x-0.2.h
create mode 100644 sim/bfin/bfroms/bf54x_l1-0.0.h
create mode 100644 sim/bfin/bfroms/bf54x_l1-0.1.h
create mode 100644 sim/bfin/bfroms/bf54x_l1-0.2.h
create mode 100644 sim/bfin/bfroms/bf561-0.5.h
create mode 100644 sim/bfin/config.in
create mode 100755 sim/bfin/configure
create mode 100644 sim/bfin/configure.ac
create mode 100644 sim/bfin/devices.c
create mode 100644 sim/bfin/devices.h
create mode 100644 sim/bfin/dv-bfin_cec.c
create mode 100644 sim/bfin/dv-bfin_cec.h
create mode 100644 sim/bfin/dv-bfin_ctimer.c
create mode 100644 sim/bfin/dv-bfin_ctimer.h
create mode 100644 sim/bfin/dv-bfin_dma.c
create mode 100644 sim/bfin/dv-bfin_dma.h
create mode 100644 sim/bfin/dv-bfin_dmac.c
create mode 100644 sim/bfin/dv-bfin_dmac.h
create mode 100644 sim/bfin/dv-bfin_ebiu_amc.c
create mode 100644 sim/bfin/dv-bfin_ebiu_amc.h
create mode 100644 sim/bfin/dv-bfin_ebiu_ddrc.c
create mode 100644 sim/bfin/dv-bfin_ebiu_ddrc.h
create mode 100644 sim/bfin/dv-bfin_ebiu_sdc.c
create mode 100644 sim/bfin/dv-bfin_ebiu_sdc.h
create mode 100644 sim/bfin/dv-bfin_emac.c
create mode 100644 sim/bfin/dv-bfin_emac.h
create mode 100644 sim/bfin/dv-bfin_eppi.c
create mode 100644 sim/bfin/dv-bfin_eppi.h
create mode 100644 sim/bfin/dv-bfin_evt.c
create mode 100644 sim/bfin/dv-bfin_evt.h
create mode 100644 sim/bfin/dv-bfin_gptimer.c
create mode 100644 sim/bfin/dv-bfin_gptimer.h
create mode 100644 sim/bfin/dv-bfin_mmu.c
create mode 100644 sim/bfin/dv-bfin_mmu.h
create mode 100644 sim/bfin/dv-bfin_nfc.c
create mode 100644 sim/bfin/dv-bfin_nfc.h
create mode 100644 sim/bfin/dv-bfin_otp.c
create mode 100644 sim/bfin/dv-bfin_otp.h
create mode 100644 sim/bfin/dv-bfin_pll.c
create mode 100644 sim/bfin/dv-bfin_pll.h
create mode 100644 sim/bfin/dv-bfin_ppi.c
create mode 100644 sim/bfin/dv-bfin_ppi.h
create mode 100644 sim/bfin/dv-bfin_rtc.c
create mode 100644 sim/bfin/dv-bfin_rtc.h
create mode 100644 sim/bfin/dv-bfin_sic.c
create mode 100644 sim/bfin/dv-bfin_sic.h
create mode 100644 sim/bfin/dv-bfin_spi.c
create mode 100644 sim/bfin/dv-bfin_spi.h
create mode 100644 sim/bfin/dv-bfin_trace.c
create mode 100644 sim/bfin/dv-bfin_trace.h
create mode 100644 sim/bfin/dv-bfin_twi.c
create mode 100644 sim/bfin/dv-bfin_twi.h
create mode 100644 sim/bfin/dv-bfin_uart.c
create mode 100644 sim/bfin/dv-bfin_uart.h
create mode 100644 sim/bfin/dv-bfin_uart2.c
create mode 100644 sim/bfin/dv-bfin_uart2.h
create mode 100644 sim/bfin/dv-bfin_wdog.c
create mode 100644 sim/bfin/dv-bfin_wdog.h
create mode 100644 sim/bfin/dv-eth_phy.c
create mode 100644 sim/bfin/gui.c
create mode 100644 sim/bfin/gui.h
create mode 100644 sim/bfin/interp.c
create mode 100644 sim/bfin/machs.c
create mode 100644 sim/bfin/machs.h
create mode 100644 sim/bfin/sim-main.h
create mode 100644 sim/bfin/tconfig.in
-mike
[-- Attachment #1.2: 0001-sim-bfin-new-port.patch.xz --]
[-- Type: application/x-xz, Size: 199468 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v2] sim: bfin: new port
2010-11-16 1:41 [PATCH] sim: bfin: new port Mike Frysinger
@ 2010-12-31 23:12 ` Mike Frysinger
2011-02-14 20:18 ` [PATCH v3] " Mike Frysinger
0 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2010-12-31 23:12 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1.1: Type: Text/Plain, Size: 11173 bytes --]
here is an updated Blackfin port with more functionality ! :)
-mike
include/gdb/:
2010-12-31 Mike Frysinger <vapier@gentoo.org>
* sim-bfin.h: New file.
sim/:
2010-12-31 Mike Frysinger <vapier@gentoo.org>
* MAINTAINERS: Add bfin entry.
* configure.tgt (bfin-*-*): Handle bfin targets.
* configure: Regenerate.
sim/bfin/:
2010-12-31 Mike Frysinger <vapier@gentoo.org>
* Makefile.in, TODO, _insn_list.h, _proc_list.h, aclocal.m4,
bfin-sim.c, bfin-sim.h, bfroms/all.h, bfroms/bf50x-0.0.h,
bfroms/bf51x-0.0.h, bfroms/bf51x-0.1.h, bfroms/bf51x-0.2.h,
bfroms/bf526-0.0.h, bfroms/bf526-0.1.h, bfroms/bf527-0.0.h,
bfroms/bf527-0.1.h, bfroms/bf527-0.2.h, bfroms/bf533-0.1.h,
bfroms/bf533-0.2.h, bfroms/bf533-0.3.h, bfroms/bf537-0.0.h,
bfroms/bf537-0.1.h, bfroms/bf537-0.3.h, bfroms/bf538-0.0.h,
bfroms/bf54x-0.0.h, bfroms/bf54x-0.1.h, bfroms/bf54x-0.2.h,
bfroms/bf54x_l1-0.0.h, bfroms/bf54x_l1-0.1.h, bfroms/bf54x_l1-0.2.h,
bfroms/bf561-0.5.h, bfroms/bf59x-0.0.h, bfroms/bf59x_l1-0.1.h,
config.in, configure, configure.ac, devices.c, devices.h,
dv-bfin_cec.c, dv-bfin_cec.h, dv-bfin_ctimer.c, dv-bfin_ctimer.h,
dv-bfin_dma.c, dv-bfin_dma.h, dv-bfin_dmac.c, dv-bfin_dmac.h,
dv-bfin_ebiu_amc.c, dv-bfin_ebiu_amc.h, dv-bfin_ebiu_ddrc.c,
dv-bfin_ebiu_ddrc.h, dv-bfin_ebiu_sdc.c, dv-bfin_ebiu_sdc.h,
dv-bfin_emac.c, dv-bfin_emac.h, dv-bfin_eppi.c, dv-bfin_eppi.h,
dv-bfin_evt.c, dv-bfin_evt.h, dv-bfin_gptimer.c, dv-bfin_gptimer.h,
dv-bfin_mmu.c, dv-bfin_mmu.h, dv-bfin_nfc.c, dv-bfin_nfc.h,
dv-bfin_otp.c, dv-bfin_otp.h, dv-bfin_pll.c, dv-bfin_pll.h,
dv-bfin_ppi.c, dv-bfin_ppi.h, dv-bfin_rtc.c, dv-bfin_rtc.h,
dv-bfin_sic.c, dv-bfin_sic.h, dv-bfin_spi.c, dv-bfin_spi.h,
dv-bfin_trace.c, dv-bfin_trace.h, dv-bfin_twi.c, dv-bfin_twi.h,
dv-bfin_uart.c, dv-bfin_uart.h, dv-bfin_uart2.c, dv-bfin_uart2.h,
dv-bfin_wdog.c, dv-bfin_wdog.h, dv-cfi.c, dv-cfi.h, dv-eth_phy.c,
gui.c, gui.h, interp.c, linux-targ-map.h, machs.c, machs.h,
sim-main.h, tconfig.in: New Blackfin port.
sim/common/:
2010-12-31 Mike Frysinger <vapier@gentoo.org>
* gennltvals.sh: Handle bfin targets.
* nltvals.def: Regenerate.
---
include/gdb/sim-bfin.h | 84 +
sim/MAINTAINERS | 1 +
sim/bfin/Makefile.in | 83 +
sim/bfin/TODO | 16 +
sim/bfin/_insn_list.h | 38 +
sim/bfin/_proc_list.h | 30 +
sim/bfin/aclocal.m4 | 171 +
sim/bfin/bfin-sim.c | 6050 +++++++++++++++++++++++++++++
sim/bfin/bfin-sim.h | 345 ++
sim/bfin/bfroms/all.h | 43 +
sim/bfin/bfroms/bf50x-0.0.h | 515 +++
sim/bfin/bfroms/bf51x-0.0.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf51x-0.1.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf51x-0.2.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf526-0.0.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf526-0.1.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf527-0.0.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf527-0.1.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf527-0.2.h | 4099 ++++++++++++++++++++
sim/bfin/bfroms/bf533-0.1.h | 131 +
sim/bfin/bfroms/bf533-0.2.h | 131 +
sim/bfin/bfroms/bf533-0.3.h | 131 +
sim/bfin/bfroms/bf537-0.0.h | 259 ++
sim/bfin/bfroms/bf537-0.1.h | 259 ++
sim/bfin/bfroms/bf537-0.3.h | 259 ++
sim/bfin/bfroms/bf538-0.0.h | 131 +
sim/bfin/bfroms/bf54x-0.0.h | 515 +++
sim/bfin/bfroms/bf54x-0.1.h | 515 +++
sim/bfin/bfroms/bf54x-0.2.h | 515 +++
sim/bfin/bfroms/bf54x_l1-0.0.h | 8195 ++++++++++++++++++++++++++++++++++++++++
sim/bfin/bfroms/bf54x_l1-0.1.h | 8195 ++++++++++++++++++++++++++++++++++++++++
sim/bfin/bfroms/bf54x_l1-0.2.h | 8195 ++++++++++++++++++++++++++++++++++++++++
sim/bfin/bfroms/bf561-0.5.h | 259 ++
sim/bfin/bfroms/bf59x-0.0.h | 515 +++
sim/bfin/bfroms/bf59x_l1-0.1.h | 8195 ++++++++++++++++++++++++++++++++++++++++
sim/bfin/config.in | 167 +
sim/bfin/configure | 6833 +++++++++++++++++++++++++++++++++
sim/bfin/configure.ac | 74 +
sim/bfin/devices.c | 163 +
sim/bfin/devices.h | 156 +
sim/bfin/dv-bfin_cec.c | 800 ++++
sim/bfin/dv-bfin_cec.h | 139 +
sim/bfin/dv-bfin_ctimer.c | 267 ++
sim/bfin/dv-bfin_ctimer.h | 33 +
sim/bfin/dv-bfin_dma.c | 553 +++
sim/bfin/dv-bfin_dma.h | 65 +
sim/bfin/dv-bfin_dmac.c | 469 +++
sim/bfin/dv-bfin_dmac.h | 32 +
sim/bfin/dv-bfin_ebiu_amc.c | 456 +++
sim/bfin/dv-bfin_ebiu_amc.h | 31 +
sim/bfin/dv-bfin_ebiu_ddrc.c | 184 +
sim/bfin/dv-bfin_ebiu_ddrc.h | 26 +
sim/bfin/dv-bfin_ebiu_sdc.c | 201 +
sim/bfin/dv-bfin_ebiu_sdc.h | 39 +
sim/bfin/dv-bfin_emac.c | 601 +++
sim/bfin/dv-bfin_emac.h | 61 +
sim/bfin/dv-bfin_eppi.c | 271 ++
sim/bfin/dv-bfin_eppi.h | 30 +
sim/bfin/dv-bfin_evt.c | 153 +
sim/bfin/dv-bfin_evt.h | 31 +
sim/bfin/dv-bfin_gptimer.c | 183 +
sim/bfin/dv-bfin_gptimer.h | 27 +
sim/bfin/dv-bfin_mmu.c | 508 +++
sim/bfin/dv-bfin_mmu.h | 93 +
sim/bfin/dv-bfin_nfc.c | 241 ++
sim/bfin/dv-bfin_nfc.h | 41 +
sim/bfin/dv-bfin_otp.c | 270 ++
sim/bfin/dv-bfin_otp.h | 79 +
sim/bfin/dv-bfin_pll.c | 187 +
sim/bfin/dv-bfin_pll.h | 27 +
sim/bfin/dv-bfin_ppi.c | 231 ++
sim/bfin/dv-bfin_ppi.h | 32 +
sim/bfin/dv-bfin_rtc.c | 194 +
sim/bfin/dv-bfin_rtc.h | 26 +
sim/bfin/dv-bfin_sic.c | 1439 +++++++
sim/bfin/dv-bfin_sic.h | 27 +
sim/bfin/dv-bfin_spi.c | 229 ++
sim/bfin/dv-bfin_spi.h | 54 +
sim/bfin/dv-bfin_trace.c | 285 ++
sim/bfin/dv-bfin_trace.h | 37 +
sim/bfin/dv-bfin_twi.c | 227 ++
sim/bfin/dv-bfin_twi.h | 38 +
sim/bfin/dv-bfin_uart.c | 437 +++
sim/bfin/dv-bfin_uart.h | 49 +
sim/bfin/dv-bfin_uart2.c | 258 ++
sim/bfin/dv-bfin_uart2.h | 33 +
sim/bfin/dv-bfin_wdog.c | 206 +
sim/bfin/dv-bfin_wdog.h | 36 +
sim/bfin/dv-cfi.c | 704 ++++
sim/bfin/dv-cfi.h | 60 +
sim/bfin/dv-eth_phy.c | 206 +
sim/bfin/gui.c | 286 ++
sim/bfin/gui.h | 50 +
sim/bfin/interp.c | 790 ++++
sim/bfin/linux-targ-map.h | 1992 ++++++++++
sim/bfin/machs.c | 1223 ++++++
sim/bfin/machs.h | 52 +
sim/bfin/sim-main.h | 116 +
sim/bfin/tconfig.in | 27 +
sim/common/gennltvals.sh | 4 +
sim/common/nltvals.def | 30 +
sim/configure | 8 +
sim/configure.tgt | 3 +
103 files changed, 99448 insertions(+), 0 deletions(-)
create mode 100644 include/gdb/sim-bfin.h
create mode 100644 sim/bfin/Makefile.in
create mode 100644 sim/bfin/TODO
create mode 100644 sim/bfin/_insn_list.h
create mode 100644 sim/bfin/_proc_list.h
create mode 100644 sim/bfin/aclocal.m4
create mode 100644 sim/bfin/bfin-sim.c
create mode 100644 sim/bfin/bfin-sim.h
create mode 100644 sim/bfin/bfroms/all.h
create mode 100644 sim/bfin/bfroms/bf50x-0.0.h
create mode 100644 sim/bfin/bfroms/bf51x-0.0.h
create mode 100644 sim/bfin/bfroms/bf51x-0.1.h
create mode 100644 sim/bfin/bfroms/bf51x-0.2.h
create mode 100644 sim/bfin/bfroms/bf526-0.0.h
create mode 100644 sim/bfin/bfroms/bf526-0.1.h
create mode 100644 sim/bfin/bfroms/bf527-0.0.h
create mode 100644 sim/bfin/bfroms/bf527-0.1.h
create mode 100644 sim/bfin/bfroms/bf527-0.2.h
create mode 100644 sim/bfin/bfroms/bf533-0.1.h
create mode 100644 sim/bfin/bfroms/bf533-0.2.h
create mode 100644 sim/bfin/bfroms/bf533-0.3.h
create mode 100644 sim/bfin/bfroms/bf537-0.0.h
create mode 100644 sim/bfin/bfroms/bf537-0.1.h
create mode 100644 sim/bfin/bfroms/bf537-0.3.h
create mode 100644 sim/bfin/bfroms/bf538-0.0.h
create mode 100644 sim/bfin/bfroms/bf54x-0.0.h
create mode 100644 sim/bfin/bfroms/bf54x-0.1.h
create mode 100644 sim/bfin/bfroms/bf54x-0.2.h
create mode 100644 sim/bfin/bfroms/bf54x_l1-0.0.h
create mode 100644 sim/bfin/bfroms/bf54x_l1-0.1.h
create mode 100644 sim/bfin/bfroms/bf54x_l1-0.2.h
create mode 100644 sim/bfin/bfroms/bf561-0.5.h
create mode 100644 sim/bfin/bfroms/bf59x-0.0.h
create mode 100644 sim/bfin/bfroms/bf59x_l1-0.1.h
create mode 100644 sim/bfin/config.in
create mode 100755 sim/bfin/configure
create mode 100644 sim/bfin/configure.ac
create mode 100644 sim/bfin/devices.c
create mode 100644 sim/bfin/devices.h
create mode 100644 sim/bfin/dv-bfin_cec.c
create mode 100644 sim/bfin/dv-bfin_cec.h
create mode 100644 sim/bfin/dv-bfin_ctimer.c
create mode 100644 sim/bfin/dv-bfin_ctimer.h
create mode 100644 sim/bfin/dv-bfin_dma.c
create mode 100644 sim/bfin/dv-bfin_dma.h
create mode 100644 sim/bfin/dv-bfin_dmac.c
create mode 100644 sim/bfin/dv-bfin_dmac.h
create mode 100644 sim/bfin/dv-bfin_ebiu_amc.c
create mode 100644 sim/bfin/dv-bfin_ebiu_amc.h
create mode 100644 sim/bfin/dv-bfin_ebiu_ddrc.c
create mode 100644 sim/bfin/dv-bfin_ebiu_ddrc.h
create mode 100644 sim/bfin/dv-bfin_ebiu_sdc.c
create mode 100644 sim/bfin/dv-bfin_ebiu_sdc.h
create mode 100644 sim/bfin/dv-bfin_emac.c
create mode 100644 sim/bfin/dv-bfin_emac.h
create mode 100644 sim/bfin/dv-bfin_eppi.c
create mode 100644 sim/bfin/dv-bfin_eppi.h
create mode 100644 sim/bfin/dv-bfin_evt.c
create mode 100644 sim/bfin/dv-bfin_evt.h
create mode 100644 sim/bfin/dv-bfin_gptimer.c
create mode 100644 sim/bfin/dv-bfin_gptimer.h
create mode 100644 sim/bfin/dv-bfin_mmu.c
create mode 100644 sim/bfin/dv-bfin_mmu.h
create mode 100644 sim/bfin/dv-bfin_nfc.c
create mode 100644 sim/bfin/dv-bfin_nfc.h
create mode 100644 sim/bfin/dv-bfin_otp.c
create mode 100644 sim/bfin/dv-bfin_otp.h
create mode 100644 sim/bfin/dv-bfin_pll.c
create mode 100644 sim/bfin/dv-bfin_pll.h
create mode 100644 sim/bfin/dv-bfin_ppi.c
create mode 100644 sim/bfin/dv-bfin_ppi.h
create mode 100644 sim/bfin/dv-bfin_rtc.c
create mode 100644 sim/bfin/dv-bfin_rtc.h
create mode 100644 sim/bfin/dv-bfin_sic.c
create mode 100644 sim/bfin/dv-bfin_sic.h
create mode 100644 sim/bfin/dv-bfin_spi.c
create mode 100644 sim/bfin/dv-bfin_spi.h
create mode 100644 sim/bfin/dv-bfin_trace.c
create mode 100644 sim/bfin/dv-bfin_trace.h
create mode 100644 sim/bfin/dv-bfin_twi.c
create mode 100644 sim/bfin/dv-bfin_twi.h
create mode 100644 sim/bfin/dv-bfin_uart.c
create mode 100644 sim/bfin/dv-bfin_uart.h
create mode 100644 sim/bfin/dv-bfin_uart2.c
create mode 100644 sim/bfin/dv-bfin_uart2.h
create mode 100644 sim/bfin/dv-bfin_wdog.c
create mode 100644 sim/bfin/dv-bfin_wdog.h
create mode 100644 sim/bfin/dv-cfi.c
create mode 100644 sim/bfin/dv-cfi.h
create mode 100644 sim/bfin/dv-eth_phy.c
create mode 100644 sim/bfin/gui.c
create mode 100644 sim/bfin/gui.h
create mode 100644 sim/bfin/interp.c
create mode 100644 sim/bfin/linux-targ-map.h
create mode 100644 sim/bfin/machs.c
create mode 100644 sim/bfin/machs.h
create mode 100644 sim/bfin/sim-main.h
create mode 100644 sim/bfin/tconfig.in
[-- Attachment #1.2: 0001-sim-bfin-new-port.patch.xz --]
[-- Type: application/x-xz, Size: 227780 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v3] sim: bfin: new port
2010-12-31 23:12 ` [PATCH v2] " Mike Frysinger
@ 2011-02-14 20:18 ` Mike Frysinger
2011-02-14 20:49 ` Pedro Alves
2011-02-20 7:24 ` Mike Frysinger
0 siblings, 2 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-14 20:18 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1.1: Type: text/plain, Size: 387 bytes --]
here is the version i plan on committing if there's no feedback. i'd like to
get this in before the 7.3 branch.
off the top of my head, changes since the v2 patch are:
- back out any minor changes that need other patches that havent been
approved yet in common code
- get dynamic FDPIC ELF working
- more linux system calls to support gcc testing of FDPIC ELF apps
-mike
[-- Attachment #1.2: 0001-sim-bfin-new-port.patch.xz --]
[-- Type: application/x-xz, Size: 228940 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-14 20:18 ` [PATCH v3] " Mike Frysinger
@ 2011-02-14 20:49 ` Pedro Alves
2011-02-14 21:12 ` Mike Frysinger
2011-02-20 7:24 ` Mike Frysinger
1 sibling, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-02-14 20:49 UTC (permalink / raw)
To: gdb-patches; +Cc: Mike Frysinger
On Monday 14 February 2011 20:14:32, Mike Frysinger wrote:
>+++ b/sim/bfin/bfroms/bf59x_l1-0.1.h
> @@ -0,0 +1,8195 @@
> +/* DO NOT EDIT: Autogenerated. */
> +static const char bfrom_bf59x_l1_0_1[] = {
What are these generated from?
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-14 20:49 ` Pedro Alves
@ 2011-02-14 21:12 ` Mike Frysinger
2011-02-14 21:55 ` Pedro Alves
0 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2011-02-14 21:12 UTC (permalink / raw)
To: gdb-patches; +Cc: Pedro Alves
On Monday, February 14, 2011 15:40:18 Pedro Alves wrote:
> On Monday 14 February 2011 20:14:32, Mike Frysinger wrote:
> >+++ b/sim/bfin/bfroms/bf59x_l1-0.1.h
> >
> > @@ -0,0 +1,8195 @@
> > +/* DO NOT EDIT: Autogenerated. */
> > +static const char bfrom_bf59x_l1_0_1[] = {
>
> What are these generated from?
memory dumps of the rom from actual hardware
-mike
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-14 21:12 ` Mike Frysinger
@ 2011-02-14 21:55 ` Pedro Alves
2011-02-14 22:11 ` Mike Frysinger
0 siblings, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-02-14 21:55 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
On Monday 14 February 2011 20:49:50, Mike Frysinger wrote:
> On Monday, February 14, 2011 15:40:18 Pedro Alves wrote:
> > On Monday 14 February 2011 20:14:32, Mike Frysinger wrote:
> > >+++ b/sim/bfin/bfroms/bf59x_l1-0.1.h
> > >
> > > @@ -0,0 +1,8195 @@
> > > +/* DO NOT EDIT: Autogenerated. */
> > > +static const char bfrom_bf59x_l1_0_1[] = {
> >
> > What are these generated from?
>
> memory dumps of the rom from actual hardware
What kind of rom, and what kind of hardware? What
tool does one use to extract this rom? What's the
copyright and license for this?
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-14 21:55 ` Pedro Alves
@ 2011-02-14 22:11 ` Mike Frysinger
2011-02-14 22:23 ` Mike Frysinger
2011-02-15 16:25 ` Pedro Alves
0 siblings, 2 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-14 22:11 UTC (permalink / raw)
To: gdb-patches
On Monday, February 14, 2011 16:44:37 Pedro Alves wrote:
> On Monday 14 February 2011 20:49:50, Mike Frysinger wrote:
> > On Monday, February 14, 2011 15:40:18 Pedro Alves wrote:
> > > On Monday 14 February 2011 20:14:32, Mike Frysinger wrote:
> > > >+++ b/sim/bfin/bfroms/bf59x_l1-0.1.h
> > > >
> > > > @@ -0,0 +1,8195 @@
> > > > +/* DO NOT EDIT: Autogenerated. */
> > > > +static const char bfrom_bf59x_l1_0_1[] = {
> > >
> > > What are these generated from?
> >
> > memory dumps of the rom from actual hardware
>
> What kind of rom, and what kind of hardware?
it's the on-chip rom that exists on all Blackfin parts. usually it's used for
bootstrapping a part, but it also has helper functions which are sometimes
used at runtime by the boot loader (i.e. u-boot).
> What tool does one use to extract this rom?
it's memory mapped, so any code that runs on the processor can read it. which
is fairly trivial when the part can boot linux.
> What's the copyright and license for this?
ADI releases the source code to these roms for anyone to view/play with, but
they hold the copyrights. i'm not sure there is any license mention in the
source files, but they arent terribly useful for anything else considering
they're written in pure assembly, assume rom locations in the processor,
generally require proprietary ADI tools to compile/link, and no one else can
make a Blackfin processor.
but that is the source code, not the final binary which is what we're talking
about here: gcc foo.c -o foo; objcopy -O binary foo foo.bin; <convert foo.bin
into a header>. what license would be necessary for inclusion ? i'm fairly
certain a redistributable license (if not already in place) would be trivial
to get seeing as i am an ADI employee. i dont think copyright makes much
sense with these things.
-mike
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-14 22:11 ` Mike Frysinger
@ 2011-02-14 22:23 ` Mike Frysinger
2011-02-15 16:25 ` Pedro Alves
1 sibling, 0 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-14 22:23 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 358 bytes --]
also, these rom images arent generally required to make the sim useful. they
are sometimes needed if you want to simulate certain features of the
bootloader/linux in the operating environment, but that's about it. which is
to say, while it'd be a shame to lose that functionality, they can easily be
pulled out if this is a blocking issue.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-14 22:11 ` Mike Frysinger
2011-02-14 22:23 ` Mike Frysinger
@ 2011-02-15 16:25 ` Pedro Alves
2011-02-16 1:34 ` Mike Frysinger
1 sibling, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-02-15 16:25 UTC (permalink / raw)
To: gdb-patches; +Cc: Mike Frysinger
On Tuesday 15 February 2011 22:10:54, Mike Frysinger wrote:
> > What kind of rom, and what kind of hardware?
>
> it's the on-chip rom that exists on all Blackfin parts. usually it's used for
> bootstrapping a part, but it also has helper functions which are sometimes
> used at runtime by the boot loader (i.e. u-boot).
>
> > What tool does one use to extract this rom?
>
> it's memory mapped, so any code that runs on the processor can read it. which
> is fairly trivial when the part can boot linux.
So it sounds like these would qualify as device firmware, which are
okay to have source trees in some circles, but I'm obviously not a lawyer,
and certainly not an FSF representative in any way regarding
licensing/copyright, so I may be totally wrong, and I don't know if
FSF repositories belong in the circles that allow such blobs.
Is there any other similar case in the sim/ for other
architectures, perhaps?
> > What's the copyright and license for this?
>
> ADI releases the source code to these roms for anyone to view/play with, but
> they hold the copyrights. i'm not sure there is any license mention in the
> source files, but they arent terribly useful for anything else considering
> they're written in pure assembly, assume rom locations in the processor,
> generally require proprietary ADI tools to compile/link, and no one else can
> make a Blackfin processor.
>
> but that is the source code, not the final binary which is what we're talking
> about here: gcc foo.c -o foo; objcopy -O binary foo foo.bin; <convert foo.bin
> into a header>. what license would be necessary for inclusion ? i'm fairly
> certain a redistributable license (if not already in place) would be trivial
> to get seeing as i am an ADI employee. i dont think copyright makes much
> sense with these things.
I think you'll need to find out about that redistributable license, and
someone other than me will have to bless having such binaries in
the tree. I suggest contacting FSF legal.
Patch-wise, I expect you'll at least need to put your answers above
in the sources in some form, and add mentions of the copyright and
licensing that applies to these files and blobs.
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-15 16:25 ` Pedro Alves
@ 2011-02-16 1:34 ` Mike Frysinger
2011-02-16 5:34 ` Joel Brobecker
0 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2011-02-16 1:34 UTC (permalink / raw)
To: gdb-patches; +Cc: Pedro Alves
On Tuesday, February 15, 2011 10:56:55 Pedro Alves wrote:
> On Tuesday 15 February 2011 22:10:54, Mike Frysinger wrote:
> > > What kind of rom, and what kind of hardware?
> >
> > it's the on-chip rom that exists on all Blackfin parts. usually it's
> > used for bootstrapping a part, but it also has helper functions which
> > are sometimes used at runtime by the boot loader (i.e. u-boot).
> >
> > > What tool does one use to extract this rom?
> >
> > it's memory mapped, so any code that runs on the processor can read it.
> > which is fairly trivial when the part can boot linux.
>
> So it sounds like these would qualify as device firmware, which are
> okay to have source trees in some circles, but I'm obviously not a lawyer,
> and certainly not an FSF representative in any way regarding
> licensing/copyright, so I may be totally wrong, and I don't know if
> FSF repositories belong in the circles that allow such blobs.
it depends how you qualify it. this is not microcode that is loaded at
runtime and/or can be modified in any way. it is completely burned into the
hardware. every Blackfin processor has a static ROM when it comes out of the
factory sitting at address 0xef000000. it's not like we're talking firmware
blobs that get loaded into a parallel processor at runtime (i.e. WiFi drivers)
which could in practice be tweaked by end users.
> Is there any other similar case in the sim/ for other
> architectures, perhaps?
i couldnt really find anything. but i get the feeling that people stopped
doing this level of development on the GNU sim some time ago.
> I think you'll need to find out about that redistributable license, and
> someone other than me will have to bless having such binaries in
> the tree. I suggest contacting FSF legal.
>
> Patch-wise, I expect you'll at least need to put your answers above
> in the sources in some form, and add mentions of the copyright and
> licensing that applies to these files and blobs.
sounds more like i'll just drop it for now since it is a minor part of the
bigger picture.
-mike
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-16 1:34 ` Mike Frysinger
@ 2011-02-16 5:34 ` Joel Brobecker
0 siblings, 0 replies; 36+ messages in thread
From: Joel Brobecker @ 2011-02-16 5:34 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches, Pedro Alves
> it depends how you qualify it. this is not microcode that is loaded
> at runtime and/or can be modified in any way. it is completely burned
> into the hardware. every Blackfin processor has a static ROM when it
> comes out of the factory sitting at address 0xef000000.
[...]
> sounds more like i'll just drop it for now since it is a minor part of
> the bigger picture.
I have found in the past that it is very easy to get a quick answer
from the FSF regarding these matters. So, if you are considering
"undropping" this part, you can send an email to assign@gnu.org.
They usually answer within a couple of days.
--
Joel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-14 20:18 ` [PATCH v3] " Mike Frysinger
2011-02-14 20:49 ` Pedro Alves
@ 2011-02-20 7:24 ` Mike Frysinger
2011-02-21 10:13 ` Joel Brobecker
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
1 sibling, 2 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-20 7:24 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 191 bytes --]
changes since v3:
- stubbed all the bootroms (i'll follow up)
- add simple jtag/watchpoint device simulation
so if no one has any other feedback, i'll merge it by the end of feb ...
-mike
[-- Attachment #2: 0001-sim-bfin-new-port.patch.xz --]
[-- Type: application/octet-stream, Size: 228940 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-20 7:24 ` Mike Frysinger
@ 2011-02-21 10:13 ` Joel Brobecker
2011-02-21 18:27 ` Mike Frysinger
2011-02-22 10:08 ` Pedro Alves
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
1 sibling, 2 replies; 36+ messages in thread
From: Joel Brobecker @ 2011-02-21 10:13 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
Please, sending compressed files makes it harder to look at the file.
I think you were right to do it for a file that's 4MB, but in that case,
using something a little more usual like gz, zip or bzip2 would have
made things easier... I had to install the xzutil on my laptop and it
wasn't without its little scary moment...
> changes since v3:
> - stubbed all the bootroms (i'll follow up)
> - add simple jtag/watchpoint device simulation
I'm not a sim expert, so I can only provide cosmetic review.
However, I did notice a couple of important things: The copyright
headers should mention 2011, and the license should be GPL version 3.
Question: Why do you have .h files whose name starts with an underscore?
For instance: sim/bfin/_proc_list.h...
General comment: We should really strive to follow the same coding
standards in sim/ as we do in gdb/. In particular, it would be nice
to have more comments, and to follow the maximum line length as
possible.
For instance:
> typedef enum
> {
> c_0, c_1, c_4, c_2, c_uimm2, c_uimm3, c_imm3, c_pcrel4,
> c_imm4, c_uimm4s4, c_uimm4s4d, c_uimm4, c_uimm4s2, c_negimm5s4, c_imm5, c_imm5d, c_uimm5, c_imm6,
> c_imm7, c_imm7d, c_imm8, c_uimm8, c_pcrel8, c_uimm8s4, c_pcrel8s4, c_lppcrel10, c_pcrel10,
For the comments - I think that's a lot of code now, and I wont' block
the commit for something like that. But, to me, code documentation is
an integral part of software quality... For instance, the following
function has a relatively cryptic name, particularly for someone who
is not familiar with the bfin architecture:
> +static const char *
> +fmtconst_str (const_forms_t cf, bs32 x, bu32 pc)
Remove the '*' at the beginning of each line in multi-line comments:
> /* If an operation would otherwise cause a positive value to overflow
> * and become negative, instead, saturation limits the result to the
> * maximum positive value for the size register being used.
Binary operators should be at the start of the line rather than
at the end:
> if ((gs < 2) || /* Dregs/Pregs as source */
> (gd < 2) || /* Dregs/Pregs as dest */
> (gs == 4 && src < 4) || /* Accumulators as source */
> (gd == 4 && dst < 4 && (gs < 4)) || /* Accumulators as dest */
I am pretty sure you already know all this; it's just that it's so
much code that it's hard to always be complient, particularly if
the code started in something like 2005.
I have no other comment. I think you know what you're doing in
the simulator area, so I'm inclined to trust your judgment on
the rest of the code (if you could just remember for future
contributions that comments are important). If Pedro has no further
comments, the meat of the patch is OK with me.
--
Joel (burp - 100K lines of patch later)
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-21 10:13 ` Joel Brobecker
@ 2011-02-21 18:27 ` Mike Frysinger
2011-02-22 8:28 ` Joel Brobecker
2011-02-22 10:50 ` Pedro Alves
2011-02-22 10:08 ` Pedro Alves
1 sibling, 2 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-21 18:27 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 2744 bytes --]
On Monday, February 21, 2011 04:54:36 Joel Brobecker wrote:
> Please, sending compressed files makes it harder to look at the file.
> I think you were right to do it for a file that's 4MB, but in that case,
> using something a little more usual like gz, zip or bzip2 would have
> made things easier... I had to install the xzutil on my laptop and it
> wasn't without its little scary moment...
sorry, i'm so used to xz i expect everyone to have it ;)
> > changes since v3:
> > - stubbed all the bootroms (i'll follow up)
> > - add simple jtag/watchpoint device simulation
>
> I'm not a sim expert, so I can only provide cosmetic review.
> However, I did notice a couple of important things: The copyright
> headers should mention 2011, and the license should be GPL version 3.
all the files do say 2011 that i can see ... were there ones missing that you
saw ?
much of the sim project seems to still be GPL v2, so i didnt want to try and
figure out what's going on. if this code should be GPL v3, that's fine, i can
relicense it.
> Question: Why do you have .h files whose name starts with an underscore?
> For instance: sim/bfin/_proc_list.h...
it's meant to convey that the header isnt meant to be generally included by
random files. they can only be included in specific instances since they're
simple lists which need certain preprocessor directives in place before they
can be included. i'm trying to avoid bit rot related to copying & pasting the
same list of numbers over and over in multiple places.
> General comment: We should really strive to follow the same coding
> standards in sim/ as we do in gdb/. In particular, it would be nice
> to have more comments, and to follow the maximum line length as
> possible.
it is supposed to be the GNU coding style. if it isnt, then it's just an
oversight. i'll go through and try to fix up missing pieces including the
ones you highlighted.
> For instance:
> > typedef enum
> > {
> >
> > c_0, c_1, c_4, c_2, c_uimm2, c_uimm3, c_imm3, c_pcrel4,
> > c_imm4, c_uimm4s4, c_uimm4s4d, c_uimm4, c_uimm4s2, c_negimm5s4, c_imm5,
> > c_imm5d, c_uimm5, c_imm6, c_imm7, c_imm7d, c_imm8, c_uimm8, c_pcrel8,
> > c_uimm8s4, c_pcrel8s4, c_lppcrel10, c_pcrel10,
>
> For the comments - I think that's a lot of code now, and I wont' block
> the commit for something like that. But, to me, code documentation is
> an integral part of software quality... For instance, the following
> function has a relatively cryptic name, particularly for someone who
> is not familiar with the bfin architecture:
this section is simply copy & pasted from the existing disassembler. at some
point i'd like to unify it.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-21 18:27 ` Mike Frysinger
@ 2011-02-22 8:28 ` Joel Brobecker
2011-02-22 17:58 ` Mike Frysinger
2011-02-22 10:50 ` Pedro Alves
1 sibling, 1 reply; 36+ messages in thread
From: Joel Brobecker @ 2011-02-22 8:28 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
> > I'm not a sim expert, so I can only provide cosmetic review.
> > However, I did notice a couple of important things: The copyright
> > headers should mention 2011, and the license should be GPL version 3.
>
> all the files do say 2011 that i can see ... were there ones missing that you
> saw ?
The ones I saw were at the beginning of the patch. For instance:
+++ b/include/gdb/sim-bfin.h
+ Copyright (C) 2005 Free Software Foundation, Inc.
+++ b/sim/bfin/Makefile.in
+# Copyright (C) 2005 Free Software Foundation, Inc.
A quick grep only gives a few hits, and several of them are false
positives (either a generated file, or a regexp that's too simple):
% grep Copyright 0001-sim-bfin-new-port.patch| grep -v 2011
+ Copyright (C) 2005 Free Software Foundation, Inc.
+# Copyright (C) 2005 Free Software Foundation, Inc.
+# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
+# Copyright © 2004 Scott James Remnant <scott@netsplit.com>.
+# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
+Copyright (C) 2010 Free Software Foundation, Inc.
+Copyright (C) 2010 Free Software Foundation, Inc.
> much of the sim project seems to still be GPL v2, so i didnt want to
> try and figure out what's going on. if this code should be GPL v3,
> that's fine, i can relicense it.
IIRC, there are many files in the sim/ area that are actually not
copyright the FSF - so we couldn't change the license. So we only
changed the files that were marked copyright the FSF. I was told
that the reason for allowing code that hasn't been assigned to
the FSF in the sim area is historical and had to do with being
desperate to have a ppc sim. I think that was a mistake - we'll
live with it, but it certainly is causing trouble as you can see.
For new contributions, I don't see a reason for licensing it GPL v2,
so let's go with v3.
> it's meant to convey that the header isnt meant to be generally
> included by random files. they can only be included in specific
> instances since they're simple lists which need certain preprocessor
> directives in place before they can be included. i'm trying to avoid
> bit rot related to copying & pasting the same list of numbers over and
> over in multiple places.
OK. Thanks for the explanation.
> it is supposed to be the GNU coding style. if it isnt, then it's just an
> oversight. i'll go through and try to fix up missing pieces including the
> ones you highlighted.
Thanks - I know what you are dealing with. I have the same issue with
our VxWorks that I've been trying to contribute. It's also a lot of
code, some of it written years away, and it's plain impossible to make
sure that it perfectly adheres to all the rules. So we just do our best
by doing a couple of passes and fix the obvious errors.
--
Joel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-22 8:28 ` Joel Brobecker
@ 2011-02-22 17:58 ` Mike Frysinger
0 siblings, 0 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-22 17:58 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 869 bytes --]
On Tuesday, February 22, 2011 03:20:10 Joel Brobecker wrote:
> > > I'm not a sim expert, so I can only provide cosmetic review.
> > > However, I did notice a couple of important things: The copyright
> > > headers should mention 2011, and the license should be GPL version 3.
> >
> > all the files do say 2011 that i can see ... were there ones missing that
> > you saw ?
>
> The ones I saw were at the beginning of the patch. For instance:
>
> +++ b/include/gdb/sim-bfin.h
> + Copyright (C) 2005 Free Software Foundation, Inc.
>
> +++ b/sim/bfin/Makefile.in
> +# Copyright (C) 2005 Free Software Foundation, Inc.
ah, *those* files :). i had checked all the .c/.h files in sim/bfin/, but
forgot to look at the others.
> For new contributions, I don't see a reason for licensing it GPL v2,
> so let's go with v3.
np, will do
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-21 18:27 ` Mike Frysinger
2011-02-22 8:28 ` Joel Brobecker
@ 2011-02-22 10:50 ` Pedro Alves
2011-02-22 18:07 ` Mike Frysinger
1 sibling, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-02-22 10:50 UTC (permalink / raw)
To: gdb-patches; +Cc: Mike Frysinger, Joel Brobecker
On Monday 21 February 2011 16:53:45, Mike Frysinger wrote:
> On Monday, February 21, 2011 04:54:36 Joel Brobecker wrote:
> > Question: Why do you have .h files whose name starts with an underscore?
> > For instance: sim/bfin/_proc_list.h...
>
> it's meant to convey that the header isnt meant to be generally included by
> random files. they can only be included in specific instances since they're
> simple lists which need certain preprocessor directives in place before they
> can be included. i'm trying to avoid bit rot related to copying & pasting the
> same list of numbers over and over in multiple places.
That's a good idea. I notice a copyright header is missing though.
FYI, on the gdb/ side, we name those files "*.def".
E.g., ada-operator.def, common/ax.def, std-operator.def.
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-22 10:50 ` Pedro Alves
@ 2011-02-22 18:07 ` Mike Frysinger
0 siblings, 0 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-22 18:07 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, Joel Brobecker
[-- Attachment #1: Type: Text/Plain, Size: 969 bytes --]
On Tuesday, February 22, 2011 05:08:24 Pedro Alves wrote:
> On Monday 21 February 2011 16:53:45, Mike Frysinger wrote:
> > On Monday, February 21, 2011 04:54:36 Joel Brobecker wrote:
> > > Question: Why do you have .h files whose name starts with an
> > > underscore? For instance: sim/bfin/_proc_list.h...
> >
> > it's meant to convey that the header isnt meant to be generally included
> > by random files. they can only be included in specific instances since
> > they're simple lists which need certain preprocessor directives in place
> > before they can be included. i'm trying to avoid bit rot related to
> > copying & pasting the same list of numbers over and over in multiple
> > places.
>
> That's a good idea. I notice a copyright header is missing though.
> FYI, on the gdb/ side, we name those files "*.def".
> E.g., ada-operator.def, common/ax.def, std-operator.def.
wasnt aware of existing precedence ... that works for me
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v3] sim: bfin: new port
2011-02-21 10:13 ` Joel Brobecker
2011-02-21 18:27 ` Mike Frysinger
@ 2011-02-22 10:08 ` Pedro Alves
2011-02-22 17:57 ` Mike Frysinger
1 sibling, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-02-22 10:08 UTC (permalink / raw)
To: gdb-patches; +Cc: Joel Brobecker, Mike Frysinger
On Monday 21 February 2011 09:54:36, Joel Brobecker wrote:
> Please, sending compressed files makes it harder to look at the file.
> I think you were right to do it for a file that's 4MB, but in that case,
> using something a little more usual like gz, zip or bzip2 would have
> made things easier... I had to install the xzutil on my laptop and it
> wasn't without its little scary moment...
>
> > changes since v3:
> > - stubbed all the bootroms
Did you send the correct patch? I still see a bunch of:
> diff --git a/sim/bfin/bfroms/bf50x-0.0.h b/sim/bfin/bfroms/bf50x-0.0.h
> new file mode 100644
> index 0000000..8d88c73
> --- /dev/null
> +++ b/sim/bfin/bfroms/bf50x-0.0.h
> @@ -0,0 +1,515 @@
> +/* DO NOT EDIT: Autogenerated. */
> +static const char bfrom_bf50x_0_0[] = {
> (i'll follow up)
Thanks, I do hope this is sorted out.
> I have no other comment. I think you know what you're doing in
> the simulator area, so I'm inclined to trust your judgment on
> the rest of the code (if you could just remember for future
> contributions that comments are important).
> If Pedro has no further comments, the meat of the patch is OK with me.
One:
> +#! /bin/sh
> +# Guess values for system-dependent variables and create Makefiles.
> +# Generated by GNU Autoconf 2.68.
The whole tree is at Autoconf 2.64. Please use that version.
Preferably, a pristine FSF version, as distros tend to patch
autoconf, and that causes churn on the output.
I'll reply to another email, but other than that I have further
comments. Thanks.
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-22 10:08 ` Pedro Alves
@ 2011-02-22 17:57 ` Mike Frysinger
2011-02-22 18:25 ` Pedro Alves
0 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2011-02-22 17:57 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches, Joel Brobecker
[-- Attachment #1: Type: Text/Plain, Size: 1639 bytes --]
On Tuesday, February 22, 2011 05:04:19 Pedro Alves wrote:
> On Monday 21 February 2011 09:54:36, Joel Brobecker wrote:
> > Please, sending compressed files makes it harder to look at the file.
> > I think you were right to do it for a file that's 4MB, but in that case,
> > using something a little more usual like gz, zip or bzip2 would have
> > made things easier... I had to install the xzutil on my laptop and it
> > wasn't without its little scary moment...
> >
> > > changes since v3:
> > > - stubbed all the bootroms
>
> Did you send the correct patch? I still see a bunch of:
> > diff --git a/sim/bfin/bfroms/bf50x-0.0.h b/sim/bfin/bfroms/bf50x-0.0.h
> > new file mode 100644
> > index 0000000..8d88c73
> > --- /dev/null
> > +++ b/sim/bfin/bfroms/bf50x-0.0.h
> > @@ -0,0 +1,515 @@
> > +/* DO NOT EDIT: Autogenerated. */
> > +static const char bfrom_bf50x_0_0[] = {
but they're all empty stubs:
foo[] = {};
this allows the sim to at least generate a region of NOPs, and makes it easier
for when i merge back in.
> > +#! /bin/sh
> > +# Guess values for system-dependent variables and create Makefiles.
> > +# Generated by GNU Autoconf 2.68.
>
> The whole tree is at Autoconf 2.64. Please use that version.
np
> Preferably, a pristine FSF version, as distros tend to patch
> autoconf, and that causes churn on the output.
Gentoo does not apply patches to 2.64. installing any autotool package by
hand outside of the PM is a pita ...
this is generally why i keep old autoconf/automake versions in the Gentoo
tree. so i can easily downgrade for old FSF projects ;).
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v3] sim: bfin: new port
2011-02-22 17:57 ` Mike Frysinger
@ 2011-02-22 18:25 ` Pedro Alves
2011-02-22 20:54 ` Mike Frysinger
0 siblings, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-02-22 18:25 UTC (permalink / raw)
To: gdb-patches; +Cc: Mike Frysinger, Joel Brobecker
On Tuesday 22 February 2011 17:56:23, Mike Frysinger wrote:
> On Tuesday, February 22, 2011 05:04:19 Pedro Alves wrote:
> > > Mike Frysinger wrote:
> > > > changes since v3:
> > > > - stubbed all the bootroms
> > >
> > Did you send the correct patch? I still see a bunch of:
> > > diff --git a/sim/bfin/bfroms/bf50x-0.0.h b/sim/bfin/bfroms/bf50x-0.0.h
> > > new file mode 100644
> > > index 0000000..8d88c73
> > > --- /dev/null
> > > +++ b/sim/bfin/bfroms/bf50x-0.0.h
> > > @@ -0,0 +1,515 @@
> > > +/* DO NOT EDIT: Autogenerated. */
> > > +static const char bfrom_bf50x_0_0[] = {
>
> but they're all empty stubs:
> foo[] = {};
>
Hmm. That's not what I see on the patch from
<http://sourceware.org/ml/gdb-patches/2011-02/msg00517.html>:
diff --git a/sim/bfin/bfroms/bf50x-0.0.h b/sim/bfin/bfroms/bf50x-0.0.h
new file mode 100644
index 0000000..8d88c73
--- /dev/null
+++ b/sim/bfin/bfroms/bf50x-0.0.h
@@ -0,0 +1,515 @@
+/* DO NOT EDIT: Autogenerated. */
+static const char bfrom_bf50x_0_0[] = {
+0x40, 0x20, 0x2a, 0x20, 0x49, 0x23, 0x09, 0x23,
+0xf8, 0x25, 0xa7, 0x24, 0x33, 0x20, 0x32, 0x20,
+0x31, 0x20, 0x30, 0x20, 0x2f, 0x20, 0x2e, 0x20,
+0x2d, 0x20, 0x24, 0x20, 0x2b, 0x20, 0x2a, 0x20,
+0x54, 0x21, 0x99, 0x23, 0x00, 0x20, 0x00, 0x20,
+0x00, 0x20, 0xdb, 0x20, 0x25, 0x00, 0x24, 0x00,
+0x26, 0x27, 0x44, 0x27, 0x59, 0x27, 0x81, 0x27,
+0xce, 0x23, 0x27, 0x26, 0x90, 0x26, 0x23, 0x00,
I downloaded the file with wget, and xz -d'd it manually,
to make sure I wasn't hitting some cache weirdness in
my kde/ark desktop.
Am I looking at the right file?
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v5] sim: bfin: new port
2011-02-20 7:24 ` Mike Frysinger
2011-02-21 10:13 ` Joel Brobecker
@ 2011-02-22 20:29 ` Mike Frysinger
2011-03-01 5:16 ` Mike Frysinger
` (3 more replies)
1 sibling, 4 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-02-22 20:29 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1.1: Type: Text/Plain, Size: 164 bytes --]
hopefully the last iteration for now ;)
changes:
- fix up style in random places
- update copyrights
- use GPLv3 everywhere
- use autoconf-2.64
-mike
[-- Attachment #1.2: 0001-sim-bfin-new-port.patch.bz2 --]
[-- Type: application/x-bzip, Size: 148570 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5] sim: bfin: new port
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
@ 2011-03-01 5:16 ` Mike Frysinger
2011-03-01 10:11 ` Joel Brobecker
` (2 subsequent siblings)
3 siblings, 0 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-03-01 5:16 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 280 bytes --]
On Tuesday, February 22, 2011 15:26:44 Mike Frysinger wrote:
> hopefully the last iteration for now ;)
>
> changes:
> - fix up style in random places
> - update copyrights
> - use GPLv3 everywhere
> - use autoconf-2.64
i'll commit this later today (monday)
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5] sim: bfin: new port
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
2011-03-01 5:16 ` Mike Frysinger
@ 2011-03-01 10:11 ` Joel Brobecker
2011-03-01 21:19 ` Pedro Alves
2011-03-03 21:40 ` [PATCH v6] " Mike Frysinger
3 siblings, 0 replies; 36+ messages in thread
From: Joel Brobecker @ 2011-03-01 10:11 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
> hopefully the last iteration for now ;)
>
> changes:
> - fix up style in random places
> - update copyrights
> - use GPLv3 everywhere
> - use autoconf-2.64
> -mike
I did a few greps here and there to see if there were places
where some of the comments I made were still relevant, and I am
satisfied.
I don't know if Pedro wanted to take a final look or not...
--
Joel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v5] sim: bfin: new port
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
2011-03-01 5:16 ` Mike Frysinger
2011-03-01 10:11 ` Joel Brobecker
@ 2011-03-01 21:19 ` Pedro Alves
2011-03-01 23:42 ` Mike Frysinger
2011-03-03 21:40 ` [PATCH v6] " Mike Frysinger
3 siblings, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-03-01 21:19 UTC (permalink / raw)
To: gdb-patches; +Cc: Mike Frysinger
Hi Mike,
On Tuesday 22 February 2011 20:26:44, Mike Frysinger wrote:
> --- /dev/null
> +++ b/sim/bfin/linux-fixed-code.h
> @@ -0,0 +1,23 @@
> +/* DO NOT EDIT: Autogenerated. */
> +/* Fixed code region of Linux userspace starting at 0x400. Last produced
> + from Linux-2.6.37 (not that the fixed code region changes often). */
> +static const unsigned char bfin_linux_fixed_code[] = {
> +0x28, 0xe1, 0xad, 0x00, 0xa0, 0x00, 0x00, 0x20,
(...)
> +0xa4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +};
I was surprised to still see a binary blob in
the code, and though this blog was generated from a
different source, I also worry about it. :-(
AINAL yadda yadda.
From the comment, this blob in question is a dump of code
from the Linux kernel. In short, you're making the
gdb sources include a piece of the Linux kernel.
The whole Linux kernel as a single product is GPLv2.
If that was indeed extracted from a Linux kernel's
binary (either from a running system or from the
object code), then from my understanding it is
GPLv2 as well, and retains the original copyright of
the Kernel, as (sic from the GPL FAQ) 'when a program
translates its input into some other form, the copyright
status of the output inherits that of the input
it was generated from'.
This seem to make that hunk in the patch not acceptable,
as GPLv2 is incompatible with GPLv3.
There's then the issue that since the blob is
a GPLv2 binary, to distribute/convey it, per the GPL,
we'd need to be able to provide the source it's
generated from as well. And any scripts/instructions
necessary to regenerate the autogenerated file.
(It is also my understanding that when you distribute/convey
object code, you must keep copyright notices
intact, and I would assume that to mean that
even these generated files should carry a copyright
(and license) header.)
Now this kernel code in question was probably (haven't
checked) largely written by ADI, and as such ADI could
probably contribute a standalone version of its source
to the FSF under GPLv3, along with some script or makefile
that compiles it with a bfin-gcc and then generates
the blob array. Or you could write simple dumb
replacement implementations of the interface instead?
I don't know if there's some rule or exception
in the GPL that applies here, and nullifies my concerns.
I'd be happy to learn about it.
I think that best would be for you to contact
<assign@gnu.org> and get an educated answer from
the FSF (Cc'ing me).
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5] sim: bfin: new port
2011-03-01 21:19 ` Pedro Alves
@ 2011-03-01 23:42 ` Mike Frysinger
2011-03-02 1:13 ` Pedro Alves
0 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2011-03-01 23:42 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 4979 bytes --]
On Tuesday, March 01, 2011 16:19:25 Pedro Alves wrote:
> On Tuesday 22 February 2011 20:26:44, Mike Frysinger wrote:
> > --- /dev/null
> > +++ b/sim/bfin/linux-fixed-code.h
> > @@ -0,0 +1,23 @@
> > +/* DO NOT EDIT: Autogenerated. */
> > +/* Fixed code region of Linux userspace starting at 0x400. Last
> > produced + from Linux-2.6.37 (not that the fixed code region changes
> > often). */ +static const unsigned char bfin_linux_fixed_code[] = {
> > +0x28, 0xe1, 0xad, 0x00, 0xa0, 0x00, 0x00, 0x20,
>
> (...)
>
> > +0xa4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +};
>
> Now this kernel code in question was probably (haven't
> checked) largely written by ADI, and as such ADI could
> probably contribute a standalone version of its source
> to the FSF under GPLv3, along with some script or makefile
> that compiles it with a bfin-gcc and then generates
> the blob array. Or you could write simple dumb
> replacement implementations of the interface instead?
this code was written purely by ADI employees (2 or 3 of them to be exact), is
written in pure Blackfin assembly, and we've explicitly licensed this file
under GPLv2 or later. so i dont think this is an issue. it is not used by
the kernel at all ... the code is placed in a fixed location for userspace
binaries to call and is defined as part of the Blackfin ABI. see below.
-mike
/*
* This file contains sequences of code that will be copied to a
* fixed location, defined in <asm/fixed_code.h>. The interrupt
* handlers ensure that these sequences appear to be atomic when
* executed from userspace.
* These are aligned to 16 bytes, so that we have some space to replace
* these sequences with something else (e.g. kernel traps if we ever do
* BF561 SMP).
*
* Copyright 2007-2008 Analog Devices Inc.
*
* Licensed under the GPL-2 or later.
*/
#include <linux/linkage.h>
#include <linux/init.h>
#include <linux/unistd.h>
#include <asm/entry.h>
__INIT
ENTRY(_fixed_code_start)
.align 16
ENTRY(_sigreturn_stub)
P0 = __NR_rt_sigreturn;
EXCPT 0;
/* Speculative execution paranoia. */
0: JUMP.S 0b;
ENDPROC (_sigreturn_stub)
.align 16
/*
* Atomic swap, 8 bit.
* Inputs: P0: memory address to use
* R1: value to store
* Output: R0: old contents of the memory address, zero extended.
*/
ENTRY(_atomic_xchg32)
R0 = [P0];
[P0] = R1;
rts;
ENDPROC (_atomic_xchg32)
.align 16
/*
* Compare and swap, 32 bit.
* Inputs: P0: memory address to use
* R1: compare value
* R2: new value to store
* The new value is stored if the contents of the memory
* address is equal to the compare value.
* Output: R0: old contents of the memory address.
*/
ENTRY(_atomic_cas32)
R0 = [P0];
CC = R0 == R1;
IF !CC JUMP 1f;
[P0] = R2;
1:
rts;
ENDPROC (_atomic_cas32)
.align 16
/*
* Atomic add, 32 bit.
* Inputs: P0: memory address to use
* R0: value to add
* Outputs: R0: new contents of the memory address.
* R1: previous contents of the memory address.
*/
ENTRY(_atomic_add32)
R1 = [P0];
R0 = R1 + R0;
[P0] = R0;
rts;
ENDPROC (_atomic_add32)
.align 16
/*
* Atomic sub, 32 bit.
* Inputs: P0: memory address to use
* R0: value to subtract
* Outputs: R0: new contents of the memory address.
* R1: previous contents of the memory address.
*/
ENTRY(_atomic_sub32)
R1 = [P0];
R0 = R1 - R0;
[P0] = R0;
rts;
ENDPROC (_atomic_sub32)
.align 16
/*
* Atomic ior, 32 bit.
* Inputs: P0: memory address to use
* R0: value to ior
* Outputs: R0: new contents of the memory address.
* R1: previous contents of the memory address.
*/
ENTRY(_atomic_ior32)
R1 = [P0];
R0 = R1 | R0;
[P0] = R0;
rts;
ENDPROC (_atomic_ior32)
.align 16
/*
* Atomic and, 32 bit.
* Inputs: P0: memory address to use
* R0: value to and
* Outputs: R0: new contents of the memory address.
* R1: previous contents of the memory address.
*/
ENTRY(_atomic_and32)
R1 = [P0];
R0 = R1 & R0;
[P0] = R0;
rts;
ENDPROC (_atomic_and32)
.align 16
/*
* Atomic xor, 32 bit.
* Inputs: P0: memory address to use
* R0: value to xor
* Outputs: R0: new contents of the memory address.
* R1: previous contents of the memory address.
*/
ENTRY(_atomic_xor32)
R1 = [P0];
R0 = R1 ^ R0;
[P0] = R0;
rts;
ENDPROC (_atomic_xor32)
.align 16
/*
* safe_user_instruction
* Four NOPS are enough to allow the pipeline to speculativily load
* execute anything it wants. After that, things have gone bad, and
* we are stuck - so panic. Since we might be in user space, we can't
* call panic, so just cause a unhandled exception, this should cause
* a dump of the trace buffer so we can tell were we are, and a reboot
*/
ENTRY(_safe_user_instruction)
NOP; NOP; NOP; NOP;
EXCPT 0x4;
ENDPROC(_safe_user_instruction)
ENTRY(_fixed_code_end)
__FINIT
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5] sim: bfin: new port
2011-03-01 23:42 ` Mike Frysinger
@ 2011-03-02 1:13 ` Pedro Alves
2011-03-02 2:23 ` Mike Frysinger
0 siblings, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-03-02 1:13 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
On Tuesday 01 March 2011 22:02:21, Mike Frysinger wrote:
> On Tuesday, March 01, 2011 16:19:25 Pedro Alves wrote:
> > On Tuesday 22 February 2011 20:26:44, Mike Frysinger wrote:
> > > --- /dev/null
> > > +++ b/sim/bfin/linux-fixed-code.h
> > > @@ -0,0 +1,23 @@
> > > +/* DO NOT EDIT: Autogenerated. */
> > > +/* Fixed code region of Linux userspace starting at 0x400. Last
> > > produced + from Linux-2.6.37 (not that the fixed code region changes
> > > often). */ +static const unsigned char bfin_linux_fixed_code[] = {
> > > +0x28, 0xe1, 0xad, 0x00, 0xa0, 0x00, 0x00, 0x20,
> >
> > (...)
> >
> > > +0xa4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > +};
> >
> > Now this kernel code in question was probably (haven't
> > checked) largely written by ADI, and as such ADI could
> > probably contribute a standalone version of its source
> > to the FSF under GPLv3, along with some script or makefile
> > that compiles it with a bfin-gcc and then generates
> > the blob array. Or you could write simple dumb
> > replacement implementations of the interface instead?
>
> this code was written purely by ADI employees (2 or 3 of them to be exact), is
> written in pure Blackfin assembly, and we've explicitly licensed this file
> under GPLv2 or later. so i dont think this is an issue. it is not used by
> the kernel at all ... the code is placed in a fixed location for userspace
> binaries to call and is defined as part of the Blackfin ABI. see below.
> -mike
>
Thanks. Since the Linux kernel is a mixture of code under GPLv2
and `GPLv2 or later', the resulting compiled binary is GPLv2
only (not later), so it's still an issue to dump from
the kernel binary. And I think only the interface is
defined as part of the ABI, not the implementation?
To comply with the GPL, we need to provide the source of
that blob. I guess it's easy to do what I suggested
above then? Then the GPLv2-only of the Linux kernel
won't apply, and we're all happy.
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5] sim: bfin: new port
2011-03-02 1:13 ` Pedro Alves
@ 2011-03-02 2:23 ` Mike Frysinger
2011-03-02 9:30 ` Pedro Alves
0 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2011-03-02 2:23 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 2509 bytes --]
On Tuesday, March 01, 2011 20:13:34 Pedro Alves wrote:
> On Tuesday 01 March 2011 22:02:21, Mike Frysinger wrote:
> > On Tuesday, March 01, 2011 16:19:25 Pedro Alves wrote:
> > > On Tuesday 22 February 2011 20:26:44, Mike Frysinger wrote:
> > > > --- /dev/null
> > > > +++ b/sim/bfin/linux-fixed-code.h
> > > > @@ -0,0 +1,23 @@
> > > > +/* DO NOT EDIT: Autogenerated. */
> > > > +/* Fixed code region of Linux userspace starting at 0x400. Last
> > > > produced + from Linux-2.6.37 (not that the fixed code region
> > > > changes often). */ +static const unsigned char
> > > > bfin_linux_fixed_code[] = { +0x28, 0xe1, 0xad, 0x00, 0xa0, 0x00,
> > > > 0x00, 0x20,
> > >
> > > (...)
> > >
> > > > +0xa4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > > > +};
> > >
> > > Now this kernel code in question was probably (haven't
> > > checked) largely written by ADI, and as such ADI could
> > > probably contribute a standalone version of its source
> > > to the FSF under GPLv3, along with some script or makefile
> > > that compiles it with a bfin-gcc and then generates
> > > the blob array. Or you could write simple dumb
> > > replacement implementations of the interface instead?
> >
> > this code was written purely by ADI employees (2 or 3 of them to be
> > exact), is written in pure Blackfin assembly, and we've explicitly
> > licensed this file under GPLv2 or later. so i dont think this is an
> > issue. it is not used by the kernel at all ... the code is placed in a
> > fixed location for userspace binaries to call and is defined as part of
> > the Blackfin ABI. see below.
>
> Thanks. Since the Linux kernel is a mixture of code under GPLv2
> and `GPLv2 or later', the resulting compiled binary is GPLv2
> only (not later), so it's still an issue to dump from
> the kernel binary. And I think only the interface is
> defined as part of the ABI, not the implementation?
>
> To comply with the GPL, we need to provide the source of
> that blob. I guess it's easy to do what I suggested
> above then? Then the GPLv2-only of the Linux kernel
> won't apply, and we're all happy.
i want to avoid gcc to avoid the chicken&egg issue. an .s should be fine
since gdb is in the same tree as the assembler (and this code doesnt really
need CPP magic).
but i'd like to avoid this step when possible, so how about including the
generated file too, and adding a makefile target so that it is regenerated
whenever the .s changes ?
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH v5] sim: bfin: new port
2011-03-02 2:23 ` Mike Frysinger
@ 2011-03-02 9:30 ` Pedro Alves
2011-03-02 21:46 ` Mike Frysinger
0 siblings, 1 reply; 36+ messages in thread
From: Pedro Alves @ 2011-03-02 9:30 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
On Wednesday 02 March 2011 02:17:22, Mike Frysinger wrote:
> but i'd like to avoid this step when possible, so how about including the
> generated file too, and adding a makefile target so that it is regenerated
> whenever the .s changes ?
I don't see where's the chicken&egg, but in any case, yep, keeping the
generated file in the tree is what I was thinking. No need to force
people to have a build of a bfin compiler/assembler at hand to build the
host non-bfin gdb.
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v5] sim: bfin: new port
2011-03-02 9:30 ` Pedro Alves
@ 2011-03-02 21:46 ` Mike Frysinger
2011-03-02 23:32 ` Pedro Alves
2011-03-02 23:32 ` Pedro Alves
0 siblings, 2 replies; 36+ messages in thread
From: Mike Frysinger @ 2011-03-02 21:46 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
[-- Attachment #1: Type: Text/Plain, Size: 765 bytes --]
On Wednesday, March 02, 2011 04:30:08 Pedro Alves wrote:
> On Wednesday 02 March 2011 02:17:22, Mike Frysinger wrote:
> > but i'd like to avoid this step when possible, so how about including the
> > generated file too, and adding a makefile target so that it is
> > regenerated whenever the .s changes ?
>
> I don't see where's the chicken&egg
gcc needs an assembler, and that gets compiled with binutils/gdb. so i cant
make binutils/gdb need a compiler.
> but in any case, yep, keeping the
> generated file in the tree is what I was thinking. No need to force
> people to have a build of a bfin compiler/assembler at hand to build the
> host non-bfin gdb.
ok, i'll put this together. shouldnt take long.
any other feedback ? :)
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v5] sim: bfin: new port
2011-03-02 21:46 ` Mike Frysinger
@ 2011-03-02 23:32 ` Pedro Alves
2011-03-02 23:32 ` Pedro Alves
1 sibling, 0 replies; 36+ messages in thread
From: Pedro Alves @ 2011-03-02 23:32 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
On Wednesday 02 March 2011 21:46:35, Mike Frysinger wrote:
> any other feedback ? :)
> any other feedback ? :)
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v5] sim: bfin: new port
2011-03-02 21:46 ` Mike Frysinger
2011-03-02 23:32 ` Pedro Alves
@ 2011-03-02 23:32 ` Pedro Alves
1 sibling, 0 replies; 36+ messages in thread
From: Pedro Alves @ 2011-03-02 23:32 UTC (permalink / raw)
To: Mike Frysinger; +Cc: gdb-patches
On Wednesday 02 March 2011 21:46:35, Mike Frysinger wrote:
> gcc needs an assembler, and that gets compiled with binutils/gdb. so i cant
> make binutils/gdb need a compiler.
If you keep the generated file checked in, there's no such
problem. gcc would only be necessary when making
_changes_ to the fixed page thing, to regenerate the blob.
If someone wants to make some change to the fixed page
implementation in gdb, _and_ that someone can't get a
prebuilt bfin gcc for some reason, she can always start
by building bfin binutils, then bfin gcc, and
only _then_ build bfin gdb using the host gcc + the just
built cross bfin-gcc for regenerating the fixed user
page blob.
> any other feedback ? :)
Not at the moment. :-)
Thanks for addressing this.
--
Pedro Alves
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v6] sim: bfin: new port
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
` (2 preceding siblings ...)
2011-03-01 21:19 ` Pedro Alves
@ 2011-03-03 21:40 ` Mike Frysinger
2011-03-04 10:19 ` Pedro Alves
3 siblings, 1 reply; 36+ messages in thread
From: Mike Frysinger @ 2011-03-03 21:40 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1.1: Type: Text/Plain, Size: 83 bytes --]
this adds linux-fixed-code.s and auto generates linux-fixed-code.h from that
-mike
[-- Attachment #1.2: 0001-sim-bfin-new-port.patch.bz2 --]
[-- Type: application/x-bzip, Size: 149231 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2011-03-04 21:12 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-16 1:41 [PATCH] sim: bfin: new port Mike Frysinger
2010-12-31 23:12 ` [PATCH v2] " Mike Frysinger
2011-02-14 20:18 ` [PATCH v3] " Mike Frysinger
2011-02-14 20:49 ` Pedro Alves
2011-02-14 21:12 ` Mike Frysinger
2011-02-14 21:55 ` Pedro Alves
2011-02-14 22:11 ` Mike Frysinger
2011-02-14 22:23 ` Mike Frysinger
2011-02-15 16:25 ` Pedro Alves
2011-02-16 1:34 ` Mike Frysinger
2011-02-16 5:34 ` Joel Brobecker
2011-02-20 7:24 ` Mike Frysinger
2011-02-21 10:13 ` Joel Brobecker
2011-02-21 18:27 ` Mike Frysinger
2011-02-22 8:28 ` Joel Brobecker
2011-02-22 17:58 ` Mike Frysinger
2011-02-22 10:50 ` Pedro Alves
2011-02-22 18:07 ` Mike Frysinger
2011-02-22 10:08 ` Pedro Alves
2011-02-22 17:57 ` Mike Frysinger
2011-02-22 18:25 ` Pedro Alves
2011-02-22 20:54 ` Mike Frysinger
2011-02-22 20:29 ` [PATCH v5] " Mike Frysinger
2011-03-01 5:16 ` Mike Frysinger
2011-03-01 10:11 ` Joel Brobecker
2011-03-01 21:19 ` Pedro Alves
2011-03-01 23:42 ` Mike Frysinger
2011-03-02 1:13 ` Pedro Alves
2011-03-02 2:23 ` Mike Frysinger
2011-03-02 9:30 ` Pedro Alves
2011-03-02 21:46 ` Mike Frysinger
2011-03-02 23:32 ` Pedro Alves
2011-03-02 23:32 ` Pedro Alves
2011-03-03 21:40 ` [PATCH v6] " Mike Frysinger
2011-03-04 10:19 ` Pedro Alves
2011-03-04 21:12 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).