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

See the CrossGCC FAQ for lots more information.


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: [crosstool-NG] Design discussion


On Sat, Apr 11, 2009 at 8:13 PM, Rob Landley <rob@landley.net> wrote:
> On Saturday 11 April 2009 00:26:30 Thomas Charron wrote:
>> ? I'm talking about bare metal. ?Typically, these systems have no more
>> RAM then is present on the processor. ?Like, 64k. ?There is no
>> bootloader, no busybox, and most specifically, no OS.
> Yeah, I've encountered those, and written code for them. ?Often in assembly,
> since with those constraints you need every byte, and thus you haven't got
> the luxury of coding in C, so I'm not sure how it's relevant here. ?(Last I
> checked, gcc only supported 32 bit and higher targets as a policy decision,
> which rules out the z80 and such.)

  Saying '32 bit' doesn't really cover the full range.  You can have a
32 bit instruction pointer, but only a 16 bit data pointer, or vice
versa.  However, your inference here is clear, and is wrong.  There
are many 32 bit processors you cannot run Linux on, nor would you want
to.

> I'm impressed by the way the OpenBios guys use C code directly from ROM before
> the DRAM controller is set up. ?They put the CPU cache into direct mapped
> writeback mode, zero the first few cache lines, set the stack pointer to the
> start of the address range they just dirtied, and then jump to C code and
> make sure to never touch ANY other memory until the DRAM controller is up and
> stabilized. ?I.E. they're using the cache as their stack, so they can
> initialize the dram controller from C code instead of having to do it in
> assembly.
> Neat trick, I thought. ?But they don't consider it cross compiling, any more
> than the linux bootup code to set up page tables and jump from 16 bits to 32
> bits was cross compiling...

  Welcome to the world of the embedded.  That sort of initialization
is commonplace.  But you're only seeing the tip of the iceburg there.
Most times on embedded boards I'm working on, there IS no additional
RAM.  However, what I need to use that 60Mhz processor for is
complicated, and coding it in assembly would be complex.

  As an example, one specific project I've been involved with will
control up to 28 stepper motors microstepping at 256 us/s, while
performing operations against several other peripherals connected via
SPI.

  Your typically running from flash directly.

>> ? Yes. ?Since GCC is generally tested on 'real' systems, some versions
>> perform different then others depending on the target processor
>> itself.
> Some variants of gcc are broken, yes.
>> In some cases, occasionally a version of GCC simply won't
>> work at all for a given processor.
> Yes, that's why you need a version of GCC that's capable of outputting code
> for the processor. ?(So how do _you_ configure stock gcc+binutils source to
> output code for z80 or 8086 targets? ?Yes, I'm aware of
> http://www.delorie.com/djgpp/16bit/gcc/ and I'm also aware it's based on gcc
> 2.7 and hasn't been updated in 11 years.)

  Again, you're making a huge assumption that simply isn't valid.  If
you'd like to know how I can use gcc for, say, AVR32, motorola 64k,
MIPS, ARM7/9/Cortex, then we can talk.  Here are some examples of some
boards (most are simply links to Olimex boards, cheap and easy to find
links.  :-D ):

http://www.olimex.com/dev/avr-gsm.html
http://www.olimex.com/dev/tms320-p28016.html
http://www.olimex.com/dev/lpc-p2129.html
http://www.olimex.com/dev/stm32-h103.html
http://www.olimex.com/dev/stm32-103stk.html
http://www.coridiumcorp.com/ARMduino.php?gclid=CPPX-aO165kCFSAhDQodMlKhRg

>> > Could be, but I still don't understand why. ?Care to explain?
>> ? See above. ?bare metal *ISN"T* running Linux on a small box. ?It's
>> another beast entirely.
> Yes, I know. ?You can't natively compile on a target that can't run a
> compiler. ?I agree. ?How does that mean you need more than one compiler
> targeting the same hardware?

  Yes.  Same target does NOT mean the same hardware.

> I think you're confusing two different points I've made. ?The first is "You
> should be able to have a usable somewhat generic cross compiler for a given
> target architecture" with "When your target is Linux you should be able to
> build natively under emulation, and thus avoid cross compiling." ?Those are
> two completely different arguments.
> (And the second argument never claimed that the emulator and the target
> hardware you actually deployed would have exactly the same hardware, any more
> than Ubuntu's build servers and my laptop have exactly the same hardware. ?If
> I build a boot floppy image from my laptop, am I cross compiling? ?But it's
> still a different argument.)

  Again, you're misunderstanding.  I'm saying you've made point which
simply aren't valid to me, an actual user of crosstoll-NG.  They
simply aren't relevant.  I may need two distinct compilers for the
exact same processor target.

>> ? Specifically, I've been working with a mashed in version of newlib,
>> and newlib-lpc. ?In those cases, you actually don't use the GNU C
>> library at all.
> Yes, that would be the swapping out the built-in libraries and headers part,
> above. ?This can be done after the compiler is built with a fairly simple
> wrapper. ?(If gcc wasn't constructed entirely out of unfounded assumptions,
> you wouldn't even need to wrap it.)

  Then you should REALLY call up the GCC guys and make sure they know
that --with-newlib was a reeeaaaally bad idea so they can make lickity
split and fix their obvious error in thinking.

-- 
-- Thomas

--
For unsubscribe information see http://sourceware.org/lists.html#faq


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