| Message ID | 1433351007-1704-2-git-send-email-contact@paulk.fr |
|---|---|
| State | Superseded |
| Headers | show |
The first part of this changeset introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code. First, the omap_boot_parameters structure becomes platform-specific, since its definition differs a bit across omap platforms. The offsets are removed as well since it is U-Boot's coding style to use structures for mapping such kind of data (in the sense that it is similar to registers). It is correct to assume that romcode structure encoding is the same as U-Boot, given the description of these structures in the TRMs. The original address provided by the bootrom is passed to the U-Boot binary instead of a duplicate of the structure stored in global data. This allows to have only the relevant (boot device and mode) information stored in global data. It is also expected that the address where the bootrom stores that information is not overridden by the U-Boot SPL or U-Boot. The save_omap_boot_params is expected to handle all special cases where the data provided by the bootrom cannot be used as-is, so that spl_boot_device and spl_boot_mode only return the data from global data. The second part of this changeset adds support for reading the SYS_BOOT pins on omap devices (no am33xx support yet) in order to fallback to the memory-preferred boot device described by the pins when peripheral booting is used. In particular, this allows loading the U-Boot SPL through either UART or USB and still having it to load U-Boot from memory when UART or USB are not valid boot devices. This whole changeset was build-tested on all omap boards (omap3, omap4, omap5, am33xx) and tested at run-time on a single omap3 device only. I would be very glad to see board maintainers give a go at the changeset before it gets merged, especially on devices like the Nokia RX-51 (N900) where some specific adaptation was needed.
On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > I would be very glad to see board maintainers give a go > at the changeset before it gets merged, especially on devices like > the Nokia RX-51 (N900) where some specific adaptation was needed. So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f (see other email thread). Until somebody fix that broken commit, I cannot test your new patches in qemu or on (real) Nokia N900.
On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > I would be very glad to see board maintainers give a go > > at the changeset before it gets merged, especially on devices like > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > (see other email thread). Until somebody fix that broken commit, I > cannot test your new patches in qemu or on (real) Nokia N900. Now I tested this patch series on top of u-boot master with applied my patch "Nokia RX-51: Fix calculating return address in save_boot_params". And it really as I thought broke booting U-Boot on Nokia N900 in qemu. So this patch series is NAK from my side.
On Tuesday, June 09, 2015 at 06:28:29 PM, Pali Rohár wrote: > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > I would be very glad to see board maintainers give a go > > at the changeset before it gets merged, especially on devices like > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f (see > other email thread Would be nice if you added a link to the thread in some mail archive ... > ). Until somebody fix that broken commit, I cannot > test your new patches in qemu or on (real) Nokia N900. What about you fixing it ? ;-) Best regards, Marek Vasut
On Wednesday 10 June 2015 06:27:37 Marek Vasut wrote: > On Tuesday, June 09, 2015 at 06:28:29 PM, Pali Rohár wrote: > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > I would be very glad to see board maintainers give a go > > > at the changeset before it gets merged, especially on devices > > > like the Nokia RX-51 (N900) where some specific adaptation was > > > needed. > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > (see other email thread > > Would be nice if you added a link to the thread in some mail archive > ... > > > ). Until somebody fix that broken commit, I cannot > > test your new patches in qemu or on (real) Nokia N900. > > What about you fixing it ? ;-) > > Best regards, > Marek Vasut Yesterday I sent patch which fixing that problem.
On Wed 2015-06-10 06:27:37, Marek Vasut wrote: > On Tuesday, June 09, 2015 at 06:28:29 PM, Pali Rohár wrote: > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > I would be very glad to see board maintainers give a go > > > at the changeset before it gets merged, especially on devices like > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f (see > > other email thread > > Would be nice if you added a link to the thread in some mail archive ... > > > ). Until somebody fix that broken commit, I cannot > > test your new patches in qemu or on (real) Nokia N900. > > What about you fixing it ? ;-) Traditionally, regressions are fixed by whoever caused then, not whoever was patient enough to bisect them... But in this case, fix is already available, so that is moot. Pavel
On Wednesday 10 June 2015 06:27:37 Marek Vasut wrote: > On Tuesday, June 09, 2015 at 06:28:29 PM, Pali Rohár wrote: > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > I would be very glad to see board maintainers give a go > > > at the changeset before it gets merged, especially on devices like > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f (see > > other email thread > > Would be nice if you added a link to the thread in some mail archive ... > What about searching for last emails ;-) It took me less then minute: http://lists.denx.de/pipermail/u-boot/2015-June/216237.html Patch with my fix there: http://lists.denx.de/pipermail/u-boot/2015-June/216241.html
On Wednesday 10 June 2015 08:48:38 Pavel Machek wrote: > On Wed 2015-06-10 06:27:37, Marek Vasut wrote: > > What about you fixing it ? ;-) > > Traditionally, regressions are fixed by whoever caused then, not > whoever was patient enough to bisect them... > I agree. Who broke something should also fix it. Or revert commits which broke it.
On Wednesday, June 10, 2015 at 09:45:40 AM, Pali Rohár wrote: > On Wednesday 10 June 2015 06:27:37 Marek Vasut wrote: > > On Tuesday, June 09, 2015 at 06:28:29 PM, Pali Rohár wrote: > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > I would be very glad to see board maintainers give a go > > > > at the changeset before it gets merged, especially on devices like > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f (see > > > other email thread > > > > Would be nice if you added a link to the thread in some mail archive ... > > What about searching for last emails ;-) "See other email thread" is making my search very easy indeed ... > It took me less then minute: > http://lists.denx.de/pipermail/u-boot/2015-June/216237.html > > Patch with my fix there: > http://lists.denx.de/pipermail/u-boot/2015-June/216241.html Best regards, Marek Vasut
Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > I would be very glad to see board maintainers give a go > > > at the changeset before it gets merged, especially on devices like > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > (see other email thread). Until somebody fix that broken commit, I > > cannot test your new patches in qemu or on (real) Nokia N900. > > Now I tested this patch series on top of u-boot master with applied my > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. I'm confused here -- did you try booting on the actual device or in qemu? > So this patch series is NAK from my side. Thanks for testing. Of course, the point is to make another version of the patch set that fits the N900 too, since we really need to integrate the omap3 to the common omap boot mechanism anyways. I may be able to get my hands on a N900 in a short while. If you're interested, you're welcome to look at the issue and suggest what changes should be made to make the set compatible with the N900!
On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > I would be very glad to see board maintainers give a go > > > > at the changeset before it gets merged, especially on devices like > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > (see other email thread). Until somebody fix that broken commit, I > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > Now I tested this patch series on top of u-boot master with applied my > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > I'm confused here -- did you try booting on the actual device or in > qemu? > I tested your changes only in qemu. But because you removed (or better masked) required lowlevel asm code, it will not work on real n900 too. > > So this patch series is NAK from my side. > > Thanks for testing. Of course, the point is to make another version of > the patch set that fits the N900 too, since we really need to integrate > the omap3 to the common omap boot mechanism anyways. > Make sure that asm function in rx51 lowlevel asm file is called immediately from start.S. It is required. Basically no modification to that function should be needed (maybe just fixing return address in lr). > I may be able to get my hands on a N900 in a short while. Do you have n900 device? Or are you going to use qemu? Really, for development u-boot for n900 is easier to use qemu as you can easier debug code... > If you're interested, you're welcome to look at the issue and suggest > what changes should be made to make the set compatible with the N900! > Do not hide/mask/remove that required asm function. That should be all.
On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > I would be very glad to see board maintainers give a go > > > > > at the changeset before it gets merged, especially on devices like > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > (see other email thread). Until somebody fix that broken commit, I > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > I'm confused here -- did you try booting on the actual device or in > > qemu? > > > > I tested your changes only in qemu. But because you removed (or better > masked) required lowlevel asm code, it will not work on real n900 too. > > > > So this patch series is NAK from my side. > > > > Thanks for testing. Of course, the point is to make another version of > > the patch set that fits the N900 too, since we really need to integrate > > the omap3 to the common omap boot mechanism anyways. > > > > Make sure that asm function in rx51 lowlevel asm file is called > immediately from start.S. It is required. Basically no modification to > that function should be needed (maybe just fixing return address in lr). > > > I may be able to get my hands on a N900 in a short while. > > Do you have n900 device? Or are you going to use qemu? > > Really, for development u-boot for n900 is easier to use qemu as you can > easier debug code... > > > If you're interested, you're welcome to look at the issue and suggest > > what changes should be made to make the set compatible with the N900! > > > > Do not hide/mask/remove that required asm function. That should be all. > And why is change to file board/nokia/rx51/lowlevel_init.S required?
Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > I would be very glad to see board maintainers give a go > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > I'm confused here -- did you try booting on the actual device or in > > > qemu? > > > > > > > I tested your changes only in qemu. But because you removed (or better > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > So this patch series is NAK from my side. > > > > > > Thanks for testing. Of course, the point is to make another version of > > > the patch set that fits the N900 too, since we really need to integrate > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > immediately from start.S. It is required. Basically no modification to > > that function should be needed (maybe just fixing return address in lr). The problem is that this declaration conflicts with the one from omap-common's lowlevel_init.S. I understand that it is not needed for the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. Perhaps the best way to do things here would be to have a config option clearly stating that it should not expect the booting device information structure in r0. This situation is not specific to the RX-51 anyways. > > > I may be able to get my hands on a N900 in a short while. > > > > Do you have n900 device? Or are you going to use qemu? > > > > Really, for development u-boot for n900 is easier to use qemu as you can > > easier debug code... I didin't know it was possible, perhaps I'll try it. I have a friend who owns a N900, I could certainly borrow it for a while to ensure that this patch set goes smoothly on it. > > > If you're interested, you're welcome to look at the issue and suggest > > > what changes should be made to make the set compatible with the N900! > > > > > > > Do not hide/mask/remove that required asm function. That should be all. > And why is change to file board/nokia/rx51/lowlevel_init.S required? See my comment above.
On Wednesday 10 June 2015 12:58:11 Paul Kocialkowski wrote: > Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > > I would be very glad to see board maintainers give a go > > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > > > I'm confused here -- did you try booting on the actual device or in > > > > qemu? > > > > > > > > > > I tested your changes only in qemu. But because you removed (or better > > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > > > So this patch series is NAK from my side. > > > > > > > > Thanks for testing. Of course, the point is to make another version of > > > > the patch set that fits the N900 too, since we really need to integrate > > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > > immediately from start.S. It is required. Basically no modification to > > > that function should be needed (maybe just fixing return address in lr). > > The problem is that this declaration conflicts with the one from > omap-common's lowlevel_init.S. I understand that it is not needed for > the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. > Yes. > Perhaps the best way to do things here would be to have a config option > clearly stating that it should not expect the booting device information > structure in r0. This situation is not specific to the RX-51 anyways. > Sounds good. > > > > I may be able to get my hands on a N900 in a short while. > > > > > > Do you have n900 device? Or are you going to use qemu? > > > > > > Really, for development u-boot for n900 is easier to use qemu as you can > > > easier debug code... > > I didin't know it was possible, perhaps I'll try it. I have a friend who > owns a N900, I could certainly borrow it for a while to ensure that this > patch set goes smoothly on it. > Look at this email with information how to build u-boot and run in qemu: http://lists.denx.de/pipermail/u-boot/2015-January/200171.html > > > > If you're interested, you're welcome to look at the issue and suggest > > > > what changes should be made to make the set compatible with the N900! > > > > > > > > > > Do not hide/mask/remove that required asm function. That should be all. > > > And why is change to file board/nokia/rx51/lowlevel_init.S required? > > See my comment above. >
Le mercredi 10 juin 2015 à 13:35 +0200, Pali Rohár a écrit : > On Wednesday 10 June 2015 12:58:11 Paul Kocialkowski wrote: > > Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > > > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > > > I would be very glad to see board maintainers give a go > > > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > > > > > I'm confused here -- did you try booting on the actual device or in > > > > > qemu? > > > > > > > > > > > > > I tested your changes only in qemu. But because you removed (or better > > > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > > > > > So this patch series is NAK from my side. > > > > > > > > > > Thanks for testing. Of course, the point is to make another version of > > > > > the patch set that fits the N900 too, since we really need to integrate > > > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > > > immediately from start.S. It is required. Basically no modification to > > > > that function should be needed (maybe just fixing return address in lr). > > > > The problem is that this declaration conflicts with the one from > > omap-common's lowlevel_init.S. I understand that it is not needed for > > the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. > > > > Yes. > > > Perhaps the best way to do things here would be to have a config option > > clearly stating that it should not expect the booting device information > > structure in r0. This situation is not specific to the RX-51 anyways. > > Sounds good. I just sent out v3 that fixes n900 support the way I suggested. I was able to get my hands on the device and along with the patch you sent out earlier this week, everything seems to work fine.
On Friday 12 June 2015 13:32:56 Paul Kocialkowski wrote: > Le mercredi 10 juin 2015 à 13:35 +0200, Pali Rohár a écrit : > > On Wednesday 10 June 2015 12:58:11 Paul Kocialkowski wrote: > > > Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > > > > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > > > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > > > > I would be very glad to see board maintainers give a go > > > > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > > > > > > > I'm confused here -- did you try booting on the actual device or in > > > > > > qemu? > > > > > > > > > > > > > > > > I tested your changes only in qemu. But because you removed (or better > > > > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > > > > > > > So this patch series is NAK from my side. > > > > > > > > > > > > Thanks for testing. Of course, the point is to make another version of > > > > > > the patch set that fits the N900 too, since we really need to integrate > > > > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > > > > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > > > > immediately from start.S. It is required. Basically no modification to > > > > > that function should be needed (maybe just fixing return address in lr). > > > > > > The problem is that this declaration conflicts with the one from > > > omap-common's lowlevel_init.S. I understand that it is not needed for > > > the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. > > > > > > > Yes. > > > > > Perhaps the best way to do things here would be to have a config option > > > clearly stating that it should not expect the booting device information > > > structure in r0. This situation is not specific to the RX-51 anyways. > > > > Sounds good. > > I just sent out v3 that fixes n900 support the way I suggested. I was > able to get my hands on the device and along with the patch you sent out > earlier this week, everything seems to work fine. > Hello, have you also tested that "combined" image of u-boot and linux kernel (in uImage format) is working fine? That u-boot can boot that "attached" kernel image without problem. Script for generating "combined" image from u-boot.bin and uImage kernel: https://gitorious.org/u-boot-shr/u-boot/source/maemo:debian/u-boot-gen-combined You can boot "attached" kernel via u-boot command "run attachboot".
Le vendredi 12 juin 2015 à 13:56 +0200, Pali Rohár a écrit : > On Friday 12 June 2015 13:32:56 Paul Kocialkowski wrote: > > Le mercredi 10 juin 2015 à 13:35 +0200, Pali Rohár a écrit : > > > On Wednesday 10 June 2015 12:58:11 Paul Kocialkowski wrote: > > > > Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > > > > > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > > > > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > > > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > > > > > I would be very glad to see board maintainers give a go > > > > > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > > > > > > > > > I'm confused here -- did you try booting on the actual device or in > > > > > > > qemu? > > > > > > > > > > > > > > > > > > > I tested your changes only in qemu. But because you removed (or better > > > > > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > > > > > > > > > So this patch series is NAK from my side. > > > > > > > > > > > > > > Thanks for testing. Of course, the point is to make another version of > > > > > > > the patch set that fits the N900 too, since we really need to integrate > > > > > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > > > > > > > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > > > > > immediately from start.S. It is required. Basically no modification to > > > > > > that function should be needed (maybe just fixing return address in lr). > > > > > > > > The problem is that this declaration conflicts with the one from > > > > omap-common's lowlevel_init.S. I understand that it is not needed for > > > > the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. > > > > > > > > > > Yes. > > > > > > > Perhaps the best way to do things here would be to have a config option > > > > clearly stating that it should not expect the booting device information > > > > structure in r0. This situation is not specific to the RX-51 anyways. > > > > > > Sounds good. > > > > I just sent out v3 that fixes n900 support the way I suggested. I was > > able to get my hands on the device and along with the patch you sent out > > earlier this week, everything seems to work fine. > > > > Hello, > > have you also tested that "combined" image of u-boot and linux kernel > (in uImage format) is working fine? That u-boot can boot that "attached" > kernel image without problem. > > Script for generating "combined" image from u-boot.bin and uImage kernel: > https://gitorious.org/u-boot-shr/u-boot/source/maemo:debian/u-boot-gen-combined > > You can boot "attached" kernel via u-boot command "run attachboot". I haven't tried that, but since I have removed the changes I added to the rx51-specific lowlevel_init.S, I expect that nothing should have changed on this side. I do not have serial on the device, so it's harder for me to figure out whether a kernel will run fine (I would need a graphical indication on the screen). You're welcome to test that it still works, though.
On Friday 12 June 2015 15:01:47 Paul Kocialkowski wrote: > Le vendredi 12 juin 2015 à 13:56 +0200, Pali Rohár a écrit : > > On Friday 12 June 2015 13:32:56 Paul Kocialkowski wrote: > > > Le mercredi 10 juin 2015 à 13:35 +0200, Pali Rohár a écrit : > > > > On Wednesday 10 June 2015 12:58:11 Paul Kocialkowski wrote: > > > > > Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > > > > > > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > > > > > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > > > > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > > > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > > > > > > I would be very glad to see board maintainers give a go > > > > > > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > > > > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > > > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > > > > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > > > > > > > > > > > I'm confused here -- did you try booting on the actual device or in > > > > > > > > qemu? > > > > > > > > > > > > > > > > > > > > > > I tested your changes only in qemu. But because you removed (or better > > > > > > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > > > > > > > > > > > So this patch series is NAK from my side. > > > > > > > > > > > > > > > > Thanks for testing. Of course, the point is to make another version of > > > > > > > > the patch set that fits the N900 too, since we really need to integrate > > > > > > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > > > > > > > > > > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > > > > > > immediately from start.S. It is required. Basically no modification to > > > > > > > that function should be needed (maybe just fixing return address in lr). > > > > > > > > > > The problem is that this declaration conflicts with the one from > > > > > omap-common's lowlevel_init.S. I understand that it is not needed for > > > > > the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. > > > > > > > > > > > > > Yes. > > > > > > > > > Perhaps the best way to do things here would be to have a config option > > > > > clearly stating that it should not expect the booting device information > > > > > structure in r0. This situation is not specific to the RX-51 anyways. > > > > > > > > Sounds good. > > > > > > I just sent out v3 that fixes n900 support the way I suggested. I was > > > able to get my hands on the device and along with the patch you sent out > > > earlier this week, everything seems to work fine. > > > > > > > Hello, > > > > have you also tested that "combined" image of u-boot and linux kernel > > (in uImage format) is working fine? That u-boot can boot that "attached" > > kernel image without problem. > > > > Script for generating "combined" image from u-boot.bin and uImage kernel: > > https://gitorious.org/u-boot-shr/u-boot/source/maemo:debian/u-boot-gen-combined > > > > You can boot "attached" kernel via u-boot command "run attachboot". > > I haven't tried that, but since I have removed the changes I added to > the rx51-specific lowlevel_init.S, I expect that nothing should have > changed on this side. > > I do not have serial on the device, so it's harder for me to figure out > whether a kernel will run fine (I would need a graphical indication on > the screen). > > You're welcome to test that it still works, though. > If you compile fbdev into kernel image then you should see something on screen... But I will try to test new patch series at the weekend.
Le vendredi 12 juin 2015 à 15:10 +0200, Pali Rohár a écrit : > On Friday 12 June 2015 15:01:47 Paul Kocialkowski wrote: > > Le vendredi 12 juin 2015 à 13:56 +0200, Pali Rohár a écrit : > > > On Friday 12 June 2015 13:32:56 Paul Kocialkowski wrote: > > > > Le mercredi 10 juin 2015 à 13:35 +0200, Pali Rohár a écrit : > > > > > On Wednesday 10 June 2015 12:58:11 Paul Kocialkowski wrote: > > > > > > Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > > > > > > > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > > > > > > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > > > > > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > > > > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > > > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > > > > > > > I would be very glad to see board maintainers give a go > > > > > > > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > > > > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > > > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > > > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > > > > > > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > > > > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > > > > > > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > > > > > > > > > > > > > I'm confused here -- did you try booting on the actual device or in > > > > > > > > > qemu? > > > > > > > > > > > > > > > > > > > > > > > > > I tested your changes only in qemu. But because you removed (or better > > > > > > > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > > > > > > > > > > > > > So this patch series is NAK from my side. > > > > > > > > > > > > > > > > > > Thanks for testing. Of course, the point is to make another version of > > > > > > > > > the patch set that fits the N900 too, since we really need to integrate > > > > > > > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > > > > > > > > > > > > > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > > > > > > > immediately from start.S. It is required. Basically no modification to > > > > > > > > that function should be needed (maybe just fixing return address in lr). > > > > > > > > > > > > The problem is that this declaration conflicts with the one from > > > > > > omap-common's lowlevel_init.S. I understand that it is not needed for > > > > > > the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. > > > > > > > > > > > > > > > > Yes. > > > > > > > > > > > Perhaps the best way to do things here would be to have a config option > > > > > > clearly stating that it should not expect the booting device information > > > > > > structure in r0. This situation is not specific to the RX-51 anyways. > > > > > > > > > > Sounds good. > > > > > > > > I just sent out v3 that fixes n900 support the way I suggested. I was > > > > able to get my hands on the device and along with the patch you sent out > > > > earlier this week, everything seems to work fine. > > > > > > > > > > Hello, > > > > > > have you also tested that "combined" image of u-boot and linux kernel > > > (in uImage format) is working fine? That u-boot can boot that "attached" > > > kernel image without problem. > > > > > > Script for generating "combined" image from u-boot.bin and uImage kernel: > > > https://gitorious.org/u-boot-shr/u-boot/source/maemo:debian/u-boot-gen-combined > > > > > > You can boot "attached" kernel via u-boot command "run attachboot". > > > > I haven't tried that, but since I have removed the changes I added to > > the rx51-specific lowlevel_init.S, I expect that nothing should have > > changed on this side. > > > > I do not have serial on the device, so it's harder for me to figure out > > whether a kernel will run fine (I would need a graphical indication on > > the screen). > > > > You're welcome to test that it still works, though. > > > > If you compile fbdev into kernel image then you should see something on > screen... But I will try to test new patch series at the weekend. Of course, I could always do that, but as far as I'm concerned, this patch set works as expected on the n900 and any further testing, while being greatly appreciated, should not be necessary.
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index f3725b2..464a5d1 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -26,9 +26,7 @@ ifeq ($(CONFIG_SYS_DCACHE_OFF),) obj-y += omap-cache.o endif -ifeq ($(CONFIG_OMAP34XX),) obj-y += boot-common.o -endif obj-y += lowlevel_init.o obj-y += mem-common.o diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c b/arch/arm/cpu/armv7/omap-common/boot-common.c index bbc6bed..3bd3f49 100644 --- a/arch/arm/cpu/armv7/omap-common/boot-common.c +++ b/arch/arm/cpu/armv7/omap-common/boot-common.c @@ -17,25 +17,26 @@ #include <asm/arch/sys_proto.h> #include <watchdog.h> #include <scsi.h> +#include <i2c.h> DECLARE_GLOBAL_DATA_PTR; void save_omap_boot_params(void) { - u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS); - u8 boot_device; - u32 dev_desc, dev_data; + u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS); + struct omap_boot_parameters *omap_boot_params; + u32 boot_device; + u32 boot_mode; - if ((rom_params < NON_SECURE_SRAM_START) || - (rom_params > NON_SECURE_SRAM_END)) + if ((boot_params < NON_SECURE_SRAM_START) || + (boot_params > NON_SECURE_SRAM_END)) return; - /* - * rom_params can be type casted to omap_boot_parameters and - * used. But it not correct to assume that romcode structure - * encoding would be same as u-boot. So use the defined offsets. - */ - boot_device = *((u8 *)(rom_params + BOOT_DEVICE_OFFSET)); + omap_boot_params = (struct omap_boot_parameters *)boot_params; + + /* Boot device */ + + boot_device = omap_boot_params->boot_device; #if defined(BOOT_DEVICE_NAND_I2C) /* @@ -47,29 +48,6 @@ void save_omap_boot_params(void) if (boot_device == BOOT_DEVICE_NAND_I2C) boot_device = BOOT_DEVICE_NAND; #endif - gd->arch.omap_boot_params.omap_bootdevice = boot_device; - - gd->arch.omap_boot_params.ch_flags = - *((u8 *)(rom_params + CH_FLAGS_OFFSET)); - - if ((boot_device >= MMC_BOOT_DEVICES_START) && - (boot_device <= MMC_BOOT_DEVICES_END)) { -#if !defined(CONFIG_AM33XX) && !defined(CONFIG_TI81XX) && \ - !defined(CONFIG_AM43XX) - if ((omap_hw_init_context() == - OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) { - gd->arch.omap_boot_params.omap_bootmode = - *((u8 *)(rom_params + BOOT_MODE_OFFSET)); - } else -#endif - { - dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET)); - dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET)); - gd->arch.omap_boot_params.omap_bootmode = - *((u32 *)(dev_data + BOOT_MODE_OFFSET)); - } - } - #if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX) /* * We get different values for QSPI_1 and QSPI_4 being used, but @@ -77,31 +55,66 @@ void save_omap_boot_params(void) * mangle the later code, if we're coming in as QSPI_4 just * change to the QSPI_1 value. */ - if (gd->arch.omap_boot_params.omap_bootdevice == 11) - gd->arch.omap_boot_params.omap_bootdevice = BOOT_DEVICE_SPI; + if (boot_device == 11) + boot_device = BOOT_DEVICE_SPI; +#endif + + gd->arch.omap_boot_device = boot_device; + + /* Boot mode */ + + boot_mode = MMCSD_MODE_UNDEFINED; + + if ((boot_device >= MMC_BOOT_DEVICES_START) && + (boot_device <= MMC_BOOT_DEVICES_END)) { +#ifdef CONFIG_OMAP34XX + switch (boot_device) { + case BOOT_DEVICE_MMC1: + boot_mode = MMCSD_MODE_FS; + break; + case BOOT_DEVICE_MMC2: + boot_mode = MMCSD_MODE_RAW; + break; + } +#else + boot_params = omap_boot_params->boot_device_descriptor; + if ((boot_params < NON_SECURE_SRAM_START) || + (boot_params > NON_SECURE_SRAM_END)) + return; + + boot_params = *((u32 *)(boot_params + DEVICE_DATA_OFFSET)); + if ((boot_params < NON_SECURE_SRAM_START) || + (boot_params > NON_SECURE_SRAM_END)) + return; + + boot_mode = *((u32 *)(boot_params + BOOT_MODE_OFFSET)); + + if (boot_mode != MMCSD_MODE_FS && + boot_mode != MMCSD_MODE_RAW) +#ifdef CONFIG_SUPPORT_EMMC_BOOT + boot_mode = MMCSD_MODE_EMMCBOOT +#else + boot_mode = MMCSD_MODE_UNDEFINED; +#endif #endif + } + + gd->arch.omap_boot_mode = boot_mode; + + /* CH flags */ + + gd->arch.omap_ch_flags = omap_boot_params->ch_flags; } #ifdef CONFIG_SPL_BUILD u32 spl_boot_device(void) { - return (u32) (gd->arch.omap_boot_params.omap_bootdevice); + return gd->arch.omap_boot_device; } u32 spl_boot_mode(void) { - u32 val = gd->arch.omap_boot_params.omap_bootmode; - - if (val == MMCSD_MODE_RAW) - return MMCSD_MODE_RAW; - else if (val == MMCSD_MODE_FS) - return MMCSD_MODE_FS; - else -#ifdef CONFIG_SUPPORT_EMMC_BOOT - return MMCSD_MODE_EMMCBOOT; -#else - return MMCSD_MODE_UNDEFINED; -#endif + return gd->arch.omap_boot_mode; } void spl_board_init(void) @@ -116,9 +129,12 @@ void spl_board_init(void) /* Prepare console output */ preloader_console_init(); -#ifdef CONFIG_SPL_NAND_SUPPORT +#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT) gpmc_init(); #endif +#ifdef CONFIG_SPL_I2C_SUPPORT + i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE); +#endif #if defined(CONFIG_AM33XX) && defined(CONFIG_SPL_MUSB_NEW_SUPPORT) arch_misc_init(); #endif @@ -152,7 +168,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image) debug("image entry point: 0x%X\n", spl_image->entry_point); /* Pass the saved boot_params from rom code */ - image_entry((u32 *)&gd->arch.omap_boot_params); + image_entry((u32 *)*((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS)); } #endif diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S index 746df92..80619b0 100644 --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S @@ -16,13 +16,11 @@ #include <asm/arch/spl.h> #include <linux/linkage.h> -#ifndef CONFIG_OMAP34XX ENTRY(save_boot_params) ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS str r0, [r1] b save_boot_params_ret ENDPROC(save_boot_params) -#endif ENTRY(omap_smc1) PUSH {r4-r12, lr} @ save registers - ROM code may pollute diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c index b064c0c..4914682 100644 --- a/arch/arm/cpu/armv7/omap3/board.c +++ b/arch/arm/cpu/armv7/omap3/board.c @@ -73,62 +73,6 @@ const struct gpio_bank *const omap_gpio_bank = gpio_bank_34xx; #endif -#ifdef CONFIG_SPL_BUILD -/* -* We use static variables because global data is not ready yet. -* Initialized data is available in SPL right from the beginning. -* We would not typically need to save these parameters in regular -* U-Boot. This is needed only in SPL at the moment. -*/ -u32 omap3_boot_device = BOOT_DEVICE_NAND; - -/* auto boot mode detection is not possible for OMAP3 - hard code */ -u32 spl_boot_mode(void) -{ - switch (spl_boot_device()) { - case BOOT_DEVICE_MMC2: - return MMCSD_MODE_RAW; - case BOOT_DEVICE_MMC1: - return MMCSD_MODE_FS; - break; - default: - puts("spl: ERROR: unknown device - can't select boot mode\n"); - hang(); - } -} - -u32 spl_boot_device(void) -{ - return omap3_boot_device; -} - -int board_mmc_init(bd_t *bis) -{ - switch (spl_boot_device()) { - case BOOT_DEVICE_MMC1: - omap_mmc_init(0, 0, 0, -1, -1); - break; - case BOOT_DEVICE_MMC2: - case BOOT_DEVICE_MMC2_2: - omap_mmc_init(1, 0, 0, -1, -1); - break; - } - return 0; -} - -void spl_board_init(void) -{ - preloader_console_init(); -#if defined(CONFIG_SPL_NAND_SUPPORT) || defined(CONFIG_SPL_ONENAND_SUPPORT) - gpmc_init(); -#endif -#ifdef CONFIG_SPL_I2C_SUPPORT - i2c_init(CONFIG_SYS_OMAP24_I2C_SPEED, CONFIG_SYS_OMAP24_I2C_SLAVE); -#endif -} -#endif /* CONFIG_SPL_BUILD */ - - /****************************************************************************** * Routine: secure_unlock * Description: Setup security registers for access diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S b/arch/arm/cpu/armv7/omap3/lowlevel_init.S index 2497613..1e58772 100644 --- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S @@ -16,16 +16,6 @@ #include <asm/arch/clocks_omap3.h> #include <linux/linkage.h> -#ifdef CONFIG_SPL_BUILD -ENTRY(save_boot_params) - ldr r4, =omap3_boot_device - ldr r5, [r0, #0x4] - and r5, r5, #0xff - str r5, [r4] - b save_boot_params_ret -ENDPROC(save_boot_params) -#endif - /* * Funtion for making PPA HAL API calls in secure devices * Input: diff --git a/arch/arm/include/asm/arch-am33xx/omap.h b/arch/arm/include/asm/arch-am33xx/omap.h index e5c0b0d..47962da 100644 --- a/arch/arm/include/asm/arch-am33xx/omap.h +++ b/arch/arm/include/asm/arch-am33xx/omap.h @@ -33,4 +33,15 @@ #define AM4372_BOARD_VERSION_END SRAM_SCRATCH_SPACE_ADDR + 0x14 #define QSPI_BASE 0x47900000 #endif + +/* Boot parameters */ +#ifndef __ASSEMBLY__ +struct omap_boot_parameters { + unsigned int reserved; + unsigned int boot_device_descriptor; + unsigned char boot_device; + unsigned char reset_reason; +}; +#endif + #endif diff --git a/arch/arm/include/asm/arch-omap3/omap.h b/arch/arm/include/asm/arch-omap3/omap.h index 194b93b..537d13b 100644 --- a/arch/arm/include/asm/arch-omap3/omap.h +++ b/arch/arm/include/asm/arch-omap3/omap.h @@ -142,6 +142,7 @@ struct gpio { #define NON_SECURE_SRAM_START 0x40208000 /* Works for GP & EMU */ #define NON_SECURE_SRAM_END 0x40210000 +#define SRAM_SCRATCH_SPACE_ADDR 0x4020E000 #define LOW_LEVEL_SRAM_STACK 0x4020FFFC @@ -245,4 +246,16 @@ struct gpio { /* ABB tranxdone mask */ #define OMAP_ABB_MPU_TXDONE_MASK (0x1 << 26) +/* Boot parameters */ +#ifndef __ASSEMBLY__ +struct omap_boot_parameters { + unsigned int boot_message; + unsigned char boot_device; + unsigned char reserved; + unsigned char reset_reason; + unsigned char ch_flags; + unsigned int boot_device_descriptor; +}; +#endif + #endif diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h index 3e45ce1..cfa4d58 100644 --- a/arch/arm/include/asm/arch-omap3/sys_proto.h +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h @@ -75,4 +75,6 @@ void get_dieid(u32 *id); void do_omap3_emu_romcode_call(u32 service_id, u32 parameters); void omap3_set_aux_cr_secure(u32 acr); u32 warm_reset(void); + +void save_omap_boot_params(void); #endif diff --git a/arch/arm/include/asm/arch-omap4/omap.h b/arch/arm/include/asm/arch-omap4/omap.h index d43dc26..12b1a09 100644 --- a/arch/arm/include/asm/arch-omap4/omap.h +++ b/arch/arm/include/asm/arch-omap4/omap.h @@ -124,4 +124,15 @@ struct s32ktimer { /* ABB tranxdone mask */ #define OMAP_ABB_MPU_TXDONE_MASK (0x1 << 7) +/* Boot parameters */ +#ifndef __ASSEMBLY__ +struct omap_boot_parameters { + unsigned int boot_message; + unsigned int boot_device_descriptor; + unsigned char boot_device; + unsigned char reset_reason; + unsigned char ch_flags; +}; +#endif + #endif diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index e844bfb..4ba87b9 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -260,4 +260,16 @@ struct io_delay { u32 dly; }; #endif /* __ASSEMBLY__ */ + +/* Boot parameters */ +#ifndef __ASSEMBLY__ +struct omap_boot_parameters { + unsigned int boot_message; + unsigned int boot_device_descriptor; + unsigned char boot_device; + unsigned char reset_reason; + unsigned char ch_flags; +}; +#endif + #endif diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index bb24f33..4e3ea55 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -8,10 +8,6 @@ #ifndef __ASM_GBL_DATA_H #define __ASM_GBL_DATA_H -#ifdef CONFIG_OMAP -#include <asm/omap_boot.h> -#endif - /* Architecture-specific global data */ struct arch_global_data { #if defined(CONFIG_FSL_ESDHC) @@ -45,8 +41,10 @@ struct arch_global_data { unsigned long tlb_size; #endif -#ifdef CONFIG_OMAP - struct omap_boot_parameters omap_boot_params; +#ifdef CONFIG_OMAP_COMMON + u32 omap_boot_device; + u32 omap_boot_mode; + u8 omap_ch_flags; #endif #ifdef CONFIG_FSL_LSCH3 unsigned long mem2_clk; diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h deleted file mode 100644 index f77f9d6..0000000 --- a/arch/arm/include/asm/omap_boot.h +++ /dev/null @@ -1,34 +0,0 @@ -/* - * (C) Copyright 2013 - * Texas Instruments, <www.ti.com> - * - * Sricharan R <r.sricharan@ti.com> - * - * SPDX-License-Identifier: GPL-2.0+ - */ - -/* ROM code defines */ -/* Boot device */ -#define BOOT_DEVICE_MASK 0xFF -#define BOOT_DEVICE_OFFSET 0x8 -#define DEV_DESC_PTR_OFFSET 0x4 -#define DEV_DATA_PTR_OFFSET 0x18 -#define BOOT_MODE_OFFSET 0x8 -#define RESET_REASON_OFFSET 0x9 -#define CH_FLAGS_OFFSET 0xA - -#define CH_FLAGS_CHSETTINGS (0x1 << 0) -#define CH_FLAGS_CHRAM (0x1 << 1) -#define CH_FLAGS_CHFLASH (0x1 << 2) -#define CH_FLAGS_CHMMCSD (0x1 << 3) - -#ifndef __ASSEMBLY__ -struct omap_boot_parameters { - char *boot_message; - unsigned int mem_boot_descriptor; - unsigned char omap_bootdevice; - unsigned char reset_reason; - unsigned char ch_flags; - unsigned long omap_bootmode; -}; -#endif diff --git a/arch/arm/include/asm/omap_common.h b/arch/arm/include/asm/omap_common.h index b0296fb..e8c502c 100644 --- a/arch/arm/include/asm/omap_common.h +++ b/arch/arm/include/asm/omap_common.h @@ -673,4 +673,13 @@ static inline u8 is_dra7xx(void) #define OMAP_SRAM_SCRATCH_BOOT_PARAMS (SRAM_SCRATCH_SPACE_ADDR + 0x24) #define OMAP5_SRAM_SCRATCH_SPACE_END (SRAM_SCRATCH_SPACE_ADDR + 0x28) +/* Boot parameters */ +#define DEVICE_DATA_OFFSET 0x18 +#define BOOT_MODE_OFFSET 0x8 + +#define CH_FLAGS_CHSETTINGS (1 << 0) +#define CH_FLAGS_CHRAM (1 << 1) +#define CH_FLAGS_CHFLASH (1 << 2) +#define CH_FLAGS_CHMMCSD (1 << 3) + #endif /* _OMAP_COMMON_H_ */ diff --git a/arch/arm/include/asm/ti-common/sys_proto.h b/arch/arm/include/asm/ti-common/sys_proto.h index d3ab75f..2bdb71c 100644 --- a/arch/arm/include/asm/ti-common/sys_proto.h +++ b/arch/arm/include/asm/ti-common/sys_proto.h @@ -36,7 +36,7 @@ static inline u8 uboot_loaded_by_spl(void) * variable by both SPL and u-boot.Check out for CHSETTINGS, which is a * mandatory section if CH is present. */ - if ((gd->arch.omap_boot_params.ch_flags) & (CH_FLAGS_CHSETTINGS)) + if (gd->arch.omap_ch_flags & CH_FLAGS_CHSETTINGS) return 0; else return running_from_sdram();
This introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code. First, the omap_boot_parameters structure becomes platform-specific, since its definition differs a bit across omap platforms. The offsets are removed as well since it is U-Boot's coding style to use structures for mapping such kind of data (in the sense that it is similar to registers). It is correct to assume that romcode structure encoding is the same as U-Boot, given the description of these structures in the TRMs. The original address provided by the bootrom is passed to the U-Boot binary instead of a duplicate of the structure stored in global data. This allows to have only the relevant (boot device and mode) information stored in global data. It is also expected that the address where the bootrom stores that information is not overridden by the U-Boot SPL or U-Boot. The save_omap_boot_params is expected to handle all special cases where the data provided by the bootrom cannot be used as-is, so that spl_boot_device and spl_boot_mode only return the data from global data. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> --- arch/arm/cpu/armv7/omap-common/Makefile | 2 - arch/arm/cpu/armv7/omap-common/boot-common.c | 118 ++++++++++++++----------- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 2 - arch/arm/cpu/armv7/omap3/board.c | 56 ------------ arch/arm/cpu/armv7/omap3/lowlevel_init.S | 10 --- arch/arm/include/asm/arch-am33xx/omap.h | 11 +++ arch/arm/include/asm/arch-omap3/omap.h | 13 +++ arch/arm/include/asm/arch-omap3/sys_proto.h | 2 + arch/arm/include/asm/arch-omap4/omap.h | 11 +++ arch/arm/include/asm/arch-omap5/omap.h | 12 +++ arch/arm/include/asm/global_data.h | 10 +-- arch/arm/include/asm/omap_boot.h | 34 ------- arch/arm/include/asm/omap_common.h | 9 ++ arch/arm/include/asm/ti-common/sys_proto.h | 2 +- 14 files changed, 130 insertions(+), 162 deletions(-) delete mode 100644 arch/arm/include/asm/omap_boot.h