by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Thomas Jakober
    @tjakober
    It seems I have WSL1
    Gregor Hartmann
    @HHHartmann
    Could it be that your sources are quite old?
    Wer had this error fixed some time ago.
    Thomas Jakober
    @tjakober
    No, I just downloaded them. But what was the solution when you fixed it?
    Thomas Jakober
    @tjakober
    I tried to make the epp8266 and I get the same error. It seems to be a problem under wsl.
    PRUNE libmain.a libc.a
    /bin/sh: 1: Syntax error: "(" unexpected
    Makefile:334: recipe for target '/home/thomas/nodemcu-firmware/nodemcu-firmware/sdk/.pruned-3.0-e4434aa' failed
    make: * [/home/thomas/nodemcu-firmware/nodemcu-firmware/sdk/.pruned-3.0-e4434aa] Error 2
    make: Leaving directory '/home/thomas/nodemcu-firmware/nodemcu-firmware'
    Gregor Hartmann
    @HHHartmann
    Then please feel free to open an issue so it can be tracked properly
    uDude
    @uDude

    @tjakober What are your .h changes. I just used linux x64 w/o issue on default...

    git clone --recursive https://github.com/nodemcu/nodemcu-firmware
    cd nodemcu-firmware
    make -j8
    git show-ref | grep HEAD
    71a182caa7841cbb478ed90ede526dc881943c80 refs/remotes/origin/HEAD

    I showed the head ref, too just in case something was fixed before I posted.

    uDude
    @uDude
    @tjakober I went further back in the chat history and see that my answer above does not answer your question.
    uDude
    @uDude

    Yeouch. I was just looking at 'smartconfig.' Man is it ugly for security, even using AES. In the situation where you are a company and you have pre-provisioned your devices with specific AES keys to deliver to the public customer, those keys live on the device. We all know how to dump the storage, find the programs, perform disassembly or whatever is needed to find the keys. Now after they are publicly shared some war driver can capture your packets (or your neighbor can do the same) and your network is passphrase is known. Even without capturing the AES key, an attacker can drop a device with battery to capture the info of the target. The device can then get on the network transmit its passphrase to "destination hosts somewhere belonging to 'chchchoo' (sorry had to sneeze) the attacker." The device erases itself to avoid detection or maybe reconfigures itself for some rapid or stealthy recon. It could just alter the key to send you on a fools errand when doing your response effort to figure out what someone did. Basically smartconfig will unwittingly put the networks of your customers at risk -- or your personal network if you use it yourself.

    No matter what, good security practices indicate that you should pay attention to what hosts are on your network -- or use good provisioning techniques that meet your risk threshold for your Intellectual Property (which may or may not include smartconfig). I don't use it.

    Marcel Stör
    @marcelstoer
    uDude
    @uDude
    Saw that and was pleased :). Generally, the only thing I wish for this project is that we could pay someone (or more) full time to port it to a handful of other MCUs (e.g., STM). I'm personally quite ill which is why I'm so spotty on the chat.
    uDude
    @uDude
    All -- I have a question. The blocksize of the flash HW write is 4KB ???
    uDude
    @uDude
    I see it in the docs -- I just didn't dig through spiffs code to see if it matches. If it is 4KB then I have question about "app/lua/lflash.c has #define WRITE_BLOCKSIZE 2048. Now is it set to 2KB for memory issues? Each time the 2KB write happens the esp should read the full block, update it, then write it. So writing with 2KB means double the reads and double the writes for each write. Correct?? I know this routine should rarely be used but I'm just curious about the reason for 2KB rather than 4KB.
    KT819GM
    @KT819GM
    isn’t lflash.c lfs part? if so it’s read only on spiffs?
    uDude
    @uDude
    @KT819GM -- yes it the code is part of lfspart, and it modifies the partition table on disk; hence my curiosity.
    Thomas Jakober
    @tjakober

    The Makefile definitely does not work on wsl. I made now a VM with Ubuntu and there it will compile to some extent. However also there I have a missing file:
    In file included from /home/thomas/nodemcu-firmware-esp32/components/luac_cross/../lua/lua.h:18:0,
    from /home/thomas/nodemcu-firmware-esp32/components/luac_cross/../base_nodemcu/linit.c:12:
    /home/thomas/nodemcu-firmware-esp32/components/luac_cross/../lua/luaconf.h:305:10: fatal error: readline/readline.h: No such file or directory

    include <readline/readline.h>

          ^~~~~~~~~~~~~~~~~~~~~

    compilation terminated.

    Gregor Hartmann
    @HHHartmann
    You are missing a package. Judging from
    libreadline-dev. There might be more.
    Thomas Jakober
    @tjakober
    this did the job. Thanks alot
    Gregor Hartmann
    @HHHartmann
    Glad i could help
    Terry Ellison
    @TerryE
    @uDude, there isn't a flash write block size, per se. There is a block erase quanta of 4 Kb, but writes are a multiple of aligned words and use NAND write rules.
    See Wikipedia article on this. In fact the smallest write we do is 1 bit.
    Terry Ellison
    @TerryE
    There is an overhead with writing, as the ICache is disabled by the SDK during the flash write and hence write to flash has a per record overhead. The block size is somewhat arbitrary, and is as compromise between reducing the per write overheads and RAM needed.
    Thomas Jakober
    @tjakober
    I am struggling with the new ESP32 time module. When I set the timezone to EST I get one hout less than it is actually. When I set it to UTC+1 which should be equivalent to EST, I get two hours less. Only when I set it to UTC-1 I get the correct time. I am in Switzerland and we currently do not have DST. What I am thinking wrong?
    Thomas Jakober
    @tjakober
    I have also another problem: How can I clear the wifi configuration? The previous wifi.sta.clearconfig() does'nt exist anymore. And even wifi.sta.disconnect() does not work:
    KT819GM
    @KT819GM
    try wifi.setmode(wifi.NULLMODE, true) to see if it will clear wifi credentials
    Thomas Jakober
    @tjakober
    No after this and then revert to station mode it connects again to the previous ap
    KT819GM
    @KT819GM
    after that you should do restart, not go back to STA, but still it’s highly possible that on esp32 it will not work :(
    Thomas Jakober
    @tjakober
    After restart it goes to nullmode but after setting station mode it connects anyway
    M.K.
    @mk-pmb
    hi :)
    What are the technical reasons we have to decide at compile time which modules we want to include?
    Could we move towards something like Dynamic Kernel Module Support?
    Maybe have a directory modules/ in the flash file system and at boot time inject modules/*.so into the firmware memory? (I'd like it to ignore subdirs, reasons on demand.)
    What would it take to also make the firmware provide an additional USB endpoint that offers the flash file system as a mass storage device?
    KT819GM
    @KT819GM
    About USB endpoint - it’s hardware limitation on esp8266 (and current esp32) in first place, as you can't translate 5V signals into 3V ones in firmware. Or you mean to use USB to UART like cp2102 and somehow mount it as disk?
    KT819GM
    @KT819GM
    And technical reasons should be obvious - you have limited ram and storage and you can’t recompile firmware to add C modules on mcu itself. But it’s possible to add / remove Lua modules on the fly. But maybe I’m wrong.
    M.K.
    @mk-pmb
    Originally I meant using the USB port that I use to power it and upload the firmware. My board looks very similar to this: http://www.nodemcu.com/images/thumbnail/z1s_1.jpg_450x300.jpg but if we can afford the resources to run a second USB device personality, it would sound interesting to do that. I do have a 2 port logic level converter circuit board.
    were your "obvious" reasons meant for doing the DKMS compile on the MCU itself? yeah that was so obviously wasteful I didn't even consider it as the goal. :-) I meant it just as a direction, and I also now I see it was a misleading one because turns out you don't even need DKMS just to load kernel modules at runtime, sorry. I had just that latter part in mind, loading pre-compiled additional drivers from the flash disk at boot, so toggling a vendor-specific module would be just rename a file and reboot.
    M.K.
    @mk-pmb
    more importantly, you could easily free up space of unused modules, and upload new ones.
    KT819GM
    @KT819GM
    I think it’s not possible to mount it as disk trough uart, thats why I wrote “somehow". Software like nodemcu-uploader, nodemcu-tool exists for exact this purpose - to upload file into spiffs. With Lua it’s a bit different development metodology, usually you create “bones" - firmware with modules predefined modules which you cant replace with Lua code, and you modify / update just Lua parts trough cable / air. All goes fast and painless. I trully understand what your point is, but I doubt that even ecosystems like arduino / mbed have this “modules / dependencies on the fly” feature.
    M.K.
    @mk-pmb
    emulating traditional USB mass storage would have been just a nice bonus, and I can replace that with a specialized virtual file system driver on the host (i.e. FUSE in my case).
    I'm trying however to make the build process as simple as possible, so people can just get started and postpone as many decisions as possible. especially don't have to worry about backupping their flash-stored files just to try a new module for whatever latest blinkentoy vendor.
    ideally we could get down to one firmware image per CPU architecture and number type (int/float) and people with more flash will just have more flash storage, then put the optional modules there.
    thinking of it, that would even enable me to change modules via wifi, that would be a LOT cooler.
    KT819GM
    @KT819GM
    With LFS I think it’s now possible to load almost all C modules into firmware and run code from LFS. You can change Lua code trough wifi easily, like trough FTP.
    think of this - how many times you need to remove / add module ads1115.c from firmware?
    x^n times less than updating your lua code, which you can update in any way you like
    HTTP_OTA Lua module as example will take your LFS and update it for you, you choose how to launch it
    M.K.
    @mk-pmb
    yeah that's a good step in the right direction already. as I understood it though, LFS only works for ESP32, right?
    KT819GM
    @KT819GM
    no
    it’s for ESP8266 mainly because of ram