OpenWrt 18.06.2 install on GoFlex Home - Failure

I followed this guideline
https://openwrt.org/toh/seagate/goflexhome

for installing OpenWrt on a GoFlex Home unit but unfortunately on reboot it didn't boot OpenWrt :frowning: ...

NAS>> reset


<------> -- NAS EXPLORER --
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_.
| | | |___|  _ \ / _ \ / _ \| __|.
| |_| |___| |_) | (_) | (_) | |_.
 \___/    |____/ \___/ \___/ \__|.
 ** QSI BOARD: NAS-PLUG LE.

U-Boot 1.1.4 (Jun 10 2010 - 08:28:13) Marvell version: 3.4.27
QSI NAS version: 1.0.4

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFB00

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz.

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

CPU : Marvell Feroceon (Rev 1)

Streaming disabled.
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  3 ^H^H^H 2 ^H^H^H 1 ^H^H^H 0.

NAND read: device 0 offset 0x100000, size 0x600000

Reading data from 0x100000 --   0% complete.Reading data from 0x10f000 --   1% complete.Reading data from 0x11e800 --   2% complete.Reading data from 0x12e000 --   3% complete.Read
 6291456 bytes read: OK
## Booting image at 00800000 ...
   Image Name:   Linux-2.6.22.18
   Created:      2010-06-17   5:37:59 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2095148 Bytes =  2 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
NAS>> exit
Unknown command 'exit' - try 'help'
NAS>> ~
[EOT]

Any suggestions as to what happened or what to do?

Does this install require a particular U-Boot to be installed for it to work?

Again, you have a few threads open for issues related to this device. Perhaps you should better title the threads; and and place more details in your postings. As a suggestion, perhaps you should make a master thread for seeking solution to a "successful installation on the GoFlex Home."


For anyone who may assist you - this is helpful background knowledge for them:

2 Likes

Not sure what a master thread is, or how to start one.

Although most of the threads were related to a GoFlex Home, they were independent problems. I followed a Wiki guide for 'successfull installation of OpenWrt on the GoFlex Home'. Maybe there is a way of incorporating comments into the wiki if there are mistakes or users encounter problems.

  • a master thread means making 1 thread for the setup of the device
  • if you followed a Wiki, please clarify that your device is working successfully - as that's not clear from Post No. 1
  • you were told by @tmomas in the "Contacting page maintainer" thread - that it's a Wiki, everyone can edit it

The title of the thread makes it clear that my device is not working successfully. I did follow the wiki but the results were not as shown.

Contacting, what I was told may be the maintainer was someone who hasn't used OpenWrt on GoFlex Home for a few years.

I also followed further instructions in the same wiki

This time the section starting

Install u-boot and OpenWrt 18.06.1 into NAND via serial cable and tftp-server

It seems relatively straightforward:-

download from tftp-server u-boot.kwb file to RAM start offset 0x6400000

tftp 0x6400000 u-boot.kwb
or

tftpboot 0x6400000 u-boot.kwb
Bytes transferred = 607044 (94344 hex) ← this number is needed for nand write

erase nand start from 0x0 size 0x100000

nand erase 0x0 0x100000
write nand from RAM start offset 0x6400000 to nand start 0x0 size 0x94344

nand write 0x6400000 0x0 0x94344
reboot device

reset
now you are rebooting in the new u-boot

The problem was that I got:-

NAS>> nand write 0x640000 0x0 0x94344

NAND write: device 0 offset 0x0, size 0x94344
nand_write_ecc: Attempt to write not page aligned data
 0 bytes written: ERROR

Someone mentioned that

0x94344 is not an integer division of 1024 (1K). NAND block is 128K.

but have no idea what that means, and can't help wondering if the instructions actually worked for anyone...

This was somewhat helpful information regarding your issue; and alludes to a basic computing concept you really need to understand in order to proceed!

It took some time for me to realize that you're serious. If you're unclear on what the 1024 error means, I'd suggest learning more about the number's significance in computing, especially if you're going to work with bootloaders.

Regarding the number 1024, see:


Based on the conversation in Contacting page maintainer, I'm guessing that you've based that off a code commit from 2015. I'd advise following the instructions with an understanding of what you're doing in each step.

I religiously followed the instructions in the guide

from the point it says

Install u-boot and OpenWrt 18.06.1 into NAND via serial cable and tftp-server

This was for 18.06.1 which was in 2018 not 2015.

I am still trying to find out who provided the instructions and why I'm getting the NAND write error. The figure I entered is exactly the one specified.

If it is not page aligned should I use 98304 or maybe 95232 instead of 94344?

I think what you're missing is - that people are telling you that you may have to be the user in the community to explore this. Hence, you'd be the one updating the Wiki.

That information isn't helpful in solving your issue.

  • Did you try 18.06.1?
  • Did you try 18.06.2?

Again, this information wasn't helpful in solving your issue. You were shown a contact via the commit log - someone who has knowledge, you admitted that, saying:

You are the person to contact now.


I told you why.

:man_facepalming:

  • OMG! I can mathematically prove you're guessing!!!
  • Please don't brick your device!
  • I think we'd all need to understand how you flashed everything, given the gross miscalculations you're using to flash equipment
  • Those numbers are divisible by 1024 in decimal...I can tell you're missing something...

This isn't decimal, or also-known-as base-10, or also-known-as 'Kindergarten-counting' - not disrespecting you, trying to better define where we learn this (i.e. 0,1, 2, 3...10) method of counting you're incorrectly using.

You need to be totaling these values in hexadecimal, hex, or base-16 (i.e. 0,1,2,3...10,A,B,C,D,E,F or 1,2,3...16), numbers in that notation are usually written, prefixed with "$", "0x" or "x" - or suffixed with "H":

PLEASE READ THIS PARTICULAR LINK ABOVE:

Or as a cheat: you can use the calculator on your computer - in "SCIENTIFIC" and/or "PROGRAMMING" MODES on your computer, flipping from DEC (decimal) to HEX (hexadecimal); and vice versa.

The point I am making is that I followed instructions in a wiki precisely and they didn't work out.

I never managed to contact the person who wrote the wiki. The reference I was given was to some old installation from several years ago and that person has no knowledge of later developments.

I have no idea why I got the NAND write error. If you don't know either just say so.

LOL, I guess you're trolling. I've told you twice about the NAND error; I won't elaborate again. If you're having a difficult time counting in hex, perhaps you should just say so! I'm willing to help someone learn to count in hex, I'm not willing for them to act like I didn't tell them twice how to solve their problem.

I hope for the best for you - in counting flash space in decimal instead of hex.

EDIT: If you decide you want to understand why 98304, 95232, 94344 appear to be decimal instead of hex (and hence won't work), feel free to reply. You will also need to be able to:

  • count in hex; and/or
  • use a Scientific/Programming Calculator in Hex and Decimal modes

in order to proceed to properly flash your device.

We also need to know if that's the original bootloader, and if not, how did you flash it!

By the way:

1024 = 0x400 = x400 = $400 = 400H

So, to directly answer you - it gave you an error because you didn't count in increments of 0x400. You have been incorrectly counting in increments of 0x1024 (which equals 4132 in decimal - and not evenly divisible by 0x400). Hope this helps. If you don't understand where 0x400 comes from, please read the educational material above.

So, you use a number at least 128k (or in hex 0x20000) larger than the image you're flashing. The blocks are 128k, so do not go over bounds mathematically.

 _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06.2, r7676-cddd7b4c77
 -----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------

I managed it, now have to figure out how!

2 Likes

Just a word of causion

If you going to re-write u-boot always make sure you don't have bad blocks in the Nand area where u-boot resides.

1 Like

root@LEDE:/# dmesg | grep -i 'bad'
[ 0.645561] Scanning device for bad blocks
[ 0.662441] Bad eraseblock 114 at 0x000000e40000
[ 0.747850] Bad eraseblock 839 at 0x0000068e0000

or

dmesg | grep "bad PEBs"
[ 2.281770] ubi0: good PEBs: 1014, bad PEBs: 2, corrupted PEBs: 0

Running

dmesg | grep -i 'bad'

Does not show anything...

Still not sure how bad blocks arise, ie what is the life expectancy of flash and is there any way of checking for usage similar to smartctl for disks?

@balanga

Ok, good

I had 2 devices 1 which had and other had none, luckly also my bad block was not where u-boot resides.

As for Nand Flash bad blocks happen over a period of time, and as far as i know there is not a tool like smartctl

You will have to keep checking the logs to see if any new bad block appear, the Nand manages the recovery of some bad blocks

Refer to the pdf for more info

1 Like

http://www.freepatentsonline.com/20180060148.pdf

1 Like

NAND devices can have bad blocks immediately after manufacturing, this is normal. Most other bad blocks develop slowly.

1 Like