This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, RX] Add target rx-*-linux


On Fri, 03 Aug 2018 03:49:32 +0900,
Jeff Law wrote:
> 
> On 07/31/2018 10:58 PM, Yoshinori Sato wrote:
> > On Tue, 31 Jul 2018 21:49:37 +0900,
> > Oleg Endo wrote:
> >>
> >> Hi,
> >>
> >> On Tue, 2018-07-31 at 10:39 +0900, Yoshinori Sato wrote:
> >>>  
> >>> It standrad linux kernel.
> >>>
> >>> My target is RX62N + 16MByte external memory.
> >>> I think that connecting with a 32 bit bus is not so slow.
> >>
> >> The latest RX71/RX65 support 60 MHz 32 bit data external SDRAM.  On top
> >> of that, there is no instruction/data cache for external SDRAM.  The
> >> system was not designed to operate like that.  The primary use case for
> >> RX is to run code from on-chip flash and use on-chip RAM as application
> >> data.  Every individual access to external memory by the CPU costs
> >> about 3 bus cycles, from what I can see in the hardware manual...
> > 
> > I agree.
> > 
> > Because I have not done benchmarks, I only have my own sense,
> > but it works faster than I suppose.
> > 
> >>> Also, since the code size is small, I think the influence of memory
> >>> speed is relaxed.
> >>
> >> Even if all the Linux + user application code fits into the on-chip
> >> flash ROM, the problem will be the CPU accessing data in external
> >> memory without cache.  That's why I don't think it's practical to run
> >> Linux on RX MCUs.  It will run, but  there are better embedded Linux
> >> options for the same or lower price as RX MCUs.  So I'm not sure how
> >> useful this will be?
> > 
> > Although it is not ready yet, it is possible to place the code in the ROM area
> > including the user program.
> > I think that it is possible to create an environment where Linux can operate on
> > a single chip as long as it is an MCU with a large capacity memory.
> Or consider if one mated the -linux target with a glibc & qemu port for
> the rx.  You could then build a chroot of rx-linux binaries and
> bootstrap gcc within the chroot.
> 
> That turns out to be a nice stress test for code generator correctness.
> 
> Jeff

I think that it is difficult to bootstrap gcc because RX target
has severe restrictions on memory.
And qemu is not ready yet, if you do not use real hardware you need
to use gdb and sim, there is speed problem as well.

-- 
Yosinori Sato


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]