[J-core] 2 CPU:s or nothing

[Daniel V]

2016-11-26 19:40 GMT+01:00, Rob Landley <rob at landley.net>:
>
>
> On 11/25/2016 09:41 PM, Daniel V wrote:
>> 2016-11-26 0:09 GMT+01:00, Rob Landley <rob at landley.net>:
>>> On 11/25/2016 12:04 PM, Daniel V wrote:
>>>> Hi!
>>>>
>>>> Ok, some philosophical stuff here. And not critique of any kind.
>>>>
>>>> I just want to remind about something...
>>>>
>>>> If you want to boot a system you have a MCU and a CPU. Why cant both
>>>> be built upon j-core?
>>>
>>> If by MCU you mean microntroller instead of marvel cinematic universe,
>>> you can have a J1 and a J2 instance at the same time, sure. I suppose it
>>> might be a little like the big.little stuff the arm guys are doing, but
>>> that always struck me as overcomplicated.
>>
>> Well that was not what I was talking about. That they are trying to
>> do, is reducing power consumption.
>
> The two processors can run at the same time, and don't have to run the
> same code. Qualcomm's Snapdragon SOC in most android phones has 4
> different processors in it, only one of which runs Linux. (Although I
> helped port Linux to the hexagon, but that's not what's running in the
> android versions.)
>
> So yes, hardware like that exists. Programming it in new ways is your
> problem.

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?



>> What I was implying is that a built in MCU could be used to handle
>> real-time events.
>
> We have DSPs and we have SMP. You want a third kind of processor
> because...?

I was talking one processors like the others used for a thing a MCU
normally does.

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?



>> And i suggested a extra j-core with RAM, to get rid of an external MCU
>> for real-time i/o and thinks like that.
>
> It's already SMP. You can run Linux on one processor and run something
> else on the other processor _today_ if you want to.

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?


>>>> I understand if you want to build a custom platform that you can dump
>>>> that FPGA and separate MCU, but it would be highly specific. But why
>>>> not make it more general?
>>>
>>> You're the one who proposed having the separate MCU in the first place?
>>
>> I was implying that a MCU is in many applications needed for real-time
>> stuff, you can have that MCU inside the ASIC instead. If someone don't
>> need that, it's their application. I don't condone it.
>
> You can dedicate a processor to the realtime task, yes. That's how
> Google does their self-driving cars, they don't even use rtlinux, they
> just taskset each process to a specific processor and have one for the
> system (which the kernel threads are all taskset to).

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?


> They did a video on this at ELC back in 2013:
>
>   https://www.youtube.com/watch?v=7Yd9Ij0INX0
>
> If you're not comfortable enough with Linux to be sure it can keep its
> hands off your process, you can have the process run on the bare metal
> under an RTOS. That's about how Android works on Snapdragons, with the
> Arm "scorpion" processor running Linux and the QDSP6 "hexagon" processor
> running a hand-rolled ball of qualcomm realtime weirdness that handles
> baseband signal processing and also offloads video/audio compression
> stuff. In the snapdragon case they _could_ both be android chips (or
> more likely could both be hexagon chips, which was part of the
> motivation behind porting linux to run natively on hexagon in 2010, but
> there was qualcomm internal politics between the Austin and Raleigh
> campsus and the lawyers were the ones in control of the company anyway
> so it didn't really matter what either engineering group wanted...).

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?



>> I was
>> talking about reducing the number of parts, not adding to it. You are
>> the one talking about adding things.
>
> You're talking about adding an MCU.

I was talking one processors like the others used for a thing a MCU
normally does.

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?



>>>> Maybe it's possible to reduce the need of the number of development
>>>> chains to a fewer number, by letting that MCU be built upon a J-core.
>>>
>>> The one you proposed using in the first place? Maybe. (I assume you mean
>>> toolchains. Is having different toolchains a high bar? My aboriginal
>>> linux project had a dozen or so, and I've built something like 8 targets
>>> with Rich's musl-cross-make.)
>>
>> Yes, my main language isn't English.
>>
>> But does it have a tool-chain for AVR or PIC and things that isn't
>> linux?
>
> I mostly don't personally bother, no. (I did plenty of 8-bit programming
> back in the day, but none of it was in C. I haven't done 16-bit C
> programming since DOS. (I'm aware of http://elks.sf.net but didn't play
> with it.) I've done bare metal programming in u-boot and such this
> decade, but other than J-core most recently that was on hexagon, Armv7,
> Cortex-M.) Back when I maintained my own fork of tinycc circa 2008 it
> did have output for TMS320 but I didn't have a test environment for that
> output.
>
> I assume your hardware vendor can point you to a relevant toolchain, if
> not an outright BSP?

I don't need that tool-chain.

I was talking one processors like the others used for a thing a MCU
normally does.

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?



>>>> Maybe that wouldn't be space efficient, but is that really a concern.
>>>
>>> A concern for what? While doing what? Trying to accomplish what?
>>
>> To accomplish real-time applications by offloading a CPU running
>> Linux.
>
> I wouldn't try to run two instances of Linux on the same machine (modulo
> virtualization), but you can run Linux and non-Linux on different
> processors. That's fairly common.
>
>> The context switching in linux would take more power and gain
>> poor results, than using one extra core with a small amount of RAM.
>
> I'm under the impression tying a third processor into the L1 cache
> design we have now would be a routing nightmare, so adding a third
> processor at the moment means it wouldn't share memory but would instead
> have its own sram. It got proposed as a way to handle a couple things,
> but didn't happen because it's not worth the transistors.

I have never suggested that.

I was talking one processors like the others used for a thing a MCU
normally does.

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?



>>>> and then be load new programs into RAM.
>>>
>>> Usually that's what a boot rom does, yes?
>>
>> I was talking about loading a program with that MCU, and then use that
>> MCU for real-time handling.
>
> Usually people who have linux and something else running on different
> processors load the something else from linux using a kernel module (the
> processors start quiesced), or if it's on a different kind of processor
> they sometimes use the Linux "firmware loading" mechanism. But feel free
> to reinvent this wheel in a different way I guess?

You have already confirmed that it's not reinventing anything.

I was talking one processors like the others used for a thing a MCU
normally does.

You only confirm it a good idea to have two processors, and one not
running Linux. Why where you bashing it?