Atmel website | ARM Community | AVR freaks | Technical Support
Banner
 FAQ •  Search •  Register •  Login 

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
 Post subject:
PostPosted: Wed Jun 06, 2007 10:23 pm 
Offline

Joined: Wed Feb 18, 2004 5:53 pm
Posts: 132
Location: Sweden
samus8zero2x wrote:
I'm a little confused about the process for setting up Buildroot for the AT91 series here. Is this right:

[snip]
The reason I am wondering is because of the make_boards script...is it really necessary to run it? It looks like it just downloads the latest buildroot-atmel and configures it (for all the boards?).




No, but this makes it easy for a newbie (once all bugs are ironed out)
to get what he/she wants without typing stuff manually.
After becoming a little more proficient, you obviously only
build the stuff you need to build.

_________________
Best Regards
Ulf Samuelsson


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 07, 2007 11:30 pm 
Offline

Joined: Tue Jan 09, 2007 8:33 pm
Posts: 22
So now I seem to be able to load the kernel and the ramdisk (ext2), but I also have the RTC issue and also, after the "Freeing init memory" message, the boot process seems to hang.

Any ideas? Is there a way I can configure and rebuild the kernel? I haven't been able to figure out how to build the kernel outside the buildroot make process...


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 08, 2007 3:46 pm 
Offline

Joined: Tue Jan 09, 2007 8:33 pm
Posts: 22
Alright...got this one figured out. I was making buildroot with GCC 4.1.2. I changed to GCC 4.0.4, switched to NPTL threading, and disabled ccache support. Actually I think the only thing that made a difference was GCC, but I did the others because I saw Google results indicating the ccache could cause a problem. I used NPTL because I prefer it...

Maybe this will help someone else who runs into this problem...


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 14, 2007 10:56 pm 
Offline

Joined: Mon Oct 23, 2006 4:15 pm
Posts: 53
Hi everybody, new buildroot works great. I wanted to change a few things from the default kernel and package configuration on the 9263-ek. I'm not sure what I did to cause this, but at boot I now get the following error and cant get into my filesystem:

Code:
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 12780KiB [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem).
Freeing init memory: 124K
INIT: version 2.86 booting
INIT: /etc/inittab[18]: duplicate ID field "null"
INIT: /etc/inittab[19]: duplicate ID field "null"
INIT: /etc/inittab[20]: duplicate ID field "null"eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1

INIT: /etc/inittab[21]: duplicate ID field "null"
INIT: /etc/inittab[22]: duplicate ID field "null"
INIT: /etc/inittab[24]: missing id field
INIT: /etc/inittab[31]: id field too long (max 4 characters)
INIT: /etc/inittab[34]: duplicate ID field "null"
INIT: /etc/inittab[35]: duplicate ID field "null"
INIT: /etc/inittab[36]: duplicate ID field "null"
INIT: /etc/inittab[40]: missing id field
INIT: /etc/inittab[43]: shutdown: unknown action field
INIT: /etc/inittab[44]: shutdown: unknown action field
INIT: /etc/inittab[45]: shutdown: unknown action field
INIT: /etc/inittab[46]: shutdown: unknown action field
mount: cannot read /proc/mounts: No such file or d
Enter runlevel:


Here are the actual contents of the inittab file:
Code:
# /etc/inittab
#
# Copyright (C) 2001 Erik Andersen <andersen>
#
# Note: BusyBox init doesn't support runlevels.  The runlevels field is
# completely ignored by BusyBox init. If you want runlevels, use
# sysvinit.
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# id        == tty to run on, or empty for /dev/console
# runlevels == ignored
# action    == one of sysinit, respawn, askfirst, wait, and once
# process   == program to run

# Startup the system
null::sysinit:/bin/mount -o remount,rw /
null::sysinit:/bin/mount -t proc proc /proc
null::sysinit:/bin/mount -a
null::sysinit:/bin/hostname -F /etc/hostname
null::sysinit:/sbin/ifconfig lo 127.0.0.1 up
null::sysinit:/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
# now run any rc scripts
::sysinit:/etc/init.d/rcS

# Set up a couple of getty's
#tty1::respawn:/sbin/getty 38400 tty1
#tty2::respawn:/sbin/getty 38400 tty2

# Put a getty on the serial port
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100

# Logging junk
null::sysinit:/bin/touch /var/log/messages
null::respawn:/sbin/syslogd -n -m 0
null::respawn:/sbin/klogd -n
tty3::respawn:/usr/bin/tail -f /var/log/messages

# Stuff to do for the 3-finger salute
::ctrlaltdel:/sbin/reboot

# Stuff to do before rebooting
null::shutdown:/usr/bin/killall klogd
null::shutdown:/usr/bin/killall syslogd
null::shutdown:/bin/umount -a -r
null::shutdown:/sbin/swapoff -a


I'm not sure what the contents of the original inittab was from building everything the first time. Anybody have any thoughts?

Thanks, Matt.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 20, 2007 4:49 pm 
Offline

Joined: Mon Oct 23, 2006 4:15 pm
Posts: 53
I dont know what happened, but the error is gone after rebuilding.

Anybody have experience building Qtopia for Atmel ARM yet? I get:

Code:
/usr/arm/buildroot-atmel/toolchain_build_arm_small/bin/sed -i -e 's/-O2/-Os -pipe  -I/usr/local/arm/gcc-4.1.2-uclibc/include -I/usr/arm/buildroot-atmel/toolchain_build_arm_small/linux/include/' /usr/arm/buildroot-atmel/toolchain_build_arm_small/qtopia-core-opensource-src-4.2.2/mkspecs/qws/linux-arm-g++/qmake.conf
/usr/arm/buildroot-atmel/toolchain_build_arm_small/bin/sed: -e expression #1, char 21: unknown option to `s'


when I try to build it. The offending line in qtopia4.mk is:

Code:
$(SED) 's/-O2/$(TARGET_CFLAGS)/' $(QTOPIA4_TARGET_DIR)/mkspecs/qws/linux-$(BR2_PACKAGE_QTOPIA4_EMB_PLATFORM)-g++/qmake.conf
   -[ -f $(QTOPIA4_QCONFIG_FILE) ] && cp $(QTOPIA4_QCONFIG_FILE) \
       $(QTOPIA4_TARGET_DIR)/$(QTOPIA4_QCONFIG_FILE_LOCATION)
   (cd $(QTOPIA4_TARGET_DIR); rm -rf config.cache; \
      PATH=$(TARGET_PATH) \
      CFLAGS="$(TARGET_CFLAGS)" \
      LDFLAGS="$(TARGET_LDFLAGS)" \
      CXXFLAGS="$(TARGET_CXXFLAGS)" \
      QPEHOME=/usr \
      QPEDIR=/usr \
      ./configure \
      -v \
      -platform linux-g++ \
      -embedded $(BR2_PACKAGE_QTOPIA4_EMB_PLATFORM) \
      -xplatform qws/linux-$(BR2_PACKAGE_QTOPIA4_EMB_PLATFORM)-g++ \
      $(QTOPIA4_QCONFIG_COMMAND) \
      $(QTOPIA4_DEBUG) \
      -depths 8 \
      -no-cups \
      -no-nis \
      -no-freetype \
      -no-accessibility \
      -no-libmng \
      -no-gif \
      -no-sql-db2 \
      -no-sql-ibase \
      -no-sql-mysql \
      -no-sql-oci \
      -no-sql-odbc \
      -no-sql-psql \
      -no-sql-sqlite \
      -no-sql-sqlite2 \
      -no-sql-tds \
      -prefix /usr \
      -prefix-install \
      -L $(STAGING_DIR)/usr/lib \
      -I $(STAGING_DIR)/usr/include \
      $(QTOPIA4_QT3SUPPORT) \
      $(QTOPIA4_TSLIB) \
      $(QTOPIA4_LARGEFILE) \
      $(QTOPIA4_ENDIAN) \
   );


I'm not too familiar with sed...can anybody see whats wrong here?

Thanks, Matt.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jul 24, 2007 8:56 pm 
Offline

Joined: Tue Jan 09, 2007 8:33 pm
Posts: 22
Hi mattwood2000,

I haven't tried to compile Qtopia or Qt-Embedded, but I have tried compiling every other GUI variant available in buildroot and none of them work. They all have issues with either threading, locales, or uClibc libraries in general.

Contrary to my previous posts, I have switched to using linuxthreads to see if it would help. It helps in some cases, but breaks in others, so I still can't compile anything new.

Best advice: try switching up combinations of uclibc, gcc, and binutils versions and see if any of them yield a working Qtopia compile. If you do get a good compile, post it!

For my troubles, I'm giving up on uClibc and going to glibc. I already have a working chroot environment and a working native toolchain in the chroot environment, but I'm working on optimizing the toolchain a little more before I try to build a new kernel and new RFS. If I'm successful, the buildroot kernel and RFS will simply be an easy way to boot from scratch and then chroot into a more robust environment.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron