haritz has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
monstr has joined #u-boot
RoganDawes has joined #u-boot
ikarso has joined #u-boot
mripard has joined #u-boot
frieder has joined #u-boot
rvalue- has joined #u-boot
rvalue has quit [Ping timeout: 276 seconds]
rvalue- is now known as rvalue
frieder has quit [Ping timeout: 276 seconds]
naoki has joined #u-boot
Stat_headcrabbed has joined #u-boot
frieder has joined #u-boot
<mkorpershoek>
pigmoral: they have been applied. They are going through CI now and if everything goes well I'll send a PR to Tom for including this into next. Sorry for the delay and thanks for the reminder !
<mkorpershoek>
You are welcome. I hope next time your contributions won't slip through the cracks like this. I should have paid more attention, sorry.
<marex>
mkorpershoek: that blame is on me, really
frieder has quit [Quit: Leaving]
<pigmoral>
No worries at all, these things happen :-)
alperak has joined #u-boot
dsimic has quit [Ping timeout: 276 seconds]
dsimic has joined #u-boot
srk- has joined #u-boot
srk has quit [Ping timeout: 248 seconds]
Stalevar has joined #u-boot
srk- is now known as srk
mmu_man has quit [Ping timeout: 248 seconds]
warthog9 has quit [Remote host closed the connection]
monstr has quit [Ping timeout: 252 seconds]
<RoganDawes>
hey folks. Still battling with my imx6 module :-) Turns out there is a Linux 4.9.88 tree with a device tree in it which should describe the hardware. However, taking that device tree binary (because I couldn't figure out the right way to handle all of the nested includes), running `dtc -O dts` to get back to source, and then comparing with modern
<RoganDawes>
device tree from e.g. the imx6ull_evk (going from binary back to source the same way) shows quite significant differences. However, narrowing it down to just the nand/gpmi clauses (stanzas?), I was able to find the original `fsl,pins` stanza from the linux source. However, it *still* doesn't work :-)
warthog9 has joined #u-boot
<RoganDawes>
so I am left with a few smaller differences from the controller to resolve. One of which is the `compatible` clause, which is `"fsl,imx6ull-gpmi-nand\0fsl, imx6ul-gpmi-nand";` for Linux, and `"fsl,imx6q-gpmi-nand";` (having copied the imx6ull evk as suggested). That said, I cannot find any references to `imx6ul-gpmi-nand` in the u-boot tree, so I'm
<RoganDawes>
going to presume this part is correct.
<RoganDawes>
So, at this stage, I have the controller configured identically (had to adjust the dma channel and an entry in the `reg = ` clause, but it is still not working. So, I presume there is some other iomuxing setup that I still need to resolve.
<RoganDawes>
(controller configured identically apart from the driver being imz6q-gpmi-nand, that is)
umbramalison has joined #u-boot
RoganDawes has quit [Quit: Client closed]
RoganDawes has joined #u-boot
<RoganDawes>
One that stands out is `interrupt-controller` (Linux 4.9.88): ` reg = <0xa01000 0x1000 0xa02000 0x100>;` vs (U-Boot): `reg = <0xa01000 0x1000 0xa02000 0x2000 0xa04000 0x2000 0xa06000 0x2000>;` ? But I suspect that this is pairs of address offset/length, which suggests that the Linux range is included in the U-Boot ranges?
<RoganDawes>
Are you suggesting that the imx6ul may not have had working NAND at all?
umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
<RoganDawes>
marex: I have been through the commit history for the last month, and the only changes appear to affect SPL, which I do not believe I am using. I am doing `make u-boot.imx`, and using the DCD configuration while running `imx_usb u-boot.imx`
hanetzer has joined #u-boot
<RoganDawes>
I did try building with `USE_IMXIMG_PLUGIN`, but that failed, I presume because I should first load the SPL and then the rest of U-Boot?
<RoganDawes>
not the build that failed, the upload using imx_usb failed, that is
<RoganDawes>
I am now honestly at my wits end. I have no idea what else to do to try debug this.
<RoganDawes>
I have rebased my changes onto master, and rebuilt, with no change in behaviour.
<RoganDawes>
But maybe this is meaningful? For all the changes I have made to the device tree, there has been zero actual change in behaviour. I just get timeouts trying to talk to the NAND. So I disabled the GPMI controller in the device tree, presuming that u-boot must surely error out before trying to read from the nand, but it didn't! Again, no change in
<RoganDawes>
behaviour, still times out trying to enumerate the NAND chip! How can that be?
umbramalison has quit [Quit: %So long and thanks for all the fish%]
<RoganDawes>
thank you for your help, marex! I have it booting and recognising the NAND now. Really appreciated!
<RoganDawes>
Now I just need to find the advice I was given regarding the easiest way to flash the NAND via USB (SDP vs whatever other protocols are available)
alperak has quit [Quit: Connection closed for inactivity]
clamor has quit [Read error: Connection reset by peer]
eballetbo has quit [Quit: Connection closed for inactivity]
<cambrian_invader>
ums with ubi?
<RoganDawes>
cambrian_invader: I have nand flash I want to write e.g. a linux kernel to. Doesn't sound like UMS is the right thing for that, because it needs a block device, not an MTD
<cambrian_invader>
which is why you use ubi
<cambrian_invader>
to make a block device from an mtd
<RoganDawes>
I guess so!
<RoganDawes>
what about fastboot?
Laralubsch has joined #u-boot
<cambrian_invader>
fastboot will also work I think
<cambrian_invader>
it's nice if you have ethernet but not usb
<RoganDawes>
should work for usb, according to the docs.
<cambrian_invader>
yes; I find ums more convenient for usb but both work
Hypfer6 is now known as Hypfer
f_[x] has quit [Remote host closed the connection]
Wouter0100 has joined #u-boot
<marex>
cambrian_invader: best use ubiformat in Linux to retain bad block counters
<cambrian_invader>
does the one in u-boot ignore them?