<bbrezillon>
RSpliet: have you checked the ready-busy id ?
<bbrezillon>
have you claimed the appropriate clk ?
<bbrezillon>
is NAND detection working ?
fredy has joined #linux-sunxi
<RSpliet>
bbrezillon: to answer your questions: no (what?), I think so yes (I'll post you the DT bindings, inspired by yours), it's failing now due to mismatches between first and second read of ID
philippe_fouquet has quit [Remote host closed the connection]
<rm>
but for some reason not shown anymore in the "Branches / Tags" drop down on the main page
<mripard>
mark__: yes
<rm>
so... nvm, I guess
premoboss has joined #linux-sunxi
<mark__>
mripard: Alright, I'll give it a try then. Just wanted to make sure it's not an insane idea or anything :)
<mripard>
mark__: it's what modules are made for
<mark__>
mripard: Not compiling the USB module will result in the usb controller not being powered on at all, is that correct?
<mripard>
it depends on your kernel, bootloader and board
<mripard>
but yeah, probably
<RSpliet>
bbrezillon: who is responsible for setting these clocks?
<bbrezillon>
RSpliet: the driver, thanks to the description you put in your DT
<RSpliet>
bbrezillon: but does it calculate the right pll values too? or does it just enable?
<RSpliet>
(sorry, still having my IDE indexing my tree, I'll get through it a bit easier soon)
<bbrezillon>
it doesn't change the PLL config
<RSpliet>
bbrezillon: ok... from what I can tell normally BROM does that, but only if you boot U-boot from NAND
naobsd has quit [Quit: naobsd]
<RSpliet>
and since I can't flash u-boot in NAND until Linux has NAND working, I'm in a deadlock :-D
Akagi201 has joined #linux-sunxi
<bbrezillon>
RSpliet: oh my bad, it's changing the nand clk rate, but this clk is not propagating the change rate request to its parent (one of the system PLL)
<bbrezillon>
IOW, the nand clk rate should be close enough to what the NAND device is expecting
<bbrezillon>
unless you have a very weird PLL config
<bbrezillon>
anyway, you can print the nand clk rate if you want to check
<RSpliet>
but this is called after trying to read the ID
<RSpliet>
the clock rate should be changed before reset I think
<bbrezillon>
"but this is called after trying to read the ID" => no it's not, see the sunxi_nand_chip_init function => but this is called after trying to read the ID
<RSpliet>
let me check for that NAND_E Close... thing
mauro_ has quit [Ping timeout: 256 seconds]
<RSpliet>
there's no pins attached, maybe I can get my colleague to help me close it
<bbrezillon>
RSpliet: 25Mhz seems like an acceptable value for the NAND clk rate
<bbrezillon>
you can try to reduce it (say 10 or 20Mhz) by calling clk_set_rate after the first call to sunxi_nand_chip_set_timings has returned
simosx has joined #linux-sunxi
Akagi201 has quit []
<RSpliet>
worth a try
adj_ has quit [Remote host closed the connection]
<RSpliet>
bbrezillon: I've halved the clock rate, but no luck
domidumont has joined #linux-sunxi
<bbrezillon>
RSpliet: any progress with NAND_E Close ? Is it really opened ?
<RSpliet>
it isn't
<RSpliet>
although I'd be happy to verify with a multimeter
<RSpliet>
tWHR of 80ns isn't stellar is it... that's not going to cause ID read errors
<RSpliet>
1 cycle on 12,5MHz
<RSpliet>
seems to correspond with all the others
philippe_fouquet has joined #linux-sunxi
<bbrezillon>
RSpliet: not sure I understand, is it working when you configure the clk to 12,5MHz ?
<RSpliet>
it isn't
<bbrezillon>
an mode0 is setting twhr to 120ns
<bbrezillon>
so this should just work
ricardocrudo has joined #linux-sunxi
pmattern has joined #linux-sunxi
mauro_ has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 250 seconds]
<bbrezillon>
RSpliet: is your NAND detected by u-boot (and/or allwinner BSP) ?
<RSpliet>
bbrezillon: I don't have NAND-enabled U-boot yet
<RSpliet>
my workflow was first to get BROM to load U-boot from NAND, then look at U-boot... but to get U-boot in NAND I need Linux support or some tool that can do FES flashing of NAND
<RSpliet>
I picked the DT bits from it... many patches on top seem to be about partitioning and randomisation. The only truly interesting bits is the hynix-specific initialiser, but it doesn't even get to the point that it detects the manufacturer OK
focus has quit [Remote host closed the connection]
focus has joined #linux-sunxi
<bbrezillon>
RSpliet: BTW, why are you testing on a RC version, 4.0 is out
<RSpliet>
bbrezillon: haven't rebased yet
<bbrezillon>
ok
<bbrezillon>
I think the root cause of this whole mess has something to do with NFC (NAND flash controller) IP initialization
domidumont has quit [Quit: Leaving.]
<RSpliet>
the magic writes to NFC_REG_TIMING_CTL and NFC_REG_TIMING_CFG?
<bbrezillon>
we shouldn't have timeouts when launching simple commands (those that do not wait for the device to be ready)
steeve has joined #linux-sunxi
<bbrezillon>
RSpliet: I doubt this has something to do with NAND timings at all
domidumont has joined #linux-sunxi
<RSpliet>
ok... so step 1 for me would be verifying whether the interrupts are triggered at all
<bbrezillon>
here, we're timeouting on really basic stuff like 'is the last cmd sent'
<bbrezillon>
RSpliet: I'm pretty sure they are not
<bbrezillon>
you could also check the status register
<bbrezillon>
(when encountering a timeout)
<RSpliet>
you'd think I can find them in /proc/interrupts
<RSpliet>
but how do I recognise GIC interrupt line 37?
<RSpliet>
ah got it
<RSpliet>
27: 0 0 GIC 69 sunxi-nand
leviathancn has joined #linux-sunxi
domidumont has quit [Quit: Leaving.]
leviathancn has quit [Ping timeout: 240 seconds]
sdschulze has joined #linux-sunxi
domidumont has joined #linux-sunxi
leviathancn has joined #linux-sunxi
<bbrezillon>
RSpliet: you should really try with my sunxi-nand-next branch, because I'm sure it was working on my cubietruck ;-)
alexxy has quit [Quit: No Ping reply in 180 seconds.]
<RSpliet>
bbrezillon: I realised that... where does your bootloader reside?
mmarker has quit [Quit: ZNC - 1.6.0 - http://znc.in]
<bbrezillon>
RSpliet: as you can see on this dump the NAND clks are not enabled
<bbrezillon>
which is expected since the NAND driver failed to probe the NAND controller and then released the clks
<bbrezillon>
this is why I suggested to return 0 before calling sunxi_nand_chips_init
<bbrezillon>
so that the probe can succeed and the all the relevant clks enabled
<bbrezillon>
then you'll be able to read NFC registers with devmem
mmarker has joined #linux-sunxi
mmarker has joined #linux-sunxi
<RSpliet>
ah yes
reinforce has quit [Quit: Leaving.]
<RSpliet>
bbrezillon: I added return 0 to the error path for sunxi_nand_chips_init (after line 1388), such that the clocks are configured, the driver remains loaded but the clocks aren't unprepared
<RSpliet>
but still I'm reading 0 using devmem
alexvf has joined #linux-sunxi
<bbrezillon>
and what's the content of /sys/kernel/debug/clk/clk_summary ?
mauro_ has quit [Ping timeout: 250 seconds]
leviathancn has quit [Ping timeout: 256 seconds]
<RSpliet>
for unknown reason the AHB bit wasn't set
<bbrezillon>
RSpliet: the clk ahb_nand clk was enabled but the bit wasn't set ?
<RSpliet>
bbrezillon: I'm not sure if I completely understand your question, so let me overload you with information
<RSpliet>
the bit wans't set after loading the driver and prematurely returning 0 (so without disabling the clocks again)
<RSpliet>
sunxi_nand doesn't fail on the clk_prepare_enable(dev, "ahb")
<RSpliet>
and this clock refers to the right <&ahb_gates 13> in dt
<bbrezillon>
RSpliet: ok, that's really weird
<bbrezillon>
RSpliet: I'd still like to be sure the ahb_gate 13 is enabled (from the clk subsystem POV), and the bit is not set in the AHB_GATING_REG0 register
<bbrezillon>
can you dump clk_summary and then do a devmem on this register (0xc1c20060)
<bbrezillon>
RSpliet: (you should do that after a fresh reboot)
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
Nyuutwo has quit [Ping timeout: 272 seconds]
domidumont has quit [Read error: Connection reset by peer]
<mmarker>
Ok, have an A20 board running mainline. I want to do something stupid with Cedrus. Does it kinda work, and am I asking for pain to port the 3.0 cedar_dev driver to 4.0?
<mmarker>
Or should I use my free time more wisely?
afaerber has quit [Quit: Verlassend]
Black_Horseman has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
<TheLinuxBug>
What are you wanting to accomplish?
<TheLinuxBug>
I think they provide a git with linux-sunxi version of the code for cedar
RzR has quit [Excess Flood]
<TheLinuxBug>
which you can compile your self
<TheLinuxBug>
not sure if thats what your getting at?
sdschulze has joined #linux-sunxi
RzR has joined #linux-sunxi
<mmarker>
Trying to find it, but it looks like it's just a 3.0 kernel.
<mmarker>
Unless if there's something I'm missing on the wiki.
<TheLinuxBug>
I might also be thinking of using the android blob on linux... that may be another way to use it, but sounds like your wanting to compile it from scratch your self?
<mmarker>
You need a kernel device for those to bitbang cpu registers, I believe
<TheLinuxBug>
hmm
<TheLinuxBug>
I know roman built a kernel for A20 with it