The mmc switch was misbehaving for me. This fixes the problem: https://github.com/mvduin/u-boot/commit/fa320a46aa4ca37803d3b2262f4d60d34432...
The rest of the master branch of that repository is some experimentation I did to see if I could get some of the features of the dra7 and beaglebone u-boot's working, and to get a bit more familiar with the u-boot source code.
Highlights:
- LPAE build of u-boot, runs in hypervisor mode - usb mass storage gadget mode allows flashing or mounting the eMMC (or any attached card) via the USB3 device port. It's not fast, but useful for testing and recovery purposes. - made some way in converting to the new driver model - cosmetic stuff here and there
I've also explored how ram init is done, but haven't yet attempted to get it to recognize the 4 GB.
I'm afraid that most of the work and play is in one big commit. I should probably try to separate out the more useful stuff, but that's not going to happen today anymore :-)
Matthijs
Hi Matthijs,
Am 12.02.2017 um 07:45 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
The mmc switch was misbehaving for me. This fixes the problem: https://github.com/mvduin/u-boot/commit/fa320a46aa4ca37803d3b2262f4d60d34432... https://github.com/mvduin/u-boot/commit/fa320a46aa4ca37803d3b2262f4d60d344323587
Oh! Yes. Seems to be right.
I thought that setting a gpio to input is just a marker for the driver. But it seems to touch the gpio controller...
The only thing we want here is to read back in U-Boot the state that was set by MLO. But not modify anything. So your patch is doing the right thing and I have applied it so that you can rebase:
http://git.goldelico.com/?p=gta04-uboot.git;a=shortlog;h=refs/heads/letux-20...
The rest of the master branch of that repository is some experimentation I did to see if I could get some of the features of the dra7 and beaglebone u-boot's working, and to get a bit more familiar with the u-boot source code.
It is sometimes a big hack. My approach is to be minimally invasive to upstream code, i.e. try to add things to new files and #include maintained code where possible. So I usually take a working base device, remove some things and add others instead of maintaining a completely new board file. This is usually simlar to how hardware was developed (GTA04 = beagleboard + display + GSM, Pyra = omap5evm + mainboard + display). This should make rebasing to newer u-boot releases easier.
Highlights: LPAE build of u-boot, runs in hypervisor mode
Do we need different U-Boot binaries for LPAE and non-LPAE, like for the Kernel? Or can we simply enable LPAE for everyone?
usb mass storage gadget mode allows flashing or mounting the eMMC (or any attached card) via the USB3 device port. It's not fast, but useful for testing and recovery purposes.
Interesting feature. Have to look how it works.
made some way in converting to the new driver model cosmetic stuff here and there
Which is debatable by nature...
I've also explored how ram init is done, but haven't yet attempted to get it to recognize the 4 GB.
Fine!
I'm afraid that most of the work and play is in one big commit. I should probably try to separate out the more useful stuff, but that's not going to happen today anymore :-)
There is no need to hurry... Rome wasn't built in one day and it took me several months to get to where we are now.
And, IMHO, a boot loader should be stabilized once and then not be touched for years (or you invite a lot of problems into kernel and user support). For example we did use the 2011.03 u-boot for the GTA04 until now. But now we have a variant that needs a working OneNAND driver and this forced to port everything to the letux-2016.11. And it is still not as stable as the 2011.03 was (for example a user-space triggered reboot makes u-boot stop when trying to read the MMC).
BR, Nikolaus
Hi Matthijs,
Am 12.02.2017 um 12:57 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Matthijs,
Am 12.02.2017 um 07:45 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
The mmc switch was misbehaving for me. This fixes the problem: https://github.com/mvduin/u-boot/commit/fa320a46aa4ca37803d3b2262f4d60d34432...
Oh! Yes. Seems to be right.
I thought that setting a gpio to input is just a marker for the driver. But it seems to touch the gpio controller...
The only thing we want here is to read back in U-Boot the state that was set by MLO. But not modify anything. So your patch is doing the right thing and I have applied it so that you can rebase:
http://git.goldelico.com/?p=gta04-uboot.git;a=shortlog;h=refs/heads/letux-20...
I have played a little around and we seem to have a similar issue with the kernel. I don't see the eMMC, but if I insert a µSD card it is available.
Here is what U-Boot says:
... MMC: Found LC15 V5.1 board_mmc_init called (vers = 51) U-Boot soft: gpio82 = 0 (mmc1=eMMC) OMAP SD/MMC: 0, OMAP SD/MMC: 1, OMAP SD/MMC: 2 ** First descriptor is NOT a primary desc on 1:1 ** *** Warning - bad CRC, using default environment ...
But the kernel says this:
root@gta04:~# cd /sys/class/gpio/ root@gta04:/sys/class/gpio# echo 82 >export root@gta04:/sys/class/gpio# cd gpio82 root@gta04:/sys/class/gpio/gpio82# ls -l total 0 -rw-r--r-- 1 root root 4096 Jan 1 05:13 active_low lrwxrwxrwx 1 root root 0 Jan 1 05:13 device -> ../../../gpiochip2 -rw-r--r-- 1 root root 4096 Jan 1 05:13 direction -rw-r--r-- 1 root root 4096 Jan 1 05:13 edge drwxr-xr-x 2 root root 0 Jan 1 05:13 power lrwxrwxrwx 1 root root 0 Jan 1 05:13 subsystem -> ../../../../../../../class/gpio -rw-r--r-- 1 root root 4096 Jan 1 05:13 uevent -rw-r--r-- 1 root root 4096 Jan 1 05:13 value root@gta04:/sys/class/gpio/gpio82# cat direction in root@gta04:/sys/class/gpio/gpio82# cat value 1 root@gta04:/sys/class/gpio/gpio82#
Oops - it has been switched back to input and reads value "1"... Trying "echo out >dir" makes the mmc stack fail and return I/O errors.
So the switch works, is not used by any driver, but still reset to input.
Maybe we have to define the gpio or controller to inherit the initial value from u-boot?
And write a proper (or at least simple) txs02612 driver that better controls the µSD/eMMC switch (including reset of the mmc stack, i.e. simulate card removal and reinsertion). There is an entry in the issue tracker where I have written down what I think we need:
http://projects.goldelico.com/p/gta04-kernel/issues/698/
BR, Nikolaus
On 12 February 2017 at 21:49, H. Nikolaus Schaller hns@goldelico.com wrote:
And write a proper (or at least simple) txs02612 driver that better controls the µSD/eMMC switch (including reset of the mmc stack, i.e. simulate card removal and reinsertion).
It should do no such thing. It should just multiplex requests, but I'm pretty sure it could even switch to perform a request on the other card while it's waiting on BUSY. Basically like the old multi-card MMC bus worked, but using the switch instead of using the select-card command.
Matthijs
Hi Matthijs,
Am 13.02.2017 um 02:38 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 12 February 2017 at 21:49, H. Nikolaus Schaller hns@goldelico.com wrote: And write a proper (or at least simple) txs02612 driver that better controls the µSD/eMMC switch (including reset of the mmc stack, i.e. simulate card removal and reinsertion).
It should do no such thing. It should just multiplex requests,
Indeed. I just suggested that above because it seems to be easier to hack just a driver that provides a /sys control and writing "emmc" or "usd" to that would throw the switch to the other side and simulate swapping of cards.
but I'm pretty sure it could even switch to perform a request on the other card while it's waiting on BUSY. Basically like the old multi-card MMC bus worked, but using the switch instead of using the select-card command.
Yes, that is how it IMHO should be done (to provide both memory devices to user space in parallel), but I have no idea how the mmc core works and if it can be done at all...
That is the reason why I have just collected ideas for the architecture and not written any LOC.
Some tricky part could become that µSD is 4 bit wide and eMMC 8 bit. And eMMC is non-removable while µSD is removable. Well, since it is hidden under the battery we can treat it as non-removable for the beginning.
So it seems you have an idea how it could be done. Would you work a little on such a driver?
BR and thanks, Nikolaus
On 12 February 2017 at 12:57, H. Nikolaus Schaller hns@goldelico.com wrote:
So your patch is doing the right thing and I have applied it so that you can rebase
Done :-)
It is sometimes a big hack. My approach is to be minimally invasive to upstream code, i.e. try to add things to new files and #include maintained code where possible.
Yeah, I tend to lose overview in the maze of #includes in u-boot config though... TI is really overdue to properly switch over to the Kconfig model.
To be fair, configs/ti_omap5_common.h is *supposed* to be the common include for omap5-based targets. Including the uevm and #undefing parts seems icky to me, and risks becoming more wrong if more details of the uevm are spelled out in detail. As far as "maintained" goes, it clearly lags behind dra7 though...
Do we need different U-Boot binaries for LPAE and non-LPAE, like for the
Kernel?
I'm pretty sure LPAE u-boot can start non-LPAE kernel and vice versa. My impression is that the main reason for an LPAE u-boot is because it's needed for hypervisor mode (which is always LPAE iirc).
Or can we simply enable LPAE for everyone?
Assuming you mean all pyra (or more generally Letux Cortex-A15) users, it's fine to enable LPAE for everyone. Non-LPAE kernel *might* be more efficient but I haven't evaluated this. I don't think there's any reason to run a non-LPAE u-boot, assuming the LPAE version works (haven't tried it yet).
Interesting feature. Have to look how it works.
=> ums 0 mmc 1:0
(the :0 indicates whole card instead of just a partition)
And, IMHO, a boot loader should be stabilized once and then not be touched for years (or you invite a lot of problems into kernel and user support).
On the beaglebone I never worry much about it since I don't need anything from it other than booting the kernel, and if it's not working right I can replace easily via usb. It's not the critical component it is on some other platforms since the ROM bootloader already offers sufficient alternatives ways of booting.
Having said that though, I haven't yet seen the ROM bootloader appear as usb device on the pyra like it does on the uEVM. I'm going to give that another try...
Matthijs
the 2016.11 u-boot board detections sets fdtfile to "omap5-letux-cortex15-v5.0+pyra-v4.9.dtb" on my board, is this actually the right version for this board ?
Here's a picture of the thing : http://wreck.k-n-p.org/py-2.jpeg http://wreck.k-n-p.org/py-4.jpeg
Hi,
Am 13.02.2017 um 22:51 schrieb aTc atc@k-n-p.org:
the 2016.11 u-boot board detections sets fdtfile to "omap5-letux-cortex15-v5.0+pyra-v4.9.dtb" on my board, is this actually the right version for this board ?
I think you received your prototypes a while ago. Therefore it should be right. I am not sure if I still have this combination which means we have to add another .dts for it to mix the right CPU and Mainboard versions.
Here's a picture of the thing : http://wreck.k-n-p.org/py-2.jpeg http://wreck.k-n-p.org/py-4.jpeg
Yes, the CPU board indeed seems to be V5.0.
Let me check tomorrow.
BR and thanks, Nikolaus
Hi aTc,
Am 13.02.2017 um 22:58 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 13.02.2017 um 22:51 schrieb aTc atc@k-n-p.org:
the 2016.11 u-boot board detections sets fdtfile to "omap5-letux-cortex15-v5.0+pyra-v4.9.dtb" on my board, is this actually the right version for this board ?
I think you received your prototypes a while ago. Therefore it should be right. I am not sure if I still have this combination which means we have to add another .dts for it to mix the right CPU and Mainboard versions.
Here's a picture of the thing : http://wreck.k-n-p.org/py-2.jpeg http://wreck.k-n-p.org/py-4.jpeg
Yes, the CPU board indeed seems to be V5.0.
Let me check tomorrow.
I have verified and both of your boards should be V5.0. Version detection software is also correct, but what is wrong is the version encoding resistor R1901.
It is 10k but the pull-up of the OMAP5 is much stronger than on the OMAP5 so that if the omap5 pulls up we will always see a "1" - independently of the resistor being installed or not. This has been fixed in the V5.1 boards by making the pull-down resistors 1k.
One solution would be to replace R1901, but IMHO the easier thing would be to add
omap5-letux-cortex15-v5.0+pyra-v4.9.dts
which would include omap5-letux-cortex15-v5.0+pyra-v5.0.dts to work around this bad version detection. This is not a real problem since AFAIR only 2 or 3 real V4.9 boards did exist and none combined with a V5.0 CPU board.
Or you can simply rename/duplicate the .dtb
We could also do a workaround in u-boot but I am not sure if we should do that because u-boot is doing what it can.
BR and thanks, Nikolaus
Am 14.02.2017 um 09:37 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi aTc,
Am 13.02.2017 um 22:58 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 13.02.2017 um 22:51 schrieb aTc atc@k-n-p.org:
the 2016.11 u-boot board detections sets fdtfile to "omap5-letux-cortex15-v5.0+pyra-v4.9.dtb" on my board, is this actually the right version for this board ?
I think you received your prototypes a while ago. Therefore it should be right. I am not sure if I still have this combination which means we have to add another .dts for it to mix the right CPU and Mainboard versions.
Here's a picture of the thing : http://wreck.k-n-p.org/py-2.jpeg http://wreck.k-n-p.org/py-4.jpeg
Yes, the CPU board indeed seems to be V5.0.
Let me check tomorrow.
I have verified and both of your boards should be V5.0. Version detection software is also correct, but what is wrong is the version encoding resistor R1901.
It is 10k but the pull-up of the OMAP5 is much stronger than on the OMAP5 so that if the omap5 pulls up we will always see a "1" - independently of the resistor being installed or not. This has been fixed in the V5.1 boards by making the pull-down resistors 1k.
One solution would be to replace R1901, but IMHO the easier thing would be to add
omap5-letux-cortex15-v5.0+pyra-v4.9.dts
which would include omap5-letux-cortex15-v5.0+pyra-v5.0.dts to work around this bad version detection. This is not a real problem since AFAIR only 2 or 3 real V4.9 boards did exist and none combined with a V5.0 CPU board.
Or you can simply rename/duplicate the .dtb
We could also do a workaround in u-boot but I am not sure if we should do that because u-boot is doing what it can.
The more I think about this, it appears to be that a workaround in u-boot is the better way. Because then the .dtb file matches the version numbers that are printed on the PCBs.
BR, Nikolaus
Am 14.02.2017 um 10:08 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 14.02.2017 um 09:37 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi aTc,
Am 13.02.2017 um 22:58 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 13.02.2017 um 22:51 schrieb aTc atc@k-n-p.org:
the 2016.11 u-boot board detections sets fdtfile to "omap5-letux-cortex15-v5.0+pyra-v4.9.dtb" on my board, is this actually the right version for this board ?
I think you received your prototypes a while ago. Therefore it should be right. I am not sure if I still have this combination which means we have to add another .dts for it to mix the right CPU and Mainboard versions.
Here's a picture of the thing : http://wreck.k-n-p.org/py-2.jpeg http://wreck.k-n-p.org/py-4.jpeg
Yes, the CPU board indeed seems to be V5.0.
Let me check tomorrow.
I have verified and both of your boards should be V5.0. Version detection software is also correct, but what is wrong is the version encoding resistor R1901.
It is 10k but the pull-up of the OMAP5 is much stronger than on the OMAP5 so that if the omap5 pulls up we will always see a "1" - independently of the resistor being installed or not. This has been fixed in the V5.1 boards by making the pull-down resistors 1k.
One solution would be to replace R1901, but IMHO the easier thing would be to add
omap5-letux-cortex15-v5.0+pyra-v4.9.dts
which would include omap5-letux-cortex15-v5.0+pyra-v5.0.dts to work around this bad version detection. This is not a real problem since AFAIR only 2 or 3 real V4.9 boards did exist and none combined with a V5.0 CPU board.
Or you can simply rename/duplicate the .dtb
We could also do a workaround in u-boot but I am not sure if we should do that because u-boot is doing what it can.
The more I think about this, it appears to be that a workaround in u-boot is the better way. Because then the .dtb file matches the version numbers that are printed on the PCBs.
Done. Please test if it solves your problem:
http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=9aa860994da878eb8daeb...
BR and thanks, Nikolaus
-
aTc -
H. Nikolaus Schaller -
Matthijs van Duin