From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19624 invoked by alias); 12 Jul 2007 21:37:34 -0000 Received: (qmail 19614 invoked by uid 22791); 12 Jul 2007 21:37:33 -0000 X-Spam-Check-By: sourceware.org Received: from stelecom.gomel.by (HELO stelecom.gomel.by) (82.209.213.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Jul 2007 21:37:30 +0000 Received: from localhost (localhost [127.0.0.1]) by stelecom.gomel.by (Postfix) with ESMTP id 8A399B01D864; Fri, 13 Jul 2007 00:37:26 +0300 (EEST) Received: from stelecom.gomel.by ([127.0.0.1]) by localhost (stelecom.gomel.by [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05677-12; Fri, 13 Jul 2007 00:37:25 +0300 (EEST) Received: from localhost (unknown [82.209.208.34]) by stelecom.gomel.by (Postfix) with ESMTP id D4D8BB019115; Fri, 13 Jul 2007 00:37:23 +0300 (EEST) Date: Thu, 12 Jul 2007 21:37:00 -0000 From: Sergei Gavrikov To: Tales Toledo Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20070712213621.GA29303@ubuntu> References: <20070706191055.GA10570@ubuntu> <2308fb0f0707061237k630fdea4y7e3c148aa213f16c@mail.gmail.com> <20070706211314.GA12393@ubuntu> <2308fb0f0707090845i122a5131v7a307e3969b79ed7@mail.gmail.com> <20070709172751.GA10396@ubuntu> <2308fb0f0707091211w2c6b0fb0xc1f4354e0eda9b65@mail.gmail.com> <20070709214653.GA16045@ubuntu> <2308fb0f0707101223k78efbaa0t1a809824859be2b5@mail.gmail.com> <20070710220328.GA22048@ubuntu> <2308fb0f0707121400o287710d0o584194bab30c6d0d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2308fb0f0707121400o287710d0o584194bab30c6d0d@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] How to enable diag_printf at Redboot X-SW-Source: 2007-07/txt/msg00111.txt.bz2 On Thu, Jul 12, 2007 at 06:00:33PM -0300, Tales Toledo wrote: > On 7/10/07, Sergei Gavrikov wrote: > >Execuse me a double post, I have a doubts about e-mail delivery. > > > >On Tue, Jul 10, 2007 at 04:23:59PM -0300, Tales Toledo wrote: > >> On 7/9/07, Sergei Gavrikov wrote: > >> >I again did review your previous RedBoot dumps. You known/sure that is > >> >1) RAM copy of `fconfig' is correct, 2) Written flash copy of `fconfig' > >> >seems or is correct too, there are a valid human readable chunks at the > >> >least, > >> > >> Just checking ... 1) and 2) Ok. You can see as follow > >> RedBoot> fconfig -i > >> Initialize non-volatile configuration - continue (y/n)? y > >> Run script at boot: false > >> Use BOOTP for network configuration: false > >> Gateway IP address: 192.168.1.1 > >> Local IP address: 192.168.1.100 > >> Local IP address mask: 255.255.255.0 > >> Default server IP address: 192.168.1.1 > >> DNS domain name: > >> DNS server IP address: 192.168.1.1 > >> Network hardware address [MAC]: 0x7C:0x71:0x43:0xA6:0x7C:0x92 > >> GDB connection port: 9000 > >> Force console for special debug messages: false > >> Network debug at boot time: false > >> Update RedBoot non-volatile configuration - continue (y/n)? y > >> ... Erase from 0x407d0000-0x407d1000: . > >> ... Program from 0x01fe3000-0x01fe4000 at 0x407d0000: . > >> RedBoot> ck > >> RedBoot> cksum > >> usage: cksum -b -l > >> RedBoot> cksum -b 0x01fe3000 -l 0x1000 > >> POSIX cksum = 2836439824 4096 (0xa910a310 0x00001000) > >> RedBoot> cksum -b 0x407d0000 -l 0x1000 > >> POSIX cksum = 2836439824 4096 (0xa910a310 0x00001000) > >> RedBoot> > >> > >> >3) you don't see the BAD magic values in your dumps (0x0BADFACE > >> >or 0xDEADDEAD). > >> > >> RedBoot> dump -b 0x407d0000 -l 0x1000 > >> 407D0000: 00 00 10 00 0B AD FA CE 01 0C 01 00 62 6F 6F 74 > >> |............boot| > >> 407D0010: 5F 73 63 72 69 70 74 00 00 00 00 00 04 11 01 0C > >> |_script.........| > >> 407D0020: 62 6F 6F 74 5F 73 63 72 69 70 74 5F 64 61 74 61 > >> |boot_script_data| > >> 407D0030: 00 62 6F 6F 74 5F 73 63 72 69 70 74 00 00 00 00 > >> |.boot_script....| > >> > >> I can see 0x0BADFACE... I miss this point, what is wrong with that? > > > >It seems I thought itself :-), you have to see both those keys, because > >the RedBoot config is (flash_config.h) > > > >struct _config { > > unsigned long len; > > unsigned long key1; > > unsigned char config_data[MAX_CONFIG_DATA-(4*4)]; > > unsigned long key2; > > unsigned long cksum; > >}; > > > >I did try to say what that point checks just 3 things: CRC, KEY1 > >(0x0BADFACE) and KEY2 (0xDEADDEAD): > > > > if ((flash_crc(config) != config->cksum) || > > (config->key1 != CONFIG_KEY1)|| (config->key2 != CONFIG_KEY2)) { > > diag_printf("**Warning** FLASH configuration checksum error or > > invalid key\n"); > > diag_printf("Use 'fconfig -i' to [re]initialize database\n"); > > config_init(); > > return; > > } > > > > This is my printf result just before the if test > config->key1 = 0xbadface, config->key2 = 0xffffffff, config->cksum = > 0xffffffff, flash_crc = 0x706de31e > > As you see I don't get config->key2 and config->cksum with the right values. > > >Check what that KEY2/CRC is present at the end of 4K area. > > I can't find it. I don´t have any KEY2 at 4K area. > > >You believe that CRC is okay. So, this is the last point. Try to > build a minimalist > >RedBoot, i.e. which supports serial and Flash devices only. That > >reduces a size of RedBoot and rebuild-time. That will be to have a few > >config options. I wonder it's possible 'fconfig' issue won't be occur... > >So, try to remove NET stuff from RedBoot: > > After investigate more and more I think I have a problem with sectors > configuration in flash. I read am29xxxxx_parts.inl and the support for > the part number I have in my board (S29GL064MR3) doesn't look fine. > The sectors seems to be wrong since it is just TOP boot and not > top/bottom as described there. I will try to do some changes tomorrow. I had a thought about top/bottom issue, but, you told what you have a standard target... I think, it will be it. Well, you should fix a parts description according datasheet. I have yet another mad idea: try to use _positive_ number for the CYGNUM_REDBOOT_FLASH_CONFIG_BLOCK option, i.e. try to swap flash config holder: # Which block of flash to use # Which block of flash should hold the configuration # information. Positive numbers are absolute block numbers. # Negative block numbers count backwards from the last block. # eg 2 means block 2, -2 means the last but one block. # cdl_option CYGNUM_REDBOOT_FLASH_CONFIG_BLOCK { ... I wonder what the values: KEY1, KEY2, CRC you will get? It seems this won't be a right way to fix a problem, but who knows. Sergei -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss