minishell when typing, easily execute code outside RAM or ROM on stm32p103

[mlouielu]

When running qemu with stm32p103, typing in minishell will easily crash.

Memory map:                  
  .text   = 00000140--000225d0  140432 Bytes               
  .rodata = 00022608--000298ee   29414 Bytes               
  .data   = 20000000--2000051c    1308 Bytes               
  .bss    = 20000520--20001c6c    5964 Bytes               
  .heap   = 20001c80--20009c80   32768 Bytes               
  .pgmem  = 20018000--2001f000   28672 Bytes               
Order  Bitmap                
    0  00000000  00000000  00000000  00000000              
    1  00000000  00000000    
    2  00000000              
    3  00007fff              
Created idle_thread at <0x20018200>                        
Created main_thread at <0x20018800> with priority=31       
Reclaim early stack's physical memory (2048 Bytes, order=3).                                                          
Creating /proc/version       
Creating /proc/meminfo       
Creating /dev/mem            
Creating /dev/null           
Creating /dev/zero           
Creating /dev/random         
Creating MTD device mtd0     
Kernel bootstrap done.       
--                           
Piko version 0.0.0 (grd@louie) (armv7-m, cortex-m4) #Tue Aug 15 10:48:37 2017                                         
arm-none-eabi-gcc (Arch Repository) 7.1.0                  

$ pqemu: fatal: Trying to execute code outside RAM or ROM at 0x79797978                                               

R00=79797979 R01=00000026 R02=00000001 R03=00000000        
R04=00000000 R05=00000000 R06=00000000 R07=20018fd8        
R08=00000000 R09=00000000 R10=00000000 R11=00000000        
R12=00000000 R13=200189fc R14=00000483 R15=79797978        
PSR=00000173 ---- T svc32    
FPSCR: 00000000              
make: *** [target/stm32p103/build.mk:6: run] Aborted (core dumped)                                                    

[iankuan]

That's really a bug. In my opinion, we use printk to output msg without buffering and interrupt disabling, so it really makes sense. However, I'm now working on tty(perhaps third pick). I guess it would be resolved after that patch.

By the way, a quick fixup is to disable interrupt when using printk. But that's not fit our design principles, we wouldn't accept that fixup.

[mlouielu]

@yenwu What is third pick? So the problem came from "when using printk printing, it get some interrupt?`

[iankuan]

Ouch, I shot myself in the feet. Disable interrupt is already exist in impl of printk.

@mlouielu , I mean that tty is the third entry in TODO-list.

[mlouielu]

When hanging, read will not block and repeatedly reading char. Maybe buffer problem?

[mlouielu]

After some investigating, I can finally reproduce this problem on QEMU with gdb.

How to reproduce

• set breakpoint at tasklet_schedule
• run make TARGET=stm32p103 dbg and make TARGET=stm32p103 gdb
• in gdb, continue
• When break at tasklet_scheudle, p current_thread_info() to check which thread you are at.
• If current_thread_info() return thread_main, then type something at QEMU
• It will freeze after bitmap_enqueue.

Why hang?

tasklet_schedule didn't check which thread is executing, and it was called by systick.c:systick, the thread was switching between softirq and main, so there is a 1/2 chance you will hang because it execute in main thread, not softirq.

Proposing #24 to fix this problem.

[iankuan]

Dear @jserv , @mlouielu ,

I have already modify the issue title of #12 to specify the platform, stm32p103. There might be some bugs on qemu for stm32p103. I have already tested it on real hardware, stm32f429 for minishell and even msleep_2.

If anyone can reproduce that on stm32f429. Please post another issue.

Thanks.