Issues with Debian Stretch Image on BeagleBoard-X15
176 views
Skip to first unread message
Kumar Abhishek
Jun 25, 2017, 12:45:20 PM6/25/17
to Beagle Board, Robert Nelson
I have two issues working with the latest BeagleBoard Stretch image on the BeagleBoard X15. ( I used image under both https://rcn-ee.net/rootfs/bb.org/testing/2017-06-22/stretch-lxqt/ and https://rcn-ee.net/rootfs/bb.org/testing/2017-06-18/stretch-lxqt/ )
1. The bootup from microSD card containing the image happens only after roughly 3-4 minutes, the board is unresponsive until then. I don't know why this is happening but this did not happen with a Jessie image ( the board boots immediately )
2. The syslog is getting spammed with log messages like this, and it fills up the entire space on the microSD card, to the point I can no longer do anything:
[ 4906.387892] alloc_contig_range: [fceb1, fceb2) PFNs busy
[ 4906.387951] alloc_contig_range: [fceb2, fceb3) PFNs busy
[ 4906.388082] alloc_contig_range: [fceb3, fceb4) PFNs busy
[ 4906.388152] alloc_contig_range: [fceb4, fceb5) PFNs busy
[ 4906.388251] alloc_contig_range: [fceb5, fceb6) PFNs busy
[ 4906.388307] alloc_contig_range: [fceb6, fceb7) PFNs busy
[ 4906.540999] alloc_contig_range: [fceb0, fceb1) PFNs busy
[ 4906.541076] alloc_contig_range: [fceb1, fceb2) PFNs busy
[ 4906.541135] alloc_contig_range: [fceb2, fceb3) PFNs busy
[ 4906.541195] alloc_contig_range: [fceb3, fceb4) PFNs busy
[ 4906.541253] alloc_contig_range: [fceb4, fceb5) PFNs busy
[ 4906.541311] alloc_contig_range: [fceb5, fceb6) PFNs busy
[ 4906.541369] alloc_contig_range: [fceb6, fceb7) PFNs busy
[ 4906.549392] alloc_contig_range: [fceb0, fceb1) PFNs busy
[ 4906.549539] alloc_contig_range: [fceb1, fceb2) PFNs busy
[ 4906.549599] alloc_contig_range: [fceb2, fceb3) PFNs busy
[ 4906.549654] alloc_contig_range: [fceb3, fceb4) PFNs busy
[ 4906.549708] alloc_contig_range: [fceb4, fceb5) PFNs busy
[ 4906.549762] alloc_contig_range: [fceb5, fceb6) PFNs busy
[ 4906.549816] alloc_contig_range: [fceb6, fceb7) PFNs busy
I wanted to bring these to your notice.
Thanks
Kumar Abhishek
Robert Nelson
Jun 25, 2017, 1:40:21 PM6/25/17
to Kumar Abhishek, Beagle Board
Hi Kumar, what do you have plugged in? Which rev of the x15? I had tested this image on Friday, it was working for me on the new x15 (sr 2.0 silicon)
Regards,
Kumar Abhishek
Jun 26, 2017, 3:15:11 AM6/26/17
to Robert Nelson, Beagle Board
I have Rev A2 of the X15, and the kernel logs say that it is a DRA752 ES1.1 silicon.On Sun, Jun 25, 2017 at 11:09 PM, Robert Nelson <robert...@gmail.com> wrote:
Hi Kumar, what do you have plugged in? Which rev of the x15? I had tested this image on Friday, it was working for me on the new x15 (sr 2.0 silicon)Regards,
Kumar Abhishek
Jun 26, 2017, 7:08:51 AM6/26/17
to Robert Nelson, Beagle Board
1. Using a serial console, I get the following output:----------------------------------
U-Boot SPL 2017.01-00341-gb2aad42503 (Jun 21 2017 - 10:56:05)
DRA752-GP ES1.1
Trying to boot from MMC1
** Unable to use mmc 0:1 for loading the env **
Using default environment
U-Boot 2017.01-00341-gb2aad42503 (Jun 21 2017 - 10:56:05 -0500), Build: jenkins-github_Bootloader-Builder-581
CPU : DRA752-GP ES1.1
Model: TI AM5728 BeagleBoard-X15
Board: BeagleBoard X15 REV A.20
DRAM: 2 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
** Unable to use mmc 0:1 for loading the env **
Using default environment
setup_board_eeprom_env: beagle_x15
SCSI: SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw
Press SPACE to abort autoboot in 2 seconds
usb_boot is currently disabled
scsi_boot is currently disabled
switch to partitions #0, OK
mmc0 is current device
Scanning mmc device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
445 bytes read in 395 ms (1000 Bytes/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt ...
debug: [uname_r=4.9.33-ti-r42] ...
loading /boot/vmlinuz-4.9.33-ti-r42 ...
9530640 bytes read in 96459 ms (95.7 KiB/s)
loading /boot/dtbs/4.9.33-ti-r42/am57xx-beagle-x15.dtb ...
152761 bytes read in 1969 ms (75.2 KiB/s)
loading /boot/initrd.img-4.9.33-ti-r42 ...
5913007 bytes read in 59990 ms (95.7 KiB/s)
debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] ...
debug: [bootz 0x82000000 0x88080000:5a39af 0x88000000] ...
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8fa5c000, end 8ffff9af ... OK
Loading Device Tree to 8fa33000, end 8fa5b4b8 ... OK
Starting kernel ...
----------------------------------------------------
It seems that the loading of the kernel and initrd from the SD card is rather slow (95KB/s), wonder why.
2.
Also, the second issue (alloc_contig_range) seems to happen about 1000 seconds in after the system boots. These messages start slow initially (once every 30 seconds or so) but become more frequent with time, until they block everything.
Kumar Abhishek
Jun 27, 2017, 5:23:13 AM6/27/17
to Robert Nelson, Beagle Board
1. Update: Switching to a different SD card solves the boot time being long2. Doing 'sudo service lightdm stop' seems to stop the "alloc_contig_range" spam in the kernel log, suggesting it might have something to do with the X server (?)
Kumar Abhishek
Jun 27, 2017, 6:58:55 AM6/27/17
to Robert Nelson, Beagle Board
I found some other people report the same issue 'alloc_contig_range' spamming the system logs:One of the suggested fix is to suppress printing of this message (example as was done in a raspberry Pi tree)
On Tue, Jun 27, 2017 at 2:52 PM, Kumar Abhishek <kumar.abhi...@gmail.com> wrote:
1. Update: Switching to a different SD card solves the boot time being long
2. Doing 'sudo service lightdm stop' seems to stop the "alloc_contig_range" spam in the kernel log, suggesting it might have something to do with the X server (?)
Jeff Andich
Jun 27, 2017, 9:51:35 AM6/27/17
to BeagleBoard, robert...@gmail.com
Argh.
I was hoping to test the bbx15-debian-9.0-lxqt-armhf-2017-06-22 image on my 572xEVM, by burning a 4GB SD card, but for some reason, my board seems to boot the SPL 9 times (rinse and repeat fashion) and then appears to get stuck in the SPL. Looks like my SOC revision is different than your's..
.
.
.
U-Boot SPL 2017.01-00341-gb2aad42503 (Jun 21 2017 - 10:56:05)
DRA752-GP ES2.0
Trying to boot from MMC1
** Unable to use mmc 0:1 for loading the env **
Using default environment
.
.
.
U-Boot SPL 2017.01-00341-gb2aad42503 (Jun 21 2017 - 10:56:05)
DRA752-GP ES2.0
On Tuesday, June 27, 2017 at 5:58:55 AM UTC-5, Kumar Abhishek wrote:
I found some other people report the same issue 'alloc_contig_range' spamming the system logs:
One of the suggested fix is to suppress printing of this message (example as was done in a raspberry Pi tree)
On Tue, Jun 27, 2017 at 2:52 PM, Kumar Abhishek <kumar.abhi...@gmail.com> wrote:
1. Update: Switching to a different SD card solves the boot time being long
2. Doing 'sudo service lightdm stop' seems to stop the "alloc_contig_range" spam in the kernel log, suggesting it might have something to do with the X server (?)
Jeff Andich
Jun 27, 2017, 10:26:54 AM6/27/17
to BeagleBoard, robert...@gmail.com
Will TRY to muck around with this, but will likely have to wait a week...
Reply all
Reply to author
Forward
0 new messages