13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

John-Mark Gurney-2
The microSD card that I was using on my BeagleBone white got corrupted,
so I decided to update to the latest version.  The latest snapshot fails
to boot.  It loads the kernel, but then when starting the kernel, it
hangs, and eventually it will reset.

The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.

Any ideas?  I tried all three available 13 snaps, and they all behave
the same.

The following is an example of the reset loop:
Kernel entry at 0x84000180...
Kernel args: (null)
/
U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000)
Trying to boot from MMC1
Loading Environment from FAT... *** Warning - bad CRC, using default environment



U-Boot 2019.04 (Jul 18 2019 - 04:19:33 +0000)

CPU  : AM335X-GP rev 1.0
Model: TI AM335x BeagleBone
DRAM:  256 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

<ethaddr> not set. Validating first E-fuse MAC
Net:   eth0: ethernet@4a100000
Warning: usb_ether MAC addresses don't match:
Address in ROM is          de:ad:be:ef:00:01
Address in environment is  d4:94:a1:85:ce:72
, eth1: usb_ether
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
80492 bytes read in 8 ms (9.6 MiB/s)
Found EFI removable media binary efi/boot/bootarm.efi
Scanning disk [hidden email]...
Found 3 disks
BootOrder not defined
616000 bytes read in 54 ms (10.9 MiB/s)
## Starting EFI application at 82000000 ...
Consoles: EFI console  
    Reading loader env vars from /efi/freebsd/loader.env
Setting currdev to disk0p1:
FreeBSD/arm EFI loader, Revision 1.1

   Command line arguments: l
   EFI version: 2.70
   EFI Firmware: Das U-Boot (rev 8217.1024)
   Console: efi (0)
   Load Path: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)/efi\boot\bootarm.efi
   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)
Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)
Setting currdev to disk0p1:
Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x193d7,0x5e6c11)
Setting currdev to disk0p2:
Loading /boot/defaults/loader.conf
Loading /boot/device.hints
Loading /boot/loader.conf
Loading /boot/loader.conf.local
Loading kernel...
/boot/kernel/kernel text=0x85a6c4 data=0xb41e0+0x258720 syms=[0x4+0xa8d50+0x4+0x10c071]
Loading configured modules...
can't find '/boot/entropy'
/boot/kernel/umodem.ko text=0x1be0 text=0x1310 data=0x1088+0xf80 syms=[0x4+0x1070+0x4+0xbcd]
loading required module 'ucom'
/boot/kernel/ucom.ko text=0x1f74 text=0x2e40 data=0x1088+0x17b4 syms=[0x4+0x14f0+0x4+0xc5d]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...              
Using DTB provided by EFI at 0x87ee9000.
Kernel entry at 0x84000180...
Kernel args: (null)
/
U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000)
Trying to boot from MMC1
Loading Environment from FAT... *** Warning - bad CRC, using default environment


--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Ian Lepore-3
On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:

> The microSD card that I was using on my BeagleBone white got
> corrupted,
> so I decided to update to the latest version.  The latest snapshot
> fails
> to boot.  It loads the kernel, but then when starting the kernel, it
> hangs, and eventually it will reset.
>
> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
>
> Any ideas?  I tried all three available 13 snaps, and they all behave
> the same.
>

This happened with the latest DTS import (which was months ago).  A
couple people have speculated that we just need a trivial do-nothing
driver for the new ti,sysc device, but when I tried that a couple
months ago it didn't work, so instead I just reverted sys/dts to the
old source and got on with what I needed to do.

This is just the latest in a years-long string of breakages because the
linux TI folks just never stop tinkering with their device-tree source.
I'm sure they're doing it because it gets them some benefits, but for
us the changes add no value and have a high maintenance cost.  A hang
before the copyright banner appears is especially painful to debug
(doubly so because there's no existing EARLY_PRINTF support in the ti
code).

- Ian

> The following is an example of the reset loop:
> Kernel entry at 0x84000180...
> Kernel args: (null)
> /
> U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000)
> Trying to boot from MMC1
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
>
>
> U-Boot 2019.04 (Jul 18 2019 - 04:19:33 +0000)
>   I just tried the trivial sysc driver again, it definitely hangs the
> same as not having the driver.
> CPU  : AM335X-GP rev 1.0
> Model: TI AM335x BeagleBone
> DRAM:  256 MiB
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
> <ethaddr> not set. Validating first E-fuse MAC
> Net:   eth0: ethernet@4a100000
> Warning: usb_ether MAC addresses don't match:
> Address in ROM is          de:ad:be:ef:00:01
> Address in environment is  d4:94:a1:85:ce:72
> , eth1: usb_ether
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> 80492 bytes read in 8 ms (9.6 MiB/s)
> Found EFI removable media binary efi/boot/bootarm.efi
> Scanning disk [hidden email]...
> Found 3 disks
> BootOrder not defined
> 616000 bytes read in 54 ms (10.9 MiB/s)
> ## Starting EFI application at 82000000 ...
> Consoles: EFI console  
>     Reading loader env vars from /efi/freebsd/loader.env
> Setting currdev to disk0p1:
> FreeBSD/arm EFI loader, Revision 1.1
>
>    Command line arguments: l
>    EFI version: 2.70
>    EFI Firmware: Das U-Boot (rev 8217.1024)
>    Console: efi (0)
>    Load Path: /VenHw(e61d73b9-a384-4acc-aeab-
> 82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)/efi\boot\bootarm
> .efi
>    Load Device: /VenHw(e61d73b9-a384-4acc-aeab-
> 82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)
> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-
> 82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x42f,0x18fa8)
> Setting currdev to disk0p1:
> Trying: /VenHw(e61d73b9-a384-4acc-aeab-
> 82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x193d7,0x5e6c11)
> Setting currdev to disk0p2:
> Loading /boot/defaults/loader.conf
> Loading /boot/device.hints
> Loading /boot/loader.conf
> Loading /boot/loader.conf.local
> Loading kernel...
> /boot/kernel/kernel text=0x85a6c4 data=0xb41e0+0x258720
> syms=[0x4+0xa8d50+0x4+0x10c071]
> Loading configured modules...
> can't find '/boot/entropy'
> /boot/kernel/umodem.ko text=0x1be0 text=0x1310 data=0x1088+0xf80
> syms=[0x4+0x1070+0x4+0xbcd]
> loading required module 'ucom'
> /boot/kernel/ucom.ko text=0x1f74 text=0x2e40 data=0x1088+0x17b4
> syms=[0x4+0x14f0+0x4+0xc5d]
>
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...              
> Using DTB provided by EFI at 0x87ee9000.
> Kernel entry at 0x84000180...
> Kernel args: (null)
> /
> U-Boot SPL 2019.04 (Jul 18 2019 - 04:19:33 +0000)
> Trying to boot from MMC1
> Loading Environment from FAT... *** Warning - bad CRC, using default
> environment
>
>

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

John-Mark Gurney-2
Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:

> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
> > The microSD card that I was using on my BeagleBone white got
> > corrupted,
> > so I decided to update to the latest version.  The latest snapshot
> > fails
> > to boot.  It loads the kernel, but then when starting the kernel, it
> > hangs, and eventually it will reset.
> >
> > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
> >
> > Any ideas?  I tried all three available 13 snaps, and they all behave
> > the same.
> >
>
> This happened with the latest DTS import (which was months ago).  A
> couple people have speculated that we just need a trivial do-nothing
> driver for the new ti,sysc device, but when I tried that a couple
> months ago it didn't work, so instead I just reverted sys/dts to the
> old source and got on with what I needed to do.

Can we revert the dts in the tree then?  Doesn't help when we know
the fix, but don't apply it...

Or add an overlay that undoes the changes?

I can do some testing...

> This is just the latest in a years-long string of breakages because the
> linux TI folks just never stop tinkering with their device-tree source.
> I'm sure they're doing it because it gets them some benefits, but for
> us the changes add no value and have a high maintenance cost.  A hang
> before the copyright banner appears is especially painful to debug
> (doubly so because there's no existing EARLY_PRINTF support in the ti
> code).

[...]

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Emmanuel Vadot-7
On Sun, 21 Jul 2019 13:55:57 -0700
John-Mark Gurney <[hidden email]> wrote:

> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
> > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
> > > The microSD card that I was using on my BeagleBone white got
> > > corrupted,
> > > so I decided to update to the latest version.  The latest snapshot
> > > fails
> > > to boot.  It loads the kernel, but then when starting the kernel, it
> > > hangs, and eventually it will reset.
> > >
> > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
> > >
> > > Any ideas?  I tried all three available 13 snaps, and they all behave
> > > the same.
> > >
> >
> > This happened with the latest DTS import (which was months ago).  A
> > couple people have speculated that we just need a trivial do-nothing
> > driver for the new ti,sysc device, but when I tried that a couple
> > months ago it didn't work, so instead I just reverted sys/dts to the
> > old source and got on with what I needed to do.
>
> Can we revert the dts in the tree then?  Doesn't help when we know
> the fix, but don't apply it...

 That would be a pain for the next updates.

> Or add an overlay that undoes the changes?
>
> I can do some testing...

 Could be possible but that will probably break in a few updates of the
DTS files.

 We need a TI maintainer that's all.

> > This is just the latest in a years-long string of breakages because the
> > linux TI folks just never stop tinkering with their device-tree source.
> > I'm sure they're doing it because it gets them some benefits, but for
> > us the changes add no value and have a high maintenance cost.  A hang
> > before the copyright banner appears is especially painful to debug
> > (doubly so because there's no existing EARLY_PRINTF support in the ti
> > code).
>
> [...]
>
> --
>   John-Mark Gurney Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"


--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

John-Mark Gurney-2
Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200:

> On Sun, 21 Jul 2019 13:55:57 -0700
> John-Mark Gurney <[hidden email]> wrote:
>
> > Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
> > > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
> > > > The microSD card that I was using on my BeagleBone white got
> > > > corrupted,
> > > > so I decided to update to the latest version.  The latest snapshot
> > > > fails
> > > > to boot.  It loads the kernel, but then when starting the kernel, it
> > > > hangs, and eventually it will reset.
> > > >
> > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
> > > >
> > > > Any ideas?  I tried all three available 13 snaps, and they all behave
> > > > the same.
> > > >
> > >
> > > This happened with the latest DTS import (which was months ago).  A
> > > couple people have speculated that we just need a trivial do-nothing
> > > driver for the new ti,sysc device, but when I tried that a couple
> > > months ago it didn't work, so instead I just reverted sys/dts to the
> > > old source and got on with what I needed to do.
> >
> > Can we revert the dts in the tree then?  Doesn't help when we know
> > the fix, but don't apply it...
>
>  That would be a pain for the next updates.

Well, IMO, better than leaving a platform broken for months...

> > Or add an overlay that undoes the changes?
> >
> > I can do some testing...
>
>  Could be possible but that will probably break in a few updates of the
> DTS files.
>
>  We need a TI maintainer that's all.

I'd recommend we disconnect the builds then or something so that people
know not even to bother to try the images instead of wasting hours of
time trying to figure out what's wrong w/ the images...

At least then I'd post where's the images, and you would have replied
that things aren't working...

> > > This is just the latest in a years-long string of breakages because the
> > > linux TI folks just never stop tinkering with their device-tree source.
> > > I'm sure they're doing it because it gets them some benefits, but for
> > > us the changes add no value and have a high maintenance cost.  A hang
> > > before the copyright banner appears is especially painful to debug
> > > (doubly so because there's no existing EARLY_PRINTF support in the ti
> > > code).
> >
> > [...]

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Emmanuel Vadot-7
On Mon, 22 Jul 2019 10:12:51 -0700
John-Mark Gurney <[hidden email]> wrote:

> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200:
> > On Sun, 21 Jul 2019 13:55:57 -0700
> > John-Mark Gurney <[hidden email]> wrote:
> >
> > > Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
> > > > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
> > > > > The microSD card that I was using on my BeagleBone white got
> > > > > corrupted,
> > > > > so I decided to update to the latest version.  The latest snapshot
> > > > > fails
> > > > > to boot.  It loads the kernel, but then when starting the kernel, it
> > > > > hangs, and eventually it will reset.
> > > > >
> > > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
> > > > >
> > > > > Any ideas?  I tried all three available 13 snaps, and they all behave
> > > > > the same.
> > > > >
> > > >
> > > > This happened with the latest DTS import (which was months ago).  A
> > > > couple people have speculated that we just need a trivial do-nothing
> > > > driver for the new ti,sysc device, but when I tried that a couple
> > > > months ago it didn't work, so instead I just reverted sys/dts to the
> > > > old source and got on with what I needed to do.
> > >
> > > Can we revert the dts in the tree then?  Doesn't help when we know
> > > the fix, but don't apply it...
> >
> >  That would be a pain for the next updates.
>
> Well, IMO, better than leaving a platform broken for months...
>
> > > Or add an overlay that undoes the changes?
> > >
> > > I can do some testing...
> >
> >  Could be possible but that will probably break in a few updates of the
> > DTS files.
> >
> >  We need a TI maintainer that's all.
>
> I'd recommend we disconnect the builds then or something so that people
> know not even to bother to try the images instead of wasting hours of
> time trying to figure out what's wrong w/ the images...
>
> At least then I'd post where's the images, and you would have replied
> that things aren't working...
>
> > > > This is just the latest in a years-long string of breakages because the
> > > > linux TI folks just never stop tinkering with their device-tree source.
> > > > I'm sure they're doing it because it gets them some benefits, but for
> > > > us the changes add no value and have a high maintenance cost.  A hang
> > > > before the copyright banner appears is especially painful to debug
> > > > (doubly so because there's no existing EARLY_PRINTF support in the ti
> > > > code).
> > >
> > > [...]
>
> --
>   John-Mark Gurney Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."

 So I've unbroken the BBB.

 I've made two commits :
 r350229 ([1]) changes the hwmod driver to lookup the property in the
parent node as the dts changed that.
 r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus
like bus and for now we only threat it like if it was.

 But this is not enough to boot on BBB for now with the latest DTS.
 I've put on a github branch ([3]) two other commits.

 The first one correct the region of uart0 which isn't correct, I guess linux
 doesn't care about this as much as we do. Since this patches the DTS I want
 to start the process of upstreaming first before commiting this patch into
 our tree. I also want to update the DTS to Linux 5.2 since I want to merge
 those for 12.1 .
 The second one take care of a problem in ofw_reg_to_paddr. Since we have now
 a lot of region in the ti.sysc drivers, using only 32 pcells for the regions
 isn't enough. I've temporary bumped this value to 64 which is enough for booting
 on the BBB but we need a cleaner solution. I'll look into it soon-ish.

 So right now if you want to run current on BBB please take update you source tree
 and take the two patches from my github branch.

 Note that I think that this is the last time that I fix TI related problems
 in the tree. I've spent too much time fixing BBB and Pandaboard during the
 last 12 months and I don't even use or care about those boards. If someone
 wants to keep them alive please invest time or money into this.

 Thanks to ian@ for helping me with this issue.

[1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup
[2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup
[3] : https://github.com/evadot/freebsd/tree/bbb

--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Dr. Rolf Jansen-2
> Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot <[hidden email]>:
>
> ...
>
> Note that I think that this is the last time that I fix TI related problems
> in the tree. I've spent too much time fixing BBB and Pandaboard during the
> last 12 months and I don't even use or care about those boards. If someone
> wants to keep them alive please invest time or money into this.

You can have this quite easily. Simply revert your non-revisited batch import of 3126 files of the Linux DTS tree to the previous state (https://svnweb.freebsd.org/base?view=revision&revision=347366)

Then let others import what they need file by file or snippet by snippet. By this you would be guaranteed to never be bothered agin with any BeagleBone.

Best regards

Rolf
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

freebsd-arm mailing list
In reply to this post by Emmanuel Vadot-7
2019-07-23 00:21 skrev Emmanuel Vadot:

> On Mon, 22 Jul 2019 10:12:51 -0700
> John-Mark Gurney <[hidden email]> wrote:
>
>> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200:
>> > On Sun, 21 Jul 2019 13:55:57 -0700
>> > John-Mark Gurney <[hidden email]> wrote:
>> >
>> > > Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
>> > > > On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
>> > > > > The microSD card that I was using on my BeagleBone white got
>> > > > > corrupted,
>> > > > > so I decided to update to the latest version.  The latest snapshot
>> > > > > fails
>> > > > > to boot.  It loads the kernel, but then when starting the kernel, it
>> > > > > hangs, and eventually it will reset.
>> > > > >
>> > > > > The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
>> > > > >
>> > > > > Any ideas?  I tried all three available 13 snaps, and they all behave
>> > > > > the same.
>> > > > >
>> > > >
>> > > > This happened with the latest DTS import (which was months ago).  A
>> > > > couple people have speculated that we just need a trivial do-nothing
>> > > > driver for the new ti,sysc device, but when I tried that a couple
>> > > > months ago it didn't work, so instead I just reverted sys/dts to the
>> > > > old source and got on with what I needed to do.
>> > >
>> > > Can we revert the dts in the tree then?  Doesn't help when we know
>> > > the fix, but don't apply it...
>> >
>> >  That would be a pain for the next updates.
>>
>> Well, IMO, better than leaving a platform broken for months...
>>
>> > > Or add an overlay that undoes the changes?
>> > >
>> > > I can do some testing...
>> >
>> >  Could be possible but that will probably break in a few updates of the
>> > DTS files.
>> >
>> >  We need a TI maintainer that's all.
>>
>> I'd recommend we disconnect the builds then or something so that people
>> know not even to bother to try the images instead of wasting hours of
>> time trying to figure out what's wrong w/ the images...
>>
>> At least then I'd post where's the images, and you would have replied
>> that things aren't working...
>>
>> > > > This is just the latest in a years-long string of breakages because the
>> > > > linux TI folks just never stop tinkering with their device-tree source.
>> > > > I'm sure they're doing it because it gets them some benefits, but for
>> > > > us the changes add no value and have a high maintenance cost.  A hang
>> > > > before the copyright banner appears is especially painful to debug
>> > > > (doubly so because there's no existing EARLY_PRINTF support in the ti
>> > > > code).
>> > >
>> > > [...]
>>
>> --
>>   John-Mark Gurney                Voice: +1 415 225 5579
>>
>>      "All that I will do, has been done, All that I have, has not."
>
>  So I've unbroken the BBB.
>

I appreciate your work, thank you!

>  I've made two commits :
>  r350229 ([1]) changes the hwmod driver to lookup the property in the
> parent node as the dts changed that.
>  r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus
> like bus and for now we only threat it like if it was.
>
>  But this is not enough to boot on BBB for now with the latest DTS.
>  I've put on a github branch ([3]) two other commits.
>
>  The first one correct the region of uart0 which isn't correct, I guess linux
>  doesn't care about this as much as we do. Since this patches the DTS I want
>  to start the process of upstreaming first before commiting this patch into
>  our tree. I also want to update the DTS to Linux 5.2 since I want to merge
>  those for 12.1 .

Is there any strategy for device tree imports from Linux?
In the upcoming 13 i dont mind running the latest and greatest. But in 11.x / 12.x?

>  The second one take care of a problem in ofw_reg_to_paddr. Since we have now
>  a lot of region in the ti.sysc drivers, using only 32 pcells for the regions
>  isn't enough. I've temporary bumped this value to 64 which is enough
> for booting
>  on the BBB but we need a cleaner solution. I'll look into it soon-ish.
>
>  So right now if you want to run current on BBB please take update you
> source tree
>  and take the two patches from my github branch.
>
>  Note that I think that this is the last time that I fix TI related problems
>  in the tree. I've spent too much time fixing BBB and Pandaboard during the
>  last 12 months and I don't even use or care about those boards. If someone
>  wants to keep them alive please invest time or money into this.
>
Again, Thank you for your work. Yes I'm interested in keeping the TI SoC alive.
I will put up the resources to do periodic tests and bugfixes for the 12-stable for AM335x (and OSD3358).
If we can agree on a baseline of tests we can perform the test on other boards aswell.  Maybe based on proposal from Mark Linimon?

>  Thanks to ian@ for helping me with this issue.
>
> [1] :
> https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup
> [2] :
> https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup
> [3] : https://github.com/evadot/freebsd/tree/bbb

--
Bästa Hälsningar
Oskar Holmlund
Tel 070-3220292
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Emmanuel Vadot-7
In reply to this post by Dr. Rolf Jansen-2
On Tue, 23 Jul 2019 09:22:25 -0300
"Dr. Rolf Jansen" <[hidden email]> wrote:

> > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot <[hidden email]>:
> >
> > ...
> >
> > Note that I think that this is the last time that I fix TI related problems
> > in the tree. I've spent too much time fixing BBB and Pandaboard during the
> > last 12 months and I don't even use or care about those boards. If someone
> > wants to keep them alive please invest time or money into this.
>
> You can have this quite easily. Simply revert your non-revisited batch import of 3126 files of the Linux DTS tree to the previous state (https://svnweb.freebsd.org/base?view=revision&revision=347366)
>
> Then let others import what they need file by file or snippet by snippet. By this you would be guaranteed to never be bothered agin with any BeagleBone.
>
> Best regards
>
> Rolf

 Yeah that's doesn't work.

 A lot of DTS files are shared between boards and some bindings are
even shared between arches. So you have to threat DTS as a hole.

--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Dr. Rolf Jansen-2
In reply to this post by Emmanuel Vadot-7
> Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot <[hidden email]>:
>
> On Mon, 22 Jul 2019 10:12:51 -0700
> John-Mark Gurney <[hidden email]> wrote:
>
>> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200:
>>> On Sun, 21 Jul 2019 13:55:57 -0700
>>> John-Mark Gurney <[hidden email]> wrote:
>>>
>>>> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
>>>>> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
>>>>>> The microSD card that I was using on my BeagleBone white got
>>>>>> corrupted,
>>>>>> so I decided to update to the latest version.  The latest snapshot
>>>>>> fails
>>>>>> to boot.  It loads the kernel, but then when starting the kernel, it
>>>>>> hangs, and eventually it will reset.
>>>>>>
>>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
>>>>>>
>>>>>> Any ideas?  I tried all three available 13 snaps, and they all behave
>>>>>> the same.
>>>>>>
>>>>>
>>>>> This happened with the latest DTS import (which was months ago).  A
>>>>> couple people have speculated that we just need a trivial do-nothing
>>>>> driver for the new ti,sysc device, but when I tried that a couple
>>>>> months ago it didn't work, so instead I just reverted sys/dts to the
>>>>> old source and got on with what I needed to do.
>>>>
>>>> Can we revert the dts in the tree then?  Doesn't help when we know
>>>> the fix, but don't apply it...
>>>
>>> That would be a pain for the next updates.
>>
>> Well, IMO, better than leaving a platform broken for months...
>>
>>>> Or add an overlay that undoes the changes?
>>>>
>>>> I can do some testing...
>>>
>>> Could be possible but that will probably break in a few updates of the
>>> DTS files.
>>>
>>> We need a TI maintainer that's all.
>>
>> I'd recommend we disconnect the builds then or something so that people
>> know not even to bother to try the images instead of wasting hours of
>> time trying to figure out what's wrong w/ the images...
>>
>> At least then I'd post where's the images, and you would have replied
>> that things aren't working...
>>
>>>>> This is just the latest in a years-long string of breakages because the
>>>>> linux TI folks just never stop tinkering with their device-tree source.
>>>>> I'm sure they're doing it because it gets them some benefits, but for
>>>>> us the changes add no value and have a high maintenance cost.  A hang
>>>>> before the copyright banner appears is especially painful to debug
>>>>> (doubly so because there's no existing EARLY_PRINTF support in the ti
>>>>> code).
>>>>
>>>> [...]
>>
>> --
>>  John-Mark Gurney Voice: +1 415 225 5579
>>
>>     "All that I will do, has been done, All that I have, has not."
>
> So I've unbroken the BBB.
>
> I've made two commits :
> r350229 ([1]) changes the hwmod driver to lookup the property in the
> parent node as the dts changed that.
> r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus
> like bus and for now we only threat it like if it was.
>
> But this is not enough to boot on BBB for now with the latest DTS.
> I've put on a github branch ([3]) two other commits.
>
> The first one correct the region of uart0 which isn't correct, I guess linux
> doesn't care about this as much as we do. Since this patches the DTS I want
> to start the process of upstreaming first before commiting this patch into
> our tree. I also want to update the DTS to Linux 5.2 since I want to merge
> those for 12.1 .
> The second one take care of a problem in ofw_reg_to_paddr. Since we have now
> a lot of region in the ti.sysc drivers, using only 32 pcells for the regions
> isn't enough. I've temporary bumped this value to 64 which is enough for booting
> on the BBB but we need a cleaner solution. I'll look into it soon-ish.
>
> So right now if you want to run current on BBB please take update you source tree
> and take the two patches from my github branch.
>
> Note that I think that this is the last time that I fix TI related problems
> in the tree. I've spent too much time fixing BBB and Pandaboard during the
> last 12 months and I don't even use or care about those boards. If someone
> wants to keep them alive please invest time or money into this.
>
> Thanks to ian@ for helping me with this issue.
>
> [1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup
> [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup
> [3] : https://github.com/evadot/freebsd/tree/bbb

In the course of resuming the work on a measurement controller project, whose heart is a BeagleBone Black, I updated the running FreeBSD 13.0-CURRENT r345380 (March 2019) to the latest snapshot r350103 (2019-07-18), which didn’t include your patches yet, and as expected, I experienced the BBB hanging at boot. So, I compiled a new Kernel from trunk, r350391, including your patches [1]/[2] and manually [3], and I replaced the dtb directory on the FAT partition of the BBB with the new one, which has been generated together with the kernel. Unfortunately, the BBB still hangs in the very same stage during booting up. So, nothing has been unbroken.

I tried the kernel r350103 (no „un-breaking“ patches yet) with the latest dtb, no dice either.

Now, I checked out the other stages of the sys/gnu/dts/arm directory, i.e.:

svn co -r 347365 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-5.0
svn co -r 346091 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-4.2

I rebuild the kernel r350391 having all patches applied, but after replacing sys/gnu/dts/arm by a symlink to each of the older DTS versions, respectively. DTS-5.0 did not work same hanger. However, with DTS-4.2, I saw a major advancement in the boot sequence, and the BB Black stopped only when it thought it is a Green one:

   ...
   fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 43 on simplebus0
   ti_adc0: <TI ADC controller> mem 0x44e0d000-0x44e0dfff irq 44 disabled on simplebus0
   ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0
   gpioled0: <GPIO LEDs> on ofwbus0
   gpioled0: <beaglebone:green:heartbeat> failed to map pin
   gpioled0: <beaglebone:green:mmc0> failed to map pin
   gpioled0: <beaglebone:green:usr2> failed to map pin
   gpioled0: <beaglebone:green:usr3> failed to map pin
   cryptosoft0: <software crypto>
   panic: No usable event timer found!
   cpuid = 0
   time = 1
   Uptime: 1s
   Automatic reboot in 15 seconds - press a key on the console to abort
   Rebooting...

I removed patches [1] and [3] and left the DTS-4.2 in place, then I compiled and installed another kernel+dtb, and finally, with this one, the BBB completed booting successfully without any hick-up.

Bottom line. Your patches didn’t resolve anything, but only made the situation worse. Without [1] we were at least able to refrain to the ARM-DTS-4.2, in order to get the BBB running. With [1] even this path is broken. So please revert [1], and then I happily take your word that this was the last time „that you fix TI related problems.“

Best regards

Rolf

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Emmanuel Vadot-7
On Sun, 28 Jul 2019 17:54:02 -0300
"Dr. Rolf Jansen" <[hidden email]> wrote:

> > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot <[hidden email]>:
> >
> > On Mon, 22 Jul 2019 10:12:51 -0700
> > John-Mark Gurney <[hidden email]> wrote:
> >
> >> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200:
> >>> On Sun, 21 Jul 2019 13:55:57 -0700
> >>> John-Mark Gurney <[hidden email]> wrote:
> >>>
> >>>> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
> >>>>> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
> >>>>>> The microSD card that I was using on my BeagleBone white got
> >>>>>> corrupted,
> >>>>>> so I decided to update to the latest version.  The latest snapshot
> >>>>>> fails
> >>>>>> to boot.  It loads the kernel, but then when starting the kernel, it
> >>>>>> hangs, and eventually it will reset.
> >>>>>>
> >>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
> >>>>>>
> >>>>>> Any ideas?  I tried all three available 13 snaps, and they all behave
> >>>>>> the same.
> >>>>>>
> >>>>>
> >>>>> This happened with the latest DTS import (which was months ago).  A
> >>>>> couple people have speculated that we just need a trivial do-nothing
> >>>>> driver for the new ti,sysc device, but when I tried that a couple
> >>>>> months ago it didn't work, so instead I just reverted sys/dts to the
> >>>>> old source and got on with what I needed to do.
> >>>>
> >>>> Can we revert the dts in the tree then?  Doesn't help when we know
> >>>> the fix, but don't apply it...
> >>>
> >>> That would be a pain for the next updates.
> >>
> >> Well, IMO, better than leaving a platform broken for months...
> >>
> >>>> Or add an overlay that undoes the changes?
> >>>>
> >>>> I can do some testing...
> >>>
> >>> Could be possible but that will probably break in a few updates of the
> >>> DTS files.
> >>>
> >>> We need a TI maintainer that's all.
> >>
> >> I'd recommend we disconnect the builds then or something so that people
> >> know not even to bother to try the images instead of wasting hours of
> >> time trying to figure out what's wrong w/ the images...
> >>
> >> At least then I'd post where's the images, and you would have replied
> >> that things aren't working...
> >>
> >>>>> This is just the latest in a years-long string of breakages because the
> >>>>> linux TI folks just never stop tinkering with their device-tree source.
> >>>>> I'm sure they're doing it because it gets them some benefits, but for
> >>>>> us the changes add no value and have a high maintenance cost.  A hang
> >>>>> before the copyright banner appears is especially painful to debug
> >>>>> (doubly so because there's no existing EARLY_PRINTF support in the ti
> >>>>> code).
> >>>>
> >>>> [...]
> >>
> >> --
> >>  John-Mark Gurney Voice: +1 415 225 5579
> >>
> >>     "All that I will do, has been done, All that I have, has not."
> >
> > So I've unbroken the BBB.
> >
> > I've made two commits :
> > r350229 ([1]) changes the hwmod driver to lookup the property in the
> > parent node as the dts changed that.
> > r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus
> > like bus and for now we only threat it like if it was.
> >
> > But this is not enough to boot on BBB for now with the latest DTS.
> > I've put on a github branch ([3]) two other commits.
> >
> > The first one correct the region of uart0 which isn't correct, I guess linux
> > doesn't care about this as much as we do. Since this patches the DTS I want
> > to start the process of upstreaming first before commiting this patch into
> > our tree. I also want to update the DTS to Linux 5.2 since I want to merge
> > those for 12.1 .
> > The second one take care of a problem in ofw_reg_to_paddr. Since we have now
> > a lot of region in the ti.sysc drivers, using only 32 pcells for the regions
> > isn't enough. I've temporary bumped this value to 64 which is enough for booting
> > on the BBB but we need a cleaner solution. I'll look into it soon-ish.
> >
> > So right now if you want to run current on BBB please take update you source tree
> > and take the two patches from my github branch.
> >
> > Note that I think that this is the last time that I fix TI related problems
> > in the tree. I've spent too much time fixing BBB and Pandaboard during the
> > last 12 months and I don't even use or care about those boards. If someone
> > wants to keep them alive please invest time or money into this.
> >
> > Thanks to ian@ for helping me with this issue.
> >
> > [1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup
> > [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup
> > [3] : https://github.com/evadot/freebsd/tree/bbb
>
> In the course of resuming the work on a measurement controller project, whose heart is a BeagleBone Black, I updated the running FreeBSD 13.0-CURRENT r345380 (March 2019) to the latest snapshot r350103 (2019-07-18), which didn?t include your patches yet, and as expected, I experienced the BBB hanging at boot. So, I compiled a new Kernel from trunk, r350391, including your patches [1]/[2] and manually [3], and I replaced the dtb directory on the FAT partition of the BBB with the new one, which has been generated together with the kernel. Unfortunately, the BBB still hangs in the very same stage during booting up. So, nothing has been unbroken.
>
> I tried the kernel r350103 (no ?un-breaking? patches yet) with the latest dtb, no dice either.
>
> Now, I checked out the other stages of the sys/gnu/dts/arm directory, i.e.:
>
> svn co -r 347365 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-5.0
> svn co -r 346091 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-4.2
>
> I rebuild the kernel r350391 having all patches applied, but after replacing sys/gnu/dts/arm by a symlink to each of the older DTS versions, respectively. DTS-5.0 did not work same hanger. However, with DTS-4.2, I saw a major advancement in the boot sequence, and the BB Black stopped only when it thought it is a Green one:
>
>    ...
>    fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 43 on simplebus0
>    ti_adc0: <TI ADC controller> mem 0x44e0d000-0x44e0dfff irq 44 disabled on simplebus0
>    ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0
>    gpioled0: <GPIO LEDs> on ofwbus0
>    gpioled0: <beaglebone:green:heartbeat> failed to map pin
>    gpioled0: <beaglebone:green:mmc0> failed to map pin
>    gpioled0: <beaglebone:green:usr2> failed to map pin
>    gpioled0: <beaglebone:green:usr3> failed to map pin
>    cryptosoft0: <software crypto>
>    panic: No usable event timer found!
>    cpuid = 0
>    time = 1
>    Uptime: 1s
>    Automatic reboot in 15 seconds - press a key on the console to abort
>    Rebooting...
>
> I removed patches [1] and [3] and left the DTS-4.2 in place, then I compiled and installed another kernel+dtb, and finally, with this one, the BBB completed booting successfully without any hick-up.

 In my patch that bump the cell var in ofw_reg_to_paddr I've set to 64
before pushing at the last minute, I must have not test with the right
DTB because we need more than 64 elements.
 I've pushed a new set of patches in
https://github.com/evadot/freebsd/commits/bbb_v2
 (commits 9b33b59 and 94ec550).

 I've also fixed cpsw as the slave address changed (commited in
r350410).

> Bottom line. Your patches didn?t resolve anything, but only made the situation worse. Without [1] we were at least able to refrain to the ARM-DTS-4.2, in order to get the BBB running. With [1] even this path is broken. So please revert [1], and then I happily take your word that this was the last time ?that you fix TI related problems.?

 Since it was so nicely asked I've commited a fix for this in r350408
that lookup the ti,hwmods property in the device node and fallback on
the parent.

> Best regards
>
> Rolf

 P.S. : Note that I don't know how to solve the ofw_reg_to_paddr
problem, 128 * uint32_t is really big for the kernel stack and we
cannot use malloc since it is really early in boot and we also cannot
use libfdt to lookup the data as this would only work on system that
have libfdt.
 P.S. 2: the eMMC doesn't seems to work, sdhci complain that it cannot
power the bus, this cause a big delay in boot as it is a possible root
target.

--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 13-CURRENT snapshot 20190718 r350103 doesn't boot on BeagleBone White

Emmanuel Vadot-7
On Mon, 29 Jul 2019 13:20:21 +0200
Emmanuel Vadot <[hidden email]> wrote:

> On Sun, 28 Jul 2019 17:54:02 -0300
> "Dr. Rolf Jansen" <[hidden email]> wrote:
>
> > > Am 22.07.2019 um 19:21 schrieb Emmanuel Vadot <[hidden email]>:
> > >
> > > On Mon, 22 Jul 2019 10:12:51 -0700
> > > John-Mark Gurney <[hidden email]> wrote:
> > >
> > >> Emmanuel Vadot wrote this message on Mon, Jul 22, 2019 at 10:26 +0200:
> > >>> On Sun, 21 Jul 2019 13:55:57 -0700
> > >>> John-Mark Gurney <[hidden email]> wrote:
> > >>>
> > >>>> Ian Lepore wrote this message on Sun, Jul 21, 2019 at 12:31 -0600:
> > >>>>> On Sun, 2019-07-21 at 11:05 -0700, John-Mark Gurney wrote:
> > >>>>>> The microSD card that I was using on my BeagleBone white got
> > >>>>>> corrupted,
> > >>>>>> so I decided to update to the latest version.  The latest snapshot
> > >>>>>> fails
> > >>>>>> to boot.  It loads the kernel, but then when starting the kernel, it
> > >>>>>> hangs, and eventually it will reset.
> > >>>>>>
> > >>>>>> The latest 12 snapshot boots fine: BEAGLEBONE-20190718-r350087.
> > >>>>>>
> > >>>>>> Any ideas?  I tried all three available 13 snaps, and they all behave
> > >>>>>> the same.
> > >>>>>>
> > >>>>>
> > >>>>> This happened with the latest DTS import (which was months ago).  A
> > >>>>> couple people have speculated that we just need a trivial do-nothing
> > >>>>> driver for the new ti,sysc device, but when I tried that a couple
> > >>>>> months ago it didn't work, so instead I just reverted sys/dts to the
> > >>>>> old source and got on with what I needed to do.
> > >>>>
> > >>>> Can we revert the dts in the tree then?  Doesn't help when we know
> > >>>> the fix, but don't apply it...
> > >>>
> > >>> That would be a pain for the next updates.
> > >>
> > >> Well, IMO, better than leaving a platform broken for months...
> > >>
> > >>>> Or add an overlay that undoes the changes?
> > >>>>
> > >>>> I can do some testing...
> > >>>
> > >>> Could be possible but that will probably break in a few updates of the
> > >>> DTS files.
> > >>>
> > >>> We need a TI maintainer that's all.
> > >>
> > >> I'd recommend we disconnect the builds then or something so that people
> > >> know not even to bother to try the images instead of wasting hours of
> > >> time trying to figure out what's wrong w/ the images...
> > >>
> > >> At least then I'd post where's the images, and you would have replied
> > >> that things aren't working...
> > >>
> > >>>>> This is just the latest in a years-long string of breakages because the
> > >>>>> linux TI folks just never stop tinkering with their device-tree source.
> > >>>>> I'm sure they're doing it because it gets them some benefits, but for
> > >>>>> us the changes add no value and have a high maintenance cost.  A hang
> > >>>>> before the copyright banner appears is especially painful to debug
> > >>>>> (doubly so because there's no existing EARLY_PRINTF support in the ti
> > >>>>> code).
> > >>>>
> > >>>> [...]
> > >>
> > >> --
> > >>  John-Mark Gurney Voice: +1 415 225 5579
> > >>
> > >>     "All that I will do, has been done, All that I have, has not."
> > >
> > > So I've unbroken the BBB.
> > >
> > > I've made two commits :
> > > r350229 ([1]) changes the hwmod driver to lookup the property in the
> > > parent node as the dts changed that.
> > > r350230 ([2]) adds a new driver for the ti,sysc bus. It's a simplebus
> > > like bus and for now we only threat it like if it was.
> > >
> > > But this is not enough to boot on BBB for now with the latest DTS.
> > > I've put on a github branch ([3]) two other commits.
> > >
> > > The first one correct the region of uart0 which isn't correct, I guess linux
> > > doesn't care about this as much as we do. Since this patches the DTS I want
> > > to start the process of upstreaming first before commiting this patch into
> > > our tree. I also want to update the DTS to Linux 5.2 since I want to merge
> > > those for 12.1 .
> > > The second one take care of a problem in ofw_reg_to_paddr. Since we have now
> > > a lot of region in the ti.sysc drivers, using only 32 pcells for the regions
> > > isn't enough. I've temporary bumped this value to 64 which is enough for booting
> > > on the BBB but we need a cleaner solution. I'll look into it soon-ish.
> > >
> > > So right now if you want to run current on BBB please take update you source tree
> > > and take the two patches from my github branch.
> > >
> > > Note that I think that this is the last time that I fix TI related problems
> > > in the tree. I've spent too much time fixing BBB and Pandaboard during the
> > > last 12 months and I don't even use or care about those boards. If someone
> > > wants to keep them alive please invest time or money into this.
> > >
> > > Thanks to ian@ for helping me with this issue.
> > >
> > > [1] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_hwmods.c?revision=350229&view=markup
> > > [2] : https://svnweb.freebsd.org/base/head/sys/arm/ti/ti_sysc.c?revision=350230&view=markup
> > > [3] : https://github.com/evadot/freebsd/tree/bbb
> >
> > In the course of resuming the work on a measurement controller project, whose heart is a BeagleBone Black, I updated the running FreeBSD 13.0-CURRENT r345380 (March 2019) to the latest snapshot r350103 (2019-07-18), which didn?t include your patches yet, and as expected, I experienced the BBB hanging at boot. So, I compiled a new Kernel from trunk, r350391, including your patches [1]/[2] and manually [3], and I replaced the dtb directory on the FAT partition of the BBB with the new one, which has been generated together with the kernel. Unfortunately, the BBB still hangs in the very same stage during booting up. So, nothing has been unbroken.
> >
> > I tried the kernel r350103 (no ?un-breaking? patches yet) with the latest dtb, no dice either.
> >
> > Now, I checked out the other stages of the sys/gnu/dts/arm directory, i.e.:
> >
> > svn co -r 347365 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-5.0
> > svn co -r 346091 https://svn.freebsd.org/base/head/sys/gnu/dts/arm arm-4.2
> >
> > I rebuild the kernel r350391 having all patches applied, but after replacing sys/gnu/dts/arm by a symlink to each of the older DTS versions, respectively. DTS-5.0 did not work same hanger. However, with DTS-4.2, I saw a major advancement in the boot sequence, and the BB Black stopped only when it thought it is a Green one:
> >
> >    ...
> >    fb0: <AM335x LCD controller> mem 0x4830e000-0x4830efff irq 43 on simplebus0
> >    ti_adc0: <TI ADC controller> mem 0x44e0d000-0x44e0dfff irq 44 disabled on simplebus0
> >    ti_adc0: scheme: 0x1 func: 0x730 rtl: 0 rev: 0.1 custom rev: 0
> >    gpioled0: <GPIO LEDs> on ofwbus0
> >    gpioled0: <beaglebone:green:heartbeat> failed to map pin
> >    gpioled0: <beaglebone:green:mmc0> failed to map pin
> >    gpioled0: <beaglebone:green:usr2> failed to map pin
> >    gpioled0: <beaglebone:green:usr3> failed to map pin
> >    cryptosoft0: <software crypto>
> >    panic: No usable event timer found!
> >    cpuid = 0
> >    time = 1
> >    Uptime: 1s
> >    Automatic reboot in 15 seconds - press a key on the console to abort
> >    Rebooting...
> >
> > I removed patches [1] and [3] and left the DTS-4.2 in place, then I compiled and installed another kernel+dtb, and finally, with this one, the BBB completed booting successfully without any hick-up.
>
>  In my patch that bump the cell var in ofw_reg_to_paddr I've set to 64
> before pushing at the last minute, I must have not test with the right
> DTB because we need more than 64 elements.
>  I've pushed a new set of patches in
> https://github.com/evadot/freebsd/commits/bbb_v2
>  (commits 9b33b59 and 94ec550).
>
>  I've also fixed cpsw as the slave address changed (commited in
> r350410).
>
> > Bottom line. Your patches didn?t resolve anything, but only made the situation worse. Without [1] we were at least able to refrain to the ARM-DTS-4.2, in order to get the BBB running. With [1] even this path is broken. So please revert [1], and then I happily take your word that this was the last time ?that you fix TI related problems.?
>
>  Since it was so nicely asked I've commited a fix for this in r350408
> that lookup the ti,hwmods property in the device node and fallback on
> the parent.
>
> > Best regards
> >
> > Rolf
>
>  P.S. : Note that I don't know how to solve the ofw_reg_to_paddr
> problem, 128 * uint32_t is really big for the kernel stack and we
> cannot use malloc since it is really early in boot and we also cannot
> use libfdt to lookup the data as this would only work on system that
> have libfdt.
>  P.S. 2: the eMMC doesn't seems to work, sdhci complain that it cannot
> power the bus, this cause a big delay in boot as it is a possible root
> target.

 Also I've submitted a patch upstream for the DTS region size, I'm
waiting on having a feedback to commit it in our tree.

 https://www.spinics.net/lists/devicetree/msg299750.html
 https://www.spinics.net/lists/devicetree/msg299751.html

--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"