On 07.01.2014, at 12:44, Andreas Färber <[email protected]> wrote:

> Am 07.01.2014 10:02, schrieb Guillaume Gardet:
>> 
>> Le 07/01/2014 01:40, Andreas Färber a écrit :
>>> Am 05.01.2014 18:00, schrieb Andreas Färber:
>>>> I notice that in config-3.12.2-2-default the following are not set:
>>>> CONFIG_I2C_BCM2835
>>>> CONFIG_BCM2835_WDT
>>>> CONFIG_USB_HCD_BCMA /* not sure if applicable? */
>>>> CONFIG_MMC_SDHCI_BCM2835
>>> Using openSUSE kernel.git master's `make ARCH=arm menuconfig` based on
>>> kernel-source.git config/armv6hl/default I've created the attached diff
>>> and manually backported it to Factory's kernel-source package, resulting
>>> in the attached config file.
>>> 
>>> Unfortunately my local osc build is still not finished, so I'm sharing
>>> this untested. Since we're booting from SD card it seems logical to me
>>> to build in MMC drivers rather than having them as modules. I2C and WDT
>>> ended up being straightforward additions by contrast.
>> 
>> Thanks for fixing that.
>> 
>> Once your build is finished, you could submit your patch in opensuse-kernel 
>> ML to get it in GIT repo.
> 
> Okay. Build finished over night, no visible change when booting.
> 
> I also tried the u-boot-rpib from Factory:ARM rather than
> Factory:Contrib, renaming boot.scr to boot.scr.uimg, no change either.
> (I am planning to submit the rename fix to Base:System once my pending
> https://build.opensuse.org/request/show/212959
> has been processed.)

Accepted.

> 
> I notice that CONFIG_ARM_APPENDED_DTB=y is set. Does that *require* or
> does it *allow* a directly appended dtb? If the latter, then I could try

It *allow*s a directly appended dtb.

> rebuilding with CONFIG_ARM_ATAG_DTB_COMPAT set as last resort, which was
> required on my AC100 when using Android's fastboot bootloader.
> Just to be sure I tried appending the dtb to my zImage, but no change
> either.

Do you have a reset pin on there somewhere? If so, you could try to reset the 
system after you booted the kernel and then try to dump __log_buf from the 
still-alive RAM that the kernel wrote it to (you can find the virtual address 
with nm on vmlinux, just add the physical RAM offset to that for u-boot's md 
command).

Since you don't seem to have a working USB driver, you could add said md 
command to your boot.scr so that u-boot always dumps log_buf after reset. That 
way you might be able to find out what's going wrong.

Of course, a serial port would help as well.


Alex

--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to