I am following your discussion and wondering if the DTS file would be enough to get the kernel work with our devices (with all functionalities, usb, rtc, etc.).

In the old sources (kernel 2.65) released by Seagate there are plenty of additional drivers for the hardware. For example there are drivers added for RTC (cns3xxx-rtc), GPIO (cns3xxx-gpio), I2C (cns3xxx-i2c) and so on. After compilation some of them become part of the uImage, and some are loaded at boottime as modules.

So even if we manage to prepare the DTS file, I think we still would need to fit those drivers to the kernel source (as they are not included in the mainline), right? What I understand the DTS file is only the instruction for the kernel which drivers to load, but those drivers need to be present in the kernel. The DTS file really substitutes the device-specific initialization files in arch/arm/mach- folders, but drivers are needed anyways.

Bohdi, in your opinion should we first try to create a DTS file or maybe better try to fit some drivers to the current kernel that boots but have some missing stuff? I mean the kernel that blackdevil gave link to: https://github.com/KL-Yang/seagate_central_linux.

tommy,

> think we still would need to fit those drivers to
> the kernel source (as they are not included in the
> mainline), right? What I understand the DTS file
> is only the instruction for the kernel which
> drivers to load, but those drivers need to be
> present in the kernel. The DTS file really
> substitutes the device-specific initialization
> files in arch/arm/mach- folders, but drivers are
> needed anyways.

That's correct. Currently in mainline, looks like there are enounh CNS3xxxx supports to run this box, such as USB, PCI, SATA. I have not looked for other areas. They might be also available already. If they are not, then drivers from old kernel needed to be adapted to the FDT infrastructure (the same drivers but need to exposed FDT data structure). That's why I mentioned that there might be quite a bit of works to be done to complete the transition to FDT.

And you might be right also, that the generic mainline drivers might not be suitable for CNS3xxx. But that we will see.

> Bohdi, in your opinion should we first try to
> create a DTS file or maybe better try to fit some
> drivers to the current kernel that boots but have
> some missing stuff? I mean the kernel that
> blackdevil gave link to:
> https://github.com/KL-Yang/seagate_central_linux.

It is best to boot with a set of core functionalities first using mainline. And add each of the other functionalities as we need more.

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



Edited 1 time(s). Last edit at 03/06/2018 05:53PM by bodhi.

I've upload the linux-4.14.24-cns3xxxx-tld-1 package. Please see 1st post for download link.

This is an experimental release. So if it boots then it is a big step forward :)

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



Edited 2 time(s). Last edit at 03/07/2018 12:25AM by bodhi.

I got a segfault in the modprobe phase:

physmap platform flash device: 08000000 at 10000000
Unable to handle kernel paging request at virtual address b6e1f91d
pgd = cf9d8000
[b6e1f91d] *pgd=0ec37831, *pte=0f0e318f, *ppte=0f0e3a2e
Internal error: Oops: 17 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 422 Comm: modprobe Not tainted 4.14.24-cns3xxxx-tld-1 #1
Hardware name: Cavium Networks CNS3420 Validation Board
task: cfaf4ca0 task.stack: cfa66000
PC is at v6wbi_flush_user_tlb_range+0x28/0x48
LR is at change_protection_range+0x2a4/0x30c
pc : [<c001ab30>]    lr : [<c00c49bc>]    psr: 20000013
sp : cfa67eb8  ip : 00000000  fp : cfa67f14
r10: cf9d8020  r9 : 00440000  r8 : 00000000
r7 : 00000001  r6 : 00440000  r5 : cec1d100  r4 : 0556a34f
r3 : 00000001  r2 : 00100871  r1 : 00440000  r0 : 0043f001
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 00c5787d  Table: 0f9d8008  DAC: 00000051
Process modprobe (pid: 422, stack limit = 0xcfa66188)

Full boot log is attached. Note that I'm booting everything off tftp.

Mark

Thank you for your kernel bodhi!
first i tryed to boot the zImage from hdd, but it say wrong image format.

Whitney # scsi init;ext2load scsi 0 0x8000000 /zImage; bootm 0x8000000     

Initialize SCSI
AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part 
set feature error!
scanning bus for devices...
Supprt LBA48 addressing.
timeout exit!
  Device 0: (1:0) Vendor: ATA Prod.: HGST HTS725050A7 Rev: GH2Z
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)

3349200 bytes read
enter do_eth_down!!!
Wrong Image Format for bootm command
ERROR: can't get kernel image!

after that I used

mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux kernel" -d zImage-4.14.24-cns3xxxx-tld-1 uImage

to uncompress the zImage, but it wont boot and stops with "Starting kernel ..."

## Booting kernel from Legacy Image at 08000000 ...
   Image Name:   Linux kernel
   Created:      2018-03-07  21:52:04 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3349200 Bytes =  3.2 MB
   Load Address: 80008000
   Entry Point:  80008000
   Loading Kernel Image ... OK
OK

Starting kernel ...

Mark, how did you get the uInitrd-4.14.24?

I think i also have to load all 3 files (uImage/zImage, uInitrd, dtb) and not just uImage :-)

@Mark,

Excellent! So we know the kernel has started and run. You've got pretty far :) SATA seems to work too.

I will take a closer look at the log.

@blackdevil,

This stock u-boot has FDT supports, as Mark verified in his log. The boot command is

Whitney # bootm 0x2000000 0x5100000 0x5000000

So you can boot with the DTB separately, and should boot with with uImage and uInitrd.

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

seems good. But where do I get the uInitrd file? It it is not in the your start post isnt it?

blackdevil Wrote:
-------------------------------------------------------
> Mark, how did you get the uInitrd-4.14.24?
>
> I think i also have to load all 3 files
> (uImage/zImage, uInitrd, dtb) and not just uImage
> :-)

I load uInitrd via tftp like the rest.
Here are the steps I used:

setenv bootargs mem=256M console=ttyS0,38400; setenv arcNumber 2776
tftpboot 0x2000000 disks/seagate/uImage-4.14.24
tftpboot 0x5100000 disks/seagate/uInitrd-4.14.24
tftpboot 0x5000000 disks/seagate/cavium-cns3xxx.dtb
bootm 0x2000000 0x5100000 0x5000000

I am wildly guessing at what memory address I should be using for these, and I'm still not sure why I can't seem to use my Blackarmor 440's full 512 MB of ram but it is what it is.

I am planning to try booting from a 2.5" drive via USB next, just to rule out the tftp part.

Mark

Hi Mark,

Please try:

1. With a USB drive attached, and a HDD attached. Power up, interrupt serial console and list the envs and also the commands available.

bdinfo
usb reset
ide reset
printenv
help

2. And then set up the envs to boot the same way you did. Boot.

Please post the boot log here in code tags.

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



Edited 1 time(s). Last edit at 03/07/2018 04:57PM by bodhi.

blackdevil Wrote:
-------------------------------------------------------
> seems good. But where do I get the uInitrd file?
> It it is not in the your start post isnt it?

You would create it and the uImage the same way as in other kernels. For example, the Kirkwood kernel:
https://forum.doozan.com/read.php?2,12096

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-4.15.2-kirkwood-tld-1 -d vmlinuz-4.15.2-kirkwood-tld-1 uImage 
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-4.15.2-kirkwood-tld-1 -d initrd.img-4.15.2-kirkwood-tld-1 uInitrd

Note that the address for uImage needs to be adjusted for CNS3xxx if needed. The uInitrd is the same for all architecture, ie. 0x00000000.

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



Edited 1 time(s). Last edit at 03/07/2018 04:58PM by bodhi.

Mark's log showed a familiar kernel panic. I think the kernel config needs more switches enabled for this ARM11 specifically.

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

This model has no IDE interfaces, only SATA. Also, I've been unsuccessful in getting U-Boot to recognize any USB hard drive or stick.

U-Boot 2008.10-mpcore (Nov 11 2012 - 15:04:27)
Whitney model:(ELCAPITAN) release v1.2-beta2

CPU: Cavium Networks CNS3000
ID Code: 410fb024 (Part number: 0xB02, Revision number: 4) 
CPU ID: 900 
Chip Version: c

DRAM:  512 MB
Parallel Flash:  0 kB
Flash Manufacturer: MX
Serial Flash: 512 kB
Serial Flash:
Bank # 1:  Nb pages: 2048  Page Size: 256
  Size:    524288 bytes,  Logical address: 0x60000000
  Area 0: 60000000 to 60FFFFFF      SPI flash
In:    serial
Out:   serial
Err:   serial
CPU works at 700 MHz (700/1/1)
DDR2 Speed is 400 MHz 
Restoring RTC
Hit any key to stop autoboot:  0 
Whitney # usb reset
(Re)start USB...
USB:   scanning bus for devices... 1 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
Whitney # ide   reset
Unknown command 'ide' - try 'help'
Whitney # printenv
bootargs=root=/dev/mtdblock0 mem=256M console=ttyS0
bootcmd=
bootdelay=2
baudrate=38400
port=0
boardtest_state_memory=none
model_name=whitney_4bay
cpu_clock=700
mfgmodel=elcapitan
netmask=255.255.0.0
bootfile="/tftpboot/uImage"
tftp_bsize=512
udp_frag_size=512
whitney_state=saved
opid=Z13100257
hddlocation=C
hddpn=1CH164-515
ethaddr=00:10:75:37:B1:74
serialNo=NA6P0FXW
ethaddr0=00:10:75:37:B1:74
ethaddr1=00:10:75:37:B1:75
modelname=1BX5P3-500
serial_number=5564T01001G411001E6J0A1
tftp_path=elcapitan/bootimage
netboot_cmd=dhcp;setenv serverip ${tftp_serverip}; tftp 0x4000000 ${tftp_path}/bootpImage; go 0x4000000;
fw_zone=normal
create_volume=pass
mfgtest_state=final_tested_ok
raclient_securityKey=LLnE+YNzJnJkHzr4GNIJEw==
raclient_leaseExpires=2014-12-13T06:47:57Z
current_kernel=kernel2
autoload=yes
tftp_serverip=192.168.3.140
serverip=192.168.3.140
ipaddr=192.168.3.17
rtclog=53225a5f
num_boot_tries=2
stdin=serial
stdout=serial
stderr=serial
verify=n

Environment size: 962/65532 bytes
Whitney # help
?       - alias for 'help'
base    - print or set address offset
bcm     - read/write bcm53115m register
bdinfo  - print Board Info structure
bootelf - Boot from an ELF image in memory
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
date    - get/set/reset date & time
dcache  - enable or disable data cache
dhcp    - boot image via network using DHCP/TFTP protocol
erase   - erase FLASH memory via parallel interface
erase_spi   - erase FLASH memory via serial interface
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
flinfo  - print FLASH memory information
go      - start application at address 'addr'
help    - print online help
icache  - enable or disable instruction cache
iminfo  - print header information for application image
loadb   - load binary file over serial line (kermit mode)
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mdio     - read/write PHY register
memtest_cns3000 - cns3000 RAM test
mm      - memory modify (auto-incrementing)
mmcinit - init mmc card
mtest   - simple RAM test
mw      - memory write (fill)
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable parallel FLASH write protection
protect_spi - enable or disable serial FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
scsi    - SCSI sub-system
scsiboot- boot from SCSI device
setenv  - set environment variables
tftpboot- boot image via network using TFTP protocol
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor version
Whitney # 

I have no luck going past "booting kernel" message with the new images from bodhi.
Mark, could you please share your uImage and initrd or at last least provide some info how did you created it?


In our u-boot sata is called scsi

scsi init gives following info:

Whitney # scsi init

Initialize SCSI
AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part
scanning bus for devices...
Supprt LBA48 addressing.
timeout exit!
  Device 0: (1:0) Vendor: ATA Prod.: WDC WD7500BPKT-0 Rev: 01.0
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 715404.8 MB = 698.6 GB (1465149168 x 512)

And I can confirm what Mark wrote that our u-boot apparently doesn't have usb enabled, as I also failed to load or boot anything from usb disc or pen.

tommy79 Wrote:
-------------------------------------------------------
> Mark, could you please share your uImage and
> initrd or at last least provide some info how did
> you created it?

Play around with the addresses you use to load the images. Try the ones I used (see my boot log above).

I used Bodhi's uImage directly and created a mini uInitrd from Bodhi's 3.15 one he posted at the star t of the thread, swapping out the 3.15 modules with those from the 4.14.24 kernel.

Funny you could get SCSI information. I have a 4 bay and one drive installed at the moment and I kept getting timeout errors when I tried "scsi init."

Whitney # scsi init

Initialize SCSI
AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part 
set feature error!
scanning bus for devices...
timeout exit!
Whitney # scsi reset

Reset SCSI
scanning bus for devices...
timeout exit!
Whitney #

This u-Boot is ancient and once I get Debian running reliably I plan to tackle how to upgrade it. :)

Mark

Mark,

Post your mkimage commands to generate the uImage and uInitrd

mkimage -A arm -O linux -T kernel -C none -a .............
mkimage -A arm -O linux -T ramdisk -C gzip -a ............

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

bodhi Wrote:
-------------------------------------------------------
> Mark,
>
> Post your mkimage commands to generate the uImage
> and uInitrd

The kernel came directly from your deb package, which of course I ran through mkimage:

mkimage -A arm -O linux -a 0x800000 -a 0x800000 -T kernel -C none -d vmlinuz-4.14.24-cns3xxxx-tld-1 -n linux uImage-4.14.24

For uInitrd, I unpacked your 3.18.5 Debian rootfs:

tar xvjf ../Debian-3.18.5-kirkwood-tld-1-rootfs-bodhi.tar.bz2

... then deleted the 3.18 modules from the resulting directory and copied over those from Bodhi's kernel package:

rm -rf ./lib/modules/3.18*
   (switched back to above, untarred directory)
cp -a 4.14.24-cns3xxxx-tld-1/ /mnt/root/usr/lib/modules

Then I packaged up the directory as an Initrd file:

cd root && find . |cpio -o -H newc |gzip >../initrd-4.14.24.img; cd /mnt

... and packaged the new mix up as a uInitrd file:

mkimage -A arm -T ramdisk -C gzip -n uInitrd -d initrd-4.14.24.img uInitrd-4.14.24

So I realize there won't be a full complement of modules doing things this way but I wanted to see if I could get Bodhi's kernel booting before I introduced my own mistakes with my own kernel (did I mention I haven't built kernels in over a decade?) :)

Mark



Edited 2 time(s). Last edit at 03/07/2018 07:09PM by MarkTurner.

Mark

Don't use 3.18.5. Generate the new uInird for 4.14.24 using this format.

mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-4.15.2-kirkwood-tld-1 -d initrd.img-4.15.2-kirkwood-tld-1 uInitrd

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

bodhi Wrote:
-------------------------------------------------------
> Mark
>
> Don't use 3.18.5. Generate the new uInird for
> 4.14.24 using this format.

I'll give that a try. I'm constrained by memory, remember, so I thought it wiser to try a smaller uInitrd first.

tommy,

> I have no luck going past "booting kernel" message
> with the new images from bodhi.
> Mark, could you please share your uImage and
> initrd or at last least provide some info how did
> you created it?

You need to install the kernel with dpkg. But I think I can see why there is confusion.

The kernel need to be installed on a rootfs. So to avoid touching the stock OS. You can use the Kirkwood rootfs Debian-4.12.1-kirkwood-tld-1-rootfs-bodhi.tar.bz2:

https://forum.doozan.com/read.php?2,12096

But you need to chroot into it to install, if you don't have a Kirkwood box!

Let me see if I can upload the initramfs for you guys to create your own uInitrd.

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

MarkTurner Wrote:
-------------------------------------------------------
> bodhi Wrote:
> -------------------------------------------------------
> > Mark
> >
> > Don't use 3.18.5. Generate the new uInird for
> > 4.14.24 using this format.
>
> I'll give that a try. I'm constrained by memory,
> remember, so I thought it wiser to try a smaller
> uInitrd first.

Actually, I just remembered the QEMU ARM emulation trick! I've used this before to use my laptop to compile apps for my RPi.
https://hblok.net/blog/posts/2014/02/06/chroot-to-arm/

I can start with your Debian rootfs, chroot into it from my laptop using this trick, trim the image down to the bare minimum, then repackage it.

Should be good for testing!



Edited 1 time(s). Last edit at 03/07/2018 07:29PM by MarkTurner.

With my Blackarmor fully loaded with 4 SATA drives I now get some info. Guess the bus needs a minimum of two drives to avoid timeouts:

Whitney # scsi init

Initialize SCSI
AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part 
scanning bus for devices...
Supprt LBA48 addressing.
  Device 0: (0:0) Vendor: ATA Prod.: WDC WD40EFRX-68N Rev: 82.0
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 3815447.8 MB = 3726.0 GB (7814037168 x 512)
Supprt LBA48 addressing.
  Device 1: (1:0) Vendor: ATA Prod.: WDC WD40EFRX-68N Rev: 82.0
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 3815447.8 MB = 3726.0 GB (7814037168 x 512)

MarkTurner Wrote:
-------------------------------------------------------
> Actually, I just remembered the QEMU ARM emulation
> trick! I've used this before to use my laptop to
> compile apps for my RPi.
> https://hblok.net/blog/posts/2014/02/06/chroot-to-arm/

For anyone wanting to follow along, these are the steps I just took to build a chroot ARM environment. I'm running Bodhi's rootfs on my laptop in an ARM chroot.

Note that I already installed qemu and did the binfmt registration step as detailed in the link above. Then it's just:

markt@savannah:/usr/local/src/seagate/doozan/Debian$ cp /usr/bin/qemu-arm-static usr/bin
markt@savannah:/usr/local/src/seagate/doozan/Debian$ ls usr/bin/qemu-arm-static 
usr/bin/qemu-arm-static
markt@savannah:/usr/local/src/seagate/doozan/Debian$ sudo mount -t proc /proc proc
markt@savannah:/usr/local/src/seagate/doozan/Debian$ sudo mount -o bind /dev dev
markt@savannah:/usr/local/src/seagate/doozan/Debian$ sudo mount -o bind /dev/pts dev/pts
markt@savannah:/usr/local/src/seagate/doozan/Debian$ sudo mount -o bind /sys sys
markt@savannah:/usr/local/src/seagate/doozan/Debian$ cd ..
(you have to become root to do the chroot)
markt@savannah:/usr/local/src/seagate/doozan$ sudo bash
root@savannah:/usr/local/src/seagate/doozan# chroot Debian /bin/bash

I've chrooted into Bodhi's rootfs and binfmt has done the magic to run all the ARM binaries seamlessly through qemu-arm-static!

Now I'm running the ARM bash binary and uname reports the arm architecture:

root@savannah:/# uname -a
Linux savannah 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 armv7l GNU/Linux
root@savannah:/#

If you're going to repackage this rootfs, just remember to remove /usr/bin/qemu-arm-static from the rootfs first.

Mark

MarkTurner Wrote:
-------------------------------------------------------
> MarkTurner Wrote:
> -------------------------------------------------------
> > Actually, I just remembered the QEMU ARM
> emulation
> > trick! I've used this before to use my laptop
> to
> > compile apps for my RPi.
> >
> https://hblok.net/blog/posts/2014/02/06/chroot-to-arm/
>
> For anyone wanting to follow along, these are the
> steps I just took to build a chroot ARM
> environment. I'm running Bodhi's rootfs on my
> laptop in an ARM chroot.
>
> Note that I already installed qemu and did the
> binfmt registration step as detailed in the link
> above. Then it's just:
>
>

> markt@savannah:/usr/local/src/seagate/doozan/Debian$
> cp /usr/bin/qemu-arm-static usr/bin
> markt@savannah:/usr/local/src/seagate/doozan/Debian$
> ls usr/bin/qemu-arm-static 
> usr/bin/qemu-arm-static
> markt@savannah:/usr/local/src/seagate/doozan/Debian$
> sudo mount -t proc /proc proc
> markt@savannah:/usr/local/src/seagate/doozan/Debian$
> sudo mount -o bind /dev dev
> markt@savannah:/usr/local/src/seagate/doozan/Debian$
> sudo mount -o bind /dev/pts dev/pts
> markt@savannah:/usr/local/src/seagate/doozan/Debian$
> sudo mount -o bind /sys sys
> markt@savannah:/usr/local/src/seagate/doozan/Debian$
> cd ..
> (you have to become root to do the chroot)
> markt@savannah:/usr/local/src/seagate/doozan$ sudo
> bash
> root@savannah:/usr/local/src/seagate/doozan#
> chroot Debian /bin/bash
>

>
> I've chrooted into Bodhi's rootfs and binfmt has
> done the magic to run all the ARM binaries
> seamlessly through qemu-arm-static!
>
> Now I'm running the ARM bash binary and uname
> reports the arm architecture:
>

> root@savannah:/# uname -a
> Linux savannah 4.4.0-116-generic #140-Ubuntu SMP
> Mon Feb 12 21:23:04 UTC 2018 armv7l GNU/Linux
> root@savannah:/#
>

>
> If you're going to repackage this rootfs, just
> remember to remove /usr/bin/qemu-arm-static from
> the rootfs first.
>
> Mark

Cool! that's how one would do this for a non-live rootfs. And it could be done by chrooting from the stock OS too. And remember to be root first to chroot.

I think perhaps it's time that I create and upload a basic rootfs for this kernel. It'll help in make testing easier.

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

I am uploading the basic rootfs for Cavium CNS3xxx with kernel 4.14.24-cns3xxx-tld-1.

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

I've uploaded the rootfs Debian-4.14.24-cns3xxxx-tld-1-rootfs-bodhi.tar.bz2. Please see 1st post for download link.

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

The modprobe/kernel paging issue still exists:

Whitney # bootm 0x2000000 0x5100000 0x5000000
enter do_eth_down!!!
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   linux
   Created:      2018-03-07  12:42:23 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3349200 Bytes =  3.2 MB
   Load Address: 00800000
   Entry Point:  00800000
## Loading init Ramdisk from Legacy Image at 05100000 ...
   Image Name:   initramfs-4.14.24-cns3xxxx-tld-1
   Created:      2018-03-08   2:44:43 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4607521 Bytes =  4.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.14.24-cns3xxxx-tld-1 (root@tldDebian) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 PREEMPT Mon Mar 5 04:42:28 PST 2018
CPU: ARMv6-compatible processor [410fb024] revision 4 (ARMv7), cr=00c5787d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Cavium Networks CNS3420 Validation Board
Memory policy: Data cache writeback
Built 1 zonelists, mobility grouping on.  Total pages: 65024
Kernel command line: mem=256M console=ttyS0,38400
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 248696K/262144K available (5056K kernel code, 211K rwdata, 1020K rodata, 188K init, 99K bss, 13448K reserved, 0K cma-reserved)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xd0800000 - 0xff800000   ( 752 MB)
    lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc04f8470   (5058 kB)
      .init : 0xc05f9000 - 0xc0628000   ( 188 kB)
      .data : 0xc0628000 - 0xc065cee0   ( 212 kB)
       .bss : 0xc0662664 - 0xc067b414   ( 100 kB)
Preemptible hierarchical RCU implementation.
        Tasks RCU enabled.
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns
Console: colour dummy device 80x30
console [ttyS0] enabled
Calibrating delay loop... 240.84 BogoMIPS (lpj=1204224)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x8220 - 0x8258
Hierarchical SRCU implementation.
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x88/0x1c4 with crng_init=0
VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 4
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
L2C: DT/platform modifies aux control register: 0x02040000 -> 0x02540000
random: fast init done
L2C-310 cache controller enabled, 8 ways, 256 kB
L2C-310: CACHE_ID 0x410000c4, AUX_CTRL 0x06540000
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
FS-Cache: Loaded
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 4500K
workingset: timestamp_bits=30 max_order=16 bucket_order=0
SGI XFS with security attributes, no debug enabled
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x78000000 (irq = 45, base_baud = 1500000) is a 16550A
brd: module loaded
loop: module loaded
ahci ahci.0: forcing PORTS_IMPL to 0x3
ahci ahci.0: AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl platform mode
ahci ahci.0: flags: ncq sntf pm led clo only pmp pio slum part ccc 
scsi host0: ahci
scsi host1: ahci
ata1: SATA max UDMA/133 mmio [mem 0x83000000-0x83ffffff] port 0x100 irq 65
ata2: SATA max UDMA/133 mmio [mem 0x83000000-0x83ffffff] port 0x180 irq 65
physmap platform flash device: 08000000 at 10000000
Unable to handle kernel paging request at virtual address b6f4e710
pgd = cfaf8000
[b6f4e710] *pgd=0ec57831, *pte=055583cf, *ppte=05558a2f
Internal error: Oops: 81f [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 422 Comm: modprobe Not tainted 4.14.24-cns3xxxx-tld-1 #1
Hardware name: Cavium Networks CNS3420 Validation Board
task: cf9b9240 task.stack: cfa96000
PC is at v6wbi_flush_user_tlb_range+0x28/0x48
LR is at change_protection_range+0x2a4/0x30c
pc : [<c001ab30>]    lr : [<c00c49bc>]    psr: 80000013
sp : cfa97eb8  ip : 00000000  fp : cfa97f14
r10: cfafadc8  r9 : b6f50000  r8 : 00000000
r7 : 00000002  r6 : b6f50000  r5 : cec57540  r4 : 0555a34f
r3 : 00000001  r2 : 00100071  r1 : b6f50000  r0 : b6f4f001
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 00c5787d  Table: 0faf8008  DAC: 00000051
Process modprobe (pid: 422, stack limit = 0xcfa96188)
Stack: (0xcfa97eb8 to 0xcfa98000)
7ea0:                                                       cec58ea0 b6f4e000
7ec0: cec58d20 cfa96000 cfafadc0 cec5f3c0 b6f4ffff 0555a3cf ffffffff 00000381
7ee0: b6f50000 00000002 cfa97f14 00100073 cec5f3c0 b6f4e000 cec58d20 b6f50000
7f00: 00000000 00000000 cfa97f64 cfa97f18 c00c4b44 c00c4724 00000000 00000000
7f20: cfa8b680 00000134 00000000 00000000 00000002 cfa97f74 cfa97f64 b6f50000
7f40: 00000000 b6f50000 00000001 00000005 cfa96000 b6f4e000 cfa97fa4 cfa97f68
7f60: c00c4e0c c00c4a5c 00100071 cfa97f78 c00c1874 cec5f3c0 00000022 b6f83018
7f80: b6f83018 b6f83018 0000007d c000fcc4 cfa96000 00000000 00000000 cfa97fa8
7fa0: c000fae0 c00c4cf4 b6f83018 b6f83018 b6f4e000 00002000 00000001 b6f4e000
7fc0: b6f83018 b6f83018 b6f83018 0000007d 00000002 00000000 b6f83018 bec18d5c
7fe0: 00144710 bec18c8c b6f60ed4 b6f6f33c 80000010 b6f4e000 00000000 00000000
Backtrace: 
[<c00c4718>] (change_protection_range) from [<c00c4b44>] (mprotect_fixup+0xf4/0x298)
 r10:00000000 r9:00000000 r8:b6f50000 r7:cec58d20 r6:b6f4e000 r5:cec5f3c0
 r4:00100073
[<c00c4a50>] (mprotect_fixup) from [<c00c4e0c>] (SyS_mprotect+0x124/0x208)
 r10:b6f4e000 r9:cfa96000 r8:00000005 r7:00000001 r6:b6f50000 r5:00000000
 r4:b6f50000
[<c00c4ce8>] (SyS_mprotect) from [<c000fae0>] (ret_fast_syscall+0x0/0x54)
 r10:00000000 r9:cfa96000 r8:c000fcc4 r7:0000007d r6:b6f83018 r5:b6f83018
 r4:b6f83018
Code: e20330ff e1830600 e1a01601 e5922028 (ee080f36) 
---[ end trace c62b3f7c6028f7db ]---
ata2: SATA link down (SStatus 0 SControl 300)
ata1: SATA link down (SStatus 0 SControl 300)

After watching the native kernel boot, I decided to try booting Bodhi's 4.14.24 kernel and using /dev/md1 (the native Seagate filesystem) as the rootfs. This suggests loading uinitrd into memory is indeed the cause of the kernel paging fault. I've gotten a lot farther this time than others! Now it looks like the impediment for me is that software RAID isn't started so /dev/md1 can't be found. I would be willing to try installing Bodhi's rootfs on one of the partitions that ARE available, though (these are new, scratch disks).

Bodhi, I see a number of IR protocols are being loaded. This Blackarmor box has no IR so do we need these? I would imagine they don't take up much memory, so probably doesn't matter either way.

Mark

OK, finally found a spare SATA drive I could put Bodhi's rootfs onto as /dev/sda1. I wanted to definitively rule out my uIinitrd tftp image hogging all the memory.

Now I've got new and interesting errors which might require a new kernel build as it tells me there's no kernel memory protection. A snippet from the attached boot log:

Freeing unused kernel memory: 188K
This architecture does not have kernel memory protection.
Unable to handle kernel paging request at virtual address b6d63f84
pgd = cfa1c000
[b6d63f84] *pgd=0f9d4831, *pte=0fd4218f, *ppte=0fd42a2e
Internal error: Oops: 17 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 4.14.24-cns3xxxx-tld-1 #1
Hardware name: Cavium Networks CNS3420 Validation Board
task: cf81f8e0 task.stack: cf820000
PC is at v6wbi_flush_user_tlb_range+0x28/0x48
LR is at change_protection_range+0x2a4/0x30c
pc : [<c001ab30>]    lr : [<c00c49bc>]    psr: 80000013
sp : cf821eb8  ip : 00000000  fp : cf821f14
r10: cfa1edc8  r9 : b6ea8000  r8 : 00000000
r7 : 00000002  r6 : b6ea8000  r5 : cf8cc2a0  r4 : 0fd6834f
r3 : 00000001  r2 : 00100071  r1 : b6ea8000  r0 : b6ea7001
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 00c5787d  Table: 0fa1c008  DAC: 00000051
Process init (pid: 1, stack limit = 0xcf820188)
Stack: (0xcf821eb8 to 0xcf822000)
1ea0:                                                       cf8d5ea0 b6ea6000
1ec0: cf8d5d20 cf820000 cfa1edc0 cfb07560 b6ea7fff 0fd683cf ffffffff 00000381
1ee0: b6ea8000 00000002 cf821f14 00100073 cfb07560 b6ea6000 cf8d5d20 b6ea8000
1f00: 00000000 00000000 cf821f64 cf821f18 c00c4b44 c00c4724 00000000 00000000
1f20: cfa89a40 00000134 00000000 00000000 00000002 cf821f74 cf821f64 b6ea8000
1f40: 00000000 b6ea8000 00000001 00000005 cf820000 b6ea6000 cf821fa4 cf821f68
1f60: c00c4e0c c00c4a5c 00100071 cf821f78 c00094c0 cfb07560 b6fa2000 b6fa95a8
1f80: b6fa95a8 b6fa95a8 0000007d c000fcc4 cf820000 00000000 00000000 cf821fa8
1fa0: c000fae0 c00c4cf4 b6fa95a8 b6fa95a8 b6ea6000 00002000 00000001 b6ea6000
1fc0: b6fa95a8 b6fa95a8 b6fa95a8 0000007d 00000002 00000000 b6fa95a8 bec4ddac
1fe0: 00144710 bec4dcdc b6f86ed4 b6f9533c 80000010 b6ea6000 9c713693 9c713693
Backtrace: 
[<c00c4718>] (change_protection_range) from [<c00c4b44>] (mprotect_fixup+0xf4/0x298)
 r10:00000000 r9:00000000 r8:b6ea8000 r7:cf8d5d20 r6:b6ea6000 r5:cfb07560
 r4:00100073
[<c00c4a50>] (mprotect_fixup) from [<c00c4e0c>] (SyS_mprotect+0x124/0x208)
 r10:b6ea6000 r9:cf820000 r8:00000005 r7:00000001 r6:b6ea8000 r5:00000000
 r4:b6ea8000
[<c00c4ce8>] (SyS_mprotect) from [<c000fae0>] (ret_fast_syscall+0x0/0x54)
 r10:00000000 r9:cf820000 r8:c000fcc4 r7:0000007d r6:b6fa95a8 r5:b6fa95a8
 r4:b6fa95a8
Code: e20330ff e1830600 e1a01601 e5922028 (ee080f36) 
---[ end trace 79ead98534c64208 ]---

Also, I had to reformat /dev/sda1 from ext4 to ext3 because for some reason it would not mount my ext4 partition ("incompatibilities?") even though the kernel supposedly has ext4 support (you can in the boot log that the kernel mounted my ext3 using the ext4 driver):

EXT4-fs (sda1): mounting ext3 file system using the ext4 subsystem

Mark