[U-Boot] [ANN] U-Boot v2015.10-rc4 released
Hey all,
I've pushed v2015.10-rc4 out to the repository and tarballs should exist soon.
We're coming up on the release date and I think things are in reasonable shape overall. Please speak up if there's some fixes I'm still overlooking, I thought I grabbed them all by now but I may have still missed something.
Dear Tom,
In message 20150928210901.GH22966@bill-the-cat you wrote:
I've pushed v2015.10-rc4 out to the repository and tarballs should exist soon.
Tarballs are both on the FTP server [1] and the ACD [2].
[1] ftp://ftp.denx.de/pub/u-boot/ [2] https://www.amazon.com/clouddrive/share/9JvNre5ZS9KVI3kRyTjEQNYO5x9R5ai-CRXF...
We're coming up on the release date and I think things are in reasonable shape overall. Please speak up if there's some fixes I'm still overlooking, I thought I grabbed them all by now but I may have still missed something.
Thanks a lot!
Best regards,
Wolfgang Denk
Hi Tom,
Hey all,
I've pushed v2015.10-rc4 out to the repository and tarballs should exist soon.
We're coming up on the release date and I think things are in reasonable shape overall. Please speak up if there's some fixes I'm still overlooking, I thought I grabbed them all by now but I may have still missed something.
I've found more issues with Exynos4 (Trats) regarding changes done in the following commit:
"fdt: add new fdt address parsing functions" SHA1: 02464e386bb5f0a022c121f95ae75cf583759d95
I'm strive to fix this issue ASAP.
On 28/09/15 05:09 PM, Tom Rini wrote:
Hey all,
I've pushed v2015.10-rc4 out to the repository and tarballs should exist soon.
We're coming up on the release date and I think things are in reasonable shape overall. Please speak up if there's some fixes I'm still overlooking, I thought I grabbed them all by now but I may have still missed something.
On ls1021atwr board (LS1021E, Version: 1.0, (0x87081110) with ls1021atwr_sdcard_defconfig reset hangs on my board :
=> ver
U-Boot 2015.10-rc4 (Sep 30 2015 - 12:29:15 -0400)
arm-linux-gnueabi-gcc (GCC) 4.8.1
GNU ld (GNU Binutils) 2.23.2
=> reset
resetting ...
Is anyone else seeing this ?
Regards Sinan Akman
On 09/30/2015 09:47 AM, Sinan Akman wrote:
On 28/09/15 05:09 PM, Tom Rini wrote:
Hey all,
I've pushed v2015.10-rc4 out to the repository and tarballs should exist soon.
We're coming up on the release date and I think things are in reasonable shape overall. Please speak up if there's some fixes I'm still overlooking, I thought I grabbed them all by now but I may have still missed something.
On ls1021atwr board (LS1021E, Version: 1.0, (0x87081110) with ls1021atwr_sdcard_defconfig reset hangs on my board :
=> ver
U-Boot 2015.10-rc4 (Sep 30 2015 - 12:29:15 -0400)
arm-linux-gnueabi-gcc (GCC) 4.8.1
GNU ld (GNU Binutils) 2.23.2
=> reset
resetting ...
Is anyone else seeing this ?
The board maintainer will take a look. Unfortunately she is on holiday vacation. Let me try to find someone else familiar with this board.
York
Hi York
The board maintainer will take a look. Unfortunately she is on holiday vacation. Let me try to find someone else familiar with this board.
No worries, I will also bisect and see what's going on. Just wanted to make sure I don't work on it if someone is already taking care. I'll take a look at in the coming days.
Regards Sinan Akman
On 30/09/15 01:22 PM, Sinan Akman wrote:
Hi York
The board maintainer will take a look. Unfortunately she is on holiday vacation. Let me try to find someone else familiar with this board.
No worries, I will also bisect and see what's going on. Just wanted to make sure I don't work on it if someone is already taking care. I'll take a look at in the coming days.
FYI,
git revert 623d96e89aca64c2762150087f4e872c55481f13
fixes the reset issue. I don't know yet why. I am cc'ing to Peng as well.
There are some other i2c warnings with this built, "The regulator (MC34VR500) does not exist" .. etc. but they are probably unrelated, I will take a look at them later.
Regards Sinan Akman
Hi Sinan,
On Wed, Sep 30, 2015 at 3:02 PM, Sinan Akman sinan@writeme.com wrote:
On 30/09/15 01:22 PM, Sinan Akman wrote:
Hi York
The board maintainer will take a look. Unfortunately she is on holiday vacation. Let me try to find someone else familiar with this board.
No worries, I will also bisect and see what's going on. Just wanted to make sure I don't work on it if someone is already taking care. I'll take a look at in the coming days.
FYI,
git revert 623d96e89aca64c2762150087f4e872c55481f13
fixes the reset issue. I don't know yet why. I am cc'ing to Peng as well.
Does this fix the reset issue?
--- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -55,7 +55,7 @@ void reset_cpu(ulong addr) { struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
- clrsetbits_le16(&wdog->wcr, 0, WCR_WDE); + setbits_le16(&wdog->wcr, WCR_WDE);
writew(0x5555, &wdog->wsr); writew(0xaaaa, &wdog->wsr); /* load minimum 1/2 second timeout */
Hi Fabio
Fabio Estevam wrote:
Hi Sinan, [...]
Does this fix the reset issue?
--- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -55,7 +55,7 @@ void reset_cpu(ulong addr) { struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
clrsetbits_le16(&wdog->wcr, 0, WCR_WDE);
setbits_le16(&wdog->wcr, WCR_WDE); writew(0x5555, &wdog->wsr); writew(0xaaaa, &wdog->wsr); /* load minimum 1/2 second timeout */
Nope, AFAICS it doesn't make any difference.
Regards Sinan Akman
On Wed, Sep 30, 2015 at 3:33 PM, Sinan Akman sinan@writeme.com wrote:
Nope, AFAICS it doesn't make any difference.
Ok, the issue is due to endianness: on LS1021 the watchdog is big-endian, so that's why we can't use clrsetbits_le16().
Please check: http://git.freescale.com/git/cgit.cgi/layerscape/ls1021a/linux.git/commit/?i...
What about this?
--- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -54,8 +54,11 @@ void hw_watchdog_init(void) void reset_cpu(ulong addr) { struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR; + int reg;
- clrsetbits_le16(&wdog->wcr, 0, WCR_WDE); + reg = readw(&wdog->wcr); + reg |= WCR_WDE; + writew(reg, &wdog->wcr);
writew(0x5555, &wdog->wsr); writew(0xaaaa, &wdog->wsr); /* load minimum 1/2 second timeout */
On Wed, Sep 30, 2015 at 3:56 PM, Fabio Estevam festevam@gmail.com wrote:
On Wed, Sep 30, 2015 at 3:33 PM, Sinan Akman sinan@writeme.com wrote:
Nope, AFAICS it doesn't make any difference.
Ok, the issue is due to endianness: on LS1021 the watchdog is big-endian, so that's why we can't use clrsetbits_le16().
Please check: http://git.freescale.com/git/cgit.cgi/layerscape/ls1021a/linux.git/commit/?i...
What about this?
--- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -54,8 +54,11 @@ void hw_watchdog_init(void) void reset_cpu(ulong addr) { struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
int reg;
ops, this should be u16 instead.
clrsetbits_le16(&wdog->wcr, 0, WCR_WDE);
reg = readw(&wdog->wcr);reg |= WCR_WDE;writew(reg, &wdog->wcr); writew(0x5555, &wdog->wsr); writew(0xaaaa, &wdog->wsr); /* load minimum 1/2 second timeout */
Fabio Estevam wrote:
On Wed, Sep 30, 2015 at 3:56 PM, Fabio Estevam festevam@gmail.com wrote:
On Wed, Sep 30, 2015 at 3:33 PM, Sinan Akman sinan@writeme.com wrote:
Nope, AFAICS it doesn't make any difference.
Ok, the issue is due to endianness: on LS1021 the watchdog is big-endian, so that's why we can't use clrsetbits_le16().
Please check: http://git.freescale.com/git/cgit.cgi/layerscape/ls1021a/linux.git/commit/?i...
What about this?
--- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -54,8 +54,11 @@ void hw_watchdog_init(void) void reset_cpu(ulong addr) { struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
int reg;ops, this should be u16 instead.
clrsetbits_le16(&wdog->wcr, 0, WCR_WDE);
reg = readw(&wdog->wcr);reg |= WCR_WDE;writew(reg, &wdog->wcr); writew(0x5555, &wdog->wsr); writew(0xaaaa, &wdog->wsr); /* load minimum 1/2 second timeout */
OK, this will probably work, as I tried writew earlier and it worked, I agree it seems an endianness issue, do we not want to address all common accesses in a way that takes endianness into account ?
I'll test the above as well (with u16 reg) to make sure.
Regards Sinan Akman
On Wed, Sep 30, 2015 at 4:09 PM, Sinan Akman sinan@writeme.com wrote:
OK, this will probably work, as I tried writew earlier and it worked, I agree it seems an endianness issue, do we not want to address all common accesses in a way that takes endianness into account ?
Yes, that would be nice. I don't have access to ls1021 hardware, so can't do it myself.
I'll test the above as well (with u16 reg) to make sure.
Ok, great. Please let us know how it goes.
Thanks
Hi Fabio
On 30/09/15 03:03 PM, Fabio Estevam wrote:
[...] Ok, the issue is due to endianness: on LS1021 the watchdog is big-endian, so that's why we can't use clrsetbits_le16().
Please check: http://git.freescale.com/git/cgit.cgi/layerscape/ls1021a/linux.git/commit/?i...
What about this?
--- a/drivers/watchdog/imx_watchdog.c +++ b/drivers/watchdog/imx_watchdog.c @@ -54,8 +54,11 @@ void hw_watchdog_init(void) void reset_cpu(ulong addr) { struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
int reg;ops, this should be u16 instead.
clrsetbits_le16(&wdog->wcr, 0, WCR_WDE);
reg = readw(&wdog->wcr);reg |= WCR_WDE;writew(reg, &wdog->wcr); writew(0x5555, &wdog->wsr); writew(0xaaaa, &wdog->wsr); /* load minimum 1/2 second timeout */
I took a further look at this. I believe this won't work as readw will now return the data in the wrong endianness. I think Wolfgang also already pointed out at this. We would need to use the macro with correct endianness for different platforms (ls1021atwr would need big endian) and control this based on the watchdog endian setting in dts.
However, there seems to be other problems here. The original fix was intending to preserve the current set bits in wcr and enable DTE. But in the case of ls1021atwr, the watcdog is not initialized and out of reset we have SRS bit is set. This would disable wdog_rst and prevent reset from working. Before the fix it was actually the accidental setting of SRS to zero made the reset working because a writew(WCR_WDE, &wdog->wcr) would clear that bit, setting WDE alone would not generate wdog_rst.
So I believe a proper fix would have the following steps : - move watchdog driver to DM so that we can make use of endian type - use macros with the endian type for accessing the registers - enable hw_watchdog for the board so that it gets initialized to a known value - reset SRS to enable generation of wdog_rst, this will reset immediately with 0x00 default WT value. - or program the timeout and enable WDE so the board resets after a longer timeout value if desired
Does this make sense to everyone ?
Regards Sinan Akman
On Thu, Oct 1, 2015 at 12:19 PM, Sinan Akman sinan@writeme.com wrote:
I took a further look at this. I believe this won't work as readw will now return the data in the wrong endianness. I think Wolfgang also already pointed out at this. We would need to use the macro with correct endianness for different platforms (ls1021atwr would need big endian) and control this based on the watchdog endian setting in dts.
The imx platforms do not use dts in U-boot yet.
However, there seems to be other problems here. The original fix was intending to preserve the current set bits in wcr and enable DTE. But in the case of ls1021atwr, the watcdog is not initialized and out of reset we have SRS bit is set. This would disable wdog_rst and prevent reset from working. Before the fix it was actually the accidental setting of SRS to zero made the reset working because a writew(WCR_WDE, &wdog->wcr) would clear that bit, setting WDE alone would not generate wdog_rst.
So I believe a proper fix would have the following steps :
- move watchdog driver to DM so that we can make use of endian type
- use macros with the endian type for accessing the registers
- enable hw_watchdog for the board so that it gets initialized to
a known value
- reset SRS to enable generation of wdog_rst, this will reset immediately
with 0x00 default WT value.
- or program the timeout and enable WDE so the board
resets after a longer timeout value if desired
Does this make sense to everyone ?
Looks good. 2015.10 release is only a few days away: do you think you could implement your proposal for the upcoming release?
Regards,
Fabio Estevam
On Thu, Oct 01, 2015 at 04:09:46PM -0300, Fabio Estevam wrote:
On Thu, Oct 1, 2015 at 12:19 PM, Sinan Akman sinan@writeme.com wrote:
I took a further look at this. I believe this won't work as readw will now return the data in the wrong endianness. I think Wolfgang also already pointed out at this. We would need to use the macro with correct endianness for different platforms (ls1021atwr would need big endian) and control this based on the watchdog endian setting in dts.
The imx platforms do not use dts in U-boot yet.
However, there seems to be other problems here. The original fix was intending to preserve the current set bits in wcr and enable DTE. But in the case of ls1021atwr, the watcdog is not initialized and out of reset we have SRS bit is set. This would disable wdog_rst and prevent reset from working. Before the fix it was actually the accidental setting of SRS to zero made the reset working because a writew(WCR_WDE, &wdog->wcr) would clear that bit, setting WDE alone would not generate wdog_rst.
So I believe a proper fix would have the following steps :
- move watchdog driver to DM so that we can make use of endian type
- use macros with the endian type for accessing the registers
- enable hw_watchdog for the board so that it gets initialized to
a known value
- reset SRS to enable generation of wdog_rst, this will reset immediately
with 0x00 default WT value.
- or program the timeout and enable WDE so the board
resets after a longer timeout value if desired
Does this make sense to everyone ?
Looks good. 2015.10 release is only a few days away: do you think you could implement your proposal for the upcoming release?
That seems rather large. Is there something we can revert today so that: a) All boards in v2015.07 continue to work in v2015.10 as well as before b) Any new boards are not introduced in a totally broken state?
On Thu, Oct 1, 2015 at 4:14 PM, Tom Rini trini@konsulko.com wrote:
On Thu, Oct 01, 2015 at 04:09:46PM -0300, Fabio Estevam wrote:
On Thu, Oct 1, 2015 at 12:19 PM, Sinan Akman sinan@writeme.com wrote:
I took a further look at this. I believe this won't work as readw will now return the data in the wrong endianness. I think Wolfgang also already pointed out at this. We would need to use the macro with correct endianness for different platforms (ls1021atwr would need big endian) and control this based on the watchdog endian setting in dts.
The imx platforms do not use dts in U-boot yet.
However, there seems to be other problems here. The original fix was intending to preserve the current set bits in wcr and enable DTE. But in the case of ls1021atwr, the watcdog is not initialized and out of reset we have SRS bit is set. This would disable wdog_rst and prevent reset from working. Before the fix it was actually the accidental setting of SRS to zero made the reset working because a writew(WCR_WDE, &wdog->wcr) would clear that bit, setting WDE alone would not generate wdog_rst.
So I believe a proper fix would have the following steps :
- move watchdog driver to DM so that we can make use of endian type
- use macros with the endian type for accessing the registers
- enable hw_watchdog for the board so that it gets initialized to
a known value
- reset SRS to enable generation of wdog_rst, this will reset immediately
with 0x00 default WT value.
- or program the timeout and enable WDE so the board
resets after a longer timeout value if desired
Does this make sense to everyone ?
Looks good. 2015.10 release is only a few days away: do you think you could implement your proposal for the upcoming release?
That seems rather large. Is there something we can revert today so that: a) All boards in v2015.07 continue to work in v2015.10 as well as before b) Any new boards are not introduced in a totally broken state?
Agreed; I prefer to revert the watchdog changes and break ls102x than introduce such big change.
On 01/10/15 03:17 PM, Otavio Salvador wrote:
On Thu, Oct 1, 2015 at 4:14 PM, Tom Rini trini@konsulko.com wrote:
On Thu, Oct 01, 2015 at 04:09:46PM -0300, Fabio Estevam wrote:
On Thu, Oct 1, 2015 at 12:19 PM, Sinan Akman sinan@writeme.com wrote:
I took a further look at this. I believe this won't work as readw will now return the data in the wrong endianness. I think Wolfgang also already pointed out at this. We would need to use the macro with correct endianness for different platforms (ls1021atwr would need big endian) and control this based on the watchdog endian setting in dts.
The imx platforms do not use dts in U-boot yet.
However, there seems to be other problems here. The original fix was intending to preserve the current set bits in wcr and enable DTE. But in the case of ls1021atwr, the watcdog is not initialized and out of reset we have SRS bit is set. This would disable wdog_rst and prevent reset from working. Before the fix it was actually the accidental setting of SRS to zero made the reset working because a writew(WCR_WDE, &wdog->wcr) would clear that bit, setting WDE alone would not generate wdog_rst.
So I believe a proper fix would have the following steps :
- move watchdog driver to DM so that we can make use of endian type
- use macros with the endian type for accessing the registers
- enable hw_watchdog for the board so that it gets initialized to
a known value
- reset SRS to enable generation of wdog_rst, this will reset immediately
with 0x00 default WT value.
- or program the timeout and enable WDE so the board
resets after a longer timeout value if desired
Does this make sense to everyone ?
Looks good. 2015.10 release is only a few days away: do you think you could implement your proposal for the upcoming release?
That seems rather large. Is there something we can revert today so that: a) All boards in v2015.07 continue to work in v2015.10 as well as before b) Any new boards are not introduced in a totally broken state?
Agreed; I prefer to revert the watchdog changes and break ls102x than introduce such big change.
Otavio, please note that the watchdog changes that are committed that we are referring to broke ls102x. So if you revert those as you suggest here you would have ls102x working again but it would break imx6 which the commit was for.
Perhaps what you meant is, let's leave ls1021atwr broken and not change anything for now. I think this is something Tom will probably have to decide. I would prefer we don't have anything known broken before the main release.
Regards Sinan Akman
On Thu, Oct 1, 2015 at 4:33 PM, Sinan Akman sinan@writeme.com wrote:
Otavio, please note that the watchdog changes that are committed that we are referring to broke ls102x. So if you revert those as you suggest here you would have ls102x working again but it would break imx6 which the commit was for.
Just to clarify: reverting 623d96e89aca does not break i.MX.
623d96e89aca has been introduced in v2015.10-rc4. It is safe to revert it.
On 01/10/15 03:38 PM, Fabio Estevam wrote:
On Thu, Oct 1, 2015 at 4:33 PM, Sinan Akman sinan@writeme.com wrote:
Otavio, please note that the watchdog changes that are committed that we are referring to broke ls102x. So if you revert those as you suggest here you would have ls102x working again but it would break imx6 which the commit was for.
Just to clarify: reverting 623d96e89aca does not break i.MX.
623d96e89aca has been introduced in v2015.10-rc4. It is safe to revert it.
OK
Regards Sinan Akman
On 01/10/15 03:14 PM, Tom Rini wrote:
On Thu, Oct 01, 2015 at 04:09:46PM -0300, Fabio Estevam wrote:
On Thu, Oct 1, 2015 at 12:19 PM, Sinan Akman sinan@writeme.com wrote:
I took a further look at this. I believe this won't work as readw will now return the data in the wrong endianness. I think Wolfgang also already pointed out at this. We would need to use the macro with correct endianness for different platforms (ls1021atwr would need big endian) and control this based on the watchdog endian setting in dts.
The imx platforms do not use dts in U-boot yet.
However, there seems to be other problems here. The original fix was intending to preserve the current set bits in wcr and enable DTE. But in the case of ls1021atwr, the watcdog is not initialized and out of reset we have SRS bit is set. This would disable wdog_rst and prevent reset from working. Before the fix it was actually the accidental setting of SRS to zero made the reset working because a writew(WCR_WDE, &wdog->wcr) would clear that bit, setting WDE alone would not generate wdog_rst.
So I believe a proper fix would have the following steps :
- move watchdog driver to DM so that we can make use of endian type
- use macros with the endian type for accessing the registers
- enable hw_watchdog for the board so that it gets initialized to
a known value
- reset SRS to enable generation of wdog_rst, this will reset immediately
with 0x00 default WT value.
- or program the timeout and enable WDE so the board
resets after a longer timeout value if desired
Does this make sense to everyone ?
Looks good. 2015.10 release is only a few days away: do you think you could implement your proposal for the upcoming release?
That seems rather large. Is there something we can revert today so that: a) All boards in v2015.07 continue to work in v2015.10 as well as before b) Any new boards are not introduced in a totally broken state?
I agree, this is something needs to be done in steps and not in rush. For coming out of rc4 and making sure ls1021atwr reset works, all we need is to make sure that SRS bit is set and that this bit is written properly with big endian. We could add that specifically for ls1021atw. Still there is something not nice about the current implementation that is kinda assumes hw_watchdog is enabled and _init is called but it doesn't check for this. I will come up with something to have ls1021atwr working and see if it feels clean enough.
Regards Sinan Akman
On Thu, Oct 1, 2015 at 4:28 PM, Sinan Akman sinan@writeme.com wrote:
I agree, this is something needs to be done in steps and not in rush. For coming out of rc4 and making sure ls1021atwr reset works, all we need is to make sure that SRS bit is set and that this bit is written properly with big endian. We could add that specifically for ls1021atw.
Safest approach would be to revert 623d96e89, right?
Dear Fabio,
In message CAOMZO5ATtUjk_TVS94N6evTKndozVRH9nXyE0UHPJ3sCQ906Zg@mail.gmail.com you wrote:
Ok, the issue is due to endianness: on LS1021 the watchdog is big-endian, so that's why we can't use clrsetbits_le16().
...
int reg;
clrsetbits_le16(&wdog->wcr, 0, WCR_WDE);
reg = readw(&wdog->wcr);reg |= WCR_WDE;writew(reg, &wdog->wcr);
But this is broken. We have the clrsetbits() [*] macros exactly to avoid such code.
[*] resp. setbits() - using clrsetbits*() with 0 as clear mask is a stupid thing to do anyway.
Best regards,
Wolfgang Denk
participants (7)
-
Fabio Estevam -
Lukasz Majewski -
Otavio Salvador -
Sinan Akman -
Tom Rini -
Wolfgang Denk -
York Sun