Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
вт, 23 авг. 2022 г., 06:54 Nishanth Menon : > On 08:56-20220819, Robert Nelson wrote: > > On Fri, Aug 19, 2022 at 4:30 AM Nishanth Menon wrote: > > > > > > On 11:28-20220818, Matwey V. Kornilov wrote: > [..] > > > > > > Tom, Robert, folks: what do you folks think? > > > > > > I'm okay with the delay. if we only had 'one' production run it would > > be a different story.. But with 10 years of manufacturing, parts will > > EOL and vary. Let's go with the safe slower route.. > > Matwey, would you post your fix formally? > Ok. I'll do. -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 > DDB5 849D 1736 249D >
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On 08:56-20220819, Robert Nelson wrote: > On Fri, Aug 19, 2022 at 4:30 AM Nishanth Menon wrote: > > > > On 11:28-20220818, Matwey V. Kornilov wrote: [..] > > > > Tom, Robert, folks: what do you folks think? > > > I'm okay with the delay. if we only had 'one' production run it would > be a different story.. But with 10 years of manufacturing, parts will > EOL and vary. Let's go with the safe slower route.. Matwey, would you post your fix formally? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Fri, Aug 19, 2022 at 4:30 AM Nishanth Menon wrote:
>
> On 11:28-20220818, Matwey V. Kornilov wrote:
> > I've played a little and now I believe that the issue is that EEPROM read
> > addr
> > pointer is somehow corrupted due to 1-byte address write. The EEPROM is
> > definitely have two-byte read address accoring the datasheet.
> > I've failed to unravel exact rule what is happening when only one address
> > byte
> > is set, but was able to read random places of EEPROM.
> >
> >
> > However, the following diff makes the board bootable.
> >
> >
> > diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
> > index ed34991377..26edddccc6 100644
> > --- a/board/ti/common/board_detect.c
> > +++ b/board/ti/common/board_detect.c
> > @@ -86,7 +86,6 @@ __weak void gpi2c_init(void)
> > static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr,
> > u32 header, u32 size, uint8_t
> > *ep)
> > {
> > - u32 hdr_read = 0xdeadbeef;
> > int rc;
> >
> > #if CONFIG_IS_ENABLED(DM_I2C)
> > @@ -113,10 +112,10 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > bus_addr, int dev_addr,
> > * We must allow for fall through to check the data if 2 byte
> > * addressing works
> > */
> > - (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> > + rc = dm_i2c_read(dev, 0, ep, size);
> >
> > /* Corrupted data??? */
> > - if (hdr_read != header) {
> > + if (rc || (*((u32*)ep) != header)) {
> > /*
> > * read the eeprom header using i2c again, but use only a
> > * 2 byte address (some newer boards need this..)
> > @@ -125,16 +124,13 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > bus_addr, int dev_addr,
> > if (rc)
> > return rc;
> >
> > - rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> > + rc = dm_i2c_read(dev, 0, ep, size);
> > if (rc)
> > return rc;
> > }
> > - if (hdr_read != header)
> > + if (*((u32*)ep) != header)
> > return -1;
> >
> > - rc = dm_i2c_read(dev, 0, ep, size);
> > - if (rc)
> > - return rc;
> > #else
> > u32 byte;
>
> This does work. I tested a few variations of boards to check this
> concept out.. but anyways.. on beaglebone black (element 14 boards):
>
> NOTE: This will improve detection times for 1 byte eeprom based boot,
> since there is no retry..
>
> However for boards with 2 byte addressing eeproms:
>
> master branch: https://pasteboard.co/n3P8yhSq6pem.png
> Time from first attempt to read eeprom to actual trigger of final eeprom
> read attempt: ~4ms
>
> With this patch: https://pasteboard.co/IVQzHwMuhc4p.png
> Time from first attempt to read eeprom to actual trigger of final eeprom
> read attempt: ~18ms
>
> IMHO, 14ms penalty is'nt a bad deal for dealing with variations of
> eeproms we are seeing in the wild.
>
> You can find the data (analog+digital capture) here:
> https://github.com/nmenon/data-captures/tree/main/i2c-eeprom-1byte-captures
> Tool used to capture (and view): https://www.saleae.com/downloads/
>
> Tom, Robert, folks: what do you folks think?
I'm okay with the delay. if we only had 'one' production run it would
be a different story.. But with 10 years of manufacturing, parts will
EOL and vary. Let's go with the safe slower route..
Regards,
--
Robert Nelson
https://rcn-ee.com/
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On 11:28-20220818, Matwey V. Kornilov wrote:
> I've played a little and now I believe that the issue is that EEPROM read addr
> pointer is somehow corrupted due to 1-byte address write. The EEPROM is
> definitely have two-byte read address accoring the datasheet.
> I've failed to unravel exact rule what is happening when only one address byte
> is set, but was able to read random places of EEPROM.
>
>
> However, the following diff makes the board bootable.
>
>
> diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
> index ed34991377..26edddccc6 100644
> --- a/board/ti/common/board_detect.c
> +++ b/board/ti/common/board_detect.c
> @@ -86,7 +86,6 @@ __weak void gpi2c_init(void)
> static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr,
> u32 header, u32 size, uint8_t *ep)
> {
> - u32 hdr_read = 0xdeadbeef;
> int rc;
>
> #if CONFIG_IS_ENABLED(DM_I2C)
> @@ -113,10 +112,10 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> bus_addr, int dev_addr,
> * We must allow for fall through to check the data if 2 byte
> * addressing works
> */
> - (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> + rc = dm_i2c_read(dev, 0, ep, size);
>
> /* Corrupted data??? */
> - if (hdr_read != header) {
> + if (rc || (*((u32*)ep) != header)) {
> /*
> * read the eeprom header using i2c again, but use only a
> * 2 byte address (some newer boards need this..)
> @@ -125,16 +124,13 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> bus_addr, int dev_addr,
> if (rc)
> return rc;
>
> - rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> + rc = dm_i2c_read(dev, 0, ep, size);
> if (rc)
> return rc;
> }
> - if (hdr_read != header)
> + if (*((u32*)ep) != header)
> return -1;
>
> - rc = dm_i2c_read(dev, 0, ep, size);
> - if (rc)
> - return rc;
> #else
> u32 byte;
This does work. I tested a few variations of boards to check this
concept out.. but anyways.. on beaglebone black (element 14 boards):
NOTE: This will improve detection times for 1 byte eeprom based boot,
since there is no retry..
However for boards with 2 byte addressing eeproms:
master branch: https://pasteboard.co/n3P8yhSq6pem.png
Time from first attempt to read eeprom to actual trigger of final eeprom
read attempt: ~4ms
With this patch: https://pasteboard.co/IVQzHwMuhc4p.png
Time from first attempt to read eeprom to actual trigger of final eeprom
read attempt: ~18ms
IMHO, 14ms penalty is'nt a bad deal for dealing with variations of
eeproms we are seeing in the wild.
You can find the data (analog+digital capture) here:
https://github.com/nmenon/data-captures/tree/main/i2c-eeprom-1byte-captures
Tool used to capture (and view): https://www.saleae.com/downloads/
Tom, Robert, folks: what do you folks think?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
I've played a little and now I believe that the issue is that EEPROM read addr
pointer is somehow corrupted due to 1-byte address write. The EEPROM is
definitely have two-byte read address accoring the datasheet.
I've failed to unravel exact rule what is happening when only one address byte
is set, but was able to read random places of EEPROM.
However, the following diff makes the board bootable.
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index ed34991377..26edddccc6 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -86,7 +86,6 @@ __weak void gpi2c_init(void)
static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr,
u32 header, u32 size, uint8_t *ep)
{
- u32 hdr_read = 0xdeadbeef;
int rc;
#if CONFIG_IS_ENABLED(DM_I2C)
@@ -113,10 +112,10 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
* We must allow for fall through to check the data if 2 byte
* addressing works
*/
- (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
+ rc = dm_i2c_read(dev, 0, ep, size);
/* Corrupted data??? */
- if (hdr_read != header) {
+ if (rc || (*((u32*)ep) != header)) {
/*
* read the eeprom header using i2c again, but use only a
* 2 byte address (some newer boards need this..)
@@ -125,16 +124,13 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
if (rc)
return rc;
- rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
+ rc = dm_i2c_read(dev, 0, ep, size);
if (rc)
return rc;
}
- if (hdr_read != header)
+ if (*((u32*)ep) != header)
return -1;
- rc = dm_i2c_read(dev, 0, ep, size);
- if (rc)
- return rc;
#else
u32 byte;
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
I cannot understand what is going on. As far as I understand, read
consists of i2c write of address and subsequent i2c read of data.
During the i2c write process, EEPROM handles ACK/NOACK and - since
there is no error code - the EEPROM handles i2c write correctly. And
then it looks like no EEPROM device during the i2c read stage.
вт, 16 авг. 2022 г. в 04:27, Nishanth Menon :
>
> On 23:32-20220815, Matwey V. Kornilov wrote:
> > Only the first one dm_i2c_read is successful, whenever the size value.
>
> I wonder if we need to add complete ep read... this is what I see on my
> element 14 board:
>
> ti_i2c_eeprom_get: 98: rc=0 header=0xee3355aa
> ti_i2c_eeprom_get: 102: rc=0
> ti_i2c_eeprom_get: 110: rc=0
> ti_i2c_eeprom_get: 121: header=0x rc=0
> ti_i2c_eeprom_get: 130: rc=0
> ti_i2c_eeprom_get: 135: rc=0
> ti_i2c_eeprom_get: 139: header=0xee3355aa
> ti_i2c_eeprom_get: 144: rc=0
> ep[0]=0xaa
> ep[1]=0x55
> ep[2]=0x33
> ep[3]=0xee
> ep[4]=0x41
> ep[5]=0x33
> ep[6]=0x33
> ep[7]=0x35
> ep[8]=0x42
> ep[9]=0x4e
> ep[10]=0x4c
> ep[11]=0x54
> ep[12]=0x30
> ep[13]=0x30
> ep[14]=0x43
> ep[15]=0x30
> ep[16]=0x34
> ep[17]=0x31
> ep[18]=0x34
> ep[19]=0x42
> ep[20]=0x42
> ep[21]=0x42
> ep[22]=0x4b
> ep[23]=0x30
> ep[24]=0x31
> ep[25]=0x36
> ep[26]=0x37
> ep[27]=0xff
> ep[28]=0xff
> ep[29]=0xff
> ep[30]=0xff
> ep[31]=0xff
> ep[32]=0xff
> ep[33]=0xff
> ep[34]=0xff
> ep[35]=0xff
> ep[36]=0xff
> ep[37]=0xff
> ep[38]=0xff
> ep[39]=0xff
> ep[40]=0xff
> ep[41]=0xff
> ep[42]=0xff
> ep[43]=0xff
> ep[44]=0xff
> ep[45]=0xff
> ep[46]=0xff
> ep[47]=0xff
> ep[48]=0xff
> ep[49]=0xff
> ep[50]=0xff
> ep[51]=0xff
> ep[52]=0xff
> ep[53]=0xff
> ep[54]=0xff
> ep[55]=0xff
> ep[56]=0xff
> ep[57]=0xff
> ep[58]=0xff
> ep[59]=0xff
> ep[60]=0xff
> ep[61]=0xff
> ep[62]=0xff
> ep[63]=0xff
> ep[64]=0xff
> ep[65]=0xff
> ep[66]=0xff
> ep[67]=0xff
> ep[68]=0xff
> ep[69]=0xff
> ep[70]=0xff
> ep[71]=0xff
> ep[72]=0xff
> ep[73]=0xff
> ep[74]=0xff
> ep[75]=0xff
> ep[76]=0xff
> ep[77]=0xff
> ti_i2c_eeprom_get: 195: Out OK
>
> U-Boot SPL 2022.10-rc2-00030-g29d075bc05ca-dirty (Aug 15 2022 - 14:50:17
> -0500)
> Trying to boot from MMC1
>
>
> U-Boot 2022.10-rc2-00030-g29d075bc05ca-dirty (Aug 15 2022 - 14:50:17 -0500)
>
> CPU : AM335X-GP rev 2.1
> Model: TI AM335x BeagleBone Black
> DRAM: 512 MiB
> Core: 160 devices, 18 uclasses, devicetree: separate
> WDT: Started wdt@44e35000 with servicing (60s timeout)
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> not set. Validating first E-fuse MAC
> Net: eth2: ethernet@4a10, eth3: usb_ether
> Hit any key to stop autoboot: 0
> =>
>
> >
> > пн, 15 авг. 2022 г. в 23:21, Matwey V. Kornilov :
> > >
> > > I have one idea. I'll try dm_i2c_read() with different `size' argument
> > > values tomorrow.
> > >
> > > пн, 15 авг. 2022 г. в 23:13, Matwey V. Kornilov
> > > :
> > > >
> > > > пн, 15 авг. 2022 г. в 22:56, Nishanth Menon :
> > > > >
> > > > > On 21:12-20220815, Matwey V. Kornilov wrote:
> > > > > []
> > > > >
> > > > > Trying offline for now (I am also on libera.chat #linux-ti and
> > > > > #u-boot)..
> > > > >
> > > > > >
> > > > > >
> > > > > > ti_i2c_eeprom_get: 98: rc=0 header=0xee3355aa
> > > > > > ti_i2c_eeprom_get: 102: rc=0
> > > > > > ti_i2c_eeprom_get: 110: rc=0
> > > > > > ti_i2c_eeprom_get: 121: header=0xee3355aa
> > > > > > ti_i2c_eeprom_get: 139: header=0xee3355aa
> > > > > > ti_i2c_eeprom_get: 144: rc=0
> > > > > > ep[0]=0xff
> > > > >
> > > > > gaah... data seems stuck... with one more potential fixup... Dont know
> > > > > how this might behave..
> > > >
> > > > ti_i2c_eeprom_get: 121: header=0xee3355aa rc=0
> > > >
> > > > >
> > > > > main change is this:
> > > > > @@ -113,33 +117,42 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > > > > bus_addr, int dev_addr,
> > > > > * We must allow for fall through to check the data if 2 byte
> > > > > * addressing works
> > > > > */
> > > > > - (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> > > > > + rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> > > > > + printf("%s: %d: header=0x%08x rc=%d\n", __func__, __LINE__,
> > > > > hdr_read, rc);
> > > > >
> > > > > /* Corrupted data??? */
> > > > > - if (hdr_read != header) {
> > > > > + if (rc || hdr_read != header) {
> > > > >
> > > > > 8<---
> > > > > diff --git a/board/ti/common/board_detect.c
> > > > > b/board/ti/common/board_detect.c
> > > > > index ed34991377ee..f4e5da34b70a 100644
> > > > > --- a/board/ti/common/board_detect.c
> > > > > +++ b/board/ti/common/board_detect.c
> > > > > @@ -90,13 +90,16 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > > > > bus_addr, int dev_addr,
> > > > > int rc;
> > > > >
> > > > > #if CONFIG_IS_ENABLED(DM_I2C)
> > > > > + int i;
> > > > > struct udevice *dev;
> > > > > struct udevice *bus;
> > > > >
> > > > > rc = uclass_get_device_by_seq(U
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
пн, 15 авг. 2022 г. в 20:53, Nishanth Menon :
>
> On 20:30-20220815, Matwey V. Kornilov wrote:
> > Hi Nishanth,
> >
> > I just reverted 0dba4586 and have the following diff in the config:
> >
> > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> > index b500ed0fdd..b403901879 100644
> > --- a/configs/am335x_evm_defconfig
> > +++ b/configs/am335x_evm_defconfig
> > @@ -9,6 +9,9 @@ CONFIG_AM335X_USB0=y
> > CONFIG_AM335X_USB0_PERIPHERAL=y
> > CONFIG_AM335X_USB1=y
> > CONFIG_SPL=y
> > +CONFIG_DEBUG_UART_BASE=0x44e09000
> > +CONFIG_DEBUG_UART_CLOCK=4800
> > +CONFIG_DEBUG_UART=y
> > CONFIG_DISTRO_DEFAULTS=y
> > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4030ff00
> > @@ -102,6 +105,9 @@ CONFIG_DRIVER_TI_CPSW=y
> > CONFIG_DM_PMIC=y
> > # CONFIG_SPL_DM_PMIC is not set
> > CONFIG_PMIC_TPS65217=y
> > +CONFIG_DEBUG_UART_OMAP=y
> > +CONFIG_DEBUG_UART_SHIFT=2
> > +CONFIG_DEBUG_UART_ANNOUNCE=y
> > CONFIG_SPI=y
> > CONFIG_DM_SPI=y
> > CONFIG_OMAP3_SPI=y
> >
> >
> > I've applied your patch and see the following output now:
>
> Thanks.
>
> >
> >
> > ti_i2c_eeprom_get: 97: rc=0 header=0xee3355aa
> > ti_i2c_eeprom_get: 101: rc=0
> > ti_i2c_eeprom_get: 109: rc=0
> > ti_i2c_eeprom_get: 120: header=0xee3355aa
>
> 1 byte read operation passed here. so it never enters the 2 byte read op
> check. Is'nt this supposed to be a 2 byte addressing eeprom device?
>
> I wonder if changing that code to:
> (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> if (hdr_read != header) {
> to:
>
> rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> if (rc || (hdr_read != header) {
>
> might help?
>
> > ti_i2c_eeprom_get: 138: header=0xee3355aa
>
> > ti_i2c_eeprom_get: 143: rc=0
> > ti_i2c_eeprom_get: 191: Out OK
>
> So the header for sure matched, but not the data, I presume. Can we
> cross check with the updated debug printf("ep[%d]=0x%02x\n",i, ep[i]);
> that I added below?
>
> > Bad EEPROM or unknown board, cannot configure pinmux.
> >
>
> 8<---
> diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
> index ed34991377ee..34dfc1acb3a0 100644
> --- a/board/ti/common/board_detect.c
> +++ b/board/ti/common/board_detect.c
> @@ -90,13 +90,16 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
> int dev_addr,
> int rc;
>
> #if CONFIG_IS_ENABLED(DM_I2C)
> + int i;
> struct udevice *dev;
> struct udevice *bus;
>
> rc = uclass_get_device_by_seq(UCLASS_I2C, bus_addr, &bus);
> + printf("%s: %d: rc=%d header=0x%08x\n", __func__, __LINE__, rc,
> header);
> if (rc)
> return rc;
> rc = dm_i2c_probe(bus, dev_addr, 0, &dev);
> + printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
> if (rc)
> return rc;
>
> @@ -104,6 +107,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
> int dev_addr,
> * Read the header first then only read the other contents.
> */
> rc = i2c_set_chip_offset_len(dev, 1);
> + printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
> if (rc)
> return rc;
>
> @@ -114,6 +118,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
> int dev_addr,
> * addressing works
> */
> (void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> + printf("%s: %d: header=0x%08x\n", __func__, __LINE__, hdr_read);
>
> /* Corrupted data??? */
> if (hdr_read != header) {
> @@ -122,24 +127,32 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> bus_addr, int dev_addr,
> * 2 byte address (some newer boards need this..)
> */
> rc = i2c_set_chip_offset_len(dev, 2);
> + printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
> if (rc)
> return rc;
>
> rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
> + printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
> if (rc)
> return rc;
> }
> + printf("%s: %d: header=0x%08x\n", __func__, __LINE__, hdr_read);
> if (hdr_read != header)
> return -1;
>
> rc = dm_i2c_read(dev, 0, ep, size);
> + printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
> if (rc)
> return rc;
> +
> + for (i = 0; i< size; i++)
> + printf("ep[%d]=0x%02x\n",i, ep[i]);
> #else
> u32 byte;
>
> gpi2c_init();
> rc = ti_i2c_eeprom_init(bus_addr, dev_addr);
> + printf("%s: %d: rc=%d header=0x%08x\n", __func__, __LINE__, rc,
> header);
> if (rc)
> return rc;
>
> @@ -157,6 +170,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
> int dev_addr,
> (void)i2c_read(dev_addr, 0x0, byte, (uint8_t *)&hdr_read, 4);
>
> /* Corrupted data??? */
> + printf("%s: %d: header=0x%08x\n", __func__, __LINE__, hdr_read);
>
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On 20:30-20220815, Matwey V. Kornilov wrote:
> Hi Nishanth,
>
> I just reverted 0dba4586 and have the following diff in the config:
>
> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> index b500ed0fdd..b403901879 100644
> --- a/configs/am335x_evm_defconfig
> +++ b/configs/am335x_evm_defconfig
> @@ -9,6 +9,9 @@ CONFIG_AM335X_USB0=y
> CONFIG_AM335X_USB0_PERIPHERAL=y
> CONFIG_AM335X_USB1=y
> CONFIG_SPL=y
> +CONFIG_DEBUG_UART_BASE=0x44e09000
> +CONFIG_DEBUG_UART_CLOCK=4800
> +CONFIG_DEBUG_UART=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4030ff00
> @@ -102,6 +105,9 @@ CONFIG_DRIVER_TI_CPSW=y
> CONFIG_DM_PMIC=y
> # CONFIG_SPL_DM_PMIC is not set
> CONFIG_PMIC_TPS65217=y
> +CONFIG_DEBUG_UART_OMAP=y
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_DEBUG_UART_ANNOUNCE=y
> CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_OMAP3_SPI=y
>
>
> I've applied your patch and see the following output now:
Thanks.
>
>
> ti_i2c_eeprom_get: 97: rc=0 header=0xee3355aa
> ti_i2c_eeprom_get: 101: rc=0
> ti_i2c_eeprom_get: 109: rc=0
> ti_i2c_eeprom_get: 120: header=0xee3355aa
1 byte read operation passed here. so it never enters the 2 byte read op
check. Is'nt this supposed to be a 2 byte addressing eeprom device?
I wonder if changing that code to:
(void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
if (hdr_read != header) {
to:
rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
if (rc || (hdr_read != header) {
might help?
> ti_i2c_eeprom_get: 138: header=0xee3355aa
> ti_i2c_eeprom_get: 143: rc=0
> ti_i2c_eeprom_get: 191: Out OK
So the header for sure matched, but not the data, I presume. Can we
cross check with the updated debug printf("ep[%d]=0x%02x\n",i, ep[i]);
that I added below?
> Bad EEPROM or unknown board, cannot configure pinmux.
>
8<---
diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index ed34991377ee..34dfc1acb3a0 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -90,13 +90,16 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
int rc;
#if CONFIG_IS_ENABLED(DM_I2C)
+ int i;
struct udevice *dev;
struct udevice *bus;
rc = uclass_get_device_by_seq(UCLASS_I2C, bus_addr, &bus);
+ printf("%s: %d: rc=%d header=0x%08x\n", __func__, __LINE__, rc, header);
if (rc)
return rc;
rc = dm_i2c_probe(bus, dev_addr, 0, &dev);
+ printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
if (rc)
return rc;
@@ -104,6 +107,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
* Read the header first then only read the other contents.
*/
rc = i2c_set_chip_offset_len(dev, 1);
+ printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
if (rc)
return rc;
@@ -114,6 +118,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
* addressing works
*/
(void)dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
+ printf("%s: %d: header=0x%08x\n", __func__, __LINE__, hdr_read);
/* Corrupted data??? */
if (hdr_read != header) {
@@ -122,24 +127,32 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
* 2 byte address (some newer boards need this..)
*/
rc = i2c_set_chip_offset_len(dev, 2);
+ printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
if (rc)
return rc;
rc = dm_i2c_read(dev, 0, (uint8_t *)&hdr_read, 4);
+ printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
if (rc)
return rc;
}
+ printf("%s: %d: header=0x%08x\n", __func__, __LINE__, hdr_read);
if (hdr_read != header)
return -1;
rc = dm_i2c_read(dev, 0, ep, size);
+ printf("%s: %d: rc=%d\n", __func__, __LINE__, rc);
if (rc)
return rc;
+
+ for (i = 0; i< size; i++)
+ printf("ep[%d]=0x%02x\n",i, ep[i]);
#else
u32 byte;
gpi2c_init();
rc = ti_i2c_eeprom_init(bus_addr, dev_addr);
+ printf("%s: %d: rc=%d header=0x%08x\n", __func__, __LINE__, rc, header);
if (rc)
return rc;
@@ -157,6 +170,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
(void)i2c_read(dev_addr, 0x0, byte, (uint8_t *)&hdr_read, 4);
/* Corrupted data??? */
+ printf("%s: %d: header=0x%08x\n", __func__, __LINE__, hdr_read);
if (hdr_read != header) {
/*
* read the eeprom header using i2c again, but use only a
@@ -165,16 +179,20 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr,
int dev_addr,
byte = 2;
rc = i2c_read(dev_addr, 0x0, byte, (uint8_t *)&hdr_read,
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
Hi Nishanth, I just reverted 0dba4586 and have the following diff in the config: diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index b500ed0fdd..b403901879 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -9,6 +9,9 @@ CONFIG_AM335X_USB0=y CONFIG_AM335X_USB0_PERIPHERAL=y CONFIG_AM335X_USB1=y CONFIG_SPL=y +CONFIG_DEBUG_UART_BASE=0x44e09000 +CONFIG_DEBUG_UART_CLOCK=4800 +CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x4030ff00 @@ -102,6 +105,9 @@ CONFIG_DRIVER_TI_CPSW=y CONFIG_DM_PMIC=y # CONFIG_SPL_DM_PMIC is not set CONFIG_PMIC_TPS65217=y +CONFIG_DEBUG_UART_OMAP=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_OMAP3_SPI=y I've applied your patch and see the following output now: ti_i2c_eeprom_get: 97: rc=0 header=0xee3355aa ti_i2c_eeprom_get: 101: rc=0 ti_i2c_eeprom_get: 109: rc=0 ti_i2c_eeprom_get: 120: header=0xee3355aa ti_i2c_eeprom_get: 138: header=0xee3355aa ti_i2c_eeprom_get: 143: rc=0 ti_i2c_eeprom_get: 191: Out OK Bad EEPROM or unknown board, cannot configure pinmux.
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
чт, 11 авг. 2022 г. в 01:52, Nishanth Menon :
>
> On 11:40-20220807, Matwey V. Kornilov wrote:
> > пт, 5 авг. 2022 г. в 18:01, Robert Nelson :
> > >
> > > On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov
> > > wrote:
> > > >
> > > > пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> > > > >
> > > > > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > > > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > > > > >
> > > > > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've tried to build an am335x_evm_defconfig u-boot to use it on
> > > > > > > > my
> > > > > > > > BeagleBone Black board. Surprisingly, I've found that it
> > > > > > > > doesn't work,
> > > > > > > > I see the silent console: no messages even from SPL.
> > > > > > > >
> > > > > > > > Using bisect I've found that the following commit breaks the
> > > > > > > > booting:
> > > > > > > >
> > > > > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte
> > > > > > > > address
> > > > > > > > checks first.")
> > > > > > > >
> > > > > > > > Could you please help me?
> > > > > > >
> > > > > > > Can you share some more details about which BeagleBone Black you
> > > > > > > have,
> > > > > > > specifically the revision?
> > > > > >
> > > > > > It is an ordinary C revision. Unfortunately, I cannot remember who
> > > > > > the
> > > > > > producer was. As far as I know many companies made BeagleBone Black
> > > > > > and EEPROM content can be different.
> > > > >
> > > > > OK, that'll help some. Can you see what the specific part number of
> > > > > the
> > > > > EEPROM is? That might also help Nishanth figure out what to do here.
> > > >
> > > > Attached here is the EEPROM dump.
> > >
> > > .U3.A335BNLT00C0
> > >
> > > Ah, the "CO"... i'm pretty sure that board was made by Element14,
> > > (they messed up the position of the "C") not that it really mattered
> > > as the A335BNLT is only used..
> >
> > Hi Robert,
> >
> > I have BBB from different vendors, and I do remember that I've
> > purchased the Element14 version at some point. However, I've messed
> > everything up and cannot figure out which board from which vendor. You
> > are the most probably right, but still I cannot confirm the origin.
> >
> > >
> > > Can you please take a quick snapshot of the eeprom, it should be...
> > > 24LC32AT-I/OT but maybe they used another variation..
> >
> > Attached here is U7. It says M67E. 24AA32A/24LC32A datasheet page 14
> > says that it should be 24LC32AI.
> >
>
> Wierd.. took me a bit of digging, but I did get the element14 beaglebone
> rev C black board as well.. but it boots fine for me.
>
> https://gist.github.com/nmenon/104f040a67a6af0b0418c95ad83ad50b
>
> I tested the very tip of master:
> 3dd4e916324e Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
>
> Seemed to boot fine. Apparently it is supposed to be the same type as
> your board as well and it boots just fine on master.
>
> U7, however, on my board, is unmarked.
>
> Not really sure what to make of this.
Hi,
I am finally able to run debug UART (temporarily reverting 0dba4586),
and I see the following now:
Bad EEPROM or unknown board, cannot configure pinmux.
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
--
With best regards,
Matwey V. Kornilov
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Sat, Aug 13, 2022 at 06:31:56PM +0300, Matwey V. Kornilov wrote:
> чт, 11 авг. 2022 г. в 19:11, Matwey V. Kornilov :
> >
> > чт, 11 авг. 2022 г. в 15:53, Alex Kiernan :
> > >
> > > On Thu, Aug 11, 2022 at 1:46 PM Tom Rini wrote:
> > > >
> > > > On Thu, Aug 11, 2022 at 10:47:18AM +0300, Matwey V. Kornilov wrote:
> > > >
> > > > > Can somebody please advise me working CONFIG_DEBUG_UART _* values for
> > > > > the board? I think I need to obtain some output from the board to
> > > > > debug it further.
> > > >
> > > > Reading arch/arm/dts/am33xx-l4.dtsi isn't as easy to read as I would
> > > > personally like but 0x44e09000 is UART0 and so forth. Updating
> > > > doc/board/ti/am335x_evm.rst once you're done with a note about using
> > > > DEBUG_UART would be appreciated, thanks.
> > > >
> > >
> > > Some notes I have from a previous life which may be useful, but I'm
> > > afraid I've no way of checking these days:
> > >
> > > * CONFIG_DEBUG_UART=y
> > > * CONFIG_DEBUG_UART_BASE=0x44e09000
> > > * CONFIG_DEBUG_UART_CLOCK=4800
> > > * CONFIG_DEBUG_UART_OMAP=y
> > > * CONFIG_DEBUG_UART_SHIFT=2
> > > * CONFIG_DEBUG_UART_BOARD_INIT=y
> > > * CONFIG_DEBUG_UART_ANNOUNCE=y
> > >
> >
> > Thanks. Unfortunately, these don't work.
>
> Ok. The settings were working before 0dba4586 ("arm: Init the debug UART")
Simon, any ideas? This is on am335x_evm_defconfig, for example.
--
Tom
signature.asc
Description: PGP signature
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
чт, 11 авг. 2022 г. в 19:11, Matwey V. Kornilov :
>
> чт, 11 авг. 2022 г. в 15:53, Alex Kiernan :
> >
> > On Thu, Aug 11, 2022 at 1:46 PM Tom Rini wrote:
> > >
> > > On Thu, Aug 11, 2022 at 10:47:18AM +0300, Matwey V. Kornilov wrote:
> > >
> > > > Can somebody please advise me working CONFIG_DEBUG_UART _* values for
> > > > the board? I think I need to obtain some output from the board to
> > > > debug it further.
> > >
> > > Reading arch/arm/dts/am33xx-l4.dtsi isn't as easy to read as I would
> > > personally like but 0x44e09000 is UART0 and so forth. Updating
> > > doc/board/ti/am335x_evm.rst once you're done with a note about using
> > > DEBUG_UART would be appreciated, thanks.
> > >
> >
> > Some notes I have from a previous life which may be useful, but I'm
> > afraid I've no way of checking these days:
> >
> > * CONFIG_DEBUG_UART=y
> > * CONFIG_DEBUG_UART_BASE=0x44e09000
> > * CONFIG_DEBUG_UART_CLOCK=4800
> > * CONFIG_DEBUG_UART_OMAP=y
> > * CONFIG_DEBUG_UART_SHIFT=2
> > * CONFIG_DEBUG_UART_BOARD_INIT=y
> > * CONFIG_DEBUG_UART_ANNOUNCE=y
> >
>
> Thanks. Unfortunately, these don't work.
Ok. The settings were working before 0dba4586 ("arm: Init the debug UART")
>
> > --
> > Alex Kiernan
>
>
>
> --
> With best regards,
> Matwey V. Kornilov
--
With best regards,
Matwey V. Kornilov
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
чт, 11 авг. 2022 г. в 15:53, Alex Kiernan : > > On Thu, Aug 11, 2022 at 1:46 PM Tom Rini wrote: > > > > On Thu, Aug 11, 2022 at 10:47:18AM +0300, Matwey V. Kornilov wrote: > > > > > Can somebody please advise me working CONFIG_DEBUG_UART _* values for > > > the board? I think I need to obtain some output from the board to > > > debug it further. > > > > Reading arch/arm/dts/am33xx-l4.dtsi isn't as easy to read as I would > > personally like but 0x44e09000 is UART0 and so forth. Updating > > doc/board/ti/am335x_evm.rst once you're done with a note about using > > DEBUG_UART would be appreciated, thanks. > > > > Some notes I have from a previous life which may be useful, but I'm > afraid I've no way of checking these days: > > * CONFIG_DEBUG_UART=y > * CONFIG_DEBUG_UART_BASE=0x44e09000 > * CONFIG_DEBUG_UART_CLOCK=4800 > * CONFIG_DEBUG_UART_OMAP=y > * CONFIG_DEBUG_UART_SHIFT=2 > * CONFIG_DEBUG_UART_BOARD_INIT=y > * CONFIG_DEBUG_UART_ANNOUNCE=y > Thanks. Unfortunately, these don't work. > -- > Alex Kiernan -- With best regards, Matwey V. Kornilov
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Thu, Aug 11, 2022 at 1:46 PM Tom Rini wrote: > > On Thu, Aug 11, 2022 at 10:47:18AM +0300, Matwey V. Kornilov wrote: > > > Can somebody please advise me working CONFIG_DEBUG_UART _* values for > > the board? I think I need to obtain some output from the board to > > debug it further. > > Reading arch/arm/dts/am33xx-l4.dtsi isn't as easy to read as I would > personally like but 0x44e09000 is UART0 and so forth. Updating > doc/board/ti/am335x_evm.rst once you're done with a note about using > DEBUG_UART would be appreciated, thanks. > Some notes I have from a previous life which may be useful, but I'm afraid I've no way of checking these days: * CONFIG_DEBUG_UART=y * CONFIG_DEBUG_UART_BASE=0x44e09000 * CONFIG_DEBUG_UART_CLOCK=4800 * CONFIG_DEBUG_UART_OMAP=y * CONFIG_DEBUG_UART_SHIFT=2 * CONFIG_DEBUG_UART_BOARD_INIT=y * CONFIG_DEBUG_UART_ANNOUNCE=y -- Alex Kiernan
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Thu, Aug 11, 2022 at 10:47:18AM +0300, Matwey V. Kornilov wrote: > Can somebody please advise me working CONFIG_DEBUG_UART _* values for > the board? I think I need to obtain some output from the board to > debug it further. Reading arch/arm/dts/am33xx-l4.dtsi isn't as easy to read as I would personally like but 0x44e09000 is UART0 and so forth. Updating doc/board/ti/am335x_evm.rst once you're done with a note about using DEBUG_UART would be appreciated, thanks. -- Tom signature.asc Description: PGP signature
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
Can somebody please advise me working CONFIG_DEBUG_UART _* values for
the board? I think I need to obtain some output from the board to
debug it further.
чт, 11 авг. 2022 г. в 09:56, Matwey V. Kornilov :
>
> чт, 11 авг. 2022 г. в 01:52, Nishanth Menon :
> >
> > On 11:40-20220807, Matwey V. Kornilov wrote:
> > > пт, 5 авг. 2022 г. в 18:01, Robert Nelson :
> > > >
> > > > On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov
> > > > wrote:
> > > > >
> > > > > пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> > > > > >
> > > > > > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > > > > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > > > > > >
> > > > > > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I've tried to build an am335x_evm_defconfig u-boot to use it
> > > > > > > > > on my
> > > > > > > > > BeagleBone Black board. Surprisingly, I've found that it
> > > > > > > > > doesn't work,
> > > > > > > > > I see the silent console: no messages even from SPL.
> > > > > > > > >
> > > > > > > > > Using bisect I've found that the following commit breaks the
> > > > > > > > > booting:
> > > > > > > > >
> > > > > > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte
> > > > > > > > > address
> > > > > > > > > checks first.")
> > > > > > > > >
> > > > > > > > > Could you please help me?
> > > > > > > >
> > > > > > > > Can you share some more details about which BeagleBone Black
> > > > > > > > you have,
> > > > > > > > specifically the revision?
> > > > > > >
> > > > > > > It is an ordinary C revision. Unfortunately, I cannot remember
> > > > > > > who the
> > > > > > > producer was. As far as I know many companies made BeagleBone
> > > > > > > Black
> > > > > > > and EEPROM content can be different.
> > > > > >
> > > > > > OK, that'll help some. Can you see what the specific part number
> > > > > > of the
> > > > > > EEPROM is? That might also help Nishanth figure out what to do
> > > > > > here.
> > > > >
> > > > > Attached here is the EEPROM dump.
> > > >
> > > > .U3.A335BNLT00C0
> > > >
> > > > Ah, the "CO"... i'm pretty sure that board was made by Element14,
> > > > (they messed up the position of the "C") not that it really mattered
> > > > as the A335BNLT is only used..
> > >
> > > Hi Robert,
> > >
> > > I have BBB from different vendors, and I do remember that I've
> > > purchased the Element14 version at some point. However, I've messed
> > > everything up and cannot figure out which board from which vendor. You
> > > are the most probably right, but still I cannot confirm the origin.
> > >
> > > >
> > > > Can you please take a quick snapshot of the eeprom, it should be...
> > > > 24LC32AT-I/OT but maybe they used another variation..
> > >
> > > Attached here is U7. It says M67E. 24AA32A/24LC32A datasheet page 14
> > > says that it should be 24LC32AI.
> > >
> >
> > Wierd.. took me a bit of digging, but I did get the element14 beaglebone
> > rev C black board as well.. but it boots fine for me.
> >
> > https://gist.github.com/nmenon/104f040a67a6af0b0418c95ad83ad50b
> >
> > I tested the very tip of master:
> > 3dd4e916324e Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
>
> 3dd4e916324e doesn't work,
> 3dd4e916324e + reverted a58147c2dbbf boots:
>
> U-Boot SPL 2022.10-rc2-00029-g3dd4e91632-dirty (Aug 11 2022 - 09:50:59 +0300)
> Trying to boot from MMC1
>
>
> U-Boot 2022.10-rc2-00029-g3dd4e91632-dirty (Aug 11 2022 - 09:50:59 +0300)
>
> CPU : AM335X-GP rev 2.1
> Model: TI AM335x BeagleBone Black
> DRAM: 512 MiB
> Core: 160 devices, 18 uclasses, devicetree: separate
> WDT: Started wdt@44e35000 with servicing (60s timeout)
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> not set. Validating first E-fuse MAC
> Net: eth2: ethernet@4a10, eth3: usb_ether
> Hit any key to stop autoboot: 0
> => i2c dev 0 ; i2c md 0x50 0x00.2 400
> Setting bus to 0
> : aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30.U3.A335BNLT00C0
> 0010: 34 34 31 34 42 42 42 4b 31 30 30 30 ff ff ff ff4414BBBK1000
> 0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 0050: 58 41 4e 30 30 31 30 30 30 58 58 58 58 58 58 58XAN001000XXX
> 0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
>
>
>
> >
> > Seemed to boot fine. Apparently it is supposed to be the same type as
> >
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
чт, 11 авг. 2022 г. в 01:52, Nishanth Menon :
>
> On 11:40-20220807, Matwey V. Kornilov wrote:
> > пт, 5 авг. 2022 г. в 18:01, Robert Nelson :
> > >
> > > On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov
> > > wrote:
> > > >
> > > > пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> > > > >
> > > > > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > > > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > > > > >
> > > > > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I've tried to build an am335x_evm_defconfig u-boot to use it on
> > > > > > > > my
> > > > > > > > BeagleBone Black board. Surprisingly, I've found that it
> > > > > > > > doesn't work,
> > > > > > > > I see the silent console: no messages even from SPL.
> > > > > > > >
> > > > > > > > Using bisect I've found that the following commit breaks the
> > > > > > > > booting:
> > > > > > > >
> > > > > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte
> > > > > > > > address
> > > > > > > > checks first.")
> > > > > > > >
> > > > > > > > Could you please help me?
> > > > > > >
> > > > > > > Can you share some more details about which BeagleBone Black you
> > > > > > > have,
> > > > > > > specifically the revision?
> > > > > >
> > > > > > It is an ordinary C revision. Unfortunately, I cannot remember who
> > > > > > the
> > > > > > producer was. As far as I know many companies made BeagleBone Black
> > > > > > and EEPROM content can be different.
> > > > >
> > > > > OK, that'll help some. Can you see what the specific part number of
> > > > > the
> > > > > EEPROM is? That might also help Nishanth figure out what to do here.
> > > >
> > > > Attached here is the EEPROM dump.
> > >
> > > .U3.A335BNLT00C0
> > >
> > > Ah, the "CO"... i'm pretty sure that board was made by Element14,
> > > (they messed up the position of the "C") not that it really mattered
> > > as the A335BNLT is only used..
> >
> > Hi Robert,
> >
> > I have BBB from different vendors, and I do remember that I've
> > purchased the Element14 version at some point. However, I've messed
> > everything up and cannot figure out which board from which vendor. You
> > are the most probably right, but still I cannot confirm the origin.
> >
> > >
> > > Can you please take a quick snapshot of the eeprom, it should be...
> > > 24LC32AT-I/OT but maybe they used another variation..
> >
> > Attached here is U7. It says M67E. 24AA32A/24LC32A datasheet page 14
> > says that it should be 24LC32AI.
> >
>
> Wierd.. took me a bit of digging, but I did get the element14 beaglebone
> rev C black board as well.. but it boots fine for me.
>
> https://gist.github.com/nmenon/104f040a67a6af0b0418c95ad83ad50b
>
> I tested the very tip of master:
> 3dd4e916324e Merge https://source.denx.de/u-boot/custodians/u-boot-marvell
3dd4e916324e doesn't work,
3dd4e916324e + reverted a58147c2dbbf boots:
U-Boot SPL 2022.10-rc2-00029-g3dd4e91632-dirty (Aug 11 2022 - 09:50:59 +0300)
Trying to boot from MMC1
U-Boot 2022.10-rc2-00029-g3dd4e91632-dirty (Aug 11 2022 - 09:50:59 +0300)
CPU : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM: 512 MiB
Core: 160 devices, 18 uclasses, devicetree: separate
WDT: Started wdt@44e35000 with servicing (60s timeout)
NAND: 0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
not set. Validating first E-fuse MAC
Net: eth2: ethernet@4a10, eth3: usb_ether
Hit any key to stop autoboot: 0
=> i2c dev 0 ; i2c md 0x50 0x00.2 400
Setting bus to 0
: aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30.U3.A335BNLT00C0
0010: 34 34 31 34 42 42 42 4b 31 30 30 30 ff ff ff ff4414BBBK1000
0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0050: 58 41 4e 30 30 31 30 30 30 58 58 58 58 58 58 58XAN001000XXX
0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> Seemed to boot fine. Apparently it is supposed to be the same type as
> your board as well and it boots just fine on master.
>
> U7, however, on my board, is unmarked.
>
> Not really sure what to make of this.
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
--
With best regards,
Matwey V. Kornilov
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
пт, 5 авг. 2022 г. в 18:01, Robert Nelson :
>
> On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov
> wrote:
> >
> > пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> > >
> > > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > > >
> > > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I've tried to build an am335x_evm_defconfig u-boot to use it on my
> > > > > > BeagleBone Black board. Surprisingly, I've found that it doesn't
> > > > > > work,
> > > > > > I see the silent console: no messages even from SPL.
> > > > > >
> > > > > > Using bisect I've found that the following commit breaks the
> > > > > > booting:
> > > > > >
> > > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> > > > > > checks first.")
> > > > > >
> > > > > > Could you please help me?
> > > > >
> > > > > Can you share some more details about which BeagleBone Black you have,
> > > > > specifically the revision?
> > > >
> > > > It is an ordinary C revision. Unfortunately, I cannot remember who the
> > > > producer was. As far as I know many companies made BeagleBone Black
> > > > and EEPROM content can be different.
> > >
> > > OK, that'll help some. Can you see what the specific part number of the
> > > EEPROM is? That might also help Nishanth figure out what to do here.
> >
> > Attached here is the EEPROM dump.
>
> .U3.A335BNLT00C0
>
> Ah, the "CO"... i'm pretty sure that board was made by Element14,
> (they messed up the position of the "C") not that it really mattered
> as the A335BNLT is only used..
Hi Robert,
I have BBB from different vendors, and I do remember that I've
purchased the Element14 version at some point. However, I've messed
everything up and cannot figure out which board from which vendor. You
are the most probably right, but still I cannot confirm the origin.
>
> Can you please take a quick snapshot of the eeprom, it should be...
> 24LC32AT-I/OT but maybe they used another variation..
Attached here is U7. It says M67E. 24AA32A/24LC32A datasheet page 14
says that it should be 24LC32AI.
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
--
With best regards,
Matwey V. Kornilov
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov
wrote:
>
> пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> >
> > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > >
> > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I've tried to build an am335x_evm_defconfig u-boot to use it on my
> > > > > BeagleBone Black board. Surprisingly, I've found that it doesn't work,
> > > > > I see the silent console: no messages even from SPL.
> > > > >
> > > > > Using bisect I've found that the following commit breaks the booting:
> > > > >
> > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> > > > > checks first.")
> > > > >
> > > > > Could you please help me?
> > > >
> > > > Can you share some more details about which BeagleBone Black you have,
> > > > specifically the revision?
> > >
> > > It is an ordinary C revision. Unfortunately, I cannot remember who the
> > > producer was. As far as I know many companies made BeagleBone Black
> > > and EEPROM content can be different.
> >
> > OK, that'll help some. Can you see what the specific part number of the
> > EEPROM is? That might also help Nishanth figure out what to do here.
>
> Attached here is the EEPROM dump.
.U3.A335BNLT00C0
Ah, the "CO"... i'm pretty sure that board was made by Element14,
(they messed up the position of the "C") not that it really mattered
as the A335BNLT is only used..
Can you please take a quick snapshot of the eeprom, it should be...
24LC32AT-I/OT but maybe they used another variation..
Regards,
--
Robert Nelson
https://rcn-ee.com/
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
пт, 29 июл. 2022 г. в 20:06, Matwey V. Kornilov :
>
> пт, 29 июл. 2022 г. в 19:46, Tom Rini :
> >
> > On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > > >
> > > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I've tried to build an am335x_evm_defconfig u-boot to use it on my
> > > > > BeagleBone Black board. Surprisingly, I've found that it doesn't work,
> > > > > I see the silent console: no messages even from SPL.
> > > > >
> > > > > Using bisect I've found that the following commit breaks the booting:
> > > > >
> > > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> > > > > checks first.")
> > > > >
> > > > > Could you please help me?
> > > >
> > > > Can you share some more details about which BeagleBone Black you have,
> > > > specifically the revision?
> > >
> > > It is an ordinary C revision. Unfortunately, I cannot remember who the
> > > producer was. As far as I know many companies made BeagleBone Black
> > > and EEPROM content can be different.
> >
> > OK, that'll help some. Can you see what the specific part number of the
> > EEPROM is? That might also help Nishanth figure out what to do here.
>
> Attached here is the EEPROM dump.
>
> >
> > --
> > Tom
>
>
>
> --
> With best regards,
> Matwey V. Kornilov
My other BeagleBoneBlack successfully boots with this commit (with the
same u-boot image the first board doesn't boot). Attached here is the
EEPROM dump for the second board.
--
With best regards,
Matwey V. Kornilov
eeprom2.bin
Description: Binary data
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
пт, 29 июл. 2022 г. в 19:46, Tom Rini :
>
> On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> > пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> > >
> > > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
> > >
> > > > Hi,
> > > >
> > > > I've tried to build an am335x_evm_defconfig u-boot to use it on my
> > > > BeagleBone Black board. Surprisingly, I've found that it doesn't work,
> > > > I see the silent console: no messages even from SPL.
> > > >
> > > > Using bisect I've found that the following commit breaks the booting:
> > > >
> > > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> > > > checks first.")
> > > >
> > > > Could you please help me?
> > >
> > > Can you share some more details about which BeagleBone Black you have,
> > > specifically the revision?
> >
> > It is an ordinary C revision. Unfortunately, I cannot remember who the
> > producer was. As far as I know many companies made BeagleBone Black
> > and EEPROM content can be different.
>
> OK, that'll help some. Can you see what the specific part number of the
> EEPROM is? That might also help Nishanth figure out what to do here.
Attached here is the EEPROM dump.
>
> --
> Tom
--
With best regards,
Matwey V. Kornilov
eeprom.bin
Description: Binary data
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
> пт, 29 июл. 2022 г. в 19:32, Tom Rini :
> >
> > On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
> >
> > > Hi,
> > >
> > > I've tried to build an am335x_evm_defconfig u-boot to use it on my
> > > BeagleBone Black board. Surprisingly, I've found that it doesn't work,
> > > I see the silent console: no messages even from SPL.
> > >
> > > Using bisect I've found that the following commit breaks the booting:
> > >
> > > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> > > checks first.")
> > >
> > > Could you please help me?
> >
> > Can you share some more details about which BeagleBone Black you have,
> > specifically the revision?
>
> It is an ordinary C revision. Unfortunately, I cannot remember who the
> producer was. As far as I know many companies made BeagleBone Black
> and EEPROM content can be different.
OK, that'll help some. Can you see what the specific part number of the
EEPROM is? That might also help Nishanth figure out what to do here.
--
Tom
signature.asc
Description: PGP signature
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
пт, 29 июл. 2022 г. в 19:32, Tom Rini :
>
> On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
>
> > Hi,
> >
> > I've tried to build an am335x_evm_defconfig u-boot to use it on my
> > BeagleBone Black board. Surprisingly, I've found that it doesn't work,
> > I see the silent console: no messages even from SPL.
> >
> > Using bisect I've found that the following commit breaks the booting:
> >
> > a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> > checks first.")
> >
> > Could you please help me?
>
> Can you share some more details about which BeagleBone Black you have,
> specifically the revision?
It is an ordinary C revision. Unfortunately, I cannot remember who the
producer was. As far as I know many companies made BeagleBone Black
and EEPROM content can be different.
>
> --
> Tom
--
With best regards,
Matwey V. Kornilov
Re: [BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
On Fri, Jul 29, 2022 at 07:20:11PM +0300, Matwey V. Kornilov wrote:
> Hi,
>
> I've tried to build an am335x_evm_defconfig u-boot to use it on my
> BeagleBone Black board. Surprisingly, I've found that it doesn't work,
> I see the silent console: no messages even from SPL.
>
> Using bisect I've found that the following commit breaks the booting:
>
> a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
> checks first.")
>
> Could you please help me?
Can you share some more details about which BeagleBone Black you have,
specifically the revision?
--
Tom
signature.asc
Description: PGP signature
[BISECTED] BeagleBone Black doesn't boot after a58147c2dbbf
Hi,
I've tried to build an am335x_evm_defconfig u-boot to use it on my
BeagleBone Black board. Surprisingly, I've found that it doesn't work,
I see the silent console: no messages even from SPL.
Using bisect I've found that the following commit breaks the booting:
a58147c2dbbf ("board: ti: common: board_detect: Do 1byte address
checks first.")
Could you please help me?
--
With best regards,
Matwey V. Kornilov
