[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?

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?

пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com:
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

On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com:
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.

пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com:
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

пт, 29 июл. 2022 г. в 20:06, Matwey V. Kornilov matwey.kornilov@gmail.com:
пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com:
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.

On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com:
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,

пт, 5 авг. 2022 г. в 18:01, Robert Nelson robertcnelson@gmail.com:
On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com:
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/

On 11:40-20220807, Matwey V. Kornilov wrote:
пт, 5 авг. 2022 г. в 18:01, Robert Nelson robertcnelson@gmail.com:
On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com:
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.

чт, 11 авг. 2022 г. в 01:52, Nishanth Menon nm@ti.com:
On 11:40-20220807, Matwey V. Kornilov wrote:
пт, 5 авг. 2022 г. в 18:01, Robert Nelson robertcnelson@gmail.com:
On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com: > > 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... <ethaddr> not set. Validating first E-fuse MAC Net: eth2: ethernet@4a100000, eth3: usb_ether Hit any key to stop autoboot: 0 => i2c dev 0 ; i2c md 0x50 0x00.2 400 Setting bus to 0 0000: 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 ff 4414BBBK1000.... 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 58 XAN001000XXXXXXX 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

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 matwey.kornilov@gmail.com:
чт, 11 авг. 2022 г. в 01:52, Nishanth Menon nm@ti.com:
On 11:40-20220807, Matwey V. Kornilov wrote:
пт, 5 авг. 2022 г. в 18:01, Robert Nelson robertcnelson@gmail.com:
On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote: > пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com: > > > > 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... <ethaddr> not set. Validating first E-fuse MAC Net: eth2: ethernet@4a100000, eth3: usb_ether Hit any key to stop autoboot: 0 => i2c dev 0 ; i2c md 0x50 0x00.2 400 Setting bus to 0 0000: 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 ff 4414BBBK1000.... 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 58 XAN001000XXXXXXX 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

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.

On Thu, Aug 11, 2022 at 1:46 PM Tom Rini trini@konsulko.com 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=48000000 * CONFIG_DEBUG_UART_OMAP=y * CONFIG_DEBUG_UART_SHIFT=2 * CONFIG_DEBUG_UART_BOARD_INIT=y * CONFIG_DEBUG_UART_ANNOUNCE=y

чт, 11 авг. 2022 г. в 15:53, Alex Kiernan alex.kiernan@gmail.com:
On Thu, Aug 11, 2022 at 1:46 PM Tom Rini trini@konsulko.com 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=48000000
- 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

чт, 11 авг. 2022 г. в 19:11, Matwey V. Kornilov matwey.kornilov@gmail.com:
чт, 11 авг. 2022 г. в 15:53, Alex Kiernan alex.kiernan@gmail.com:
On Thu, Aug 11, 2022 at 1:46 PM Tom Rini trini@konsulko.com 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=48000000
- 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

On Sat, Aug 13, 2022 at 06:31:56PM +0300, Matwey V. Kornilov wrote:
чт, 11 авг. 2022 г. в 19:11, Matwey V. Kornilov matwey.kornilov@gmail.com:
чт, 11 авг. 2022 г. в 15:53, Alex Kiernan alex.kiernan@gmail.com:
On Thu, Aug 11, 2022 at 1:46 PM Tom Rini trini@konsulko.com 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=48000000
- 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.

чт, 11 авг. 2022 г. в 01:52, Nishanth Menon nm@ti.com:
On 11:40-20220807, Matwey V. Kornilov wrote:
пт, 5 авг. 2022 г. в 18:01, Robert Nelson robertcnelson@gmail.com:
On Fri, Jul 29, 2022 at 12:07 PM Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
пт, 29 июл. 2022 г. в 19:46, Tom Rini trini@konsulko.com:
On Fri, Jul 29, 2022 at 07:38:28PM +0300, Matwey V. Kornilov wrote:
пт, 29 июл. 2022 г. в 19:32, Tom Rini trini@konsulko.com: > > 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:
<debug_uart> Bad EEPROM or unknown board, cannot configure pinmux.
-- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
participants (5)
-
Alex Kiernan
-
Matwey V. Kornilov
-
Nishanth Menon
-
Robert Nelson
-
Tom Rini