Re: [Elphel-support] 353 Problem Mainboards

2019-11-26 Thread Linden @ Zone4
Looks like a cabling issue on my end. Waiting on parts before I can proceed.

Linden Mills-Connery


On Mon, 18 Nov 2019 at 15:33, Linden @ Zone4  wrote:

> Think I am having an issue setting up minicom. Have a working camera
> running attached to through the serial interface. I have a /dev/ttyUSB0
> that registered when the USB to serial is plugged in so good up to that
> point. Have minicom setup as follows:
> Bps/Par/Bits: 115200 8N1
> Hardware Flow Control: No
> Software Flow Control: No
>
> Then I assume I just start minicom and it should start printing output to
> the screen or is there some step I am missing?
>
> Thanks,
>
> Linden
>
> On Tue, 1 Oct 2019 at 11:17, Oleg  wrote:
>
>> Hi Linden,
>>
>> Follow up. Were you able to get the serial output?
>>
>> Regards,
>> Oleg
>>
>> On Tue, Sep 10, 2019 at 5:29 PM Oleg 
>> wrote:
>>
>>> Link to the image of parts 1 & 2
>>> 
>>>
>>> On Tue, Sep 10, 2019 at 5:25 PM Oleg 
>>> wrote:
>>>
 Hi Linden,

 You need a program like minicom to display a serial port output.
 The speed settings for the serial port are 115200 8N1
 .
 And the device is normally: /dev/ttyUSB0

 Do you have the cable?

 It consists of 3 parts: parts 1 & 2, part 3
 ):
 parts 1&2:

> RS-232 Adapter/Cable is used to connect to the serial port of
> NC353L-369 cameras. This port outputs all the boot and debug messages and
> provides system console that can be used for software development - this
> console allows to control the camera even if the network is misconfigured.
> This kit consists of 2 parts: 0353-01-04 - DB9 to modular adapter with
> custom wiring and a
> 0353-01-05 - 6-wire modular cable with crossover wiring (6-wire
> modular telephone cable)

 part3:

> USB to RS-232 converter cable - an addition to RS-232 Adapter/Cable
> that allows to use a host PC's USB port instead of RS232.


 Regards,
 Oleg

 On Tue, Sep 10, 2019 at 5:01 PM Linden @ Zone4  wrote:

> Hi Oleg,
>
> I have another camera with issues booting that I would like to
> diagnose. Discovered I have a 10369 board can you pass along some
> instructions and I will see if it has a bad block.
>
> Thanks,
>
> Linden Mills-Connery
> Zone4 Team 
> 205-820 Main Street
> Canmore, AB, T1W2B7
> 403-401-7215
>
>
> On Tue, 28 Aug 2018 at 16:19, Oleg 
> wrote:
>
>> Linden,
>>
>> I reflashed the 000E64081CA1 - and it works now.
>>
>> It had a bad block. See the old bootlog from the serial output (via
>> the extension board 10369) below.
>>
>> Have you ever reflashed a camera? One of the tests that can tell if
>> the flash is probably corrupted is putting the camera in the netboot 
>> mode.
>> Then reflash if possible - during reflashing it detects and skips the bad
>> blocks.
>>
>> Boot log:
>>
>>> ETRAX FS NAND boot loader
>>>
>>>
>>>
>>> =
>>>
>>>
>>>
>>> Rev 1, Nov 23 2009 12:31:43
>>>
>>>
>>>
>>> Boot config: 0x0004->0x4044, len 0x0020, boot @
>>> 0x4044
>>>
>>>
>>> CPU revision: 0x0020
>>>
>>>
>>>
>>> Bootloader main at 0x38000ce2
>>>
>>>
>>>
>>> Data end: 0x3800573c
>>>
>>>
>>>
>>> Bss: 0x38008000
>>>
>>>
>>>
>>> Heap: 0x38008000
>>>
>>>
>>>
>>> Identifying nand chip...
>>>
>>>
>>>
>>> maf_id: 0x002c; dev_id: 0x00f1
>>>
>>>
>>>
>>> mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt(); mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...01; mtd->size == 0x0800
>>>
>>>
>>>
>>> len == 0x0100; and BBT_LEN_1 == 0x0400
>>>
>>>
>>>
>>> scan_bbt() ...02; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...03; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...1; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...2; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() search_read_bbts(); mtd->size == 0x0800
>>>
>>>
>>>
>>> search_read_bbts() search primary table; mtd->size == 0x0800
>>>
>>>
>>>
>>> search_bbt() ...1; mtd->size == 0x0800
>>>
>>>
>>>
>>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>>
>>>
>>>
>>> Block: 0x03ff
>>>
>>>
>>>
>>> Check, if we found a bbt for each requested chip
>>>
>>>
>>>
>>> Bad block table found at 

Re: [Elphel-support] 353 Problem Mainboards

2019-11-21 Thread Elphel Support List
Linden,

> I have a /dev/ttyUSB0
> that registered when the USB to serial is plugged in so good up to that
> point. Have minicom setup as follows:
> Bps/Par/Bits: 115200 8N1
> Hardware Flow Control: No
> Software Flow Control: No

Looks correct.

> Then I assume I just start minicom and it should start printing output to
> the screen or is there some step I am missing?

Yes. 
1. power on the camera
2. ~$ sudo minicom -c on
3a. Hit Enter - it should print "#", or type "dmesg". 
3b. If it's not doing anything - w/o terminating minicom powercycle the camera. 
And it should be printing.

If it's not responsive - I would check the cable.

Regards,
Oleg

___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2019-11-18 Thread Linden @ Zone4
Think I am having an issue setting up minicom. Have a working camera
running attached to through the serial interface. I have a /dev/ttyUSB0
that registered when the USB to serial is plugged in so good up to that
point. Have minicom setup as follows:
Bps/Par/Bits: 115200 8N1
Hardware Flow Control: No
Software Flow Control: No

Then I assume I just start minicom and it should start printing output to
the screen or is there some step I am missing?

Thanks,

Linden

On Tue, 1 Oct 2019 at 11:17, Oleg  wrote:

> Hi Linden,
>
> Follow up. Were you able to get the serial output?
>
> Regards,
> Oleg
>
> On Tue, Sep 10, 2019 at 5:29 PM Oleg 
> wrote:
>
>> Link to the image of parts 1 & 2
>> 
>>
>> On Tue, Sep 10, 2019 at 5:25 PM Oleg 
>> wrote:
>>
>>> Hi Linden,
>>>
>>> You need a program like minicom to display a serial port output.
>>> The speed settings for the serial port are 115200 8N1
>>> .
>>> And the device is normally: /dev/ttyUSB0
>>>
>>> Do you have the cable?
>>>
>>> It consists of 3 parts: parts 1 & 2, part 3
>>> ):
>>> parts 1&2:
>>>
 RS-232 Adapter/Cable is used to connect to the serial port of
 NC353L-369 cameras. This port outputs all the boot and debug messages and
 provides system console that can be used for software development - this
 console allows to control the camera even if the network is misconfigured.
 This kit consists of 2 parts: 0353-01-04 - DB9 to modular adapter with
 custom wiring and a
 0353-01-05 - 6-wire modular cable with crossover wiring (6-wire modular
 telephone cable)
>>>
>>> part3:
>>>
 USB to RS-232 converter cable - an addition to RS-232 Adapter/Cable
 that allows to use a host PC's USB port instead of RS232.
>>>
>>>
>>> Regards,
>>> Oleg
>>>
>>> On Tue, Sep 10, 2019 at 5:01 PM Linden @ Zone4  wrote:
>>>
 Hi Oleg,

 I have another camera with issues booting that I would like to
 diagnose. Discovered I have a 10369 board can you pass along some
 instructions and I will see if it has a bad block.

 Thanks,

 Linden Mills-Connery
 Zone4 Team 
 205-820 Main Street
 Canmore, AB, T1W2B7
 403-401-7215


 On Tue, 28 Aug 2018 at 16:19, Oleg 
 wrote:

> Linden,
>
> I reflashed the 000E64081CA1 - and it works now.
>
> It had a bad block. See the old bootlog from the serial output (via
> the extension board 10369) below.
>
> Have you ever reflashed a camera? One of the tests that can tell if
> the flash is probably corrupted is putting the camera in the netboot mode.
> Then reflash if possible - during reflashing it detects and skips the bad
> blocks.
>
> Boot log:
>
>> ETRAX FS NAND boot loader
>>
>>
>>
>> =
>>
>>
>>
>> Rev 1, Nov 23 2009 12:31:43
>>
>>
>>
>> Boot config: 0x0004->0x4044, len 0x0020, boot @
>> 0x4044
>>
>>
>> CPU revision: 0x0020
>>
>>
>>
>> Bootloader main at 0x38000ce2
>>
>>
>>
>> Data end: 0x3800573c
>>
>>
>>
>> Bss: 0x38008000
>>
>>
>>
>> Heap: 0x38008000
>>
>>
>>
>> Identifying nand chip...
>>
>>
>>
>> maf_id: 0x002c; dev_id: 0x00f1
>>
>>
>>
>> mtd->size == 0x0800
>>
>>
>>
>> scan_bbt(); mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...01; mtd->size == 0x0800
>>
>>
>>
>> len == 0x0100; and BBT_LEN_1 == 0x0400
>>
>>
>>
>> scan_bbt() ...02; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...03; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...2; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() search_read_bbts(); mtd->size == 0x0800
>>
>>
>>
>> search_read_bbts() search primary table; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>
>>
>>
>> Block: 0x03ff
>>
>>
>>
>> Check, if we found a bbt for each requested chip
>>
>>
>>
>> Bad block table found at page0xffc0, version 0x0001
>>
>>
>>
>> search_read_bbts() search mirror table
>>
>>
>>
>> search_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>
>>
>>
>> Block: 0x03ff
>>
>>
>>
>> Block: 0x03fe
>>
>>
>>
>> 

Re: [Elphel-support] 353 Problem Mainboards

2019-10-01 Thread Oleg
Hi Linden,

Follow up. Were you able to get the serial output?

Regards,
Oleg

On Tue, Sep 10, 2019 at 5:29 PM Oleg 
wrote:

> Link to the image of parts 1 & 2
> 
>
> On Tue, Sep 10, 2019 at 5:25 PM Oleg 
> wrote:
>
>> Hi Linden,
>>
>> You need a program like minicom to display a serial port output.
>> The speed settings for the serial port are 115200 8N1
>> .
>> And the device is normally: /dev/ttyUSB0
>>
>> Do you have the cable?
>>
>> It consists of 3 parts: parts 1 & 2, part 3
>> ):
>> parts 1&2:
>>
>>> RS-232 Adapter/Cable is used to connect to the serial port of NC353L-369
>>> cameras. This port outputs all the boot and debug messages and provides
>>> system console that can be used for software development - this console
>>> allows to control the camera even if the network is misconfigured.
>>> This kit consists of 2 parts: 0353-01-04 - DB9 to modular adapter with
>>> custom wiring and a
>>> 0353-01-05 - 6-wire modular cable with crossover wiring (6-wire modular
>>> telephone cable)
>>
>> part3:
>>
>>> USB to RS-232 converter cable - an addition to RS-232 Adapter/Cable that
>>> allows to use a host PC's USB port instead of RS232.
>>
>>
>> Regards,
>> Oleg
>>
>> On Tue, Sep 10, 2019 at 5:01 PM Linden @ Zone4  wrote:
>>
>>> Hi Oleg,
>>>
>>> I have another camera with issues booting that I would like to diagnose.
>>> Discovered I have a 10369 board can you pass along some instructions and I
>>> will see if it has a bad block.
>>>
>>> Thanks,
>>>
>>> Linden Mills-Connery
>>> Zone4 Team 
>>> 205-820 Main Street
>>> Canmore, AB, T1W2B7
>>> 403-401-7215
>>>
>>>
>>> On Tue, 28 Aug 2018 at 16:19, Oleg 
>>> wrote:
>>>
 Linden,

 I reflashed the 000E64081CA1 - and it works now.

 It had a bad block. See the old bootlog from the serial output (via the
 extension board 10369) below.

 Have you ever reflashed a camera? One of the tests that can tell if the
 flash is probably corrupted is putting the camera in the netboot mode. Then
 reflash if possible - during reflashing it detects and skips the bad 
 blocks.

 Boot log:

> ETRAX FS NAND boot loader
>
>
>
> =
>
>
>
> Rev 1, Nov 23 2009 12:31:43
>
>
>
> Boot config: 0x0004->0x4044, len 0x0020, boot @ 0x4044
>
>
>
> CPU revision: 0x0020
>
>
>
> Bootloader main at 0x38000ce2
>
>
>
> Data end: 0x3800573c
>
>
>
> Bss: 0x38008000
>
>
>
> Heap: 0x38008000
>
>
>
> Identifying nand chip...
>
>
>
> maf_id: 0x002c; dev_id: 0x00f1
>
>
>
> mtd->size == 0x0800
>
>
>
> scan_bbt(); mtd->size == 0x0800
>
>
>
> scan_bbt() ...01; mtd->size == 0x0800
>
>
>
> len == 0x0100; and BBT_LEN_1 == 0x0400
>
>
>
> scan_bbt() ...02; mtd->size == 0x0800
>
>
>
> scan_bbt() ...03; mtd->size == 0x0800
>
>
>
> scan_bbt() ...1; mtd->size == 0x0800
>
>
>
> scan_bbt() ...2; mtd->size == 0x0800
>
>
>
> scan_bbt() search_read_bbts(); mtd->size == 0x0800
>
>
>
> search_read_bbts() search primary table; mtd->size == 0x0800
>
>
>
> search_bbt() ...1; mtd->size == 0x0800
>
>
>
> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>
>
>
> Block: 0x03ff
>
>
>
> Check, if we found a bbt for each requested chip
>
>
>
> Bad block table found at page0xffc0, version 0x0001
>
>
>
> search_read_bbts() search mirror table
>
>
>
> search_bbt() ...1; mtd->size == 0x0800
>
>
>
> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>
>
>
> Block: 0x03ff
>
>
>
> Block: 0x03fe
>
>
>
> Check, if we found a bbt for each requested chip
>
>
>
> Bad block table found at page0xff80, version 0x0001
>
>
>
> scan_bbt() ...3
>
>
>
> Done.
>
>
>
> Chip identified... 3; NAND 128MiB 3,3V 8-bit
>
>
>
> type: 0x0004
>
>
>
> flags: 0x00c5
>
>
>
> size: 0x0800
>
>
>
> erasesize: 0x0002
>
>
>
> oobblock: 0x0800
>
>
>
> oobsize: 0x0040
>
>
>
> ecctype: 0x0002
>
>
>
> eccsize: 0x0100
>
>
>
> Oob info:
>
>
>
> useecc: 0x0002
>
>
>
> 

Re: [Elphel-support] 353 Problem Mainboards

2019-09-10 Thread Oleg
Link to the image of parts 1 & 2


On Tue, Sep 10, 2019 at 5:25 PM Oleg 
wrote:

> Hi Linden,
>
> You need a program like minicom to display a serial port output.
> The speed settings for the serial port are 115200 8N1
> .
> And the device is normally: /dev/ttyUSB0
>
> Do you have the cable?
>
> It consists of 3 parts: parts 1 & 2, part 3
> ):
> parts 1&2:
>
>> RS-232 Adapter/Cable is used to connect to the serial port of NC353L-369
>> cameras. This port outputs all the boot and debug messages and provides
>> system console that can be used for software development - this console
>> allows to control the camera even if the network is misconfigured.
>> This kit consists of 2 parts: 0353-01-04 - DB9 to modular adapter with
>> custom wiring and a
>> 0353-01-05 - 6-wire modular cable with crossover wiring (6-wire modular
>> telephone cable)
>
> part3:
>
>> USB to RS-232 converter cable - an addition to RS-232 Adapter/Cable that
>> allows to use a host PC's USB port instead of RS232.
>
>
> Regards,
> Oleg
>
> On Tue, Sep 10, 2019 at 5:01 PM Linden @ Zone4  wrote:
>
>> Hi Oleg,
>>
>> I have another camera with issues booting that I would like to diagnose.
>> Discovered I have a 10369 board can you pass along some instructions and I
>> will see if it has a bad block.
>>
>> Thanks,
>>
>> Linden Mills-Connery
>> Zone4 Team 
>> 205-820 Main Street
>> Canmore, AB, T1W2B7
>> 403-401-7215
>>
>>
>> On Tue, 28 Aug 2018 at 16:19, Oleg 
>> wrote:
>>
>>> Linden,
>>>
>>> I reflashed the 000E64081CA1 - and it works now.
>>>
>>> It had a bad block. See the old bootlog from the serial output (via the
>>> extension board 10369) below.
>>>
>>> Have you ever reflashed a camera? One of the tests that can tell if the
>>> flash is probably corrupted is putting the camera in the netboot mode. Then
>>> reflash if possible - during reflashing it detects and skips the bad blocks.
>>>
>>> Boot log:
>>>
 ETRAX FS NAND boot loader



 =



 Rev 1, Nov 23 2009 12:31:43



 Boot config: 0x0004->0x4044, len 0x0020, boot @ 0x4044



 CPU revision: 0x0020



 Bootloader main at 0x38000ce2



 Data end: 0x3800573c



 Bss: 0x38008000



 Heap: 0x38008000



 Identifying nand chip...



 maf_id: 0x002c; dev_id: 0x00f1



 mtd->size == 0x0800



 scan_bbt(); mtd->size == 0x0800



 scan_bbt() ...01; mtd->size == 0x0800



 len == 0x0100; and BBT_LEN_1 == 0x0400



 scan_bbt() ...02; mtd->size == 0x0800



 scan_bbt() ...03; mtd->size == 0x0800



 scan_bbt() ...1; mtd->size == 0x0800



 scan_bbt() ...2; mtd->size == 0x0800



 scan_bbt() search_read_bbts(); mtd->size == 0x0800



 search_read_bbts() search primary table; mtd->size == 0x0800



 search_bbt() ...1; mtd->size == 0x0800



 search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800



 Block: 0x03ff



 Check, if we found a bbt for each requested chip



 Bad block table found at page0xffc0, version 0x0001



 search_read_bbts() search mirror table



 search_bbt() ...1; mtd->size == 0x0800



 search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800



 Block: 0x03ff



 Block: 0x03fe



 Check, if we found a bbt for each requested chip



 Bad block table found at page0xff80, version 0x0001



 scan_bbt() ...3



 Done.



 Chip identified... 3; NAND 128MiB 3,3V 8-bit



 type: 0x0004



 flags: 0x00c5



 size: 0x0800



 erasesize: 0x0002



 oobblock: 0x0800



 oobsize: 0x0040



 ecctype: 0x0002



 eccsize: 0x0100



 Oob info:



 useecc: 0x0002



 eccbytes: 0x0018



 eccpos: 0x0028 0x0029 0x002a 0x002b 0x002c
 0x002d 0x002e 0x002f 0x0030 0x0031 0x0032
 0x0033 0x0034 0x0035 0x0036 0x0037 0x0038
 0x0039 0x003a 0x003b 0x003c 0x003d 0x003e 0x003

 Bootload in progress...



 New block 

Re: [Elphel-support] 353 Problem Mainboards

2019-09-10 Thread Oleg
Hi Linden,

You need a program like minicom to display a serial port output.
The speed settings for the serial port are 115200 8N1
.
And the device is normally: /dev/ttyUSB0

Do you have the cable?

It consists of 3 parts: parts 1 & 2, part 3
):
parts 1&2:

> RS-232 Adapter/Cable is used to connect to the serial port of NC353L-369
> cameras. This port outputs all the boot and debug messages and provides
> system console that can be used for software development - this console
> allows to control the camera even if the network is misconfigured.
> This kit consists of 2 parts: 0353-01-04 - DB9 to modular adapter with
> custom wiring and a
> 0353-01-05 - 6-wire modular cable with crossover wiring (6-wire modular
> telephone cable)

part3:

> USB to RS-232 converter cable - an addition to RS-232 Adapter/Cable that
> allows to use a host PC's USB port instead of RS232.


Regards,
Oleg

On Tue, Sep 10, 2019 at 5:01 PM Linden @ Zone4  wrote:

> Hi Oleg,
>
> I have another camera with issues booting that I would like to diagnose.
> Discovered I have a 10369 board can you pass along some instructions and I
> will see if it has a bad block.
>
> Thanks,
>
> Linden Mills-Connery
> Zone4 Team 
> 205-820 Main Street
> Canmore, AB, T1W2B7
> 403-401-7215
>
>
> On Tue, 28 Aug 2018 at 16:19, Oleg 
> wrote:
>
>> Linden,
>>
>> I reflashed the 000E64081CA1 - and it works now.
>>
>> It had a bad block. See the old bootlog from the serial output (via the
>> extension board 10369) below.
>>
>> Have you ever reflashed a camera? One of the tests that can tell if the
>> flash is probably corrupted is putting the camera in the netboot mode. Then
>> reflash if possible - during reflashing it detects and skips the bad blocks.
>>
>> Boot log:
>>
>>> ETRAX FS NAND boot loader
>>>
>>>
>>>
>>> =
>>>
>>>
>>>
>>> Rev 1, Nov 23 2009 12:31:43
>>>
>>>
>>>
>>> Boot config: 0x0004->0x4044, len 0x0020, boot @ 0x4044
>>>
>>>
>>>
>>> CPU revision: 0x0020
>>>
>>>
>>>
>>> Bootloader main at 0x38000ce2
>>>
>>>
>>>
>>> Data end: 0x3800573c
>>>
>>>
>>>
>>> Bss: 0x38008000
>>>
>>>
>>>
>>> Heap: 0x38008000
>>>
>>>
>>>
>>> Identifying nand chip...
>>>
>>>
>>>
>>> maf_id: 0x002c; dev_id: 0x00f1
>>>
>>>
>>>
>>> mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt(); mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...01; mtd->size == 0x0800
>>>
>>>
>>>
>>> len == 0x0100; and BBT_LEN_1 == 0x0400
>>>
>>>
>>>
>>> scan_bbt() ...02; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...03; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...1; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() ...2; mtd->size == 0x0800
>>>
>>>
>>>
>>> scan_bbt() search_read_bbts(); mtd->size == 0x0800
>>>
>>>
>>>
>>> search_read_bbts() search primary table; mtd->size == 0x0800
>>>
>>>
>>>
>>> search_bbt() ...1; mtd->size == 0x0800
>>>
>>>
>>>
>>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>>
>>>
>>>
>>> Block: 0x03ff
>>>
>>>
>>>
>>> Check, if we found a bbt for each requested chip
>>>
>>>
>>>
>>> Bad block table found at page0xffc0, version 0x0001
>>>
>>>
>>>
>>> search_read_bbts() search mirror table
>>>
>>>
>>>
>>> search_bbt() ...1; mtd->size == 0x0800
>>>
>>>
>>>
>>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>>
>>>
>>>
>>> Block: 0x03ff
>>>
>>>
>>>
>>> Block: 0x03fe
>>>
>>>
>>>
>>> Check, if we found a bbt for each requested chip
>>>
>>>
>>>
>>> Bad block table found at page0xff80, version 0x0001
>>>
>>>
>>>
>>> scan_bbt() ...3
>>>
>>>
>>>
>>> Done.
>>>
>>>
>>>
>>> Chip identified... 3; NAND 128MiB 3,3V 8-bit
>>>
>>>
>>>
>>> type: 0x0004
>>>
>>>
>>>
>>> flags: 0x00c5
>>>
>>>
>>>
>>> size: 0x0800
>>>
>>>
>>>
>>> erasesize: 0x0002
>>>
>>>
>>>
>>> oobblock: 0x0800
>>>
>>>
>>>
>>> oobsize: 0x0040
>>>
>>>
>>>
>>> ecctype: 0x0002
>>>
>>>
>>>
>>> eccsize: 0x0100
>>>
>>>
>>>
>>> Oob info:
>>>
>>>
>>>
>>> useecc: 0x0002
>>>
>>>
>>>
>>> eccbytes: 0x0018
>>>
>>>
>>>
>>> eccpos: 0x0028 0x0029 0x002a 0x002b 0x002c
>>> 0x002d 0x002e 0x002f 0x0030 0x0031 0x0032
>>> 0x0033 0x0034 0x0035 0x0036 0x0037 0x0038
>>> 0x0039 0x003a 0x003b 0x003c 0x003d 0x003e 0x003
>>>
>>> Bootload in progress...
>>>
>>>
>>>
>>> New block 0x0004;len: 0x0020;start: 0x0004
>>>
>>>
>>>
>>> New block 0x0006;len: 0x001e;start: 0x0006
>>>
>>>
>>>
>>> New block 0x0008;len: 0x001c;start: 0x0008
>>>
>>>
>>>
>>> New block 0x000a;len: 0x001a;start: 0x000a
>>>
>>>
>>>
>>> New block 0x000c;len: 0x0018;start: 0x000c
>>>
>>>
>>>
>>> New block 0x000e;len: 0x0016;start: 0x000e
>>>
>>>
>>>

Re: [Elphel-support] 353 Problem Mainboards

2019-09-10 Thread Linden @ Zone4
Hi Oleg,

I have another camera with issues booting that I would like to diagnose.
Discovered I have a 10369 board can you pass along some instructions and I
will see if it has a bad block.

Thanks,

Linden Mills-Connery
Zone4 Team 
205-820 Main Street
Canmore, AB, T1W2B7
403-401-7215


On Tue, 28 Aug 2018 at 16:19, Oleg  wrote:

> Linden,
>
> I reflashed the 000E64081CA1 - and it works now.
>
> It had a bad block. See the old bootlog from the serial output (via the
> extension board 10369) below.
>
> Have you ever reflashed a camera? One of the tests that can tell if the
> flash is probably corrupted is putting the camera in the netboot mode. Then
> reflash if possible - during reflashing it detects and skips the bad blocks.
>
> Boot log:
>
>> ETRAX FS NAND boot loader
>>
>>
>>
>> =
>>
>>
>>
>> Rev 1, Nov 23 2009 12:31:43
>>
>>
>>
>> Boot config: 0x0004->0x4044, len 0x0020, boot @ 0x4044
>>
>>
>>
>> CPU revision: 0x0020
>>
>>
>>
>> Bootloader main at 0x38000ce2
>>
>>
>>
>> Data end: 0x3800573c
>>
>>
>>
>> Bss: 0x38008000
>>
>>
>>
>> Heap: 0x38008000
>>
>>
>>
>> Identifying nand chip...
>>
>>
>>
>> maf_id: 0x002c; dev_id: 0x00f1
>>
>>
>>
>> mtd->size == 0x0800
>>
>>
>>
>> scan_bbt(); mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...01; mtd->size == 0x0800
>>
>>
>>
>> len == 0x0100; and BBT_LEN_1 == 0x0400
>>
>>
>>
>> scan_bbt() ...02; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...03; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...2; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() search_read_bbts(); mtd->size == 0x0800
>>
>>
>>
>> search_read_bbts() search primary table; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>
>>
>>
>> Block: 0x03ff
>>
>>
>>
>> Check, if we found a bbt for each requested chip
>>
>>
>>
>> Bad block table found at page0xffc0, version 0x0001
>>
>>
>>
>> search_read_bbts() search mirror table
>>
>>
>>
>> search_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>
>>
>>
>> Block: 0x03ff
>>
>>
>>
>> Block: 0x03fe
>>
>>
>>
>> Check, if we found a bbt for each requested chip
>>
>>
>>
>> Bad block table found at page0xff80, version 0x0001
>>
>>
>>
>> scan_bbt() ...3
>>
>>
>>
>> Done.
>>
>>
>>
>> Chip identified... 3; NAND 128MiB 3,3V 8-bit
>>
>>
>>
>> type: 0x0004
>>
>>
>>
>> flags: 0x00c5
>>
>>
>>
>> size: 0x0800
>>
>>
>>
>> erasesize: 0x0002
>>
>>
>>
>> oobblock: 0x0800
>>
>>
>>
>> oobsize: 0x0040
>>
>>
>>
>> ecctype: 0x0002
>>
>>
>>
>> eccsize: 0x0100
>>
>>
>>
>> Oob info:
>>
>>
>>
>> useecc: 0x0002
>>
>>
>>
>> eccbytes: 0x0018
>>
>>
>>
>> eccpos: 0x0028 0x0029 0x002a 0x002b 0x002c 0x002d
>> 0x002e 0x002f 0x0030 0x0031 0x0032 0x0033
>> 0x0034 0x0035 0x0036 0x0037 0x0038 0x0039
>> 0x003a 0x003b 0x003c 0x003d 0x003e 0x003
>> Bootload in progress...
>>
>>
>>
>> New block 0x0004;len: 0x0020;start: 0x0004
>>
>>
>>
>> New block 0x0006;len: 0x001e;start: 0x0006
>>
>>
>>
>> New block 0x0008;len: 0x001c;start: 0x0008
>>
>>
>>
>> New block 0x000a;len: 0x001a;start: 0x000a
>>
>>
>>
>> New block 0x000c;len: 0x0018;start: 0x000c
>>
>>
>>
>> New block 0x000e;len: 0x0016;start: 0x000e
>>
>>
>>
>> New block 0x0010;len: 0x0014;start: 0x0010
>>
>>
>>
>> New block 0x0012;len: 0x0012;start: 0x0012
>>
>>
>>
>> New block 0x0014;len: 0x0010;start: 0x0014
>>
>>
>>
>> New block 0x0016;len: 0x000e;start: 0x0016
>>
>>
>>
>> New block 0x0018;len: 0x000c;start: 0x0018
>>
>>
>>
>> complete, status 0xffb6, loaded 0x0014 bytes
>>
>>
>>
>> Data in DRAM:
>>
>>
>>
>> 0x25f005b0 0x009cedff 0xbeef05b0
>>
>>
>>
>
>
>>
>>
>>
>>
>>
>>
>> Corrupt data in NAND flash.
>>
>>
>>
>>
>>
>>
>>
>> -- System halted
>
>
> On Mon, Aug 20, 2018 at 1:53 PM Linden @ Zone4  wrote:
>
>> Thanks for the tip, solved it:
>> I recall the autocampars.php file was causing issues on this camera
>> before and I probably tried to fix it by pasting in the file from source
>> into the web based terminal (
>> http://10.23.33.9/index.php?site=phpshell.php). This converts all the
>> HTML entities ( etc...) to the wrong thing. I SCPed in the original
>> source, deleted /etc/autocampars.xml and ran /usr/html/autocampars.php
>> --init. Working again.
>>
>> I am still going to ship you the 000E64081CA1 mainboard (the one that
>> won't boot).
>>
>> Thanks,
>>
>> Linden Mills-Connery
>> Zone4 Team 
>> 205-820 Main Street
>> Canmore, AB, T1W2B7
>> 403-401-7215
>>
>> On 20 August 2018 at 10:43, Oleg  wrote:
>>

Re: [Elphel-support] 353 Problem Mainboards

2018-09-14 Thread Linden @ Zone4
Thanks Oleg,

Got the camera back and it's working.

I have done a re-flash a while ago, but I will try that next time.

Linden Mills-Connery
Zone4 Team 
205-820 Main Street
Canmore, AB, T1W2B7
403-401-7215


On Tue, 28 Aug 2018 at 16:19, Oleg  wrote:

> Linden,
>
> I reflashed the 000E64081CA1 - and it works now.
>
> It had a bad block. See the old bootlog from the serial output (via the
> extension board 10369) below.
>
> Have you ever reflashed a camera? One of the tests that can tell if the
> flash is probably corrupted is putting the camera in the netboot mode. Then
> reflash if possible - during reflashing it detects and skips the bad blocks.
>
> Boot log:
>
>> ETRAX FS NAND boot loader
>>
>>
>>
>> =
>>
>>
>>
>> Rev 1, Nov 23 2009 12:31:43
>>
>>
>>
>> Boot config: 0x0004->0x4044, len 0x0020, boot @ 0x4044
>>
>>
>>
>> CPU revision: 0x0020
>>
>>
>>
>> Bootloader main at 0x38000ce2
>>
>>
>>
>> Data end: 0x3800573c
>>
>>
>>
>> Bss: 0x38008000
>>
>>
>>
>> Heap: 0x38008000
>>
>>
>>
>> Identifying nand chip...
>>
>>
>>
>> maf_id: 0x002c; dev_id: 0x00f1
>>
>>
>>
>> mtd->size == 0x0800
>>
>>
>>
>> scan_bbt(); mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...01; mtd->size == 0x0800
>>
>>
>>
>> len == 0x0100; and BBT_LEN_1 == 0x0400
>>
>>
>>
>> scan_bbt() ...02; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...03; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() ...2; mtd->size == 0x0800
>>
>>
>>
>> scan_bbt() search_read_bbts(); mtd->size == 0x0800
>>
>>
>>
>> search_read_bbts() search primary table; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>
>>
>>
>> Block: 0x03ff
>>
>>
>>
>> Check, if we found a bbt for each requested chip
>>
>>
>>
>> Bad block table found at page0xffc0, version 0x0001
>>
>>
>>
>> search_read_bbts() search mirror table
>>
>>
>>
>> search_bbt() ...1; mtd->size == 0x0800
>>
>>
>>
>> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>>
>>
>>
>> Block: 0x03ff
>>
>>
>>
>> Block: 0x03fe
>>
>>
>>
>> Check, if we found a bbt for each requested chip
>>
>>
>>
>> Bad block table found at page0xff80, version 0x0001
>>
>>
>>
>> scan_bbt() ...3
>>
>>
>>
>> Done.
>>
>>
>>
>> Chip identified... 3; NAND 128MiB 3,3V 8-bit
>>
>>
>>
>> type: 0x0004
>>
>>
>>
>> flags: 0x00c5
>>
>>
>>
>> size: 0x0800
>>
>>
>>
>> erasesize: 0x0002
>>
>>
>>
>> oobblock: 0x0800
>>
>>
>>
>> oobsize: 0x0040
>>
>>
>>
>> ecctype: 0x0002
>>
>>
>>
>> eccsize: 0x0100
>>
>>
>>
>> Oob info:
>>
>>
>>
>> useecc: 0x0002
>>
>>
>>
>> eccbytes: 0x0018
>>
>>
>>
>> eccpos: 0x0028 0x0029 0x002a 0x002b 0x002c 0x002d
>> 0x002e 0x002f 0x0030 0x0031 0x0032 0x0033
>> 0x0034 0x0035 0x0036 0x0037 0x0038 0x0039
>> 0x003a 0x003b 0x003c 0x003d 0x003e 0x003
>> Bootload in progress...
>>
>>
>>
>> New block 0x0004;len: 0x0020;start: 0x0004
>>
>>
>>
>> New block 0x0006;len: 0x001e;start: 0x0006
>>
>>
>>
>> New block 0x0008;len: 0x001c;start: 0x0008
>>
>>
>>
>> New block 0x000a;len: 0x001a;start: 0x000a
>>
>>
>>
>> New block 0x000c;len: 0x0018;start: 0x000c
>>
>>
>>
>> New block 0x000e;len: 0x0016;start: 0x000e
>>
>>
>>
>> New block 0x0010;len: 0x0014;start: 0x0010
>>
>>
>>
>> New block 0x0012;len: 0x0012;start: 0x0012
>>
>>
>>
>> New block 0x0014;len: 0x0010;start: 0x0014
>>
>>
>>
>> New block 0x0016;len: 0x000e;start: 0x0016
>>
>>
>>
>> New block 0x0018;len: 0x000c;start: 0x0018
>>
>>
>>
>> complete, status 0xffb6, loaded 0x0014 bytes
>>
>>
>>
>> Data in DRAM:
>>
>>
>>
>> 0x25f005b0 0x009cedff 0xbeef05b0
>>
>>
>>
>
>
>>
>>
>>
>>
>>
>>
>> Corrupt data in NAND flash.
>>
>>
>>
>>
>>
>>
>>
>> -- System halted
>
>
> On Mon, Aug 20, 2018 at 1:53 PM Linden @ Zone4  wrote:
>
>> Thanks for the tip, solved it:
>> I recall the autocampars.php file was causing issues on this camera
>> before and I probably tried to fix it by pasting in the file from source
>> into the web based terminal (
>> http://10.23.33.9/index.php?site=phpshell.php). This converts all the
>> HTML entities ( etc...) to the wrong thing. I SCPed in the original
>> source, deleted /etc/autocampars.xml and ran /usr/html/autocampars.php
>> --init. Working again.
>>
>> I am still going to ship you the 000E64081CA1 mainboard (the one that
>> won't boot).
>>
>> Thanks,
>>
>> Linden Mills-Connery
>> Zone4 Team 
>> 205-820 Main Street
>> Canmore, AB, T1W2B7
>> 403-401-7215
>>
>> On 20 August 2018 at 10:43, Oleg  wrote:
>>
>>> Linden,
>>>
>>> Does the file look ok? It should have ~4k lines.
>>>
>>> 

Re: [Elphel-support] 353 Problem Mainboards

2018-08-28 Thread Oleg
Linden,

I reflashed the 000E64081CA1 - and it works now.

It had a bad block. See the old bootlog from the serial output (via the
extension board 10369) below.

Have you ever reflashed a camera? One of the tests that can tell if the
flash is probably corrupted is putting the camera in the netboot mode. Then
reflash if possible - during reflashing it detects and skips the bad blocks.

Boot log:

> ETRAX FS NAND boot loader
>
>
>
> =
>
>
>
> Rev 1, Nov 23 2009 12:31:43
>
>
>
> Boot config: 0x0004->0x4044, len 0x0020, boot @ 0x4044
>
>
>
> CPU revision: 0x0020
>
>
>
> Bootloader main at 0x38000ce2
>
>
>
> Data end: 0x3800573c
>
>
>
> Bss: 0x38008000
>
>
>
> Heap: 0x38008000
>
>
>
> Identifying nand chip...
>
>
>
> maf_id: 0x002c; dev_id: 0x00f1
>
>
>
> mtd->size == 0x0800
>
>
>
> scan_bbt(); mtd->size == 0x0800
>
>
>
> scan_bbt() ...01; mtd->size == 0x0800
>
>
>
> len == 0x0100; and BBT_LEN_1 == 0x0400
>
>
>
> scan_bbt() ...02; mtd->size == 0x0800
>
>
>
> scan_bbt() ...03; mtd->size == 0x0800
>
>
>
> scan_bbt() ...1; mtd->size == 0x0800
>
>
>
> scan_bbt() ...2; mtd->size == 0x0800
>
>
>
> scan_bbt() search_read_bbts(); mtd->size == 0x0800
>
>
>
> search_read_bbts() search primary table; mtd->size == 0x0800
>
>
>
> search_bbt() ...1; mtd->size == 0x0800
>
>
>
> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>
>
>
> Block: 0x03ff
>
>
>
> Check, if we found a bbt for each requested chip
>
>
>
> Bad block table found at page0xffc0, version 0x0001
>
>
>
> search_read_bbts() search mirror table
>
>
>
> search_bbt() ...1; mtd->size == 0x0800
>
>
>
> search_bbt() ...2; maxblocks: 0x0004; mtd->size == 0x0800
>
>
>
> Block: 0x03ff
>
>
>
> Block: 0x03fe
>
>
>
> Check, if we found a bbt for each requested chip
>
>
>
> Bad block table found at page0xff80, version 0x0001
>
>
>
> scan_bbt() ...3
>
>
>
> Done.
>
>
>
> Chip identified... 3; NAND 128MiB 3,3V 8-bit
>
>
>
> type: 0x0004
>
>
>
> flags: 0x00c5
>
>
>
> size: 0x0800
>
>
>
> erasesize: 0x0002
>
>
>
> oobblock: 0x0800
>
>
>
> oobsize: 0x0040
>
>
>
> ecctype: 0x0002
>
>
>
> eccsize: 0x0100
>
>
>
> Oob info:
>
>
>
> useecc: 0x0002
>
>
>
> eccbytes: 0x0018
>
>
>
> eccpos: 0x0028 0x0029 0x002a 0x002b 0x002c 0x002d
> 0x002e 0x002f 0x0030 0x0031 0x0032 0x0033
> 0x0034 0x0035 0x0036 0x0037 0x0038 0x0039
> 0x003a 0x003b 0x003c 0x003d 0x003e 0x003
> Bootload in progress...
>
>
>
> New block 0x0004;len: 0x0020;start: 0x0004
>
>
>
> New block 0x0006;len: 0x001e;start: 0x0006
>
>
>
> New block 0x0008;len: 0x001c;start: 0x0008
>
>
>
> New block 0x000a;len: 0x001a;start: 0x000a
>
>
>
> New block 0x000c;len: 0x0018;start: 0x000c
>
>
>
> New block 0x000e;len: 0x0016;start: 0x000e
>
>
>
> New block 0x0010;len: 0x0014;start: 0x0010
>
>
>
> New block 0x0012;len: 0x0012;start: 0x0012
>
>
>
> New block 0x0014;len: 0x0010;start: 0x0014
>
>
>
> New block 0x0016;len: 0x000e;start: 0x0016
>
>
>
> New block 0x0018;len: 0x000c;start: 0x0018
>
>
>
> complete, status 0xffb6, loaded 0x0014 bytes
>
>
>
> Data in DRAM:
>
>
>
> 0x25f005b0 0x009cedff 0xbeef05b0
>
>
>


>
>
>
>
>
>
> Corrupt data in NAND flash.
>
>
>
>
>
>
>
> -- System halted


On Mon, Aug 20, 2018 at 1:53 PM Linden @ Zone4  wrote:

> Thanks for the tip, solved it:
> I recall the autocampars.php file was causing issues on this camera before
> and I probably tried to fix it by pasting in the file from source into the
> web based terminal (http://10.23.33.9/index.php?site=phpshell.php). This
> converts all the HTML entities ( etc...) to the wrong thing. I SCPed
> in the original source, deleted /etc/autocampars.xml and ran
> /usr/html/autocampars.php --init. Working again.
>
> I am still going to ship you the 000E64081CA1 mainboard (the one that
> won't boot).
>
> Thanks,
>
> Linden Mills-Connery
> Zone4 Team 
> 205-820 Main Street
> Canmore, AB, T1W2B7
> 403-401-7215
>
> On 20 August 2018 at 10:43, Oleg  wrote:
>
>> Linden,
>>
>> Does the file look ok? It should have ~4k lines.
>>
>> http://192.168.0.9/index.php?site=admin-bin/editcgi.cgi?file=/usr/html/autocampars.php
>>
>> Regards,
>> Oleg
>>
>> On Fri, Aug 17, 2018 at 6:57 PM Linden @ Zone4  wrote:
>>
>>> I have run '/usr/html/autocampars.php --init', looks like a very similar
>>> error trace to loading http://10.23.33.9/index.php?site=autocampars.php.
>>> Output posted at bottom of GDoc:
>>>
>>> https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJLodron0P0zYcpB4/edit?usp=sharing
>>>
>>> Linden Mills-Connery
>>> Zone4 Team 
>>> 205-820 Main Street
>>> 

Re: [Elphel-support] 353 Problem Mainboards

2018-08-20 Thread Linden @ Zone4
Thanks for the tip, solved it:
I recall the autocampars.php file was causing issues on this camera before
and I probably tried to fix it by pasting in the file from source into the
web based terminal (http://10.23.33.9/index.php?site=phpshell.php). This
converts all the HTML entities ( etc...) to the wrong thing. I SCPed
in the original source, deleted /etc/autocampars.xml and ran
/usr/html/autocampars.php --init. Working again.

I am still going to ship you the 000E64081CA1 mainboard (the one that won't
boot).

Thanks,

Linden Mills-Connery
Zone4 Team 
205-820 Main Street
Canmore, AB, T1W2B7
403-401-7215

On 20 August 2018 at 10:43, Oleg  wrote:

> Linden,
>
> Does the file look ok? It should have ~4k lines.
> http://192.168.0.9/index.php?site=admin-bin/editcgi.cgi?
> file=/usr/html/autocampars.php
>
> Regards,
> Oleg
>
> On Fri, Aug 17, 2018 at 6:57 PM Linden @ Zone4  wrote:
>
>> I have run '/usr/html/autocampars.php --init', looks like a very similar
>> error trace to loading http://10.23.33.9/index.php?site=autocampars.php.
>> Output posted at bottom of GDoc:
>> https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJL
>> odron0P0zYcpB4/edit?usp=sharing
>>
>> Linden Mills-Connery
>> Zone4 Team 
>> 205-820 Main Street
>> 
>> Canmore, AB, T1W2B7
>> 
>> 403-401-7215
>>
>> On 17 August 2018 at 17:53, Oleg  wrote:
>>
>>> I deleted /etc/autocampars.xml and went to http://10.23.33.9/index.
 php?site=autocampars.php again to re-generate it which just resulted
 in an error message. The error message is also in the GDoc.

>>> That worked with the board I'm testing.
>>>
>>> What if you reboot?
>>> Try from command line?
>>>
>>> [root@Elphel353 /root]759# */usr/html/autocampars.php --init*
 autocampars.php created a new configuration file /etc/autocampars.xml
 from defaults.
 Current frame=1266, sleeping to give daemons a chance
 Current frame=1319, waking up, daemons should be dead already
 before reset - current frame=0
 after reset - current frame=2
 setting COMPRESSOR_RUN=2
 setting DAEMON_EN=Array
 (
[DAEMON_EN_AUTOEXPOSURE] => 1
[DAEMON_EN_STREAMER] => 1
[DAEMON_EN_CCAMFTP] => 0
[DAEMON_EN_CAMOGM] => 0
[DAEMON_EN_TEMPERATURE] => 0
[DAEMON_EN] => 3
 )
 after setParsFromPage - current frame=12
 Sensor was successfully initialized at August 17, 2018, 11:49 pm from
 /etc/autocampars.xml page 0
>>>
>>>
>>> Regards,
>>> Oleg
>>>
>>>
>> ___
>> Support-list mailing list
>> Support-list@support.elphel.com
>> http://support.elphel.com/mailman/listinfo/support-list_
>> support.elphel.com
>>
>
>
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2018-08-20 Thread Oleg
Linden,

Does the file look ok? It should have ~4k lines.
http://192.168.0.9/index.php?site=admin-bin/editcgi.cgi?file=/usr/html/autocampars.php

Regards,
Oleg

On Fri, Aug 17, 2018 at 6:57 PM Linden @ Zone4  wrote:

> I have run '/usr/html/autocampars.php --init', looks like a very similar
> error trace to loading http://10.23.33.9/index.php?site=autocampars.php.
> Output posted at bottom of GDoc:
>
> https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJLodron0P0zYcpB4/edit?usp=sharing
>
> Linden Mills-Connery
> Zone4 Team 
> 205-820 Main Street
> Canmore, AB, T1W2B7
> 403-401-7215
>
> On 17 August 2018 at 17:53, Oleg  wrote:
>
>> I deleted /etc/autocampars.xml and went to
>>> http://10.23.33.9/index.php?site=autocampars.php again to re-generate
>>> it which just resulted in an error message. The error message is also in
>>> the GDoc.
>>>
>> That worked with the board I'm testing.
>>
>> What if you reboot?
>> Try from command line?
>>
>> [root@Elphel353 /root]759# */usr/html/autocampars.php --init*
>>> autocampars.php created a new configuration file /etc/autocampars.xml
>>> from defaults.
>>> Current frame=1266, sleeping to give daemons a chance
>>> Current frame=1319, waking up, daemons should be dead already
>>> before reset - current frame=0
>>> after reset - current frame=2
>>> setting COMPRESSOR_RUN=2
>>> setting DAEMON_EN=Array
>>> (
>>>[DAEMON_EN_AUTOEXPOSURE] => 1
>>>[DAEMON_EN_STREAMER] => 1
>>>[DAEMON_EN_CCAMFTP] => 0
>>>[DAEMON_EN_CAMOGM] => 0
>>>[DAEMON_EN_TEMPERATURE] => 0
>>>[DAEMON_EN] => 3
>>> )
>>> after setParsFromPage - current frame=12
>>> Sensor was successfully initialized at August 17, 2018, 11:49 pm from
>>> /etc/autocampars.xml page 0
>>
>>
>> Regards,
>> Oleg
>>
>>
> ___
> Support-list mailing list
> Support-list@support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2018-08-17 Thread Oleg
>
> I deleted /etc/autocampars.xml and went to
> http://10.23.33.9/index.php?site=autocampars.php again to re-generate it
> which just resulted in an error message. The error message is also in the
> GDoc.
>
That worked with the board I'm testing.

What if you reboot?
Try from command line?

[root@Elphel353 /root]759# */usr/html/autocampars.php --init*
> autocampars.php created a new configuration file /etc/autocampars.xml from
> defaults.
> Current frame=1266, sleeping to give daemons a chance
> Current frame=1319, waking up, daemons should be dead already
> before reset - current frame=0
> after reset - current frame=2
> setting COMPRESSOR_RUN=2
> setting DAEMON_EN=Array
> (
>[DAEMON_EN_AUTOEXPOSURE] => 1
>[DAEMON_EN_STREAMER] => 1
>[DAEMON_EN_CCAMFTP] => 0
>[DAEMON_EN_CAMOGM] => 0
>[DAEMON_EN_TEMPERATURE] => 0
>[DAEMON_EN] => 3
> )
> after setParsFromPage - current frame=12
> Sensor was successfully initialized at August 17, 2018, 11:49 pm from
> /etc/autocampars.xml page 0


Regards,
Oleg
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2018-08-17 Thread Linden @ Zone4
I have run '/usr/html/autocampars.php --init', looks like a very similar
error trace to loading http://10.23.33.9/index.php?site=autocampars.php.
Output posted at bottom of GDoc:
https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJLodron0P0zYcpB4/edit?usp=sharing

Linden Mills-Connery
Zone4 Team 
205-820 Main Street
Canmore, AB, T1W2B7
403-401-7215

On 17 August 2018 at 17:53, Oleg  wrote:

> I deleted /etc/autocampars.xml and went to http://10.23.33.9/index.
>> php?site=autocampars.php again to re-generate it which just resulted in
>> an error message. The error message is also in the GDoc.
>>
> That worked with the board I'm testing.
>
> What if you reboot?
> Try from command line?
>
> [root@Elphel353 /root]759# */usr/html/autocampars.php --init*
>> autocampars.php created a new configuration file /etc/autocampars.xml
>> from defaults.
>> Current frame=1266, sleeping to give daemons a chance
>> Current frame=1319, waking up, daemons should be dead already
>> before reset - current frame=0
>> after reset - current frame=2
>> setting COMPRESSOR_RUN=2
>> setting DAEMON_EN=Array
>> (
>>[DAEMON_EN_AUTOEXPOSURE] => 1
>>[DAEMON_EN_STREAMER] => 1
>>[DAEMON_EN_CCAMFTP] => 0
>>[DAEMON_EN_CAMOGM] => 0
>>[DAEMON_EN_TEMPERATURE] => 0
>>[DAEMON_EN] => 3
>> )
>> after setParsFromPage - current frame=12
>> Sensor was successfully initialized at August 17, 2018, 11:49 pm from
>> /etc/autocampars.xml page 0
>
>
> Regards,
> Oleg
>
>
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2018-08-17 Thread Linden @ Zone4
Had a cabling issue from when I dissembled it earlier. Sensor is now
detected. I have updated the GDoc with the new outputs:
https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJLodron0P0zYcpB4/edit?usp=sharing

Firmware s 8.2.15.

I deleted /etc/autocampars.xml and went to
http://10.23.33.9/index.php?site=autocampars.php again to re-generate it
which just resulted in an error message. The error message is also in the
GDoc.

I should also note it is still generating the same 1x1 bimg.

Thanks,

Linden Mills-Connery
Zone4 Team 
205-820 Main Street
Canmore, AB, T1W2B7
403-401-7215

On 17 August 2018 at 15:03, Oleg  wrote:

> So, it does not detect the sensor.
> What's the firmware?
>
>> # cat /etc/issue
>
>
> You might have tried another cable.
> If it's the board - I would check the connector first. Then the power,
> then i2c bus.
> Links to schematics are under the diagrams here
> .
>
> Regards,
> Oleg
>
> On Fri, Aug 17, 2018 at 1:41 PM Linden @ Zone4  wrote:
>
>> Thanks Oleg.
>>
>> 000E64081C8B
>> Here is the requested diagnostics:
>> https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJL
>> odron0P0zYcpB4/edit?usp=sharing
>>
>> 000E64081CA1
>> I will send that one back to you. Will wait until we know if 000E64081C8B
>> needs to go back as well or if I can resolve the issue here.
>>
>> The one with the color tinting is behaving much better.
>>
>> Thanks,
>> ___
>> Support-list mailing list
>> Support-list@support.elphel.com
>> http://support.elphel.com/mailman/listinfo/support-list_
>> support.elphel.com
>
> Best regards,
> Oleg Dzhimiev
> Electronics Engineer
> phone: +1 801 783  x124
> Elphel, Inc.
>
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2018-08-17 Thread Oleg
So, it does not detect the sensor.
What's the firmware?

> # cat /etc/issue


You might have tried another cable.
If it's the board - I would check the connector first. Then the power, then
i2c bus.
Links to schematics are under the diagrams here
.

Regards,
Oleg

On Fri, Aug 17, 2018 at 1:41 PM Linden @ Zone4  wrote:

> Thanks Oleg.
>
> 000E64081C8B
> Here is the requested diagnostics:
>
> https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJLodron0P0zYcpB4/edit?usp=sharing
>
> 000E64081CA1
> I will send that one back to you. Will wait until we know if 000E64081C8B
> needs to go back as well or if I can resolve the issue here.
>
> The one with the color tinting is behaving much better.
>
> Thanks,
> ___
> Support-list mailing list
> Support-list@support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com

Best regards,
Oleg Dzhimiev
Electronics Engineer
phone: +1 801 783  x124
Elphel, Inc.
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2018-08-17 Thread Linden @ Zone4
Thanks Oleg.

000E64081C8B
Here is the requested diagnostics:
https://docs.google.com/document/d/1WfGlWGk0A7zLgAl1EptMntTKoKLJLodron0P0zYcpB4/edit?usp=sharing

000E64081CA1
I will send that one back to you. Will wait until we know if 000E64081C8B
needs to go back as well or if I can resolve the issue here.

The one with the color tinting is behaving much better.

Thanks,

Linden Mills-Connery
Zone4 Team 
205-820 Main Street
Canmore, AB, T1W2B7
403-401-7215

On 17 August 2018 at 12:50, Oleg  wrote:

> Hello Linden,
>
> 000E64081C8B
>> Boots up fine and I can access it on the network fine. The problem is
>> with the interface to the image sensor. All that is available on bimg is a
>> 1px x 1px white image. I have tried connecting this mainboard to a working
>> sensor and there was no change in behavior, still a 1x1 bimg. I have also
>> connected a working mainboard to this sensor and the sensor is working
>> fine. So this points to an issue with the sensor interface on the 
>> 000E64081C8B
>> mainboard.
>>
>
>  telnet or http://192.168.0.9/phpshell.php, then
> 1. ~$ dmesg
>
>> ...
>
> The sensor clock set to 2000
>> removing MRST from the sensor
>> trying MT9P001
>> Found MT9P001 2592x1944 sensor, chip ID=1801
>> trying MT9X001
>> Resetting MT9X001 sensor
>> Reading sensor registers to the shadows:
>> Initializing MT9X001 registers with default values:
>> arch/cris/arch-v32/drivers/elphel/quantization_tables.c:174:init_qtable_head_cache
>>
>
>
> 2. ~$ fpcf -i2cr16 4800 100
> It will just read sensor's registers:
>
>> 004800: 1801   32c  793  a23  1c2  28420   15000
>>000
>> 004810:   50 640400   36   100000000
>>0 40060
>> 004820:   40000200b0  480 1086   10   18
>>   16f0
>> 004830:000008000000 171d
>>5 80414
>> 004840:7033  203 1010 1010 1010   10   a8   10   28   10
>> 120f 1010   14
>> 004850: 80007 80007   160   204 8000741   5a
>> 2d13 41ff 231d
>> 004860:   13   130   1b   1b0000   cf   ef   ed   ea
>>   f100
>> 004870:   ac a700 a700  c00  600 5617 6b57 6b57 a500 ab00 a904 a700 a700
>> ff00 a9000
>> 004880:   22 1f040 1b06 1d080 1806 1a0800000
>>000
>> 004890:  7d0010000000000
>>000
>> 0048a0:00000000000  794  a24
>> 2809   b3 49f5
>> 0048b0: d6f0 ba9c ace6 fcf4 d8b6 fe6e fa7e  f1f  4fd  ac1  dff  c87  fcf
>>  ff7  57d  dea
>> 0048c0:  cff  dfa  3ca  b7a  adb  e97  bfa dcef e7ff dffe 187f 4957 eef3
>> 7f79 6fad 37ff
>> 0048d0: 68bc 7fad fedd fd3e fabb f263 2f7a 95de 3fcb faff ff33 9e9f f779
>> cbf7 8b0d fe6d
>> 0048e0: d9a6 ff3a fd7a 855d e85f a9fc dd4f 6e7f 2ebf fe71 7fef fffe 5cb7
>> 71fd ecfc 11fd
>> 0048f0:0000000010 e0b0 48cf 8068
>> e1180 1801
>
>
> 3. Check if write pointer is changing:
> http://192.168.0.9:8081/pointers
>
> 4. Check if frame number is increasing:
> http://192.168.0.9:8081/meta
>
> 5. http://192.168.0.9/parsedit.php?images=9:3:.2
>
> If 1 & 2 do not fail. Try removing autocampars.xml? Sometimes it gets
> corrupted for some reason.
>
> 000E64081CA1
>> Won't boot at all, no LEDs on Ethernet port or switch it is connected to.
>> I have done a visual inspection and cleaned the Ethernet port pins but no
>> luck. I have also connected a working mainboard to this sensor and the
>> sensor is working fine. So this points to an issue with the 000E64081CA1
>> mainboard.
>>
>
> Hard to say. Need to have a look. I would check the serial console output
> but it requires 10389.
>
> I also have another camera that is producing color tinted images:
>> https://drive.google.com/drive/folders/1bA6VOga8DPdiyhQXq7PWLPg5b7u-
>> 4L03?usp=sharing
>> I had a look and the ZIF connector between the mainboard and sensor *may*
>> have been loose. I am running some more tests on it but wondering if a
>> loose connected would result in those tinted sample images.
>>
>
> It could have, yes.
>
>
>> How should I proceed with the bad mainboards?
>>
>
> You can send them to us - we will inspect them and see what we can do.
>
> Best regards,
> Oleg Dzhimiev
> Electronics Engineer
> phone: +1 801 783  x124
> Elphel, Inc.
>
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com


Re: [Elphel-support] 353 Problem Mainboards

2018-08-17 Thread Oleg
Hello Linden,

000E64081C8B
> Boots up fine and I can access it on the network fine. The problem is with
> the interface to the image sensor. All that is available on bimg is a 1px x
> 1px white image. I have tried connecting this mainboard to a working sensor
> and there was no change in behavior, still a 1x1 bimg. I have also
> connected a working mainboard to this sensor and the sensor is working
> fine. So this points to an issue with the sensor interface on the 000E64081C8B
> mainboard.
>

 telnet or http://192.168.0.9/phpshell.php, then
1. ~$ dmesg

> ...

The sensor clock set to 2000
> removing MRST from the sensor
> trying MT9P001
> Found MT9P001 2592x1944 sensor, chip ID=1801
> trying MT9X001
> Resetting MT9X001 sensor
> Reading sensor registers to the shadows:
> Initializing MT9X001 registers with default values:
> arch/cris/arch-v32/drivers/elphel/quantization_tables.c:174:init_qtable_head_cache
>


2. ~$ fpcf -i2cr16 4800 100
It will just read sensor's registers:

> 004800: 1801   32c  793  a23  1c2  28420   15000
>000
> 004810:   50 640400   36   100000000
>0 40060
> 004820:   40000200b0  480 1086   10   18
>   16f0
> 004830:000008000000 171d
>5 80414
> 004840:7033  203 1010 1010 1010   10   a8   10   28   10
> 120f 1010   14
> 004850: 80007 80007   160   204 8000741   5a
> 2d13 41ff 231d
> 004860:   13   130   1b   1b0000   cf   ef   ed   ea
>   f100
> 004870:   ac a700 a700  c00  600 5617 6b57 6b57 a500 ab00 a904 a700 a700
> ff00 a9000
> 004880:   22 1f040 1b06 1d080 1806 1a0800000
>000
> 004890:  7d0010000000000
>000
> 0048a0:00000000000  794  a24
> 2809   b3 49f5
> 0048b0: d6f0 ba9c ace6 fcf4 d8b6 fe6e fa7e  f1f  4fd  ac1  dff  c87  fcf
>  ff7  57d  dea
> 0048c0:  cff  dfa  3ca  b7a  adb  e97  bfa dcef e7ff dffe 187f 4957 eef3
> 7f79 6fad 37ff
> 0048d0: 68bc 7fad fedd fd3e fabb f263 2f7a 95de 3fcb faff ff33 9e9f f779
> cbf7 8b0d fe6d
> 0048e0: d9a6 ff3a fd7a 855d e85f a9fc dd4f 6e7f 2ebf fe71 7fef fffe 5cb7
> 71fd ecfc 11fd
> 0048f0:0000000010 e0b0 48cf 8068
> e1180 1801


3. Check if write pointer is changing:
http://192.168.0.9:8081/pointers

4. Check if frame number is increasing:
http://192.168.0.9:8081/meta

5. http://192.168.0.9/parsedit.php?images=9:3:.2

If 1 & 2 do not fail. Try removing autocampars.xml? Sometimes it gets
corrupted for some reason.

000E64081CA1
> Won't boot at all, no LEDs on Ethernet port or switch it is connected to.
> I have done a visual inspection and cleaned the Ethernet port pins but no
> luck. I have also connected a working mainboard to this sensor and the
> sensor is working fine. So this points to an issue with the 000E64081CA1
> mainboard.
>

Hard to say. Need to have a look. I would check the serial console output
but it requires 10389.

I also have another camera that is producing color tinted images:
>
> https://drive.google.com/drive/folders/1bA6VOga8DPdiyhQXq7PWLPg5b7u-4L03?usp=sharing
> I had a look and the ZIF connector between the mainboard and sensor *may*
> have been loose. I am running some more tests on it but wondering if a
> loose connected would result in those tinted sample images.
>

It could have, yes.


> How should I proceed with the bad mainboards?
>

You can send them to us - we will inspect them and see what we can do.

Best regards,
Oleg Dzhimiev
Electronics Engineer
phone: +1 801 783  x124
Elphel, Inc.
___
Support-list mailing list
Support-list@support.elphel.com
http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com