We're working on system mode support for Hexagon, and we plan to upstream it when it is ready.
Thanks, Taylor > -----Original Message----- > From: Rob Landley <r...@landley.net> > Sent: Monday, July 26, 2021 3:55 AM > To: Sid Manning <sidn...@quicinc.com>; Brian Cain <bc...@quicinc.com>; > Taylor Simpson <tsimp...@quicinc.com>; qemu-devel@nongnu.org; linux- > hexa...@vger.kernel.org > Cc: a...@rev.ng; peter.mayd...@linaro.org; richard.hender...@linaro.org; > phi...@redhat.com > Subject: Re: [PATCH 01/20] Hexagon HVX (target/hexagon) README > > On 7/26/21 2:57 AM, Rob Landley wrote: > > Anyway... it doesn't look like qemu-system-hexagon (softmmu) its > > currently in vanilla qemu? Is there a public fork that has this somewhere? > > I did a little wild flailing to get ./configure to give me a > qemu-system-hexagon > option (patch attached), I.E. just enough to get meson to shut up and quite > possibly still missing something important. (Is this python? It looks kind of > like > python.) > > Unfortunately after liberally cribbing from the cris architecture (which seems > like the simplest one) I'm left with several new C files to implement, all > currently zero length in the patch: > > hw/hexagon/boot.c > hw/hexagon/hexagon_comet.c > target/hexagon/machine.c > target/hexagon/mmu.c > > (In theory there's a "none" board on all the current qemu-system > architectures, but I've never figured out what to DO with those...) > > All this raises two problems: > > 1) I dunno how the hexagon mmu works. (I can presumably read the kernel > code and reverse engineer what that's looking for, but it would be really nice > not to _have_ to?) > > 2) What's a comet board? (Memory layout? I/O devices? I guess all I need for > serial console on initramfs is a contiguous block of DRAM, timer interrupt to > drive the scheduler, and a serial port. I keep thinking there should be a way > to tell the "none" board to add that stuff from the command line... but > dunno how. > "map DRAM here". "add this clock hardware at here". "add this kind of serial > port at here." "call elf_load on this file and start executing at its entry > point"...) > > 3) Reading the arch/hexagon kernel stuff ala "so what IS in a comet board"... > CONFIG_HEXAGON_COMET is only ever used to guard one #define in a > header file: > > arch/hexagon/include/asm/timer-regs.h:#define > RTOS_TIMER_REGS_ADDR > > Which is then used to initialize structure members in > arch/hexagon/kernel/time.c without any sort of guard there, and no it isn't > #defined to 0 by default anywhere I can see? And of course obj-y += time.o > in arch/hexagon/kernel/Makefile has no config guard there either. So if it > wasn't set, the build would break. And that's currently all the symbol does? > > Anyway, I still hope somebody else has already done most of this in a git tree > somewhere. :) > > Rob
