RE: [PATCH 01/20] Hexagon HVX (target/hexagon) README

[Taylor Simpson]

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 <rob@landley.net>
> Sent: Monday, July 26, 2021 3:55 AM
> To: Sid Manning <sidneym@quicinc.com>; Brian Cain <bcain@quicinc.com>;
> Taylor Simpson <tsimpson@quicinc.com>; qemu-devel@nongnu.org; linux-
> hexagon@vger.kernel.org
> Cc: ale@rev.ng; peter.maydell@linaro.org; richard.henderson@linaro.org;
> philmd@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