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

[Jeff Law <law at redhat dot com>]

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