* Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
@ 2018-03-09 12:51 Alvaro G. M.
2018-03-09 19:05 ` Rob Herring
0 siblings, 1 reply; 8+ messages in thread
From: Alvaro G. M. @ 2018-03-09 12:51 UTC (permalink / raw)
To: linux-kernel, Rob Herring
Hi,
I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
makes microblaze unbootable.
I'm sorry I can't provide any console output, as nothing appears at all,
even when setting earlyprintk (or at least I wasn't able to get anything
back!).
I'm providing both dts and defconfig in case it helps.
Best regards
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_FHANDLE=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_BLK_DEV_INITRD=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_KERNEL_BASE_ADDR=0x80000000
CONFIG_XILINX_MICROBLAZE0_FAMILY="artix7"
CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_BARREL=1
CONFIG_XILINX_MICROBLAZE0_USE_DIV=1
CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=2
CONFIG_HZ_100=y
CONFIG_MMU=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=ttyUL0,9600"
CONFIG_HIGHMEM=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_TESTS=m
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
CONFIG_MTD_SPI_NOR=y
CONFIG_NETDEVICES=y
CONFIG_XILINX_EMACLITE=y
CONFIG_DP83848_PHY=y
CONFIG_DP83620_PHY=y
CONFIG_SERIAL_UARTLITE=y
CONFIG_SERIAL_UARTLITE_CONSOLE=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_XILINX=y
CONFIG_SPI=y
CONFIG_SPI_XILINX=y
CONFIG_SPI_SPIDEV=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_XILINX=y
CONFIG_SENSORS_IIO_HWMON=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_FB=y
CONFIG_FB_XILINX=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=y
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_LEDS_TRIGGER_TRANSIENT=y
CONFIG_LEDS_TRIGGER_CAMERA=y
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_IIO=y
CONFIG_AD799X=y
CONFIG_XILINX_XADC=y
CONFIG_PWM=y
CONFIG_JFFS2_FS=y
CONFIG_SQUASHFS=y
CONFIG_SQUASHFS_LZ4=y
CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BOTH=y
CONFIG_NFS_FS=y
CONFIG_ROOT_NFS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_SLAB=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_EARLY_PRINTK=y
CONFIG_CRYPTO_MANAGER=y
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,microblaze";
model = "Xilinx MicroBlaze";
cpus {
#address-cells = <1>;
#cpus = <1>;
#size-cells = <0>;
microblaze_0: cpu@0 {
bus-handle = <&amba_pl>;
clock-frequency = <83250000>;
clocks = <&clk_cpu>;
compatible = "xlnx,microblaze-9.5";
d-cache-baseaddr = <0x80000000>;
d-cache-highaddr = <0x8fffffff>;
d-cache-line-size = <0x10>;
d-cache-size = <0x8000>;
device_type = "cpu";
i-cache-baseaddr = <0x80000000>;
i-cache-highaddr = <0x8fffffff>;
i-cache-line-size = <0x20>;
i-cache-size = <0x8000>;
interrupt-handle = <µblaze_0_axi_intc>;
model = "microblaze,9.5";
timebase-frequency = <83250000>;
xlnx,addr-tag-bits = <0xd>;
xlnx,allow-dcache-wr = <0x1>;
xlnx,allow-icache-wr = <0x1>;
xlnx,area-optimized = <0x0>;
xlnx,async-interrupt = <0x1>;
xlnx,avoid-primitives = <0x0>;
xlnx,base-vectors = <0x00000000>;
xlnx,branch-target-cache-size = <0x0>;
xlnx,cache-byte-size = <0x8000>;
xlnx,d-axi = <0x1>;
xlnx,d-lmb = <0x1>;
xlnx,d-lmb-mon = <0x0>;
xlnx,data-size = <0x20>;
xlnx,dc-axi-mon = <0x0>;
xlnx,dcache-addr-tag = <0xd>;
xlnx,dcache-always-used = <0x1>;
xlnx,dcache-byte-size = <0x8000>;
xlnx,dcache-data-width = <0x0>;
xlnx,dcache-force-tag-lutram = <0x0>;
xlnx,dcache-line-len = <0x4>;
xlnx,dcache-use-writeback = <0x0>;
xlnx,dcache-victims = <0x8>;
xlnx,debug-counter-width = <0x20>;
xlnx,debug-enabled = <0x1>;
xlnx,debug-event-counters = <0x5>;
xlnx,debug-external-trace = <0x0>;
xlnx,debug-latency-counters = <0x1>;
xlnx,debug-profile-size = <0x0>;
xlnx,debug-trace-size = <0x2000>;
xlnx,div-zero-exception = <0x1>;
xlnx,dp-axi-mon = <0x0>;
xlnx,dynamic-bus-sizing = <0x0>;
xlnx,ecc-use-ce-exception = <0x0>;
xlnx,edge-is-positive = <0x1>;
xlnx,enable-discrete-ports = <0x0>;
xlnx,endianness = <0x1>;
xlnx,fault-tolerant = <0x0>;
xlnx,fpu-exception = <0x0>;
xlnx,freq = <0x4f64b50>;
xlnx,fsl-exception = <0x0>;
xlnx,fsl-links = <0x0>;
xlnx,i-axi = <0x0>;
xlnx,i-lmb = <0x1>;
xlnx,i-lmb-mon = <0x0>;
xlnx,ic-axi-mon = <0x0>;
xlnx,icache-always-used = <0x1>;
xlnx,icache-data-width = <0x0>;
xlnx,icache-force-tag-lutram = <0x0>;
xlnx,icache-line-len = <0x8>;
xlnx,icache-streams = <0x1>;
xlnx,icache-victims = <0x8>;
xlnx,ill-opcode-exception = <0x1>;
xlnx,imprecise-exceptions = <0x0>;
xlnx,interconnect = <0x2>;
xlnx,interrupt-is-edge = <0x0>;
xlnx,interrupt-mon = <0x0>;
xlnx,ip-axi-mon = <0x0>;
xlnx,lockstep-select = <0x0>;
xlnx,lockstep-slave = <0x0>;
xlnx,mmu-dtlb-size = <0x4>;
xlnx,mmu-itlb-size = <0x2>;
xlnx,mmu-privileged-instr = <0x0>;
xlnx,mmu-tlb-access = <0x3>;
xlnx,mmu-zones = <0x2>;
xlnx,num-sync-ff-clk = <0x2>;
xlnx,num-sync-ff-clk-debug = <0x2>;
xlnx,num-sync-ff-clk-irq = <0x1>;
xlnx,num-sync-ff-dbg-clk = <0x1>;
xlnx,number-of-pc-brk = <0x1>;
xlnx,number-of-rd-addr-brk = <0x0>;
xlnx,number-of-wr-addr-brk = <0x0>;
xlnx,opcode-0x0-illegal = <0x1>;
xlnx,optimization = <0x0>;
xlnx,pc-width = <0x20>;
xlnx,pvr = <0x2>;
xlnx,pvr-user1 = <0x00>;
xlnx,pvr-user2 = <0x00000000>;
xlnx,reset-msr = <0x00000000>;
xlnx,sco = <0x0>;
xlnx,trace = <0x0>;
xlnx,unaligned-exceptions = <0x1>;
xlnx,use-barrel = <0x1>;
xlnx,use-branch-target-cache = <0x0>;
xlnx,use-config-reset = <0x0>;
xlnx,use-dcache = <0x1>;
xlnx,use-div = <0x1>;
xlnx,use-ext-brk = <0x0>;
xlnx,use-ext-nm-brk = <0x0>;
xlnx,use-extended-fsl-instr = <0x0>;
xlnx,use-fpu = <0x0>;
xlnx,use-hw-mul = <0x2>;
xlnx,use-icache = <0x1>;
xlnx,use-interrupt = <0x2>;
xlnx,use-mmu = <0x3>;
xlnx,use-msr-instr = <0x1>;
xlnx,use-pcmp-instr = <0x1>;
xlnx,use-reorder-instr = <0x1>;
xlnx,use-stack-protection = <0x0>;
};
};
clocks {
#address-cells = <1>;
#size-cells = <0>;
clk_cpu: clk_cpu@0 {
#clock-cells = <0>;
clock-frequency = <83250000>;
clock-output-names = "clk_cpu";
compatible = "fixed-clock";
reg = <0>;
};
clk_bus_0: clk_bus_0@1 {
#clock-cells = <0>;
clock-frequency = <83250000>;
clock-output-names = "clk_bus_0";
compatible = "fixed-clock";
reg = <1>;
};
};
amba_pl: amba_pl {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges ;
axi_ethernetlite_0: ethernet@40e00000 {
compatible = "xlnx,xps-ethernetlite-1.00.a";
device_type = "network";
interrupt-parent = <µblaze_0_axi_intc>;
interrupts = <2 0>;
reg = <0x40e00000 0x10000>;
xlnx,duplex = <0x1>;
xlnx,include-global-buffers = <0x1>;
xlnx,include-internal-loopback = <0x1>;
xlnx,include-mdio = <0x1>;
xlnx,rx-ping-pong = <0x1>;
xlnx,s-axi-id-width = <0x1>;
xlnx,tx-ping-pong = <0x1>;
xlnx,use-internal = <0x0>;
phy-handle = <&phy0>;
axi_ethernetlite_0_mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@0 {
device_type = "ethernet-phy";
reg = <1>;
};
};
};
axi_quad_spi_0: axi_quad_spi@44a00000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "xlnx,xps-spi-2.00.a";
interrupt-parent = <µblaze_0_axi_intc>;
interrupts = <3 0>;
reg = <0x44a00000 0x10000>;
xlnx,num-ss-bits = <0x1>;
axi_flash_spi_0: n25q128@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "micron,n25q128a", "jedec,spi-nor";
reg = <0>; /* Chip select 0 */
spi-max-frequency = <100000000>;
xlnx,num-ss-bits = <0x1>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@bitfile {
label = "bitfile";
reg = <0x000000 0x200000>;
};
partition@kernel {
label = "kernel";
reg = <0x200000 0x500000>;
};
partition@rootfs {
label = "rootfs";
reg = <0x700000 0x700000>;
};
partition@persistent {
label = "persistent";
reg = <0xe00000 0x200000>;
};
partition@full-image {
label = "full-image";
reg = <0x000000 0xE00000>;
};
partition@full-disk {
label = "full-disk";
reg = <0x000000 0x1000000>;
};
};
};
};
axi_timer_0: timer@41c00000 {
clock-frequency = <83250000>;
clocks = <&clk_bus_0>;
compatible = "xlnx,xps-timer-1.00.a";
interrupt-parent = <µblaze_0_axi_intc>;
interrupts = <0 2>;
reg = <0x41c00000 0x10000>;
xlnx,count-width = <0x20>;
xlnx,gen0-assert = <0x1>;
xlnx,gen1-assert = <0x1>;
xlnx,one-timer-only = <0x0>;
xlnx,trig0-assert = <0x1>;
xlnx,trig1-assert = <0x1>;
};
axi_timer_1: pwm@41c10000 {
clock-frequency = <83250000>;
clocks = <&clk_bus_0>;
compatible = "xlnx,xps-timer-1.00.a";
reg = <0x41c10000 0x10000>;
#pwm-cells = <2>;
xlnx,pwm-outputs = <1>;
xlnx,count-width = <0x20>;
xlnx,gen0-assert = <0x1>;
xlnx,gen1-assert = <0x1>;
xlnx,one-timer-only = <0x0>;
xlnx,trig0-assert = <0x1>;
xlnx,trig1-assert = <0x1>;
};
axi_uartlite_0: serial@40600000 {
clock-frequency = <83250000>;
clocks = <&clk_bus_0>;
compatible = "xlnx,xps-uartlite-1.00.a";
current-speed = <115200>;
device_type = "serial";
interrupt-parent = <µblaze_0_axi_intc>;
interrupts = <1 0>;
port-number = <0>;
reg = <0x40600000 0x10000>;
xlnx,baudrate = <0x2580>;
xlnx,data-bits = <0x8>;
xlnx,odd-parity = <0x0>;
xlnx,s-axi-aclk-freq-hz-d = "83.25";
xlnx,use-parity = <0x0>;
};
microblaze_0_axi_intc: interrupt-controller@41200000 {
#interrupt-cells = <2>;
compatible = "xlnx,xps-intc-1.00.a";
interrupt-controller ;
reg = <0x41200000 0x10000>;
xlnx,kind-of-intr = <0xfe>;
xlnx,num-intr-inputs = <0x4>;
};
};
};
/ {
chosen {
bootargs = "console=ttyUL0,9600 root=/dev/mtdblock2 earlyprintk=serial,ttyS0,9600";
linux,stdout-path = &axi_uartlite_0;
stdout-path = &axi_uartlite_0;
};
aliases {
ethernet0 = &axi_ethernetlite_0;
serial0 = &axi_uartlite_0;
spi0 = &axi_quad_spi_0;
flash0 = &axi_flash_spi_0;
};
memory {
device_type = "memory";
reg = <0x80000000 0x0f800000>;
};
};
&axi_ethernetlite_0 {
local-mac-address = [00 0a 35 00 00 00];
};
--
Alvaro G. M.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
2018-03-09 12:51 Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b Alvaro G. M.
@ 2018-03-09 19:05 ` Rob Herring
2018-03-10 13:15 ` Michal Simek
2018-03-12 7:52 ` Alvaro G. M.
0 siblings, 2 replies; 8+ messages in thread
From: Rob Herring @ 2018-03-09 19:05 UTC (permalink / raw)
To: Alvaro G. M., Michal Simek; +Cc: linux-kernel
On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. <alvaro.gamez@hazent.com> wrote:
> Hi,
>
> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
> makes microblaze unbootable.
>
> I'm sorry I can't provide any console output, as nothing appears at all,
> even when setting earlyprintk (or at least I wasn't able to get anything
> back!).
Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so
memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK &&
!CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and
it can be removed, but I'm still investigating. Can you try out this
branch[1].
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
microblaze-fixes
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
2018-03-09 19:05 ` Rob Herring
@ 2018-03-10 13:15 ` Michal Simek
2018-03-12 7:52 ` Alvaro G. M.
1 sibling, 0 replies; 8+ messages in thread
From: Michal Simek @ 2018-03-10 13:15 UTC (permalink / raw)
To: Rob Herring, Alvaro G. M.; +Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1186 bytes --]
On 9.3.2018 20:05, Rob Herring wrote:
> On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. <alvaro.gamez@hazent.com> wrote:
>> Hi,
>>
>> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
>> makes microblaze unbootable.
>>
>> I'm sorry I can't provide any console output, as nothing appears at all,
>> even when setting earlyprintk (or at least I wasn't able to get anything
>> back!).
>
> Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so
> memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK &&
> !CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and
> it can be removed, but I'm still investigating. Can you try out this
> branch[1].
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> microblaze-fixes
>
Let me take a look at it on Monday with the rest of patches sent by you.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
2018-03-09 19:05 ` Rob Herring
2018-03-10 13:15 ` Michal Simek
@ 2018-03-12 7:52 ` Alvaro G. M.
2018-03-12 10:21 ` Michal Simek
1 sibling, 1 reply; 8+ messages in thread
From: Alvaro G. M. @ 2018-03-12 7:52 UTC (permalink / raw)
To: Rob Herring; +Cc: Michal Simek, linux-kernel
On Fri, Mar 09, 2018 at 01:05:11PM -0600, Rob Herring wrote:
> On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. <alvaro.gamez@hazent.com> wrote:
> > Hi,
> >
> > I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
> > makes microblaze unbootable.
> >
> > I'm sorry I can't provide any console output, as nothing appears at all,
> > even when setting earlyprintk (or at least I wasn't able to get anything
> > back!).
>
> Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so
> memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK &&
> !CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and
> it can be removed, but I'm still investigating. Can you try out this
> branch[1].
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> microblaze-fixes
Hi, Rob!
This branch does indeed solve the issue. My microblaze system is now
booting as it did before, and everything seems normal now. Thanks!
Tested-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
--
Alvaro G. M.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
2018-03-12 7:52 ` Alvaro G. M.
@ 2018-03-12 10:21 ` Michal Simek
2018-03-14 15:04 ` Michal Simek
0 siblings, 1 reply; 8+ messages in thread
From: Michal Simek @ 2018-03-12 10:21 UTC (permalink / raw)
To: Alvaro G. M., Rob Herring; +Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1996 bytes --]
On 12.3.2018 08:52, Alvaro G. M. wrote:
> On Fri, Mar 09, 2018 at 01:05:11PM -0600, Rob Herring wrote:
>> On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. <alvaro.gamez@hazent.com> wrote:
>>> Hi,
>>>
>>> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
>>> makes microblaze unbootable.
>>>
>>> I'm sorry I can't provide any console output, as nothing appears at all,
>>> even when setting earlyprintk (or at least I wasn't able to get anything
>>> back!).
>>
>> Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so
>> memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK &&
>> !CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and
>> it can be removed, but I'm still investigating. Can you try out this
>> branch[1].
>>
>> Rob
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>> microblaze-fixes
>
> Hi, Rob!
>
> This branch does indeed solve the issue. My microblaze system is now
> booting as it did before, and everything seems normal now. Thanks!
>
> Tested-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
>
I have tested it and I can also confirm that your two patches are fixing
issue with
809d0e2c: 00240034 26000000 746f6f62 206d656d 4.$....&bootmem
809d0e3c: 6f6c6c61 666f2063 33353220 62203830 alloc of 25308 b
809d0e4c: 73657479 69616620 2164656c 00000000 ytes failed!....
809d0e5c: 00000000 0029003c 06000000 6e72654b ....<.).....Kern
809d0e6c: 70206c65 63696e61 6e202d20 7320746f el panic - not s
Can you please update that second commit with reasonable description and
send it out? I will take it via my tree and will send pull request to Linus.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
2018-03-12 10:21 ` Michal Simek
@ 2018-03-14 15:04 ` Michal Simek
2018-03-16 15:18 ` Rob Herring
0 siblings, 1 reply; 8+ messages in thread
From: Michal Simek @ 2018-03-14 15:04 UTC (permalink / raw)
To: Alvaro G. M., Rob Herring; +Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2226 bytes --]
On 12.3.2018 11:21, Michal Simek wrote:
> On 12.3.2018 08:52, Alvaro G. M. wrote:
>> On Fri, Mar 09, 2018 at 01:05:11PM -0600, Rob Herring wrote:
>>> On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. <alvaro.gamez@hazent.com> wrote:
>>>> Hi,
>>>>
>>>> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
>>>> makes microblaze unbootable.
>>>>
>>>> I'm sorry I can't provide any console output, as nothing appears at all,
>>>> even when setting earlyprintk (or at least I wasn't able to get anything
>>>> back!).
>>>
>>> Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so
>>> memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK &&
>>> !CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and
>>> it can be removed, but I'm still investigating. Can you try out this
>>> branch[1].
>>>
>>> Rob
>>>
>>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>>> microblaze-fixes
>>
>> Hi, Rob!
>>
>> This branch does indeed solve the issue. My microblaze system is now
>> booting as it did before, and everything seems normal now. Thanks!
>>
>> Tested-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
>>
>
> I have tested it and I can also confirm that your two patches are fixing
> issue with
>
> 809d0e2c: 00240034 26000000 746f6f62 206d656d 4.$....&bootmem
> 809d0e3c: 6f6c6c61 666f2063 33353220 62203830 alloc of 25308 b
> 809d0e4c: 73657479 69616620 2164656c 00000000 ytes failed!....
> 809d0e5c: 00000000 0029003c 06000000 6e72654b ....<.).....Kern
> 809d0e6c: 70206c65 63696e61 6e202d20 7320746f el panic - not s
>
> Can you please update that second commit with reasonable description and
> send it out? I will take it via my tree and will send pull request to Linus.
>
I couldn't wait to fix current issue till 4.16 is done that's why I have
sent that patches with updated commit message to lkml.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
2018-03-14 15:04 ` Michal Simek
@ 2018-03-16 15:18 ` Rob Herring
2018-03-16 18:02 ` Michal Simek
0 siblings, 1 reply; 8+ messages in thread
From: Rob Herring @ 2018-03-16 15:18 UTC (permalink / raw)
To: Michal Simek; +Cc: Alvaro G. M., linux-kernel
On Wed, Mar 14, 2018 at 10:04 AM, Michal Simek <monstr@monstr.eu> wrote:
> On 12.3.2018 11:21, Michal Simek wrote:
>> On 12.3.2018 08:52, Alvaro G. M. wrote:
>>> On Fri, Mar 09, 2018 at 01:05:11PM -0600, Rob Herring wrote:
>>>> On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. <alvaro.gamez@hazent.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
>>>>> makes microblaze unbootable.
>>>>>
>>>>> I'm sorry I can't provide any console output, as nothing appears at all,
>>>>> even when setting earlyprintk (or at least I wasn't able to get anything
>>>>> back!).
>>>>
>>>> Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so
>>>> memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK &&
>>>> !CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and
>>>> it can be removed, but I'm still investigating. Can you try out this
>>>> branch[1].
>>>>
>>>> Rob
>>>>
>>>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>>>> microblaze-fixes
>>>
>>> Hi, Rob!
>>>
>>> This branch does indeed solve the issue. My microblaze system is now
>>> booting as it did before, and everything seems normal now. Thanks!
>>>
>>> Tested-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
>>>
>>
>> I have tested it and I can also confirm that your two patches are fixing
>> issue with
>>
>> 809d0e2c: 00240034 26000000 746f6f62 206d656d 4.$....&bootmem
>> 809d0e3c: 6f6c6c61 666f2063 33353220 62203830 alloc of 25308 b
>> 809d0e4c: 73657479 69616620 2164656c 00000000 ytes failed!....
>> 809d0e5c: 00000000 0029003c 06000000 6e72654b ....<.).....Kern
>> 809d0e6c: 70206c65 63696e61 6e202d20 7320746f el panic - not s
>>
>> Can you please update that second commit with reasonable description and
>> send it out? I will take it via my tree and will send pull request to Linus.
>>
>
> I couldn't wait to fix current issue till 4.16 is done that's why I have
> sent that patches with updated commit message to lkml.
Thanks for writing my commit msg. :) I got distracted looking at
whether other arches got broken too and didn't get this sent out.
BTW, there is a more simple fix of just moving setup_memory() call to
before unflattening if you prefer for 4.16.
Rob
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b
2018-03-16 15:18 ` Rob Herring
@ 2018-03-16 18:02 ` Michal Simek
0 siblings, 0 replies; 8+ messages in thread
From: Michal Simek @ 2018-03-16 18:02 UTC (permalink / raw)
To: Rob Herring; +Cc: Alvaro G. M., linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 3073 bytes --]
On 16.3.2018 16:18, Rob Herring wrote:
> On Wed, Mar 14, 2018 at 10:04 AM, Michal Simek <monstr@monstr.eu> wrote:
>> On 12.3.2018 11:21, Michal Simek wrote:
>>> On 12.3.2018 08:52, Alvaro G. M. wrote:
>>>> On Fri, Mar 09, 2018 at 01:05:11PM -0600, Rob Herring wrote:
>>>>> On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G. M. <alvaro.gamez@hazent.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've found via git bisect that 0fa1c579349fdd90173381712ad78aa99c09d38b
>>>>>> makes microblaze unbootable.
>>>>>>
>>>>>> I'm sorry I can't provide any console output, as nothing appears at all,
>>>>>> even when setting earlyprintk (or at least I wasn't able to get anything
>>>>>> back!).
>>>>>
>>>>> Ah, looks like microblaze doesn't set CONFIG_NO_BOOTMEM and so
>>>>> memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK &&
>>>>> !CONFIG_NO_BOOTMEM. AFAICT, microblaze doesn't really need bootmem and
>>>>> it can be removed, but I'm still investigating. Can you try out this
>>>>> branch[1].
>>>>>
>>>>> Rob
>>>>>
>>>>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>>>>> microblaze-fixes
>>>>
>>>> Hi, Rob!
>>>>
>>>> This branch does indeed solve the issue. My microblaze system is now
>>>> booting as it did before, and everything seems normal now. Thanks!
>>>>
>>>> Tested-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
>>>>
>>>
>>> I have tested it and I can also confirm that your two patches are fixing
>>> issue with
>>>
>>> 809d0e2c: 00240034 26000000 746f6f62 206d656d 4.$....&bootmem
>>> 809d0e3c: 6f6c6c61 666f2063 33353220 62203830 alloc of 25308 b
>>> 809d0e4c: 73657479 69616620 2164656c 00000000 ytes failed!....
>>> 809d0e5c: 00000000 0029003c 06000000 6e72654b ....<.).....Kern
>>> 809d0e6c: 70206c65 63696e61 6e202d20 7320746f el panic - not s
>>>
>>> Can you please update that second commit with reasonable description and
>>> send it out? I will take it via my tree and will send pull request to Linus.
>>>
>>
>> I couldn't wait to fix current issue till 4.16 is done that's why I have
>> sent that patches with updated commit message to lkml.
>
> Thanks for writing my commit msg. :) I got distracted looking at
> whether other arches got broken too and didn't get this sent out.
>
> BTW, there is a more simple fix of just moving setup_memory() call to
> before unflattening if you prefer for 4.16.
I have sent pull request to Linus with your two patches and a lot of
architectures is setting this up that's why not a problem. I need to
also look at the rest of your patches and how in-kernel dtb is handled
because there is a size limit which was fine for years but we have
reached the case that it is not enough. Simple extension is easy but not
generic solution.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-03-16 18:02 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-09 12:51 Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b Alvaro G. M.
2018-03-09 19:05 ` Rob Herring
2018-03-10 13:15 ` Michal Simek
2018-03-12 7:52 ` Alvaro G. M.
2018-03-12 10:21 ` Michal Simek
2018-03-14 15:04 ` Michal Simek
2018-03-16 15:18 ` Rob Herring
2018-03-16 18:02 ` Michal Simek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.