Menu
▾
▴
blob-cvs-commit — blob CVS commit messages list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(79) |
Aug
(27) |
Sep
(64) |
Oct
(202) |
Nov
(31) |
Dec
(59) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(125) |
Feb
(173) |
Mar
(13) |
Apr
(140) |
May
(75) |
Jun
(1) |
Jul
(37) |
Aug
(14) |
Sep
|
Oct
(20) |
Nov
(9) |
Dec
(2) |
| 2003 |
Jan
(51) |
Feb
(12) |
Mar
(18) |
Apr
(24) |
May
(1) |
Jun
|
Jul
|
Aug
(72) |
Sep
(12) |
Oct
(18) |
Nov
(60) |
Dec
(26) |
| 2004 |
Jan
(1) |
Feb
(40) |
Mar
(3) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(5) |
| 2006 |
Jan
(13) |
Feb
(5) |
Mar
(8) |
Apr
(13) |
May
(7) |
Jun
(6) |
Jul
(10) |
Aug
(6) |
Sep
(6) |
Oct
(35) |
Nov
(20) |
Dec
(10) |
| 2007 |
Jan
(13) |
Feb
(9) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(54) |
Jun
(78) |
Jul
(35) |
Aug
(21) |
Sep
(21) |
Oct
(29) |
Nov
(10) |
Dec
(5) |
| 2010 |
Jan
|
Feb
|
Mar
(26) |
Apr
(55) |
May
(73) |
Jun
(63) |
Jul
(38) |
Aug
(39) |
Sep
(19) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2011 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Stefan E. <se...@us...> - 2003-11-05 10:09:50
|
Update of /cvsroot/blob/blob/include/blob/arch In directory sc8-pr-cvs1:/tmp/cvs-serv10102/include/blob/arch Added Files: ra_alpha.h Log Message: basic support for the RotAlign Alpha Base CPU Board --- NEW FILE: ra_alpha.h --- /* * ra_alpha.h: PT Rotalign Alpha * * Based on csir_ims.h * * Copyright (C) 2001 Erik Mouw (J.A...@it...) * Copyright (C) 2002 Holger Schurig <h.s...@mn...> * Copyright (C) 2002 Jeff Sutherland <je...@ac...> * Copyright (C) 2003 Abraham vd Merwe <ab...@4d...> * Copyright (C) 2003 Stefan Eletzhofer <ste...@in...> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef BLOB_ARCH_CSIR_IMS_H #define BLOB_ARCH_CSIR_IMS_H #define USE_SERIAL1 #define TERMINAL_SPEED baud_115200 /* the base address were BLOB is loaded by the first stage loader */ #define BLOB_ABS_BASE_ADDR (0xa0200400) /* where do various parts live in RAM */ #define BOOT_PARAMS (0xa0000100) #define BLOB_RAM_BASE (0xa0100000) #define PARAM_RAM_BASE (0xa0200000) #define KERNEL_RAM_BASE (0xa0800000) #define RAMDISK_RAM_BASE (0xa1000000) /* and where do they live in flash */ #define BLOB_FLASH_BASE (0x00000000) #define BLOB_FLASH_LEN (128 * 1024) #define PARAM_FLASH_BASE (BLOB_FLASH_BASE + BLOB_FLASH_LEN) #define PARAM_FLASH_LEN (128 * 1024) #define KERNEL_FLASH_BASE (PARAM_FLASH_BASE + PARAM_FLASH_LEN) #define KERNEL_FLASH_LEN (1024 * 1024) #define RAMDISK_FLASH_BASE (KERNEL_FLASH_BASE + KERNEL_FLASH_LEN) #define RAMDISK_FLASH_LEN (4 * 1024 * 1024) /* this needs to be defined if you want parameter block support */ #define PARAM_START PARAM_FLASH_BASE #define PARAM_LEN PARAM_FLASH_LEN /* load ramdisk into ram */ #define LOAD_RAMDISK 1 /* the size (in kbytes) to which the compressed ramdisk expands */ #define RAMDISK_SIZE (4 * 1024) #if 0 #define MSC0_VALUE 0x #define MSC1_VALUE 0x #define MSC2_VALUE 0x #define MECR_VALUE 0x #define MCMEM0_VALUE 0x #define MCMEM1_VALUE 0x #define MCATT0_VALUE 0x #define MCATT1_VALUE 0x #define MCIO0_VALUE 0x #define MCIO1_VALUE 0x #endif #define MDREFR_VALUE 0x01018013 #define MDCNFG_VALUE 0x000019c9 #define MDMRS_VALUE 0x00020002 /* GPIO configuration */ /*#define GPIO0_VALUE GPIO_OUT_LO*/ #define GPIO0_VALUE GPIO_OUT_HI #define GPIO1_VALUE GPIO_OUT_LO #define GPIO2_VALUE GPIO_OUT_LO #define GPIO3_VALUE GPIO_INPUT /* eth_wakeup */ #define GPIO4_VALUE GPIO_INPUT /* bank_switch_int */ #define GPIO5_VALUE GPIO_INPUT /* eth_link_status */ #define GPIO6_VALUE GPIO_OUT_LO #define GPIO7_VALUE GPIO_OUT_LO /* cpld_clk */ #define GPIO8_VALUE GPIO_OUT_LO #define GPIO9_VALUE GPIO_INPUT /* eth_int */ #define GPIO10_VALUE GPIO_OUT_HI /* eth_reset */ #define GPIO11_VALUE GPIO_OUT_LO #define GPIO12_VALUE GPIO_OUT_LO /* watchdog_strobe */ #define GPIO13_VALUE GPIO_INPUT /* cpld_hw_reset */ #define GPIO14_VALUE GPIO_INPUT /* cpld_?? */ #define GPIO15_VALUE (GPIO_OUT_HI | GPIO_ALT_FN2) /* nCS1 [img_buffer] */ #define GPIO16_VALUE GPIO_OUT_LO #define GPIO17_VALUE GPIO_INPUT /* cpld_?? */ #define GPIO18_VALUE GPIO_INPUT /* vlio_ready_signal */ #define GPIO19_VALUE GPIO_OUT_LO #define GPIO20_VALUE GPIO_OUT_LO #define GPIO21_VALUE GPIO_OUT_LO #define GPIO22_VALUE GPIO_OUT_LO #define GPIO23_VALUE GPIO_OUT_LO #define GPIO24_VALUE GPIO_OUT_LO #define GPIO25_VALUE GPIO_OUT_HI /* LED [debug] */ #define GPIO26_VALUE GPIO_OUT_LO #define GPIO27_VALUE GPIO_OUT_LO #define GPIO28_VALUE GPIO_OUT_LO #define GPIO29_VALUE GPIO_OUT_LO #define GPIO30_VALUE GPIO_OUT_LO #define GPIO31_VALUE GPIO_OUT_LO #define GPIO32_VALUE GPIO_OUT_LO #define GPIO33_VALUE GPIO_OUT_HI /* nCS5 [unused] */ #define GPIO34_VALUE (GPIO_INPUT | GPIO_ALT_FN1) /* FFRXD */ #define GPIO35_VALUE GPIO_OUT_LO #define GPIO36_VALUE GPIO_OUT_LO #define GPIO37_VALUE GPIO_OUT_LO #define GPIO38_VALUE GPIO_OUT_LO #define GPIO39_VALUE (GPIO_OUT_LO | GPIO_ALT_FN2) /* FFTXD */ #define GPIO40_VALUE GPIO_OUT_LO #define GPIO41_VALUE GPIO_OUT_LO #define GPIO42_VALUE GPIO_OUT_LO #define GPIO43_VALUE GPIO_OUT_LO #define GPIO44_VALUE GPIO_OUT_LO #define GPIO45_VALUE GPIO_OUT_LO #define GPIO46_VALUE GPIO_OUT_LO #define GPIO47_VALUE GPIO_OUT_LO #define GPIO48_VALUE GPIO_OUT_LO #define GPIO49_VALUE GPIO_OUT_HI /* cpld_pcmcia_pwe */ #define GPIO50_VALUE GPIO_OUT_LO #define GPIO51_VALUE GPIO_OUT_LO #define GPIO52_VALUE GPIO_OUT_LO #define GPIO53_VALUE GPIO_OUT_LO #define GPIO54_VALUE GPIO_OUT_LO #define GPIO55_VALUE GPIO_OUT_LO #define GPIO56_VALUE GPIO_INPUT #define GPIO57_VALUE GPIO_INPUT #define GPIO58_VALUE GPIO_OUT_LO #define GPIO59_VALUE GPIO_OUT_LO #define GPIO60_VALUE GPIO_OUT_LO #define GPIO61_VALUE GPIO_OUT_LO #define GPIO62_VALUE GPIO_OUT_LO #define GPIO63_VALUE GPIO_OUT_LO #define GPIO64_VALUE GPIO_OUT_LO #define GPIO65_VALUE GPIO_OUT_LO #define GPIO66_VALUE GPIO_OUT_LO #define GPIO67_VALUE GPIO_OUT_LO #define GPIO68_VALUE GPIO_OUT_LO #define GPIO69_VALUE GPIO_OUT_LO #define GPIO70_VALUE GPIO_OUT_LO #define GPIO71_VALUE GPIO_OUT_LO #define GPIO72_VALUE GPIO_OUT_LO #define GPIO73_VALUE GPIO_OUT_LO #define GPIO74_VALUE GPIO_OUT_LO #define GPIO75_VALUE GPIO_OUT_LO #define GPIO76_VALUE GPIO_OUT_LO #define GPIO77_VALUE GPIO_OUT_LO #define GPIO78_VALUE (GPIO_OUT_HI | GPIO_ALT_FN2) /* nCS2 [img_buffer] */ #define GPIO79_VALUE (GPIO_OUT_HI | GPIO_ALT_FN2) /* nCS3 [eth] */ #define GPIO80_VALUE GPIO_OUT_HI /* nCS4 [unused] */ #define GPIO81_VALUE GPIO_OUT_LO #define GPIO82_VALUE GPIO_OUT_LO #define GPIO83_VALUE GPIO_OUT_LO #define GPIO84_VALUE GPIO_OUT_LO #endif /* #ifndef BLOB_ARCH_CSIR_IMS_H */ |
|
From: Stefan E. <se...@us...> - 2003-11-05 10:09:50
|
Update of /cvsroot/blob/blob/src/blob
In directory sc8-pr-cvs1:/tmp/cvs-serv10102/src/blob
Modified Files:
Makefile.am
Added Files:
ra_alpha.c
Log Message:
basic support for the RotAlign Alpha Base CPU Board
--- NEW FILE: ra_alpha.c ---
/*
* ra_alpha.c: PT Rotalign alpha
*
* Based on csir_ims.c
*
* Copyright (C) 2003 Abraham van der Merwe <ab...@4d...>
* Copyright (C) 2003 Stefan Eletzhofer <ste...@in...>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#ifdef HAVE_CONFIG_H
# include <blob/config.h>
#endif
#include <blob/main.h>
#include <blob/arch.h>
#include <blob/errno.h>
#include <blob/error.h>
#include <blob/util.h>
#include <blob/reboot.h>
#include <blob/serial.h>
#include <blob/flash.h>
#include <blob/init.h>
#include <blob/command.h>
#include <blob/uucodec.h>
#include <blob/led.h>
#include <blob/partition.h>
#include <blob/time.h>
#define GPIO25_LED GPIO_bit(0)
static int led_state;
static int led_locked;
static void rt_alpha_led_on (void)
{
if (!led_locked) {
GPSR0 = GPIO25_LED;
led_state = 1;
}
}
static void rt_alpha_led_off (void)
{
if (!led_locked) {
GPCR0 = GPIO25_LED;
led_state = 0;
}
}
static void rt_alpha_led_toggle (void)
{
if (led_state)
rt_alpha_led_off ();
else
rt_alpha_led_on ();
}
static void rt_alpha_led_lock (void)
{
led_locked = 1;
}
static void rt_alpha_led_unlock (void)
{
led_locked = 0;
}
static void rt_alpha_init_driver (void)
{
static led_driver_t rt_alpha_led_driver = {
.led_on = rt_alpha_led_on,
.led_off = rt_alpha_led_off,
.led_toggle = rt_alpha_led_toggle,
.led_lock = rt_alpha_led_lock,
.led_unlock = rt_alpha_led_unlock
};
static const flash_descriptor_t flash[] = {
{
.size = 128 * 1024,
.num = 64,
.lockable = 1
},
{ /* NULL block */ }
};
static blob_partition_t partitions[] = {
{
.magic = BLOB_DEFAULT_PART_TABLE_MAGIC,
.next = sizeof (blob_partition_t),
.offset = 0x00000000,
.size = BLOB_PART_SIZ_FULL
}, {
.magic = BLOB_PART_VALID_MAGIC,
.next = sizeof (blob_partition_t),
.offset = BLOB_PART_OFS_APPEND,
.size = BLOB_FLASH_LEN,
.name = "blob",
.mem_base = BLOB_RAM_BASE
}, {
.magic = BLOB_PART_VALID_MAGIC,
.next = sizeof (blob_partition_t),
.offset = BLOB_PART_OFS_APPEND,
.size = PARAM_FLASH_LEN,
.name = "param",
.flags = BLOB_PART_FLAG_PTABLE
}, {
.magic = BLOB_PART_VALID_MAGIC,
.next = sizeof (blob_partition_t),
.offset = BLOB_PART_OFS_APPEND,
.size = KERNEL_FLASH_LEN,
.name = "kernel",
.flags = BLOB_PART_FLAG_EXEC,
.mem_base = KERNEL_RAM_BASE,
.entry_point= KERNEL_RAM_BASE
}, {
.magic = BLOB_PART_VALID_MAGIC,
.next = sizeof (blob_partition_t),
.offset = BLOB_PART_OFS_APPEND,
.size = RAMDISK_FLASH_LEN,
.name = "ramdisk",
.flags = BLOB_PART_FLAG_LOAD,
.mem_base = RAMDISK_RAM_BASE
}, {
.magic = BLOB_PART_VALID_MAGIC,
.next = sizeof (blob_partition_t),
.offset = BLOB_PART_OFS_APPEND,
.size = BLOB_PART_SIZ_FULL,
.name = "jffs2",
.flags = BLOB_PART_FLAG_JFFS2
}, {
.magic = BLOB_PART_LAST_MAGIC
}
};
GPDR0 |= GPIO25_LED;
flash_descriptors = flash;
reboot_driver = &pxa_reboot_driver;
serial_driver = &pxa_serial_driver;
flash_driver = &intel32_flash_driver;
led_driver = &rt_alpha_led_driver;
timer_driver = &intelarm_timer_driver;
default_partition_table = partitions;
flash_partition_table = (blob_partition_t *) 0x00000000;
}
__initlist (rt_alpha_init_driver,INIT_LEVEL_DRIVER_SELECTION);
Index: Makefile.am
===================================================================
RCS file: /cvsroot/blob/blob/src/blob/Makefile.am,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -d -r1.46 -r1.47
--- Makefile.am 4 Sep 2003 18:10:42 -0000 1.46
+++ Makefile.am 5 Nov 2003 10:09:45 -0000 1.47
@@ -86,7 +86,8 @@
xmodem.c \
accelent_sa.c assabet.c brutus.c badge4.c cep.c clart.c dafit.c frodo.c \
hackkit.c h3600.c idr.c jornada720.c lart.c miniprint.c nesa.c pleb.c \
- ramses.c shannon.c smdk2500.c system3.c trizeps.c pxa_idp.c csir_ims.c
+ ramses.c shannon.c smdk2500.c system3.c trizeps.c pxa_idp.c csir_ims.c \
+ ra_alpha.c
blob_rest_elf32_DEPENDENCIES = \
|
|
From: Yamijala S. <Sri...@si...> - 2003-10-19 04:04:03
|
Hi All ! The problem Im facing is that after downloading 'blob' to target, I expect to see something on the hyper-terminal of my host windows sytem...saying uncompressing linux kernel or something like that but nothing is seen...not even a shell. Could someone please tell me what the problem could be? Thank You Sridhar -----Original Message----- From: Yamijala Sridhar Sent: Thursday, October 16, 2003 3:26 PM To: 'Christopher Hoover' Cc: blo...@li... Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs Hi All ! Ok...I got to the stage of compiling "blob" to any known board (Assabet,Creditlart,Lart,system3 etc.) but I have one problem. The compiled blob image doesnt boot Linux from FLASH when downloaded to target.I tried it with various images but it doesnt work.Could it be that the board isnt any of the standard ones? Moreover, when I tried to compile "blob" by setting -mtune=strongarm1110, there was a configuration error saying that the cross-compiler tool chain doesnt support that but it compiles fine when i retain the value of -mtune=strongarm1100.My board is SA1110-based, uses an LCD and SDRAM. So, could someone pls tell me what exactly is the problem? Im trying to get the schematics from the vendor to know whether the board is different from the standard board. Any help or suggestions meanwhile will be very much welcome. Thank You Sridhar |
|
From: Yamijala S. <Sri...@si...> - 2003-10-16 09:50:06
|
Hi All ! Ok...I got to the stage of compiling "blob" to any known board (Assabet,Creditlart,Lart,system3 etc.) but I have one problem. The compiled blob image doesnt boot Linux from FLASH when downloaded to target.I tried it with various images but it doesnt work.Could it be that the board isnt any of the standard ones? Moreover, when I tried to compile "blob" by setting -mtune=strongarm1110, there was a configuration error saying that the cross-compiler tool chain doesnt support that but it compiles fine when i retain the value of -mtune=strongarm1100.My board is SA1110-based, uses an LCD and SDRAM. So, could someone pls tell me what exactly is the problem? Im trying to get the schematics from the vendor to know whether the board is different from the standard board. Any help or suggestions meanwhile will be very much welcome. Thank You Sridhar |
|
From: Yamijala S. <Sri...@si...> - 2003-10-13 11:57:11
|
Hallo All ! Now, Im trying to compile blob for "system3" board, but i find that although i change the board name in ./configure, the compilation is still done for LART only and with such a blob image, im not able to boot linux.My board is SA-1110 based. I find that LART by default, uses sa1100 CPU and related files.Also, it doesnt use an LCD. With my new board, I have an LCD, CPU is sa1110 and uses SDRAM. So, I tried to compile for system3. When Im trying to compile blob for system3, by changing the board-name to system3, I find that the changes have no effect. I find blob using the same lart related files. why is this so? The changes made were: In ./configure file: ------------------------ --with-board=system3 --with-linux-prefix=home/sridhar/linux-2.4.20 In ./configure.in file: ---------------------------- -mtune=strongarm1110 In acconfig.h file: ------------------------ #define PT_SYSTEM3 #define SA1110 I know Chris told me not to tamper with ./configure.in and ./acconfig.h files and i tried but even that didnt help. So, after reading "porting.txt", I tried with the above modifications. Now, could someone please tell me what are the changes that i need to do to compile blob for system3. I did read the "porting.txt" file also the "README" file. I dont know where im going wrong. Thank You Sridhar -----Original Message----- From: Christopher Hoover [mailto:ch...@mu...] Sent: Thursday, October 09, 2003 10:35 PM To: Yamijala Sridhar Cc: blo...@li... Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs Sorry for the long mail but could someone please be more specific and tell me what exactly BLOB looks for in a Configured Linux Kernel tree and why? I've already explained why we use from the kernel tree.. If you want to know the specific files, look through the source. In "configure.in", I changed the --with-board=NAME to --with-board=lart. Then in acconfig.h, I changed the #undef LART to #define LART and also defined CPU as SA1100 Then in "configure", I changed the --with-board=NAME to --with-board=lart and --with-linux-prefix=/home/sridhar/linux-2.4.20 where i have a configured Linux kernel tree but with not all *.c files available. Have you read the README file?? Do not modifiy configure.in and acconfig.h. Follow the instructions precisely and get blob working, before you attempt to "optimize" the process. I won't help you until further until you *follow the instructions*. -ch |
|
From: Yamijala S. <Sri...@si...> - 2003-10-10 13:55:33
|
Sorry Chris ! Thank you for your reminder.It did help me really ! The problem was that the blob-2.0.5-pre2.tar.gz that I had downloaded was not proper. There was some download problem because of which certain files that were missing upon extraction. I realised it only after your reminder. Now, with a correct download, I am able to generate the binary image. Thank You Sridhar -----Original Message----- From: Christopher Hoover [mailto:ch...@mu...] Sent: Thursday, October 09, 2003 10:35 PM To: Yamijala Sridhar Cc: blo...@li... Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs Sorry for the long mail but could someone please be more specific and tell me what exactly BLOB looks for in a Configured Linux Kernel tree and why? I've already explained why we use from the kernel tree.. If you want to know the specific files, look through the source. In "configure.in", I changed the --with-board=NAME to --with-board=lart. Then in acconfig.h, I changed the #undef LART to #define LART and also defined CPU as SA1100 Then in "configure", I changed the --with-board=NAME to --with-board=lart and --with-linux-prefix=/home/sridhar/linux-2.4.20 where i have a configured Linux kernel tree but with not all *.c files available. Have you read the README file?? Do not modifiy configure.in and acconfig.h. Follow the instructions precisely and get blob working, before you attempt to "optimize" the process. I won't help you until further until you *follow the instructions*. -ch |
|
From: Christopher H. <ch...@mu...> - 2003-10-09 17:06:09
|
Sorry for the long mail but could someone please be more specific and = tell me=20 what exactly BLOB looks for in a Configured Linux Kernel tree and why? =20 I've already explained why we use from the kernel tree.. If you want = to know the specific files, look through the source. =20 In "configure.in", I changed the --with-board=3DNAME to = --with-board=3Dlart.=20 Then in acconfig.h, I changed the #undef LART to #define LART and also defined CPU as SA1100=20 Then in "configure", I changed the --with-board=3DNAME to = --with-board=3Dlart and=20 --with-linux-prefix=3D/home/sridhar/linux-2.4.20 where i have a = configured Linux kernel tree=20 but with not all *.c files available. =20 Have you read the README file??=20 =20 Do not modifiy configure.in and acconfig.h. =20 =20 Follow the instructions precisely and get blob working, before you = attempt to "optimize" the process. =20 =20 I won't help you until further until you *follow the instructions*.=20 =20 -ch=20 =20 |
|
From: Yamijala S. <Sri...@si...> - 2003-10-09 12:49:22
|
Hi All!
Sorry for the long mail but could someone please be more specific and tell
me
what exactly BLOB looks for in a Configured Linux Kernel tree and why?
I mean could you pls confirm whether or not it needs *.c files from a
configured kernel tree.
I suppose it is logical that it should neither look for $LINUX/src/*.c files
nor should it look for $LINUX/include/linux/*.h files. Is this true?
Im asking these because i am trying to customise BLOB to my requirement and
Im facing problems.
The customisation that i did for BLOB is:
In "configure.in", I changed the --with-board=NAME to --with-board=lart.
Then in acconfig.h, I changed the #undef LART to #define LART and also
defined CPU as SA1100
Then in "configure", I changed the --with-board=NAME to --with-board=lart
and
--with-linux-prefix=/home/sridhar/linux-2.4.20 where i have a configured
Linux kernel tree
but with not all *.c files available.
The $LINUX/include/asm files are in the path:
/home/sridhar/linux-2.4.20/asm-arm/arch-sa1100
Then i type the following at the bash shell command prompt:
export CC=arm-linux-gcc
export OBJCOPY=arm-linux-objcopy
Then i run ./configure
I get the following output on the terminal:
Loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... i686-pc-linux-gnu
checking for arm-linux-gcc... (cached) arm-linux-gcc
checking for arm-linux-objcopy... (cached) arm-linux-objcopy
checking for arm-linux-ranlib... (cached) arm-linux-ranlib
checking for arm-linux-ar... (cached) arm-linux-ar
checking for gcc... (cached) arm-linux-gcc
checking whether the C compiler (arm-linux-gcc ) works... yes
checking whether the C compiler (arm-linux-gcc ) is a cross-compiler... yes
checking whether we are using GNU C... (cached) yes
checking whether arm-linux-gcc accepts -g... (cached) yes
checking for ranlib... (cached) arm-linux-ranlib
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... (cached) yes
checking target board... Delft University of Technology LART
checking if the Linux source tree in /usr/src/linux is sane... yes
checking for inline... (cached) inline
checking for C flags to get more warnings... -Wall
creating ./config.status
creating Makefile
creating doc/Makefile
creating include/Makefile
creating include/blob/Makefile
creating include/blob/arch/Makefile
creating src/Makefile
creating src/blob/Makefile
creating src/diag/Makefile
creating src/lib/Makefile
creating tools/Makefile
creating utils/Makefile
creating utils/build/Makefile
creating utils/mkparamblock/Makefile
creating include/blob/config.h
include/blob/config.h is
unchangedConfiguration------------------------------------------------------
------------------
Target board Delft University of Technology LART
C compiler arm-linux-gcc
C flags -Os -I/usr/src/linux/include -Wall -march=armv4
-mtune=strongarm1100 -fomit-frame-pointer
-fno-builtin -mapcs-32 -nostdinc
Linker flags -static -nostdlib
Objcopy tool arm-linux-objcopy
Objcopy flags -O binary -R .note -R .comment -S
Clock scaling support no
Memory test support no
Debugging commands support no
LCD support no
MD5 support no
Run-time debug information no
However, could someone please clarify as to why i get the following error,
when i run make:
Making all in docmake[1]: Entering directory
`/home/sridhar/blob-2.0.5-pre2/doc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/doc'
Making all in tools
make[1]: Entering directory `/home/sridhar/blob-2.0.5-pre2/tools'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/tools'
Making all in utils
make[1]: Entering directory `/home/sridhar/blob-2.0.5-pre2/utils'
Making all in buildmake[2]: Entering directory
`/home/sridhar/blob-2.0.5-pre2/utils/build'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/utils/build'
Making all in mkparamblock
make[2]: Entering directory
`/home/sridhar/blob-2.0.5-pre2/utils/mkparamblock'
gcc -Wall -O2 -I../../include -I../../include -o mkparamblock mkparamblock.c
make[2]: Leaving directory
`/home/sridhar/blob-2.0.5-pre2/utils/mkparamblock'
make[2]: Entering directory `/home/sridhar/blob-2.0.5-pre2/utils'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/utils'
make[1]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/utils'
Making all in include
make[1]: Entering directory `/home/sridhar/blob-2.0.5-pre2/include'
Making all in blobmake[2]:
Entering directory `/home/sridhar/blob-2.0.5-pre2/include/blob'
make all-recursivemake[3]: Entering directory
`/home/sridhar/blob-2.0.5-pre2/include/blob'
Making all in archmake[4]: Entering directory
`/home/sridhar/blob-2.0.5-pre2/include/blob/arch'
make[4]: Nothing to be done for `all'.make[4]:
Leaving directory `/home/sridhar/blob-2.0.5-pre2/include/blob/arch'
make[4]: Entering directory `/home/sridhar/blob-2.0.5-pre2/include/blob'
make[4]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/include/blob'
make[3]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/include/blob'
make[2]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/include/blob'
make[2]: Entering directory `/home/sridhar/blob-2.0.5-pre2/include'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/include'
make[1]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/include'
Making all in src
make[1]: Entering directory `/home/sridhar/blob-2.0.5-pre2/src'
Making all in lib
make[2]: Entering directory `/home/sridhar/blob-2.0.5-pre2/src/lib'
arm-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../../include/blob -I../../include
-I../../include -Os -I/usr/src/linux/include -Wall -march=armv4
-mtune=strongarm1100 -fomit-frame-pointer -fno-builtin -mapcs-32 -nostdinc
-c command.c
make[2]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/src/lib'
make[1]: Leaving directory `/home/sridhar/blob-2.0.5-pre2/src'
In file included from command.c:42:
../../include/blob/command.h:57: parse error before
`#'
../../include/blob/command.h:57: stray '\' in program
../../include/blob/command.h:58: stray '\' in program
../../include/blob/command.h:59: stray '\' in program
../../include/blob/command.h:60: stray '\' in program
In file included from command.c:42:
../../include/blob/init.h:46: parse error before `#'
../../include/blob/init.h:46: stray '\' in program
../../include/blob/init.h:47: stray '\' in program
../../include/blob/init.h:48: stray '\' in program
../../include/blob/init.h:55: parse error before `#'
../../include/blob/init.h:55: stray '\' in program
../../include/blob/init.h:56: stray '\' in program
../../include/blob/init.h:57: stray '\' in program
command.c:78: stray '\' in program
command.c:261: stray '\' in program
command.c:59: warning: `init_commands' defined but not
used
command.c:226: warning: `help' defined but not used
command.c:257: warning: `helphelp' defined but not
used
make[2]: *** [command.o] Error 1
make[2]: Leaving directory
`/root/blob_dsp8/blob-2.0.5-pre2/src/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/root/blob_dsp8/blob-2.0.5-pre2/src'
make: *** [all-recursive] Error 1
Is there anything wrong with the configuration process?
To me that seems to be OK as i got the expected output msg but im not sure.
Pls help me.
Thank You
Sridhar
-----Original Message-----
From: Christopher Hoover [mailto:ch...@mu...]
Sent: Monday, October 06, 2003 9:56 PM
To: Yamijala Sridhar
Cc: blo...@li...
Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs
> Well, could you pls tell me as to why blob needs the Linux kernel headers?
blob doesn't use the kernel headers ($LINUX/include/linux) per se, but it
does leverage the architecture-specific headers ($LINUX/include/asm) to get
to the defines and structures that describe the processor and peripherals.
-ch
-----Original Message-----
From: Yamijala Sridhar [mailto:Sri...@si...]
Sent: Monday, October 06, 2003 3:09 AM
To: Christopher Hoover
Cc: blo...@li...
Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs
Well, could you pls tell me as to why blob needs the Linux kernel headers?
I want to know because here, I have a configured Linux kernel source tree
without
the *.c files of the configured kernel.I have the *.h files though and all
the makefiles etc. too
with me.
When I try to configure and compile the blob with this kernel source tree
(without the *.c files)
the configuration seems to be successful but at the gmake stage i get an
error output which says
"Nothing to do for 'all' " and stops.
Could someone pls let me know what the problem is and why blob needs the
kernel headers?
Thank You
Sridhar
-----Original Message-----
From: Christopher Hoover [mailto:ch...@mu...]
Sent: Wednesday, October 01, 2003 9:39 PM
To: Yamijala Sridhar; blo...@li...
Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs
>> Hallo All !!!
>> Could someone pls clarify as to why the linux kernel
>> source path is required for compiling 'blob'?
>> I suppose the bootloader is a stand-alone program and
>> should not have anything to do
>> with the kernel source tree on my development machine
>> when im cross-compiling.
Blob (unfortunately) uses the kernel headers. You are correct that this is
not the best idea, not only for the reasons you mention but also because the
kernel headers change from time to time.
-ch
|
|
From: Christopher H. <ch...@mu...> - 2003-10-06 16:26:47
|
> Well, could you pls tell me as to why blob needs the Linux kernel = headers? blob doesn't use the kernel headers ($LINUX/include/linux) per se, but = it does leverage the architecture-specific headers ($LINUX/include/asm) to = get to the defines and structures that describe the processor and = peripherals. -ch =20 -----Original Message----- From: Yamijala Sridhar [mailto:Sri...@si...]=20 Sent: Monday, October 06, 2003 3:09 AM To: Christopher Hoover Cc: blo...@li... Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs Well, could you pls tell me as to why blob needs the Linux kernel = headers?=20 I want to know because here, I have a configured Linux kernel source = tree without=20 the *.c files of the configured kernel.I have the *.h files though and = all the makefiles etc. too=20 with me.=20 When I try to configure and compile the blob with this kernel source = tree (without the *.c files)=20 the configuration seems to be successful but at the gmake stage i get an error output which says=20 "Nothing to do for 'all' " and stops.=20 Could someone pls let me know what the problem is and why blob needs the kernel headers?=20 Thank You=20 Sridhar=20 -----Original Message-----=20 From: Christopher Hoover [mailto:ch...@mu...]=20 Sent: Wednesday, October 01, 2003 9:39 PM=20 To: Yamijala Sridhar; blo...@li...=20 Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs=20 >> Hallo All !!!=20 >> Could someone pls clarify as to why the linux kernel=20 >> source path is required for compiling 'blob'?=20 >> I suppose the bootloader is a stand-alone program and=20 >> should not have anything to do=20 >> with the kernel source tree on my development machine=20 >> when im cross-compiling.=20 Blob (unfortunately) uses the kernel headers. You are correct that this = is=20 not the best idea, not only for the reasons you mention but also because = the kernel headers change from time to time.=20 -ch=20 |
|
From: Yamijala S. <Sri...@si...> - 2003-10-06 11:11:10
|
Well, could you pls tell me as to why blob needs the Linux kernel headers? I want to know because here, I have a configured Linux kernel source tree without the *.c files of the configured kernel.I have the *.h files though and all the makefiles etc. too with me. When I try to configure and compile the blob with this kernel source tree (without the *.c files) the configuration seems to be successful but at the gmake stage i get an error output which says "Nothing to do for 'all' " and stops. Could someone pls let me know what the problem is and why blob needs the kernel headers? Thank You Sridhar -----Original Message----- From: Christopher Hoover [mailto:ch...@mu...] Sent: Wednesday, October 01, 2003 9:39 PM To: Yamijala Sridhar; blo...@li... Subject: RE: blob-cvs-commit digest, Vol 1 #232 - 2 msgs >> Hallo All !!! >> Could someone pls clarify as to why the linux kernel >> source path is required for compiling 'blob'? >> I suppose the bootloader is a stand-alone program and >> should not have anything to do >> with the kernel source tree on my development machine >> when im cross-compiling. Blob (unfortunately) uses the kernel headers. You are correct that this is not the best idea, not only for the reasons you mention but also because the kernel headers change from time to time. -ch |
|
From: Christopher H. <ch...@mu...> - 2003-10-06 07:03:38
|
> Hi Christopher, Russ, list, > > I received this from Intel about a month ago. Sadly I am not familiar > enough with the blob sources anymore (nor do I have access to a > Lubbock), and although I have prodded Erik a few times it looks like > he hasn't integrated these patches yet either. > > If there is anything I can do to to help with the release do let me > know. Although the days that most of the blob code was mine are long > gone, I'd very much like to do my bit to keep blob up & running. I can't Lubbock hardware, so I'd prefer somone who has the hardware do the merge. But if no one with commit privs and hardware steps us, I'll do it. -ch |
|
From: J.D. B. <ba...@th...> - 2003-10-02 23:09:37
|
Hi Christopher, Russ, list, I received this from Intel about a month ago. Sadly I am not familiar enough with the blob sources anymore (nor do I have access to a Lubbock), and although I have prodded Erik a few times it looks like he hasn't integrated these patches yet either. If there is anything I can do to to help with the release do let me know. Although the days that most of the blob code was mine are long gone, I'd very much like to do my bit to keep blob up & running. JDB >Subject: Blob patches for Intel Lubbock >Date: Tue, 9 Sep 2003 18:10:30 +0800 >Thread-Topic: Blob patches for Intel Lubbock >Thread-Index: AcN2upIR8f/7mlmkTXeDQcQRUtnjyA== >From: "Tang, Yu" <yu...@in...> >To: <J.D...@it...>, <J.A...@it...> >Cc: "Geldmacher, Russell" <rus...@in...>, > "Tang, Yu" <yu...@in...> >X-OriginalArrivalTime: 09 Sep 2003 10:10:38.0549 (UTC) >FILETIME=[9E216850:01C376BA] > >Hi Eric/Jan-Derk, > >I am a software engineer from Intel; As you may know, Rusty >Geldmacher (rus...@in...) was working BLOB for >Intel Lubbock platform for a while before, and I am the replacement >of him on this position now. > >We ported Blob-2.0.5-pre2 to Intel Lubbock platform, which is now >available at >ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/xscale/lubbock/blob/ >for several months. We think it's time to put our efforts back to >Blob CVS tree, and your kind help will be critical for us. > >In order to simplify the process, I separated the codes into several >small patches ( against CVS code Sep.7, 2003). > >* blob-lubbock.patch > >It adds Intel Lubbock platform support to BLOB. > >As there is a SMC91c96 Ethernet controller on Lubbock, and the SMC >driver existed in BLOB seems to be specific for system3/dafit. To >solve this issue, we adds SMC_BASE macro, thus "system3"/"dafit" are >impacted. > > Changed files > - configure.in > - src/blob/lubbock.c > - src/lib/ether-smc9196.c > - include/blob/arch/lubbock.h > - include/blob/arch/dafit.h > - include/blob/arch/system3.h > >* blob-tftp-fix.patch > >two fixes in the patch, >- fixed to stop tftp when error received. >- fixed to handle image size >= 32M. > >* blob-pxa-usb.patch > >It adds "usb-eth" support to PXA-based platforms. The USB driver is >ported from Linux kernel, with modifications to make it suitable for >BLOB. This patch intends to fast downloading speed for the PXA-based >platforms which have USB client interface but don't have Ethernet >controller. > > Changed files: > - include/net/ether.h > New files: > - src/lib/pxa_usb.h > - src/lib/pxa_usb_ctl.c > - src/lib/pxa_usb_ctl.h > - src/lib/pxa_usb_ep0.c > - src/lib/pxa_usb_ep0.h > - src/lib/pxa_usb_ep1.c > - src/lib/pxa_usb_ep2.c > - src/lib/ether-pxausb.c > >I put some *.h files in src/lib, as I can't find the right place to put them. > > >All these patches are tested on Lubbock with Cotulla(x32) daughter card. > >It will be glad to hear from you soon. Any ideas are appreciated. >Thanks in advance. > >Regards, > >Tang, Yu > > > > >Content-Type: application/octet-stream; > name="blob-lubbock.patch" >Content-Description: blob-lubbock.patch >Content-Disposition: attachment; > filename="blob-lubbock.patch" > > >Content-Type: application/octet-stream; > name="blob-tftp-fix.patch" >Content-Description: blob-tftp-fix.patch >Content-Disposition: attachment; > filename="blob-tftp-fix.patch" > >Content-Type: application/octet-stream; > name="blob-pxa-usb.patch" >Content-Description: blob-pxa-usb.patch >Content-Disposition: attachment; > filename="blob-pxa-usb.patch" > -- Jan-Derk Bakker, ba...@mm... The lazy man's proverb: 'There's no business like slow business !' |
|
From: Marc S. <el...@bu...> - 2003-10-02 19:43:43
|
So, are you saying that the code for the Sharp boards got integrated already? If so, I'd really appreciate a snapshot from CVS. On Thu, Oct 02, 2003 at 03:16:21PM -0400, Brad Parker wrote: > > Hi > > I made some changes to the blob+lineo code for my A400 board and got > disgusted and did some refactoring of their code (mostly to look the > 4,000,000 #ifdef's they put everywhere). > > Then, while working on an xscale project I noticed the latest blob cvs > seems to have done a lot of this refactoring already and integrated some > new cpu's cleanly. > > So I add "put your changes into the newest blob cvs" to my to-do list and > promptly started ignoring it :-) > > My biggest beef with the lineo code is the use of "LH7A400" when they > really ment KEV7A400 and "LH79520" when they really ment KEV79520. > i.e. mixing the notion of the cpu with the board instantiation as if there > would only ever be one A400 board in the world. A common mistake. The uboot code is much much worse. > > So if some/any/all of the lineo code gets put in, please define the > Sharp eval boards as KEV7A400 and KEV79520 like this snipped below > (from configure) > > ... > cat >> confdefs.h <<\EOF > #define LH79520 1 > EOF > > BLOB_PLATFORM_OBJ="kev79520.o" > BLOB_FLASH_OBJS="sharp_lh28f320.o" > use_cpu="lh79520" > ... > > that way we can have multiple boards which use the same cpu and not all > pull our hair out. > > I sure you know all this, and sorry for the rant - I had some pent up > frustration I needed to release :-) I've been very restrained about criticizing those who came before me. Their code has always been welcome as it lightens my burden. Yet, I too have found the Lineo work wanting > > [and having said that, I'm happy to build and test blob for the KEV79520 > and KEV7A400 since I have one of each right now, as well as my own A400 > board] Good to know. I rewrote the memory initialization code once already. I'll do so again as soon as I can get something running on the KEV7A400. |
|
From: Brad P. <br...@he...> - 2003-10-02 19:16:28
|
Hi I made some changes to the blob+lineo code for my A400 board and got disgusted and did some refactoring of their code (mostly to look the 4,000,000 #ifdef's they put everywhere). Then, while working on an xscale project I noticed the latest blob cvs seems to have done a lot of this refactoring already and integrated some new cpu's cleanly. So I add "put your changes into the newest blob cvs" to my to-do list and promptly started ignoring it :-) My biggest beef with the lineo code is the use of "LH7A400" when they really ment KEV7A400 and "LH79520" when they really ment KEV79520. i.e. mixing the notion of the cpu with the board instantiation as if there would only ever be one A400 board in the world. So if some/any/all of the lineo code gets put in, please define the Sharp eval boards as KEV7A400 and KEV79520 like this snipped below (from configure) ... cat >> confdefs.h <<\EOF #define LH79520 1 EOF BLOB_PLATFORM_OBJ="kev79520.o" BLOB_FLASH_OBJS="sharp_lh28f320.o" use_cpu="lh79520" ... that way we can have multiple boards which use the same cpu and not all pull our hair out. I sure you know all this, and sorry for the rant - I had some pent up frustration I needed to release :-) [and having said that, I'm happy to build and test blob for the KEV79520 and KEV7A400 since I have one of each right now, as well as my own A400 board] -brad Marc Singer wrote: >I think that 'clean' is part of the problem. I'm working with the >Lineo patches for the Sharp ARM SoC's. Have you seen their work? I'm >making some changes so that their code works properly with another >implementation of the Sharp CPU. > >I'll post something when I've got it working. > >On Thu, Oct 02, 2003 at 10:06:31AM -0700, Christopher Hoover wrote: >> >> > Also, I'm looking at the state of blob wrt there being no >> > maintainer. I have patches, too, that need to be integrated.n >> >> Send the patches (in clean, concise pieces, i.e., standard patch submission >> technique) to blo...@li.... >> >> One of us with write access to cvs will apply them, if they are acceptable. >> >> -ch >-- >To unsubscribe from this list: send the line "unsubscribe lart" in >the body of a message to maj...@la... >Please read the LART FAQ at http://www.lart.tudelft.nl/faq.php3 > |
|
From: Marc S. <el...@bu...> - 2003-10-02 17:35:49
|
I think that 'clean' is part of the problem. I'm working with the Lineo patches for the Sharp ARM SoC's. Have you seen their work? I'm making some changes so that their code works properly with another implementation of the Sharp CPU. I'll post something when I've got it working. On Thu, Oct 02, 2003 at 10:06:31AM -0700, Christopher Hoover wrote: > > > Also, I'm looking at the state of blob wrt there being no > > maintainer. I have patches, too, that need to be integrated.n > > Send the patches (in clean, concise pieces, i.e., standard patch submission > technique) to blo...@li.... > > One of us with write access to cvs will apply them, if they are acceptable. > > -ch |
|
From: Christopher H. <ch...@mu...> - 2003-10-02 17:07:41
|
> Also, I'm looking at the state of blob wrt there being no > maintainer. I have patches, too, that need to be integrated.n Send the patches (in clean, concise pieces, i.e., standard patch submission technique) to blo...@li.... One of us with write access to cvs will apply them, if they are acceptable. -ch |
|
From: Nicolas P. <ni...@ca...> - 2003-10-01 16:58:42
|
On Wed, 1 Oct 2003, Christopher Hoover wrote: > > > That looks like BLOB is seriously lacking a maintainer to me. > > It is under fairly active maintenance, but we're certainly lacking a release > engineer. > > Are you volunteering? :-) No! ;-) Nicolas |
|
From: Christopher H. <ch...@mu...> - 2003-10-01 16:49:17
|
> That looks like BLOB is seriously lacking a maintainer to me. It is under fairly active maintenance, but we're certainly lacking a = release engineer. =20 Are you volunteering? :-) -ch |
|
From: Christopher H. <ch...@mu...> - 2003-10-01 16:10:02
|
>> Hallo All !!!=20 >> Could someone pls clarify as to why the linux kernel=20 >> source path is required for compiling 'blob'?=20 >> I suppose the bootloader is a stand-alone program and >> should not have anything to do=20 >> with the kernel source tree on my development machine >> when im cross-compiling.=20 Blob (unfortunately) uses the kernel headers. You are correct that this = is not the best idea, not only for the reasons you mention but also because = the kernel headers change from time to time. -ch |
|
From: Yamijala S. <Sri...@si...> - 2003-10-01 10:38:45
|
Hallo All !!! Could someone pls clarify as to why the linux kernel source path is required for compiling 'blob'? I suppose the bootloader is a stand-alone program and should not have anything to do with the kernel source tree on my development machine when im cross-compiling. Pls help me by clarifying my doubt. Thank You Sridhar -----Original Message----- From: blo...@li... [mailto:blo...@li...] Sent: Tuesday, September 30, 2003 8:33 AM To: blo...@li... Subject: blob-cvs-commit digest, Vol 1 #232 - 2 msgs Send blob-cvs-commit mailing list submissions to blo...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/blob-cvs-commit or, via email, send a message with subject or body 'help' to blo...@li... You can reach the person managing the list at blo...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of blob-cvs-commit digest..." Today's Topics: 1. cross-compiling blob for LART from i386 (Yamijala Sridhar) 2. Re: cross-compiling blob for LART from i386 (Holger Schurig) --__--__-- Message: 1 From: Yamijala Sridhar <Sri...@si...> To: blo...@li... Subject: cross-compiling blob for LART from i386 Date: Mon, 29 Sep 2003 15:29:16 +0530 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38670.579927E0 Content-Type: text/plain; charset="iso-8859-1" Hallo All ! May be this is a simple doubt but I would be glad to someone could help me. I read the "porting.txt" file that comes with blob but the instructions therein didnt help me completely. I tried the instructons in README file too but even then I wasnt successful.May be Im missing something vital. Could someone please help. First of all,I would like to know whether the source path mentioned in blob instructions is blob source path or the linux kernel source path?I have a feeling that kernel source path need not be required but i dont know.And, if in case it is kernel source path, is it the host x86 Linux source path or the SA-1110 Linux kernel source path?Could someone please clarify. And can someone please give me a step-by-step guidelines to do this. My environment is as below: Im cross-compiling blob on a host x86 machine for SA-1110/Linux(ARM), LART. My blob folder path is: home/sridhar/blob-2.0.5-pre2 with all subfolders and files in it. I followed the instructions in "porting.txt" but seem to falter after that. What do i do from here? Thanks in Advance Sridhar ------_=_NextPart_001_01C38670.579927E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2653.12"> <TITLE>cross-compiling blob for LART from i386</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>Hallo All !</FONT> </P> <P><FONT SIZE=3D2>May be this is a simple doubt but I would be glad to = someone could help me.</FONT> <BR><FONT SIZE=3D2>I read the "porting.txt" file that comes = with blob but the instructions therein didnt help me completely.</FONT> <BR><FONT SIZE=3D2>I tried the instructons in README file too but even = then I wasnt successful.May be Im missing something vital.</FONT> <BR><FONT SIZE=3D2>Could someone please help.</FONT> </P> <P><FONT SIZE=3D2>First of all,I would like to know whether the source = path mentioned in blob instructions </FONT> <BR><FONT SIZE=3D2>is blob source path or the linux kernel source = path?I have a feeling that kernel source path</FONT> <BR><FONT SIZE=3D2>need not be required but i dont know.And, if in case = it is kernel source path, is it the host x86 Linux source path</FONT> <BR><FONT SIZE=3D2>or the SA-1110 Linux kernel source path?Could = someone please clarify.</FONT> </P> <P><FONT SIZE=3D2>And can someone please give me a step-by-step = guidelines to do this.</FONT> <BR><FONT SIZE=3D2>My environment is as below:</FONT> </P> <P><FONT SIZE=3D2>Im cross-compiling blob on a host x86 machine for = SA-1110/Linux(ARM), LART.</FONT> <BR><FONT SIZE=3D2>My blob folder path is: home/sridhar/blob-2.0.5-pre2 = with all subfolders and files in it.</FONT> <BR><FONT SIZE=3D2>I followed the instructions in = "porting.txt" but seem to falter after that.</FONT> </P> <P><FONT SIZE=3D2>What do i do from here?</FONT> </P> <P><FONT SIZE=3D2>Thanks in Advance</FONT> <BR><FONT SIZE=3D2>Sridhar</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C38670.579927E0-- --__--__-- Message: 2 From: Holger Schurig <h.s...@mn...> To: blo...@li... Subject: Re: cross-compiling blob for LART from i386 Date: Mon, 29 Sep 2003 15:20:51 +0200 > need not be required but i dont know.And, if in case it is kernel > source path, is it the host x86 Linux source path > or the SA-1110 Linux kernel source path? The source path to the SA1110/PXA Linux kernel. It must be a kernel that already compiled successfully, so that include/asm and include/asm/arch point to the rigth directories. --__--__-- _______________________________________________ blob-cvs-commit mailing list blo...@li... https://lists.sourceforge.net/lists/listinfo/blob-cvs-commit End of blob-cvs-commit Digest |
|
From: Holger S. <h.s...@mn...> - 2003-09-29 13:41:53
|
> need not be required but i dont know.And, if in case it is kernel > source path, is it the host x86 Linux source path > or the SA-1110 Linux kernel source path? The source path to the SA1110/PXA Linux kernel. It must be a kernel that already compiled successfully, so that include/asm and include/asm/arch point to the rigth directories. |
|
From: Yamijala S. <Sri...@si...> - 2003-09-29 10:03:33
|
Hallo All ! May be this is a simple doubt but I would be glad to someone could help me. I read the "porting.txt" file that comes with blob but the instructions therein didnt help me completely. I tried the instructons in README file too but even then I wasnt successful.May be Im missing something vital. Could someone please help. First of all,I would like to know whether the source path mentioned in blob instructions is blob source path or the linux kernel source path?I have a feeling that kernel source path need not be required but i dont know.And, if in case it is kernel source path, is it the host x86 Linux source path or the SA-1110 Linux kernel source path?Could someone please clarify. And can someone please give me a step-by-step guidelines to do this. My environment is as below: Im cross-compiling blob on a host x86 machine for SA-1110/Linux(ARM), LART. My blob folder path is: home/sridhar/blob-2.0.5-pre2 with all subfolders and files in it. I followed the instructions in "porting.txt" but seem to falter after that. What do i do from here? Thanks in Advance Sridhar |
|
From: Yamijala S. <Sri...@si...> - 2003-09-15 10:35:48
|
Thank you very much Stefan.You gave me precisely the clarification i needed. Regards Sridhar Message: 4 Date: Fri, 12 Sep 2003 15:09:18 +0200 From: ste...@el... To: blo...@li... Subject: Re: blob...arch specific files Reply-To: ste...@el... Organization: Eletztrick Computing On Thu, Sep 11, 2003 at 10:32:59AM +0530, Yamijala Sridhar wrote: > Thanks Stefan and Russ...the board is SA-1110 based but how do i know which > type it is: > i.e., how do i know whether it is "Assabet" / "Neponset" / "h3600" / > "creditlart" / "system3" or any other type? > Sorry for the confusion.I need another clarification.On what basis are the > declarations for the > various addresses and lengths in <include/blob/arch/arch.h> made ? > Could anyone pls guide me. Ok. "assabet", "neponset" .... are all specific boards which use the SA1110 processor. But these boards are all quite different. They use for ex. different SDRAM chips, different board glue logic, some have additional peripheral hardware built in (Compact Flash, LCD panels, etc). BLOBs part in booting linux are: - set up memory correctly - find a way to load the kernel image to RAM, and do that - find a way to load a initial ramdisk to memory - set up a structure in RAM to tell the kernel what BLOB found out so far - finally, start the linux kernel by jumping to a specific address in memory. Almost all of the above steps require _exact_ knowledge of the specific hardware BLOB runs on (not only the processor, but also how SDRAM is wired etc.). That's why BLOB supports different "boards". A "board" in this context means: - processor type info - memory setup info - serial port setup info - kernel info (where to load from, where to put into RAM) - flash type and setup info - other hardware info So, to be able to use BLOB on your "board", you'll have to first get the above information, understand it, and then try to teach BLOB to recognize your "board". Thats what blob/doc/proting.txt is for. You'll definitely need the schematics and all other hardware information of your board you can get. Then compare what you have with other board setups, and choose the one which matches most (porobably assabet, thats the INTEL reference implementation, or Lart or HackKit, they're rather simple), copy the parts and hack support for your board in. Hope this helps, Stefan -- Eletztrick Computing - Customized Linux Development Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg http://www.eletztrick.de |
|
From: <ste...@el...> - 2003-09-12 13:09:33
|
On Thu, Sep 11, 2003 at 10:32:59AM +0530, Yamijala Sridhar wrote: > Thanks Stefan and Russ...the board is SA-1110 based but how do i know which > type it is: > i.e., how do i know whether it is "Assabet" / "Neponset" / "h3600" / > "creditlart" / "system3" or any other type? > Sorry for the confusion.I need another clarification.On what basis are the > declarations for the > various addresses and lengths in <include/blob/arch/arch.h> made ? > Could anyone pls guide me. Ok. "assabet", "neponset" .... are all specific boards which use the SA1110 processor. But these boards are all quite different. They use for ex. different SDRAM chips, different board glue logic, some have additional peripheral hardware built in (Compact Flash, LCD panels, etc). BLOBs part in booting linux are: - set up memory correctly - find a way to load the kernel image to RAM, and do that - find a way to load a initial ramdisk to memory - set up a structure in RAM to tell the kernel what BLOB found out so far - finally, start the linux kernel by jumping to a specific address in memory. Almost all of the above steps require _exact_ knowledge of the specific hardware BLOB runs on (not only the processor, but also how SDRAM is wired etc.). That's why BLOB supports different "boards". A "board" in this context means: - processor type info - memory setup info - serial port setup info - kernel info (where to load from, where to put into RAM) - flash type and setup info - other hardware info So, to be able to use BLOB on your "board", you'll have to first get the above information, understand it, and then try to teach BLOB to recognize your "board". Thats what blob/doc/proting.txt is for. You'll definitely need the schematics and all other hardware information of your board you can get. Then compare what you have with other board setups, and choose the one which matches most (porobably assabet, thats the INTEL reference implementation, or Lart or HackKit, they're rather simple), copy the parts and hack support for your board in. Hope this helps, Stefan > > Sridhar -- Eletztrick Computing - Customized Linux Development Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg http://www.eletztrick.de |
|
From: Yamijala S. <Sri...@si...> - 2003-09-12 08:31:04
|
Well, I just thought it would be better because Im a beginner and sometimes my problems and the doubts therefore may not really be relevant/useful to the blob forum although i must admit i dont know which problem is closely related with blob and which is not. -----Original Message----- From: Russ Dill [mailto:Rus...@as...] Sent: Friday, September 12, 2003 1:04 PM To: Yamijala Sridhar Cc: blo...@li... Subject: RE: blob...arch specific files On Thu, 2003-09-11 at 23:53, Yamijala Sridhar wrote: > Thank You Russ.Pls find attached the schematic with this mail. > Hope it give some info.And, could you pls let me know whether i can > have a one-one correspondence with you and not just through > blob-cvs-commit? that *definately* isn't a lart. and it *definately* isn't a schematic. Anyway, ask your vendor for more info. If there is no blob port, you may need actual schematics. why do you want a one on one correspondence? -- Russ Dill <Rus...@as...> |
704 messages has been excluded from this view by a project administrator.
