Dockstar mods: SATA, SD, 256MB RAM, Compiling/Modding U-boot; kernel DTB...

RE: ECC errors

I've been getting them for years on mtdblock0 & 1. It's always bothered me, but since everything seems to work I've never bothered with it. I don't think any amount of rebooting gets rid of them.

[   70.720733] __nand_correct_data: uncorrectable ECC error
[   70.726179] blk_update_request: I/O error, dev mtdblock0, sector 2040
[   70.732987] __nand_correct_data: uncorrectable ECC error
[   70.738426] blk_update_request: I/O error, dev mtdblock0, sector 2040
[   70.744904] Buffer I/O error on dev mtdblock0, logical block 255, async page read
[   70.755914] __nand_correct_data: uncorrectable ECC error
[   70.761298] blk_update_request: I/O error, dev mtdblock1, sector 0
[   70.767769] __nand_correct_data: uncorrectable ECC error
[   70.773125] blk_update_request: I/O error, dev mtdblock1, sector 0
[   70.779338] Buffer I/O error on dev mtdblock1, logical block 0, async page read
[   71.091512] __nand_correct_data: uncorrectable ECC error
[   71.096994] blk_update_request: I/O error, dev mtdblock0, sector 2040
[   71.103731] __nand_correct_data: uncorrectable ECC error
[   71.109078] blk_update_request: I/O error, dev mtdblock0, sector 2040
[   71.115548] Buffer I/O error on dev mtdblock0, logical block 255, async page read
[   71.126295] __nand_correct_data: uncorrectable ECC error
[   71.131646] blk_update_request: I/O error, dev mtdblock1, sector 0
[   71.138125] __nand_correct_data: uncorrectable ECC error
[   71.143522] blk_update_request: I/O error, dev mtdblock1, sector 0
[   71.149738] Buffer I/O error on dev mtdblock1, logical block 0, async page read

renojim,

> I've been getting them for years on mtdblock0 & 1.
> It's always bothered me, but since everything
> seems to work I've never bothered with it. I
> don't think any amount of rebooting gets rid of
> them.


Thanks for the report!

Note: I have not booted my Dockstar recently. So will see if I got the same error message first.

I might change the kernel configs to move mtdblock to a loadable module, if I cannot see a quick way to get rid of these error messages. Loadable module will work the same, but if we ever want to mount them to do some mods, we will need to do modprobe.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

For faster SMB if you are running a kernel > 5.4 you may want to try the new in kernel CIFS/SMD driver.

Meh, since modern Windows is able to access NFS, I removed samba, it's a performance hog!

Tried different max_block_size values.
- Default is 16384. Pretty slow.
- 65536 does a little beter, but not great
- 262144: 54MB/s
- 1048576: 60MB/s.

I also increased network buffer sizes:

    echo 1048576 > /proc/sys/net/core/wmem_default
    echo 1048576 > /proc/sys/net/core/wmem_max
    echo 1048576 > /proc/sys/net/core/rmem_default
    echo 1048576 > /proc/sys/net/core/rmem_max

But write was still slow, 24-30MB/s and pretty unstable.
Write: 24-30MB/s in all cases.

Then I started to play with /proc/fs/nfsd/threads
I found that the best value was 1!

echo 1 > /proc/fs/nfsd/threads

Read was unaffected, but writing increased to 36MB's, also was more stable (Almost flat).

RAM seems ok with this high values, I don't see any swapping.
top -c1

top - 16:24:03 up 23 min,  1 user,  load average: 0.15, 0.28, 0.39
Tasks:  74 total,   3 running,  71 sleeping,   0 stopped,   0 zombie
%Cpu0  :  1.0 us, 45.3 sy,  0.0 ni,  2.0 id,  1.0 wa,  0.0 hi, 50.7 si,  0.0 st
MiB Mem :    109.0 total,      6.5 free,     20.2 used,     82.3 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.     83.4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1250 root      20   0       0      0      0 R  79.7   0.0   1:51.97 [nfsd]
   11 root      20   0       0      0      0 R   6.9   0.0   0:14.27 [ksoftirqd/0]
   89 root      20   0       0      0      0 S   5.6   0.0   0:14.03 [kswapd0]
 1383 root      20   0    6512   2728   2240 R   1.0   2.4   0:00.24 top -c1
   12 root      20   0       0      0      0 I   0.3   0.0   0:00.85 [rcu_preempt]

Not willing to break my head further, I edited the scripts in /etc/init.d/

/etc/init.d/networking

WND_SZ=1048576
process_options() {
    echo $WND_SZ > /proc/sys/net/core/wmem_default
    echo $WND_SZ > /proc/sys/net/core/wmem_max
    echo $WND_SZ > /proc/sys/net/core/rmem_default
    echo $WND_SZ > /proc/sys/net/core/rmem_max
    ....
}

/etc/init.d/nfs-kernel-server

BS=1048576
THREADS=1
case "$1" in
  start)
                echo $BS > /proc/fs/nfsd/max_block_size
                echo $THREADS > /proc/fs/nfsd/threads
#before this line
                start-stop-daemon --start --oknodo --quiet

Edited 7 time(s). Last edit at 11/16/2021 12:09PM by davidalfa.

Hi David,

1048576 is a bit high. But perhaps that nfsd/threads is what make it possible to run with 1048576. What was the default value before?

Try testing with another Linux box to see if there is any problem.

Good job!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Default threads was 8. Tried 2,4,32...
Anything else than 1 made slower writes.

David,

> Default threads was 8. Tried 2,4,32...
> Anything else than 1 made slower writes.

That makes sense! This is a single core and 128MB RAM box. I am guesssing probably the slowdown was caused by all the context switches going on and a large buffer was allocated for each thread.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Added to Wiki thread:

Quote

Perfornance Tuning & Benchmarks

Pogo ProV3 vs Pogo E02
Another Pogo Pro V3 benchmarks
Network performance - SAMBA - NFS (various protocols)
Pogo Pro V3 Network NFS benchmarks
Kirkwood vs OXNAS network performance (with flow control)
Kirkwood vs OXNAS network performance (flow control turned off )
OXNAS vs OXNAS network performance (flow control turned off)
Samba Tuning
Mount NTFS with big_writes
Increase NFSD max_block_size
Reduce NFSD threads

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I guess if you have the simplified Dreamplug / Appneta m22 (those without SATA), maybe you can mod it without lifting up the CPU... Since dreamplug / m22 has 512MB memory, it would be more powerful.



Edited 1 time(s). Last edit at 11/13/2021 09:43AM by daviddyer.

daviddyer Wrote:
-------------------------------------------------------
> I guess if you have the simplified Dreamplug /
> Appneta m22 (those without SATA), maybe you can
> mod it without lifting up the CPU... Since
> dreamplug / m22 has 512MB memory, it would be more
> powerful.

I forgot what the Appneta looks like. Is it the same form factor as the Dreamplug?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I don't think so, sata seems to be left unconnected too.

https://newit.co.uk/forum/index.php?topic=1991.0

Sata performance isn't good in this Marvell soc, a SSD didn't got over 122MB/s reading, 70MB writing, sata2 is a lot faster than that.
Pretty limited in my opinion, and they aren't cheap either, any modern Linux SBC is cheaper and way more powerful.



Edited 2 time(s). Last edit at 11/13/2021 05:41PM by davidalfa.

The one you posted has eSATA, it was the original version.

There's a shrinked version, only one USB, no SATA, even the serial port is covered (no hole) by the yellow side board

something like this eBay item

eBay item number:274364084475 (completed listing)

These are quite old. But BAD SATA is still better than good usb 2.0 in performance.



Edited 2 time(s). Last edit at 11/13/2021 05:50PM by daviddyer.

Yes. Same. Only names are different.

> 70MB writing, sata2 is a lot faster than that

That's not the right way to compare! Theorical performance can never be achieved. Other factors play into the real performane.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

It's a SSD, Ext4 , no journal... Async, every performance option... Only 7MB/s faster than a 5400rpm 2.5HDD?

David,

> It's a SSD, Ext4 , no journal... Async, every
> performance option... Only 7MB/s faster than a
> 5400rpm 2.5HDD?

What I meant above is we can only get close to the specs, but never achieve it in real scenario.

I know it looks like there is a limitation somewhere. I recall someone got about SATA 90 MB/s writing on these Kirkwbood boxes. But when we get close to 100MB/s, that's pretty good.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Trying to make it tidier, I broke one thin wire, I think it touched something because it never worked again.
I've lifted the CPU two more times, all seems good.
Removing the solder mask is dirty, tedius and dangerous, so use as little as possible!

I switched to sata 0 Port, it works.
Made it permanent, enlarging the usb hole in the side to make room for the data cable and fixing it to the USB chassis
I'm pretty happy that it didn't kill both sata interfaces or the whole soc.

Be very careful when handling them, avoiding sharp bends.

I made a picture gallery without Dockstar stuff here:
https://postimg.cc/gallery/6KYZV5B

nfsd crashed randomly with socket errors, lowered network window size to 262144 and nfs block size to 524288, seems ok now.



Edited 2 time(s). Last edit at 11/16/2021 12:12PM by davidalfa.

> nfsd crashed randomly with socket errors, lowered
> network window size to 262144 and nfs block size
> to 524288, seems ok now.

Yes. That's expected when the max_block_size is too high.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Just for curiosity, it seems the memory could be doubled in any Kirwood box, the biggest DDR2 chip is 256MB (2Gbit).

Researching compatible parts, I found some options:

- MT47H128M16RT-25E
- A3R2GE43JBF-8E
- AS4C128M16D2-25BCN
- W972GG6KB-25

All seem to be a direct replacement, they have the same timings (400MHz 5-5-5).



Edit: I found a cheap one! Only $5!
W972GG6KB-25

https://www.ebay.com/itm/392364263006

Also here (Too cheap, looks fake)
https://a.aliexpress.com/_vXq0sC

The memory layout is slightly different, has 8 banks instead 4.

Bodhi, do you know if U-boot/kernel autodetect that or if must be hardcoded at compile time?

BA0, BA1 and BA2 are routed, so no hardware modding is needed.
If it's as easy as it looks, I think I will try!

This is just a (pretty crazy) idea. I wonder if I can make a little PCB that sits over the original RAM footprint and extend it to connect two RAM chips. Won't be easy...
CE1 (Chip Enable) and ODT1 (On-Die Termination 1) would need to be routed from under the CPU, as the unused signals aren't routed (A14, CE1, CE2, CE3, M_ODT1) so modding is needed to enable more chips.
But maybe 512MB could be enabled, and Up to 1GB in the best case.
Also, this would allow to use interleaved mode, boosting the RAM performance.



Edit2: Curiosly, I had a dead set TV box for parts, with the same memory type (different chip, same memory layout, 64M x16).

Wanting to see what was under the dockstar RAM, I lifted it and replaced the RAM with the TV box one, was pretty easy and everything worked flawlessly.

I added few pictures to the dockstar folder showing the traces under the RAM.
Bought the 256MB chip, I'm gonna try!



Edited 11 time(s). Last edit at 11/16/2021 03:14PM by davidalfa.

David,


> Bodhi, do you know if U-boot/kernel autodetect
> that or if must be hardcoded at compile time?

Yes, it is hardcoded in u-boot. Most Kirkwood u-boot define 2 banks, you could populate 1 bank, but the extra RAM will not be recognized by u-boot. But it does not matter, as long as it runs OK.

In the kernel, it is hardcoded in the DTS. The bootargs is where you can overide the memory size that u-boot pass to the kernel. The bootargs also overide what's in the DTS.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I'm not even thinking on modifying the board to add more memory chips.
Routing high speed bga parts is no joke!
For now I will only replace the existing memory with the 256MB one.

The original Nanya NT5TU64M16DG-AC also uses 8 banks, the difference comes in the internal row addressing, 13bit -> 14 bit, everything else is (or seems) the same.

My kernel/uboot knowledge is not great, how would I override the kernel settings to use that extra address bit?

Browsing the source code is exhausting if you don't know where or what to search, I'd appreciate some basic guidelines, ex. which files set the RAM config, where do I get the Kernel/patches/dts/dtb sources and how to compile, if any special steps are needed.

I'd like to be able to compile it instead depending on someone doing it for me every time!
I've compiled kernels few times, sometimes it's straight forward (make device_defconfig; make), but others it's a complete nightmare, you get overwhelmed by thousands of errors, almost impossible to fix unless you know the code, and all you get is the typical instructions saying "download and compile", so there's little to do.
Maybe a wrong package version, or too new gcc, but the code doesn't always check that...!

Thanks!



Edited 4 time(s). Last edit at 11/16/2021 05:14PM by davidalfa.

> For now I will only replace the existing memory
> with the 256MB one.

Even that, what I said above still applies. If u-boot hardcoded number is 128MB, then only that much will be recognized. This is due to the SoC requirement. RAM is always the first thing the SoC BootROM figures out before starting u-boot proper, and it is hardcoded in the u-boot header image. So you would need to patch and rebuild to get it to recognize 256MB RAM transparently.

> My kernel/uboot knowledge is not great, how would
> I override the kernel settings to use that extra
> address bit?

For starter, just boot normally and see how much RAM Linux kernel thinks the board has. And then if it is not right, use the bootargs mem=256M to see if it can recognize the capacity.

https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html


> Browsing the source code is exhausting if you
> don't know where or what to search, I'd appreciate
> some basic guidelines, ex. which files set the RAM
> config, where do I get the Kernel/patches/dts/dtb
> sources and how to compile, if any special steps
> are needed.

> I'd like to be able to compile it instead
> depending on someone doing it for me every time!
> I've compiled kernels few times, sometimes it's
> straight forward (make device_defconfig; make),
> but others it's a complete nightmare, you get
> overwhelmed by thousands of errors, almost
> impossible to fix unless you know the code, and
> all you get is the typical instructions saying
> "download and compile", so there's little to do.

Usually when you see that many errors, it is because the kernel source is too old comparing to the Debian version you are at. Typically, if you get the latest Linux source code, and patches that matches that version (like I provided in the release thread https://forum.doozan.com/read.php?2,12096), and install the latest toochain, then the build should be quite easy.

Building u-boot and/or kernel is a subject that I prefer not to talk about, because it could get very time consuming for me. Having only a cetain amount of free time, I have to choose the battles, my first priority is helping troubleshooting problem in installation and booting. Next is building latest kernel and/or u-boot. That's about all I can do.

But the question like you have, e.g. how to get the kernel to use the new RAM, I'll be glad to answer. This is the sequence:

- u-boot recognizes the RAM capacity (hardcoded in its image header).
- u-boot starts the kernel, and pass this info to the kernel in a pre-dertermined memory area (true for all ARM architecture SoCs).
- Linux kernel determines the amount of RAM the box have by going through this, in order:

a. bootargs
b. info passed by u-boot
c. DTS

So to overide what u-boot thinks it has, you would need to use bootargs. I think it should work for most Kirkwood SoC boxes.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I know this is a lot to read, sorry! I'm using it to quickly access my own findings.
I already found everything I needed: You can go to the end of the post.

I already compiled your uboot (as stated in the 1st post), but I wanted to know where the hardcoded memory is defined, it must be a simple number somehere in the code!

I tried setting the memory size to 64M, but linux shows the same: 109M.

setenv bootargs 'mem=64M,console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'

top

MiB Mem :    109.0 total,

In any case, lowering the ram should be easy, as it simply limits the addressing, everything over it won't be used, but the controller has the capability.

However, I think accessing more ram won't be that easy, the dram controller needs to be configured to correctly address the ram.
Does the kernel figure and adjust that? Or it take the dram controller "as it is" from uboot?

Uboot usually uses some define like SDRAM_SIZE, PHYS_SDRAM_SIZE, etc, to set the ram size, but I found nothing like that in kirkwood code.
I make recursive searchs with grep to find everything containing that word in the whole uboot folder:

grep -Rls SDRAM

These are my findings:

arch/arm/mach-kirkwood/include/mach/config.h

/*
 * By default kwbimage.cfg from board specific folder is used
 * If for some board, different configuration file need to be used,
 * CONFIG_SYS_KWD_CONFIG should be defined in board specific header file
 */

board/Seagate/dockstar/kwbimage.cfg

DATA 0xFFD01410 0x0000000d	#  DDR Address Control
# bit1-0:   00, Cs0width=x8
# bit3-2:   11, Cs0size=1Gb
# bit5-4:   00, Cs1width=nonexistent
# bit7-6:   00, Cs1size =nonexistent
# bit9-8:   00, Cs2width=nonexistent
# bit11-10: 00, Cs2size =nonexistent
# bit13-12: 00, Cs3width=nonexistent
# bit15-14: 00, Cs3size =nonexistent
# bit16:    0,  Cs0AddrSel
# bit17:    0,  Cs1AddrSel
# bit18:    0,  Cs2AddrSel
# bit19:    0,  Cs3AddrSel
# bit31-20: 0 required

The comments are wrong (I guess it's copy&paste), 0x0D is binary 1101:
- Cs0Width 01: x16 memory
- Cs0Size 11: 1Gb (Setting this to 00 should set the memory size to 2Gb, the addressing is automatically adjusted)

So all it takes to enable 256MB is this:

DATA 0xFFD01410 0x00000001	#  DDR Address Control
# bit1-0:   01, Cs0width=x16
# bit3-2:   00, Cs0size=2Gb

I'm checking the soc registers here (DRAM: page 398):
http://natisbad.org/NAS/refs/Marvell/FS_88F6180_9x_6281_OpenSource.pdf

0x01410

Bit   Field     Type/Init   Val   Description
1:0   CS0Width  RW          0x0   SDRAM Address Select

Determines what address bits to drive on M_A[14:0] and M_BA[2:0] during
activate and command phases (row and column addresses).
NOTE: See DDR SDRAM Address Multiplex.
0 = Reserved
1 = x16


Bit   Field     Type/Init   Val   Description
3:2   CS0Size   RW          0x1   SDRAM Device Configuration

Effects SDRAM row and column address bits multiplexing. See DDR SDRAM
Addressing.
0 = 2 Gb: when supported
1 = 256 Mb
2 = 512 Mb
3 = 1 Gb

Uboot seems to take the memory size from size from here:

arch/arm/mach-mvebu/cpu.c

/*
 * This function initialize Controller DRAM Fastpath windows.
 * It takes the CS size information from the 0x1500 scratch registers
 * and sets the correct windows sizes and base addresses accordingly.
 *
 * These values are set in the scratch registers by the Marvell
 * DDR3 training code, which is executed by the BootROM before the
 * main payload (U-Boot) is executed. This training code is currently
 * only available in the Marvell U-Boot version. It needs to be
 * ported to mainline U-Boot SPL at some point.
 */
static void update_sdram_window_sizes(void)
{
	u64 base = 0;
	u32 size, temp;
	int i;

	for (i = 0; i < SDRAM_MAX_CS; i++) {
		size = readl((MVEBU_SDRAM_SCRATCH + (i * 8))) & SDRAM_ADDR_MASK;
		if (size != 0) {
			size |= ~(SDRAM_ADDR_MASK);

			/* Set Base Address */
			temp = (base & 0xFF000000ll) | ((base >> 32) & 0xF);
			writel(temp, MVEBU_SDRAM_BASE + DDR_BASE_CS_OFF(i));

These registers are in the page 390 of the manual.

Hmm.. A lot of questions.
Is the ram size already set by the BootROM before u-boot is executed?
If so, how is it reading and applying the values set in from kwbimage.cfg?
Is some additional data being appended to the uboot image?

The simplest way is to compare two files.
Let's compile two uboot versions, changing the RAM size and quickly finding the differences...seems easy. Nope!
Comparing the files showed no difference, only the build date!

So I analyzed your u-boot.kwb file... There's a 512-byte header before the u-boot code, with the init values!

0x0068:   10 14 D0 FF 0D 00 00 00

Clearly in Little-Endian, it makes sense after reversing:

FFD01410 0000000D

Clearly:
DATA 0xFFD01410 0x0000000d	#  DDR Address Control

Checking Makefile, I was able to generate the kwb file after running:

make u-boot.kwb

Wanting to understand the header structure and know if it had any checksum, I analyzed tools/kwimage code.
The unsecure header structure is very simple:

- Bytes 0-31 are the main header (boot source, etc). Byte 31 is the sum of bytes 0-30.
- Bytes 32-511 are the "extended" header, with the init values. Byte 511 is the sum of bytes 32-510.

To change DRAM bank 0 size from 1Gbit to 2Gbit, only 2 bytes need to be patched:
- 0x006C: 0x01
- 0x01FF: 0xF4

Simple as reading mtd0, patching the bytes and writing it back, and definitely a lot easier than compiling everything.

That's what I'll do when the DRAM arrives!



Edited 24 time(s). Last edit at 11/17/2021 10:19AM by davidalfa.

David,

>
> Wanting to understand the header structure and
> know if it had any checksum, I analyzed
> tools/kwimage code.

It does have a checksum.

> writing it back, and definitely a lot easier than
> compiling everything.

True, it is a hack that should work, quick and dirty (of course, the right way is to change the code).

With the hacking method, you could use binwalk to see where the header end. Extract the header and the payload. Tweak the header, and recompute the checksum, and put them back to one image. This is what we would do with some stock u-boots when we don't have GPL source code.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote

Is the ram size already set by the BootROM before u-boot is executed?

Yes. BootROM will determine the RAM size before u-boot starts. This is necessary to load u-boot image to memory. And a modern u-boot also relocate itself to a proper place.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Yes, I also prefer properly coding it, but compiling for embedded systems is usually a huge mess.
Given they are simple values, not cpu instructions, it's plain easy.

Well, I made a very stupid error, and spend few hours recovering it with JTAG.
First, me, Mr. Stupid, used net console, instead a solid serial port connection
then used u-boot to modify the nand: nand read, nand erase, mw... Linux+ssh would have been much safer.
Before running nand write, I made a terrible mistake: I pressed Ctrl+C in a Linux terminal, but the focus was on the netcat window,... killed!
The Dockstar was closed, so no way to connect it using the serial port. Trying to remove the cover, the power plug slipped out.

So it was a happy OpenOCD afternoon trying to to recover it.
For the jtag interface, I used a STM32 blue pill and versaloon firmware: https://github.com/zoobab/versaloon
It's living again! Will make another post about the JTAG...

I modified the said bits, but for 64M (So I can confirm that it works).
I set the memory bits to 0x9 (Binary 1001: 512Mbit, 16 bit). Fixed the checksum to 0xFC. Flashed back and resetted.

U-boot worked, but kept reporting 128MB.
As expected, the kernel tried to boot, but it likely tried to access the 128MB and died without giving any error message.

Ohh, I see. The memory size is also hardcoded! (reg 0x1504)

DATA 0xFFD01504 0x07FFFFF1	# CS[0]n Size
# bit0:    1,  Window enabled
# bit1:    0,  Write Protect disabled
# bit3-2:  00, CS0 hit selected
# bit23-4: ones, required
# bit31-24: 0x07, Size (i.e. 128MB)

So also this address needs to be modified with the correct value:

0x00B7:    0F(256M)    07 (128MB)    03(64MB)

To change it from u-boot (This time it was a must, as linux no longer booted):

nand read 0x100000 0 0x20000
nand erase 0 0x20000
mw.b 0x10006C 0x0D
mw.b 0x1000B7 0x07
mw.b 0x1001FF 0x00
nand write 0x100000 0 0x20000

I'm not even using binwalk for such simple task: I use HxD editor, paste the bytes and run the checksum verification, takes seconds.

Now I tried again for 64MB:

0x006C: 09
0x00B7: 03
0x01FF: F8

I'm also leaving the values for 256MB for the future:

0x006C: 01
0x00B7: 0F
0x01FF: FC

And finally!

U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:17:19 -0700)
Seagate GoFlex Net

SoC:   Kirkwood 88F6281_A0
DRAM:  64 MiB

But the kernel doesn't boot.
mem=64M does nohing, so maybe that option is disabled in the kernel?
So now, it seems I need to forcibly edit the DTS, changing that value to the desired value.

	memory {
		device_type = "memory";
		reg = <0x00000000 0x8000000>;
	};

However, it depends on other files:

#include "kirkwood.dtsi"
#include "kirkwood-6281.dtsi"

Here it comes the question ...where can I get the code that? Otherwise the DTS file is simply useless for me?
I found nothing in your github. It's oficially supported by Debian?

BTW, I tried raw disk access, much faster writes:

root@debian:~# dd if=/dev/zero of=/dev/sda2 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.6482 s, 84.9 MB/s

Also, I tried a "reserved" cpu speed setting: Yet to see the stability, now it's working at 1.6GHz.
Edit: Unstable, random errors, some times not booting. 1.5GHz is doing fine.



Edited 3 time(s). Last edit at 11/18/2021 02:17AM by davidalfa.

davidalfa Wrote:

>

> U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:17:19
> -0700)
> Seagate GoFlex Net
> 
> SoC:   Kirkwood 88F6281_A0
> DRAM:  64 MiB
>

>
> But the kernel doesn't boot.

Post the log of this session (from the u-boot banner, until the kernel stops booting).


> Here it comes the question ...where can I get the
> code that? Otherwise the DTS file is simply
> useless for me?
> I found nothing in your github. It's oficially
> supported by Debian?

https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-dockstar.dts

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:17:19 -0700)
Seagate GoFlex Net

SoC:   Kirkwood 88F6281_A0
DRAM:  64 MiB
WARNING: Caches not enabled
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Reset IDE: Bus 0: OK Bus 1: not available
  Device 0: Model: WDC WD10JPVX-22JC3T0 Firm: 01.01A01 Ser#:  WD-WX61E14X1081
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0
loading envs from usb 0 ...
** Bad device usb 0 **

Partition Map for IDE device 0  --   Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     2048            20969472        e9df59ed-01     83 Boot
  2     41945088        4194304         e9df59ed-02     82
  3     46139392        1907382272      e9df59ed-03     83
running scan_disk ...
Scan device usb
device usb 0:1
** Bad device usb 0 **
device usb 1:1
** Bad device usb 1 **
device usb 2:1
** Bad device usb 2 **
device usb 3:1
** Bad device usb 3 **
Scan device ide

Reset IDE: Bus 0: OK Bus 1: not available
  Device 0: Model: WDC WD10JPVX-22JC3T0 Firm: 01.01A01 Ser#:  WD-WX61E14X1081
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
device ide 0:1
1 bytes read in 41 ms (0 Bytes/s)
Found bootable drive on ide 0
loading uImage ...
5472984 bytes read in 923 ms (5.7 MiB/s)
loading uInitrd ...
9710349 bytes read in 1649 ms (5.6 MiB/s)
loading DTB /boot/dts/kirkwood-goflexnet.dtb ...
11457 bytes read in 63 ms (176.8 KiB/s)
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-5.14.9-kirkwood-tld-1
   Created:      2021-11-12  12:47:52 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5472920 Bytes = 5.2 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-5.14.9-kirkwood-tld-1
   Created:      2021-11-12  12:48:02 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    9710285 Bytes = 9.3 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01c00000
   Booting using the fdt blob at 0x1c00000
   Loading Kernel Image ... OK
   Loading Ramdisk to 031ca000, end 03b0cacd ... OK
   Loading Device Tree to 031c4000, end 031c9cc0 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

And that's all.

David,

> Starting kernel ...

Make sure you have earlyprintk=serial in your bootargs so it will show more than just hang there.

printenv set_bootargs

and if earlyprintk is not in the output,

setenv set_bootargs 'setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts earlyprintk=serial'

and then

boot

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Same (Silent).
Interestingly, I found that when setting 256MB in uboot, the kernel does detect it:
top

MiB Mem :    235.9 total,

Of course, using all that ram will crash the system, I'm simply being lucky due the low memory usage.

So after all, it seems no more steps are needed.