Debian on Medion NAS MD 86xxx (MitraStar STG-212)

> "memtester" is running fine so this isn't memory r
> elated .. perhaps something in the "coherency" sto
> ff is going wrong ..

Was there a new Ext4 partition in the box when you ran localgen?

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

no new ext4 partition and the rootfs partition is fine
it also cannot be usb stick related .. tested with different USB Sticks (Intenso Basic Line, Sandisk Cruizer Fit, Verbatim Store 'n' Go, Transcend JetFlash 510) and I've seen this on boxes with slightly differend MD numbers

Did the released kernel show the same problem?

Quote

Updated 19 Mar 2017:

Kernel linux-4.4.54-oxnas-tld-1 package was uploaded.

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

I fucked up the NAND (U-boot and everything), but I can get access to a programmer. Could someone give me a dump of U-boot? The first 4 mtd blocks I guess.

I fit a MEDION P89626 with bodhi's Debian a few days ago and it runs stable - in part.

The stable part:
* it has been running for four days now and is still reachable by SSH.
* it was stable enough to compile its own kernel from source
* memtester has been running for several hours without reporting any issues

The not so stable part:
* the kernel build was interrupted 4 times by a cryptic "internal compiler error" - but repeating the build got it finished in the end
* apt-* or aptitude operations more often than not abort with segfaults or report corrupted package lists. Doing apt-get update restores functionality for the next few operations. dmesg shows no errors.

I'm posting here because my symptoms resemble those reported by pengu before.

How could I narrow down the cause of the problem?

kralan,

> The not so stable part:
> * the kernel build was interrupted 4 times by a
> cryptic "internal compiler error" - but repeating
> the build got it finished in the end
> * apt-* or aptitude operations more often than not
> abort with segfaults or report corrupted package
> lists. Doing apt-get update restores functionality
> for the next few operations. dmesg shows no
> errors.
>
> I'm posting here because my symptoms resemble
> those reported by pengu before.
>
> How could I narrow down the cause of the problem?

Look at your RAM. How big is the swap file? it is on an attached HDD?

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

~# free
              total        used        free      shared  buff/cache   available
Mem:         121804       29620        3168         720       89016       85104
Swap:        524116       44088      480028

Swap is on the internal hdd driven by sata_oxnas.

128MB is not much RAM, but I would not expect OOM conditions to go away simply by restarting a kernel build.
I would expect more problems with kernel building and less with apt-* if it were for OOM.
Am I guessing wrong?

kralan,

> 128MB is not much RAM, but I would not expect OOM
> conditions to go away simply by restarting a
> kernel build.
> I would expect more problems with kernel building
> and less with apt-* if it were for OOM.
> Am I guessing wrong?

I was just eliminating possibilities!

I've seen segfaults occur when the file system is corrupted and apt does not know what to do.

Is this rootfs Ext3 or Ext4? have you tried fsck it to see if there is any error?

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

Thank you for sharing your thoughts, bodhi!

The filesystem is ext4, fsck -f does not complain.

kralan,

> The filesystem is ext4, fsck -f does not complain.

I'd suggest you use Ext3 and run it the same way you did (build, dpkg, apt,...). See if the same symptom occur.

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

I got round to transferring the rootfs to ext3 and a quick test looked promising in the beginning, but still failed in the end. Just the intervals between occurrences of the problem might have increased a bit.
I'll start a kernel compilation task overnight and report back.

For reference, long ago I used to compile the kernel on GoFlex Net (Kirkwood) which has 128MB RAM, running kernel 3.x. It took somewhere like 10 to 20 hours. But it did without any problem.

I've not tried to compile any kernel on the Pogo V3 (OXNAS).

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

My kernel build completed, but I had to restart it 5 times.
So, ext3 does not behave any better than ext4.

Stock firmware on the MEDION runs at 750Mhz, yours appears to run at 850MHz.
I'd like to try the slower clock. Can you give a quick pointer where to change it? In the SPL, I guess?

kralan

kralan,

> Stock firmware on the MEDION runs at 750Mhz, yours
> appears to run at 850MHz.
> I'd like to try the slower clock. Can you give a
> quick pointer where to change it? In the SPL, I
> guess?

Sure. I think you need to go back to the older GCC 4 to compile it cleanly. I lost the 700 Mhz SPL binary and have not recompiled because of that (lazy :).

./include/configs/ox820.h

#define CONFIG_PLLA_FREQ_MHZ            850

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

Following instructions here I cloned the oxnas branch from here.

After editing the APLL frequency as described in bodhi's post and installing gcc-4.9 I built u-boot like this:

make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 ox820_config
make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 

but I can't find a file resembling a SPL. Do I need extra configuration or build commands?

Alternatively, does this old package contain a slow SPL?

Can I mix the alternative SPLs freely with recent u-boot?
Is there a way of recovery from flashing a non-working SPL?

kralan Wrote:
-------------------------------------------------------
> Following instructions
> here
> I cloned the oxnas branch from
> here.
>
> After editing the APLL frequency as described in
> bodhi's post and installing gcc-4.9 I built u-boot
> like this:

> make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9
> ox820_config
> make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 
> 

but I can't find a file resembling a SPL.
> Do I need extra configuration or build commands?
>
> Alternatively, does
> this old
> package contain a slow SPL?
>
> Can I mix the alternative SPLs freely with recent
> u-boot?
> Is there a way of recovery from flashing a
> non-working SPL?

Try that old SPL. See if it is slower speed. There is SATA recovery procedure. So even NAND is faulty, you still can boot. In fact, that procedure is a good way to test SPL and uboot before flashing, too.

I will explain the SPL build later.

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

kralan,

Please see the updated README.oxnas.

https://github.com/mibodhi/u-boot-oxnas/blob/2015.10-oxnas/README.u-boot-oxnas

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

bodhi,

thank your for the follow-up.

I have my Medion running stable. Here's what I did:
Setting up as described in this post and preparing the HDD as described here,

make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 ox820

yielded no SPL

make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 ox820_sata

would build a SPL, which would reset at IDE detection,

make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 ox820_ext4

would fail at build with

make[3]: Entering directory '/root/src/u-boot-oxnas/board/ox820'
gcc-4.9  -g  -Os   -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float  -D__KERNEL__ -ffunction-sections -fdata-sections -DCONFIG_SYS_TEXT_BASE=0x64000000 -DCONFIG_SPL_BUILD -I/root/src/u-boot-oxnas/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.9/include -pipe  -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -fstack-usage     -o /root/src/u-boot-oxnas/spl/board/ox820/ox820.o ox820.c -c
ox820.c: In function 'dram_init':
ox820.c:297:30: warning: pointer targets in passing argument 1 of 'get_ram_size' differ in signedness [-Wpointer-sign]
  gd->ram_size = get_ram_size((unsigned long *)CONFIG_SYS_SDRAM_BASE,
                              ^
In file included from ox820.c:1:0:
/root/src/u-boot-oxnas/include/common.h:456:6: note: expected 'long int *' but argument is of type 'long unsigned int *'
 long get_ram_size  (long *, long);
      ^
In file included from /root/src/u-boot-oxnas/include/common.h:901:0,
                 from ox820.c:1:
ox820.c: At top level:
/root/src/u-boot-oxnas/include/bootstage.h:217:33: error: expected identifier or '(' before 'do'
 #define show_boot_progress(val) do {} while (0)
                                 ^
ox820.c:384:6: note: in expansion of macro 'show_boot_progress'
 void show_boot_progress(int val) {
      ^
/root/src/u-boot-oxnas/include/bootstage.h:217:39: error: expected identifier or '(' before 'while'
 #define show_boot_progress(val) do {} while (0)
                                       ^
ox820.c:384:6: note: in expansion of macro 'show_boot_progress'
 void show_boot_progress(int val) {
      ^
ox820.c:337:13: warning: 'set_leds' defined but not used [-Wunused-function]
 static void set_leds(int leds, int blink_count, int blink_delay_msec)
             ^
/root/src/u-boot-oxnas/config.mk:374: recipe for target '/root/src/u-boot-oxnas/spl/board/ox820/ox820.o' failed
make[3]: *** [/root/src/u-boot-oxnas/spl/board/ox820/ox820.o] Error 1
make[3]: Leaving directory '/root/src/u-boot-oxnas/board/ox820'
Makefile:215: recipe for target '/root/src/u-boot-oxnas/spl/board/ox820/libox820.o' failed
make[2]: *** [/root/src/u-boot-oxnas/spl/board/ox820/libox820.o] Error 2
make[2]: Leaving directory '/root/src/u-boot-oxnas/spl'
Makefile:624: recipe for target 'spl/u-boot-spl.bin' failed
make[1]: *** [spl/u-boot-spl.bin] Error 2
make[1]: Leaving directory '/root/src/u-boot-oxnas'
.boards.depend:14: recipe for target 'ox820_ext4' failed
make: *** [ox820_ext4] Error 2

so I patched line 208 in include/bootstage.h to always choose the prototype over the macro:

// #if !defined(CONFIG_SPL_OS_BOOT) && !defined(USE_HOSTCC)
#if 1

I know this is not a solution but just a hack, but it built successfully and the resulting SPL boots ok.

The Medion has been running for a few days now and I could not provoke a segfault, neither by repeated kernel building nor with any aptitude abuse. So it would seem that the clock frequency was to blame.

One question remains:
As per your instruction, I used u-boot.2013, from the oxnas branch, for the SPL.
Is it still true that u-boot.2015 would not build a working SPL?
I'm asking because the updated build instructions and encode.py are in the 2015.10-oxnas branch only.
encode.py doesn't look like a python script, btw.
I'm going to need encode.py to flash a SPL to NAND, right?

Thanks for bearing with me
kralan

kralan,

> I have my Medion running stable.

> The Medion has been running for a few days now and
> I could not provoke a segfault, neither by
> repeated kernel building nor with any aptitude
> abuse. So it would seem that the clock frequency
> was to blame.

Cool! Sorry you had to go through all this. In retrospect, I should have released 2 SPL with different clock, 700 and 850 Mhz. The Pogo V3 is quite stable with 850 Mhz clock, so that's why I never thought it might cause problem. The Medion apparently can not be overclocked.

>
> One question remains:
> As per your instruction, I used u-boot.2013, from
> the oxnas branch, for the SPL.
> Is it still true that u-boot.2015 would not build
> a working SPL?

When I tried during building 2015 u-boot, SPL would not compile. I recall something was hardcoded to gcc 4.x. I tried the symlink approach but it did not compile cleanly either.

> I'm asking because the updated build instructions
> and encode.py are in the 2015.10-oxnas branch
> only.

I've just added that SPL instruction when you asked, so the updated README is on the 2015.10-oxnas branch.

> encode.py doesn't look like a python script, btw.
> I'm going to need encode.py to flash a SPL to
> NAND, right?

Yes, you need to encode it. This was from kref's posted instruction long ago, I can't remember if it was on his GitHub.

If you would like to spend more time trying to compile the SPL using latest gcc, that would be great! Give it a shot and see if you can. I recall that it was too tedious for me to spend too much time trying. So I kept it at gcc 4.x and later forgot all about it :)

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

I found this usable version of encode.py.

Find attached 750Mhz versions of the ox820 SPL for NAND and SATA boot.

Hi kralan,

> Find attached 750Mhz versions of the ox820 SPL for
> NAND and SATA boot.

Thanks, but I meant you could help me by trying to compile SPL on 2015.10-oxnas branch and let me know what you will find.

You should use the later GCC such as 6.x or 7.x, and use NAND option to compile u-boot and SPL at the same time. This is something I wanted to do, but never got around to do it (partly because no user has requested the 2015 SPL here, either).

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

You can use newer compilers by taking patches 410 and 420 from openwrt.

But the rest of the oxnas integration is quite a mess: the board Kconfig (are the choices really mutually exclusive?) is included twice, the u-boot SPL infrastructure is not used, the ext4 function signatures have changed, etc.

Is it really worth the effort getting this old u-boot right?

regards
kralan

kralan,

> But the rest of the oxnas integration is quite a
> mess: the board Kconfig (are the choices
> really mutually exclusive?) is included
> twice, the u-boot SPL infrastructure is not used,
> the ext4 function signatures have changed, etc.
>
> Is it really worth the effort getting this old
> u-boot right?

Probably not. Rebasing u-boot proper to latest mainline is not very difficult, but SPL is quite a different story. So that's why I updated u-boot to 2015, but not SPL.

There is no urgency to update to 2019 u-boot, unless we find something really interesting we want to use in mainline.

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

bodhi,

I forked your u-boot-oxnas and made it build the SPL, for nand or block device, with gcc up to 7.
There may be cleanup to do but I didn't put much effort into that.
Hope you can use it. Find it at github.
I should probably add I am not sure I have done everything "the right way"(tm) and I haven't tested it yet.

thanks
kralan



Edited 1 time(s). Last edit at 04/07/2019 04:54PM by kralan.

kralan,

> I forked your u-boot-oxnas and made it compile the
> SPL, for nand or block device, with gcc up to 7.

Cool!

> Hope you can use it. Find it at
> github.
> I should probably add I am not sure I have done
> everything "the right way"(tm)

:) Thanks!

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

kralan,

A little bit of a hack to get other GCC versions working :) But your patches are straight forward and good, IMO. I'll try to compile with the changes and test it.

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

bodhi,

if you go try it, I should point out:
* The Kconfig logic for selecting the boot source could need some love. The mutually exclusive choice would not cover all use cases, as I gather from the code in include/configs/ox820.h, so I made them individual choices.
* CONFIG_BOOT_FROM_FAT and CONFIG_BOOT_FROM_EXT4 depend on CONFIG_BOOT_FROM_SATA.
* If CONFIG_BOOT_FROM_SATA is selected, but neither CONFIG_BOOT_FROM_FAT nor CONFIG_BOOT_FROM_EXT4, the subsequent stages are loaded from predefined sectors on the disk.
* I don't know whether CONFIG_BOOT_FROM_FAT and CONFIG_BOOT_FROM_EXT4 are mutually exclusive.
* I don't know whether CONFIG_BOOT_FROM_NAND and CONFIG_BOOT_FROM_SATA are mutually exclusive.
* I chose to stay with CONFIG_SPL_BLOCK_SUPPORT, as it was in the old code, but there is also CONFIG_SPL_SATA_SUPPORT, which could be the better choice.

Happy hacking,
kralan

I prepared the HDD with this https://archlinuxarm.org/forum/viewtopic.php?f=55&t=2146&start=80 and it is working, and it is booting uBoot 1.1.2 (Dec 31 2011).

But now i dont know how to boot Debian on it. I tried to boot Openwrt with this instruction https://openwrt.org/toh/cloudengines/pogoplugpro , but it seems that after every reboot the system gets deleted(probably i am just booting it in ram temporarly)

steven,

There are 2 aternatives.

1. Stay with the stock u-boot and the same setup you have. Boot Debian on USB. This is simpler. But you need serial console to be safe.

2. Install new u-boot and create Debian rootfs on USB. This is more advance, but you got new u-boot that can do a lot more than stock.

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