Hi Liang,
I am trying to add support for older SoCs to the meson-nand driver.
Back when the driver was in development I used an early revision (of
your driver) and did some modifications to make it work on older SoCs.
Now that the driver is upstream I wanted to give it another try and
make a real patch out of it. Unfortunately it's not working anymore.
As far as I know the NFC IP block revision on GXL is similar (or even
the same?) as on all older SoCs. As far as I can tell only the clock
setup is different on the older SoCs (which have a dedicated NAND
clock):
- we don't need the "amlogic,mmc-syscon" property on the older SoCs
because we don't need to setup any muxing (common clock framework
will do everything for us)
- "rx" and "tx" clocks don't exist
- I could not find any other differences between Meson8, Meson8b,
Meson8m2, GXBB and GXL
In this series I'm sending two patches which add support for the older
SoCs.
Unfortunately these patches are currently not working for me (hence the
"RFC" prefix). I get a (strange) crash which is triggered by the
kzalloc() in meson_nfc_read_buf() - see below for more details.
Can you please help me on this one? I'd like to know whether:
- the meson-nand driver works for you on GXL or AXG on linux-next?
(I was running these patches on top of next-20190301 on my M8S
board which uses a 32-bit Meson8m2 SoC. I don't have any board using
a GXL SoC which also has NAND)
- you see any issue with my patches? (maybe I missed more differences
between GXL and the older SoCs)
kernel log extract:
[...]
Could not find a valid ONFI parameter page, trying bit-wise majority to recover it
ONFI parameter recovery failed, aborting
Unable to handle kernel paging request at virtual address 80110000
pgd = (ptrval)
[80110000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc8-next-20190301-00053-g50ac6f7757e2 #4145
Hardware name: Amlogic Meson platform
PC is at kmem_cache_alloc_trace+0xc8/0x268
LR is at kmem_cache_alloc_trace+0x2c/0x268
pc : [<c046479c>] lr : [<c0464700>] psr: 60000013
sp : c02adc58 ip : e9e7a440 fp : 00004ee2
r10: 80110000 r9 : ffffe000 r8 : c110918c
r7 : 00000008 r6 : c08967c0 r5 : 00000dc0 r4 : c0201e40
r3 : c109dd30 r2 : 00000000 r1 : 00004ee2 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 0020404a DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
Stack: (0xc02adc58 to 0xc02ae000)
dc40: e9d84048 00000003
dc60: e9e7a440 c02add18 00000028 e9e68680 c02adcf0 00000003 e9d84048 00000002
dc80: e9e7a440 c08967c0 c1108cb4 c02adcdc 10624dd3 c02adce4 10624dd3 00000005
dca0: e9e7a440 c0f5c310 00000028 c0f09998 00000005 e9d84048 00000005 c02add57
dcc0: c1108c88 e9e7a440 c02adcf0 e9d84428 e9d843b0 c0882258 000000ff 40000000
dce0: c02adce8 00000000 c02adcf0 00000003 00000000 00000090 00000000 00000000
dd00: 00000000 00000001 00000001 c02adcdf 00000000 00000190 00000002 00000005
dd20: c02add57 00000001 00000000 a10a1ef7 00000000 c1108c88 c1180250 e9d843c0
dd40: 00000001 000000de 00000000 c088d114 c0f08db4 00d843c0 00000000 a10a1ef7
dd60: 00000015 e9d84048 c1108c88 c088d470 e9d84048 c08888b4 00000000 60000013
dd80: c0eebc9c 000000ad c0da01ac 00000000 e9e7a48c c0cc6d50 c12122cc a10a1ef7
dda0: e9e7a440 e9e7a440 e9d84040 c0eebc9c e987f410 eafd6748 e9d84048 c1108c88
ddc0: e9e7a48c c0895c70 00000000 e9871f00 e9e7a440 c04eef60 00000000 eafd64bc
dde0: e9e7a534 00000000 00000000 00000000 00000001 a10a1ef7 00000000 e987f410
de00: 00000000 c1180728 00000000 00000000 c1180728 00000000 c1071854 c07fd388
de20: c120da38 e987f410 c120da3c 00000000 00000000 c07fb410 e987f410 c1180728
de40: c1180728 c07fb910 00000000 c1071834 c10004a8 c07fb65c c10004a8 c0a917b4
de60: c0da1914 e987f410 00000000 c1180728 c07fb910 00000000 c1071834 c10004a8
de80: c1071854 c07fb908 00000000 c1180728 e987f410 c07fb968 e98b8eb4 c1108c88
dea0: c1180728 c07f97d4 c1175260 c029a958 e98b8eb4 a10a1ef7 c029a96c c1180728
dec0: e9e1fa80 c1175260 00000000 c07fa844 c0f09c64 c1108c88 ffffe000 c1180728
dee0: c1108c88 ffffe000 c103b788 c07fc494 c11c2ca0 c1108c88 ffffe000 c0302f1c
df00: ebfffd96 c0346f90 c0fab8a0 c0f2ad00 00000000 00000006 00000006 c0e9e26c
df20: 00000000 c1108c88 c0eb11b0 c0e9e2e0 c11d1300 ebfffd84 ebfffd89 a10a1ef7
df40: c1071838 c11c2ca0 c10914b8 a10a1ef7 c11c2ca0 c1091804 00000007 c11d1300
df60: c11d1300 c1001180 00000006 00000006 00000000 c10004a8 0000013d 00000000
df80: c02c0504 00000000 c0cbf6e8 00000000 00000000 00000000 00000000 00000000
dfa0: 00000000 c0cbf6f0 00000000 c03010e8 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c046479c>] (kmem_cache_alloc_trace) from [<c08967c0>] (meson_nfc_exec_op+0x2c4/0x3e8)
[<c08967c0>] (meson_nfc_exec_op) from [<c0882258>] (nand_readid_op+0x128/0x1c4)
[<c0882258>] (nand_readid_op) from [<c088d114>] (hynix_nand_has_valid_jedecid+0x34/0x78)
[<c088d114>] (hynix_nand_has_valid_jedecid) from [<c088d470>] (hynix_nand_decode_id+0x64/0x3fc)
[<c088d470>] (hynix_nand_decode_id) from [<c08888b4>] (nand_scan_with_ids+0xa04/0x171c)
[<c08888b4>] (nand_scan_with_ids) from [<c0895c70>] (meson_nfc_probe+0x460/0x690)
[<c0895c70>] (meson_nfc_probe) from [<c07fd388>] (platform_drv_probe+0x48/0x98)
[<c07fd388>] (platform_drv_probe) from [<c07fb410>] (really_probe+0x1e0/0x2cc)
[<c07fb410>] (really_probe) from [<c07fb65c>] (driver_probe_device+0x60/0x16c)
[<c07fb65c>] (driver_probe_device) from [<c07fb908>] (device_driver_attach+0x58/0x60)
[<c07fb908>] (device_driver_attach) from [<c07fb968>] (__driver_attach+0x58/0xcc)
[<c07fb968>] (__driver_attach) from [<c07f97d4>] (bus_for_each_dev+0x74/0xb4)
[<c07f97d4>] (bus_for_each_dev) from [<c07fa844>] (bus_add_driver+0x1b8/0x1d8)
[<c07fa844>] (bus_add_driver) from [<c07fc494>] (driver_register+0x74/0x108)
[<c07fc494>] (driver_register) from [<c0302f1c>] (do_one_initcall+0x54/0x284)
[<c0302f1c>] (do_one_initcall) from [<c1001180>] (kernel_init_freeable+0x2d4/0x36c)
[<c1001180>] (kernel_init_freeable) from [<c0cbf6f0>] (kernel_init+0x8/0x110)
[<c0cbf6f0>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xc02adfb0 to 0xc02adff8)
dfa0: 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e5943000 e5942014 e3130007 1a000038 (e79ae002)
---[ end trace 28d391ed14b0f021 ]---
Martin Blumenstingl (2):
dt-bindings: nand: meson: add support for more SoCs
mtd: rawnand: meson: support for older SoCs up to Meson8
.../bindings/mtd/amlogic,meson-nand.txt | 14 ++++--
drivers/mtd/nand/raw/meson_nand.c | 46 +++++++++++++------
2 files changed, 42 insertions(+), 18 deletions(-)
--
2.21.0
This adds support for the following SoCs to the meson-nand driver:
- Meson8 (assuming Meson8m2 uses the same IP block revision)
- Meson8b
- GXBB
The clock setup is the only difference between GXL and the older SoCs.
Compared to GXL and AXG these older SoCs:
- have a dedicated NAND clock instead of one that's shared with
sd_emmc_c
- use the same ECC capabilities as GXL (up to 60-bits ECC)
The "amlogic,mmc-syscon" property is not required on these older SoCs
because the NAND clock is not shared with the sd_emmc_c controller. The
syscon from that property is used to switch the clock output between the
NAND controller and the sd_emmc_c controller on the newer SoCs.
The "rx" and "tx" clocks also don't exist on the older SoCs which also
means that the phase cannot be controlled there. Obtain these clocks
using devm_clk_get_optional() which will return NULL if they were not
passed via device-tree. None of the "consumers" of the "rx" and "tx"
clocks (within the meson-nand driver) have to be adjusted because the
common clock framework is NULL-safe (meaning NULL-clocks can be passed,
clk_prepare_enable() and clk_disable_unprepare() are no-ops in that
case).
Signed-off-by: Martin Blumenstingl <[email protected]>
---
drivers/mtd/nand/raw/meson_nand.c | 46 ++++++++++++++++++++++---------
1 file changed, 33 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
index 38db4fd61459..2a5f9ce5db9b 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -128,6 +128,7 @@ struct meson_nand_ecc {
struct meson_nfc_data {
const struct nand_ecc_caps *ecc_caps;
+ bool has_mmc_syscon;
};
struct meson_nfc_param {
@@ -209,7 +210,7 @@ static int meson_nand_calc_ecc_bytes(int step_size, int strength)
return ecc_bytes;
}
-NAND_ECC_CAPS_SINGLE(meson_gxl_ecc_caps,
+NAND_ECC_CAPS_SINGLE(meson8_ecc_caps,
meson_nand_calc_ecc_bytes, 1024, 8, 24, 30, 40, 50, 60);
NAND_ECC_CAPS_SINGLE(meson_axg_ecc_caps,
meson_nand_calc_ecc_bytes, 1024, 8);
@@ -999,21 +1000,22 @@ static int meson_nfc_clk_init(struct meson_nfc *nfc)
return PTR_ERR(nfc->device_clk);
}
- nfc->phase_tx = devm_clk_get(nfc->dev, "tx");
+ nfc->phase_tx = devm_clk_get_optional(nfc->dev, "tx");
if (IS_ERR(nfc->phase_tx)) {
dev_err(nfc->dev, "failed to get TX clk\n");
return PTR_ERR(nfc->phase_tx);
}
- nfc->phase_rx = devm_clk_get(nfc->dev, "rx");
+ nfc->phase_rx = devm_clk_get_optional(nfc->dev, "rx");
if (IS_ERR(nfc->phase_rx)) {
dev_err(nfc->dev, "failed to get RX clk\n");
return PTR_ERR(nfc->phase_rx);
}
- /* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
- regmap_update_bits(nfc->reg_clk,
- 0, CLK_SELECT_NAND, CLK_SELECT_NAND);
+ if (nfc->data->has_mmc_syscon)
+ /* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
+ regmap_update_bits(nfc->reg_clk,
+ 0, CLK_SELECT_NAND, CLK_SELECT_NAND);
ret = clk_prepare_enable(nfc->core_clk);
if (ret) {
@@ -1345,16 +1347,32 @@ static irqreturn_t meson_nfc_irq(int irq, void *id)
return IRQ_HANDLED;
}
+static const struct meson_nfc_data meson8_data = {
+ .ecc_caps = &meson8_ecc_caps,
+ .has_mmc_syscon = false,
+};
+
static const struct meson_nfc_data meson_gxl_data = {
- .ecc_caps = &meson_gxl_ecc_caps,
+ .ecc_caps = &meson8_ecc_caps,
+ .has_mmc_syscon = true,
};
static const struct meson_nfc_data meson_axg_data = {
.ecc_caps = &meson_axg_ecc_caps,
+ .has_mmc_syscon = true,
};
static const struct of_device_id meson_nfc_id_table[] = {
{
+ .compatible = "amlogic,meson8-nfc",
+ .data = &meson8_data,
+ }, {
+ .compatible = "amlogic,meson8b-nfc",
+ .data = &meson8_data,
+ }, {
+ .compatible = "amlogic,meson-gxbb-nfc",
+ .data = &meson8_data,
+ }, {
.compatible = "amlogic,meson-gxl-nfc",
.data = &meson_gxl_data,
}, {
@@ -1390,12 +1408,14 @@ static int meson_nfc_probe(struct platform_device *pdev)
if (IS_ERR(nfc->reg_base))
return PTR_ERR(nfc->reg_base);
- nfc->reg_clk =
- syscon_regmap_lookup_by_phandle(dev->of_node,
- "amlogic,mmc-syscon");
- if (IS_ERR(nfc->reg_clk)) {
- dev_err(dev, "Failed to lookup clock base\n");
- return PTR_ERR(nfc->reg_clk);
+ if (nfc->data->has_mmc_syscon) {
+ nfc->reg_clk =
+ syscon_regmap_lookup_by_phandle(dev->of_node,
+ "amlogic,mmc-syscon");
+ if (IS_ERR(nfc->reg_clk)) {
+ dev_err(dev, "Failed to lookup clock base\n");
+ return PTR_ERR(nfc->reg_clk);
+ }
}
irq = platform_get_irq(pdev, 0);
--
2.21.0
Older Amlogic SoCs have a slightly different integration of the NFC
(NAND flash controller) than the new ones (GXL, GXM, AXG).
On GXL, AXG and newer the "NAND device clock" is shared with sd_emmc_c.
This requires muxing the signal of that clock between the sd_emmc_c
controller and the NAND controller. The "amlogic,mmc-syscon" property
exists for this purpose.
Older SoCs (Meson8, Meson8b, Meson8m2 and GXBB) have a dedicated "NAND
device clock". Thus we don't need to "amlogic,mmc-syscon" property for
muxing the clock on these older SoCs.
The clock implementation itself is also more advanced on newer SoCs
because the phase of the RX and TX clock can be controlled. Older SoCs
cannot change the phase of the "NAND device clock". Thus the "rx" and
"tx" clock-names are only required for the GXL, GXM and AXG SoCs.
Signed-off-by: Martin Blumenstingl <[email protected]>
---
.../devicetree/bindings/mtd/amlogic,meson-nand.txt | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
index 3983c11e062c..8766d4e82a74 100644
--- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.txt
@@ -5,6 +5,9 @@ the MTD NAND bindings.
Required properties:
- compatible : contains one of:
+ - "amlogic,meson8-nfc"
+ - "amlogic,meson8b-nfc"
+ - "amlogic,meson-gxbb-nfc"
- "amlogic,meson-gxl-nfc"
- "amlogic,meson-axg-nfc"
- clocks :
@@ -13,12 +16,13 @@ Required properties:
- clock-names: Should contain the following:
"core" - NFC module gate clock
- "device" - device clock from eMMC sub clock controller
- "rx" - rx clock phase
- "tx" - tx clock phase
+ "device" - NAND device clock
+ "rx" - rx clock phase, only used on the GXL, GXM and AXG SoCs.
+ "tx" - tx clock phase, only used on the GXL, GXM and AXG SoCs.
-- amlogic,mmc-syscon : Required for NAND clocks, it's shared with SD/eMMC
- controller port C
+- amlogic,mmc-syscon : Only used on the GXL, GXM and AXG SoCs.
+ Required for NAND clocks, it's shared with SD/eMMC
+ controller port C
Optional children nodes:
Children nodes represent the available nand chips.
--
2.21.0
Hello Martin,
On 2019/3/2 2:29, Martin Blumenstingl wrote:
> Hi Liang,
>
> I am trying to add support for older SoCs to the meson-nand driver.
> Back when the driver was in development I used an early revision (of
> your driver) and did some modifications to make it work on older SoCs.
>
> Now that the driver is upstream I wanted to give it another try and
> make a real patch out of it. Unfortunately it's not working anymore.
>
> As far as I know the NFC IP block revision on GXL is similar (or even
> the same?) as on all older SoCs. As far as I can tell only the clock
> setup is different on the older SoCs (which have a dedicated NAND
> clock):
> - we don't need the "amlogic,mmc-syscon" property on the older SoCs
> because we don't need to setup any muxing (common clock framework
> will do everything for us)
> - "rx" and "tx" clocks don't exist
> - I could not find any other differences between Meson8, Meson8b,
> Meson8m2, GXBB and GXL
>
That is right. the serials NFC is almost the same except:
1) The clock control and source that M8-serials are not share with EMMC.
2) The base register address
3) DMA encryption option which we don't care on NFC driver.
> In this series I'm sending two patches which add support for the older
> SoCs.
>
> Unfortunately these patches are currently not working for me (hence the
> "RFC" prefix). I get a (strange) crash which is triggered by the
> kzalloc() in meson_nfc_read_buf() - see below for more details.
>
> Can you please help me on this one? I'd like to know whether:
> - the meson-nand driver works for you on GXL or AXG on linux-next?
> (I was running these patches on top of next-20190301 on my M8S
> board which uses a 32-bit Meson8m2 SoC. I don't have any board using
> a GXL SoC which also has NAND)
Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but
i an not sure it runs the same flow with yours. because i see the print
"Counld not find a valid ONFI parameter page, ...." in yours. i will try
to reproduce it on AXG(i don't have a M8 platform now).
> - you see any issue with my patches? (maybe I missed more differences
> between GXL and the older SoCs)
>
i think it is ok now.
>
> kernel log extract:
> [...]
> Could not find a valid ONFI parameter page, trying bit-wise majority to recover it
> ONFI parameter recovery failed, aborting
> Unable to handle kernel paging request at virtual address 80110000
> pgd = (ptrval)
> [80110000] *pgd=00000000
> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc8-next-20190301-00053-g50ac6f7757e2 #4145
> Hardware name: Amlogic Meson platform
> PC is at kmem_cache_alloc_trace+0xc8/0x268
> LR is at kmem_cache_alloc_trace+0x2c/0x268
> pc : [<c046479c>] lr : [<c0464700>] psr: 60000013
> sp : c02adc58 ip : e9e7a440 fp : 00004ee2
> r10: 80110000 r9 : ffffe000 r8 : c110918c
> r7 : 00000008 r6 : c08967c0 r5 : 00000dc0 r4 : c0201e40
> r3 : c109dd30 r2 : 00000000 r1 : 00004ee2 r0 : 00000000
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 0020404a DAC: 00000051
> Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
> Stack: (0xc02adc58 to 0xc02ae000)
> dc40: e9d84048 00000003
> dc60: e9e7a440 c02add18 00000028 e9e68680 c02adcf0 00000003 e9d84048 00000002
> dc80: e9e7a440 c08967c0 c1108cb4 c02adcdc 10624dd3 c02adce4 10624dd3 00000005
> dca0: e9e7a440 c0f5c310 00000028 c0f09998 00000005 e9d84048 00000005 c02add57
> dcc0: c1108c88 e9e7a440 c02adcf0 e9d84428 e9d843b0 c0882258 000000ff 40000000
> dce0: c02adce8 00000000 c02adcf0 00000003 00000000 00000090 00000000 00000000
> dd00: 00000000 00000001 00000001 c02adcdf 00000000 00000190 00000002 00000005
> dd20: c02add57 00000001 00000000 a10a1ef7 00000000 c1108c88 c1180250 e9d843c0
> dd40: 00000001 000000de 00000000 c088d114 c0f08db4 00d843c0 00000000 a10a1ef7
> dd60: 00000015 e9d84048 c1108c88 c088d470 e9d84048 c08888b4 00000000 60000013
> dd80: c0eebc9c 000000ad c0da01ac 00000000 e9e7a48c c0cc6d50 c12122cc a10a1ef7
> dda0: e9e7a440 e9e7a440 e9d84040 c0eebc9c e987f410 eafd6748 e9d84048 c1108c88
> ddc0: e9e7a48c c0895c70 00000000 e9871f00 e9e7a440 c04eef60 00000000 eafd64bc
> dde0: e9e7a534 00000000 00000000 00000000 00000001 a10a1ef7 00000000 e987f410
> de00: 00000000 c1180728 00000000 00000000 c1180728 00000000 c1071854 c07fd388
> de20: c120da38 e987f410 c120da3c 00000000 00000000 c07fb410 e987f410 c1180728
> de40: c1180728 c07fb910 00000000 c1071834 c10004a8 c07fb65c c10004a8 c0a917b4
> de60: c0da1914 e987f410 00000000 c1180728 c07fb910 00000000 c1071834 c10004a8
> de80: c1071854 c07fb908 00000000 c1180728 e987f410 c07fb968 e98b8eb4 c1108c88
> dea0: c1180728 c07f97d4 c1175260 c029a958 e98b8eb4 a10a1ef7 c029a96c c1180728
> dec0: e9e1fa80 c1175260 00000000 c07fa844 c0f09c64 c1108c88 ffffe000 c1180728
> dee0: c1108c88 ffffe000 c103b788 c07fc494 c11c2ca0 c1108c88 ffffe000 c0302f1c
> df00: ebfffd96 c0346f90 c0fab8a0 c0f2ad00 00000000 00000006 00000006 c0e9e26c
> df20: 00000000 c1108c88 c0eb11b0 c0e9e2e0 c11d1300 ebfffd84 ebfffd89 a10a1ef7
> df40: c1071838 c11c2ca0 c10914b8 a10a1ef7 c11c2ca0 c1091804 00000007 c11d1300
> df60: c11d1300 c1001180 00000006 00000006 00000000 c10004a8 0000013d 00000000
> df80: c02c0504 00000000 c0cbf6e8 00000000 00000000 00000000 00000000 00000000
> dfa0: 00000000 c0cbf6f0 00000000 c03010e8 00000000 00000000 00000000 00000000
> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c046479c>] (kmem_cache_alloc_trace) from [<c08967c0>] (meson_nfc_exec_op+0x2c4/0x3e8)
> [<c08967c0>] (meson_nfc_exec_op) from [<c0882258>] (nand_readid_op+0x128/0x1c4)
> [<c0882258>] (nand_readid_op) from [<c088d114>] (hynix_nand_has_valid_jedecid+0x34/0x78)
> [<c088d114>] (hynix_nand_has_valid_jedecid) from [<c088d470>] (hynix_nand_decode_id+0x64/0x3fc)
> [<c088d470>] (hynix_nand_decode_id) from [<c08888b4>] (nand_scan_with_ids+0xa04/0x171c)
> [<c08888b4>] (nand_scan_with_ids) from [<c0895c70>] (meson_nfc_probe+0x460/0x690)
> [<c0895c70>] (meson_nfc_probe) from [<c07fd388>] (platform_drv_probe+0x48/0x98)
> [<c07fd388>] (platform_drv_probe) from [<c07fb410>] (really_probe+0x1e0/0x2cc)
> [<c07fb410>] (really_probe) from [<c07fb65c>] (driver_probe_device+0x60/0x16c)
> [<c07fb65c>] (driver_probe_device) from [<c07fb908>] (device_driver_attach+0x58/0x60)
> [<c07fb908>] (device_driver_attach) from [<c07fb968>] (__driver_attach+0x58/0xcc)
> [<c07fb968>] (__driver_attach) from [<c07f97d4>] (bus_for_each_dev+0x74/0xb4)
> [<c07f97d4>] (bus_for_each_dev) from [<c07fa844>] (bus_add_driver+0x1b8/0x1d8)
> [<c07fa844>] (bus_add_driver) from [<c07fc494>] (driver_register+0x74/0x108)
> [<c07fc494>] (driver_register) from [<c0302f1c>] (do_one_initcall+0x54/0x284)
> [<c0302f1c>] (do_one_initcall) from [<c1001180>] (kernel_init_freeable+0x2d4/0x36c)
> [<c1001180>] (kernel_init_freeable) from [<c0cbf6f0>] (kernel_init+0x8/0x110)
> [<c0cbf6f0>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xc02adfb0 to 0xc02adff8)
> dfa0: 00000000 00000000 00000000 00000000
> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: e5943000 e5942014 e3130007 1a000038 (e79ae002)
> ---[ end trace 28d391ed14b0f021 ]---
>
>
> Martin Blumenstingl (2):
> dt-bindings: nand: meson: add support for more SoCs
> mtd: rawnand: meson: support for older SoCs up to Meson8
>
> .../bindings/mtd/amlogic,meson-nand.txt | 14 ++++--
> drivers/mtd/nand/raw/meson_nand.c | 46 +++++++++++++------
> 2 files changed, 42 insertions(+), 18 deletions(-)
>
Hi Liang,
On Mon, Mar 4, 2019 at 5:55 AM Liang Yang <[email protected]> wrote:
>
> Hello Martin,
>
> On 2019/3/2 2:29, Martin Blumenstingl wrote:
> > Hi Liang,
> >
> > I am trying to add support for older SoCs to the meson-nand driver.
> > Back when the driver was in development I used an early revision (of
> > your driver) and did some modifications to make it work on older SoCs.
> >
> > Now that the driver is upstream I wanted to give it another try and
> > make a real patch out of it. Unfortunately it's not working anymore.
> >
> > As far as I know the NFC IP block revision on GXL is similar (or even
> > the same?) as on all older SoCs. As far as I can tell only the clock
> > setup is different on the older SoCs (which have a dedicated NAND
> > clock):
> > - we don't need the "amlogic,mmc-syscon" property on the older SoCs
> > because we don't need to setup any muxing (common clock framework
> > will do everything for us)
> > - "rx" and "tx" clocks don't exist
> > - I could not find any other differences between Meson8, Meson8b,
> > Meson8m2, GXBB and GXL
> >
> That is right. the serials NFC is almost the same except:
> 1) The clock control and source that M8-serials are not share with EMMC.
> 2) The base register address
> 3) DMA encryption option which we don't care on NFC driver.
great, thank you for confirming this!
> > In this series I'm sending two patches which add support for the older
> > SoCs.
> >
> > Unfortunately these patches are currently not working for me (hence the
> > "RFC" prefix). I get a (strange) crash which is triggered by the
> > kzalloc() in meson_nfc_read_buf() - see below for more details.
> >
> > Can you please help me on this one? I'd like to know whether:
> > - the meson-nand driver works for you on GXL or AXG on linux-next?
> > (I was running these patches on top of next-20190301 on my M8S
> > board which uses a 32-bit Meson8m2 SoC. I don't have any board using
> > a GXL SoC which also has NAND)
> Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but
> i an not sure it runs the same flow with yours. because i see the print
> "Counld not find a valid ONFI parameter page, ...." in yours. i will try
> to reproduce it on AXG(i don't have a M8 platform now).
I'm looking forward to hear about the test results on your AXG boards
for reference: my board has a SK Hynix H27UCG8T2B (ID bytes: 0xad 0xde
0x94 0xeb 0x74 0x44, 20nm MLC)
I have another board (where I haven't tested the NFC driver yet) with
a SK Hynix H27UCG8T2E (ID bytes: 0xad 0xde 0x14 0xa7 0x42 0x4a, 1Ynm
MLC). if it helps with your analysis I can test on that board as well
> > - you see any issue with my patches? (maybe I missed more differences
> > between GXL and the older SoCs)
> >
> i think it is ok now.
many thanks for checking my patches!
Regards
Martin
Hello,
Martin Blumenstingl <[email protected]> wrote on Tue,
5 Mar 2019 23:12:51 +0100:
> Hi Liang,
>
> On Mon, Mar 4, 2019 at 5:55 AM Liang Yang <[email protected]> wrote:
> >
> > Hello Martin,
> >
> > On 2019/3/2 2:29, Martin Blumenstingl wrote:
> > > Hi Liang,
> > >
> > > I am trying to add support for older SoCs to the meson-nand driver.
> > > Back when the driver was in development I used an early revision (of
> > > your driver) and did some modifications to make it work on older SoCs.
> > >
> > > Now that the driver is upstream I wanted to give it another try and
> > > make a real patch out of it. Unfortunately it's not working anymore.
> > >
> > > As far as I know the NFC IP block revision on GXL is similar (or even
> > > the same?) as on all older SoCs. As far as I can tell only the clock
> > > setup is different on the older SoCs (which have a dedicated NAND
> > > clock):
> > > - we don't need the "amlogic,mmc-syscon" property on the older SoCs
> > > because we don't need to setup any muxing (common clock framework
> > > will do everything for us)
> > > - "rx" and "tx" clocks don't exist
> > > - I could not find any other differences between Meson8, Meson8b,
> > > Meson8m2, GXBB and GXL
> > >
> > That is right. the serials NFC is almost the same except:
> > 1) The clock control and source that M8-serials are not share with EMMC.
> > 2) The base register address
> > 3) DMA encryption option which we don't care on NFC driver.
> great, thank you for confirming this!
>
> > > In this series I'm sending two patches which add support for the older
> > > SoCs.
> > >
> > > Unfortunately these patches are currently not working for me (hence the
> > > "RFC" prefix). I get a (strange) crash which is triggered by the
> > > kzalloc() in meson_nfc_read_buf() - see below for more details.
> > >
> > > Can you please help me on this one? I'd like to know whether:
> > > - the meson-nand driver works for you on GXL or AXG on linux-next?
> > > (I was running these patches on top of next-20190301 on my M8S
> > > board which uses a 32-bit Meson8m2 SoC. I don't have any board using
> > > a GXL SoC which also has NAND)
> > Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but
> > i an not sure it runs the same flow with yours. because i see the print
> > "Counld not find a valid ONFI parameter page, ...." in yours. i will try
> > to reproduce it on AXG(i don't have a M8 platform now).
> I'm looking forward to hear about the test results on your AXG boards
> for reference: my board has a SK Hynix H27UCG8T2B (ID bytes: 0xad 0xde
> 0x94 0xeb 0x74 0x44, 20nm MLC)
> I have another board (where I haven't tested the NFC driver yet) with
> a SK Hynix H27UCG8T2E (ID bytes: 0xad 0xde 0x14 0xa7 0x42 0x4a, 1Ynm
> MLC). if it helps with your analysis I can test on that board as well
Liang, you just have to fake the output of the ONFI page detection and
you will probably run into this error which will then be easy to
reproduce.
Thanks,
Miquèl
Hi Martin,
On 2019/3/7 21:09, Miquel Raynal wrote:
> Hello,
>
> Martin Blumenstingl <[email protected]> wrote on Tue,
> 5 Mar 2019 23:12:51 +0100:
>
>> Hi Liang,
>>
>> On Mon, Mar 4, 2019 at 5:55 AM Liang Yang <[email protected]> wrote:
>>>
>>> Hello Martin,
>>>
>>> On 2019/3/2 2:29, Martin Blumenstingl wrote:
>>>> Hi Liang,
>>>>
>>>> I am trying to add support for older SoCs to the meson-nand driver.
>>>> Back when the driver was in development I used an early revision (of
>>>> your driver) and did some modifications to make it work on older SoCs.
>>>>
>>>> Now that the driver is upstream I wanted to give it another try and
>>>> make a real patch out of it. Unfortunately it's not working anymore.
>>>>
>>>> As far as I know the NFC IP block revision on GXL is similar (or even
>>>> the same?) as on all older SoCs. As far as I can tell only the clock
>>>> setup is different on the older SoCs (which have a dedicated NAND
>>>> clock):
>>>> - we don't need the "amlogic,mmc-syscon" property on the older SoCs
>>>> because we don't need to setup any muxing (common clock framework
>>>> will do everything for us)
>>>> - "rx" and "tx" clocks don't exist
>>>> - I could not find any other differences between Meson8, Meson8b,
>>>> Meson8m2, GXBB and GXL
>>>>
>>> That is right. the serials NFC is almost the same except:
>>> 1) The clock control and source that M8-serials are not share with EMMC.
>>> 2) The base register address
>>> 3) DMA encryption option which we don't care on NFC driver.
>> great, thank you for confirming this!
>>
>>>> In this series I'm sending two patches which add support for the older
>>>> SoCs.
>>>>
>>>> Unfortunately these patches are currently not working for me (hence the
>>>> "RFC" prefix). I get a (strange) crash which is triggered by the
>>>> kzalloc() in meson_nfc_read_buf() - see below for more details.
>>>>
>>>> Can you please help me on this one? I'd like to know whether:
>>>> - the meson-nand driver works for you on GXL or AXG on linux-next?
>>>> (I was running these patches on top of next-20190301 on my M8S
>>>> board which uses a 32-bit Meson8m2 SoC. I don't have any board using
>>>> a GXL SoC which also has NAND)
>>> Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but
>>> i an not sure it runs the same flow with yours. because i see the print
>>> "Counld not find a valid ONFI parameter page, ...." in yours. i will try
>>> to reproduce it on AXG(i don't have a M8 platform now).
>> I'm looking forward to hear about the test results on your AXG boards
>> for reference: my board has a SK Hynix H27UCG8T2B (ID bytes: 0xad 0xde
>> 0x94 0xeb 0x74 0x44, 20nm MLC)
>> I have another board (where I haven't tested the NFC driver yet) with
>> a SK Hynix H27UCG8T2E (ID bytes: 0xad 0xde 0x14 0xa7 0x42 0x4a, 1Ynm
>> MLC). if it helps with your analysis I can test on that board as well
>
> Liang, you just have to fake the output of the ONFI page detection and
> you will probably run into this error which will then be easy to
> reproduce.
>
I have tested it on AXG platform; I find MX30LF4G also enter this flow ,
but it doesn't crash. log as follow:
[ 1.018056] Could not find a valid ONFI parameter page, trying
bit-wise majority to recover it
[ 1.021057] ONFI parameter recovery failed, aborting
[ 1.025966] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
[ 1.032237] nand: Macronix NAND 512MiB 3,3V 8-bit
[ 1.036889] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048,
OOB size: 64
[ 1.045741] Bad block table not found for chip 0
[ 1.050077] Bad block table not found for chip 0
[ 1.053538] Scanning device for bad blocks
[ 1.069094] Bad eraseblock 20 at 0x000000280000
[ 1.071074] Bad eraseblock 24 at 0x000000300000
[ 1.127494] random: fast init done
[ 1.348754] Bad eraseblock 519 at 0x0000040e0000
[ 1.632819] Bad eraseblock 1028 at 0x000008080000
[ 2.405420] Bad eraseblock 2411 at 0x000012d60000
[ 3.349276] Bad block table written to 0x00001ffe0000, version 0x01
[ 3.350967] Bad block table written to 0x00001ffc0000, version 0x01
[ 3.356429] 5 fixed-partitions partitions found on MTD device
ffe07800.nfc
[ 3.362925] Creating 5 MTD partitions on "ffe07800.nfc":
[ 3.368188] 0x000000000000-0x000000200000 : "boot"
[ 3.373970] 0x000000200000-0x000000600000 : "env"
[ 3.378564] 0x000000600000-0x000001000000 : "system"
[ 3.383511] 0x000001000000-0x000004000000 : "rootfs"
[ 3.388525] 0x000004000000-0x00000c000000 : "media"
I am looking forward to a Hynix nand flash to test on GXL platform, and
there should be something different from MXIC flash on ONFI page
detection. I will update the result asap net week.
Do you have another type of nand flash to test on M8 platform ?
>
> Thanks,
> Miquèl
>
> .
>
Hi Martin and Miquel,
On 2019/3/7 21:09, Miquel Raynal wrote:
> Hello,
>
> Martin Blumenstingl <[email protected]> wrote on Tue,
> 5 Mar 2019 23:12:51 +0100:
>
>> Hi Liang,
>>
>> On Mon, Mar 4, 2019 at 5:55 AM Liang Yang <[email protected]> wrote:
>>>
>>> Hello Martin,
>>>
>>> On 2019/3/2 2:29, Martin Blumenstingl wrote:
>>>> Hi Liang,
>>>>
>>>> I am trying to add support for older SoCs to the meson-nand driver.
>>>> Back when the driver was in development I used an early revision (of
>>>> your driver) and did some modifications to make it work on older SoCs.
>>>>
>>>> Now that the driver is upstream I wanted to give it another try and
>>>> make a real patch out of it. Unfortunately it's not working anymore.
>>>>
>>>> As far as I know the NFC IP block revision on GXL is similar (or even
>>>> the same?) as on all older SoCs. As far as I can tell only the clock
>>>> setup is different on the older SoCs (which have a dedicated NAND
>>>> clock):
>>>> - we don't need the "amlogic,mmc-syscon" property on the older SoCs
>>>> because we don't need to setup any muxing (common clock framework
>>>> will do everything for us)
>>>> - "rx" and "tx" clocks don't exist
>>>> - I could not find any other differences between Meson8, Meson8b,
>>>> Meson8m2, GXBB and GXL
>>>>
>>> That is right. the serials NFC is almost the same except:
>>> 1) The clock control and source that M8-serials are not share with EMMC.
>>> 2) The base register address
>>> 3) DMA encryption option which we don't care on NFC driver.
>> great, thank you for confirming this!
>>
>>>> In this series I'm sending two patches which add support for the older
>>>> SoCs.
>>>>
>>>> Unfortunately these patches are currently not working for me (hence the
>>>> "RFC" prefix). I get a (strange) crash which is triggered by the
>>>> kzalloc() in meson_nfc_read_buf() - see below for more details.
>>>>
>>>> Can you please help me on this one? I'd like to know whether:
>>>> - the meson-nand driver works for you on GXL or AXG on linux-next?
>>>> (I was running these patches on top of next-20190301 on my M8S
>>>> board which uses a 32-bit Meson8m2 SoC. I don't have any board using
>>>> a GXL SoC which also has NAND)
>>> Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but
>>> i an not sure it runs the same flow with yours. because i see the print
>>> "Counld not find a valid ONFI parameter page, ...." in yours. i will try
>>> to reproduce it on AXG(i don't have a M8 platform now).
>> I'm looking forward to hear about the test results on your AXG boards
>> for reference: my board has a SK Hynix H27UCG8T2B (ID bytes: 0xad 0xde
>> 0x94 0xeb 0x74 0x44, 20nm MLC)
>> I have another board (where I haven't tested the NFC driver yet) with
>> a SK Hynix H27UCG8T2E (ID bytes: 0xad 0xde 0x14 0xa7 0x42 0x4a, 1Ynm
>> MLC). if it helps with your analysis I can test on that board as well
>
> Liang, you just have to fake the output of the ONFI page detection and
> you will probably run into this error which will then be easy to
> reproduce.
>
i don't reproduce it by using a SK Hynix nand flash H27UCG8T2E on gxl
platform. it runs well.
[......]
[ 0.977127] loop: module loaded
[ 0.998625] Could not find a valid ONFI parameter page, trying
bit-wise majority to recover it
[ 1.001619] ONFI parameter recovery failed, aborting
[ 1.006684] Could not find valid JEDEC parameter page; aborting
[ 1.012391] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde
[ 1.018660] nand: Hynix NAND 8GiB 3,3V 8-bit
[ 1.022885] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size:
16384, OOB size: 1664
[ 1.047033] Bad block table not found for chip 0
[ 1.054950] Bad block table not found for chip 0
[ 1.054970] Scanning device for bad blocks
[ 1.522664] random: fast init done
[ 4.893731] Bad eraseblock 1985 at 0x0001f07fc000
[ 5.020637] Bad block table written to 0x0001ffc00000, version 0x01
[ 5.028258] Bad block table written to 0x0001ff800000, version 0x01
[ 5.029905] 5 fixed-partitions partitions found on MTD device
d0074800.nfc
[ 5.035714] Creating 5 MTD partitions on "d0074800.nfc":
[......]
Martin, Now i am not sure whether NFC driver leads to kernel panic when
calling kmem_cache_alloc_trace.
> .
>
Hi Liang,
On Tue, Mar 12, 2019 at 10:05 AM Liang Yang <[email protected]> wrote:
>
> Hi Martin and Miquel,
>
> On 2019/3/7 21:09, Miquel Raynal wrote:
> > Hello,
> >
> > Martin Blumenstingl <[email protected]> wrote on Tue,
> > 5 Mar 2019 23:12:51 +0100:
> >
> >> Hi Liang,
> >>
> >> On Mon, Mar 4, 2019 at 5:55 AM Liang Yang <[email protected]> wrote:
> >>>
> >>> Hello Martin,
> >>>
> >>> On 2019/3/2 2:29, Martin Blumenstingl wrote:
> >>>> Hi Liang,
> >>>>
> >>>> I am trying to add support for older SoCs to the meson-nand driver.
> >>>> Back when the driver was in development I used an early revision (of
> >>>> your driver) and did some modifications to make it work on older SoCs.
> >>>>
> >>>> Now that the driver is upstream I wanted to give it another try and
> >>>> make a real patch out of it. Unfortunately it's not working anymore.
> >>>>
> >>>> As far as I know the NFC IP block revision on GXL is similar (or even
> >>>> the same?) as on all older SoCs. As far as I can tell only the clock
> >>>> setup is different on the older SoCs (which have a dedicated NAND
> >>>> clock):
> >>>> - we don't need the "amlogic,mmc-syscon" property on the older SoCs
> >>>> because we don't need to setup any muxing (common clock framework
> >>>> will do everything for us)
> >>>> - "rx" and "tx" clocks don't exist
> >>>> - I could not find any other differences between Meson8, Meson8b,
> >>>> Meson8m2, GXBB and GXL
> >>>>
> >>> That is right. the serials NFC is almost the same except:
> >>> 1) The clock control and source that M8-serials are not share with EMMC.
> >>> 2) The base register address
> >>> 3) DMA encryption option which we don't care on NFC driver.
> >> great, thank you for confirming this!
> >>
> >>>> In this series I'm sending two patches which add support for the older
> >>>> SoCs.
> >>>>
> >>>> Unfortunately these patches are currently not working for me (hence the
> >>>> "RFC" prefix). I get a (strange) crash which is triggered by the
> >>>> kzalloc() in meson_nfc_read_buf() - see below for more details.
> >>>>
> >>>> Can you please help me on this one? I'd like to know whether:
> >>>> - the meson-nand driver works for you on GXL or AXG on linux-next?
> >>>> (I was running these patches on top of next-20190301 on my M8S
> >>>> board which uses a 32-bit Meson8m2 SoC. I don't have any board using
> >>>> a GXL SoC which also has NAND)
> >>> Yes, it works on AXG platform using a MXIC slc nand flash(MX30LF4G); but
> >>> i an not sure it runs the same flow with yours. because i see the print
> >>> "Counld not find a valid ONFI parameter page, ...." in yours. i will try
> >>> to reproduce it on AXG(i don't have a M8 platform now).
> >> I'm looking forward to hear about the test results on your AXG boards
> >> for reference: my board has a SK Hynix H27UCG8T2B (ID bytes: 0xad 0xde
> >> 0x94 0xeb 0x74 0x44, 20nm MLC)
> >> I have another board (where I haven't tested the NFC driver yet) with
> >> a SK Hynix H27UCG8T2E (ID bytes: 0xad 0xde 0x14 0xa7 0x42 0x4a, 1Ynm
> >> MLC). if it helps with your analysis I can test on that board as well
> >
> > Liang, you just have to fake the output of the ONFI page detection and
> > you will probably run into this error which will then be easy to
> > reproduce.
> >
> i don't reproduce it by using a SK Hynix nand flash H27UCG8T2E on gxl
> platform. it runs well.
> [......]
> [ 0.977127] loop: module loaded
> [ 0.998625] Could not find a valid ONFI parameter page, trying
> bit-wise majority to recover it
> [ 1.001619] ONFI parameter recovery failed, aborting
> [ 1.006684] Could not find valid JEDEC parameter page; aborting
> [ 1.012391] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde
> [ 1.018660] nand: Hynix NAND 8GiB 3,3V 8-bit
> [ 1.022885] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size:
> 16384, OOB size: 1664
> [ 1.047033] Bad block table not found for chip 0
> [ 1.054950] Bad block table not found for chip 0
> [ 1.054970] Scanning device for bad blocks
> [ 1.522664] random: fast init done
> [ 4.893731] Bad eraseblock 1985 at 0x0001f07fc000
> [ 5.020637] Bad block table written to 0x0001ffc00000, version 0x01
> [ 5.028258] Bad block table written to 0x0001ff800000, version 0x01
> [ 5.029905] 5 fixed-partitions partitions found on MTD device
> d0074800.nfc
> [ 5.035714] Creating 5 MTD partitions on "d0074800.nfc":
> [......]
>
> Martin, Now i am not sure whether NFC driver leads to kernel panic when
> calling kmem_cache_alloc_trace.
thank you for confirming that it works for you on GXL
I'm not sure that this is a NFC driver problem.
after enabling CONFIG_SLAB_FREELIST_HARDENED in my kernel config the
crash moves. it's now crashing in slub.c's kfree() at
BUG_ON(!PageCompound(page));
maybe this is related to some difference in 32-bit ARM and arm64
or it could even be some memory management issue
I'm not sure yet so I'll try to dig deeper
Regards
Martin
Hello Liang,
On Sat, Mar 16, 2019 at 11:55 AM Martin Blumenstingl
<[email protected]> wrote:
[...]
> > Martin, Now i am not sure whether NFC driver leads to kernel panic when
> > calling kmem_cache_alloc_trace.
> thank you for confirming that it works for you on GXL
>
> I'm not sure that this is a NFC driver problem.
> after enabling CONFIG_SLAB_FREELIST_HARDENED in my kernel config the
> crash moves. it's now crashing in slub.c's kfree() at
> BUG_ON(!PageCompound(page));
I added some debug prints in meson_nfc_read_buf() to get some details
about the info buffer before the crash,
format is: meson_nfc_read_buf <virtual address> <physical address>
during my first test three different addresses are used:
- meson_nfc_read_buf e9e6c640 0x29e6c640 (works fine)
- meson_nfc_read_buf e9e6c680 0x29e6c680 (works fine)
- meson_nfc_read_buf ee39a34b 0x2e39a34b (crashes during kfree)
so I tried playing around with the allocation size (see the attached
patch) and changed it to:
kzalloc(PER_INFO_BYTE + 64, GFP_KERNEL)
this results in the following addresses being used:
- meson_nfc_read_buf e9ea4280 0x29ea4280 (works fine)
- meson_nfc_read_buf e9ea4300 0x29ea4300 (works fine)
(there is no crash anymore)
Liang, are there any special requirements on the "info address" like
the alignment?
also do you know why the PER_INFO_BYTE buffer is allocated dynamically
in meson_nfc_read_buf() instead of allocating it at initialization?
I'm not saying that it should be changed! I'm curious because there's
per-meson_nfc_nand_chip info and data buffers which are allocated at
initialization time.
meson_nfc_read_buf debug log with PER_INFO_BYTE allocation:
[ 2.032914] meson_nfc_read_buf e9e6c640 0x29e6c640
[ 2.033005] meson_nfc_dma_buffer_setup 0x29e6c640
[ 2.037717] meson_nfc_read_buf: about to kfree info
[ 2.042535] meson_nfc_read_buf: kfree'd info
[ 2.046794] meson_nfc_read_buf e9e6c640 0x29e6c640
[ 2.051552] meson_nfc_dma_buffer_setup 0x29e6c640
[ 2.056261] meson_nfc_read_buf: about to kfree info
[ 2.061086] meson_nfc_read_buf: kfree'd info
[ 2.065356] meson_nfc_read_buf e9e6c680 0x29e6c680
[ 2.070102] meson_nfc_dma_buffer_setup 0x29e6c680
[ 2.074810] meson_nfc_read_buf: about to kfree info
[ 2.079635] meson_nfc_read_buf: kfree'd info
[ 2.083978] meson_nfc_read_buf e9e6c640 0x29e6c640
[ 2.088684] meson_nfc_dma_buffer_setup 0x29e6c640
[ 2.093334] meson_nfc_read_buf: about to kfree info
[ 2.098199] meson_nfc_read_buf: kfree'd info
[ 2.102446] meson_nfc_read_buf e9e6c640 0x29e6c640
[ 2.107208] meson_nfc_dma_buffer_setup 0x29e6c640
[ 2.111883] meson_nfc_read_buf: about to kfree info
[ 2.116765] meson_nfc_read_buf: kfree'd info
[ 2.120996] meson_nfc_read_buf e9e6c640 0x29e6c640
[ 2.125762] meson_nfc_dma_buffer_setup 0x29e6c640
[ 2.130433] meson_nfc_read_buf: about to kfree info
[ 2.135294] meson_nfc_read_buf: kfree'd info
[ 2.139545] Could not find a valid ONFI parameter page, trying
bit-wise majority to recover it
[ 2.148173] ONFI parameter recovery failed, aborting
[ 2.153058] meson_nfc_read_buf e9e6c680 0x29e6c680
[ 2.157831] meson_nfc_dma_buffer_setup 0x29e6c680
[ 2.162527] meson_nfc_read_buf: about to kfree info
[ 2.167369] meson_nfc_read_buf: kfree'd info
[ 2.171611] meson_nfc_read_buf ee39a34b 0x2e39a34b
[ 2.176383] meson_nfc_dma_buffer_setup 0x2e39a34b
[ 2.181076] meson_nfc_read_buf: about to kfree info
[ 2.185932] ------------[ cut here ]------------
[ 2.190503] kernel BUG at mm/slub.c:3950!
[ 2.194491] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
meson_nfc_read_buf debug log with PER_INFO_BYTE+64 allocation:
[ 2.033019] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.033112] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.037847] meson_nfc_read_buf: about to kfree info
[ 2.042642] meson_nfc_read_buf: kfree'd info
[ 2.046909] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.051659] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.056374] meson_nfc_read_buf: about to kfree info
[ 2.061192] meson_nfc_read_buf: kfree'd info
[ 2.065461] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.070208] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.074922] meson_nfc_read_buf: about to kfree info
[ 2.079742] meson_nfc_read_buf: kfree'd info
[ 2.084087] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.088789] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.093440] meson_nfc_read_buf: about to kfree info
[ 2.098303] meson_nfc_read_buf: kfree'd info
[ 2.102553] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.107316] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.111990] meson_nfc_read_buf: about to kfree info
[ 2.116870] meson_nfc_read_buf: kfree'd info
[ 2.121103] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.125868] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.130540] meson_nfc_read_buf: about to kfree info
[ 2.135400] meson_nfc_read_buf: kfree'd info
[ 2.139652] Could not find a valid ONFI parameter page, trying
bit-wise majority to recover it
[ 2.148276] ONFI parameter recovery failed, aborting
[ 2.153165] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.157938] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.162634] meson_nfc_read_buf: about to kfree info
[ 2.167475] meson_nfc_read_buf: kfree'd info
[ 2.171717] meson_nfc_read_buf e9ea4280 0x29ea4280
[ 2.176489] meson_nfc_dma_buffer_setup 0x29ea4280
[ 2.181183] meson_nfc_read_buf: about to kfree info
[ 2.186025] meson_nfc_read_buf: kfree'd info
[ 2.190265] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde
[ 2.196598] nand: Hynix NAND 8GiB 3,3V 8-bit
[ 2.200840] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size:
16384, OOB size: 1280
[ 2.208829] meson_nfc_read_buf e9ea4300 0x29ea4300
[ 2.213581] meson_nfc_dma_buffer_setup 0x29ea4300
[ 2.218291] meson_nfc_read_buf: about to kfree info
[ 2.223115] meson_nfc_read_buf: kfree'd info
[ 2.227374] ------------[ cut here ]------------
[ 2.231968] WARNING: CPU: 1 PID: 1 at
drivers/mtd/nand/raw/nand_base.c:5503 nand_scan_with_ids+0x1718/0x171c
[ 2.241760] No oob scheme defined for oobsize 1280
...
(the "No oob scheme defined for oobsize 1280" message is expected)
Regards
Martin
Hi Martin,
Thanks for your time.
On 2019/3/20 4:27, Martin Blumenstingl wrote:
> Hello Liang,
>
> On Sat, Mar 16, 2019 at 11:55 AM Martin Blumenstingl
> <[email protected]> wrote:
> [...]
>>> Martin, Now i am not sure whether NFC driver leads to kernel panic when
>>> calling kmem_cache_alloc_trace.
>> thank you for confirming that it works for you on GXL
>>
>> I'm not sure that this is a NFC driver problem.
>> after enabling CONFIG_SLAB_FREELIST_HARDENED in my kernel config the
>> crash moves. it's now crashing in slub.c's kfree() at
>> BUG_ON(!PageCompound(page));
> I added some debug prints in meson_nfc_read_buf() to get some details
> about the info buffer before the crash,
> format is: meson_nfc_read_buf <virtual address> <physical address>
>
> during my first test three different addresses are used:
> - meson_nfc_read_buf e9e6c640 0x29e6c640 (works fine)
> - meson_nfc_read_buf e9e6c680 0x29e6c680 (works fine)
> - meson_nfc_read_buf ee39a34b 0x2e39a34b (crashes during kfree)
>
> so I tried playing around with the allocation size (see the attached
> patch) and changed it to:
> kzalloc(PER_INFO_BYTE + 64, GFP_KERNEL)
> this results in the following addresses being used:
> - meson_nfc_read_buf e9ea4280 0x29ea4280 (works fine)
> - meson_nfc_read_buf e9ea4300 0x29ea4300 (works fine)
> (there is no crash anymore)
>
> Liang, are there any special requirements on the "info address" like
> the alignment?
It must be 4 bytes alignment. i have met it previously when debugging
NFC driver on AXG platform, but it is not specified on spec. Now i am
confused that how to get the no aligned address "xe39a34b" when using
kmalloc; i think it should return the aligned address. doesn't it?
> also do you know why the PER_INFO_BYTE buffer is allocated dynamically
> in meson_nfc_read_buf() instead of allocating it at initialization?
> I'm not saying that it should be changed! I'm curious because there's
> per-meson_nfc_nand_chip info and data buffers which are allocated at
> initialization time.
> NAND scan or initialization is divided into three stages:
nand_scan_ident->nand_attach->nand_scan_tail. info and data buffer which
depend on the result of nand_scan_ident are allocated on nand_attach; so
nand_scan_ident can not use the info buffer on meson_nfc_nand_chip.
Allocating a fixed size info buffer before nand_scan_ident and attach it
on the struct meson_nfc; Or considering not use dma for reading data
less than 8 bytes. Both can reduce kmalloc and kfree calling. Thanks.
>
> meson_nfc_read_buf debug log with PER_INFO_BYTE allocation:
> [ 2.032914] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.033005] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.037717] meson_nfc_read_buf: about to kfree info
> [ 2.042535] meson_nfc_read_buf: kfree'd info
> [ 2.046794] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.051552] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.056261] meson_nfc_read_buf: about to kfree info
> [ 2.061086] meson_nfc_read_buf: kfree'd info
> [ 2.065356] meson_nfc_read_buf e9e6c680 0x29e6c680
> [ 2.070102] meson_nfc_dma_buffer_setup 0x29e6c680
> [ 2.074810] meson_nfc_read_buf: about to kfree info
> [ 2.079635] meson_nfc_read_buf: kfree'd info
> [ 2.083978] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.088684] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.093334] meson_nfc_read_buf: about to kfree info
> [ 2.098199] meson_nfc_read_buf: kfree'd info
> [ 2.102446] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.107208] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.111883] meson_nfc_read_buf: about to kfree info
> [ 2.116765] meson_nfc_read_buf: kfree'd info
> [ 2.120996] meson_nfc_read_buf e9e6c640 0x29e6c640
> [ 2.125762] meson_nfc_dma_buffer_setup 0x29e6c640
> [ 2.130433] meson_nfc_read_buf: about to kfree info
> [ 2.135294] meson_nfc_read_buf: kfree'd info
> [ 2.139545] Could not find a valid ONFI parameter page, trying
> bit-wise majority to recover it
> [ 2.148173] ONFI parameter recovery failed, aborting
> [ 2.153058] meson_nfc_read_buf e9e6c680 0x29e6c680
> [ 2.157831] meson_nfc_dma_buffer_setup 0x29e6c680
> [ 2.162527] meson_nfc_read_buf: about to kfree info
> [ 2.167369] meson_nfc_read_buf: kfree'd info
> [ 2.171611] meson_nfc_read_buf ee39a34b 0x2e39a34b
> [ 2.176383] meson_nfc_dma_buffer_setup 0x2e39a34b
> [ 2.181076] meson_nfc_read_buf: about to kfree info
> [ 2.185932] ------------[ cut here ]------------
> [ 2.190503] kernel BUG at mm/slub.c:3950!
> [ 2.194491] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> ...
>
> meson_nfc_read_buf debug log with PER_INFO_BYTE+64 allocation:
> [ 2.033019] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.033112] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.037847] meson_nfc_read_buf: about to kfree info
> [ 2.042642] meson_nfc_read_buf: kfree'd info
> [ 2.046909] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.051659] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.056374] meson_nfc_read_buf: about to kfree info
> [ 2.061192] meson_nfc_read_buf: kfree'd info
> [ 2.065461] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.070208] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.074922] meson_nfc_read_buf: about to kfree info
> [ 2.079742] meson_nfc_read_buf: kfree'd info
> [ 2.084087] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.088789] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.093440] meson_nfc_read_buf: about to kfree info
> [ 2.098303] meson_nfc_read_buf: kfree'd info
> [ 2.102553] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.107316] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.111990] meson_nfc_read_buf: about to kfree info
> [ 2.116870] meson_nfc_read_buf: kfree'd info
> [ 2.121103] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.125868] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.130540] meson_nfc_read_buf: about to kfree info
> [ 2.135400] meson_nfc_read_buf: kfree'd info
> [ 2.139652] Could not find a valid ONFI parameter page, trying
> bit-wise majority to recover it
> [ 2.148276] ONFI parameter recovery failed, aborting
> [ 2.153165] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.157938] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.162634] meson_nfc_read_buf: about to kfree info
> [ 2.167475] meson_nfc_read_buf: kfree'd info
> [ 2.171717] meson_nfc_read_buf e9ea4280 0x29ea4280
> [ 2.176489] meson_nfc_dma_buffer_setup 0x29ea4280
> [ 2.181183] meson_nfc_read_buf: about to kfree info
> [ 2.186025] meson_nfc_read_buf: kfree'd info
> [ 2.190265] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xde
> [ 2.196598] nand: Hynix NAND 8GiB 3,3V 8-bit
> [ 2.200840] nand: 8192 MiB, MLC, erase size: 4096 KiB, page size:
> 16384, OOB size: 1280
> [ 2.208829] meson_nfc_read_buf e9ea4300 0x29ea4300
> [ 2.213581] meson_nfc_dma_buffer_setup 0x29ea4300
> [ 2.218291] meson_nfc_read_buf: about to kfree info
> [ 2.223115] meson_nfc_read_buf: kfree'd info
> [ 2.227374] ------------[ cut here ]------------
> [ 2.231968] WARNING: CPU: 1 PID: 1 at
> drivers/mtd/nand/raw/nand_base.c:5503 nand_scan_with_ids+0x1718/0x171c
> [ 2.241760] No oob scheme defined for oobsize 1280
> ...
> (the "No oob scheme defined for oobsize 1280" message is expected)
>
miss mtd_set_ooblayout(mtd, &meson_ooblayout_ops) on function
meson_nand_attach_chip.
>
> Regards
> Martin
>
Hi Liang,
On Wed, Mar 20, 2019 at 4:32 AM Liang Yang <[email protected]> wrote:
>
> Hi Martin,
>
> Thanks for your time.
> On 2019/3/20 4:27, Martin Blumenstingl wrote:
> > Hello Liang,
> >
> > On Sat, Mar 16, 2019 at 11:55 AM Martin Blumenstingl
> > <[email protected]> wrote:
> > [...]
> >>> Martin, Now i am not sure whether NFC driver leads to kernel panic when
> >>> calling kmem_cache_alloc_trace.
> >> thank you for confirming that it works for you on GXL
> >>
> >> I'm not sure that this is a NFC driver problem.
> >> after enabling CONFIG_SLAB_FREELIST_HARDENED in my kernel config the
> >> crash moves. it's now crashing in slub.c's kfree() at
> >> BUG_ON(!PageCompound(page));
> > I added some debug prints in meson_nfc_read_buf() to get some details
> > about the info buffer before the crash,
> > format is: meson_nfc_read_buf <virtual address> <physical address>
> >
> > during my first test three different addresses are used:
> > - meson_nfc_read_buf e9e6c640 0x29e6c640 (works fine)
> > - meson_nfc_read_buf e9e6c680 0x29e6c680 (works fine)
> > - meson_nfc_read_buf ee39a34b 0x2e39a34b (crashes during kfree)
> >
> > so I tried playing around with the allocation size (see the attached
> > patch) and changed it to:
> > kzalloc(PER_INFO_BYTE + 64, GFP_KERNEL)
> > this results in the following addresses being used:
> > - meson_nfc_read_buf e9ea4280 0x29ea4280 (works fine)
> > - meson_nfc_read_buf e9ea4300 0x29ea4300 (works fine)
> > (there is no crash anymore)
> >
> > Liang, are there any special requirements on the "info address" like
> > the alignment?
> It must be 4 bytes alignment. i have met it previously when debugging
> NFC driver on AXG platform, but it is not specified on spec. Now i am
> confused that how to get the no aligned address "xe39a34b" when using
> kmalloc; i think it should return the aligned address. doesn't it?
thank you for confirming the 4-byte alignment requirement!
I have no explanation for the unaligned address returned by kzalloc().
I'll ask on the linux-mm mailing list if they have a hint why this
happens.
> > also do you know why the PER_INFO_BYTE buffer is allocated dynamically
> > in meson_nfc_read_buf() instead of allocating it at initialization?
> > I'm not saying that it should be changed! I'm curious because there's
> > per-meson_nfc_nand_chip info and data buffers which are allocated at
> > initialization time.
> > NAND scan or initialization is divided into three stages:
> nand_scan_ident->nand_attach->nand_scan_tail. info and data buffer which
> depend on the result of nand_scan_ident are allocated on nand_attach; so
> nand_scan_ident can not use the info buffer on meson_nfc_nand_chip.
thank you for the explanation!
> Allocating a fixed size info buffer before nand_scan_ident and attach it
> on the struct meson_nfc; Or considering not use dma for reading data
> less than 8 bytes. Both can reduce kmalloc and kfree calling. Thanks.
both suggestions sound reasonable.
however, I will search for the root cause of the unaligned address
first before changing the Meson NFC driver.
[...]
> > [ 2.227374] ------------[ cut here ]------------
> > [ 2.231968] WARNING: CPU: 1 PID: 1 at
> > drivers/mtd/nand/raw/nand_base.c:5503 nand_scan_with_ids+0x1718/0x171c
> > [ 2.241760] No oob scheme defined for oobsize 1280
> > ...
> > (the "No oob scheme defined for oobsize 1280" message is expected)
> >
> miss mtd_set_ooblayout(mtd, &meson_ooblayout_ops) on function
> meson_nand_attach_chip.
thank you for the suggestion. I didn't have time to test this on my
board yet but I'll let you know about my results during the weekend.
Does the missing mtd_set_ooblayout() call also affect GXL or AXG boards?
Regards
Martin
Hi Martin,
On 2019/3/21 4:48, Martin Blumenstingl wrote:
> Hi Liang,
>
> On Wed, Mar 20, 2019 at 4:32 AM Liang Yang <[email protected]> wrote:
>>
>> Hi Martin,
>>
>> Thanks for your time.
>> On 2019/3/20 4:27, Martin Blumenstingl wrote:
>>> Hello Liang,
>>>
>>> On Sat, Mar 16, 2019 at 11:55 AM Martin Blumenstingl
>>> <[email protected]> wrote:
>>> [...]
>
>> Allocating a fixed size info buffer before nand_scan_ident and attach it
>> on the struct meson_nfc; Or considering not use dma for reading data
>> less than 8 bytes. Both can reduce kmalloc and kfree calling. Thanks.
> both suggestions sound reasonable.
> however, I will search for the root cause of the unaligned address
> first before changing the Meson NFC driver.
That is good. And i will implement one of both mentioned above soon.
>
> [...]
>>> [ 2.227374] ------------[ cut here ]------------
>>> [ 2.231968] WARNING: CPU: 1 PID: 1 at
>>> drivers/mtd/nand/raw/nand_base.c:5503 nand_scan_with_ids+0x1718/0x171c
>>> [ 2.241760] No oob scheme defined for oobsize 1280
>>> ...
>>> (the "No oob scheme defined for oobsize 1280" message is expected)
>>>
>> miss mtd_set_ooblayout(mtd, &meson_ooblayout_ops) on function
>> meson_nand_attach_chip.
> thank you for the suggestion. I didn't have time to test this on my
> board yet but I'll let you know about my results during the weekend.
> Does the missing mtd_set_ooblayout() call also affect GXL or AXG boards?
>
Yes. I deleted it unintentionally.
>
> Regards
> Martin
>
> .
>