[U-Boot] [ANN] U-Boot v2018.03-rc3 released
Hey all,
So, we're a day late. That's because I wanted the MMC PR to come in for some important fixes, and it was too late in my day to then push a release. I think we probably have a few more fixes that need to come in, but hopefully no more new regressions to be found. That said, if you have your environment, well, anywhere, a little bit of hardware testing wouldn't hurt. I think we're still on track for -rc4 on March 5th and the release on March 12th. But if we aren't, the release will get delayed.
And on a related note, there has been more feedback on getting going back to a longer release cycle. I'm thinking about it and maybe trying a longer cycle for a few releases to get a feel for everything again.
On a different note, I'm thinking that boards and SoC families, etc, that have been orphaned for more than a year should probably get dropped. I've contacted a few people off-list (which is why we've had a few pickups of late) for things, but if you know someone that would be interested in something, please speak up.
Thanks all!
On Tue, Feb 20, 2018 at 10:03 PM, Tom Rini trini@konsulko.com wrote:
Hey all,
So, we're a day late. That's because I wanted the MMC PR to come in for some important fixes, and it was too late in my day to then push a release. I think we probably have a few more fixes that need to come in, but hopefully no more new regressions to be found. That said, if you have your environment, well, anywhere, a little bit of hardware testing wouldn't hurt. I think we're still on track for -rc4 on March 5th and the release on March 12th. But if we aren't, the release will get delayed.
Something's broken my board (AM335x, not quite a BBB):
MMC: mmc@481d8000 - probe failed: -1
Looks to be this commit:
2d7482cf793fe4d8a98906002708d6e1fa2c5ba3
Still looking, but I'd guess I'm now missing something from my DTB which I didn't need previously.
On Wed, Feb 21, 2018 at 9:20 AM, Alex Kiernan alex.kiernan@gmail.com wrote:
On Tue, Feb 20, 2018 at 10:03 PM, Tom Rini trini@konsulko.com wrote:
Hey all,
So, we're a day late. That's because I wanted the MMC PR to come in for some important fixes, and it was too late in my day to then push a release. I think we probably have a few more fixes that need to come in, but hopefully no more new regressions to be found. That said, if you have your environment, well, anywhere, a little bit of hardware testing wouldn't hurt. I think we're still on track for -rc4 on March 5th and the release on March 12th. But if we aren't, the release will get delayed.
Something's broken my board (AM335x, not quite a BBB):
MMC: mmc@481d8000 - probe failed: -1
Looks to be this commit:
2d7482cf793fe4d8a98906002708d6e1fa2c5ba3
Still looking, but I'd guess I'm now missing something from my DTB which I didn't need previously.
mmc_of_parse says:
/* f_max is obtained from the optional "max-frequency" property */ dev_read_u32(dev, "max-frequency", &cfg->f_max);
I don't have a max-frequency (pretty much all my config comes direct from am33xx.dtsi), so if I add a max-frequency to my tree I get a working board, but the comment above suggests I shouldn't need to, so do we need something like this added (or a refactor of mmc_of_parse so it takes a default?)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index 02970f2..b87ff01 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -1825,6 +1825,8 @@ static int omap_hsmmc_ofdata_to_platdata(struct udevice *dev) if (ret < 0) return ret;
+ if (cfg->f_max == 0) + cfg->f_max = 52000000; cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS; cfg->f_min = 400000; cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
I'm also seeing MMC_MODE_1BIT (which I didn't previously have set) alongside MMC_MODE_4BIT and MMC_MODE_8BIT (which I previously did), but I'm guessing that doesn't matter?
On 21/02/2018 11:10, Alex Kiernan wrote:
On Wed, Feb 21, 2018 at 9:20 AM, Alex Kiernan alex.kiernan@gmail.com wrote:
On Tue, Feb 20, 2018 at 10:03 PM, Tom Rini trini@konsulko.com wrote:
Hey all,
So, we're a day late. That's because I wanted the MMC PR to come in for some important fixes, and it was too late in my day to then push a release. I think we probably have a few more fixes that need to come in, but hopefully no more new regressions to be found. That said, if you have your environment, well, anywhere, a little bit of hardware testing wouldn't hurt. I think we're still on track for -rc4 on March 5th and the release on March 12th. But if we aren't, the release will get delayed.
Something's broken my board (AM335x, not quite a BBB):
MMC: mmc@481d8000 - probe failed: -1
Looks to be this commit:
2d7482cf793fe4d8a98906002708d6e1fa2c5ba3
Still looking, but I'd guess I'm now missing something from my DTB which I didn't need previously.
mmc_of_parse says:
/* f_max is obtained from the optional "max-frequency" property */ dev_read_u32(dev, "max-frequency", &cfg->f_max);I don't have a max-frequency (pretty much all my config comes direct from am33xx.dtsi), so if I add a max-frequency to my tree I get a working board, but the comment above suggests I shouldn't need to, so do we need something like this added (or a refactor of mmc_of_parse so it takes a default?)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index 02970f2..b87ff01 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -1825,6 +1825,8 @@ static int omap_hsmmc_ofdata_to_platdata(struct udevice *dev) if (ret < 0) return ret;
if (cfg->f_max == 0)cfg->f_max = 52000000;
Thanks for catching this. I'll send a series soon related to am335x_evm and mmc. I'll include your fix.
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS; cfg->f_min = 400000; cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;I'm also seeing MMC_MODE_1BIT (which I didn't previously have set) alongside MMC_MODE_4BIT and MMC_MODE_8BIT (which I previously did), but I'm guessing that doesn't matter?
1Bit is always supported. So it doesn't matter. JJ
participants (3)
-
Alex Kiernan -
Jean-Jacques Hiblot -
Tom Rini