RE: OMAP baseline test results for v3.8-rc4
On Thu, Feb 07, 2013 at 03:30:56, Paul Walmsley wrote: Hi Vaibhav, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: I could not track down U-Boot that you were using It's posted now at: http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-9-gcf6e04d__20120803171543/ Care to try it? Thanks. Unfortunately, I'll be able to do this early next week only. However, using your build configs for v3.7 and v3.8-rcX I got the same observations i.e. v3.7 boots but others don't. One difference that I found was that post v3.7 the configs that you are using have CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 (didn't try rc2/3 but I suspect early_printk was the culprit there too). I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, that's expected behavior. Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that was used before; no luck. Ah, I was really hoping you wouldn't say that ;) or just skip earlyprintk option in the bootargs for now? Haven't tried this one yet. If you still have issues booting can you update your U-Boot to v2013.01 since things seem to be working fine at this point. Let's try to identify and get rid of bootloader dependencies in the kernel. They indicate that the kernel isn't initializing something appropriately, which could cause strange problems later. Agreed. It could also be that the boot-loader is doing something crazy but we do need to know what's the dependency. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc4
Hi Vaibhav, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: I could not track down U-Boot that you were using It's posted now at: http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-9-gcf6e04d__20120803171543/ Care to try it? However, using your build configs for v3.7 and v3.8-rcX I got the same observations i.e. v3.7 boots but others don't. One difference that I found was that post v3.7 the configs that you are using have CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 (didn't try rc2/3 but I suspect early_printk was the culprit there too). I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, that's expected behavior. Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that was used before; no luck. or just skip earlyprintk option in the bootargs for now? Haven't tried this one yet. If you still have issues booting can you update your U-Boot to v2013.01 since things seem to be working fine at this point. Let's try to identify and get rid of bootloader dependencies in the kernel. They indicate that the kernel isn't initializing something appropriately, which could cause strange problems later. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc4
On Wed, 6 Feb 2013, Paul Walmsley wrote: Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. And just tried this with u-boot v2013.01 on a BeagleBoard A6a, does not fix it. If you still have issues booting can you update your U-Boot to v2013.01 since things seem to be working fine at this point. Let's try to identify and get rid of bootloader dependencies in the kernel. They indicate that the kernel isn't initializing something appropriately, which could cause strange problems later. Oh and it's worth noting that parts of u-boot v2013.01 don't work correctly on earlier BeagleBones, i.e. Ethernet booting. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc4
On Fri, Jan 25, 2013 at 22:29:43, Tony Lindgren wrote: * Bedia, Vaibhav vaibhav.be...@ti.com [130123 06:35]: Hi Tony, On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: [...] But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. I think earlyprintk on AM335x has not been functional for a while [1]. Will the latest patches from you to enable multiplatform debug-ll be sufficient to test this out? I am trying to track down the boot issues reported and just want to be sure of the dependencies. Yes you should check with current linux next and select the DEBUG_LL port manually. Verified on linux-next that selecting the right UART port gives a functional early_console. (One of the rare cases where forcing a kernel panic early in the boot process makes sense ;) Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Hello Jan, On Tue, 22 Jan 2013, Jan Lübbe wrote: Just a guess, but there can be problems when the appended DTB crosses an 1MB boundary. See this mail for details and a patch: http://www.spinics.net/lists/arm-kernel/msg216898.html Thanks for the suggestion. That patch didn't fix it for me. - Paul
RE: OMAP baseline test results for v3.8-rc4
Hi, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or just skip earlyprintk option in the bootargs for now? I'll give this a try over the next few days. If EARLY_PRINTK is known to be broken for DT boots, could you please put together a Kconfig patch that prevents either EARLY_PRINTK from being selected when a DT-only board is selected, or vice-versa? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
* Bedia, Vaibhav vaibhav.be...@ti.com [130123 06:35]: Hi Tony, On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: [...] But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. I think earlyprintk on AM335x has not been functional for a while [1]. Will the latest patches from you to enable multiplatform debug-ll be sufficient to test this out? I am trying to track down the boot issues reported and just want to be sure of the dependencies. Yes you should check with current linux next and select the DEBUG_LL port manually. [1] http://marc.info/?l=linux-omapm=134642491119235w=2 This one should no longer be needed as we now use the machine_id for board-generic.c for DT boot. [2] https://patchwork.kernel.org/patch/1896851/ This alone won't work without multiplatform support. At least modifying the Kconfig to use the new settings for OMAP2PLUS is needed. Probably easiest to make sure it works in linux next first. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc4
Hi Paul, On Tue, Jan 22, 2013 at 07:54:44, Paul Walmsley wrote: Hi guys, Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. You'll need to use the bootloader that TI originally shipped with the BeagleBones: U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) This is because many folks don't replace their bootloader. I do plan to add a test with a recent version of u-boot, but the kernel should not be dependent on the bootloader in any way to work correctly. If it is, then we need to document what u-boot version the kernel started to work with. The Kconfig that I use is here: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only It's possible that there's something wrong with the Kconfig. It's basically just omap2plus_defconfig, but with all OMAP support for non-AM33xx turned off, and with the appended DTB and ATAG compatibility options turned on. Let's try to do this ASAP. That way, if it's some bootloader dependency or bug in the kernel, some fix can be merged during the v3.8-rc series, which is rapidly drawing to a close. I could not track down U-Boot that you were using so I used the v2013.01 tag for U-Boot. However, using your build configs for v3.7 and v3.8-rcX I got the same observations i.e. v3.7 boots but others don't. One difference that I found was that post v3.7 the configs that you are using have CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 (didn't try rc2/3 but I suspect early_printk was the culprit there too). I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, that's expected behavior. Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or just skip earlyprintk option in the bootargs for now? If you still have issues booting can you update your U-Boot to v2013.01 since things seem to be working fine at this point. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On 22/01/13 18:23, Tony Lindgren wrote: * Mark Jackson mpfj-l...@mimc.co.uk [130122 05:46]: On 22/01/13 13:32, Bedia, Vaibhav wrote: snip Following works for me: Kernel === git checkout next-20130122 make distclean make omap2plus_defconfig Enable the appended DTB related options via menuconfig make -j7 cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone U-Boot === Built from v2013.01 snip A dumb question... in your case what's the bootargs set? Note that the mainline kernel for AM335x doesn't have MMC support yet and the default bootargs is set to rootfs on MMC. Yes ... I'm trying to boot from a rootfs on MMC:- Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. Regards, Tony From: Kevin Hilman khil...@deeprootsystems.com Date: Tue, 15 Jan 2013 14:12:24 -0800 Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk Otherwise we can race with the earlyconsole getting turned off which can cause a non-booting system with earlyprintk enabled. [t...@atomide.com: updated description] Signed-off-by: Tony Lindgren t...@atomide.com --- Kevin, can I add your Signed-off-by to this one? --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -omap_late_initcall(omap_device_late_init); +late_initcall_sync(omap_device_late_init); Sorry ... still no joy:- U-Boot# askenv bootargs Please enter 'bootargs':ttyO0,115200n8 earlyprintk root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait U-Boot# dhcp 8000 10.0.0.100:/nanobone/uImage-dtb;bootm 8000 link up on port 0, speed 100, full duplex BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.112 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.112 Filename '/nanobone/uImage-dtb'. Load address: 0x8000 Loading: # # # # ### 625 KiB/s done Bytes transferred = 3972199 (3c9c67 hex) ## Booting kernel from Legacy Image at 8000 ... Image Name: Linux 3.8.0-rc3-12154-gac00f0e-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3972135 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... My .config can be found at http://pastebin.com/rj5ptt7W Cheers Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc4
Hi Tony, On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote: [...] But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. I think earlyprintk on AM335x has not been functional for a while [1]. Will the latest patches from you to enable multiplatform debug-ll be sufficient to test this out? I am trying to track down the boot issues reported and just want to be sure of the dependencies. [1] http://marc.info/?l=linux-omapm=134642491119235w=2 [2] https://patchwork.kernel.org/patch/1896851/ Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Paul == Paul Walmsley p...@pwsan.com writes:
Paul Hi guys,
Paul Regarding the AM33xx test failures with appended DTBs, it would
Paul be very helpful if especially the TI people could try reproducing
Paul the problem. Otherwise it's going to cause problems with merging
Paul any new AM33xx patches, since I won't be able to test them
Paul without additional work. Plus, this is something that used to
Paul work up until d01e4afd, so something isn't right.
Paul You'll need to use the bootloader that TI originally shipped with
Paul the BeagleBones:
Paul U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43)
FYI, my beaglebone came with a slightly different U-Boot:
U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)
But I have the same behaviour. Recent kernels work with a modern U-Boot,
but not the original. The build I'm doing is very similar to yours:
git describe
v3.8-rc4-71-g9a92841
make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
echo CONFIG_ARM_APPENDED_DTB=y .config
echo CONFIG_ARM_ATAG_DTB_COMPAT=y .config
yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig
make ARCH=arm CROSS_COMPILE=arm-linux-
cat arch/arm/boot/dts/am335x-bone.dtb arch/arm/boot/zImage
make ARCH=arm CROSS_COMPILE=arm-linux- uImage
# old u-boot (ethernet not stable here, so load from sd)
U-Boot SPL 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)
Texas Instruments Revision detection unimplemented
No AC power, disabling frequency switch
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)
I2C: ready
DRAM: 256 MiB
No daughter card present
NAND: HW ECC Hamming Code selected
nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10
No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment
Net: cpsw
Hit any key to stop autoboot: 0
U-Boot# mmc rescan
U-Boot# fatload mmc 0:1 0x8020 uImage.new
reading uImage.new
3945127 bytes read
U-Boot# setenv bootargs console=$console
U-Boot# bootm 0x8020
## Booting kernel from Legacy Image at 8020 ...
Image Name: Linux-3.8.0-rc4-00071-g9a92841
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:3945063 Bytes = 3.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
And it hangs. With a reasonably modern U-Boot it works:
U-Boot SPL 2012.10 (Oct 29 2012 - 23:39:02)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2012.10 (Oct 29 2012 - 23:39:02)
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: cpsw
Hit any key to stop autoboot: 0
U-Boot# dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.16.1.2
Using cpsw device
TFTP from server 172.16.1.1; our IP address is 172.16.1.2
Filename 'uImage'.
Load address: 0x8020
Loading: #
#
#
#
#
done
Bytes transferred = 3945127 (3c32a7 hex)
U-Boot# setenv bootargs console=$console
U-Boot# bootm
## Booting kernel from Legacy Image at 8020 ...
Image Name: Linux-3.8.0-rc4-00071-g9a92841
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:3945063 Bytes = 3.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-rc4-00071-g9a92841 (peko@dell) (gcc version 3
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructie
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335e
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] AM335X ES1.0 (neon )
...
For the failing case, __log_buf doesn't contain anything sensible so I
guess it crashes early:
grep __log_buf System.map
c07cc450 b __log_buf
U-Boot# md 807cc450
807cc450: e5749fbf ef220eff 3df957df acebffbd..t.W.=
807cc460: 61df 7e93c5ef ddbafdfd bb2ac2fd...a...~..*.
807cc470: 7ff1 f7fafd7f 717ddf7f 3feecfbc..}q...?
807cc480: bddb573d beeaba9b c57f7b99 f77dfbfe=W...{}.
807cc490: 6b7dde97 ebffcfaf fdf62df5 77e5f7bb..}k.-.w
807cc4a0: 5fdffdf5 7bc2d8be 7d977ddd feafafff..._...{.}.}
807cc4b0: f7429df5 76e2fd6d dedffd3d cf6769ff..B.m..v=ig.
807cc4c0: fb5644dd bdcf3a69 ffbfffd9 befff9ae.DV.i:..
807cc4d0: f7537fd7 feafe2f2 f37c7c2f fe5ffded
Re: OMAP baseline test results for v3.8-rc4
On Tue, 2013-01-22 at 02:24 +, Paul Walmsley wrote: Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. Just a guess, but there can be problems when the appended DTB crosses an 1MB boundary. See this mail for details and a patch: http://www.spinics.net/lists/arm-kernel/msg216898.html Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Jan == Jan Lübbe j...@pengutronix.de writes: Jan On Tue, 2013-01-22 at 02:24 +, Paul Walmsley wrote: Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. Jan Just a guess, but there can be problems when the appended DTB Jan crosses an 1MB boundary. See this mail for details and a patch: Jan http://www.spinics.net/lists/arm-kernel/msg216898.html True, but that doesn't seem to be the case here: ls -la arch/arm/boot/uImage -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage E.G. far from the 1MB boundary. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On Tue, Jan 22, 2013 at 10:40:46AM +0100, Peter Korsgaard wrote: Jan == Jan Lübbe j...@pengutronix.de writes: Jan On Tue, 2013-01-22 at 02:24 +, Paul Walmsley wrote: Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. Jan Just a guess, but there can be problems when the appended DTB Jan crosses an 1MB boundary. See this mail for details and a patch: Jan http://www.spinics.net/lists/arm-kernel/msg216898.html True, but that doesn't seem to be the case here: ls -la arch/arm/boot/uImage -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage E.G. far from the 1MB boundary. Don't rely on that. Remember, if the compressed image occupies the same location as the decompressed kernel, the decompressor will copy the data to a different location in RAM first - I think at RAM offset + 32K + decompressed kernel size. So yes, please try the patch in the link above. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On 22/01/13 02:24, Paul Walmsley wrote: Hi guys, Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. My non-working setup (I'm using a recent U-Boot) is as follows ... [Note that the DTB patch mentioned elsewhere in this thread seems to be *already* applied to -next] $ git describe next-20130121 $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_EARLY_PRINTK=y $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0×80008000 -e 0×80008000 -n ‘Linux’ -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb And when I boot:- U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01 (Jan 16 2013 - 15:20:58) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 167 bytes read in 3 ms (53.7 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... cpsw Waiting for PHY auto negotiation to complete. done link up on port 0, speed 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.112 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.112 Filename '/nanobone/uImage-dtb'. Load address: 0x8000 Loading: # # # # ### 627.9 KiB/s done Bytes transferred = 3963919 (3c7c0f hex) ## Booting kernel from Legacy Image at 8000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3963855 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Russell == Russell King - ARM Linux li...@arm.linux.org.uk writes: Russell Don't rely on that. Remember, if the compressed image Russell occupies the same location as the decompressed kernel, the Russell decompressor will copy the data to a different location in RAM Russell first - I think at RAM offset + 32K + decompressed kernel Russell size. Ok, but this is with the exact same kernel image loaded at the same address for the two cases. The only difference is U-Boot version. Russell So yes, please try the patch in the link above. I did. No visible difference. Also not with changing the uImage load address (2M/16M/32M from start of RAM). -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Hi, Mark Bytes transferred = 3963919 (3c7c0f hex) Mark ## Booting kernel from Legacy Image at 8000 ... MarkImage Name: Linux MarkImage Type: ARM Linux Kernel Image (uncompressed) MarkData Size:3963855 Bytes = 3.8 MiB MarkLoad Address: 80008000 MarkEntry Point: 80008000 MarkVerifying Checksum ... OK MarkLoading Kernel Image ... OK Mark OK I haven't tried a recent -next build, but what is your kernel command line and did you try without EARLY_PRINTK? -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP baseline test results for v3.8-rc4
Hi, On Tue, Jan 22, 2013 at 14:25:13, Peter Korsgaard wrote: Paul == Paul Walmsley p...@pwsan.com writes: Paul Hi guys, Paul Regarding the AM33xx test failures with appended DTBs, it would Paul be very helpful if especially the TI people could try reproducing Paul the problem. Otherwise it's going to cause problems with merging Paul any new AM33xx patches, since I won't be able to test them Paul without additional work. Plus, this is something that used to Paul work up until d01e4afd, so something isn't right. Paul You'll need to use the bootloader that TI originally shipped with Paul the BeagleBones: Paul U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) FYI, my beaglebone came with a slightly different U-Boot: U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14) But I have the same behaviour. Recent kernels work with a modern U-Boot, but not the original. The build I'm doing is very similar to yours: git describe v3.8-rc4-71-g9a92841 make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig echo CONFIG_ARM_APPENDED_DTB=y .config echo CONFIG_ARM_ATAG_DTB_COMPAT=y .config yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig make ARCH=arm CROSS_COMPILE=arm-linux- cat arch/arm/boot/dts/am335x-bone.dtb arch/arm/boot/zImage make ARCH=arm CROSS_COMPILE=arm-linux- uImage # old u-boot (ethernet not stable here, so load from sd) U-Boot SPL 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14) Texas Instruments Revision detection unimplemented No AC power, disabling frequency switch OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14) I2C: ready DRAM: 256 MiB No daughter card present NAND: HW ECC Hamming Code selected nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# mmc rescan U-Boot# fatload mmc 0:1 0x8020 uImage.new reading uImage.new 3945127 bytes read U-Boot# setenv bootargs console=$console U-Boot# bootm 0x8020 ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3945063 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... And it hangs. With a reasonably modern U-Boot it works: I just re-built U-Boot from f63b270 and the kernel from 9a92841 using commands similar to Peter's and the kernel boots for me with the appended DTB. (For some reason U-Boot version string doesn't have the commit id and I can't recollect what causes this) U-Boot SPL 2011.09 (Jan 22 2013 - 18:06:56) Texas Instruments Revision detection unimplemented OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2011.09 (Jan 22 2013 - 16:00:25) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled No daughter card present NAND: HW ECC Hamming Code selected nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10 No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# setenv bootargs console=$console U-Boot# setenv serverip 172.24.133.119 U-Boot# setenv bootfile uImage U-Boot# dhcp 8020 link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 172.24.190.59 Using cpsw device TFTP from server 172.24.133.119; our IP address is 172.24.190.59; sending through gateway 172.24.188.1 Filename 'uImage'. Load address: 0x8020 Loading: # # # # # # # # # # # ### done Bytes transferred = 3917327 (3bc60f hex) U-Boot# bootm 0x8020 ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.8.0-rc4-00071-g9a92841 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3917263 Bytes = 3.7 MiB
RE: OMAP baseline test results for v3.8-rc4
On Tue, Jan 22, 2013 at 15:45:08, Mark Jackson wrote: On 22/01/13 02:24, Paul Walmsley wrote: Hi guys, Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. My non-working setup (I'm using a recent U-Boot) is as follows ... [Note that the DTB patch mentioned elsewhere in this thread seems to be *already* applied to -next] $ git describe next-20130121 $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_EARLY_PRINTK=y $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0×80008000 -e 0×80008000 -n ‘Linux’ -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb And when I boot:- U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01 (Jan 16 2013 - 15:20:58) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 167 bytes read in 3 ms (53.7 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... cpsw Waiting for PHY auto negotiation to complete. done link up on port 0, speed 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 44 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.112 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.112 Filename '/nanobone/uImage-dtb'. Load address: 0x8000 Loading: # # # # ### 627.9 KiB/s done Bytes transferred = 3963919 (3c7c0f hex) ## Booting kernel from Legacy Image at 8000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3963855 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Following works for me: Kernel === git checkout next-20130122 make distclean make omap2plus_defconfig Enable the appended DTB related options via menuconfig make -j7 cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone U-Boot === Built from v2013.01 Bootlog === U-Boot SPL 2013.01 (Jan 22 2013 - 18:47:57) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01 (Jan 22 2013 - 18:47:57) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: cpsw, usb_ether Hit any key to stop autoboot: 0 U-Boot# setenv serverip 172.24.133.119 U-Boot# setenv bootfile uImage-dtb.am335x-bone U-Boot# dhcp 8020 link up on port 0, speed 100, full duplex
Re: OMAP baseline test results for v3.8-rc4
On 22/01/13 12:21, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@mimc.co.uk writes: Hi, Mark Bytes transferred = 3963919 (3c7c0f hex) Mark ## Booting kernel from Legacy Image at 8000 ... MarkImage Name: Linux MarkImage Type: ARM Linux Kernel Image (uncompressed) MarkData Size:3963855 Bytes = 3.8 MiB MarkLoad Address: 80008000 MarkEntry Point: 80008000 MarkVerifying Checksum ... OK MarkLoading Kernel Image ... OK Mark OK I haven't tried a recent -next build, but what is your kernel command line and did you try without EARLY_PRINTK? Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait I understand that MMC is not in the mainline. Aha ... I tried without EARLY_PRINTK and it now boots up to the point of rootfs access. Cheers Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On 22/01/13 13:32, Bedia, Vaibhav wrote: snip Following works for me: Kernel === git checkout next-20130122 make distclean make omap2plus_defconfig Enable the appended DTB related options via menuconfig make -j7 cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone U-Boot === Built from v2013.01 snip A dumb question... in your case what's the bootargs set? Note that the mainline kernel for AM335x doesn't have MMC support yet and the default bootargs is set to rootfs on MMC. Yes ... I'm trying to boot from a rootfs on MMC:- Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait But I should get *something* from the kernel before it starts trying to access the rootfs ? Regards Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
* Mark Jackson mpfj-l...@mimc.co.uk [130122 05:46]: On 22/01/13 13:32, Bedia, Vaibhav wrote: snip Following works for me: Kernel === git checkout next-20130122 make distclean make omap2plus_defconfig Enable the appended DTB related options via menuconfig make -j7 cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb arch/arm/boot/zImage-dtb.am335x-bone mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone U-Boot === Built from v2013.01 snip A dumb question... in your case what's the bootargs set? Note that the mainline kernel for AM335x doesn't have MMC support yet and the default bootargs is set to rootfs on MMC. Yes ... I'm trying to boot from a rootfs on MMC:- Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait But I should get *something* from the kernel before it starts trying to access the rootfs ? Here's something Kevin fixed but did not send it out before going to a vacation. Can you give it a try with earlyprintk enabled? Note that this does not help with no output early on, that sounds like a bug configuring the DEBUG_LL port somewhere. Regards, Tony From: Kevin Hilman khil...@deeprootsystems.com Date: Tue, 15 Jan 2013 14:12:24 -0800 Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk Otherwise we can race with the earlyconsole getting turned off which can cause a non-booting system with earlyprintk enabled. [t...@atomide.com: updated description] Signed-off-by: Tony Lindgren t...@atomide.com --- Kevin, can I add your Signed-off-by to this one? --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -omap_late_initcall(omap_device_late_init); +late_initcall_sync(omap_device_late_init); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On 16:32-20130121, Mark Jackson wrote: Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: [...] Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite - Nishanth Menon Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag see: http://pastebin.com/bGNxJnZJ build configuration: compiler: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. U-boot: git://git.denx.de/u-boot.git v2013.01-rc3 config: am335x_evm_config kernel: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v3.8-rc4 config: omap2plus_defconfig -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.8-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ snip Failing tests: needing investigation Boot tests: * am335xbone: hangs after Starting kernel - Cause unknown - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html snip Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite - Nishanth Menon Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? Cheers Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On Mon, Jan 21, 2013 at 04:32:13PM +, Mark Jackson wrote: Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.8-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ snip Failing tests: needing investigation Boot tests: * am335xbone: hangs after Starting kernel - Cause unknown - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html snip Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite - Nishanth Menon Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? Hi Mark, I'm not sure what needs to be fixed. The only thing my edma dmaengine series adds is new features (specifically, mmc and spi dma support). I would suspect some boot problem specific to Paul's configuration if it's hanging. I just booted current mainline with an omap2plus_defconfig build on my bone a5 and it came up fine. I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? For the features I listed above, yes. Also Mark Greer's crypto patches for AM33xx depend on that series as does a patch series (not ready yet) that I have to support the Bone audio capes. There's a dependency I'm working through in a separate thread on lkml since the dmaengine edma series requires the proposed dma_get_channel_caps() api...still discussing that implementation. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On Mon, Jan 21, 2013 at 06:20:03PM +, Richard Cochran wrote: On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Do you use appended dtb? The only different that jumped out at me first Paul's reported hang is he uses appended dtb and I boot my boards with a single uImage and multiple dtbs the traditional DT way. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
On Mon, Jan 21, 2013 at 01:24:19PM -0500, Matt Porter wrote:
On Mon, Jan 21, 2013 at 06:20:03PM +, Richard Cochran wrote:
On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote:
for MMC filesystem - we need the edma series. for a ramdisk, I am able
to boot up to shell with 3.8-rc4 tag
Yep, I also could boot 3.8-rc3 using ramfs, no problem.
Do you use appended dtb? The only different that jumped out at me first
Paul's reported hang is he uses appended dtb and I boot my boards with a
single uImage and multiple dtbs the traditional DT way.
No, not appended. I have a u-boot that supports dtb:
U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
and using the omap2plus_defconfig, with a minicom script like the one
below, and it works just fine.
HTH,
Richard
verbose on
send setenv ipaddr 192.168.1.77
send setenv serverip 192.168.1.12
send setenv netmask 255.255.255.0
send setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw
initrd=0x8200,16MB ramdisk_size=16384 earlyprintk=serial
send tftp 8100 uImage
expect {
U-Boot#
}
send tftp 8200 beaglebone-initrd.gz
expect {
U-Boot#
}
send tftp 8000 am335x-bone.dtb
expect {
U-Boot#
}
send bootm 8100 - 8000
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Matt == Matt Porter mpor...@ti.com writes: Matt On Mon, Jan 21, 2013 at 04:32:13PM +, Mark Jackson wrote: Does anyone know when the BeagleBone support is going to be fixed in mainline ? Matt Hi Mark, Matt I'm not sure what needs to be fixed. The only thing my edma dmaengine Matt series adds is new features (specifically, mmc and spi dma support). Matt I would suspect some boot problem specific to Paul's configuration Matt if it's hanging. I just booted current mainline with an Matt omap2plus_defconfig build on my bone a5 and it came up fine. It also works here. I have noticed issues with nfs boot and recent mainline when powered from the USB cable though. I suspect we're getting close to the power limit. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Matt == Matt Porter mpor...@ti.com writes: Matt On Mon, Jan 21, 2013 at 06:20:03PM +, Richard Cochran wrote: On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Matt Do you use appended dtb? The only different that jumped out at me first Matt Paul's reported hang is he uses appended dtb and I boot my boards with a Matt single uImage and multiple dtbs the traditional DT way. It works for me with appended dtb as well. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.8-rc4
Hi guys, Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. You'll need to use the bootloader that TI originally shipped with the BeagleBones: U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) This is because many folks don't replace their bootloader. I do plan to add a test with a recent version of u-boot, but the kernel should not be dependent on the bootloader in any way to work correctly. If it is, then we need to document what u-boot version the kernel started to work with. The Kconfig that I use is here: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only It's possible that there's something wrong with the Kconfig. It's basically just omap2plus_defconfig, but with all OMAP support for non-AM33xx turned off, and with the appended DTB and ATAG compatibility options turned on. Let's try to do this ASAP. That way, if it's some bootloader dependency or bug in the kernel, some fix can be merged during the v3.8-rc series, which is rapidly drawing to a close. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
