[OLPC-devel] Re: buildrom issues

[Jordan Crouse]

On 28/06/06 08:57 -0600, Ronald G Minnich wrote:
> gcc -shared -o libiw.so.28 -Wl,-soname,libiw.so.28  -lm -lc iwlib.so
> /usr/bin/ld: errno@@GLIBC_PRIVATE: TLS definition in /lib/libc.so.6 
> section .tbss mismatches non-TLS reference in iwlib.so
> iwlib.so: could not read symbols: Bad value

Hmm - yeah, something very bad is happening there.  I'll look into it,
but I can't promise you anything before tommorrow (Thursday).

> second, I had VERBOSE set there; not very verbose. In general, I don't 
> like systems that hide all the build steps. It took me a while to 
> realize, for example, that even though the top-level makefile said it 
> was making some things, it was not; and since the cycle is a ROM BIOS 
> reflash per iteration, this gets tiresome. We've found that for the case 
> that you are reflashing a BIOS, the more build spew you get, the better. 
> I.e., let's yank some of the @ from the makefiles :-)

Fair enough - it needs to be a good mix though - there is certainly some 
spew that isn't very useful.  Feel free to start removing @ where you wish.

One interesting thing to do is to define a variable like this:

ifeq ($(VERBOSE),y)
VFLAG=
else
VFLAG=@
endif

And then putting $(VFLAG) on the front of those lines you want to see when
VERBOSE=y instead of the hardcoded @.

> third, I guess I need to fix up some dependencies. the only way to 
> reliably assure that I get my mods in is to
> make clean && make

This is one of the problems of the system as designed right now -
dependencies don't always work well (or sometimes at all).  Definitely
an area to look at, if anybody out there is a GNU make expert with free time.

> i.e. there might be a /proc in device.txt, so mount proc after the 
> devices are made.

Mmm... good point.  /sys should be in the devices.txt too.

> Fifth, here is the device.txt that gets me mostly there:
> [rminnich at q buildrom]$ more ../buildrom-old/skeleton/device.txt
> /dev            d       755     0       0
> /proc           d       555     0       0
> /mntpoint       d       777     0       0
> /dev/null       c       640     0       0       1       3
> /dev/zero       c       640     0       0       1       5
> /dev/tty        c       640     0       0       5       0
> /dev/tty0       c       640     0       0       4       0
> /dev/console    c       640     0       0       5       1
> /dev/sda1       b       640     0       0       8       1
> /dev/sda2       b       640     0       0       8       2
> /dev/sda3       b       640     0       0       8       3
> /dev/sda4       b       640     0       0       8       4
> 
> Am I doing something wrong here?

That looks correct to me.   I'll add it to the GIT tree (again, probably
tommorrow).

> Finally ... although I really love the klb, we've done a lot of work 
> with similar systems here, and ... when things go south, it's really 
> nice to have a shell prompt. Right now, I get an error from klb, and the 
>  diagnostic is rebuild things and reflash. This is really tiring. If I 
> had a shell prompt, there is some poking around I could do.

I'm really of two minds on that - one one hand, the shell prompt is good,
but on the other hand, its not really very useful in a production
environment.  I wonder if we could continue to develop the klb, but add some
code to exec() a shell with a key-press at the right time.  Then, when
the klb goes to production, the shell, and the magic key press disappear.

I'm just not ready to abandon the klb quite yet - I think there is a
reasonable amount of potential there, and you can't argue with the size.

I'll send out an e-mail when I update the tree.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>