U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

[Robert Nelson]

Okay, i have a version of u-boot with overlays enabled, ready for some
basic testing..

*************Background***************************************

in u-boot we are doing:

dtb= is loaded at ${fdtaddr}

We read /boot/uEnv.txt for (dtb_overlay=<path/file.dtbo>)

then load it, into ${rdaddr} #(no reason that specific address)

Then we must run thru this routine:

fdt addr ${fdtaddr}
fdt resize;
fdt apply ${rdaddr}
fdt resize;

Without the "fdt resize, the jump to kernel bomb's in bootz."

*****************************************************************

*************Actual testing...***************************************

Step 1: Do you have a usb serial adapter to monitor the boot process?

no = stop reading now... till you have one in hand...
yes = please continue

Step 2: Remove /uEnv.txt (i forgot to code that path in this test)

rm /uEnv.txt

Step 3: Update u-boot to v2017.01-rc2

cd /opt/scripts/tools/developers/
git pull
./update_bootloader.sh --use-beta-bootloader

On reboot, it should show:

U-Boot SPL 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21)
Trying to boot from MMC1

U-Boot 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
Build: jenkins-github_Bootloader-Builder-493

If not, eMMC probably messing with you..

dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Step 4: /boot/uEnv.txt

remove "cape_universal=enable" we dont want any false posititves...

dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo

before:
kernel:
root@beaglebone:~# dmesg | grep serial
[ 2.082007] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
base_baud = 3000000) is a 8250
[ 2.096583] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 159,
base_baud = 3000000) is a 8250
[ 20.106023] systemd[1]: Created slice system-serial\x2dgetty.slice.

after:
U-Boot:
loading /boot/dtbs/4.4.39-ti-r75/am335x-boneblack-wireless.dtb ...
64988 bytes read in 163 ms (388.7 KiB/s)
debug: [dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo] ...
loading /lib/firmware/BB-UART2-00A0.dtbo ...
883 bytes read in 276 ms (2.9 KiB/s)

kernel:
root@beaglebone:~# dmesg | grep serial
[ 2.081559] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
base_baud = 3000000) is a 8250
[ 2.095942] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159,
base_baud = 3000000) is a 8250
[ 2.096807] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 160,
base_baud = 3000000) is a 8250
[ 20.316939] systemd[1]: Created slice system-serial\x2dgetty.slice.

Step 5: Profit!!! ;)

*****************************************************************

I know it's a little limited, but something for testing over Christmas. ;)

FAQ:

What does this solve? Lots of random kernel races... (looking at
video/emmc/etc)... As U-Boot updates the final *.dtb and not the
kernel...

What about 2+ overlays? Maybe next week, for Christmas you get one.. ;)

Does this replace the current method? No it just improves things..

What have you tested it on? Just BB-UART2-00A0.dtbo and then i wrote
this email up and got ready to go home...

Will it read the eeprom and auto load the correct overlay? Sure,
sometime between next week and the start of the new year... ;)

Will this fix the issue with the painful out of box experience with
LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. ;)

How do i actually test things?

Easiest, /boot/uEnv.txt

dtb=am335x-boneblack-overlay.dtb
dtb_overlay=/lib/firmware/xyz.dtbo

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

Robert,

So, I have a custom overlay for a physical custom cape . . . as of this moment, I have a few gpio's( I think around 22 ish ), 6 PWM's,, and eventually I can put an ADC into that same overlay. Right, now for the ADC I'm just loading the "stock" ADC overlay for ADC functionality. Additionally, in the future I may also need to add uart4 back into the mix. For now, our current cape no longer needs uart.

The question I have is . . . Would this improve anything for us ? Right now, I just load the custom overlay through initramfs, which also seems fine. For this project we do not really have a need for an LCD, but that might change in the future. At least for *some* hardware configurations.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiSVX8-koZ2DFH36xUqEAcSwDn%2Btv8phoYDE8O-tpvUXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Fri, Dec 23, 2016 at 5:46 PM, William Hermans <yyr...@gmail.com> wrote:
> Robert,
>
> So, I have a custom overlay for a physical custom cape . . . as of this
> moment, I have a few gpio's( I think around 22 ish ), 6 PWM's,, and
> eventually I can put an ADC into that same overlay. Right, now for the ADC
> I'm just loading the "stock" ADC overlay for ADC functionality.
> Additionally, in the future I may also need to add uart4 back into the mix.
> For now, our current cape no longer needs uart.
>
> The question I have is . . . Would this improve anything for us ? Right now,
> I just load the custom overlay through initramfs, which also seems fine. For
> this project we do not really have a need for an LCD, but that might change
> in the future. At least for *some* hardware configurations.

For those interfaces, there's not a lot of overlay loading issues on
the kernel side. The biggest change, you should see your pin's taken
earlier and more consistently at bootup. You can also optimize your
boot time more, as one of the big reasons everything we have is built
as a module, is just too make the kernel overlays work more reliable.

[William Hermans]

On Fri, Dec 23, 2016 at 5:58 PM, Robert Nelson <robert...@gmail.com> wrote:

For those interfaces, there's not a lot of overlay loading issues on
the kernel side.  The biggest change, you should see your pin's taken
earlier and more consistently at bootup.  You can also optimize your
boot time more, as one of the big reasons everything we have is built
as a module, is just too make the kernel overlays work more reliable.

I wonder if this will help mitigate, at least *some* of the big boot "lag" waiting on network interfaces to come up. That alone, if so, would be a huge plus.

Anyway, the steps you've listed above will work on emmc as well as sdcard ?

Additionally, although perhaps not related to this per se. I'd really like to see some sort of boot options where "we" did not have to write an environment file for the sdcard *if* we just wanted to boot from the emmc, but would like an sdcard inserted for extra storage. That is, without having to hack the second stage bootloader. Or is that a big deal for you guys ? You know, I'm not even sure how that would work . . .honestly this just popped into my head right now.

[Robert Nelson]

On Fri, Dec 23, 2016 at 7:08 PM, William Hermans <yyr...@gmail.com> wrote:
>
>
> On Fri, Dec 23, 2016 at 5:58 PM, Robert Nelson <robert...@gmail.com>
> wrote:
>>
>> For those interfaces, there's not a lot of overlay loading issues on
>> the kernel side. The biggest change, you should see your pin's taken
>> earlier and more consistently at bootup. You can also optimize your
>> boot time more, as one of the big reasons everything we have is built
>> as a module, is just too make the kernel overlays work more reliable.
>
>
> I wonder if this will help mitigate, at least *some* of the big boot "lag"
> waiting on network interfaces to come up. That alone, if so, would be a huge
> plus.

the cpsw/eth0 is just broken. ;) i saw on github (irc zmatt) was looking at it:

https://github.com/dutchanddutch/bb-kernel/commit/0c720957b43a8cea423b80e9fa8772ddb41c186c

> Anyway, the steps you've listed above will work on emmc as well as sdcard ?

it should, it's looking in the /boot/uEnv.txt file..

> Additionally, although perhaps not related to this per se. I'd really like
> to see some sort of boot options where "we" did not have to write an
> environment file for the sdcard *if* we just wanted to boot from the emmc,
> but would like an sdcard inserted for extra storage. That is, without having
> to hack the second stage bootloader. Or is that a big deal for you guys ?
> You know, I'm not even sure how that would work . . .honestly this just
> popped into my head right now.

ah, just don't have /uEnv.txt, /boot.scr, /boot/boot.scr in the 1st
partition, or /boot/uEnv.txt in any of the first 7 partitions and
it'll ignore the microSD..

[William Hermans]

On Fri, Dec 23, 2016 at 6:15 PM, Robert Nelson <robert...@gmail.com> wrote:

the cpsw/eth0 is just broken. ;)  i saw on github (irc zmatt) was looking at it:

https://github.com/dutchanddutch/bb-kernel/commit/0c720957b43a8cea423b80e9fa8772ddb41c186c

hmmm, I wonder if that works ? Matthijs hehe I should have known.

ah, just don't have /uEnv.txt, /boot.scr, /boot/boot.scr in the 1st
partition, or /boot/uEnv.txt in any of the first 7 partitions and
it'll ignore the microSD..

Ah, ok, sounds like it's been around a while and I just haven't realized. Thanks for the answers, and have a great Christmas !

[vba...@yahoo.com]

--------------------------------------------
On Sat, 12/24/16, Robert Nelson <robert...@gmail.com> wrote:

Subject: Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)
To: "Beagle Board" <beagl...@googlegroups.com>
Date: Saturday, December 24, 2016, 3:15 AM

On Fri, Dec 23, 2016 at 7:08 PM,
William Hermans <yyr...@gmail.com>
wrote:
>
>

> On Fri, Dec 23, 2016 at 5:58 PM, Robert Nelson <robert...@gmail.com>
> wrote:
>>
>> For those interfaces, there's not a lot of overlay
loading issues on
>> the kernel side.  The biggest change, you
should see your pin's taken
>> earlier and more consistently at bootup.  You
can also optimize your
>> boot time more, as one of the big reasons
everything we have is built
>> as a module, is just too make the kernel overlays
work more reliable.
>
>
> I wonder if this will help mitigate, at least *some* of
the big boot "lag"
> waiting on network interfaces to come up. That alone,
if so, would be a huge
> plus.

the cpsw/eth0 is just broken. ;)  i saw on github (irc
zmatt) was looking at it:

https://github.com/dutchanddutch/bb-kernel/commit/0c720957b43a8cea423b80e9fa8772ddb41c186c

> Anyway, the steps you've listed above will work on emmc
as well as sdcard ?

it should, it's looking in the /boot/uEnv.txt file..

> Additionally, although perhaps not related to this per
se. I'd really like
> to see some sort of boot options where "we" did not
have to write an
> environment file for the sdcard *if* we just wanted to
boot from the emmc,
> but would like an sdcard inserted for extra storage.
That is, without having
> to hack the second stage bootloader. Or is that a big
deal for you guys ?
> You know, I'm not even sure how that would work . .
.honestly this just
> popped into my head right now.

ah, just don't have /uEnv.txt, /boot.scr, /boot/boot.scr in
the 1st
partition, or /boot/uEnv.txt in any of the first 7
partitions and
it'll ignore the microSD..

Regards,

--
Robert Nelson
https://rcn-ee.com/

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the
Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails

from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/beagleboard/CAOCHtYg%3D4gs7OFOmfTb9cr9_p6ViUWQkqC3zDG_t_ESOXmaALA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

2 ian. 3 febr. - Primul guvern al Romaniei prezidat de Barbu Catargiu. 24 ian. 5 febr. - Parlamentul Romaniei proclama Unirea si stabileste Bucurestiul drept capitala a tarii. 25 mai - Mihail Kogalniceanu cere intr-un discurs parlamentar rezolvarea problemei agrare. t 8 20 ian. - Este asasinat in conditii neelucidate Barbu Catargiu. 11 23 iun. - Adunarea voteaza proiectul de lege rurala propus de Comisia Centrala de la Focsani Cuza refuza insa sa il aprobe nov. dec. - Are loc tranzitul armelor sarbesti prin Romania in ciuda protestelor Marilor Puteri.18627 apr. - Conventie intre Anglia si S.U.A. privind interzicerea comertului cu sclavi. 22 sept. - Eliberarea negrilor din scalvie in S.U.A. - Otto von Bismarck devine presedinte al Consiliului de Ministri al Prusiei.

[Rick Mann]

> On Dec 23, 2016, at 16:58 , Robert Nelson <robert...@gmail.com> wrote:
>
> For those interfaces, there's not a lot of overlay loading issues on
> the kernel side. The biggest change, you should see your pin's taken
> earlier and more consistently at bootup. You can also optimize your
> boot time more, as one of the big reasons everything we have is built
> as a module, is just too make the kernel overlays work more reliable.

Are these changes in the most recent distros, Robert?

--
Rick Mann
rm...@latencyzero.com

[Robert Nelson]

These changes are only 6 hours old, you must have missed the first post with all the details.

Regards,

[William Hermans]

So . . .

What ?!?

Ok, so I have zero problems testing. But what I do have problems with is understanding how to get from point A to point B

Exact steps, with no "mumbo jumbo" in between.

So first, will this work with the latest "stable" image ? If so, why would I want to destroy the partition table of the only boot-able partition ? I would actually want the partition table intact so I can make these changes while reflecting those same changes.on the boot able "image" / file system.

[William Hermans]

By the way, I could test with 3 different boards. and A5A, an Element14 RevC, and an BBG.

[Robert Nelson]

Like those posted?

> So first, will this work with the latest "stable" image ?

Yes.

> If so, why would I
> want to destroy the partition table of the only boot-able partition ?

Explained by the "if not" in step 3...

> I
> would actually want the partition table intact so I can make these changes
> while reflecting those same changes.on the boot able "image" / file system.

[Robert Nelson]

On Wed, Dec 28, 2016 at 4:07 AM, William Hermans <yyr...@gmail.com> wrote:
> By the way, I could test with 3 different boards. and A5A, an Element14
> RevC, and an BBG.

This patch/test is not about the base board's..

This is about capes.. Especially the LCD capes...

[William Hermans]

So what you're telling me that testing for different boards is irrelevant ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYjRPnK4OK5OJKPFEkwFxSkQgSSO5Jhd7K15%2BRxy_X-jtg%40mail.gmail.com.

[William Hermans]

My point was that . . .

on reboot, it should show:

U-Boot SPL 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21)
Trying to boot from MMC1

U-Boot 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600),
Build: jenkins-github_Bootloader-Builder-493

If not, eMMC probably messing with you..

dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Is a bit heavy handed, and perhaps a bit too overboard.

[Robert Nelson]

On Wed, Dec 28, 2016 at 9:10 AM, William Hermans <yyr...@gmail.com> wrote:
> So what you're telling me that testing for different boards is irrelevant ?

That is correct. This feature has been enabled in our version of
u-boot since last October or so... So we know those boards work.

Just finally figured out the missing piece to actually load an overlay
on top of the main dtb..

[William Hermans]

On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <robert...@gmail.com> wrote:

On Wed, Dec 28, 2016 at 9:10 AM, William Hermans <yyr...@gmail.com> wrote:
> So what you're telling me that testing for different boards is irrelevant ?

That is correct.  This feature has been enabled in our version of
u-boot since last October or so...  So we know those boards work.

Just finally figured out the missing piece to actually load an overlay
on top of the main dtb..

sweet. Do tell ;)

[Robert Nelson]

"fdt resize"

[William Hermans]

Well, I'm not sure why I should be testing then. I do not have an LCD cape, and probably never will. But I figured I could test my custom cape at boot *AFTER* I get something like 1-wire to load at boot. e.g. the is infinitely easier to test, and something I could also test in hardware right away.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgemJazx%3Dg2qndYNmGF%2BPs%2BK%3DAE47_Z6Vv6H03kYJO%3D6A%40mail.gmail.com.

[William Hermans]

Ok so from a fresh emmc flashing( slightly modified rootfs on the flasher image)

debian@beaglebone:~$ rm /uEnv.txt
rm: cannot remove '/uEnv.txt': No such file or directory

debian@beaglebone:~$ sudo apt-get update
debian@beaglebone:~$ sudo apt-get install git

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
debian@beaglebone:/opt/scripts/tools/developers$ sudo ./update_bootloader.sh --use-beta-bootloader
debian@beaglebone:/opt/scripts/tools/developers$ sudo reboot

U-Boot 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600), Build: jenkins-github_Bootloader-Builder-493

debian@beaglebone:~$ sudo nano /boot/uEnv.txt
    ##BeagleBone Black: HDMI (Audio/Video) disabled:
    dtb=am335x-boneblack-emmc-overlay.dtb
    dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo

    cmdline=coherent_pool=1M quiet

debian@beaglebone:~$ sudo reboot
debian@beaglebone:~$ cat /sys/bus/w1/devices/28-00000647ddf6/w1_slave
0b 01 4b 46 7f ff 05 10 a8 : crc=a8 YES
0b 01 4b 46 7f ff 05 10 a8 t=16687


One minor thing of concern - "evm" :

Are you 100% sure, on selecting [am335x_evm] (y/n)? y
log: dd if=/tmp/tmp.HPy1G6iV9J/dl/MLO-am335x_evm-v2017.01-rc2-r4 of=/dev/mmcblk0 seek=1 bs=128k
0+1 records in
0+1 records out
68504 bytes (69 kB) copied, 0.00287351 s, 23.8 MB/s
log: dd if=/tmp/tmp.HPy1G6iV9J/dl/u-boot-am335x_evm-v2017.01-rc2-r4.img of=/dev/mmcblk0 seek=1 bs=384k

[William Hermans]

Robert,

Have you created a script that removes all the unnecessary kernel modules loaded superfluously at boot ? I mean there are a lot of them, and I'd say that 99% of them in most cases will just be wasting a lot of memory . . .

[William Hermans]

Anyway, this is pretty slick. How long do you figure it'll take before this functionality come into the default uboot ?

[Robert Nelson]

On Wed, Dec 28, 2016 at 5:27 PM, William Hermans <yyr...@gmail.com> wrote:
> Anyway, this is pretty slick. How long do you figure it'll take before this
> functionality come into the default uboot ?

Oh pretty quickly in the current version..

But i want to add the whole cape eeprom parser to u-boot..

That'll take more time..

[chao...@yahoo.com]

--------------------------------------------

On Thu, 12/29/16, William Hermans <yyr...@gmail.com> wrote:

Subject: Re: [beagleboard] U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

To: beagl...@googlegroups.com, "Robert Nelson" <robert...@gmail.com>
Date: Thursday, December 29, 2016, 1:27 AM

Anyway, this is
pretty slick. How long do you figure it'll take before
this functionality come into the default uboot ?

On Wed, Dec 28, 2016

at 9:36 AM, William Hermans <yyr...@gmail.com>
wrote:
Robert,

Have you created a script that removes all the
unnecessary kernel modules loaded superfluously at boot ? I
mean there are a lot of them, and I'd say that 99% of
them in most cases will just be wasting a lot of memory . .
.

On Wed, Dec 28, 2016

On Wed, Dec 28, 2016

at 8:52 AM, William Hermans <yyr...@gmail.com>
wrote:
Well, I'm not sure why I should be testing
then. I do not have an LCD cape, and probably never will.
But I figured I could test my custom cape at boot *AFTER* I
get something like 1-wire to load at boot. e.g. the is
infinitely easier to test, and something I could also test
in hardware right away.

On Wed, Dec 28, 2016

at 8:27 AM, Robert Nelson <robert...@gmail.com>
wrote:

On

Wed, Dec 28, 2016 at 9:25 AM, William Hermans <yyr...@gmail.com>
wrote:

> On Wed, Dec 28, 2016 at 8:23 AM, Robert Nelson <robert...@gmail.com>

> wrote:

>>

>> On Wed, Dec 28, 2016 at 9:10 AM, William Hermans
<yyr...@gmail.com>

>> wrote:

>> > So what you're telling me that testing for
different boards is

>> > irrelevant ?

>>

>> That is correct.  This feature has been enabled in
our version of

>> u-boot since last October or so...  So we know
those boards work.

>>

>> Just finally figured out the missing piece to
actually load an overlay

>> on top of the main dtb..

>

>

> sweet. Do tell ;)



"fdt resize"

Regards,



--

Robert Nelson

https://rcn-ee.com/

--

For more options, visit http://beagleboard.org/discuss

---

You received this message because you are subscribed to the
Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails
from it, send an email to beagleboard+unsubscribe@google
groups.com.

To view this discussion on the web visit https://groups.google.com/d/ms
gid/beagleboard/CAOCHtYgemJazx
%3Dg2qndYNmGF%2BPs%2BK%3DAE47_
Z6Vv6H03kYJO%3D6A%40mail.gmail .com.

For
more options, visit https://groups.google.com/d/op
tout.












--

For more options, visit http://beagleboard.org/discuss

---

You received this message because you are subscribed to the
Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails

from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpa-OLfZLFc1nshG541EBqfCtGX%3DT7J5DgHY1-pnmY4Bw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

sistenta unui popor insa nu se discuta se afirma

[evilwulfie]

why does this person repost these emails without adding any comments ? ?

[Gerald Coley]

>  from it, send an email to beagleboard+unsubscribe@googlegroups.com.

>
>  To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpa-OLfZLFc1nshG541EBqfCtGX%3DT7J5DgHY1-pnmY4Bw%40mail.gmail.com.
>
>  For more options, visit https://groups.google.com/d/optout.
>  sistenta unui popor insa nu se discuta se afirma
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ee7e4fc0-d252-421d-c38c-9eb3c1cb6aee%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Gerald

 

ger...@beagleboard.org

http://beagleboard.org/

gco...@emprodesign.com

[Gerald Coley]

Well, I don't know. Seems like some people will set an out of office and respond with Spam. I guess this is a new thing.

Gerald

On Wed, Dec 28, 2016 at 7:31 PM, evilwulfie <evilw...@gmail.com> wrote:

>  from it, send an email to beagleboard+unsubscribe@googlegroups.com.

>
>  To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpa-OLfZLFc1nshG541EBqfCtGX%3DT7J5DgHY1-pnmY4Bw%40mail.gmail.com.
>
>  For more options, visit https://groups.google.com/d/optout.
>  sistenta unui popor insa nu se discuta se afirma
>

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ee7e4fc0-d252-421d-c38c-9eb3c1cb6aee%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

[William Hermans]

Someone, it seems, I've already added to my "block list".

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAHK_S%2BdSfCbsOeirvzeByR7aCgkHpu_NhghjQQP5R_5Q2ZtxZg%40mail.gmail.com.

[Robert Nelson]

On Wed, Dec 28, 2016 at 7:33 PM, Gerald Coley <ger...@beagleboard.org> wrote:
> Well, I don't know. Seems like some people will set an out of office and
> respond with Spam. I guess this is a new thing.

they show up as:

"chao.ruth via BeagleBoard <beagl...@googlegroups.com>"

So they must be coming thru the web interface.

[Gerald Coley]

I set them to moderated. Let's see what happens.

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiZf%3DvZnQ88dEzujbjghMpYb_7WZgtv6kbSJGgCzjY6Cg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Matthijs van Duin]

On Fri, Dec 23, 2016 at 6:15 PM, Robert Nelson <robert...@gmail.com> wrote:

the cpsw/eth0 is just broken. ;)  i saw on github (irc zmatt) was looking at it

While I don't exclude the possibility that the cpsw driver might be crappy (haven't really looked at it much), the blame here actually lies with linux itself, which unconditionally resets the phy.

Latest version of the patch:

https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.9/patches/local/0003-WiP-trying-to-achieve-fast-link-up-at-boot.patch

 

On Saturday, 24 December 2016 02:27:13 UTC+1, William Hermans wrote:

hmmm, I wonder if that works ?

If you had Cc'd me then you wouldn't have needed to wonder :-)

I'm not going to pretend it's an elegant patch, but we've been using it for months now on all our beaglebones and it appears to work like a charm:

[    5.548658] alexje kernel: net eth0: initializing cpsw version 1.12 (0)

[    5.551254] alexje kernel: SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=-1)

[    5.551903] alexje kernel: cpsw 4a100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

[    5.593833] alexje systemd-networkd[105]: eth0: Gained carrier

Matthijs