Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1256825 > unrolled thread

RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig Huan Wang <alison.wang@freescale.com> - 2015-10-27 16:00 +0100
    Re: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig Arnd Bergmann <arnd@arndb.de> - 2015-10-30 14:50 +0100
      RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig Huan Wang <alison.wang@freescale.com> - 2015-11-02 04:20 +0100

#1256825 — RE: [PATCH v4] ARM: configs: Add Freescale LS1021A defconfig

PiBPbiBUaHVyc2RheSAxNSBPY3RvYmVyIDIwMTUgMDI6MTE6NTcgSHVhbiBXYW5nIHdyb3RlOg0K
PiA+ID4gT24gV2VkbmVzZGF5IDE0IE9jdG9iZXIgMjAxNSAxMDoxODo0NyBIdWFuIFdhbmcgd3Jv
dGU6DQo+ID4gPiA+ID4gT24gVGh1cnNkYXkgMjQgU2VwdGVtYmVyIDIwMTUgMDc6Mjc6MTAgSHVh
biBXYW5nIHdyb3RlOg0KPiA+ID4gPiA+ID4gPiBPbiBGcmksIFNlcCAxOCwgMjAxNSBhdCA0OjM4
IEFNLCBIdWFuIFdhbmcNCj4gPGFsaXNvbi53YW5nQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPiA+
ID4gPiA+ID4gQW55IHN1Z2dlc3Rpb24/IFRoYW5rcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRy
eSBlbmFibGluZyBERUJVR19MTCBmb3IgeW91ciBwbGF0Zm9ybSB0byBnZXQgc29tZSBkZWJ1Zw0K
PiA+ID4gPiA+IG91dHB1dCwgaWYgeW91IHN0aWxsIGRvbid0IGdldCBhbnkgaGVscGZ1bCBtZXNz
YWdlcywgdHJ5IGFsc28NCj4gPiA+ID4gPiBpbnNlcnRpbmcNCj4gPiA+ID4gPg0KPiA+ID4gPiA+
ICAgICAgIHByaW50YXNjaWkoX19mdW5jX18pOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gc3RhdGVt
ZW50cyBpbiB0aGUgZWFybHkgYm9vdCBwcm9jZXNzIHRvIHNlZSBob3cgZmFyIHlvdSBnZXQNCj4g
YmVmb3JlIHRoZSBoYW5nLg0KPiA+ID4gPiA+DQo+ID4gPg0KPiA+IFtBbGlzb24gV2FuZ10gbHMx
MDIxYSB1c2VzIGR1YXJ0IGFzIHRoZSBkZWZhdWx0IHNlcmlhbCBwb3J0LCBub3QNCj4gPiBscHVh
cnQuIFNvDQo+ID4gODI1MC8xNjU1MCBzZXJpYWwgZHJpdmVyIGlzIHVzZWQuIExldCBtZSBleHBs
YWluIG15IGRlYnVnIHByb2Nlc3MgaW4NCj4gZGV0YWlsLg0KPiANCj4gQWgsIEkgc2VlLg0KPiAN
Cj4gPiBXaGVuIENPTkZJR19WTVNQTElUXzJHIGlzIHVzZWQsIEkgY291bGQgYm9vdCB1cCB0aGUg
d2hvbGUga2VybmVsIGFuZA0KPiA+IGdldCB0aGUgcHJpbnQgbWVzc2FnZSAiIEJvb3RpbmcgTGlu
dXggb24gcGh5c2ljYWwgQ1BVIDB4ZjAwIiBhZnRlcg0KPiAiU3RhcnRpbmcga2VybmVsIg0KPiA+
IGFzIGJlbG93Lg0KPiA+DQo+ID4gU3RhcnRpbmcga2VybmVsIC4uLg0KPiA+IFsgICAgMC4wMDAw
MDBdIEJvb3RpbmcgTGludXggb24gcGh5c2ljYWwgQ1BVIDB4ZjAwDQo+ID4gLi4uLi4NCj4gPg0K
PiA+IEJ1dCB3aGVuIENPTkZJR19WTVNQTElUXzNHIGlzIHVzZWQsIEkgY291bGRuJ3QgZ2V0IHBy
aW50IG1lc3NhZ2UgIg0KPiA+IEJvb3RpbmcgTGludXggb24gcGh5c2ljYWwgQ1BVIDB4ZjAwIi4g
SXQgb25seSBoYW5ncyBhdCAgIlN0YXJ0aW5nDQo+IGtlcm5lbCAuLi4iLg0KPiA+DQo+ID4gTW9y
ZW92ZXIsIEkgYWRkIHNvbWUgYXNtIGNvZGUgaW4gX190dXJuX21tdV9vbiB0byBwcmludCBzb21l
IHNpbXBsZQ0KPiA+IGNoYXJhY3RlcnMsIGFuZCBJIGNvdWxkIGdldCB0aGUgcHJpbnQgY2hhcmFj
dGVycyB3aGVuDQo+ID4gQ09ORklHX1ZNU1BMSVRfM0cgaXMgdXNlZC4gU28gSSBndWVzcyB0aGVy
ZSBpcyBzb21ldGhpbmcgd3Jvbmcgd2l0aA0KPiB0aGUgcGFnZSB0YWJsZXMuDQo+IA0KPiBPay4g
V2hhdCBJIHdhcyBzdWdnZXN0aW5nIGFib3ZlIHRob3VnaCB3YXMgdG8gdHJ5IHRvIHBpbnBvaW50
IGV4YWN0bHkNCj4gd2hlcmUgaXQgZ29lcyB3cm9uZy4gWW91IGhhdmUgdmVyaWZpZWQgdGhhdCBp
dCBkb2VzIG5vdCBjcmFzaCBiZWZvcmUgdGhlDQo+IHBhZ2UgdGFibGVzIGFyZSBlbmFibGVkLCBi
dXQgdGhhdCBpcyB2ZXJ5IGVhcmx5LiBZb3UgaGF2ZSBhbHNvIHNob3duDQo+IHRoYXQgdGhlIGtl
cm5lbCBjcmFzaGVzIGJlZm9yZSB0aGUgcG9pbnQgYXQgd2hpY2ggdGhlICdCb290aW5nIExpbnV4
IG9uDQo+IHBoeXNpY2FsIENQVSAweGYwMCcgbWVzc2FnZSBpcyBwcmludGVkIHRvIHRoZSBrZXJu
ZWwsIGJ1dCB0aGF0IGlzICptdWNoKg0KPiBsYXRlcjogc2V0dXBfYXJjaCgpIGNhbGxzIHBhcnNl
X2Vhcmx5X3BhcmFtKCksIHdoaWNoIGluIHR1cm4gc2V0cyB1cA0KPiBlYXJseV9jb25zb2xlX3dy
aXRlKCkuIFRoaXMgbWVhbnMgdGhlICdCb290aW5nIExpbnV4IG9uIHBoeXNpY2FsIENQVQ0KPiAw
eGYwMCcNCj4gaXMgc3RpbGwgc3R1Y2sgaW4gdGhlIGxvZyBidWZmZXIgYW5kIHlvdSBtYXkgaGF2
ZSBjcmFzaGVkIHNvbWVvbmUNCj4gaW5iZXR3ZWVuLg0KPiANCj4gSWYgeW91IGNhbiBjYWxsIHBy
aW50YXNjaWkoKSwgeW91IGNhbiB0cnkgdG8gZG8gdGhhdCBqdXN0IGFmdGVyIGVuYWJsaW5nDQo+
IHRoZSBwYWdlIHRhYmxlcyB0byBzZWUgaWYgdGhhdCB3YXMgdGhlIHByb2JsZW0gbGlrZSB5b3Ug
c3VzcGVjdCwgb3INCj4gb3RoZXJ3aXNlIGFkZCBtb3JlIHByaW50YXNjaWkoKSBzdGF0ZW1lbnRz
IGJldHdlZW4gX190dXJuX21tdV9vbiBhbmQNCj4gcGFyc2VfZWFybHlfcGFyYW0oKSB0byBwaW5w
b2ludCB0aGUgZXhhY3QgY29kZSB0aGF0IGJyZWFrcy4NCltBbGlzb24gV2FuZ10gVGhhbmsgeW91
IHZlcnkgbXVjaCBmb3IgeW91ciBoZWxwLiBUaGUgaXNzdWUgaXMgZml4ZWQuDQoNCkJlc3QgUmVn
YXJkcywNCkFsaXNvbiBXYW5nDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1259499

On Tuesday 27 October 2015 14:40:21 Huan Wang wrote:
> > 
> > Ok. What I was suggesting above though was to try to pinpoint exactly
> > where it goes wrong. You have verified that it does not crash before the
> > page tables are enabled, but that is very early. You have also shown
> > that the kernel crashes before the point at which the 'Booting Linux on
> > physical CPU 0xf00' message is printed to the kernel, but that is *much*
> > later: setup_arch() calls parse_early_param(), which in turn sets up
> > early_console_write(). This means the 'Booting Linux on physical CPU
> > 0xf00'
> > is still stuck in the log buffer and you may have crashed someone
> > inbetween.
> > 
> > If you can call printascii(), you can try to do that just after enabling
> > the page tables to see if that was the problem like you suspect, or
> > otherwise add more printascii() statements between __turn_mmu_on and
> > parse_early_param() to pinpoint the exact code that breaks.
> [Alison Wang] Thank you very much for your help. The issue is fixed.
> 

Ah, very good. I'm curious what caused the problem in the end.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1260317

> On Tuesday 27 October 2015 14:40:21 Huan Wang wrote:
> > >
> > > Ok. What I was suggesting above though was to try to pinpoint
> > > exactly where it goes wrong. You have verified that it does not
> > > crash before the page tables are enabled, but that is very early.
> > > You have also shown that the kernel crashes before the point at
> > > which the 'Booting Linux on physical CPU 0xf00' message is printed
> > > to the kernel, but that is *much*
> > > later: setup_arch() calls parse_early_param(), which in turn sets up
> > > early_console_write(). This means the 'Booting Linux on physical CPU
> > > 0xf00'
> > > is still stuck in the log buffer and you may have crashed someone
> > > inbetween.
> > >
> > > If you can call printascii(), you can try to do that just after
> > > enabling the page tables to see if that was the problem like you
> > > suspect, or otherwise add more printascii() statements between
> > > __turn_mmu_on and
> > > parse_early_param() to pinpoint the exact code that breaks.
> > [Alison Wang] Thank you very much for your help. The issue is fixed.
> >
> 
> Ah, very good. I'm curious what caused the problem in the end.
[Alison Wang] The problem is caused by the wrong fdt_high setting (0xcfffffff).
When 3G/1G user/kernel memory split is used, U-Boot relocates the device tree
blob into high memory when booting the kernel and the kernel is unable to access
the blob.

Best Regards,
Alison Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web