Modify

Opened 7 years ago

Closed 7 years ago

Last modified 21 months ago

#4987 closed defect (fixed)

last change in bcm_tag.h is not good for NB4

Reported by: joel_ejc@… Owned by: florian
Priority: normal Milestone: Barrier Breaker 14.07
Component: kernel Version: Trunk
Keywords: Cc:

Description

since this change I can't get images that can be loaded with serial port on my NB4 at CFE level

bcm963xx_flash: CFE bootloader detected                                         
bcm963xx_flash: CFE boot tag found with version 6 and board type 96358VW.       
bcm963xx_flash: Partition 0 is CFE offset 0 and length 10000                    
bcm963xx_flash: Partition 1 is kernel offset 10100 and length be4f6             
bcm963xx_flash: Partition 2 is rootfs offset 40400000 and length 550001         
bcm963xx_flash: Partition 3 is nvram offset 7f0000 and length 10000             
Creating 4 MTD partitions on "bcm963xx":                                        
0x00000000-0x00010000 : "CFE"                                                   
0x00010100-0x000ce5f6 : "kernel"                                                
mtd: partition "kernel" doesn't start on an erase block boundary -- force read-y
0x40400000-0x40950001 : "rootfs"                                                
mtd: partition "rootfs" is out of reach -- disabled                             
mtd: partition "rootfs" set to be root filesystem                               
split_squashfs: error occured while reading from "bcm963xx"                     
0x007f0000-0x00800000 : "nvram"                                                 
TCP bic registered                                                              
NET: Registered protocol family 17                                              
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>                   
All bugs added by David S. Miller <davem@redhat.com>                            
end_request: I/O error, dev mtdblock2, sector 0                                 
SQUASHFS error: sb_bread failed reading block 0x0                               
Trap instruction in kernel code[#1]:                                            
Cpu 0                                                                           
$ 0   : 00000000 10008400 00000000 00000000                                     
$ 4   : 81d18000 00000000 00000001 80237a38      

rootfs offset is wrong
bcm963xx_flash: Partition 2 is rootfs offset 40400000 and length 550001

I revert firmware-uils/src/imagetag.c and bcm_tag.h to version 15200 and no more problem.
bcm963xx_flash: Partition 2 is rootfs offset d0000 and length 720000
trouble in squashfs but maybe it's my configuration

 KAMIKAZE (bleeding edge, r15336) -------------------                           
  * 10 oz Vodka       Shake well with ice and strain                            
  * 10 oz Triple sec  mixture into 10 shot glasses.                             
  * 10 oz lime juice  Salute!                                                   
 ---------------------------------------------------                            
root@OpenWrt:/# SQUASHFS error: lzma returned unexpected result 0x1             
SQUASHFS error: Unable to read fragment cache block [8d690]                     
SQUASHFS error: Unable to read page, block 8d690, size 2ecb                     
SQUASHFS error: lzma returned unexpected result 0x1  

Attachments (1)

patch_nb4 (4.1 KB) - added by joel_ejc@… 7 years ago.
proposed patch for loading an image by CFE with a NB4

Download all attachments as: .zip

Change History (12)

comment:1 Changed 7 years ago by joel_ejc@…

Hi,
I propose a patch which allows loading an image by CFE on my NB4
There is changes in
firmawre-utils/src/imagetag.c
target/linux/brcm63xx/image/Makefile
and
target/linux/brcm63xx/files/drivers/mtd/maps/bcm63xx-flash.c

Joel

Changed 7 years ago by joel_ejc@…

proposed patch for loading an image by CFE with a NB4

comment:2 in reply to: ↑ description Changed 7 years ago by Daniel Dickinson <cshore@…>

Replying to joel_ejc@…:

since this change I can't get images that can be loaded with serial port on my NB4 at CFE level

bcm963xx_flash: CFE bootloader detected                                         
bcm963xx_flash: CFE boot tag found with version 6 and board type 96358VW.       
bcm963xx_flash: Partition 0 is CFE offset 0 and length 10000                    
bcm963xx_flash: Partition 1 is kernel offset 10100 and length be4f6             
bcm963xx_flash: Partition 2 is rootfs offset 40400000 and length 550001         
bcm963xx_flash: Partition 3 is nvram offset 7f0000 and length 10000             
Creating 4 MTD partitions on "bcm963xx":                                        
0x00000000-0x00010000 : "CFE"                                                   
0x00010100-0x000ce5f6 : "kernel"                                                
mtd: partition "kernel" doesn't start on an erase block boundary -- force read-y
0x40400000-0x40950001 : "rootfs"                                                
mtd: partition "rootfs" is out of reach -- disabled                             
mtd: partition "rootfs" set to be root filesystem                               
split_squashfs: error occured while reading from "bcm963xx"                     
0x007f0000-0x00800000 : "nvram"                                                 
TCP bic registered                                                              
NET: Registered protocol family 17                                              
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>                   
All bugs added by David S. Miller <davem@redhat.com>                            
end_request: I/O error, dev mtdblock2, sector 0                                 
SQUASHFS error: sb_bread failed reading block 0x0                               
Trap instruction in kernel code[#1]:                                            
Cpu 0                                                                           
$ 0   : 00000000 10008400 00000000 00000000                                     
$ 4   : 81d18000 00000000 00000001 80237a38      

rootfs offset is wrong
bcm963xx_flash: Partition 2 is rootfs offset 40400000 and length 550001

I revert firmware-uils/src/imagetag.c and bcm_tag.h to version 15200 and no more problem.
bcm963xx_flash: Partition 2 is rootfs offset d0000 and length 720000
trouble in squashfs but maybe it's my configuration

 KAMIKAZE (bleeding edge, r15336) -------------------                           
  * 10 oz Vodka       Shake well with ice and strain                            
  * 10 oz Triple sec  mixture into 10 shot glasses.                             
  * 10 oz lime juice  Salute!                                                   
 ---------------------------------------------------                            
root@OpenWrt:/# SQUASHFS error: lzma returned unexpected result 0x1             
SQUASHFS error: Unable to read fragment cache block [8d690]                     
SQUASHFS error: Unable to read page, block 8d690, size 2ecb                     
SQUASHFS error: lzma returned unexpected result 0x1  

The patch looks good to me; it looks like there is going to be a bunch of special casing having to go on. Perhaps the cfe and 'real' lengths and offsets should default to what they used to be, and we make the current default a 'comtrend' profile, and when people can't flash from web interface we create a profile for them.

I'm suspecting the code from Broadcom was not as universal as I thought. BTW do you have source code for the NB4 I could look at?

comment:3 Changed 7 years ago by joel_ejc@…

Hi,
NB4 is using a adpatation of Boradcom code made by Efixo. For flashing there are two ways :
an internal procedure in the original firmware (upgrade) that used the following format

# hexdump -C -n 256 NB4-R1.5.10-MAIN 
00000000  36 00 00 00 42 72 6f 61  64 63 6f 6d 20 43 6f 72  |6...Broadcom Cor|
00000010  70 6f 72 61 74 69 6f 00  76 65 72 2e 20 32 2e 30  |poratio.ver. 2.0|
00000020  00 00 00 00 00 00 36 33  35 38 00 00 39 36 33 35  |......6358..9635|
00000030  38 56 57 00 00 00 00 00  00 00 00 00 31 00 34 31  |8VW.........1.41|
00000040  38 32 32 36 35 00 00 00  00 00 00 00 00 00 00 00  |82265...........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 33 32  |..............32|
00000060  31 37 30 39 36 39 36 30  00 00 33 31 32 31 31 35  |17096960..312115|
00000070  32 00 00 00 33 32 32 30  32 31 38 31 31 32 00 00  |2...3220218112..|
00000080  31 30 36 31 31 31 33 00  00 00 00 00 00 00 4e 42  |1061113.......NB|
00000090  34 2d 52 31 2e 35 2e 31  30 2d 4d 41 49 4e 00 00  |4-R1.5.10-MAIN..|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000d0  00 00 00 00 00 00 00 00  AA AA AA AA BB BB BB BB  |........!oIm.^r.|
000000e0  CC CC CC CC 00 00 00 00  00 00 00 00 HH HH HH HH  |DJ...........]..|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100

with
AA AA AA AA CRC of image (total file - header)
BB BB BB BB CRC of squashfs part of the image
CC CC CC CC CRC of kernel part of the image
HH HH HH HH CRC of the header
and there is no loading by http interface.

The other way is the command flashimage at de CFE level (serial port)
this command seems to accept old fashion header
with only
loading address of squashfs part and size of squasfs part
loading address of kernel part and size of kernel part
HH HH HH HH CRC of the header
other CRC are not necessary

best regards
Joel

comment:4 Changed 7 years ago by anonymous

The default loading address used by flashimage is BFC10000

comment:5 Changed 7 years ago by joel_ejc@…

comment:6 in reply to: ↑ description Changed 7 years ago by cshore@…

Replying to joel_ejc@…:

bcm963xx_flash: Partition 2 is rootfs offset 40400000 and length 550001
bcm963xx_flash: Partition 3 is nvram offset 7f0000 and length 10000

Can you send me a hex (or hex+ascii) dump of the first 256 bytes of this image. I don't see where the 40400000 length 550001 could be coming from in the code. Unless it is getting mangled by the flashing process on the neufbox, which makes no sense (they don't change the CFE do they?)

Do you do an svn update, or individual file updates?

If the tag is right then it on the kernel side that there is a problem, which makes finding the problem easier. (Something in the /home/daniel/Projects/openwrt-comtrend/build-ref/openwrt/target/linux/brcm63xx/files/include/asm-mips/mach-bcm63xx/bcm_tag.h file perhaps?)

comment:7 follow-up: Changed 7 years ago by joel_ejc@…

This is a header with the current version

$ hexdump -C -n 320 /tftpboot/OPWRT-2304
00000000  36 00 00 00 42 72 6f 61  64 63 6f 6d 20 43 6f 72  |6...Broadcom Cor|
00000010  70 6f 72 61 74 69 6f 00  76 65 72 2e 20 32 2e 30  |poratio.ver. 2.0|
00000020  00 00 00 00 00 00 36 33  35 38 00 00 39 36 33 35  |......6358..9635|
00000030  38 56 57 00 00 00 00 00  00 00 00 00 31 00 32 31  |8VW.........1.21|
00000040  36 32 34 33 36 00 00 00  30 00 00 00 00 00 00 00  |62436...0.......|
00000050  00 00 00 00 30 00 00 00  00 00 00 00 00 00 33 32  |....0.........32|
00000060  31 37 30 39 36 39 36 30  00 00 31 33 37 36 32 36  |17096960..137626|
00000070  30 00 00 00 33 32 31 37  30 39 36 39 36 30 00 00  |0...3217096960..|
00000080  37 38 33 33 33 32 00 00  00 00 00 00 00 00 00 00  |783332..........|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000d0  00 00 00 00 00 00 00 00  a1 20 4c 04 00 00 00 00  |......... L.....|
000000e0  33 32 31 37 38 38 33 31  33 36 00 00 29 6e dc fa  |3217883136..)n..|
000000f0  00 00 00 00 00 00 31 33  37 36 32 35 36 00 00 00  |......1376256...|
00000100  80 01 00 00 80 01 00 00  00 0b f3 d8 5d 00 00 40  |............]..@|
00000110  00 00 04 00 08 19 c5 4b  e9 db a3 68 43 3e 18 4d  |.......K...hC>.M|
00000120  d5 cb f0 2c 1e f1 bd 62  e0 10 d0 3b cb 14 35 1a  |...,...b...;..5.|
00000130  99 1a e4 3a 44 05 78 a9  3f 18 c4 f6 9b 3d ff c3  |...:D.x.?....=..|
00000140

We can see that squashfs address = kernel address = 3217096960
Whe image is loaded by CFE serial port I got

Booting from image (0xbe010000) ...
Code Address: 0x80010000, Entry Address: 0x80010000
Linux kernel CRC error.  Corrupted image?
Download mode ... press any key to stop
key pressed, quit download mode.
web info: Waiting for connection on socket 0.
CFE>

so new version of imagetag.c which imposes squashfs address = kernel address = 3217096960 can't be used.

By using old version of imagetag.c and bcm_Tag.h image can be loaded at CFE level but I think later bcm63xx-mtd.c got a trouble when squashfs address must be defined.

I did my tests with a brand new directory.

Up to now I'm happy with my patch and I can play with lastest version of trunk.

Best regards
Joel

comment:8 in reply to: ↑ 7 Changed 7 years ago by Daniel Dickinson <cshore@…>

Replying to joel_ejc@…:

This is a header with the current version

> 
> $ hexdump -C -n 320 /tftpboot/OPWRT-2304
> 00000000  36 00 00 00 42 72 6f 61  64 63 6f 6d 20 43 6f 72  |6...Broadcom Cor|
> 00000010  70 6f 72 61 74 69 6f 00  76 65 72 2e 20 32 2e 30  |poratio.ver. 2.0|
> 00000020  00 00 00 00 00 00 36 33  35 38 00 00 39 36 33 35  |......6358..9635|
> 00000030  38 56 57 00 00 00 00 00  00 00 00 00 31 00 32 31  |8VW.........1.21|
> 00000040  36 32 34 33 36 00 00 00  30 00 00 00 00 00 00 00  |62436...0.......|
> 00000050  00 00 00 00 30 00 00 00  00 00 00 00 00 00 33 32  |....0.........32|
> 00000060  31 37 30 39 36 39 36 30  00 00 31 33 37 36 32 36  |17096960..137626|
> 00000070  30 00 00 00 33 32 31 37  30 39 36 39 36 30 00 00  |0...3217096960..|
> 00000080  37 38 33 33 33 32 00 00  00 00 00 00 00 00 00 00  |783332..........|
> 00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 000000d0  00 00 00 00 00 00 00 00  a1 20 4c 04 00 00 00 00  |......... L.....|
> 000000e0  33 32 31 37 38 38 33 31  33 36 00 00 29 6e dc fa  |3217883136..)n..|
> 000000f0  00 00 00 00 00 00 31 33  37 36 32 35 36 00 00 00  |......1376256...|
> 00000100  80 01 00 00 80 01 00 00  00 0b f3 d8 5d 00 00 40  |............]..@|
> 00000110  00 00 04 00 08 19 c5 4b  e9 db a3 68 43 3e 18 4d  |.......K...hC>.M|
> 00000120  d5 cb f0 2c 1e f1 bd 62  e0 10 d0 3b cb 14 35 1a  |...,...b...;..5.|
> 00000130  99 1a e4 3a 44 05 78 a9  3f 18 c4 f6 9b 3d ff c3  |...:D.x.?....=..|
> 00000140

We can see that squashfs address = kernel address = 3217096960

That is actually correct. We define the real squashfs addresses for the purpose of mtd in kamikaze in a formerly reserved location (because that's needed in order be able flash from stock firmware using the web interface).

Whe image is loaded by CFE serial port I got

> Booting from image (0xbe010000) ...
> Code Address: 0x80010000, Entry Address: 0x80010000
> Linux kernel CRC error.  Corrupted image?
> Download mode ... press any key to stop
> key pressed, quit download mode.
> web info: Waiting for connection on socket 0.
> CFE>

so new version of imagetag.c which imposes squashfs address = kernel address = 3217096960 can't be used.

This looks like either the kernel is using the CRC from the imagetag (stock CFE for other routers doesn't check that), or the kernel is mangled somehow. Either that the CRC for the entire image is supposed to be just the kernel, but only when using the CFE to flash (otherwise it's the other method you posted). Can you try using the alice profile for imagetag?

imagetag -i vmlinux.lzma.cfe -f root.squashfs.cfe -o output_filename.bin -b 96358GW -c 9635 -e 0x80010000 -l 0x80010000

where vmlinuz.lzma.cfe and root.squashfs.cfe are the appropriate files from the build_dir/linux-xxx/linux-xxx directory (I think...it's the kernel directory under build_dir)

By using old version of imagetag.c and bcm_Tag.h image can be loaded at CFE level but I think later bcm63xx-mtd.c got a trouble when squashfs address must be defined.

I did my tests with a brand new directory.

Up to now I'm happy with my patch and I can play with lastest version of trunk.

I'm just trying to narrow down the reasons for the bug. If the CFE needs to be handled differently than a web upload that is important to know

comment:9 Changed 7 years ago by florian

  • Owner changed from developers to florian
  • Status changed from new to assigned

comment:10 Changed 7 years ago by florian

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed with [16393].

comment:11 Changed 21 months ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.