Booting Linux on ESP32-S3 with U-Boot #19
Comments
|
It would, but why would anybody want that? |
|
I'm interested in trying to create drivers for the ESP32-S3's hardware without the need of ESP-IDF or without anything that ESP-IDF does getting in the way. I do also want to check out developing for bare-metal Xtensa on the ESP32-S3. |
|
Developing your own drivers will be hard for the Wifi part, which requires closed-source firmware that interacts with FreeRTOS(or at least tries to; You could possibly stub out the required FreeRTOS functions). The Wifi hardware is not documented. I think in some ways the ESP-IDF makes creating new drivers for Linux easier - You can just create a small binding between FreeRTOS and Linux via the IPC mechanism, instead of a full driver. If you actually just want working drivers, don't re-implement them yourself, just use the ESP-IDF drivers in Linux via the IPC, and write a Linux "stub" driver. But if you just want to learn about embedded programming I guess you could just try to port u-boot! Learning is guaranteed :P |
|
I will learn, which is what I'm aiming for! I want to see if I can get U-Boot to replace the main app entirely so that only the bare minimum of ESP-IDF would be needed. |
The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: c15471f ("ocfs2: fix sparse file & data ordering issue in direct io") Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Reviewed-by: Heming Zhao <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
|
Is there any progress for U-boot to esp32 (sx6 cores.? sx7 cores.?). I like to remote boot pxe (wifi.?) SD-card images also welcome.. 8MB psram boards on to desk.. (functional I2C and SPI drivers, I2S & ADC like to have also functional..) Thank you |
|
Sorry, can't say I've made much progress. I've been caught up with school and work, and before that, I was struggling to get the fundamentals of the processor to work properly. Plus, I still need to make a custom bare-bones bootloader that sets up the bare minimum for operating systems. Sorry to disappoint. As for kernel sources, this repository on the For peripherals, you have GPIO, USB, and SPI. You can bit-bang I2C. |
|
Thanks for fast reply, I just cloned U-boot sources and have fresh 19.1.5 clang (Xtensa&etc) compiled to /usr/local Wifi drivers need to get from esp-idf for closed source blob reason.? Is there any reverse engineering or some docs of them.? Got some google link that someone have done hacks of them but no documentation how.. Thank you Hmm, edit: esp32 sx6 cores don't have USB, so it means not functional kernel for sx6-cores or missed something.? Edit2: found this some work for esp32 wifi: Edit3: Cheked U-Boot sources and find there is some Xtensa support for HW types and find some note from OpenWrt list: "Home-built using buildroot. I have three different xtensa toolchains Btw you mentioned I2C bitbang drivers. Well not like much of them due blocking feature and low performance in multitasking enviroment (any OS, like freertos). For that reason I did about year ago for esp8266 chips I2C driver (lack hw/idf support for I2C(.?)). It uses one timer firing IRQ (can drive other hw too at same, if someone will do so), use circular buffer and is moustly used for I2C-LCD(64x128) ".nix virtual tty" display system. Runs 100Khz fine and dosn't do blocking for OS.. Got it running, but not used much due esp32 chips have more future.. Basically reason was that esp8266 chips have solder holes and bigger mask, so can hand solder hw more easilly than esp32-S3 etc. It is bad mistake from esp-people to drop solder holes from chips above esp8266. There should be models of -S3 etc. that have enough big layout & solder holes to get hand solder protos possible.. Order PCB, yes, later, need software first functional, especially for chips that have octa-ram 64MB or greater and good linux(-rt, emc2, grbl) support.. Edit4: Hmm, for esp8266(lx106),esp32 (sx6), esp32-S2 & -S3 (sx7), but lacks IRQ and MPU/MMU(?): |
Would it be possible to get a proper bootloader like U-Boot onto the ESP32-S3 and boot Linux with it?
The text was updated successfully, but these errors were encountered: