General NAS-Central Forums

Welcome to the NAS community
It is currently Wed Oct 18, 2017 9:37 am

All times are UTC




Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9  Next
Author Message
PostPosted: Sun Feb 15, 2015 10:28 pm 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
micromend wrote:
thank you again for all your effort.....

I have reset my environment to serial and edited the post above, the I/O still works on both interfaces :)

perhaps it is because i am using netconsole instead of clunc


it is a nice opportunity to see if can get an u-boot compiled for 2big2.

clunc is only used by lacie u-boot to interrupt u-boot and switch to netconsole mode.
When it is switch you need a net console window to talk to u-boot via the web interface


Top
 Profile  
 
PostPosted: Sun Feb 15, 2015 10:51 pm 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
it seems this u-boot has an issue

Code:
Marvell>> tftpboot 0x1000000 uImage-u-boot-nwsp2-1
tftpboot 0x1000000 uImage-u-boot-nwsp2-1
Using egiga0 device
TFTP from server 192.168.1.44; our IP address is 192.168.1.252
Filename 'uImage-u-boot-nwsp2-1'.
Load address: 0x1000000
Loading: #################################################################
         #########################
done
Bytes transferred = 459280 (70210 hex)
Marvell>> bootm
bootm
## Booting image at 01000000 ...
   Image Name:   kernel
   Created:      2015-02-15  22:31:00 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    459216 Bytes = 448.5 kB
   Load Address: 00900000
   Entry Point:  00970000
   Verifying Checksum ... OK
OK

Starting kernel ...



this is the output on the serial port of the nwsp2 when loading the uImage

Code:
          _           ____ _
          | |    __ _ / ___(_) ___
          | |   / _` | |   | |/ _ \
          | |___ (_| | |___| |  __/
          |_____\__,_|\____|_|\___|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|  ** LOADER **
 ** MARVELL BOARD: ASTON_NS REV: 0 LE
Hold rear button - long :  FAIL


U-Boot 1.1.4 (Feb 15 2015 - 23:23:19) Marvell version: 3.4.16  LaCie 1.5.24 256M            B

U-Boot code: 06000000 -> 060701D0  BSS: -> 060BDE80

Soc: MV88F6281 Rev 3 (DDR2)
CPU running @ 800Mhz L2 running @ 400Mhz
SysClock = 200Mhz , TClock = 166Mhz

DRAM CAS Latency = 3 tRP = 3 tRAS = 9 tRCD=3
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
undefined instruction
pc : [<00000160>]          lr : [<00000064>]
sp : 05fffed0  ip : 00000010     fp : ffc00000
r10: 06080003  r9 : 0000ffff     r8 : 05ffffcc
r7 : 06070430  r6 : 00000000     r5 : 000005fa  r4 : 00000000
r3 : 0000000f  r2 : 05fffec0     r1 : 01400100  r0 : 00000000
Flags: Nzcv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...


The u-boot that runs ok gives this as output. It seems to fail at initializing the the flash memory
Code:
         | |    __ _ / ___(_) ___
          | |   / _` | |   | |/ _ \
          | |___ (_| | |___| |  __/
          |_____\__,_|\____|_|\___|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__| fvdw vs80
 ** LOADER **
 ** MARVELL BOARD: ASTON_NS LE
Hold rear button - long :  FAIL


U-Boot 1.1.4 (Jan  7 2013 - 21:15:04) Marvell version: 3.4.16  LaCie 1.3.9 256MB             fvdw gpt usbboot vs80

U-Boot code: 00600000 -> 006701D0  BSS: -> 006BDAE0

Soc: MV88F6281 Rev 3 (DDR2)
CPU running @ 800Mhz L2 running @ 400Mhz
SysClock = 200Mhz , TClock = 166Mhz

DRAM CAS Latency = 3 tRP = 3 tRAS = 9 tRCD=3
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
[512kB@f8000000] Flash: 512 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done

CPU : Marvell Feroceon (Rev 1)


I *think* were to look in the code to correct this


Top
 Profile  
 
PostPosted: Sun Feb 15, 2015 11:00 pm 
Offline

Joined: Thu Jan 15, 2015 9:49 pm
Posts: 70
the con command will show the available console devices

Code:
2big2> con
List of available devices:
serial   80000003 SIO
eserial0 00000003 .IO
nc       80000003 SIO stdin stdout stderr
2big2>


that looks like it is setting up the memory space....
over the top of where the u-boot is loaded ?

EDIT: sorry yes the flash SPI is giving the error....
but your output shows much more than mine....


Top
 Profile  
 
PostPosted: Sun Feb 15, 2015 11:23 pm 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
yes it is showing more output

I got this u-boot uImage now running on the nwsp2, the error was in setting initialization of the flash
(notice that u-boot is loaded high up in RAM)
Now recompile it for 2big2 and see if it runs

Code:
           _           ____ _
          | |    __ _ / ___(_) ___
          | |   / _` | |   | |/ _ \
          | |___ (_| | |___| |  __/
          |_____\__,_|\____|_|\___|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|  ** LOADER **
 ** MARVELL BOARD: ASTON_NS REV: 0 LE
Hold rear button - long :  FAIL


U-Boot 1.1.4 (Feb 16 2015 - 00:16:57) Marvell version: 3.4.16  LaCie 1.5.24 256MB

U-Boot code: 06000000 -> 060701D0  BSS: -> 060BDE80

Soc: MV88F6281 Rev 3 (DDR2)
CPU running @ 800Mhz L2 running @ 400Mhz
SysClock = 200Mhz , TClock = 166Mhz

DRAM CAS Latency = 3 tRP = 3 tRAS = 9 tRCD=3
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
fvdw1
fvdw1a
fvdw2
[512kB@f8000000] fvdw3
Flash: 512 kB
Addresses 98M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (98M - 97M): Done

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME]
Waiting for LUMP (3)
no lump receive; continuing
Hit any key to stop autoboot:  0

Reset IDE:
Marvell Serial ATA Adapter
Integrated Sata device found


** Device 0 not available

** Device 1 not available

** Device 0 not available

** Device 1 not available
## Booting image at 00800000 ...
Bad Magic Number
Waiting for LUMP (0)


Top
 Profile  
 
PostPosted: Sun Feb 15, 2015 11:41 pm 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
a new set of files has been sent by e-mail with the correction for flash init

If this doesn't run then maybe the pro_6281 config is not the right one for your device and we could try the nand version...
but that will be for tomorrow, it is bedtime

---edit
interesting to know is what is the exact output of "flinfo" (u-boot command)


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 9:17 am 
Offline

Joined: Thu Jan 15, 2015 9:49 pm
Posts: 70
the files did not run, but I am sure I don't have the NAND version
I think it may be another problem with mainline u-boot....
this time I did exactly like your example, upload with tftp....

i think 1.3.9 may be the better next step, i would probably burn that one to SPI
then I should be able to replicate your tests


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 9:21 am 
Offline

Joined: Mon Jun 16, 2008 10:45 am
Posts: 6048
Quote:
Data Size: 459216 Bytes = 448.5 kB
Load Address: 00900000
Entry Point: 00970000
Where did you get that entrypoint from? It is inside the the image, but hardly. (459216 equals 0x701d0). For u-boot I'd expect the entrypoint to be the same as the load address.


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 11:08 am 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
Mijzelf wrote:
Quote:
Data Size: 459216 Bytes = 448.5 kB
Load Address: 00900000
Entry Point: 00970000
Where did you get that entry point from? It is inside the the image, but hardly. (459216 equals 0x701d0). For u-boot I'd expect the entry point to be the same as the load address.


No the entry point isn't the same as load address.
You can derive it from the makefile where the doimage command is used to build the image for flash or uart, you will seet the difference between the option for load address and execution address.
You can also derive it from the System.map and look where jumpStart is located
Below some snippits from the System.map from this u-boot image
Beginning (notice the address 0x6000000, thats where u-boot will load itself)
Code:
06000000 T _start
06000020 t _undefined_instruction
06000024 t _software_interrupt
06000028 t _prefetch_abort
0600002c t _data_abort
<snip>

the location of jumpStart (notice the offset 0x70000 compared to start address of the the binary)
Code:
<snip>
06056f38 D __u_boot_cmd_end
06070000 t jumpStart
0607003c t romBoot
0607009c t device_5281
060700dc t device_5281_D0
060700dc t device_5281_D1
060700dc t device_5281_D2
06070100 t device_5281_C0
06070124 t device_5281_B0
06070148 t device_5281_A0
06070148 t device_cont
06070180 t not619X
06070188 t __start
0607018c T dramBoot
06070190 t _jumpStart
<snip>


What the uImage contains the u-boot image itself and a 64 bytes header that instructs the bootm command to copy the u-boot image inside the uImage to address 0x900000 and starts execution at 0x970000. u-boot will copy itself to address 0x6000000 and starts execution at 0x6070000


The fact that this u-boot runs on a nwsp2 indicates that either we use the wrong config for this 2big2 or mainline u-boot can not handle the higher memory regions where u-boot copies itself.
You can try if mainline u-boot can read/write there by uploading the uImage not to 0x1000000 but to for example 0xa000000
I saw similar behavior on a 6082 board which has only 16MB of ram but two chips, u-boot was not able to use memory above 8 MB properly. Had to to do with DRAM setup. So if mainline u-boot has a bug this could explain it.
What I can do beside compiling 1.3.9 is compile this u-boot but for loading it for example at address 0x200000 just for testing

But that will be this evening, need to go shopping now, sorry to keep you waiting


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 11:21 am 
Offline

Joined: Thu Jan 15, 2015 9:49 pm
Posts: 70
no rush, I am at work, and will not be able to do anything until tonight anyway :)

if indeed this is a bug in mainline, I will file a new bug report

but I suspect the board needs to be updated, as I posted previously,
now I have the serial connection I see a warning on boot

Code:
Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be removed.

so I think perhaps more things may be broken than just the SATA I already reported

Quote:
4205 CONFIG_SYS_GENERIC_BOARD
4206 This selects the architecture-generic board system instead of the
4207 architecture-specific board files. It is intended to move boards
4208 to this new framework over time. Defining this will disable the
4209 arch/foo/lib/board.c file and use common/board_f.c and
4210 common/board_r.c instead. To use this option your architecture
4211 must support it (i.e. must define __HAVE_ARCH_GENERIC_BOARD in
4212 its config.mk file). If you find problems enabling this option on
4213 your board please report the problem and send patches!


more information here:-
/doc/README.generic-board


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 5:54 pm 
Offline

Joined: Thu Jan 15, 2015 9:49 pm
Posts: 70
fvdw wrote:
---edit
interesting to know is what is the exact output of "flinfo" (u-boot command)


this is an unknown command in mainline u-boot v2015.01

did you want the bdinfo ?

Code:
2big2> bdinfo
arch_number = 0x0000089C
boot_params = 0x00000100
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x10000000
eth0name    = egiga0
ethaddr     = 00:d0:4b:91:xx:xx
current eth = egiga0
ip_addr     = 192.168.1.20
baudrate    = 115200 bps
TLB addr    = 0x0FFF0000
relocaddr   = 0x0FF6A000
reloc off   = 0x0F96A000
irq_sp      = 0x0FB68F3C
sp start    = 0x0FB68F30
2big2>


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 6:54 pm 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
no normally flinfo should list flash info, bdinfo is not the same, is there no command for flash info ?

Anyhow I compiled lacie u-boot 3.5.9-2.0.6
This one contains a specific config for 2big2 spi and nand version

It also produce the image fro flash and uart with extension "kwb" instead of "bin" that could suggest that they could work with kwboot (at least the uart one)
I also made an uImage again, I will mail them in a minute.
The compile went smooth without need to make modifications.
There was one setting I was not sure and that was board revison, I entered 3 it translated that to D
Seems this info is only used in the banner of u-boot.

check your e-mail


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 7:28 pm 
Offline

Joined: Thu Jan 15, 2015 9:49 pm
Posts: 70
I have tested both uart and uImage, I get the same results as before....

should I just put one of these into SPI and prey ?
I can always take the board to work tomorrow and put mainline back....

I can't see any instruction for flash info 'flinfo' listed on help

there is SPI subsystem and i2c subsystem

Code:
2big2> sf
sf - SPI flash sub-system

Usage:
sf probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus
                                  and chip select
sf read addr offset len - read `len' bytes starting at
                                  `offset' to memory at `addr'
sf write addr offset len        - write `len' bytes from memory
                                  at `addr' to flash at `offset'
sf erase offset [+]len          - erase `len' bytes from `offset'
                                  `+len' round up `len' to block size
sf update addr offset len       - erase and write `len' bytes from memory
                                  at `addr' to flash at `offset'
2big2> sf probe
SF: Detected MX25L4005 with page size 256 Bytes, erase size 64 KiB, total 512 KiB


Code:
2big2> i2c
i2c - I2C sub-system

Usage:
i2c bus [muxtype:muxaddr:muxchannel] - show I2C bus info
crc32 chip address[.0, .1, .2] count - compute CRC32 checksum
i2c dev [dev] - show or set current I2C bus
i2c loop chip address[.0, .1, .2] [# of objects] - looping read of device
i2c md chip address[.0, .1, .2] [# of objects] - read from I2C device
i2c mm chip address[.0, .1, .2] - write to I2C device (auto-incrementing)
i2c mw chip address[.0, .1, .2] value [count] - write to I2C device (fill)
i2c nm chip address[.0, .1, .2] - write to I2C device (constant address)
i2c probe [address] - test for and show device(s) on the I2C bus
i2c read chip address[.0, .1, .2] length memaddress - read to memory
i2c write memaddress chip address[.0, .1, .2] length - write memory to i2c
i2c reset - re-init the I2C Controller
i2c speed [speed] - show or set I2C bus speed
2big2> i2c bus
Bus 0:  twsi0
2big2> i2c probe
Valid chip addresses: 3E 50 51 52 53 54 55 56 57 64
2big2>


here is the full list of commands available to me
Code:
2big2> help
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
button  - Return GPIO push button status 0=off 1=on
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dhcp    - boot image via network using DHCP/TFTP protocol
diskboot- boot from IDE device
echo    - echo args to console
editenv - edit environment variable
eeprom  - EEPROM sub-system
env     - environment handling commands
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
false   - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fatsize - determine a file's size
fdt     - flattened device tree utility commands
go      - start application at address 'addr'
help    - print command description/usage
i2c     - I2C sub-system
ide     - IDE sub-system
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loadx   - load binary file over serial line (xmodem mode)
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
showvar - print local hushshell variables
sleep   - delay execution for some time
source  - run script from memory
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true    - do nothing, successfully
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version
2big2>


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 7:52 pm 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
this main line u-boot doesn't seem to have any command to access the flash...
How to write a new u-boot to flash using this u-boot ?

Lets do one test load the uImage at address 0x6000000

but don't start give after uploading the command
Code:
md.b 0x6000000 0x210


Just to see mainline u-boot is capable to readand write to these memory area (0x6000000 is around position 100MB up in the memory.

I also will compile this u-boot for nwsp2 to see if it runs on kirkwood boards


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 8:02 pm 
Offline

Joined: Thu Jan 15, 2015 9:49 pm
Posts: 70
this is how i update the SPI

Code:
fatload usb 0:1 0x800000 new-u-boot.kwb
sf probe 0
sf erase 0 0x50000
sf write 0x800000 0 0x50000
reset


would this be a big enough chunk to write LaCie stock or would i need to increase 0x50000 ?

my tftp transfer shows 0x701CC


Last edited by micromend on Mon Feb 16, 2015 8:08 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 8:06 pm 
Offline

Joined: Wed Mar 18, 2009 11:13 pm
Posts: 773
I see, sorry I missed that I am not so familiar with mainline u-boot.
Be sure you use the right kwb file, so the sf one and not the uart one, the headers differ, an uart image in flash won't run.
The compiler is ready to compile it for nwsp2, give me a minute to test it on a nwsp2


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 6 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group