Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - FAILURE

[Janet Estabridis]

Thanks Ralph,
I had all those setting on the one that hangs...  I'll keep at it.  

The kernel that boots and doesn't see the jffs2 was from the Altera Quartus 
17.0  intelFPGA/17.0/embedded/embeddedsw/socfpga/prebuilt_images - directory 
and I just noticed that there is a "kernel.config" file there too...  It has 
the all the MTD enabled but I'll use that to make a new zImage and see if that 
gets me farther.
Janet

- Original Message -
From: "Ralph Siemsen" <ral...@netwinder.org>
To: "Janet Estabridis" <jpe1...@mchsi.com>
Cc: "Charles Manning" <cdhmann...@gmail.com>, "rfi" <rfi@lists.rocketboards.org>
Sent: Sunday, October 15, 2017 6:13:26 PM
Subject: Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - 
FAILURE

I would suggest to first reproduce the kernel that boots. Then you can
add to it selectively. Most likely you will need the following settings:

CONFIG_MTD=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y
CONFIG_OF_MTD=y

For the root filesystem, you are correct, this is largely independent of
the kernel. You can copy the existing root filesystem into QSPI, or you
can use buildroot/yocto/others to construct one.

-Ralph

On Sun, Oct 15, 2017 at 07:58:51PM -0400, Janet Estabridis wrote:
> Thanks Ralph,
> Your 2 cents were worth more than 2 cents.  
> I am feeling "less stupid" and will look at the kernel settings again.  I 
> sure thought I had what I needed for flash and MTD blocks.
> 
> For the minimal root filesystem - I should be able to get a root filesystem 
> that works and just update to newer kernels, correct?
> 
> Janet
> 
> 
> - Original Message -
> From: "Ralph Siemsen" <ral...@netwinder.org>
> To: "Janet Estabridis" <jpe1...@mchsi.com>
> Cc: "Charles Manning" <cdhmann...@gmail.com>, "rfi" 
> <rfi@lists.rocketboards.org>
> Sent: Sunday, October 15, 2017 4:38:53 PM
> Subject: Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - 
> FAILURE
> 
> Hi Janet,
> 
> My $0.02 here: the *.dts entries look semi reasonable, you have a flash
> device and two partitions defined therein. The second one is labelled as
> jffs2 which matches with your root=/dev/mtdblock1 on the kernel command
> line. So far, so good.
> 
> Therefore you are likely missing some drivers from the kernel, the flash
> controller and/or the MTD subsystem. I'm not sure offhand why your
> second kernel is failing to boot. I'd suggest comparing the boot
> messages versus the working boot - what is the next line that normally
> would appear? That is where to go looking.
> 
> You could also try to ensure you are using the same kernel version and
> the same configuration. Often you can obtain the kernel config at
> runtime from /proc/config or /proc/config.gz, this makes it easier to
> reproduce the exact same kernel.
> 
> Regarding using Altera tools, versus something like buildroot, or just
> building the kernel manually: these are all viable approaches. Like
> Charles I also use buildroot for all my work, mostly because I find it a
> lot simpler than the Yocto system. However as you indicated that you are
> comfortable doing a direct "make ARCH=..." in the kernel, I would
> suggest you just do that. Buildroot and yocto just add complexity on top
> of that basic step.
> 
> Regarding using jffs2 versus squashfs: both have their uses. But keep in
> mind with a squashfs, the entire contents has to be read in by uboot
> (similar to how it loads the zImage) and placed into RAM. If your
> rootfilesystem is say 100MB in size, you are permanently tying up that
> much of your RAM. Versus an in-flash filesystem such as jffs2 or ubifs
> will only use RAM as you load each individual program into memory.
> A squashfs is also by necessity read-only, while jffs2/ubitfs can be
> mounted read-write. Lastly, all three choices do data compression, so
> you'll be able to fit about the same total amount into your
> /dev/mtdblock1 partition.
> 
> Regards,
> -Ralph
> 
> 
> On Sun, Oct 15, 2017 at 12:55:03PM -0400, Janet Estabridis wrote:
> > Ralph / Charles / Anyone else, 
> > 
> > * 
> > Here is a section of *.dts file with the flash: 
> > 
> > flash0: n25q512a@0 { 
> > compatible = "n25q512a"; /* appended from boardinfo */ 
> > #address-cells = <1>; /* appended from boardinfo */ 
> > #size-cells = <1>; /* appended from boardinfo */ 
> > reg = <0>; /* appended from boardinfo */ 
> > spi-max-frequency = <1>; /* appended from boardinfo */ 
> 

Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - FAILURE

[Ralph Siemsen]

I would suggest to first reproduce the kernel that boots. Then you can
add to it selectively. Most likely you will need the following settings:

CONFIG_MTD=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
CONFIG_MTD_SPI_NOR=y
CONFIG_SPI_CADENCE_QUADSPI=y
CONFIG_OF_MTD=y

For the root filesystem, you are correct, this is largely independent of
the kernel. You can copy the existing root filesystem into QSPI, or you
can use buildroot/yocto/others to construct one.

-Ralph

On Sun, Oct 15, 2017 at 07:58:51PM -0400, Janet Estabridis wrote:
> Thanks Ralph,
> Your 2 cents were worth more than 2 cents.  
> I am feeling "less stupid" and will look at the kernel settings again.  I 
> sure thought I had what I needed for flash and MTD blocks.
> 
> For the minimal root filesystem - I should be able to get a root filesystem 
> that works and just update to newer kernels, correct?
> 
> Janet
> 
> 
> - Original Message -
> From: "Ralph Siemsen" <ral...@netwinder.org>
> To: "Janet Estabridis" <jpe1...@mchsi.com>
> Cc: "Charles Manning" <cdhmann...@gmail.com>, "rfi" 
> <rfi@lists.rocketboards.org>
> Sent: Sunday, October 15, 2017 4:38:53 PM
> Subject: Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - 
> FAILURE
> 
> Hi Janet,
> 
> My $0.02 here: the *.dts entries look semi reasonable, you have a flash
> device and two partitions defined therein. The second one is labelled as
> jffs2 which matches with your root=/dev/mtdblock1 on the kernel command
> line. So far, so good.
> 
> Therefore you are likely missing some drivers from the kernel, the flash
> controller and/or the MTD subsystem. I'm not sure offhand why your
> second kernel is failing to boot. I'd suggest comparing the boot
> messages versus the working boot - what is the next line that normally
> would appear? That is where to go looking.
> 
> You could also try to ensure you are using the same kernel version and
> the same configuration. Often you can obtain the kernel config at
> runtime from /proc/config or /proc/config.gz, this makes it easier to
> reproduce the exact same kernel.
> 
> Regarding using Altera tools, versus something like buildroot, or just
> building the kernel manually: these are all viable approaches. Like
> Charles I also use buildroot for all my work, mostly because I find it a
> lot simpler than the Yocto system. However as you indicated that you are
> comfortable doing a direct "make ARCH=..." in the kernel, I would
> suggest you just do that. Buildroot and yocto just add complexity on top
> of that basic step.
> 
> Regarding using jffs2 versus squashfs: both have their uses. But keep in
> mind with a squashfs, the entire contents has to be read in by uboot
> (similar to how it loads the zImage) and placed into RAM. If your
> rootfilesystem is say 100MB in size, you are permanently tying up that
> much of your RAM. Versus an in-flash filesystem such as jffs2 or ubifs
> will only use RAM as you load each individual program into memory.
> A squashfs is also by necessity read-only, while jffs2/ubitfs can be
> mounted read-write. Lastly, all three choices do data compression, so
> you'll be able to fit about the same total amount into your
> /dev/mtdblock1 partition.
> 
> Regards,
> -Ralph
> 
> 
> On Sun, Oct 15, 2017 at 12:55:03PM -0400, Janet Estabridis wrote:
> > Ralph / Charles / Anyone else, 
> > 
> > * 
> > Here is a section of *.dts file with the flash: 
> > 
> > flash0: n25q512a@0 { 
> > compatible = "n25q512a"; /* appended from boardinfo */ 
> > #address-cells = <1>; /* appended from boardinfo */ 
> > #size-cells = <1>; /* appended from boardinfo */ 
> > reg = <0>; /* appended from boardinfo */ 
> > spi-max-frequency = <1>; /* appended from boardinfo */ 
> > m25p,fast-read; /* appended from boardinfo */ 
> > page-size = <256>; /* appended from boardinfo */ 
> > block-size = <16>; /* appended from boardinfo */ 
> > tshsl-ns = <50>; /* appended from boardinfo */ 
> > tsd2d-ns = <50>; /* appended from boardinfo */ 
> > tchsh-ns = <4>; /* appended from boardinfo */ 
> > tslch-ns = <4>; /* appended from boardinfo */ 
> > cdns,page-size = <256>; /* appended from boardinfo */ 
> > cdns,block-size = <16>; /* appended from boardinfo */ 
> > cdns,tshsl-ns = <50>; /* appended from boardinfo */ 
> > cdns,tsd2d-ns = <50>; /* appended from boardinfo */ 
> > cdns,tchsh-ns = <4>; /* appended from

Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - FAILURE

[Janet Estabridis]

Thanks Ralph,
Your 2 cents were worth more than 2 cents.  
I am feeling "less stupid" and will look at the kernel settings again.  I sure 
thought I had what I needed for flash and MTD blocks.

For the minimal root filesystem - I should be able to get a root filesystem 
that works and just update to newer kernels, correct?

Janet


- Original Message -
From: "Ralph Siemsen" <ral...@netwinder.org>
To: "Janet Estabridis" <jpe1...@mchsi.com>
Cc: "Charles Manning" <cdhmann...@gmail.com>, "rfi" <rfi@lists.rocketboards.org>
Sent: Sunday, October 15, 2017 4:38:53 PM
Subject: Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - 
FAILURE

Hi Janet,

My $0.02 here: the *.dts entries look semi reasonable, you have a flash
device and two partitions defined therein. The second one is labelled as
jffs2 which matches with your root=/dev/mtdblock1 on the kernel command
line. So far, so good.

Therefore you are likely missing some drivers from the kernel, the flash
controller and/or the MTD subsystem. I'm not sure offhand why your
second kernel is failing to boot. I'd suggest comparing the boot
messages versus the working boot - what is the next line that normally
would appear? That is where to go looking.

You could also try to ensure you are using the same kernel version and
the same configuration. Often you can obtain the kernel config at
runtime from /proc/config or /proc/config.gz, this makes it easier to
reproduce the exact same kernel.

Regarding using Altera tools, versus something like buildroot, or just
building the kernel manually: these are all viable approaches. Like
Charles I also use buildroot for all my work, mostly because I find it a
lot simpler than the Yocto system. However as you indicated that you are
comfortable doing a direct "make ARCH=..." in the kernel, I would
suggest you just do that. Buildroot and yocto just add complexity on top
of that basic step.

Regarding using jffs2 versus squashfs: both have their uses. But keep in
mind with a squashfs, the entire contents has to be read in by uboot
(similar to how it loads the zImage) and placed into RAM. If your
rootfilesystem is say 100MB in size, you are permanently tying up that
much of your RAM. Versus an in-flash filesystem such as jffs2 or ubifs
will only use RAM as you load each individual program into memory.
A squashfs is also by necessity read-only, while jffs2/ubitfs can be
mounted read-write. Lastly, all three choices do data compression, so
you'll be able to fit about the same total amount into your
/dev/mtdblock1 partition.

Regards,
-Ralph


On Sun, Oct 15, 2017 at 12:55:03PM -0400, Janet Estabridis wrote:
> Ralph / Charles / Anyone else, 
> 
> * 
> Here is a section of *.dts file with the flash: 
> 
> flash0: n25q512a@0 { 
> compatible = "n25q512a"; /* appended from boardinfo */ 
> #address-cells = <1>; /* appended from boardinfo */ 
> #size-cells = <1>; /* appended from boardinfo */ 
> reg = <0>; /* appended from boardinfo */ 
> spi-max-frequency = <1>; /* appended from boardinfo */ 
> m25p,fast-read; /* appended from boardinfo */ 
> page-size = <256>; /* appended from boardinfo */ 
> block-size = <16>; /* appended from boardinfo */ 
> tshsl-ns = <50>; /* appended from boardinfo */ 
> tsd2d-ns = <50>; /* appended from boardinfo */ 
> tchsh-ns = <4>; /* appended from boardinfo */ 
> tslch-ns = <4>; /* appended from boardinfo */ 
> cdns,page-size = <256>; /* appended from boardinfo */ 
> cdns,block-size = <16>; /* appended from boardinfo */ 
> cdns,tshsl-ns = <50>; /* appended from boardinfo */ 
> cdns,tsd2d-ns = <50>; /* appended from boardinfo */ 
> cdns,tchsh-ns = <4>; /* appended from boardinfo */ 
> cdns,tslch-ns = <4>; /* appended from boardinfo */ 
> 
> part0: partition@0 { 
> label = "Flash 0 Raw Data"; /* appended from boardinfo */ 
> reg = <0x 0x0080>; /* appended from boardinfo */ 
> }; //end partition@0 (part0) 
> 
> part1: partition@80 { 
> label = "Flash 1 jffs2 Filesystem"; /* appended from boardinfo */ 
> reg = <0x0080 0x0380>; /* appended from boardinfo */ 
> }; //end partition@80 (part1) 
> }; //end n25q512a@0 (flash0) 
> 
> * 
> 
> Also, I was not sure what the zImage had in it since it was the one provided 
> with the "intelFPGA/17.0/embedded/embeddedsw/spcfpga/prebuilt_images" 
> so I had a zImage created that I knew had the mtd enabled because I had used 
> it previously to try and embed when I use that zImage hangs SOONER and never 
> gets to look for the root filesystem. 
> 
> 
> ***

Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - FAILURE

[Ralph Siemsen]

 0.213942] usbcore: registered new device driver usb 
> [ 0.214127] sopc@0:usbphy@0 supply vcc not found, using dummy regulator 
> [ 0.215332] pps_core: LinuxPPS API ver. 1 registered 
> [ 0.215344] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo 
> Giometti < giome...@linux.it > 
> [ 0.215379] PTP clock support registered 
> [ 0.215572] FPGA manager framework 
> [ 0.216682] Switched to clocksource timer 
> [ 0.247290] NET: Registered protocol family 2 
> [ 0.247903] TCP established hash table entries: 8192 (order: 3, 32768 bytes) 
> [ 0.247982] TCP bind hash table entries: 8192 (order: 4, 65536 bytes) 
> [ 0.248104] TCP: Hash tables configured (established 8192 bind 8192) 
> [ 0.248184] UDP hash table entries: 512 (order: 2, 16384 bytes) 
> [ 0.248229] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) 
> [ 0.248422] NET: Registered protocol family 1 
> [ 0.248737] RPC: Registered named UNIX socket transport module. 
> [ 0.248749] RPC: Registered udp transport module. 
> [ 0.248756] RPC: Registered tcp transport module. 
> [ 0.248762] RPC: Registered tcp NFSv4.1 backchannel transport module. 
> [ 0.249337] CPU PMU: Failed to parse /sopc@0/pmu0/interrupt-affinity[0] 
> [ 0.249377] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 
> counters available 
> [ 0.250323] futex hash table entries: 512 (order: 3, 32768 bytes) 
> [ 0.261140] NFS: Registering the id_resolver key type 
> [ 0.261179] Key type id_resolver registered 
> [ 0.261188] Key type id_legacy registered 
> [ 0.261247] ntfs: driver 2.1.32 [Flags: R/W]. 
> [ 0.261603] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. 
> [ 0.262566] io scheduler noop registered (default) 
> [ 0.266856] dma-pl330 ffe01000.dma: Loaded driver for PL330 DMAC-341330 
> [ 0.266875] dma-pl330 ffe01000.dma: DBUFF-512x8bytes Num_Chans-8 Num_Peri-32 
> Num_Events-8 
> [ 0.270828] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled 
> [ 0.272023] console [ttyS0] disabled 
> [ 0.272062] ffc02000.serial: ttyS0 at MMIO 0xffc02000 (irq = 27, base_baud = 
> 625) is a 16550A 
> [ 0.854533] console [ttyS0] enabled 
> [ 0.859650] brd: module loaded 
> [ 0.862782] at24 0-0051: 4096 byte 24c32 EEPROM, writable, 32 bytes/write 
> [ 0.870364] cadence-qspi ff705000.flash: couldn't determine chip select 
> [ 0.878126] CAN device driver interface 
> [ 0.882589] stmmaceth ff702000.ethernet: snps,phy-addr property is deprecated 
> [ 0.889885] stmmac - user ID: 0x10, Synopsys ID: 0x37 
> [ 0.894916] Ring mode enabled 
> [ 0.897969] DMA HW capability register supported 
> [ 0.902479] Enhanced/Alternate descriptors 
> [ 0.906835] Enabled extended descriptors 
> [ 0.910828] RX Checksum Offload Engine supported (type 2) 
> [ 0.916286] TX Checksum insertion supported 
> [ 0.920544] Enable RX Mitigation via HW Watchdog Timer 
> [ 0.931858] libphy: stmmac: probed 
> [ 0.935255] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active 
> [ 0.942015] ffb4.usb supply vusb_d not found, using dummy regulator 
> [ 0.948673] ffb4.usb supply vusb_a not found, using dummy regulator 
> [ 0.986664] dwc2 ffb4.usb: EPs: 16, dedicated fifos, 8064 entries in 
> SPRAM 
> [ 1.846747] dwc2 ffb4.usb: DWC OTG Controller 
> [ 1.851461] dwc2 ffb4.usb: new USB bus registered, assigned bus number 1 
> [ 1.858521] dwc2 ffb4.usb: irq 39, io mem 0x 
> [ 1.864053] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 
> [ 1.870831] usb usb1: New USB device strings: Mfr=3, Product=2, 
> SerialNumber=1 
> [ 1.878033] usb usb1: Product: DWC OTG Controller 
> [ 1.882719] usb usb1: Manufacturer: Linux 4.1.22-ltsi-02999-g9689ce4 
> dwc2_hsotg 
> [ 1.890005] usb usb1: SerialNumber: ffb4.usb 
> [ 1.895192] hub 1-0:1.0: USB hub found 
> [ 1.898977] hub 1-0:1.0: 1 port detected 
> [ 1.903420] usbcore: registered new interface driver usb-storage 
> [ 1.909764] mousedev: PS/2 mouse device common for all mice 
> [ 1.921084] rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0 
> [ 1.927335] i2c /dev entries driver 
> [ 1.931578] watchdog: Invalid min and max timeout values, resetting to 0! 
> [ 1.938801] Synopsys Designware Multimedia Card Interface Driver 
> [ 1.945043] dw_mmc ff704000.flash: IDMAC supports 32-bit address mode. 
> [ 1.951599] dw_mmc ff704000.flash: Using internal DMA controller. 
> [ 1.957688] dw_mmc ff704000.flash: Version ID is 240a 
> [ 1.962760] dw_mmc ff704000.flash: DW MMC controller at irq 38, 32 bit host 
> data width, 1024 deep fifo 
> [ 1.972198] dw_mmc ff704000.flash: Got CD GPIO 
> [ 2.016692] dw_mmc ff704000.flash: 1 slots initialized 
> 
> *** 
> 
> Charles - I have never heard of squashfs but am not opposed to 

Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - FAILURE

[Charles Manning]

 (order: 2, 16384 bytes)
> [0.248229] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> [0.248422] NET: Registered protocol family 1
> [0.248737] RPC: Registered named UNIX socket transport module.
> [0.248749] RPC: Registered udp transport module.
> [0.248756] RPC: Registered tcp transport module.
> [0.248762] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [0.249337] CPU PMU: Failed to parse /sopc@0/pmu0/interrupt-affinity[0]
> [0.249377] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7
> counters available
> [0.250323] futex hash table entries: 512 (order: 3, 32768 bytes)
> [0.261140] NFS: Registering the id_resolver key type
> [0.261179] Key type id_resolver registered
> [0.261188] Key type id_legacy registered
> [0.261247] ntfs: driver 2.1.32 [Flags: R/W].
> [0.261603] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
> [0.262566] io scheduler noop registered (default)
> [0.266856] dma-pl330 ffe01000.dma: Loaded driver for PL330 DMAC-341330
> [0.266875] dma-pl330 ffe01000.dma:  DBUFF-512x8bytes Num_Chans-8
> Num_Peri-32 Num_Events-8
> [0.270828] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> [0.272023] console [ttyS0] disabled
> [0.272062] ffc02000.serial: ttyS0 at MMIO 0xffc02000 (irq = 27,
> base_baud = 625) is a 16550A
> [0.854533] console [ttyS0] enabled
> [0.859650] brd: module loaded
> [0.862782] at24 0-0051: 4096 byte 24c32 EEPROM, writable, 32
> bytes/write
> [0.870364] cadence-qspi ff705000.flash: couldn't determine chip select
> [0.878126] CAN device driver interface
> [0.882589] stmmaceth ff702000.ethernet: snps,phy-addr property is
> deprecated
> [0.889885] stmmac - user ID: 0x10, Synopsys ID: 0x37
> [0.894916]  Ring mode enabled
> [0.897969]  DMA HW capability register supported
> [0.902479]  Enhanced/Alternate descriptors
> [0.906835]  Enabled extended descriptors
> [0.910828]  RX Checksum Offload Engine supported (type 2)
> [0.916286]  TX Checksum insertion supported
> [0.920544]  Enable RX Mitigation via HW Watchdog Timer
> [0.931858] libphy: stmmac: probed
> [0.935255] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active
> [0.942015] ffb4.usb supply vusb_d not found, using dummy regulator
> [0.948673] ffb4.usb supply vusb_a not found, using dummy regulator
> [0.986664] dwc2 ffb4.usb: EPs: 16, dedicated fifos, 8064 entries
> in SPRAM
> [1.846747] dwc2 ffb4.usb: DWC OTG Controller
> [1.851461] dwc2 ffb4.usb: new USB bus registered, assigned bus
> number 1
> [1.858521] dwc2 ffb4.usb: irq 39, io mem 0x
> [1.864053] usb usb1: New USB device found, idVendor=1d6b,
> idProduct=0002
> [1.870831] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [1.878033] usb usb1: Product: DWC OTG Controller
> [1.882719] usb usb1: Manufacturer: Linux 4.1.22-ltsi-02999-g9689ce4
> dwc2_hsotg
> [1.890005] usb usb1: SerialNumber: ffb4.usb
> [1.895192] hub 1-0:1.0: USB hub found
> [1.898977] hub 1-0:1.0: 1 port detected
> [1.903420] usbcore: registered new interface driver usb-storage
> [1.909764] mousedev: PS/2 mouse device common for all mice
> [1.921084] rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
> [1.927335] i2c /dev entries driver
> [1.931578] watchdog: Invalid min and max timeout values, resetting to
> 0!
> [1.938801] Synopsys Designware Multimedia Card Interface Driver
> [1.945043] dw_mmc ff704000.flash: IDMAC supports 32-bit address mode.
> [    1.951599] dw_mmc ff704000.flash: Using internal DMA controller.
> [1.957688] dw_mmc ff704000.flash: Version ID is 240a
> [1.962760] dw_mmc ff704000.flash: DW MMC controller at irq 38, 32 bit
> host data width, 1024 deep fifo
> [1.972198] dw_mmc ff704000.flash: Got CD GPIO
> [2.016692] dw_mmc ff704000.flash: 1 slots initialized
>
> ***
>
> Charles - I have never heard of squashfs but am not opposed to trying
> anything.  What are the advantages and do you think changing to squashfs
> will work with all the Altera tools.
>
> THANKS.
>
> --
> *From: *"Charles Manning" <cdhmann...@gmail.com>
> *To: *"Ralph Siemsen" <ral...@netwinder.org>
> *Cc: *"Janet Estabridis" <jpe1...@mchsi.com>, "rfi" <
> rfi@lists.rocketboards.org>
> *Sent: *Saturday, October 14, 2017 5:30:29 PM
> *Subject: *Re: [Rfi] QSPI Boot - No filesystem could mount root, tried:
> jffs2 - FAILURE
>
>
> If you are booting from Q

Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - FAILURE

[Charles Manning]

If you are booting from QSPI have you considered rather using squashfs for
rootfs?

That's what I tend to use for QSPI-based products.


On Sat, Oct 14, 2017 at 2:01 PM, Ralph Siemsen  wrote:

> On Fri, Oct 13, 2017 at 07:58:48PM -0400, Janet Estabridis wrote:
> > Thanks in advance.
> >
> > I'm working on embedding to the QSPI on the Sodia Cyclone V Eval board.
> >
> > Starting kernel ...
> >
> > [0.00] Kernel command line: console=ttyS0,115200
> root=/dev/mtdblock1 rw rootfstype=jffs2
>
> This looks reasonable, and is telling the kernel to boot from the 2nd
> partition in your QSPI. And it is specifying the filesystem type
> which is also required for JFFS2, as it cannot be auto-detected.
>
> However looking through the remaining kernel boot messages, I do not see
> any indication of the kernel having detected the QSPI device. And
> therefore it also does not know about partitions on this device.
>
> This could be caused either by missing some kernel configuration
> settings (eg. QSPI driver, MTD subsystem, etc) or by missing entries in
> the device tree (DTS) files.
>
> The offset in the QSPI is specified in the partition table, which
> usually goes into the device tree.
>
> Regards,
> -Ralph
> ___
> Rfi mailing list
> Rfi@lists.rocketboards.org
> http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi
>
___
Rfi mailing list
Rfi@lists.rocketboards.org
http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi

Re: [Rfi] QSPI Boot - No filesystem could mount root, tried: jffs2 - FAILURE

[Ralph Siemsen]

On Fri, Oct 13, 2017 at 07:58:48PM -0400, Janet Estabridis wrote:
> Thanks in advance.
> 
> I'm working on embedding to the QSPI on the Sodia Cyclone V Eval board.
> 
> Starting kernel ...
> 
> [0.00] Kernel command line: console=ttyS0,115200 root=/dev/mtdblock1 
> rw rootfstype=jffs2

This looks reasonable, and is telling the kernel to boot from the 2nd
partition in your QSPI. And it is specifying the filesystem type
which is also required for JFFS2, as it cannot be auto-detected.

However looking through the remaining kernel boot messages, I do not see
any indication of the kernel having detected the QSPI device. And
therefore it also does not know about partitions on this device.

This could be caused either by missing some kernel configuration
settings (eg. QSPI driver, MTD subsystem, etc) or by missing entries in
the device tree (DTS) files.

The offset in the QSPI is specified in the partition table, which
usually goes into the device tree.

Regards,
-Ralph
___
Rfi mailing list
Rfi@lists.rocketboards.org
http://lists.rocketboards.org/cgi-bin/mailman/listinfo/rfi